Big Bubbles (no troubles)

What sucks, who sucks and you suck

Linux's Not UNIX

Just popped up on my radar thanks to @mattwillsh, Paul Eberhart’s Linux Future post from last August is a great read/rant about the current direction of Linux development, that is garnering a lot of relieved agreement from long-time UNIX hands. The spark, as it usually is at the moment, was another longwinded discussion about the merits or otherwise of systemd, Fedora’s recently adopted init (and ‘everything else’) replacement, but Eberhart perceptively identifies this as only a proxy for general concerns, often inarticulately expressed, about the apparent direction of the Linux OS. Worth reading for the comparison of ‘The UNIX Philosophy’ against what he terms the ‘FLOS’ (FreeDesktop Linux OS) philosophy alone.

Meanwhile, Lennart Poettering carries on writing code and replacing all the legacy parts of Linux that offend his sensibilities (and to be fair, he has a point about most of them even if you don’t agree with his methods). (Beware, having broken the back of init, he’s coming for your Grandma’s faithful syslog next.) While I share Eberhart’s concerns, I think we need to look at how and why we got to this state, if only to consider whether matters are likely to improve from the point of view of ‘old skool’ UNIX hands (short answer: unlikely).

I came to UNIX via what I now tend to think of as the ‘classical’ route: I first encountered it in the university lab during a Computer Science degree, specifically SunOS 4 (i.e. proprietary UNIX rather than open source). I learnt my way around by referencing documentation that probably originated in the 70s and early 80s, specifically in the form of a photocopied, monotype manual (which I still have - wonder if it’s online anywhere?). This introduced you to the command line via C Shell and some basic utilities such as vi. If you wanted a GUI, you ran ‘startx’; then you could run lots of shells (terminal emulators) on the same screen, which was useful. It was a fascinating education, much more interesting than any of my degree modules, that ultimately led to my present career and that I now feel privileged to have been part of the last generation to enjoy.

…Because my perception is that UNIX users no longer come to the OS via the ‘lore’ (if that word puts you in mind of wizened elders with pointy hats, beards and sandals, it’s entirely intentional). They come to it via the Internet (or occasionally via covermount CDs on mainstream hobby magazines), and they’re not using it because their academic course requires it. They’re using it mainly because they want a better, free (as in cost) Windows replacement, or it seems cool (or did until we all bought smartphones instead of PCs), or they want to be teenage haXXor5, or some other reason that has little to do with cultivating a fine beard and a knowing air. (I’m not seeking to be pejorative about this, by the way; generally, more people knowingly using a UNIX-based OS is a great thing, regardless of hairstyle.) And they’re not coming to UNIX per se; they’re coming to Linux. And Linux, as is increasingly being emphasised, is not UNIX. (Strictly speaking it never was, being unable to trace a direct descent from V7 via the BSD or SysV lineage, unlike all the ‘real’ UNIXes.)

If you’re coming to Linux from a desktop OS like Windows or MacOS, you pretty much want the experience to be at least as friction-free: removable media should automatically appear, printing should just print (OK, possibly a holy grail that one), audio should simply output (never mind, eh Lennart?), boot time should be minimal and everything should Just Work without requiring you to touch the command line. Hence we saw the appearance of desktop environments (not applications or systems, which imply something much less integrated and all-encompassing), chiefly GNOME and KDE. And what the developers of those environments gradually realised was that their lives would be easier, and their functionality much more complete, if they could extend their chubby fingers into the OS and modify it to serve them directly - even if it meant serving others less well or not at all.

This is great - or at least invisible - if you’re a GNOME or KDE user. It’s still pretty good if you use a compliant alternative such as XFCE. But it has rapidly become a nightmare if you prefer something else, particularly if you’ve bodged together your own environment by picking and choosing individual components (fluxbox for the window manager, rxvt for terminals, Chrome for browsing, etc.). And then it gets worse if you also partly think of your desktop as a server, and still expect to drop down to a root shell to mount a disk or tune the system config - hey, who moved my cheese?!

Linux isn’t particularly tackling problems that other UNIXen haven’t also faced. The init system has long been the focus of complaints, dating back to when we argued whether BSD or SysV-style rc scripts were better, and the growing prevalence of desktop use and the requirement for faster startup and shutdown has only sharpened these. Hence Solaris introduced SMF, for example. (If your UNIX flavour isn’t doing anything about these sort of issues, it’s likely that it is slowly declining towards obsolescence and your vendor is expecting to transition the userbase to Linux.)

The difference, as Eberhart acutely sums up in his post, is that all these issues on Linux appear to be tackled through the prism of ‘what best suits the desktop requirement’ - almost solely, with at best lip service paid to the other options.

Systemd isn’t so bad in itself. It’s different, and nobody likes change, but the overall design appears cogent and, once you know the relevant arguments, systemctl is straightforward enough to use. There’s a general feeling that it beats Upstart, which was the last well-known attempt to fix init (I’ve heard it opined that it’s also better than SMF, because there’s no XML involved). But it does a lot, and it does so by extending into everything so that you can’t easily remove it and use something else; it’s a pain to debug when it goes wrong or doesn’t quite work as you expect because “WTF is it doing??”; and it’s intentionally Linux-centric and non-portable, which means there is almost no chance of it ever appearing on the other UNIXen you manage, which is about to make your day job another order of magnitude harder even if you successfully CONFIG MANAGE ALL THE THINGS. It represents, and is proud of it, Fragmentation. (In fairness, SMF was unlikely to appear on any other UNIX OS either, but for different reasons and not for any inherent dependency on Solaris.) No wonder UNIX old-timers, sysadmins and command line hackers have some misgivings.

At the end, Eberhart wonders “if mainline Linux is going to retain its position but become largely unrecognizable as a UNIX system”. I incline towards this belief myself, assuming Linux retains at least its current profile as a desktop system (which is by no means guaranteed, given that even Microsoft is struggling to sustain interest in Windows). I doubt the naysayers will have much impact on its present course, as Poettering and his compatriots continue to put up working code and garner significant support within the Fedora project. You can’t march behind the status quo. The one possible point of conflict sufficient to derail the oncoming train that I can see is Red Hat’s (and Canonical’s) enterprise business and its dependence on a suitable Free base for a server OS. Once you start pulling in dependencies on D-BUS and mDNS and higher level desktop infrastructure, a minimised server OS install, of the sort usually stamped out via EC2 images, looks increasingly untenable. Even if storage is now cheap, nobody is going to want to be forced to install several hundred megs of GNOME libraries and components with porous interfaces, unknown vulnerabilities and no direct purpose on their Internet-facing cloud VM, let alone administer the tottering pile that results. (There’s probably an opportunity here for the BSD and Illumos derivatives, assuming that the codebase for the kind of cloud applications people want remains relatively portable and untainted by these Linuxisms. Hmm…do the other UNIX flavours also want to retain access to a portable desktop environment codebase? And do the GNOME and KDE projects care about that anymore?)

You know what? We - the UNIX community - only ever borrowed/co-opted Linux, because it was the easiest, cheapest way to get a mostly (or occasionally better) UNIX experience on the kind of hardware we could afford. When the value and performance proposition became undeniable, we even started deploying it on the server. But it turns out that Linux wasn’t really meant for us, and doesn’t care about that stuff; it has wider ambitions. Whether those ambitions will turn out to be worthless once the destination is reached, because the party has moved on, time will tell.

(What do I continue to use on my desktop at home in the interim? No idea; I mainly still live on the command line, but I also want to get work done using applications such as photo editors and office suites that have finally become available to a reasonable standard on Linux, which precludes moving to, say, FreeBSD or OpenIndiana. Either I keep Fedora around for this stuff and resolve to treat it like a commercial blackbox OS, or I buy a Mac Mini or Windows PC and live with commercial software in its own dedicated environment. The sad thing is that it now feels like there’s little difference between those options, other than cost.)

Other bubbles