I've been thinking similarly, that we're quickly going to want to start minimising dependencies and code size in the programs we make to try to reduce attack surface area.
It could push us further into dependency hell though, as people look for a package that does a simple task instead of the risk of expanding their bug/attack surface area, assuming that the library they depend upon has itself been checked (and the same for its dependencies all the way down).
Trying to keep code small could backfire by ballooning dependency on dependencies to do more of the work.
No, adding a "package that does a simple task" and is exposed to untrusted input expands "your bug/attack surface area". It isn't an alternative to "expanding your bug/attack surface area." People who are trying to keep code small will choose 400 lines of their own code that does only what they need instead of 4000 lines of code in a dependency.
That was always little more than unix propaganda. Until GNU came around and held itself to a higher standard, it was common for unix tools to do bullshit like read input into fixed length line buffers and silently truncate anything longer (when they weren't overtly crashing). "Do it well", hardly. A more true to life account of "unix philosophy" is "worse is better". It doesn't have to be good, merely available.
It’s still a relatively decent and ambitious thing to aspire to, i.e. a lean interface/tool scope that prevents scope creep. Composability (with pipelines) also works quite well. But yes, it is somewhat propaganda.
GNU programs do lots of things poorly, starting with "echo -e" and "cat -n" and continuing through to tools like awk and sed. Powershell does Unix philosophy better than GNU does.
> it was common for unix tools to do bullshit like read input into fixed length line buffers and silently truncate anything longer (when they weren't overtly crashing).
You might want to remind yourself what caused the November 2025 Cloudflare outage!
Yeah, well, the Unix philosophy is from the engineering department, not the accounting department.
Funding FOSS projects without advertising, dopamine-hacking, donation-begging into the void, or being subsidized by billionaires that want to influence the electorate is still largely unsolved.
The problem isn't that we don't know how (solved issue: UBI, higher pay for less work, high marginal income tax rate, unrealized capital gains tax above a minimum, land tax, etc.).
The problem isn't even the billionaires.
The problem is convincing comfortable, ambitious middle-high earners to put a cap on their and their bosses' prospects in exchange for the stability (and subsequent ground preparation for innovation) of a higher floor.
They're the stumbling block because they're the ones who, on balance and en masse, have the money and votng power to excuse and enable the status quo.
> The problem isn't that we don't know how (solved issue: UBI, higher pay for less work, high marginal income tax rate, unrealized capital gains tax above a minimum, land tax, etc.).
Part of the problem is that there are people who think all rather than only some of those things are a good idea.
High marginal tax rates and taxing unrealized gains are both unintended consequences factories. Especially the second one, but even the first one is basically a trade off between creating perverse incentives and arbitrage opportunities (i.e. massive loopholes) because the high rates don't apply to everything, or supercharging offshoring because the high rates do apply to everything.
Conversely, a UBI is a good idea, and doesn't actually require oppressive tax rates because it replaces most of the existing system of government benefits and subsidies -- which impose even higher de facto marginal tax rates on most of the middle class in the form of benefits phase outs. US federal spending is already >$20,000 per capita.
Not all of that is assistance programs, but a large proportion of it is. And most of those programs are a net negative compared to reallocating their budgets to a UBI. Having separate bureaucracies to administer separate programs for food assistance, housing assistance, education assistance, etc. is foolish even before they create weird marginal rate cliffs and higher marginal rates on lower income people by having arbitrarily overlapping phase out rates.
It isn't about the source of the money. Converting those things to a UBI would cost less money to give people more money because you'd save the amount spent on administration, while improving economic efficiency by not imposing arbitrary restrictions on how it's spent. The primary reason we don't do that isn't upper middle class people demanding a status quo in their own interest -- it isn't in their interest.
It's a combination of ordinary incompetence and bad structural incentives because politicians like to claim credit for creating new programs instead of just indexing the amount of a cash payment everybody gets to GDP per capita and then sending them all home.
I get that a lot of folks were traumatised by the shift from init based systems to systemd. However the architecture is sound and relatively straightforward given the inherent complexity in managing a diversity of system processes.
EDITED TO ADD:
If you’re looking for a UNIX anti-hero regarding “do one thing and do it well” (that predates systemd), look no further than emacs.
Most of the complexity comes from trying to wrangle uncooperative, poorly written processes. For example, if process descriptors had existed early enough--they came to Linux long after systemd--the ecosystem would have been more sane and systemd and alternatives could have had a more narrow focus.
Linux is now a corporate Unix. Many features exist to support tooling around impenetrable services and applications that can't be modified to behave better. This type of value-add is the bread-and-butter of commercial products and services. But by solving problems in the wrong place you're just adding cruft atop cruft, which hastens bitrot. Starting fresh with saner and thinner applications is how Linux won the Unix wars, but now the ecosystem is recapitulating the same sins.
I've taken to saying Donald Knuth was wrong, premature optimization isn't the root of all evil.
Dependencies are.
Part of that is reading bits and pieces of what Nancy Leveson had to say about the subject. Subsystems even when working to spec can produce spectacular failures.
Man learns how to split code file in two. Man thinks world ending. Man not know up from down, hot from cold. All code: single file! Single file! Single file! Shell is HERESY! libc is HERESY! A user/kernelspace divide is HERESY! Sound abstractions only useful abstractions.
