being Unixlike

updated: 2022-01-19

It is possible to be "for" something without being "against" other things, and that is often a laudable goal, but that should not prevent us from differentiating between the thing we like and different things. With that in mind, to varying degrees, the following is a desription of things we deem un-Unixlike:

• GNU

  GNU stands for "GNU's Not Unix". It is an apt name: the design of GNU tools, while aiming to reimplement many features of a Unixlike OS, was undertaken with an explicit goal of diverging from Unix as the world then knew it from the beginning. GNU tools often not only diverge from POSIX standards, but also from Unix philosophy in quite egregious ways. One of the most obvious is the rampant violation of Doug McIlroy's entire description of the Unix philosophy: "Do one thing and do it well."

  An especially egregious example of GNU tools intentionally going horribly awry is the absurdly ideological violation of Unix-style privilege separation perpetrated by GNU's implementation of su. Thanks to Richard Stallman's edict, GNU su is explicitly prevented from having its accessibility limited by a requirement for a non-root user account to be included in the wheel group before that account can use su to gain root privileges. Any modern, sane implementation of su should allow admins to prevent non-wheel user accounts from acting with root privileges.

  A more pedestrian example, but still worse than a simple case of a tool being less Unixlike in GNU form than is otherwise normal, is wget. We should prefer curl, as a straightforward approach to copying files across the network. Any implementation of whole website mirroring in the vein of wget should ideally be implemented in terms of curl, via a simple wrapper script or use of the cURL library in a more substantive -- but still simple to use -- program.

• GNU/Linux

  Only somewhat distinct from the point about GNU, but desering its own mention, is the attempt to cobble together a Unixlike OS by combining GNU userland with the Linux kernel. This is, to be fair, sufficient to create a user experience somewhat (superficially) like a Unix OS. The wide-ranging incompatibilities by default with both POSIX standards and Unix conventions can easily trip up users, and often contribute to situations where portability across Unixlike OSes is worse than is reasonable. Nontrivial Bash scripting, differences in how various command line options work to render familiar options quite surprisingly unfamiliar, and deeply entangled dependencies amongst common tool types lead to consternation in practical application of the Unix philosophy.

• Red Hat

  Red Hat and its employees have contributed a number of annoyingly un-Unixy things to the general open source ecosystem over the years. The egregiousness of these ham-handed attempts to "improve" our tools has grown from merely frustrating (e.g. the weird and awkward network configuration files of Red Hat Linux in the '90s and '00s) to utterly antithetical to Unix life (e.g. systemd, about which you can read more later). Some intermediate horrors include NetworkManager (known "affectionately" as NetworkMangler, the Fifth Horseman of the Apocalinux), which set out to import the Microsoft style, nondeterministic flavored, "fighting against the user" brand of network configuration to the Linux world; PulseAudio (which also sported a few unpleasant slang monickers), an incompatible reimplementation of part of ALSA's support for sound operations with some new, sometimes dubious additions to its capabilities, ultimately resulting in this ALSA "replacement" having to be used alongside ALSA if you want full audio support on Linux; Red Hat's input into the eventual shitshow of the LSB; and the X Development Group Base Directory Specification (see that later in the list).

  Red Hat's crimes are many, mostly petty, and generally just a constant whining purple sound in our ears as we try to get by in the world of computing environments. Avoiding Red Hat distributions (e.g. RHL, RHEL, Fedora, and CentOS) has been a great way to avoid those pains a lot of the time, but some of the more poignant miseries (including those mentioned by name above) have infected the larger Linux world with much more pernicious hazards.

• restrictive licensing

  In the grand tradition of the hoary olde Unix greybeards of auld, including such luminaries as Ken Thompson, Dennis Ritchie, and the folk behind the early BSD Unix systems, we resist restricting access to our code. That means avoiding proprietary and copyleft licenses, of course, but also licenses of any kind that come with overly bureaucratic compliance requirements and unreasonable, easily avoidable license incompatibilities. This is why the ##copyfree channel is mentioned in the About page of this site: copyfree licenses are our refuge from legal restrictions. Just as we favor programs that interact easily with arbitrary other well-formed Unixy programs, we favor licenses that interact easily with arbitrary developers and arbitrary other (hopefully well-formed) Unixy licenses.

• sudo-as-root

  Wholesale replacement of su with sudo comes with unpleasant consequences. That aside, however, it violates the Unixlike ethos of trusting the competence of the admin. Ideally, we should choose sysadmins who are competent. While there are cases where this is not practical or (in some sense) desirable, these should be identified on a case-by-case basis and handled only as needed. Replacing su with sudo as increasing numbers of Linux distributions have done could be valid for a particular deployment environment choice. That said, an entire OS (e.g. Ubuntu) being saddled with this choice by default, forcing anyone who wants to back out of this system administration approach to apply nonstandard (for that OS) configuration, is decidedly un-Unixlike.

  The problem is compounded when there is no reasonable way to delete unused code and configuration without breaking the system's included management tooling. Arguably (to put it mildly), part of being Unixlike includes not having to keep gigantic heaps of deactivated, un-Unixy software and configuration strewn about the system, cluttering up the place. Even including a giant privilege separation bypass mechanism mudball like sudo in a default install, whether activated or not, is deeply questionable from the perspective of the Unix philosophy.

• systemd

  Initial debates about whether to incorporate systemd into Linux distributions were predicated on claims that SysV init was bad, and systemd was good (as SysV init's replacement). Whether the init-related functionality of systemd was actually good in principle, there were concerns about its quality of implementation even then. It quickly became clear, however, that systemd was not only of dubious quality in some ways, but also much more than an init system or even init++ (e.g. including runtime control system). It gradually grew toward evidently attempting to replace everything in Linux that was not a kernel or optional in one giant hairball of subsystems, and also set out to pre-empt a lot of optional components by providing half-baked defaults that could be extremely difficult to root out or even just disable entirely.

  In addition to being a do-everything antithesis to the principle of doing one thing well, systemd has demonstrated a strong propensity for exhibiting various devastating operational issues (e.g. breaking FDE so you can't use your installed system or access stored data any longer), including security vulnerabilities, utility-destroying bugs, potentially hardware damaging behavior (e.g. undesirably waking a sleeping laptop while it's in a backpack), and downright antisocial "my way or the highway" system design choices. Sometimes, vulnerabilities and bugs even get designated "features", with blame for any problems directed at admins and users, in a remarkable echoing of classic Microsoft-style gaslighting behavior. On top of all that, systemd development has tended toward pushing Linux distributions to support only systemd, and no optional alternatives, which is antithetical to the idea of trusting a sysadmin to choose how to configure a system. Similar forced support scenarios have cropped up in relation to applications and desktop environments (e.g. GNOME), too, pulling the rug out from under the typical "everything should be easily replaceable" preference ethos of the Unix world.

• XDG BDS

  The X Development Group Base Directory Specification seems at first glance like a noble effort to address an important concern for portable application configuration standards. Upon closer inspection, it reveals itself to be a complicated mess of micromanagement and violation of all the simplicity of long Unix tradition. Parts of the BDS seem quite reasonable, but only if stripped of most of the detail. The result is that full compliance with the BDS would be prohibitively difficult, more than double the code weight of many programs, and unnavigable by anyone who is not willing to devote significant quantities of time to the arduous task of becoming a subject matter expert in one single, specific, bureaucratic, overwrought, agonizing, self-important, impractical system whose documentation is a scattershot disaster area of divergent and often nigh-impenetrable forms of documentation. Even the file types of the specification documentation differ from one part of the whole to the next.

  All of this is, for the most part, foisted upon the world just to manage things like configuration and log files. Unix lovers should just ignore it.

• ZFS

  If you want to use ZFS because it serves some important purpose for you, have at it. Using it all the time just because it exists, consuming system resources when you do not even use its features beyond the more basic capabilities available to pretty much any Unixy filesystem, is like buying an M1 Abrams tank for driving to your dayjob at Del Taco. A valid choice is not necessarily a valid default, and ZFS is a great example of that. Apply this principle to other, similar options, such as btrfs which, at minimum, should offer the filesystem and logical volume manager as separable, more generally composable, and non-default choices.

by apotheon

2022-01-14

If you have comments, questions, or a burning desire to explain how we're wrong, see the About page to find us on IRC and discuss this document with us.