The unix philosophy prevails!
You might want to remind yourself what caused the November 2025 Cloudflare outage!
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 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.
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 never said it was. They think it is, though, and fight cash payments tooth and nail. People don't vote in their economic self-interest when it involves new and unusual policies that they perceive as an attack. There are a lot more of them voting than there are billionaires, and they contribute quite a bit to efforts to keep things the way they are. I think breaking the pact six figure earners have with people making much more is crucial to restructuring the economy to work for people who aren't elite wealth-holders.
>It isn't about the source of the money. Converting those things to a UBI would cost less money to give people more money
We're talking about two different things. You want benefit reform. I want benefit reform, and forced distribution of productivity gains to labor, and heavy structural impediments to outsize personal wealth. You say "unintended consequences" when you I think you mean "undesirable consequences", but the funny thing is that they're both intended and desirable. Let's go back to an exec's lifestyle being tied to his job because he can't extract a huge paycheck without being taxed heavily. Please, take your money and inflate a foreign economy instead of spending it to buy elections here (if you manage to get it past the IRS).
Sure you did:
> 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.
The thing about a UBI is that it works regardless of what the amount is, up to any reasonable threshold. If it's small it doesn't do as much but it still does better than the same amount in some other benefits. You can only mess it up by making it excessively large, e.g. you can't do a $100k/year UBI because you'd need to collect ~$34 trillion in tax revenue from a ~$32 trillion GDP. Everything other than that is a trade off which is basically asking the question of how redistributive you want to be.
The amount of redistributive we are right now isn't zero, so converting that existing budget to be a UBI instead is "free" -- it's a net positive to essentially everyone -- no reduction in prospects or bonuses required.
But we can't even manage to do that.
And we could even get a "real" UBI without having oppressive tax rates -- $15,000 for every US citizen comes from a <16% universal tax rate, i.e. a flat tax of <16% of GDP. That's the number with no other government programs, but it's also something that replaces most of them.
> You say "unintended consequences" when you I think you mean "undesirable consequences", but the funny thing is that they're both intended and desirable.
I mean unintended as in you won't like them.
There are a lot of things that it's hard to tax because they're hard to value. How much is it worth to have a job that lets you play with the company's toys, or choose who they hire, or who gets their contracts? How much is a piece of "intellectual property" worth? How about a contract with an unspecified probability of having a large payout in the future? Things like that can all be used to transfer value at a reduced amount of tax, but they bring inefficiency and corruption. Misallocation of resources, nepotism and cronyism, bureaucratic empire building, reduced liquidity, etc. The higher the tax rate you use, the more incentive there is to do these things in order to avoid it.
If you subject people to very different tax rates then they can be arbitraged. Instead of Bob in the highest tax bracket making $X, a dozen family members in lower tax brackets get "hired" to be paid $X/12 so the family gets the same money without paying the higher rate, and now we're incentivizing nepotism and cronyism again.
More than 90% of new businesses fail. That means the remaining <10% need to have significantly better returns for the founders than what you get by working a corporate job or nobody would do it, and if nobody starts new companies then markets consolidate as existing companies fail or buy each other, and the more markets consolidate the more they screw consumers/workers and the more influence they have over the government.
Tax rates have a strong effect on where companies build things. If you invest a million dollars in something that will produce a 15% annual return and there is a 20% tax rate, that's a 12% return after tax. If you make the tax rate 80%, it's a 3% return after tax. Meanwhile if you build it in some other country you get a 10% return after tax, and they're going to do the thing that has the highest after-tax return, so you raise the tax rate and the factory is gone, along with the jobs.
> Let's go back to an exec's lifestyle being tied to his job because he can't extract a huge paycheck without being taxed heavily.
Wait, what? That's basically setting it up so that your boss owns you, and how to set up the economy so that it runs even more on cronyism and favors because there is no tax on the implicit value of a back room deal.
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.
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.
Trying to keep code small could backfire by ballooning dependency on dependencies to do more of the work.
中国特色. And an even larger gap vis optimized-for-pharma US IP config (Industrial Policy).
I'm happy if LLMs and the semiconductor shortage will create a renaissance of native applications.
Systemic problems everywhere, Woody!
But would you give up packages, central repositories, downloads that Just Work without patching, public version control systems, open-source software, ... , and much of what they enabled?
"Civilization advances by extending the number of important operations which we can perform without thinking about them." - Alfred North Whitehead, An Introduction to Mathematics (1911)
Getting packed into 2026 airline seats can be a "miserable experience". But that taken-for-granted human flight... a cramped seat in the effin clouds... is what? A century or two of focused effort, eventually massive effort, building that dream? Another century pursuing the dream of compact mechanical power? 10 millennia on metallurgy? So one's flight may have sucked, and there are many downsides to aviation existing... but living the dream of human flight, isn't living in a dream of no problems and effortless happily ever afters.
But yes, I'm so looking forward to agentic full-stack-ish rewrites, slashing through decades of accumulated stagnant cruft. Laptop-like angular-resolution HMDs are this-year-ish (though expensive, not mass market). And doing such rewrites by hand is a pain. Someone reports a Claude one-shot which installed a PICO Space Pro dev env, created a simple app, uploaded the apk to the headset, and responded with "ready for you to test"... and it was. Wild ride incoming. Though that's perhaps not a minimalist/efficient renaissance you had in mind? Still, in the midst of upset, there's opportunity to pursue visions which might not be viable in more settled times.
Then why do you need Automatic Updates ? If it works, don't fix it. /s
Later on, you'd hope the author created a `make.yourunix` or `INSTALL.yourunix` or README section for your unix, and that was nice. Then being able to simply say `./configure; make` and have it mostly just work... magic wonderful. Then basically "$ gimme name-of-the-thing", first for Perl, and then more and more others, eventually even python (but not C) - next level. And now we're at "Minion, build me an X", with an "and install whatever it is we need" implicit, quiet. That's, just, wow.
So from Objective-C and proto-C++ C-with-types, created hoping software might someday, maybe, be reused like hardware components... to now? So very living that dream.
So the solutions need to be structural.
e.g. relative to a monolith kernel, seL4 is small, has no known bugs (AI can try, but so far crickets) and is the only piece that needs to run privileged.
Everything running under seL4 benefits from the guarantees seL4 provides.
seL4 is the choice that allows for a safe system to be built. Any other choice of kernel currently available does lack the mechanisms and guarantees.
>Of course, you’d want to try ../… Yes, it does let you escape the temporary folder...
This is absolute bull on seL4 by construction. "sandboxes" that prevent access that the OS otherwise grants. In seL4, this component would not need a sandbox in the first place, because it would never have a capability to some VFS path it doesn't need to access.
This sort of escape relies on ambient security, which is the security model of UNIX and Windows NT. Access is granted by default and then restricted, rather than simply not granted. A broken security model.
And, unlike a demonstrated shitty browser sandbox, seL4 formally guarantees isolation. Capabilities cannot be forged.
Sysvinit, it's a 1000 lines of code, maybe a bit more. It's a rock compared to systemd.
So many devs have zero issue with large codebases. Some substitute "small" with "perceived small because I pull in 10M lines of node and composer packages".
And of course the new goal is to bring "trusted computing", eg Microsoft style EEE to Linux with Lennart's now corporate gig.
But it is a different world. So, what can you do?
Complete opposite of my experience. I've never had a single problem with SystemD - it's one of the most surprisingly reliable parts of Linux IMO.
In contrast SysVInit worked ok on servers and sort of on desktops, but on laptops forget it.
Since 2005, for more than 2 decades, I have used on all my laptops only Linux with Gentoo and SysVInit and I have never encountered any problem.
Perhaps you mean that your particular Linux distribution had some startup shell scripts (which are not a part of SysVinit, they are only launched by SysVInit when the run level is changed) that were buggy on laptops. Buggy initialization shell scripts are not unusual, but such scripts are normally small and any bugs are relatively easy to find and fix, unlike with the bugs of SystemD.
While you did not had any single problem with SystemD, when I first tried SystemD (with Arch Linux; that was many years ago and that specific bug must have been fixed some time later, but nonetheless it convinced me that the developers of SystemD are incompetent), SystemD exhibited the most stupid bug that I have ever seen in a computer, i.e. the shutdown of the computer was very slow in comparison with SysVInit and moreover it sometimes failed, which is a thing that I have never seen in a computer elsewhere.
The reason for failure was that SystemD, instead of just sending signals to all processes like SysVInit, it used some inter-process messaging through DBus. At that time, at least on my computer, there was some kind of race condition between the concurrent processes that were terminated and some times DBus died before some other process that tried to communicate through it and then the SystemD shutdown sequence remained stuck and it never completed.
I consider such a bug much worse than a bug caused by carelessness, like a buffer overflow, because it demonstrated an erroneous design of the architecture of the system.
You can't really separate the buggy SysVinit shell scripts from SysVinit itself. That's classic "guns don't kill people, people kill people".
I prefer to not get shot.
Systemd doesn't just replace 1000 lines of Sysvinit. Those "millions of lines" also replace the thousands of hundred-line poorly-vetted Bash scripts you need, plus your syslog daemon, plus dozens of "fork, setuid, chroot" variants, plus your cron daemon. And that's before we get into things not directly related to service management, like logind, hostnamed, networkd, resolved, timesyncd, tmpfiles, udevd, and so on.
Systemd is an umbrella project. Look at each individual component in isolation, and the vast majority of the time the thing it replaces is significantly more complex and fragile. Systemd was adopted by most of the Linux ecosystem because it was a significant improvement over the status quo, there is no need to invent conspiracy theories here.
When people say systemd they really mean systemd-init, which is one piece of software. Not systemd-resolved, which is another.
Most distributions only use some of them, and the “some” set is different from distro to distro. Many distros swap parts out. And some distros only use systemd-resolved.
Systemd is, legitimately, well divided. Most of the complaints against systemd are from people who know basically nothing about systemd.
How many pieces of software is nginx or Apache, where every feature is an optional plugin?
E.g. explorer.exe is not replaceable on windows so the display server and that is one software. (The kernel is NOT though, because it can surely run in a headless way). It's not that hard of a concept..
You can absolutely run systemd-init without systemd-journald, and some distros do.
systemd-init has nothing to do with network resolution.
systemd-journald is a nicer example though.
Frankly the amount of crying I have seen about systemd... and it's basically the most stable part of my Linux installs. Even though I really have seen everything else "catch on fire".
So you're correct that sysvinit is more than an order of magnitude smaller and simpler than systemd, and having all that code in your TCB is an express ticket to the bug-of-the-month club. But you're still underestimating sysvinit by an order of magnitude.
Bringing Treacherous Computing to Linux is, of course, generally a bad thing, and it's not a good idea to have the lead maintainer of the central component of your operating system employed by a notoriously unethical company whose main product is a competing operating system.
Usually your inittab only includes gettys, shutdown/reboot, and launching rc. That's the only things sysvinit does and it's not even the best way to do them.
A new service manager for Linux distributions. The last piece of a full alternative to systemd. https://skarnet.com/projects/service-manager.html. This is a proof of concept, it does not yet have its final form.
"Now"? It's always been that way. Most developers just didn't want to admit it because it meant more work and that their past existing work was shite.
And that is why it is now more usable. More affordable.
Sounds like it wasn't very usable
That article makes good re-reading in the "Penetrate and Patch" section now, in the days of AI exploits popping up faster and faster.
[1] https://www.ranum.com/security/computer_security/editorials/...
The blog-post is written by AI. I am more than interested to hear a human talk about it but AI generated blog post removes that interest.
The article that I am talking about which is generated by AI is this one: https://tinfoil.sh/blog/2026-10-25-less-is-more
Hope this clears up the confusion!
I then tested it on pangram and gptzero and pangram does say 97% human and only 3% AI and GPTzero says 100% human
For some reason, my AI spidey sense had activated and I used the new AI text detector and it had a false positive maybe.
But I was wrong and since this is written by human, now I will read it :-D
An interesting observation that I have made here is the amount of stickiness that Pangram and others can have. I tried a new AI text detector and it failed and because of it I falsely accused someone of AI writing. Now I would prefer not to use that. So AI text detectors have this sort of effect where they have to be really effective and false positives/negatives can change a lot of things/interactions.
My apologies though once again that I said that it was AI generated when it wasn't!
We need a clean start. A lot of layers can and should be rebuilt, and even if you do it without reducing functionality, I feel like in a lot of cases like we’ll be able to cut down the code significantly.
When I explain software bloat to non technical people, I say imagine you built a 10 story building, but every few years it was a story at a time with the renovations along the way.
Like there’s gonna be a lot of inefficiencies. Yea I know we refactor. But doing a clean slate rebuild. Knowing exactly what you need based on real world experience, it should work to really streamline stuff.
See the Versailles Wedding Hall collapse in Israel, 2001: https://en.wikipedia.org/wiki/Versailles_wedding_hall_disast...
""" An initial inquiry blamed the collapse on the Pal-Kal method of constructing light-weight coffered concrete floor systems which was banned shortly after …
Late in the construction process … a third storey was added. … the structure supporting the new third storey was subjected to much greater loading than was originally anticipated. … somewhat mitigated by the construction of partitions on the floor below …
A few weeks before the collapse, the wedding hall owners decided to remove the partitions. … the floor above began to sag several centimetres. The owners viewed the sagging floor primarily as a cosmetic problem, and attempted to level it with additional grout and fill … a new and significant dead load at the weakened area. """
But think about it: they can and will “start from scratch” whenever they see the need to do so, while software engineers have been forced to cope with bad decisions from the 80s because the cost of starting fresh was simply unaffordable for most projects.
I guess this is what they are doing.
So, just normal BIOS boot?