The Culture Argument, and the Claim That Fails

The cultural case for Linux is the part of this argument most likely to slide into flattery, so it is worth reducing to its testable components. Three claims are commonly made: that open development produces better software for this kind of work, that customisability is a professional advantage rather than a hobby, and that the learning curve is a feature. All three contain something real. One of them, in its popular form, is demonstrably false, and this volume ends with it.

4.1 Open source as a working method

The useful version of the open-source argument has nothing to do with price or ideology. It is that the source being available changes what a practitioner can do when something behaves unexpectedly.

The sequence is the same every time. A tool misbehaves. On a closed system, the available moves are to search for others reporting the same thing, to experiment with inputs, to file a report, and to wait. On Linux the same practitioner reads the code, finds the branch responsible, and knows — rather than suspects — what happened. If the answer matters enough, the fix is applied locally and the system is rebuilt.

This matters disproportionately in security work, where the interesting cases are by definition the ones outside documented behaviour. A vulnerability is a difference between what documentation claims and what code does, and only one of the two is available on a closed system.

It also underpins something the previous volumes relied on: every factual claim about the kernel, the wireless stack or the capture path in this dive can be checked by reading the relevant source. The corresponding claims about the closed stacks had to be taken from vendor documentation, which is exactly the weaker form of evidence.

Two honest qualifications. Reading kernel source is a skill with a steep cost, and the number of practitioners who actually exercise this option on any given problem is small. And “open” covers an enormous range of maintenance quality — from the kernel, which has an industrial review process, down to a decade-old tool with one unpaid maintainer, which is precisely the failure mode this volume ends on.

4.2 Customisability, stated carefully

The weak version of this claim is about window managers and colour schemes, and it is not worth defending. The strong version is about the system, not the desktop.

The professionally relevant form is that the behaviour of the machine is configurable at every layer: which services run, what the kernel is compiled with, how the network stack behaves, what happens when a device is plugged in, what the shell does with a keystroke. A workstation can be shaped tightly around a repeated task, and a practitioner who does the same thing a hundred times a week will shape it.

The equally real cost is that a highly customised machine is a machine only its owner can use, whose configuration lives in the owner’s head, and which will break in ways no search result describes. Teams that share systems tend to discover that standardisation beats customisation, and the same practitioner who tunes a personal laptop obsessively will often insist on a stock image for anything shared.

4.3 The learning curve as a feature

The claim is that Linux’s difficulty is a filter: it demands an understanding of filesystems, permissions, processes and networking, and the person who acquires that understanding is more capable afterwards.

There is something to it. A system that does not hide its mechanisms teaches them, and the knowledge transfers — to servers, to embedded devices, to containers, to the majority of the systems the population described in the first volume actually work on.

The claim is also used to excuse bad interfaces, and that use should be rejected outright. An error message that names no cause teaches nothing. A tool whose documentation is a mailing-list thread from 2009 teaches nothing. Difficulty that arises from the problem is educational; difficulty that arises from neglect is just neglect, and “the learning curve is a feature” is regularly deployed to defend the second kind.

The community norms have the same double edge. A culture that expects people to read documentation, reproduce a problem and report it precisely produces practitioners who can do those things — and the same culture is the source of the hostility to newcomers that it is regularly and fairly accused of.

Even the distributions say so. Kali’s documentation states plainly that it is not recommended for anyone unfamiliar with Linux or looking for a general-purpose desktop, and steers newcomers elsewhere. The tool most associated with the “hacker Linux” image explicitly declines to be an entry point.

4.4 The claim that fails

Which leaves the most repeated cultural claim of all: that open source is more secure because, in Eric Raymond’s formulation, given enough eyeballs all bugs are shallow.

As a statement about what open source permits, it holds: anyone may audit the code. As a statement about what actually happens, the record is against it, and three well-documented cases make the point without needing a fourth.

Heartbleed (2014) was a missing bounds check in OpenSSL’s TLS heartbeat handling that let a remote attacker read server memory — private keys included. OpenSSL was among the most widely deployed pieces of code in existence, and the flaw sat in shipped releases for roughly two years before anyone noticed.

Shellshock (2014) was a flaw in how Bash parsed function definitions out of environment variables, remotely exploitable through CGI and other paths that passed attacker data into the environment. Bash is one of the most read, most packaged, most studied programs on any Unix system, and the bug had been present for around a quarter of a century.

The xz-utils backdoor (CVE-2024-3094, March 2024) is the most instructive of the three, because it was not an accident. A contributor operating under the name “Jia Tan” spent years building maintainer trust on a compression library bundled into essentially every Linux distribution, then shipped a backdoor in the 5.6.0 and 5.6.1 releases that subverted authentication in OpenSSH on distributions that linked the two. It carried the maximum CVSS score. It was caught by Andres Freund — a Microsoft engineer and PostgreSQL developer — who was investigating why SSH logins had become about half a second slower than he expected, and who reported it to the Openwall security list, publishing his technical findings on 29 March 2024. Distributions reverted within hours and the attack was stopped before it reached most stable releases.

The correct conclusions are narrower than either camp usually draws.

Openness did not prevent any of the three. In the xz case, the attack was enabled by the social structure of open maintenance: an under-resourced maintainer under pressure, and a helpful volunteer. The “many eyes” claim, as popularly stated, is not supported.

But openness is what made all three findable and fixable by people who did not own the code. Freund could read the build scripts, diff the release tarball against the repository, and prove what he suspected. A performance anomaly of half a second in a closed product would have been, at most, a support ticket. And the fix reached the world within days without waiting on a vendor’s release schedule.

The defensible claim is therefore not “open source is more secure”. It is that open source is more auditable, and auditability is worth having precisely because nobody audits by default. That is a weaker statement, and it has the advantage of surviving contact with the evidence.