A somewhat pragmatic comparison of OS for software engineers
The debate on which laptop is the best for professionally developing software has a tendency to get somewhat fanatic and emotional. When it does, this debate quickly depreciates because it becomes particularly difficult to discern opinions from facts, plus people get all shouty which is rarely a good thing in the context of a discussion. It's a shame, because I do believe that it's an important question which will most certainly affect one's development experience in many ways.
Seeing that I have had experience working with all the major contenders (i.e., Windows, Linux, and macOS) at least to some extent, I'm hoping my experience can be of use to people contemplating new setups for professional software development.
It's important that we define KPIs (a fancy word for criteria) which we will use to perform the comparison. Hopefully this will help avoiding statements like X is better because it's gray. Unless gray is a criteria I actually care about (spoiler, I don't), grayness is hardly a pro or a con. Defining KPIs is actually a very tricky part, and is itself a subject of debate since different people tend to care, and therefore prfioritize, different things. For example, some readers may have stopped reading this post back when I said gray was not a KPI I'd be using, simply because they must have their operating system (a.k.a. OS) or laptop, in gray.
Personally, I think the following KPIs are decent when it comes to setups for (professional) software development:
Seeing that I have had experience working with all the major contenders (i.e., Windows, Linux, and macOS) at least to some extent, I'm hoping my experience can be of use to people contemplating new setups for professional software development.
It's important that we define KPIs (a fancy word for criteria) which we will use to perform the comparison. Hopefully this will help avoiding statements like X is better because it's gray. Unless gray is a criteria I actually care about (spoiler, I don't), grayness is hardly a pro or a con. Defining KPIs is actually a very tricky part, and is itself a subject of debate since different people tend to care, and therefore prfioritize, different things. For example, some readers may have stopped reading this post back when I said gray was not a KPI I'd be using, simply because they must have their operating system (a.k.a. OS) or laptop, in gray.
Personally, I think the following KPIs are decent when it comes to setups for (professional) software development:
- Scripting & automation
- Text (files) manipulation (especially important since, well, logs)
- Scripting the operating system
- Software Packages (install/remove software)
- System parameters (query/set OS properties)
- Ecosystem
- Availability of (preferably free) online resources which can assist in solving issues around the OS of choice
- Compatibility/integration with popular relevant open source projects
- Compatibility with the production system
Windows
I spent a good 5 years using C# and developing on Windows at the beginning of my career. I never felt that the operating system was limiting in any way. I liked the cool features C# had to offer and was glad I did not have to use the language-wise inferior Java.
It wasn't until years later, when I started a new position as a data engineer and moved to Linux, that I realized the power it had to offer, and the costs you had to pay. I was part of the data platform team, and we all used Linux, though Mac was also an option. I opted for Linux over Mac because I wanted to have the same setup as my teammates in case I had trouble getting things up on my newly installed Linux laptop. I was not a Linux fanboy, at least not at the beginning.
In terms of the KPIs defined earlier, scripting and automation for Windows were not up to par with Linux whatsoever. The Windows cmd is nowhere near scratching the surface of what Linux based shells have to offer. Linux shells have a ton of built in utils (with even more arguments) text manipulation, querying system properties and installing new packages.
My personal experience having spent the last decade a half as a professional software engineer, is that the Windows culture tends to be less DevOps oriented, and thus less DevOps friendly. I'm not sure whether it was ever intentional, or official, but Windows became known as the operations system for non-techies. It's the user friendly home theater PC in your living room. It's the video game friendly operating system you have on your kid's PC.
Recent trends in the software ecosystem got Microsoft fighting hard to change that image. It has made some interesting moves in that direction, but I believe it will take (much) more time before this image actually changes.
Recent versions of Windows have the WSL (Windows Subsystem for Linux) which:
"... enables you to run native Linux command-line tools directly on Windows, alongside your traditional Windows desktop..."
My experience working with WSL for the past few months has not been ideal. It's definitely an improvement, but it's also definitely not there yet. While the native Windows OS shares the filesystem with WSL, the paths are different and you constantly have to translate one to another. There's a CLI tool to help you with that (wslpath) but it's a tool designed to solve a problem which ideally should never have existed and it's only there because of the Window/Linux tango.
Also, packages you install on WSL won't be available in Windows and vice versa. While it's understandable, it constitutes a poor user experience nonetheless. On top of all these, currently the WSL is simply too slow. Non trivial "git status" commands may take minutes to complete, and trivial ones may cost you a few good seconds of your file.
Recently MS has announced WSL 2, which should have significant speed improvements and will hopefully address the significant speed issues.
Also, packages you install on WSL won't be available in Windows and vice versa. While it's understandable, it constitutes a poor user experience nonetheless. On top of all these, currently the WSL is simply too slow. Non trivial "git status" commands may take minutes to complete, and trivial ones may cost you a few good seconds of your file.
Recently MS has announced WSL 2, which should have significant speed improvements and will hopefully address the significant speed issues.
As far as software package management goes, it was only recently that I learned about chocolatey, a package manager for Windows. According to the chocolatey GitHub repo, its development started circa 2014, so its quite new comparing it to the analogous solutions for macOS (homebrew, add-on, since 2009) and Ubuntu (APT, built-it, since as long one can remember). New isn't necessarily bad, but it does mean that things are likely to be a little rough around the edges.
The culture around Windows is also why the ecosystem for Windows has remained very limited throughout that past decade or so. Microsoft was pretty much the ecosystem, which is both a curse and a blessing. Getting Hadoop or Spark clusters to work on windows has long been a journey not for the faint hearted. On the other hand, since Microsoft was responsible for most of the stuff, the things that were available were usually polished so you wouldn't have to rely on the community as much.
Bottom line is, working with Windows as my main development environment again (i.e., after all the years working on Linux/Mac) left much to be desired.
I couldn't help asking myself why would I use Windows if I kept conducting most of my business in the WSL (cumbersome and slow as it may be)?
Verdict: Not there yet for professional software development. Unless you're developing software on top of, or for, the Microsoft/Windows stack.
I'm far from being an expert on the matter, but I once wrote a script that reloaded my Graphics card drivers because it prevented the laptop from going into sleep mode. I used to run this script before bagging my laptop.
What I liked best about Linux is that it taught me to think in scripts, and scripts are essentially a little gift from God called automation. This has tremendously affected the way I inspect files and logs. Composing (piping) utilities on top of one another is a very fundamental approach in Linux. I'm not familiar with anything remotely as powerful in Windows.
There is a number of desktop environments you can install on top of your Linux system. Ubunto comes with a built-in one called Unity but you can replace it, should you wish to do so. This is not always trivial and you will probably have to resolve some issues along the way. During my Linux period I actually went with Cinnamon over Ubuntu, and had to spend a couple of weekends to get the dual screen setup to work and get things in order.
In fact that was a common problem in Linux, it did not excel at handling peripherals. Fancy keyboards, mice, multi monitor setups, more often than not these would require extra work and searching through community forms. If you wanted to make things feel comfy you had to put in the extra work, That's definitely not for everyone.
Personally, since I came to Linux from Windows, which did a terrific job handling literally all kinds peripherals, having to spend all these hours getting things to work on Linux was very frustrating. The upside was that there were plenty of forums around, and lots of information was available online.
The open source ecosystem loves Linux (it's free, remember?), so in that regard you can't go wrong. Most of the popular open source projects dig Linux and are likely to be built on, and tested on, Linux based systems.
Production systems love the stability of Linux based servers so working on Linux during development will make you feel comfortable ssh-ing and inspecting production servers.
If, however, the production servers are Windows, it does take the sting out of this last argument.
That said, I wouldn't rule out developing on Linux even in this case, but it will require to eventually test things on Windows to make sure things work in production.
Verdict: Unpolished, raw power. Steep, but rewording learning curve - if you stick with it.
Bottom line is, working with Windows as my main development environment again (i.e., after all the years working on Linux/Mac) left much to be desired.
I couldn't help asking myself why would I use Windows if I kept conducting most of my business in the WSL (cumbersome and slow as it may be)?
Verdict: Not there yet for professional software development. Unless you're developing software on top of, or for, the Microsoft/Windows stack.
Linux
Im many many ways Linux based system are kind of the opposite to Windows, for better and worse. Linux puts the emphasis on the underlying stuff, with the shell being the most comprehensive way to access things. The scripting power is immense and scripts are used all over. There's a built-in software package manager that can be easily used in scripts.I'm far from being an expert on the matter, but I once wrote a script that reloaded my Graphics card drivers because it prevented the laptop from going into sleep mode. I used to run this script before bagging my laptop.
What I liked best about Linux is that it taught me to think in scripts, and scripts are essentially a little gift from God called automation. This has tremendously affected the way I inspect files and logs. Composing (piping) utilities on top of one another is a very fundamental approach in Linux. I'm not familiar with anything remotely as powerful in Windows.
There is a number of desktop environments you can install on top of your Linux system. Ubunto comes with a built-in one called Unity but you can replace it, should you wish to do so. This is not always trivial and you will probably have to resolve some issues along the way. During my Linux period I actually went with Cinnamon over Ubuntu, and had to spend a couple of weekends to get the dual screen setup to work and get things in order.
In fact that was a common problem in Linux, it did not excel at handling peripherals. Fancy keyboards, mice, multi monitor setups, more often than not these would require extra work and searching through community forms. If you wanted to make things feel comfy you had to put in the extra work, That's definitely not for everyone.
Personally, since I came to Linux from Windows, which did a terrific job handling literally all kinds peripherals, having to spend all these hours getting things to work on Linux was very frustrating. The upside was that there were plenty of forums around, and lots of information was available online.
The open source ecosystem loves Linux (it's free, remember?), so in that regard you can't go wrong. Most of the popular open source projects dig Linux and are likely to be built on, and tested on, Linux based systems.
Production systems love the stability of Linux based servers so working on Linux during development will make you feel comfortable ssh-ing and inspecting production servers.
If, however, the production servers are Windows, it does take the sting out of this last argument.
That said, I wouldn't rule out developing on Linux even in this case, but it will require to eventually test things on Windows to make sure things work in production.
Verdict: Unpolished, raw power. Steep, but rewording learning curve - if you stick with it.
MacOS
MacOS is kind of the best of both worlds. You get the Linux power (Free BSD), with a polished desktop environment and peripherals support. While it's true that Free BDS is not exactly Linux, but most of the issues I have run into had pretty straight forward solutions (e.g., GNU coreutils instead of the ones that come built-in). The screen quality is amazing and you can use HiDPI to make your external monitor look retina-like (in case it supports high resolution).
In addition to the OS part, a great benefit the Mabook pro is its long battery life. This was especially noticeable when I moved from my Lenovo W530, which used to ran out of juice after ~3 hours, to Macbook pro, which would last more than 5 hours. A giant con to the Macbook pro is its insane price. Luckily, it is usually a non-issue as Macbooks are pretty standard equipment in tech companies.
I took the scenery route working first on Windows, then Linux, then Mac. Once I went Mac I never wanted to go back to any of my previous setups. Truth be told, I can't say that I know anyone who did.
While MacOS and the Macbook pro are not without faults, IMHO it's the best setup for software engineers who wish to have the Linux/Unix power available to them, while not having to fight the OS for their second monitor and other pesky stuff. Things just work out of the (shiny, 3000$ worth) box.
Verdict: The best of both worlds, Linux power with a polished desktop environment. Double the benefits for triple the price.
Comments
Post a Comment