Unix philosophy is dead Long live something else?

Unix philosophy is dead! Long live... something else?

The more I learn about the systems I depend on every day, the more I'm convinced that everything in compsci is a dumpster fire that we collectively refuse to extinguish. It's a social problem - and, of course, everyone is trying to solve it with tech.

Haruhi says...

"dmi went into a bit of a different direction than usual with this one! she asked me to issue a Content Warning for Capitalism and The Current State Of The World. Heavy language and philosophical topics ahead."

Myth of the UNIX philosophy

Personally, I don't believe in simplicity. Not KISS, not suckless (eww!), not even the UNIX philosophy. Growing up, I used to swear by the last one, ignoring the parts that no longer fit, and trying to make the most of it - but that's adding nuance to a philosophy that hates nuance at its very core.

Wikipedia lists 7 different sets of rules that can be named "The UNIX philosophy", all of which compiled by different people, across 30+ years of UNIX history. I can't summarize them any better than Wikipedians already did, so I'd recommend skimming over that article before continuing with my post.

I genuinely like some of the points that get brought up. The platonic-ideal UNIX environment appeals to me as someone who loves shell scripting - I spent so much time in the shell that pipes and redirects feel like a much cleaner, prettier solution than virtually anything else. But even within my environment, there are no tools that fully adhere to any version of the "UNIX Philosophy" - whatever that is, really. See, beyond Wikipedia, if you ask ten hackers what the UNIX philosophy really is, you will get 12 different responses. And, as soon as they state them out loud, those versions too become the truth and canon. Adherence is recommended, but if something doesn't fit, you can just alter the ruleset.

Pedantry Corner

"But coreutils fully adhere to the UNIX philosphy!

They only do one thing, and they do it well!"

Reality check: how many command line switches does cat take? I'm running busybox, and that one has

six, plus --help:

$ cat --help
BusyBox v1.37.0 (2026-01-10 15:38:28 UTC) multi-call binary.
Usage: cat [-nbvteA] [FILE]...
Print FILEs to stdout
-n Number output lines
-b Number nonempty lines
-v Show nonprinting characters as ^x or M-x
-t ...and tabs as ^I
-e ...and end lines with $
-A Same as -vte

For a tool that's most often used just to read out a file, that's a lot. Hell, most of them can be trivially recreated with tr or sed.

As for the latter part, "do it well"... I can list you a non-trivial amount of bugs and papercuts in sed and grep out of the top of my head. I beg to differ.

In our harsh reality, there's a multitude of large tools that do several semi-related things. curl immediately comes to mind: despite how well it fits with classic stream-processing tools, it probably does five hundred things you haven't thought about yet. Single-purpose tools still exist, but I'd consider them to be on the way out. Text streams have proven to be a bad fit for almost everything outside administrative tasks and quick hacks. Heck, most younger Linux and UNIX users seem to be getting increasingly scared of shell scripting - some going as far as to replace simple automations, previously achieved with scripts, with programs written in compiled languages, like Go or Rust.

But that's just the UNIX bubble - there's a whole other world out there.

Outside world

Unless you're a nerd, CLI interfaces are passé. To some of us (myself included), it's often hard to imagine the world outside OSS: what do you mean Windows machines, running a concerning amount of spyware, some of which is even 1st-party?! Of course, the UNIX philosophy wasn't in mind of anyone designing any piece of Windows software, but let's try applying it anyways:

For regular users, tools are generally large, integrated software packages that do a lot of things - some better, some worse - and attempt to offer a coherent experience across all of those functions. This makes sense: if you're using a graphics editor, having more integrated features means less user time for the same output. Exporting a PNG just to overimpose some text onto a blank frame, then import it back again would suck, and has never been a good workflow - except, if read literally, this is exactly what the UNIX philosophy strives for.

A lot of large software suites offer some sort of a "macro" system: a way to "script" the internal functions of a program to achieve a specific end result. This is analogous to shell scripting, except much more limited. "Power users", the more tech-savvy crowd that knows their applications deeply enough to even look for scripting support, generally love the feature: it reduces the repetitiveness of basic tasks, and saves lots of time. Meanwhile, regular users (reminder: that's most of them) don't know about macros, or require assistance in setting them up - even when good documentation exists. This is in direct opposition of what the UNIX philosophy assumes: how can the user be expected to leverage scripting, if they don't care to understand the system itself?

Smaller GUI tools are notoriously hard to chain and integrate together. The most common interface for transferring data between programs is copy/paste, which (on Windows) uses OLE objects to carry something more than just plaintext. The results depend highly on software support on both sides; from the perspective of a casual user, OLE is the annoyance that messes with the text styling when pasting stuff into Word.

Of course, all of those examples are over-exaggerated. Those rules would look different it they were written around UIs - but through exaggeration, you've hopefully noticed how not all "ideal" solutions fit for real-world problems. This applies both to the Windows world, as well as our local UNIX/Linux playground.

One solution (does not|to) rule them all!

Developers tend to generalize everyone and everything, until they can come up with one, common, "beautiful" solution. Of course, you may not do it - but lots of developers do.

In my opinion, this is the largest ignored fallacy of the modern computing industry.

"One common solution" to any problem that isn't completely banal is literally impossible. You already knew that if you've been around the block enough times, and seen how people really use tools. But damn if developers didn't try!

Different users have different needs. Figuring out what exactly those needs are is an unsolved problem unto itself. If developers listen to their userbase (and not all of them do), they can only improve based on their mental model of what the userbase wants - and that mental model is bound to be biased and inaccurate. Users don't know the internal design of the program, and developers don't know the exact user workflows. A simple suggestion often turns into a multi-day refactor, because the rabbithole really goes that deep. Nothing is simple - except simple things, but we don't know which things are simple until the task is over.

I find old interfaces fascinating. It's a mix of figuring stuff out for the first time, together with working around limitations of old technology. You only know how hard it really is to design a good low-res interface if you've done it before.

What isn't immediately obvious becomes clear once you mess with it.

What the designers of old have come up with is nothing short of spectacular: at odds with low color depths and poor quality screens, they still managed to come up with something that looks appealing, logical, and readable.

it kind of rules?

Of course, even back then, copying from the next kid over was commonplace. Virtually all interfaces were walking the thin line between "inspiration" and "plagiarism". Companies were sued, agreements were signed, history was made.