Some time ago I came across yet another angry discussion about systemd, and have been reading and thinking a great deal about the design of Systemd, and what it says about Linux. I’ve come to realize that the strife in the Linux community is because an active and well-funded group of developers who have been driving the direction of various core components are not building UNIX. They are building some other philosophically divergent system on top of the Linux kernel, with roughly the same relationship to UNIX as Plan9. For convenience I’m going to call the non-UNIX environment they’re building FLOS for the remainder of this post (F since the FreeDesktop.org folks, and their backers in the Fedora project, are driving this, L for the Linux kernel, OS should be self-explanatory). I intend this term to be value-neutral.
To me, the core of a UNIX system is a philosophical matter. To quote Mike Gancarz’s The UNIX Philosophy from 1994, UNIX has 9 paramount precepts:
- Small is beautiful.
- Make each program do one thing well.
- Build a prototype as soon as possible.
- Choose portability over efficiency.
- Store data in flat text files.
- Use software leverage to your advantage.
- Use shell scripts to increase leverage and portability.
- Avoid captive user interfaces.
- Make every program a filter.
FLOS is a nearly diametrically opposed design, with design concepts like the following:
- FLOS avoids scripts, and prefers to split tasks into compiled logic interacting with logic-less configuration files.
- FLOS prioritizes ease of machine manipulablity over human manipulablity.
- The components of FLOS communicate over D-Bus rather than sockets and pipes.
- FLOS is built on a core of monolithic programs which attempt to synergisticly manage multiple complex components.
- FLOS leverages features specific to Linux and ignores portability.
- FLOS prefers tightly integrated components to generic solutions.
I’m not sure that this is a bad design, but it is most definitely not UNIX or anything like it. I’ve seen some fairly convincing arguments that the FLOS design philosophy has serious benefits, and there are decades of convincing arguments that abandoning the UNIX way is the path to ruin. Systemd is the big realization of the FLOS design, but many projects, especially FreeDesktop projects, have been working this way for some time. I’m going to pick out a couple examples and talk about them under the fold.
I run Arch, so my examples will be focused there… although from the look of things the Fedora project’s choices are being taken as upstream gospel, so I’ll be pointing at them quite a bit as well. Allan Mcrae has been particularly vocal about whatever Fedora does being the right thing for Arch to do, such that no Arch-specific changes will need to be made for software that is compatible with FLOS. Arch’s own philosophy, The Arch Way was a big part of what attracted me to Arch in the first place, but its execution is making Arch a particularly bloody place while the larger community decides if Linux will continue to be a UNIX-like system.
In retrospect, the first strong signs of the FLOS design showed up with Udev in 2003. Udev was easy to miss, because it was a necessary change – the old DevFS system did not deal well with dynamic devices, was largely unmaintained and ill-understood, and there is a cogent argument that it is safer and more flexible to perform device management in userspace rather than in the kernel. Udev initially demonstrated FLOS design in that it uses a fleet of logicless configuration files, but has since swallowed Linux’s old hardware abstraction layer, HAL, becoming a sort of monolithic hardware management process, and switched to communicating with other processes via d-bus. Udev’s source tree and development process has also recently been moved into systemd’s, to further integrate the pieces, as a FLOS design would advocate.
One of the earliest really apparent examples of the difference between UNIX and FLOS is the move to ignore the FHS. Ignoring the FHS is happening in two ways visible from my Arch system at the moment.
One form is that the Udisks developers (FreeDesktop.org folks, naturally) took it upon themselves to move automount paths from
/run/media/$USER/$DEVICE_NAME. I’ve already bitched about that here, but to summarize it makes working with removable media from the command line a miserable exercise in digging around long unpredictable directory hierarchies, makes it much harder to script around removable media, and creates weird problems with device ownership and mount paths for removable devices attached when the number of users logged in is not exactly equal to 1 (0 being the most frustrating and common exception). I’d like to specifically quote the Udiscs2 command documentation, because it makes my point for me:
This program is not intended to be used by scripts or other programs – options/commands may change in incompatible ways in the future even in maintenance releases. Scripts and/or other programs should either use the D-Bus APIs of udisks2-daemon(8) or native low-level commands such as mount(8).
In other words, Udisks2 is not to be used with scripts or via a textual interface, you communicate with it via d-bus. It is tightly integrated with upstream (udev, and the *Kits) and downstream components (Desktop Environment) – FLOS, not UNIX.
The more drastic form is the effort to throw everything into /usr and symlink stuff out to where the FHS says it should be, and nearly every piece of software for a UNIX like system ever made expects it to be. The Fedora project has a vast document here, which makes circular references to the similar page at the FreeDesktop project defending and documenting this change.
Historically, the basic distinction was that
/ is required to bring up the system, and
/usr can be mounted later, from the network, or a slower/more complicated storage device… or not at all if something goes wrong. This also means that a single image of the entirety of
/usr should be readily shared between similarly configured systems, bolstered by a rule that things not performing system administration should never write to
/usr. There is a reasonably recent spat about this stuff here, do not just read the first message that tries to trivialize the distinction despite supplying still-relevant reasons, a few messages later more counter arguments show up. I’m going to exclude a longer discussion of this, because it is instructive only as an example of “We don’t care about UNIX,” rather than a good exposition of the FLOS design.
Another big piece of FLOS style design showing up on Linux was the rise of the *Kits
– PolicyKit, ConsoleKit, PackageKit, etc. These are now all but required to run a normal looking interactive Linux system. They are designed to be easy to use via an API, but difficult to use from the command line. They support configuration files and discourage scripting. They have basically built a FLOS-style system to supersede various pieces of UNIX, particularly around user management and permissions, which break various UNIX conventions in favor of finer granularity and binary APIs.
ConsoleKit and its successor, systemd-loginctl are particularly interesting. ConsoleKit is a cludgy abomination, built to bridge between FLOS-designed parts and UNIX designed parts – it spawns on the order of 60 idle threads, and manages the interaction of normal UNIX processes with FLOS style behaviors in session management, permissions, and hardware interaction. systemd-loginctl is the new mechanism, which is integrated into systemd and simply ignores the old UNIX way of doing things. systemd-loginctl is naturally much more elegant as it doesn’t have to bridge paradigms, but also leaves anyone not using a suitably enabled session type out in the cold.
I’ll only mention Systemd in passing, even though it is clear to me that systemd is the transition point from “Linux as UNIX” to “Linux as FLOS,” simply because I haven’t dealt with it enough to feel comfortable commenting on the implementation yet, and wanted to get this finished and posted. The simplest argument for Systemd as the realization of FLOS is to take a look at the list of features in this justification for Systemd. Even a Linux sysadmin/power user will be spending some time with google figuring out what many of the things Systemd does are – it doesn’t do one thing well, because it does fucking everything . It does init’s job. It does inetd’s job. It integrates a bootsplash mechanism. It talks over d-bus. It is configured with a pile of logic-less configuration files and binary tools. It integrates with the *kits. It makes heavy use of Linux-specific features like cgroups. It handles disc management. It handles user authentication. It has more bells, whistles, and kitchen sinks than many simple Linux based systems I use regularly, and it is just the init process. I find reading about systemd rather draining, because it consistently makes design decisions that are absolutely opposite of the UNIX way, backed by otherwise mostly cogent arguments. The argument is whether or not preserving the UNIX philosophy is more important than adding features and making ease and performance gains for specific use cases, not about systemd in particular.
It’s too early to tell if FLOS will fall on its face like all the other not-quite-UNIXy-enough OSes that have come by, or if mainline Linux is going to retain its position but become largely unrecognizable as a UNIX system. I’m not entirely decided if that is a bad thing (for the record: I mostly think it is, but there are a handful of convincing arguments to the contrary in specific cases), and I’m not sure what I’ll end up running in that eventuality. The various more UNIX-like *NIXes (the *BSD flavors and Minix and such) are third-class citizens, and having nothing that behaves like UNIX around dramatically reduces the joy of It’s a UNIX system! I know this!.
Now that I have the product of some weeks’ musings and readings out in a wall of text, I’d like to know if my interpretation of the situation makes sense to anyone else.
 Anyone who objects to most of what I’m talking about on the internet seems to be immediately, and ironically, accused of ad-hominem attacks on Lennart Poettering, so I’ll go ahead and address that – I’m interested in the philosophical situation, not the individual developers. Pottering has been a prolific adherent to the FLOS philosophy in words and code, so he naturally comes in to the discussion, but this isn’t about him.
 I don’t mean to compare what Linux is turning in to to Plan9. Plan9 is, frankly, more UNIX than UNIX in its philosophy and adherence to that philosophy. Plan9 was also very carefully, if you’ll pardon the pun, planned, while FLOS looks to be very much an ad-hoc effort, making a sort of Cathedral/Bazaar example (Link is to a recent discussion, not the old ESR book).
 W’re talking about nerds and philosophy, so things are obviously contentious. FLOS suggests both “FLOSS” (Free/Libre Open Source Software) and “F*ing Loss”, so the reader is welcome to hear the value distinction they want in it.
 As much as I love Arch, some things really piss me off about the community, in particular that development decisions for some years have been made by insular cabals on high-volume mailing lists, and if anyone in the user community complains about decisions on the nice modern managable BBS that looks like the center of the community, they are told they “Should have read the mailing list a year ago,” while non-members of the cabals are angrily dismissed if they speak up on the lists.
 The merged /usr (which is an ass-backward name, btw) proponents point out that Solaris has been working this way for 15 years. Solaris has always been an odd duckling among the *NIXen, which eschews many conventions that most others follow. I for one find the hall-of-mirrors nature of the Solaris file system really fucking aggravating – last time I dealt with Solaris boxes, I was working on a system configured from a pile of directories and subdirectories haphazardly cross-linked between /etc/ and /usr/lib, which is absolutely fucking insane.