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.

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

I see some of you running towards me, screaming:
  "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 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.

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.

Those were the 80s. Fast-forward 20 years, and as much as the interfaces changed, the design trends didn't: imitate apple, "with a twist".

Of course, nothing in tech stays the same for long. As better screens became the norm, interfaces faced new challenges: scalability, responsiveness, supporting multiple aspect ratios, and so on. All of those problems are notoriously hard to solve, even more so when backwards compatibility is a factor. It's also much harder to "steal" someone else's solution - UIs are visible, underlying algorithms... Not so much. The results ranged from okay to sloppy to downright dreadful.

Lessons were learnt. New frameworks were built. With time, a lot of the "stack" got turned into webapps, some running in a browser, others masquerading as a separate window, pretending they're "Native". Even more of the focus shifted towards a mobile-first approach, where the user is expected to own an Android or iOS smartphone to even have a chance at running the app.

Pedantry Corner

I'm writing native with a capital letter and quotes for a very specific reason: in 2026, it's hard to decide what's a native interface, even for mobile platforms. Unless all the programs are 1st-party, native interfaces can only really be strived for, not actually achieved. If it's even remotely possible, a keen developer will be quick to add their own widget, custom element, or UI control.

Of course, one such case doesn't make the UI "custom", but at some point we'd be faced off with a Ship of Theseus situation, where the toolkit is "still the same", but everything is custom, a'la how Telegram uses Qt.

This begs the question: once a significant amount of 3rd-party applications are available, is the "native" look what the toolkit developer envisioned, or is it what the status quo ended up on? I'd argue that it depends on your perspective and alignment between "application developer" and "toolkit developer".

The situation is even worse on Linux, where there are no 1st-party UI toolkit developers. Both GTK+ and Qt are equal contenders. What, the CLI? Get off!

In the 2010s, web assumed a design language much closer to the then-new smartphone interface - and through frameworks like Electron, a lot of it leaked through to desktop programs. Large margins, "symbolic" icons, flat interfaces, hiding as much of the UI as possible - all of this was a purposeful shift towards applications which look simpler, and aim to be easier to use for the newbie.

Of course, a philosophy like this would completely disregard the professional - and, to be fair, the design shift is less apparent in pro software. Compare Blender from 2003 to Blender from 2026:

Similar information density - if anything, 5.0.1 is more readable. The UI got redesigned a couple years back, but the spirit is still there. Same thing applies to virtually all programs for professionals. It's an exception to the rule: when redesigns happen, they're usually there for a reason, and rehash things in a more... thoughtful manner.

However, specialized professionals and generalized power users depend on all kinds of applications, not just pro stuff. To assume that they're exempt from the change would be foolish. Furthermore! Oversimplification of the user interface has a much stronger negative effect on someone who suddenly needs to click through 3 layers of menus to get to the same option 100 times a day compared to someone who does it maybe once a month. This is why users rarely complain: 99% of them don't care, and whoever remains has to eat it up, while constantly listening to others invalidating their experience.

Deep inside, a part of me cries seeing each and every app redesign. Not because I hate what's new, or even because the interface looks "worse". Rather, it's been a Hot Second since I last saw a full redesign that honestly iterated on things that mattered for me, a power user. Instead, every redesign forces me to discard the muscle memory I built around the UI, and re-learn how to perform the same basic tasks, often through a worse workflow. And because most programs are huge monoliths, I can't easily fork it myself and backport an older UI. Trust me, I've tried.

Back when OSS was a rebellion

As I was writing this piece, I got linked to a systemd MR where they integrate a birthDate field into systemd-userdb. I'm not really interested in discussing any other parts of systemd and its general direction, mainly because I don't believe there's anything left to be said on the subject that both hasn't been already said and would get to the right audience. But this change in particular is a perfect example of how much the open-source community shifted over the last 20 years.

We used to be a rebellion against big tech. An alternative with huge aspirations, and even larger pros/cons if one decided to depend on it. 90s and 2000s open-source was genuinely cool, and it felt like a place where things are possible. Where you could change something meaningful, and make the world a better place. The earlier you go, the less money was in the game, and the more innovation happened just because we could improve things. This is what got me excited about OSS back then: the hacker spirit, the promise that despite all the shortcomings and an impossible learning curve, something better was possible. Back then, that's what gave me hope.

And now? Open-Source is corporate as fuck. Instead of committing crimes because we believed the law to be wrong (see: libdvdcss), we're implicitly complying with regulations that exist purely to undermine our freedom, "just to be safe". It feels like everything that remains of the innovative spirit is centralized within hyper-specific groups of burnt-out (mostly queer) hackers. The crowd of generalists has moved on.

Who's responsible? Everyone? Or, maybe nobody? Did we all change because the crowd itself changed? Are we all acting according to some unspoken, ever-evolving social conduct? If so, how do we break out of it?

Despite how disconnected the subjects of this post may appear at first glance, there's a logical connection between all of them. For, you see, the dumpster fire keeps on burning not because we collectively wouldn't want to extinguish it. It burns because most people have "no opinion on the matter". It burns because people "just follow the rules". It's for a reason that internet is full of people who use LLMs because "it's convenient", completely ignoring all the problems (read: politics) around them. My question for those people is no longer "Where did you lose your moral spine?", it is now "How the hell did you manage to get this far without one!?".

The problems I touched upon have no easy solutions. We can't simply reverse time, or change how everyone thinks. Even if we could, the path forward isn't obvious; Everything is complicated, everything has deeper roots. I'd like to emphasize that despite the strong wording, this is not a hate piece. I have some heavy opinions on what's happening in the world, but I don't hate any individuals for how they act or acted. I do however find some of it spiteful.

Where do we go from here?

Measuring anything with a predefined set of virtues with no room for nuance is doomed to end poorly. The concept of a single "philosophy" getting applied to a field as broad as modern computer science is utterly ridiculous. At the same time, the polar opposite (blindly following the crowd) is what got us here in the first place. Neither one of the extremes lead to good things.

With this post, I want to encourage you, my dear reader, to THINK, and decide for yourself: exactly what set of virtues aligns best with you. There are no "sides of the barricade", no "us vs them", no "bad and good"; just different paths leading to different outcomes (for me, you, OSS, and the universe).

Proofreading by Riedler, Jana, Toast, kleines Filmröllchen, famfo, and Eloy. Thanks!

Comments: