Linux on the Machine You Have

On 14 October 2025, three weeks from today, Microsoft stops shipping security updates for Windows 10. The machines will keep working. They will simply stop being patched, which for anything that touches a network is a slow-motion version of not working, and the only route back onto a supported operating system runs through a hardware check that a large number of otherwise healthy computers cannot pass.

The check is worth reading precisely, because the argument depends on how mundane it is. Windows 11 requires a Trusted Platform Module at version 2.0, firmware that is UEFI and Secure Boot capable, 4 GB of memory, 64 GB of storage, and a processor on Microsoft's published list of approved parts. The memory and storage figures are trivial. The list and the TPM version are not, and they are what actually disqualify a working machine.

There is a reprieve and it is a short one. Consumer Extended Security Updates run through 13 October 2026, one year, and Microsoft offers three ways in: sync your settings with Windows Backup at no charge, redeem 1,000 Microsoft Rewards points, or pay $30. It covers critical and important security updates and nothing else, no technical support beyond help activating it, and enrolling late does not extend the window. It is a year, structured so that taking it feels like a decision you already made.

Set that against the other option. A machine that fails Microsoft's processor list will install a current Linux desktop and run it well, because the thing that disqualified it was a policy about attestation hardware rather than a shortage of compute. So for the first time in the history of this argument, the free operating system is also the one that does not require you to buy anything, and it is arriving in the same month that a very large number of people have to decide something.

That is the whole shift, and I want to be careful about what I am claiming with it. I am not claiming Linux got good enough because Windows got inconvenient; that would be a terrible reason to move a fleet. I am claiming the two things happened independently and met, and that the case which used to require ideology now only requires arithmetic. The rest of this is what the arithmetic actually contains, including the parts that still cost you.

GNOME is opinionated and it is right about most of it. The design has a point of view: one way to do a thing, few knobs, an overview treating workspaces as the primary idea rather than a power-user feature. Live in it a week and the coherence stops feeling like restriction. The cost is that where its opinion differs from yours the answer is an extension, extensions break across releases, and your daily environment now rests on something nobody promised to keep working. GNOME 49 landed six days ago, so nobody is running it yet.

Plasma is configurable and it is right about that too. Plasma 6.4, from June, will let you tile per virtual desktop, rework the panel into something that resembles whatever you left behind, and adjust nearly everything else. That is a real answer for people migrating with habits. The cost is the mirror image of GNOME's: a settings surface large enough that two engineers on the same team end up on materially different systems, and troubleshooting starts with finding out what somebody changed.

Installation stopped being a story. This is the least glamorous improvement and probably the most important. Fedora 42 shipped in April with a rewritten installer built on the premise that you get the system on the disk first and configure later, and it also promoted its Plasma variant to a full Edition alongside the GNOME one. Nothing about that is exciting. That is the point: the install is now forty minutes of clicking Next, which is the bar every other desktop operating system cleared years ago.

The sore points are real and they are all display and power. Fractional scaling works natively and still degrades for older applications running through the X11 compatibility layer, which is most of the ones your users care about. High dynamic range exists on both desktops and the application support behind it is thin. Suspend behavior on laptops depends on what the vendor's firmware implements rather than on anything the desktop controls, which is why a machine sometimes goes into a bag charged and comes out warm and empty. None of these are hard to trip over.

The traditional Linux update is a package manager reconciling a few thousand files in place, and the traditional Linux disaster is that reconciliation going wrong somewhere in the middle. Every wiki page telling you how to recover from that is evidence of the underlying design. The answer that actually solved it is to stop updating files and start replacing images: the system boots from a composed, read-only tree, an update fetches the next tree, and the switch happens at a reboot.

Fedora ships this as its Atomic Desktops, Silverblue with GNOME and Kinoite with Plasma, and both were included in the April release. The property that matters is not immutability for its own sake. It is that the previous image is still on the disk, so the recovery procedure for a bad update is to pick the older entry at the boot menu. That is a better answer to "will this break my machine" than any amount of documentation, because it does not require the user to have read the documentation.

The proof that this is livable rather than merely elegant is a games console. The Steam Deck shipped on 25 February 2022 running an Arch-derived system with a read-only root and paired system partitions that update by swapping, and it went to an audience with no interest whatsoever in how any of that worked. Millions of people have now run an image-based Linux system for years without ever learning that is what they were doing, which is the only test of an operating system that means anything.

I would not oversell it. The model trades one class of problem for another: installing something outside the image means containers or a per-user package layer, drivers that want to build against a running kernel are awkward, and anyone whose muscle memory is a package manager will spend a fortnight irritated. It removes the failure that used to end the conversation, and it introduces a smaller set of frictions that mostly annoy the people who were never at risk from the old one.

A compatibility layer redefined what supported means. Proton arrived in August 2018 as a packaged combination of Wine with graphics translation layers, and it turned "does this game run on Linux" from a question about the publisher into a question about the library. No developer had to agree to anything. The interesting part is that almost none of the work stayed in games: the same translation layers, the same graphics drivers and the same window-system fixes are what everything else on the desktop now runs on.

Shipping it on hardware forced the last mile. A compatibility layer that mostly works is a hobby. A compatibility layer sold inside a physical product with a returns policy is a commitment, and the difference showed up in the parts nobody volunteers for: controller input, sleep and resume, audio device switching, shader caching, the specific badly behaved installer that four thousand people hit on the same afternoon. The desktop got that work for free because it was the same code underneath.

The remaining exclusion is not technical and will not be solved. Competitive titles that ship anti-cheat running in the kernel are the hard boundary, and they stay excluded because their entire security model rests on an operating system the publisher can attest. This is not a bug anyone is going to fix. If the deciding application is one of those, the answer is no, and it is worth saying plainly rather than promising that next year is different.

Hardware support is good until it is a specific machine. Fingerprint readers, some wireless chipsets, ambient light sensors and the vendor firmware update path are all per-model questions, and the honest answer is that you have to check yours rather than trust a general claim. The situation improved enormously once vendors started publishing firmware through a common Linux service, and that coverage is still vendor by vendor, so "supported" resolves to a list you have to look at.

Then there is the peripheral with a Windows-only utility, which is the failure people underestimate because it sounds trivial. A mouse whose profiles are set by an application, a headset whose firmware updates through one, a monitor with a calibration tool: community replacements exist for a good fraction of these and they are workarounds you now own. One is a shrug. Six, across a team, is somebody's afternoon every week and it never appears in any comparison.

The applications that genuinely are not there are worth naming so nobody discovers them later. Adobe's creative suite has no Linux build and no plausible route to one. Video conferencing works, and works through the browser rather than through the client the rest of your organization is running, which mostly does not matter and does matter the week something breaks and the support answer assumes the desktop app. Neither of these is fatal. Both of them are the sort of thing a migration plan should say out loud in advance.

And "free" is a statement about licensing and nothing else. Somebody still enrolls the device, proves it is encrypted, pushes the patch, and wipes it when it goes missing in an airport. On Windows that machinery is bought, and its cost is a line item somebody already approved. On Linux it is assembled, and its cost is a person, which is the more expensive of the two and the one that does not show up in the comparison spreadsheet because nobody put a row in for it.

Decide the management plane before the distribution. Enrollment, patch delivery, configuration, remote wipe, and evidence that each of those happened: pick the tooling for that first and let it constrain the choice of system, rather than the other way round. Teams do this backwards constantly, choose on the desktop experience, and then discover in month four that the thing that reports encryption status supports two distributions and neither is the one now on forty desks.

Your auditor wants artifacts, not architecture. A control is satisfied by evidence, so the question is never whether the machine is secure but whether you can produce a per-device record showing disk encryption on, endpoint agent reporting, patch level current, and screen lock enforced. Those agents exist for Linux and are frequently a tier behind their Windows equivalents in coverage and in support responsiveness. Find that out during the evaluation, from your actual vendors, in writing.

The thing nobody can give up is never an application. It is a workflow with a Windows-only step buried in it: a signing tool, a VPN client with a proprietary posture check, a hardware token whose middleware is a driver, an internal system that only authenticates from a managed browser profile. Ask every team what they would be unable to do on the first morning, take the answers seriously, and accept that one of them may end the discussion for a subset of people. Partial adoption is a real outcome, not a failure.

I should narrow the claim before it reads as advocacy. Nothing here says move a fleet, and the extended-updates year exists precisely so nobody has to decide in October. My claim is smaller and harder to argue with: the option is now defensible in a room full of people paid to say no to it, five years ago it was not, and the reason has almost nothing to do with the kernel and almost everything to do with installers, atomic updates and a translation layer funded by video games.

The date on the calendar is telling you something else too, which is what kind of thing you own. A machine whose supported life ends because a vendor drew a line under a firmware version was never quite yours; it was licensed until the licensing changed. That is normal and most people should keep taking it. It is worth noticing that there is now a version of the same computer whose end date is when the hardware stops working, and for many desks that is the longer number.