This is a list of reasons why I use Linux as my primary operating system (I use Arch BTW), and why I will continue to do so as long as it's physically possible, or until something better comes along. Early in 2022 I made a list of pros and cons of using Windows and why I choose to use Linux, however the longer I use Linux the list of cons for Windows continues to get longer. Therefore this page exists as a "living document" to act as an extention to that article.

Code Signing

Microsoft and Apple make use of Code Signing in their operating systems, and the certificates used as part of that code signing have an expiration date, just as any secure certificate would. This is a problem, however, if you happen to be offline during the right period of time, or you put your computer away for a few years and want to come back to it. All of a sudden your software won't launch. This isn't even some apocalypse or software archival scenario; shortly after Windows 11 was released, a code signing certificate expired causing built-in programs like Snipping Tool to fail to launch. A similar incident happened with Apple's MacOS in 2017.

As for the apocalypse/survival scenario, you could load up a laptop with all the software and documentation you may need, stick it in a faraday cage, and leave it until the apocalypse comes, knowing that when you boot it up everything will work and won't need an internet connection.

Spyware

On top of Windows 10 and 11 collecting unknown amounts of telemetry from every installation of Windows, it is becoming more and more reliant on having an attached Microsoft account, which can be suspended by Microsoft for benign reasons such as uploading a picture of your child in the bath to OneDrive or even just using a vpn. A similar incident happened with Google where a parent took a photo of their childs groin to send to their doctor, which google found and suspended then ultimately terminated their account over.

Auditable

If you really want to, you can audit all of the open-source software that comes with your distribution of choice. You can look at what the kernel is doing, you can look at encryption algorithms, or you can see how your spreadsheet macro is implemented. While you may not be able to look at everything, and while there are still sometimes binary blobs (for instance firmware loaded into a device on initialization like video cards, wifi modules, etc.), you can still inspect how the kernel is interacting with those devices. I personally have had issues in the past and found the problem by bisecting the kernel; there's no way I would have been able to do that with Windows or a proprietary driver.

Even NVIDIA, who Linus Torvalds once gave the middle finger to due to them being a pain to work with, has released open source drivers for their newer cards, and as of this writing appear to be maintaining them. While still incomplete, it's a good start and at the very least blows the door open for Nouveau to drastically improve their drivers.

Yes, you can run open source software on Windows or MacOS as well, however a lot of open source software originates on Linux and therefore Windows and MacOS generally end up being second-class citizens for a lot of software.

Filesystem Cleanliness

In general, all software that you'll install on Linux will be included in some sort of package manager, if not the one your distribution came with then one like Flatpak or Snap. Since everything is installed and tracked via a package manager, the filesystem in general is kept relatively clean. The only places that will have untracked files are generally the /home and /var directories, alone with any changes you manually make to /etc. Unless you do something dumb like sudo make install, the rest of the filesystem should only have files that are tracked by a package manager. This prevents problems that plague windows such as old dlls laying around causing problems for newer programs, or just filesystem bloat in general.

In theory, Windows' Add/Remove Programs feature is supposed to take care of this, however that relies on the programs uninstaller to actually remove everything related to the program. Similarly, on MacOS, programs are generally uninstalled by moving the program itself to the trash, however that doesn't cleanup the Library folder.

Yes, your home directory can become a mess in Linux, however you can generally tell what's no longer needed as most programs are well behaved and stick their settings, cache, and other data in directories that contain their name or the name of their developer. That, and if you wanted to start fresh, you can just remove all of the folders that start with a . in your home directory, logout, and then log back in, and you've kept all your data and basically have a fresh installation.

Filesystems

Linux has a plethora of filesystems to choose from for all types of use-cases that you may have. You have ext4 as your general purpose filesystem, BTRFS for your "next-generation" filesystem that supports Copy-on-Write, as well as snapshots, compression, etc.. Then, you have XFS which is taken from IRIX and is a high-performance filesystem that supports checksumming and other features. You also have support for a lot of other operating systems such as NTFS, FAT, HFS, and even Apple's new APFS, among other old and esoteric filesystems. Basically, if it's a filesystem used generally within the last 20 years or so, Linux can read it, with some exceptions.

I personally have found that XFS is able to max out the speed of modern NVME disks and supports features such as checksumming, reflinks (only supported in BTRFS and XFS as of the time of this writing), and is working on features such as Copy-on-Write, and therefore that's what I primarily use as of the time of this writing. I've also used BTRFS in the past.

On top of the regular filesystems, you have FUSE which allows filesystems to be defined in user-space, i.e. you don't need to be a kernel expert to create one. It doesn't even have to be a concrete filesystem; it could be something simple like IgnoreFS.

Command Line

Due to the way Linux's filesystem is laid out, all programs are available to be run from the command line by default. Since Windows and MacOS keep programs inside of their own directories (yes an .app file is a directory), you either have to have a ton of paths in your PATH environment variable, or you have to specify full paths to applications. This is, in general, annoying on Windows and MacOS. You could say that PowerShell somewhat resolves this by having its own commands, or that for MacOS nothing is interesting in .app directories for the CLI, however there are occasionally programs that you need such as VMware's cli programs for VMware fusion, or gpg on Windows.

Battery Life

Battery life is generally better on Linux, with some exceptions. In general, Linux is more efficient due to fewer services running in the background by default; you don't have programs reaching out to Microsoft to check for updates, you don't have an anti-virus program constantly checking stuff, nor do you have other services doing who knows what in the background. You do have services running by default in Linux, but they're generally not doing anything unless certain things happen, or it's checking for updates for the entire system, not just the base operating system.

Windows can eek out better battery life in some situations, however it does so by dramatically throttling the processor and gpu, creating a generally bad experience.

Audio Subsystem

Linux has a fantastic audio subsystem, previously PulseAudio and now replaced by PipeWire. Not only can each physical input/output be controlled individually, but each applications input/output can also be controlled separately along with which specific physical or virtual inputs/outputs the applications inputs/outputs are connected to. Inputs/outputs can be connected connected together between applications, combined for multiple outputs, or in any other logical manner you could think of. Take a look at the QjackCtl project to see what's possible.

But wait, QjackCtl uses JACK, not PipeWire. What gives? Without going into the entire history of Linux audio, PipeWire replaces a handful of older standards, ALSA, JACK, and PulseAudio, and combines them all into a single backend. Applications that use any of those subsystems will transparently use the new PipeWire backend, which also allows applications using different standards to interact with eachother.

Windows' audio subsystem is similar, however its full functionality isn't exposed by default and requires third-party, generally proprietary, programs to do any kind of advanced manipulation. MacOS is similar in that additional functionality can be unlocked with third-party programs, however it's generally even more limited than Windows.

Backwards Compatibility

This is a bit of an odd one; Linux doesn't genrally have great backwards compatibility in the traditional sense. For instance, library updates that result in a new ABI require recompilation of all programs that depend on it. Given the repository model of most Linux distributions, this isn't really a problem. However, if you use software that's not in the repository that is say proprietary so that it can't be fixed or even recompiled, you have a problem.

Fortunately, there's ways to get around this. First, the application can be containerized in some way, using AppImage or Flatpak to package the application with older libraries that will be used instead of system libraries. You could also use environment variables such as LD_LIBRARY_PATH and/or LD_PRELOAD to tell Linux where to look for shared libraries or to preload certain libraries. If push comes to shove, you could even install an older distribution into a chroot and run the application from there.

As a last resort, if the library you're trying to use/replace is open source, or if you're able to decompile the library, it's always possible to write a shim library (i.e. one that implements the same ABI but passes through the request to another library) to either replace the library entirely or interface it with a newer version.

Windows is able to do something similar with libraries and backwards compatibility, but it's functionality that is generally hidden and uncontrollable from the end-user, as with a lot of advanced features of Windows.

On top of that, you have WINE for running traditional Windows programs. While WINE won't run all Windows programs, compatibility is getting better and better every day, especially given contributions from Valve with their Proton version of WINE. Given the configurability and flexibility of WINE, it's possible that programs that fail to run or run poorly in the most recent version of Windows function just fine within WINE.

Again, Windows has a compatibility layer now to help with running older programs, however it's hidden away in properties dialog and even then it's not very configurable; it generally either works or it doesn't, and it when it doesn't you don't have much recourse for trying to correct the issue.