The short version
- Technical staff are moving to Linux mostly because Windows 11 stranded working hardware and because they want control over when a machine updates.
- It genuinely fits developer workstations, single-purpose machines and hardware that failed the Windows 11 check.
- It does not fit anyone who lives in desktop Excel or Adobe Creative Cloud.
- The real risk is not Linux. It is an unmanaged machine appearing on your network because nobody was asked.
Somewhere in most companies there is one person whose laptop does not look like everyone else’s. They are usually in engineering or IT, they are usually the person colleagues go to when something breaks, and at some point in the last couple of years they quietly stopped running Windows.
What is actually driving it
The trigger is usually hardware. Windows 11’s requirements, particularly TPM 2.0 and the supported processor list, stranded a large amount of equipment that still works perfectly well. A four-year-old workstation that fails the compatibility check is not a slow machine. It is a machine Microsoft decided not to support, and the people most likely to notice that distinction are the ones who understand what the check is testing.
The second driver is control. A workstation that restarts itself for a feature update in the middle of a long-running job costs real time, and the people running those jobs have been complaining about it for years. Linux updates when its owner says so. For anyone whose work is measured in hours rather than minutes, builds, renders, data processing, that difference is practical rather than ideological.
Then there is everything Microsoft added to the consumer experience and never removed from the professional one. Suggested content in the Start menu, bundled apps that reinstall themselves after updates, prompts to finish setting up an account, advertising surfaces inside the operating system itself. None of it is dangerous. All of it reads as noise to someone sitting in front of that screen for nine hours a day.
The people switching are rarely making a statement about Microsoft. They are optimizing a tool they use for forty hours a week.
Microsoft accelerated this by accident. Windows Subsystem for Linux was built to keep developers on Windows, and for plenty of them it worked exactly as intended. For others it served as an introduction. A year of running Linux tooling inside Windows makes running it directly feel like a much smaller step than it once did.
Where it genuinely fits
Four situations where this is a sensible business decision rather than a personal preference:
- Developer and engineering workstations. Native toolchains, containers and package management with no translation layer in between.
- Hardware that failed the Windows 11 check. A machine facing replacement or an escalating per-device support fee can often serve several more years in a specific role.
- Single-purpose machines. Kiosks, digital signage, shop-floor terminals and test rigs, where a locked-down system that does one job is the whole requirement.
- Servers and infrastructure. Already true in most environments, including plenty that would describe themselves as a Microsoft shop.
Where it does not
The limits matter more than the advantages, because they are what turn an enthusiastic switch into a support ticket. The desktop versions of Word, Excel, Outlook and Teams do not run natively on Linux. Browser versions cover ordinary use, but anyone working in Excel with macros, add-ins or large models will find the web version inadequate inside a day. Adobe’s Creative Cloud applications have no supported Linux version at all.
Management is the bigger gap. Your existing tooling probably does not cover it. If your endpoints run through Intune, your antivirus is a Windows agent and your patching sits inside a Windows-shaped RMM platform, a Linux machine falls outside all three. That is what turns one employee’s preference into an unmonitored device holding company credentials.
The risk is not the operating system
The risk is not that a capable employee runs a capable operating system. It is that they do it without anyone deciding, which is how a business ends up with an endpoint that receives no managed patches, reports to no console, carries no detection agent and appears in no compliance report. Shadow IT has always worked this way. It arrives as a workaround by a competent person solving a real problem, and it stays invisible until something breaks or an auditor asks a direct question.
What to do about it
If someone has asked, the answer does not have to be no. It has to be managed. Decide which roles it is available to, standardize on one distribution with a long-term support release so you are maintaining one thing instead of five, and confirm before anyone switches that your endpoint protection, backup and patching tools actually have Linux coverage. Most serious platforms do. Check rather than assume.
It is also worth asking why the request came up at all. Someone requesting a different operating system is usually telling you something specific about the machine they were issued, the update policy they work under, or the job they are trying to get done. The operating system is the visible part of that conversation. It is rarely the whole of it.
Know what is actually on your network?
Unmanaged devices are the ones that cause problems, whatever they are running. PTSI can audit your endpoints, tell you what is outside your management tools, and bring it back under control.
