Where Linux Is the Wrong Tool

An argument that returns the same answer for every case is not an argument. This volume sets out the situations in which the preference described in the preceding volumes is wrong — not as a concession appended for balance, but because the boundaries are what make the rest of the case usable. Someone deciding what to run for a particular job needs the exceptions more than the rule.

5.1 Apple platform work: there is no choice

The hardest boundary is legal and technical at once. Applications for iOS, iPadOS, watchOS and visionOS must be built with Xcode, Xcode runs only on macOS, and the tools that archive, validate and upload a build to the App Store — xcodebuild, xcrun altool, Transporter — are macOS-only. Apple’s developer documentation states the build requirement directly, including which Xcode and SDK versions submissions must use.

The consequence extends past app development. A researcher working on iOS security, Apple silicon internals, or the macOS kernel needs Apple hardware running Apple’s operating system, and cross-platform tooling does not substitute. Cloud Mac rental exists as a workaround for build automation; it is a workaround for the same requirement, not an exception to it.

There is also a smaller point that Linux advocacy tends to skip: macOS is a certified UNIX. Apple registers macOS against the Open Group’s UNIX 03 product standard — the register lists macOS 26 Tahoe on both Apple silicon and Intel — while Linux has never been certified against it. A Mac provides a real Unix shell, the standard utilities, Homebrew, native SSH and a supported laptop with excellent battery life. For a large share of practitioners the Mac is not a compromise; it is a Unix workstation that also runs Microsoft Office.

5.2 Windows-native work: targets, tooling and evidence

Three distinct groups are better served by Windows, for three different reasons.

Anyone whose targets are Windows. Corporate endpoints, Active Directory, Group Policy, Exchange and the identity plumbing around them are Windows systems, and the offensive and defensive tooling built for them is largely Windows-native — PowerShell and .NET tooling, C# collectors, kernel-level telemetry. Much of it can be run from Linux with effort, and red teams do, but the practitioner who understands that estate has generally learned it by living in it.

Anyone doing Windows reverse engineering or debugging. WinDbg is the kernel debugger for Windows and has no equivalent elsewhere; x64dbg is Windows-only; the environment in which a Windows binary’s behaviour makes sense is Windows. Ghidra, IDA and Binary Ninja run everywhere, which covers static analysis — dynamic analysis of a Windows binary does not, in any meaningful sense, happen on Linux. And since the overwhelming majority of commodity malware targets Windows, the analyst’s detonation environment is Windows regardless of what the host runs.

Digital forensics examiners. The commercial suites whose output is expected to survive a courtroom — EnCase, FTK, Magnet AXIOM — are Windows applications, per their published system requirements. Excellent open alternatives exist (Autopsy, The Sleuth Kit, Volatility, plus the entire dd-and-hashing tradition), and they are used constantly. But an examiner whose work must match an opposing expert’s tooling, or satisfy an accreditation regime, does not get to choose on technical merit alone, and the examiner’s workstation ends up being Windows even when every image on it came from a Linux server.

5.3 Hardware, drivers and the cost of the desktop

The practical objections are the ones a practitioner meets on the first afternoon, and they remain real.

Graphics. NVIDIA hardware on Linux has meant a proprietary driver for most of its history, with the friction that implies for kernel updates, secure boot signing and suspend behaviour. The situation improves steadily; it is not yet the non-event it is on Windows.

Wireless and peripherals. The previous volumes’ claim that monitor mode is a kernel feature is true and is not the same as saying every card works. New laptop wireless chipsets, fingerprint readers, ambient light sensors, docking stations and certain webcams commonly lag, sometimes by a full hardware generation, and occasionally never arrive. Practitioners buy hardware known to be supported, which is a real constraint dressed up as a preference.

Firmware and vendor support. fwupd and the LVFS have improved firmware updates enormously, but coverage depends on the vendor choosing to participate.

The commercial application floor. Adobe’s suite, Microsoft Office proper, many CAD and EDA packages, some VPN and endpoint-security clients mandated by employers, and a long tail of industry-specific software do not run on Linux. Compatibility layers work sometimes; “sometimes” is not a plan when the software is a condition of employment.

None of this is an argument against Linux for the tasks in the earlier volumes. It is an argument against assuming the desktop is solved, and against being surprised when a colleague who does the same job chooses differently.

5.4 WSL2 and virtualisation: the pragmatic answer

The honest modern position is that the choice is less binary than it was, and Microsoft’s own documentation is the best guide to how much less.

WSL2 runs a real Linux kernel in a lightweight virtual machine. It runs the same distributions, the same package managers and the great majority of the same tooling, with access to Windows files and interoperability in both directions. For the shell, scripting and package-archive arguments of the third volume, it is close to a complete answer.

It is not a complete answer for the second volume’s arguments, and Microsoft says so. Its FAQ states that WSL2 does not include serial support or USB device support natively — USB requires the third-party usbipd-win project, itself a documented workaround with kernel-version requirements. Networking is virtualised, so a WSL2 distribution normally has a different address from the host. GPU access goes through a /dev/dxg device rather than a native driver. Microsoft’s own list of differences from bare-metal Linux is long enough that it advises treating WSL as an inner-loop development environment rather than a production one.

Reading that fairly: WSL2 removes the development reasons to dual-boot, and leaves the hardware-facing reasons intact. Wireless monitor mode, raw USB work, driver development, kernel instrumentation against real hardware — these still want Linux on the metal, or a VM with real device passthrough.

The arrangement most working practitioners end up with is not a victory for any platform: a primary machine chosen for the hardware and the commercial software, Linux native on a second machine or in a VM for the work that needs it, a Windows VM for detonating Windows samples, and a Mac when the work touches Apple. The tribal question — which operating system is best — turns out to be less useful than the professional one, which is which machine is appropriate to the task in front of them.

5.5 The summary that survives its own limits

Pulling the five volumes together into claims that hold with their qualifications attached:

• For kernel, container, network-stack and wireless work, Linux is not merely preferred but structurally required for parts of the job. This is the strongest form of the claim, and it is narrow.
• For server, cloud and embedded work, Linux wins on parity with the target — a large, dull, decisive advantage.
• For general tooling, scripting and reproducibility, Linux wins on degree rather than kind, and WSL2, Homebrew and PowerShell have all narrowed the margin.
• For Apple platform work, macOS is mandatory.
• For Windows internals, enterprise estates and courtroom forensics, Windows is correct, and choosing otherwise is stubbornness.
• For the desktop as a whole, Linux remains a small minority — around 4% by StatCounter’s mid-2026 worldwide figures, with that source’s own caveats — and the hardware and commercial-software gaps that keep it there are real.

The proposition this dive began with was that hackers prefer Linux. The defensible version is that practitioners whose work requires reaching below the interface prefer the system that lets them, that a large fraction of such work targets Linux anyway, and that the practitioners whose work points elsewhere use something else without much agonising about it.