Goin’ back to Windows: small, fuzzy apps and compatability settings

This is part of a series on moving from desktop Linux back to Windows.

The first post is here. The previous post is here.

In the first post, I mentioned that one of the motivators for moving back to Windows was that I really liked the hardware of the Lenovo Yoga 920.

I bought one of the “4k Ultra HD Touch Screen” models, not because I cared about the 4k but because it was overall better spec’d. I’m not even sure 4k is realistically perceptible, or useful, on a 14″ laptop.

In fact, on Windows 10, it does have a drawback: lots of apps I’ve installed by default show up really small and fuzzy. And some apps, while “right-sized”, had fairly fuzzy text.

One of the first apps I installed (via Chocolatey, see previous post) was Launchy. And after installing it and activating it with alt-space, I got this:

See how small that is in the pic? Crazytown. It should look like this:

I got the same thing for other apps such as Gimp and VS Code.

Fortunately, the fix is straightforward, if annoying since it seems you have to do it on a per-app basis.

The trick is to change the “Compatibility — High DPI Scaling” setting to either “Application” or “System” (a bit more on that later), for each app that suffers from this problem. Here’s how:

  1. Use the win key to open up the Windows search bar.
  2. Type the name of the app in question
  3. When the app pops up, right click and select “Open file location”

  1. Then, select the app, right click, and click “Compatibility”
  2. Check the checkbox beside “Override high DPI…”
  3. Select either “Application” or “System”
  4. Click “OK” and re-launch the app and see if it helps

My experience so far is that:

  • “System” works best most of the time for apps whose UI was really tiny
  • “Application” works for apps whose UI was right-sized — like Firefox — but whose text was fuzzy

Props to this post about fuzzy fonts for leading me to this solution, which fixed more than just fuzzy fonts for me.

Goin’ back to Windows: package management with Chocolatey

This is part of a series on moving from desktop Linux back to Windows.

The first post is here. The previous post is here.

Windows software management: the current default state

Three years ago, I wrote about moving from Windows to Linux for personal computing and development. Part of my frustration with Windows was around package management — installing, keeping up to date, and removing software. And part of my motivation for experimenting with moving back to Windows is the existence of what appears to be a serviceable solution for package management on Windows: Chocolatey. More on that soon.

But first, let’s talk the current state of installing and keeping software up to date on the main modern operating systems for consumer use.

Linux effectively makes package management a first-class citizen; Mac doesn’t, but homebrew has become de facto package management for Mac, at least for a developer machine.

For the devices we use for most of our personal computing — the little super-computers in our pockets — we’ve come to expect that software is installed from one place, automatically updated, and simple to remove. Even in the wild and woolly world of Android, you get all your software from Google Play; it’s rare to be downloading and installing .apk files from the Internet.

Yet we continue to suffer this craziness on Windows. If you’ve used Windows for a long time — and especially if you’ve used Windows exclusively — this is probably your software install/update experience:

  1. download an executable (.exe, .msi) from the Internet
  2. click it to install
  3. maybe change its install location but probably not
  4. to update… do the same things
  5. over, and over, and over

If you’ve done this long enough, it might even seem sane, reasonable, no big deal.

But I’ll tell you this: after working on Linux and Mac for enough years, that process above drives me f**king crazy and I want to do it as little as humanly possible.

Installing & Updating Software on Linux and Mac

Let’s say you want to install a recent version of PostgreSQL; or Python; or Redis; or Intellij IDEA; or Docker; or &tc… In Windows, you’d do the thing you do above.

But on Mac, you’d probably use homebrew. You’d install homebrew once; and then from a terminal you’d brew install redis. Or brew install docker. You get the picture. To update, you’d use brew to update: brew upgrade redis. Or brew upgrade docker. Or to update all just brew update; brew upgrade. Easy peasy. No “go out to the Internet and download/click things” nonsense.

On Linux, it’s about the same. Depending on the variant, it might be apt install redis or yum install redis. To update: apt update redis or just apt update to update all.

This is the typical experience. Sure, on both, you sometimes need to go out to the internet and download a thing. But that’s the exceptional case. And, yes, keeping that software up to date is often just as much of a hassle as it is on Windows, which is why you try to avoid that as much as possible

Aside from the huge (to me) benefit of being able to easily update all software with a few commands, there’s also the benefit of being able to see all the software you have installed on your system in a single place.

Regrettably, perhaps until you actually see that stuff in action, you might not realize just how incredible it is. My experience with several years on Ubuntu is that it is so brain-dead easy to keep software up to date that it’s practically more difficult not to. If you believe that up-to-date software generally results in a more secure, reliable system, then Ubuntu makes the right thing to do the easy thing to do.

Enter Chocolatey.

Chocolatey

On Windows, there has existed for several years a similar method for installing, listing, and updating software: Chocolatey. If you checked it out a few years ago and thought, as I did, “it’s just not there yet”… it’s there now. Or, at least, it’s come a loooong way.

As of this writing, there are over 5000 packages available via Chocolatey.

If you read my last post giving props to Jessie Frazelle, and if you checked out her boxstarter file, you see lines like this:

choco install Microsoft-Hyper-V-All -source windowsFeatures
choco install Microsoft-Windows-Subsystem-Linux -source windowsfeatures
choco install sysinternals -y
choco install googlechrome

That’s Chocolatey.

Once installing Chocolatey, from powershell or cmd, you can search for packages with choco search [string]; install with choco install [package]; uninstall with choco uninstall [package]; upgrade with choco upgrade [package]; upgrade all with choco upgrade all. And much much more.

You can see all your Chocolatey-installed packages with choco list -l and you get nice output like this:

PS C:\Users\marc> choco list -l
Chocolatey v0.10.8
7zip.install 16.4.0.20170506
avastfreeantivirus 17.9.3761.0
baretail 3.50.0.20120226
chocolatey 0.10.8
chocolatey-core.extension 1.3.3
ConEmu 17.12.26.0
DotNet4.5.2 4.5.2.20140902
Firefox 57.0.2
gimp 2.8.22.20171021
git 2.15.1.2
git.install 2.15.1.2
golang 1.9.2
GoogleChrome 63.0.3239.84
notepadplusplus.install 7.5.3
spotify 1.0.66.478
sysinternals 2017.12.13
visualstudiocode 1.18.1
windirstat 1.1.2.20161210
18 packages installed.

All Chocolatey-installed software is registered as usual with Windows and so they show up in “Apps and Features” as well.

And, as demonstrated in Jessie’s boxstarter file, you can also install Windows features such as Windows Subsystem for Linux 😍. It’s a darn comprehensive tool.

In short: I like Chocolatey and will use it whenever possible.

Shortcomings

Note: This section has been edited, after figuring out the problem. I’m keeping these problems in here, though, in the very unlikely case anyone else stumbles across this behavior.

I had initially observed 2 problems with Chocolatey:

  1. it hadn’t worked, for me, for installing “big” software (eg Intellij IDEA, Docker for Windows)
  2. it was pretty slow, at least compared with homebrew or apt/yum, and downloading packages even of small size seemed to take a long time

Turns out, the cause of both of these problems was IPv6 settings in my wireless router. There was nothing wrong with Chocolatey. I wrote about how I resolved Chocolatey / Powershell slowness via fixing my router’s IPv6 settings.

Conclusion

Chocolatey seems to be the only game in town for sane package management on Windows. I’m grateful that it exists, I like it, and I’m happy to use it. If you’re on Windows, I encourage you to give it a shot.

Next post: Small, fuzzy apps and compatibility settings

Goin’ back to Windows: Thanks Jessie!

This is part of a series on moving from desktop Linux back to Windows.

The first post is here.

Learning about WSL and Windows Automation from Jessie Frazelle

I mentioned in the previous Goin’ Back to Windows post that I was partly influenced to make the move by reading what Jessie Frazelle and others had written on the topic.

In this quick  post, I want to call out a few of Jessie’s writings in particular.

First, Windows for Linux nerds. She talks about how Windows Subsystem for Linux (WSL) works, calling windows programs from a bash prompt, and even creating a repeatable Windows config script using boxstarter. Great stuff.

In that post, she links to her boxstarter file. Even if you don’t use it (or create your own based on it), I think there’s a lot of value just in seeing what kinds of things a developer might want to do to configure her Windows machine. Also, if you, like I, had never heard of boxstarter, well, now you do. It’s a thing in the world, and it appears to be a good thing indeed.

Thanks for sharing with us, Jessie!

Next post: software package management with Chocolatey

Goin’ back to Windows… Windows… Windows…

Three years ago, I wrote about moving off of Windows/Mac and onto Linux for personal computing and developing.

Three years later, I’ve moved back to Windows.

In that 3-year-old post, which was about habit change and work/life balance, the key features I was looking for in a developer machine were a solid terminal and easier installation/updating of software via package management. The things I use most as a developer these days are Go, a database such as PostgreSQL, docker, a terminal to interact with those things, Jenkins, a web browser, and an IDE of some sort.

In the intervening years, Windows has come a long way. With Windows Subsystem for Linux, Virtualization and top-notch docker support, Visual Studio Code and its myriad of plugins (including Go), Chocolatey, and a few other goodies, Windows has become, for me, just about as enjoyable as Linux and (gasp) probably even more enjoyable than Mac.

So why did I decide to even make this journey in the first place? Two reasons:

  1. a busted Linux laptop
  2. influencers

I was using a dual-booted Samsung Chronos laptop, running Ubuntu. Out of the blue, a few months ago, it became terribly unstable and slow. I simply could not figure it out. Maybe a disk issue? Who knows. I didn’t invest much energy into it because I’ve been shedding Samsung from my life for a few years now and this was an opportunity.

While researching replacement options, I became increasingly enamored with the Lenovo Yoga series, though it was running Windows so… boo. But then a funny thing happened. Internet-famous-to-me people like Jessie Frazelle, Brian Ketelsen, and others had moved to Microsoft to work on Windows-related tech, evangelizing Azure, Go, docker, WSL, etc. Developer friends such as Ray Camden and Sean Corfield were talking about their move back to Windows. And the more I read from them, the more I started to even consider giving Windows another shot.

I liked the hardware of the Yoga a lot, especially for the price, so I took a risk. Worst case scenario was that the Windows experience would suck and I’d just put dual-boot a Linux distro on it.

As of now, I’m really glad I’ve made the switch. In the posts that follow, I’ll discuss the various software and configurations I’m currently using as part of this journey.

Next post: Learning about WSL and Windows Automation from Jessie Frazelle