I left the Linux desktop, not Linux

My Linux journey started in 2008 with Ubuntu 8.04 LTS, and it started because a Windows XP hard drive died.

I had a spare 40GB IDE drive and a friend with an Ubuntu CD. That was the first time I installed an operating system because I had to, not because I wanted a project. The project came later.

From there the path went Ubuntu, then Arch, then Void, a stint on a Hackintosh, then Fedora, then Debian 13. I built a Linux distribution once. I had opinions about package managers, a dotfiles repository, and a mental map of where every configuration file lived. I am not someone who installed Ubuntu, got bored and bought a Mac.

Today the MacBook and the Mac desktop are the daily drivers. The Framework Laptop 13 still runs Debian, and the home lab is still Linux. I left the Linux desktop, not Linux.

That sentence took a while to write, because for a long time the laptop being a project was part of the point.

The long way around

I liked the control. I liked knowing where the kernel came from, which package owned a file, and what would happen if I removed it. I liked being able to fix the machine instead of waiting for someone else to fix it.

That is not a phase you grow out of because you stop caring. It is a phase you leave because you start caring about something else more.

The distro-hopping was part of the education. Ubuntu taught me the basics. Arch taught me how the pieces fit together. Void taught me that a simple system is not the same thing as a small one. The Hackintosh taught me how much of an operating system is a set of assumptions about hardware. Fedora taught me what a fast-moving distribution feels like when it is run well. Debian taught me what patience looks like when it is run well.

Building Sailex taught me the rest. Once you have built your own distribution, you stop believing that the desktop is a mysterious thing that just works or does not. You know it is a pile of decisions. You know someone has to make them.

For years I was willing to be that someone for my own laptop. The question is when the decisions stopped being interesting and started being maintenance.

The Debian answer

The last serious attempt to make Linux the daily driver was not Fedora. It was Debian.

Fedora 44 was a good system. Fedora is explicitly a fast-moving distribution. It exists to show new upstream work quickly, on a six-month cadence, with each release supported for roughly thirteen months. That is a legitimate design goal. It also means the packages, the kernel and the toolchain are all moving at the same time, all the time, whether or not you wanted the new thing.

Debian takes the other approach. Freeze, test, harden, ship. A stable release gets about three years of full support plus LTS coverage after that, roughly five years in total. Point releases still carry security and bug fixes. The difference is that the ABI and API surface are designed to stay put for the life of the release. You are not relearning quirks every six to thirteen months.

I wanted that. When your day job is being paged at 2am for something that should not have changed, you develop a strong preference for systems that behave predictably. That preference does not stay at the office.

I moved the workstation and the Framework Laptop 13 from Fedora 44 to Debian 13 (Trixie). I started working through the rest of the home lab servers. The move was not impulsive, and it was not because Fedora had burned me. Fedora had not. I was evaluating what I actually wanted from an operating system over the life of the machine.

Debian fit better on almost every axis that mattered to me.

The package manager was part of it. I know apt well, and I knew dnf well enough. Debian's packaging philosophy lines up with how I want to run systems: strict dependency policy, a long-tested archive, and a clear separation between stable, testing and unstable. It is not just familiarity. It is a model of ownership I understand.

The governance model mattered too. Debian's Social Contract, the DFSG (Debian Free Software Guidelines) and its position as a community-governed, vendor-independent project matter to me. Fedora is a great project, but it is sponsored by Red Hat and IBM, and its roadmap reflects the interests that come with that. Debian's independence and its conservative defaults align more closely with how I want the systems I am responsible for to be governed.

The migration itself was real work. I inventoried packages and services before touching anything. I backed up /etc and the home directories. I did fresh installs with the non-free firmware component included, restored configs and mapped Fedora packages to Debian equivalents. I rebuilt the security model instead of porting it: Fedora defaults to SELinux, Debian defaults to AppArmor, and those are different enforcement models with different policy syntax.

The Framework needed more care than the workstation. Newer hardware means newer firmware, and not all of it is in the stable archive. I used the backports repository selectively, with pinning, for the kernel and a handful of packages. I used containers for tooling that needed to be newer than stable, and Flatpak for a few desktop applications that move faster than Debian's release cycle. I rebuilt my dotfiles around the "Don't Break Debian" philosophy: stay inside the package manager where possible, avoid third-party repositories, do not overwrite system-managed files, and use /usr/local or well-scoped systemd units for anything custom.

I kept a rollback image of the old system until the new one had proved itself. That is the unglamorous part of a migration. The cutover gets the attention. The rollback plan is what lets you sleep.

It worked. Debian was more stable, more predictable and easier to reason about than Fedora. The Framework ran. The workstation ran. The servers are still running Debian.

That is the part of the move that stuck. The MacBook eventually took over the Framework's daily-driver role, and the Mac desktop took over the workstation's. The Debian servers stayed where they were.

The tax that stayed

What did not change was the role I was playing.

Debian made the integration layer more stable. It did not make the integration layer disappear. I still owned the sleep behavior, the external display, the dock, the Bluetooth stack, the firmware, the battery and the long tail of applications that assumed a different operating system. The failures were quieter. They were still mine.

The problem was not Fedora. The problem was not Debian. The problem was that a daily driver had become a system I maintained rather than a tool I used.

I do that kind of work for a living. I tell clients to stop maintaining things that are not their differentiator. I tell them to make the boring parts boring and spend their attention on the work that matters. I was not taking my own advice.

A daily driver is not supposed to be a second job.

The work case

Some of the switch was practical. A managed device, the security posture that came with it, and a set of applications that were simply easier on macOS. My day job runs through Azure, Microsoft 365, a browser, a terminal and a VPN. Most of that is cross-platform. The last mile was not.

The last mile is always the part that decides. A client portal that behaves better in Safari. A video call that does not fight the audio stack. A security agent that the employer supports on one platform. A document that opens without a compatibility warning. None of these are technical mountains. Together they are a strong argument for using the machine that other people are already testing.

I run Arcline. The laptop has to be a professional tool before it is a statement.

The compliance angle is less exciting and more important. A managed Mac is not fully mine. That is the deal. Someone else can enforce disk encryption, screen lock, patching and endpoint software. I can still do my work, but I do not own the final say over the device. For a consultant working with regulated clients, that is not a drawback. It is the point. The device has to be defensible, not just convenient.

Some of it was curiosity. I had spent years being the person who fixed the laptop. I wanted to know what it felt like to use one that mostly fixed itself.

The first week

The first week was suspicious.

The lid opened and the machine was where I left it. The battery estimate was not a negotiation. The external display came back at the resolution I set. The trackpad worked. The keyboard worked. The headphones paired. Nothing asked me to read a forum thread.

I kept waiting for the catch. It is not that macOS has no problems. It is that the problems were not mine to solve. When something went wrong, the answer was usually "update" or "wait for the vendor," not "dig through a log at 11pm." That is a different relationship with the machine.

The hardware helped. A laptop that sleeps properly and runs on battery for a real day changes how you use it. The desktop does not have a battery, but it has the same quality of not asking for attention. The display, the peripherals, the wake-from-sleep behavior, the noise: it all disappeared into the background.

That is the most positive thing I can say about an operating system. It disappeared.

The ecosystem

The ecosystem is the part I expected to ignore. I did not move because I wanted my phone and my laptop to share a clipboard. But they do, and I use it. A link, a code, a photo, a document: the small handoffs add up.

That is convenience, not freedom. It is also a hook. The more devices and services I use, the more the lock-in is real. I notice that. I still use the convenience. The honest version is that the ecosystem is good at removing friction and bad at giving you an exit.

What I gave up

I did not get this for free, and I am not going to pretend the trade is obvious for everyone.

Package management and customization

Homebrew is excellent. It is also not the same thing as owning the base system. On Debian I could see the whole dependency graph and decide what the machine was made of. On macOS I have a userland package manager sitting on top of a sealed system, plus a set of defaults I can change but do not really own.

I miss knowing where everything came from. I miss the feeling that the machine was assembled rather than supplied. I miss being able to remove something and know that it was actually gone.

The trade is real: I spend less time managing packages and more time accepting that some parts of the system are not mine to manage.

Containers and virtual machines

Docker on macOS is a Linux virtual machine with a friendly CLI. Colima makes that VM pleasant. It is still a VM. The kernel is not the host kernel, the filesystem is not the host filesystem, and the performance is not the same.

For most of what I do, that is fine. A Rails app, a Postgres container, a test suite, a few CLI tools: the VM is good enough. For the work where it is not, I have Linux servers. The homelab is not a metaphor. It is where the real kernels live.

The Framework is still here, still running Debian, still useful when I need a Linux machine with a screen and a keyboard. It is just not the machine I open every morning.

Privacy and telemetry

Apple is not a privacy charity. The operating system talks to Apple services, the App Store is the only practical way to install some software, and a lot of the integration that makes the ecosystem pleasant depends on data leaving the machine.

I can turn some of it off. I cannot audit all of it. On Debian I had a better story about what the machine was doing, even if the story was sometimes "a package I have not looked at in two years."

The trade is not that Apple is trustworthy. The trade is that I have less time and more trust in a vendor whose incentives I can at least name. That is a smaller claim than "private," and it is the honest one.

Repairability and upgrades

The modern Mac is a sealed object. The memory is soldered, the storage is not a user part, and the battery replacement is a project. The desktop is the same story in a larger case.

I do not like this. I liked being able to add memory, replace a disk or swap a battery. I liked knowing that a repair was a decision rather than a visit to a store.

I made sure the machines had enough memory and storage to last, because I cannot upgrade them later. That is a worse way to buy a computer. It is the price of the rest of the trade.

What I got

The list is short and unglamorous.

I got time back. Not a dramatic amount in any one week, but a steady return on all the small integrations I stopped doing. I got a laptop that sleeps, a display that wakes, a battery that lasts and a desktop that stays quiet. I got the software my work already assumes. I got a security posture that someone else maintains.

I also got a useful piece of humility. I had confused "I can fix this" with "this is a good use of my time." Those are different statements. The first is a skill. The second is a judgment. SRE work is mostly judgment.

The Mac is not a better computer in some absolute sense. It is a better computer for the life I have now. That is a much smaller and more useful claim.

The philosophy

I still believe in owning your tools. I still believe that understanding the stack matters. I still think the Linux desktop is one of the best ways to learn how a computer actually works, and I would recommend it to anyone who wants that education.

The distro-hopping is also what pulled me into cloud, DevOps and SRE work. The same instinct that wants a frozen dependency tree on a server is the one that eventually wanted a laptop that did not move under me.

Debian is still the distribution I trust for servers. Its Social Contract, its DFSG and its independence are not marketing to me. They are the reason I can explain who controls the systems I run. Moving the laptop to macOS did not change that. It made the split clearer: the servers are governed like infrastructure, and the laptop is a tool I buy from a vendor.

There is a difference between learning from a system and maintaining it forever. At some point the lesson is learned. The question becomes what you want to spend your attention on.

I want to spend mine on reliability, on clients, on the homelab, on writing and on the parts of the work that do not come back after a reboot. The laptop is a terminal into that work. It is not the work.

This is the same argument I make to clients about their platforms. Keep the differentiator. Buy, rent or automate the rest. Do not make a hobby out of something that is supposed to be infrastructure. I finally applied it to the machine on my desk.

Who should not switch

If you enjoy the desktop as a hobby, do not switch. The tinkering is the point for you, and macOS will feel like a rented apartment.

If you need to repair and upgrade your hardware, do not switch. If you need native Linux containers and VMs, do not switch. If your privacy model requires an operating system you can audit, do not switch. If your software is Linux-only, do not switch. If you are happy and the taxes are low, do not switch.

If you are tired of being the integration layer, if your work assumes macOS, if you want the hardware to disappear, it is worth a serious look. Not because the Mac is morally superior. Because the trade might fit.

What I still run

Linux is not gone. It is on the homelab. It is in the k3s nodes, the Proxmox host, the containers, the servers that hold the things I care about. The home lab servers are still Debian. The Framework still runs Debian. When I need a kernel, a network stack, a filesystem or a service that stays up, Linux is still the answer.

The Mac is the window into that world, not a replacement for it. The laptop stopped being a project. The homelab is still a project, and I like it that way.

That is the distinction I did not understand before I switched. "Daily driver" is not a statement about what you know or what you value. It is a statement about which machine you want to maintain. I still know Linux. I still choose it where it counts. I just do not choose it for the machine that has to open on a plane, connect to a client's VPN and last a full day without a charger.

Nearly two decades after that Windows XP drive died, I ended up close to where I started: Debian on the servers, a Mac on the desk. The Linux desktop was not a failure. It was the long way around to understanding what I actually wanted.

I left the Linux desktop, not Linux.

The laptop stopped being a project. That was the point.