The Right Shoes?

If Part 1 was about running a marathon in leather brogues, Part 2 is about their opposite. The right shoes are a pair of the latest running trainers, the ones with so much bounce they are almost illegal. They don’t just avoid pain; they give you an edge.

Most developers still sit on Windows or macOS. Both can be made to work. Neither matches Linux for speed and predictability. The closer your workstation is to production, the shorter the feedback loop.

Where the gaps show

The biggest differences surface in file I/O. Modern development involves sprawling dependency trees and thousands of small files. Builds and reloads hammer the filesystem.

On Linux, inotify handles file events. It is efficient, scalable, and designed for real-time monitoring. On macOS, FSEvents sits above APFS. It works, but with more latency and less consistency under load. On Windows, developers rely on the USN Journal, built for backup and recovery, not continuous reloads.

Security multiplies the cost. Every open, close, stat, or watch request triggers a filter driver. NTFS already serialises access with oplocks, and antivirus hooks add another detour. What should be a sub-millisecond syscall becomes a millisecond operation. That is why unpacking a tarball takes two minutes on NTFS, nine seconds on WSL2, and under six seconds on Linux.

Unpacking a tarball: two minutes on NTFS, nine seconds on WSL2, under six on Linux.

Developers sometimes try to work around it. On Windows, that can mean keeping projects inside the WSL2 filesystem rather than NTFS, excluding development directories from antivirus scans, disabling Windows Search indexing, or adjusting NTFS oplocks. On macOS, common tweaks include using case-sensitive APFS volumes for projects, disabling Spotlight indexing on build directories, or increasing file watcher limits with launchctl.

The problem is that in most enterprises these are exactly the changes corporate IT locks down. Antivirus rules are centrally enforced. Indexing policies are uniform. Filesystem settings are off-limits. The knobs exist, but no one can touch them. And even if they could, in an organisation of two thousand engineers most will not. They will work with the defaults. If the defaults are slow, every build and test is slow.

Linux avoids this. ext4, xfs, and btrfs handle scale without tweaks. The defaults work. Fluxbox was the same: a window manager so light it could run on hardware where antivirus had gone wild and still not drop a frame. Transparent terminals before they were a thing. No decoration, no hacks, just speed. Simplicity as strength, not compromise.

The shim is not invisible

On Linux, containers are just processes. cgroups limit resources. Namespaces isolate them. The same scheduler that runs your editor threads runs your containers.

On Windows and macOS, every container is a guest. Docker starts a Linux VM, mounts a filesystem, and places containers inside it. File operations cross from NTFS or APFS into ext4 through a translation layer. That shim intercepts syscalls and forwards them. Every open, close, and stat pays the toll.

The cost is measurable. Run a database in Docker on Windows and watch latency spike. Bind-mount a large dependency tree and performance collapses. What Linux treats as routine syscalls, Windows and macOS translate into interprocess RPC.

There are workarounds. On Windows and macOS, teams sometimes use Docker Desktop’s delegated mounts to reduce filesystem thrash, run everything inside the VM instead of bind-mounting to the host, allocate more CPU and memory to the Docker VM, or disable file sharing with antivirus and indexing services.

These measures help, but most are blocked by corporate IT policy. Antivirus exclusions are rarely granted. VM settings are centrally locked. Indexing rules are uniform. At enterprise scale the defaults are the only thing most developers ever see, and the defaults are slow.

This is also why developers on Linux often carry more credibility. The bar is higher. Running Linux means dealing with shells, filesystems, and processes directly. It requires a comfort with complexity that Windows hides. Developers who only know Windows may be capable, but they have not had to cross that threshold. Their feedback is shaped by shims. Linux developers see the thing itself.

It is the same parable you hear in systems programming: if you never touch assembler, you can write code, but you will never really understand memory management. Abstractions are useful, but they hide truths. And when the truths leak through, as they always do, only those who have seen under the hood can respond with clarity.

Local Kubernetes clusters highlight the divide. Developers often reach for tools like kind, k3d, or minikube to simulate production. On Linux these talk directly to the kernel. On Windows and macOS they route through a hypervisor. Overlay filesystems, volume mounts, and networking all pass through the shim. Docker makes it look portable. On non-Linux hosts it is an emulator, and the emulator shows.

The shim is not invisible. It consumes CPU. It adds latency. It introduces variance between dev and prod. Ignoring it is the costliest mistake an enterprise can make.

Virtual desktops are worse

Enterprises sometimes reach for virtual desktops. The logic is familiar: centralise, control, standardise. But VDI belongs in the noughties.

It is the worst of both worlds. Developers share backend infrastructure. Performance depends on network round-trips. Latency creeps into every keystroke. Builds contend for central resources. Instead of fixing the workstation, VDI pushes it further away.

Security teams turn to VDI to shrink surface area. That makes sense, but it also hard-codes the wrong behaviours: shared environments, slow feedback, normalised delay. If local loops are the cure, VDI prescribes more of the disease.

Better options exist. Isolated Linux workstations or personal Kubernetes namespaces provide the balance. Security and speed do not have to conflict.

The way forward

Corporate IT often hesitate at Linux desktops. Manageability has been the concern. That gap is closing. Modern MDM tools patch, encrypt, and monitor Linux. Endpoint protection, VPN clients, and zero-trust agents ship Linux builds.

Uniform fleets keep IT simple, but they are expensive for engineering. Treating every laptop the same costs tens of millions in lost productivity. Security teams deserve credit for what they defend against, but they need to account for the trade-offs they impose.

Developers need choice. Some will prefer macOS for its polish. Some need Windows for specific integrations. But when workloads involve heavy file churn or containerised services, Linux is the better fit. That is not preference. It is measurable.

Closer to production, closer to speed

The right shoes are the ones closest to production.

For teams whose production runs on Linux, Linux workstations close the loop. They cut the twentyfold slowdown. They remove the emulator. They make local clusters behave like production.

VDI belongs in the past. It fixes yesterday’s risks while locking in today’s bad habits. Developers need predictable, isolated environments, not streamed desktops that jitter on every keystroke. Security teams have reasons for reaching for VDI, but engineering pays the price.

And the wider context matters. The desktop is no longer the constraint. Slack, Teams, Zoom, even PowerPoint: everything is web-first. The argument that Linux is not ready no longer holds. The real question is whether enterprises are ready to treat developer workstations as production-grade equipment, not generic office laptops.

Fluxbox may be nostalgia, but its principle holds. Keep it simple. Keep it close to production. Every choice is a trade-off. The mistake is pretending you are not making one, or worse, making the wrong one in full view of the bill it generates.

And if you happen to read this, and happen to work for me or know me, ping me. Let’s get you over to Linux. This piece is provocative by design. Sometimes it takes an aggressive argument to shake loose old defaults.