The Billy bookcase does not care what you put in it. Paperback, hardback, A4 binder, potted plant — the shelf holds it. The shelf is indifferent. The content travels freely because the carrier has no opinions.

The Linux desktop cares enormously about your books.

Put a Qt application on a GTK desktop and it brings its own fonts. Put a KDE application on GNOME and the theming is wrong. The scrollbars are different widths. The file picker is a completely different application depending on which toolkit the developer chose. The Billy with strong opinions, loudly expressed, technically justified, and consistently surprising.

The Linux kernel is the real Billy — indifferent, standardised, holds everything. The Linux desktop is the shelf that keeps moving.

Debian: The Stable Foundation

Debian is slow. Deliberately. Packages sit in testing for months before reaching stable. Versions are behind what other distributions ship. The Debian stable release feels slightly old on the day it arrives.

It is also the most predictable Linux distribution in existence. The waterline is where it was last time you looked. The package is where it was. The configuration file is where it was. The seam between “system” and “application” is stable enough to build on without checking whether it moved.

This predictability is not an accident. It is the result of a governance model that prioritises stability over novelty — a slow layer doing what slow layers should do, stabilising and remembering while the fast layers above it innovate.

The Raspberry Pi proof:

The Raspberry Pi runs Raspberry Pi OS, which is Debian underneath. The Raspberry Pi Foundation chose Debian not because it was the most exciting distribution but because it was the most stable foundation. The command line works the same way it worked five years ago. The package manager installs the package where it was last time. The configuration files are where the documentation said they would be.

The result: millions of people learning Linux on a $35 computer, building projects, writing tutorials, teaching classes — all on a foundation stable enough that a tutorial written in 2018 still works in 2026. The Billy held every book they put in it. The shelf never moved.

Ubuntu: The Billy That Got Opinions

Ubuntu took Debian’s stable foundation and added a layer of decisions on top. Good decisions, mostly. Better default applications. A more polished installer. Hardware support that worked out of the box. Real improvements in every version.

And then the opinions arrived.

Unity replaced GNOME as the default desktop — a bold decision, technically interesting, deeply unpopular with users who had built muscle memory for GNOME. Years later: abandoned, GNOME restored, the users who had adapted to Unity now adapting back. The shelf moved twice.

The Amazon search results in the desktop search bar — Ubuntu monetising the user’s search queries by surfacing Amazon products in the application launcher. The enshittification moment. The trust cost was permanent. The feature was eventually removed. The memory remained.

Snaps forced as the default package format over apt — technically motivated (better sandboxing, easier updates) but imposed without adequate transition, breaking user expectations about where applications live, how they start, and how fast they launch. The shelf moved again. The books were in different places.

Each decision was individually defensible. Collectively: you cannot predict where the waterline is because Ubuntu keeps moving it. Not maliciously. With genuine conviction that the new position is better. The monks copying what they believe should be copied, certain they are right.

Rafting versus a boat trip:

Debian is a boat trip. The channel is marked. The waterline is predictable. You can read while travelling because you are not fighting the current.

Ubuntu is rafting. The river — Ubuntu’s release cycle, its changing preferences, its willingness to move seams between versions — decides the route. Occasionally exciting. Exhausting for daily use. You are always slightly wet. You never know exactly where the rocks are until you hit them.

Both use the same water. The kernel underneath is identical. The difference is who decides where the waterline is and whether they ask the passengers first.

The Tribal Infighting at the Seams

The Linux ecosystem has been fighting about where the seams should be for thirty years. The fights are real and the outcomes matter technically. They are also being had in the wrong room by the wrong people for the wrong audience.

The GTK/Qt split: two competing widget toolkit standards, each with their own theming engine, their own font rendering, their own file picker. An application built for one looks subtly wrong on a desktop built for the other. The user who notices that their Qt application has different scrollbars from their GTK applications is experiencing the tribal infighting as visual friction. Nobody asked them which tribe they preferred.

The init system wars: systemd versus OpenRC versus runit. Technical arguments, genuine differences, real performance implications. The user who just wants their laptop to boot does not know what an init system is. They know that the boot sequence changed between distributions and now something behaves differently. The seam moved. Nobody told them.

The packaging format proliferation: apt, rpm, Flatpak, Snap, AppImage. Five packaging formats, each solving the dependency problem differently, each creating new problems. The user who installs an application from Snap discovers it launches slowly because it is sandboxed differently from the apt package they expected. The shelf has opinions about how books should be wrapped.

Each tribe is the monks defending their scriptorium. Not wrong about the text they copy. Wrong about insisting everyone else must copy it the same way, and wrong about designing the shelf around their copying preferences rather than around the books the users actually have.

Android and Chrome OS: Take What Works, Leave the Rest

Google looked at Linux and made a simple decision: take the kernel, leave the tribal infighting.

Android: Linux kernel underneath, two billion devices, every manufacturer, every form factor, every price point from $30 to $1,200. The foundation holds everything. The kernel does not care if it is running on a Samsung flagship or a cheap Android Go device for a developing market. The Billy holds every book.

Google drew the seams once, clearly, and has moved them slowly with extensive deprecation warnings. The NDK/SDK boundary. The system/application boundary. The permission model. Each seam has been controversial. Each seam has been stable long enough that developers could build on it. The boat trip. Occasionally a wave. Never full rafting.

Chrome OS: Linux kernel underneath, boots in seconds, runs in schools and offices worldwide, requires almost no maintenance. The seams are defined by Google: browser is the application layer, Linux is the substrate, Chrome OS is the interface. The waterline is predictable. The users never need to know the kernel exists.

Both work precisely because they took the foundation and left behind the parts that were fighting about where the seams should be. The GTK/Qt theming wars: not present. The init system debate: not user-visible. The packaging format proliferation: replaced by a single consistent model.

The proof that the foundation was never the problem:

The Linux kernel powers Android. The Linux kernel powers Chrome OS. The Linux kernel powers every server that runs the internet. The Linux kernel is the Billy that holds everything.

The Linux desktop is the Billy that keeps moving the shelves. The users who assemble their flat-pack on a Debian foundation can predict where the shelf will be tomorrow. The users on Ubuntu are rafting. The users on Android have a boat trip.

Building a New Parking Lot for Every Car

Every distribution that moves its seams forces users to rebuild their mental model. Not just learn something new — unlearn something they were right about before.

The user who learned that applications live in /usr/bin and configuration lives in /etc is correct on Debian. Mostly correct on Ubuntu. Partially correct on a Flatpak-heavy system where the application lives in /var/lib/flatpak and the configuration lives in ~/.var/app. The parking lot moved. The car does not fit anymore. The user builds a new parking lot. Next version: the lot moves again.

The Raspberry Pi user who learned command-line Linux on Raspberry Pi OS does not have to rebuild the parking lot. The commands are where they were. The files are where the documentation said. Debian’s conservative approach to moving seams means the parking lot stays where it is. Buy a new Raspberry Pi — same parking lot. Upgrade the OS — same parking lot. The foundation is the Billy. The shelf is where the shelf was.

The Android lesson for desktop Linux:

Stop fighting about where the seams should be. Pick a position. Defend it conservatively. Move it only with extensive warning and a long transition period. Let the tribal infighting happen on the mailing list, not in the user’s file system.

The 90% who use Linux on the Raspberry Pi, on Android, on Chrome OS are not in the mailing list. They are assembling the flat-pack. They need the shelf to be where it was last time. They need the hex torque to turn the same bolt it turned before.

Take the parts that work. Leave the rest. Get on with it.

The kernel is the Billy. The waterline should be stable. The books the users actually have should fit without rebuilding the parking lot.

A Different Printer for Every Chapter

The book that requires a different printer for chapter 3 is not a book. It is a collection of documents that happen to be numbered sequentially. The meaning spans the chapters. The Gutenberg layer should be indifferent to which chapter it is carrying.

The Linux desktop requires a different printer for every chapter:

  • Chapter 1 (GNOME application): GTK3, GNOME keyring, Wayland
  • Chapter 2 (KDE application): Qt5, KWallet, X11 compatibility layer
  • Chapter 3 (Electron application): ships its own Chromium and Node.js, 200MB for a text editor
  • Chapter 4 (Flatpak): sandboxed, different filesystem view, different portal system
  • Chapter 5 (Snap): different sandbox, slower startup, different update mechanism
  • Chapter 6 (AppImage): no sandbox, no updates, just a file you downloaded and hope is safe

Six chapters. Six printer configurations. The user who wanted to read a book is now a printer technician.

The Raspberry Pi contrast: every chapter uses the same printer. apt installs it. It goes in /usr/bin. The tutorial from 2018 still works. One printer. Every chapter. The book is readable.

Windows: one printer per era, ugly and consistent. Every chapter looks the same shade of slightly wrong. Readable. Mac: one beautiful printer, maintained in lockstep with the OS. Every chapter looks right on the same paper. Readable and beautiful. Linux desktop: bring your own printer for each chapter. The book is technically present. Reading it requires printer management skills the author never intended to teach.

The printer is the Gutenberg layer. The chapter is the Semantic content. The waterline should be invisible — the user reads without knowing which printer produced it. Android hid the printer. Chrome OS hid the printer. Debian on the Raspberry Pi hid the printer. The Linux desktop put the printer in the living room and asked the user to manage it.

That is the tribal infighting made visible. Every tribe decided their printer was the correct one. Nobody asked the reader.

This post is part of the Gutenberg/Semantic series. Related: Nothing Is Confusing to Me: The Inmates Are Running the Asylum on proximity blindness and tribal Def, Don’t Go Down With Your Iceberg on the cost of fusing to the substrate, and The Watershed on Android and Chrome OS taking the Linux thread and running with it.