Using Linux as a desktop machine

Editor Note: This was originally published on the Sitewards blog

Probably not. The meme “is ${X} the year of Linux on the desktop?" has been a thing long before I was a developer and will be here likely long after I'm gone. But I am a happy "Linux on the desktop user", at least in terms of my development life. This is post is a reflection on that -- why I use it, what the good parts are, and what the bad parts are (in comparison to Windows*).

The brutal truth about why I use it

I am forever indebted to those colleagues, and the patience with which they helped me migrate to the new system, and answered my patient and apparently stupid questions. I am now a happy Linux user, and would not go back.

The bad parts

Sometimes it breaks. Spectacularly.

  • The ability to boot into Linux mysteriously disappeared.
  • The ability to boot into Windows mysteriously disappeared.
  • The “display manager” (graphical interface) exploded monumentally, rendering me unable to rescue it save on the occasional reboot where I’d get a working display.
  • Updates didn’t complete before battery death leading to a horribly broken system.

All of those things are 12/10 on the “things I did not want to fix” scale. Sometimes, it happens. The good news is, sometimes crazy things also happen with testing environments, or even staging or production machines. It’s nice to have solved a few of these on your desktop before having to desperately search man pages in production.

There are no safeties

Luckily, I was only a week in, and still landing on my feet. But it cost me a day to set my machine back up to something that could develop once again. More generally, this illustrates the point about Linux — there is no safety. No magic recovery mode to help you back on your feet when you do something foolish. Additionally, things do not always come “out of the box” in a good way — notably, Both Debian and Ubuntu ship with no firewalling.

The good parts

Consistent OS from my Dekstop to your production machine

So, I only need to understand a single OS from development right through to production.

Faster development process

  • Run an emulator, which virtualises the Linux machine, or
  • Run the process in a Sandbox called “Docker”, on the same machine

The latter approach allows the processes to execute much, much faster. Because there is no overhead of virtualising things like memory, CPU and disk space and there is no need to sync files over a shared mount I will be able to build and test a chance 3–4 times faster than if I was using an emulator.

Superior development tooling

Practically speaking, this amounts to being able to investigate issues much more quickly with the same set of tools.

Free Software

The software is generally of a good quality, and if it’s not it’s often simple enough to fix.

Entirely Transparent

That sort of visibility has become a critical part of my workflow, and I find it stifling when code is obfuscated or compiled and sources hidden.

In Summary

There’s goods and bads to all things. But this is what works for me, and I hope it’s illustrative to you.

Still with me? Awesome! I’m glad you found it interesting. If you’re curious about anything further, or have more general Linux questions we’re always available if you reach out — just hit the “Contact” link

If you’re super excited about the idea of working with Linux as your development machine you sound like just the sort of person we’re interested in paying for you to do some work we have! Check out the “Jobs” link for further information.

  • I don’t know MacOS very well.