Switcher 2026: The Zen of Linux ⭐

A few weeks back, we were preparing for our return to Pennsylvania from Mexico City, and I spent a few hours the previous Saturday resetting and decommissioning several laptops that I wouldn’t need during our last days in that apartment. I was surprised by two things in the wake of this work, the first being the electrical explosion described in From the Editor’s Desk: All’s Well That Ends Well ⭐️ that distracted me for the next 24 hours. And the other being that I found myself missing Linux each day: Some of those laptops were running whatever Linux distributions and I had worked them into my daily workflow.

Interesting. Also, unexpected.

One of the oddities of my life is that I end up flying between Mexico City and PA with multiple laptops, and the reality of this particular flight was that I was already planning to bring four laptops back to PA. So keeping a Linux-based laptop up and running didn’t really make sense. And I knew that when I returned to PA, I’d have access to all kinds of laptops, including many based on 12th and 13th generation Intel chipsets that would be ideal for testing Linux. All I had to do was wait a few days.

But it bothered me. I installed the Windows Subsystem for Linux (WSL) on the Lenovo IdeaPad Slim 5x Gen 11 that I was bringing back to PA to review, thinking that maybe doing so would satisfy some need. And it did, to some degree. But in thinking about what it was that I was missing, I started listing out a few major conceptual differences between Linux and Windows, and how these things can be stumbling blocks for anyone hoping to switch or at least add a Linux PC to their lives. Part of this thinking led to Switcher 2026: Minimizing the Microsoft in Windows 11 ⭐. Some of the underlying principles in there–using a local account and not an online account for sign-in, using a package manager to install apps, and so on–might be viewed as using Windows but with a Linux mentality.

At a high level, Windows and Linux are similar enough, and those similarities can help make any transition easier. Linux has a desktop with a taskbar-like dock and a quick settings interface, and those basic UIs will be familiar to Windows users, as will apps like Settings, Files, and Software (which is like an app store). But Linux was also made in the image of Unix, the OS platform that Windows, in the guise of NT over 30 years ago, was positioned against. And there are differences, many of which are conceptual or philosophical in nature. Understanding these differences is, I think, important. As is embracing the Linux way, so to speak, if you’re going to use that platform. I think of this as the Zen of Linux.

Here’s what I mean.

Software is installed with package managers

As I noted in Switcher 2026: Debian is Too Complex For Its Own Good ⭐, Windows users are trained to find the apps they need on the web; we Google it, we download an EXE, and we install it. And that’s the way it’s been for the past 25 years ago. It feels normal because it is normal. But here’s the thing. It wasn’t always that way, as we used to purchase software in retail stores on floppy or CD and install apps that way. And this isn’t necessarily the best way to install apps.

In Windows, we have some choices. Yes, there’s the web. But we can also use the Microsoft Store, which started off as the Windows Store, when it was originally a cesspool of low-quality apps, though it’s now quite good. Or we can use the Windows Package Manager (winget), which is built into Windows (or some other package manager) from the command line (CLI) to try and automate the installation of apps.

This progression from EXE installers to the Store and then to a package manager is classic Microsoft in that it’s so backwards it’s almost comical. That it feels normal to us says more about how tradition leads to expectations than it does about logic or doing things correctly. Package managers are common in Linux and in other Unix-like systems, like macOS. But they only arrived in Windows belatedly as an afterthought, especially in Microsoft’s case.

Years ago in the pre-cloud era, Microsoft rearchitected Exchange Server, I think for Exchange 2007. The goal was to reverse the normal process for creating software that ran on Windows (or, in this case, Windows Server). That is, instead of starting from a GUI and then making command line access available, this new Exchange would start with the command line, in this case PowerShell, and then the GUI would be built on top of that. The command line would offer a superset of the functionality in the GUI, instead of the reverse. Put another way, it would work like Unix/Linux, instead of the traditional Microsoft/Windows approach.

This seemed like an excellent idea to me at the time. And I made the point that all software should be like this. I expected this shift to occur across Windows and the Microsoft stack. But it never did: Today, even with all the advances recently in the Terminal app and with the introduction of the Windows Package Manager (winget) and other CLIs (like Store CLI), Windows is decidedly GUI-first. A tiger can’t change its stripes.

The problem with that approach is that tacked-on features like command lines and package managers are never full-featured. With the Microsoft Store, a GUI, you don’t just get app installs, you get automatic app management: The Store keeps those apps up-to-date for you, and you don’t have to do a thing (unless the app maker decided to bypass this crucial functionality, which is annoying). But with winget, you’re on your own. It’s good for installing apps and, as I do, bulk-installing multiple apps. You can use it to manually check for app updates and install those. But winget will not automatically keep your apps up-to-date. Only the Store can do that in Windows. (That there are GUI front-ends to winget for automating app management is, likewise, classic Windows.)

Linux is designed with package management as a core feature. This can be done via a command line, typically using apt (the Advanced Package Tool). Or it can be done through an app store-like experience like the Software app in Debian and Ubuntu-based distributions. In Linux, the package manager–or package managers, are there are several, and some distributions support multiple package managers–is how one finds, installs, manages software. Meaning, not just apps, but all software. Including drivers. In my experience, the GUIs for this are usually very good. But the command line is better, more full-featured. A superset.

This feels right to me. This feels so right to me that I do it on Windows, too, even though the experience is comparatively lackluster.

That is, instead of playing whack-a-mole with software downloads on the web, you can typically find everything you need with a package manager that’s GUI or CLI-based. (Debian being a strange exception because of its out-of-date sources.) Whichever approach you choose–I mix and match, and I suspect most Linux users do, too–the package manager will handle everything for you, from dependencies to updating. All you need to do as the user is learn about this new (to you) way of doing things. Meaning, you need to learn to stop going to the web every time you need an app or driver.

The command line is a good thing

When it comes to Linux, we’ve all heard the line that “this, finally, is the year of desktop Linux.” And we’ve all chuckled to ourselves, or more publicly on social media, when that never seems to materialize. Yes, hilarious. But as Linux has improved dramatically in recent years, a new mantra has arisen. And this time it’s not about Linux finally making sense on the desktop, though it does. It’s about how you may or may not finally be able to use Linux without touching the command line.

This is the holy grail for many, especially those who believe that severing the command line cord, as Windows users did with the NT-based platform that’s now the norm, is the right way forward. But you’re not thinking clearly. The command line isn’t a crutch or a fallback, and though you can use Linux, mostly, without touching the command line, you shouldn’t. Just as–wait for it–you shouldn’t use Windows without touching the command line. This is a good thing. The command line, in many cases, is better.

I mean that broadly. Yes, CLIs are largely non-discoverable in that you can’t just figure out which features are hidden in there, and typing random short terms to see if they’re commands is a non-starter. There is a bit of a bar to entry here. But that’s true of anything new. We’ve been suckling at the GUI teat for so long we’ve forgotten how to get things done efficiently. Sometimes the old way of doing things is just old. But sometimes it’s better.

PowerShell was an interesting reminder of this. So, too, was the Windows Package Manager (winget) and, more recently, the Store CLI in Windows. If you want to update virtually all out-of-date apps in Windows right now, the fastest way–i.e the “best” way–is to open a Terminal window with admin privileges and type the following:

winget install –all –silent

Or, you could open the Store app, navigate to Downloads, click “Check for updates” and then “Install all” repeatedly and just update some of the apps. Some of which will require you to manually update them. There are different ways to do things.

As any Linux user will tell you, one of the first things one does when getting started with a new install is to open a command line window and perform the above process, but using Linux tools. For example, you can check for updates (and update the local repository database) with the following:

sudo apt install

And then use the following to install all the updates:

sudo apt upgrade

You can do a lot more with apt, but those two back-to-back are probably the most common set of Linux commands that everyone uses.

It’s fast, semi-automatic, and, most importantly, it works. And, yes, the command line is more than just apt, there’s a whole world to explore there with multiple high-quality text editors and other utilities. But being comfortable with the basics is key to any Linux experience. And the command line is not something to fear or avoid, it’s something to embrace. (And on Windows, too, as noted.)

The file system is different

We’ve been dealing with drive letters in Windows since its inception, which makes sense because this file system scheme predates Windows and has its origins in MS-DOS, which was inspired by CP/M, which was itself inspired by the IBM systems that CP/M’s creator, Gary Kildall, was familiar with.

That’s a lot of ancient history, but Unix and now Linux have similar historical influences that persist to this day, too. The Unix file system (now used by Linux) dates back to the 1960s and was influenced by Multics and the time sharing computer systems its creators had at Bell Labs. As Brian Kernighan explains in the book Unix: A History and a Memoir, Unix was in many ways a file system implementation in the early days, a hierarchical system with a root (/), sub-directories, mountable and unmountable volumes, and an abstraction of connected physical devices. All done in an era in which physical storage was considered secondary storage (where RAM was primary storage). The Unix file system, notably, was simpler than that used by its predecessor, Multics.

Regardless of the history, the structure of the Unix–and now Linux–file system has endured. There are no drive letters, no C: prompt or designation representing the system drive as in Windows. (Back in the floppy drive days, the first disk was A:, and A: and B: are still reserved for floppies today even though no one has that kind of hardware.) Kernighan describes the Unix file system as simple, clean, and elegant. But it will be alien to anyone used to Windows and its unique way of laying out folders on the disk.

It’s not worth beating this to death per se, but in Unix/Linux, everything in the file system, including directories (folders), is a file. Each of these files has associated access permissions, size, create and modification times and dates, and other meta data, as do files in Windows. But the hierarchy of this file system is quite different. As is the way that Linux, today, interacts with storage devices, including removable disks like USB sticks and hard drives.

Knowing the basics will help.

A typical Windows system disk has Program Files (and now Program Files (x86)), Users, and Windows folders in the root of C:. And your user folder is typically found in C:\Users*username*, with subfolders like Desktop, Documents, Pictures, and others. In Linux, you will find folders like bin, etc, opt, run, var, boot, home, lib, mnt, and several others under root (/). Your user folder is in home (like /home/paul). And as with Windows, that folder contains subfolders like Desktop, Documents, Pictures, and others.

So that’s simple enough. But the way Linux handles removable storage is different enough to warrant a mention. When you insert a USB or other removable drive in a Windows PC, it appears as a drive with a unique drive letter (usually D:, E:, or whatever the next available letter is). To find this in a command line, you have to look in /media, typically (on Ubuntu, /run/media; the Disks utility will tell you where it is). But you can’t get to /media easily from GUI file managers like the Files app. So Linux mounts the drive there in an easily accessible way alongside other removable/network locations. You can use that UI to eject a removable disk (or disconnect from a network location).

Beyond understanding the basic layout differences between Windows and Linux file systems, the key concept on the Linux side is that its file-based approach bleeds into my previous point about the command line: The standard Linux set of commands, which, again, are based on what we see in Unix, are designed to work consistently across everything the file system contains, whether we think of those things as directories (folders), binary files, text files, or whatever else. Each has its own access permissions, each can be accessed by any number of commands, most of which are single purpose, and those commands can be chained in useful ways to perform much more complex tasks and automations.

Whether either of these schemes–Windows and Linux–are “better” is sort of beside the point, though both have their advantages and disadvantages. They’re just different, and there are some minor differences that some will find confusing. Linux file names are case sensitive, which is important to understand. And native Linux file systems support longer path lengths than Windows file systems, but you can access most/all Windows-based file systems normally in Linux.

Updates that require rebooting

This one remains an open question of sorts. Well, sort of.

As any Windows user can attest, the quantity of Windows updates has exploded over the past few (several?) years while the quality of those updates has declined. The net result is chaos and a need to reboot the PC more often than most would like. This is why Microsoft is updating Windows Update this year as part of its “pain points” initiative. The goal is to reduce interruptions and, more specifically, to get to the point where a typical PC will reboot because of system updates just one time each month.

So what’s the experience like with Linux?

The party line is that rebooting a Linux PC is a form of defeat and that the architecture of Linux means that distribution makers can update discrete parts of the system without requiring an offline install while rebooting. But this has not been my experience. When you bring up a new Linux install, the Software app and/or a dedicated software updates utility will invariably prompt you to install some updates, just as with Windows, and those updates will invariable require a reboot. And going forward, those who look for updates, to apps or the system, will invariably find some available, just as on Windows.

To me, this isn’t all that different, with one important caveat: Linux updates seem to be much more reliable than Windows updates. Combined with the more automatic nature of app updates, this creates a sense of calm and order, which does stand in direct opposition to the situation in Windows today. Granted, Microsoft is working on this.

From experience comes familiarity and then … something more

I’ve been testing Linux for decades, but when I started down the path of writing the articles in the Switcher 2026 series, I debated whether I wanted to make Linux work like Windows, as I have to do on the Mac, or whether I could just embrace the differences and think–and work–differently.

With a few months of active use and much experimentation behind me, however, I realize this wasn’t a concern. There are enough different Linux distributions that anyone can find a user experience that’s familiar and efficient enough to meet their needs. But learning the differences, some outlined here, is important too.

In other words, this isn’t an either/or thing. With any platform shift, there’s going to be something to learn and some familiar workflows that will need to change. And that’s as true of Linux as it is of ChromeOS, the Mac, or whatever else.

Best of all, as you learn new things, and new ways of doing things, you may find that those things impact your workflow on Windows or some other platform too. And that’s great, even if you never end up switching at all.