We recently wrote about moving away from OVMF (~1M lines of C) to very minimal and hyperspecific firmware (300 lines of assembly)[1] for our specific confidential VM machine targets, and the idea that "popular" does not automatically mean "secure". You can point an LLM at any large codebase and it will find vulnerabilities, so "patch the planet" isn't very scalable. You can instead just write hyperspecific, small codebases and throw all the security practices at it - like LLMs (economical if it's small), fuzzing, formal methods etc.
I'm not sure we have been living the dream with shitty desktop web apps running in a full browser each taking several gigs of ram for playing some music or chatting with coworkers and friends. Electron and its likes are the scourge of software world.
I'm happy if LLMs and the semiconductor shortage will create a renaissance of native applications.
The core of the problem is a profit incentive and an economy based on greed. Our society is designed to extract value, not to offer the best products/services to the general population.
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.
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.
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.
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.
I feel like I was reading this from Marcus Ranum in 2005 in the famous article "Six dumbest ideas in computer security"[1] where he wrote about just running a custom webserver that accepts only correctly specified requests, instead of Apache and a filter set of bad-request-blockers and a default-permit firewall and etc.
That article makes good re-reading in the "Penetrate and Patch" section now, in the days of AI exploits popping up faster and faster.
"Popular" usually means that supporting many use cases. Many use cases means a lot of code. Probably means increased complexity. Tailored hyperspecific firmware is much more usable now and maybe you can even formally verify it.
I really like this idea of 300 lines (asm) vs ~1M lines (C) which was possible by really understanding what you are doing and limiting to the core feature you need. In this case you had 'the luxury' of this being low level code. What I fear for is all (application) the code that runs on top of frameworks/run-times/interpreters (in reference to the recent PHP drama). We can harden our application code as much as we like, but if the underlying code is not safe we have an issue - this combined with you remark on attackers being in the advantage versus defenders. At this time the only way that I see to protect this is by using some kind of (virtual) private network. What are your ideas on this?
This is one of my biggest gripes with systemd. Millions of lines of code. Immense complexity. Constant churn. Endless config changes(leading to outdated and potentially dangerous configs).
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.
I do not believe that it is possible for SysVInit itself to have any problems on laptops, because it does nothing that is hardware specific.
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.
But that's not quite the the right comparison, is it?
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.
But is the actual architecture of systemd giving simple, securable, reviewable boundaries? This is a codebase that runs in stages of inherent privelege and very low levels in many linux systems.
Yes, systemd is not one piece of software, it’s a collection of software, like GNU. The components aren’t just modules or something, they’re actually different programs altogether.
When people say systemd they really mean systemd-init, which is one piece of software. Not systemd-resolved, which is another.
Sysvinit is not 1000 lines if you add all the scripts you have to write to get feature parity with systemd. And now you have written that in the worst programming language ever created, bash, that is basically impossible to not be chock full of errors.
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".
Even daemontools (0.76-8.1 Debian) is 3771 lines of C, much more than 1000. Sysvinit is much more code than daemontools; sysvinit 3.06 is 8407 lines of C and 3595 lines of sh, according to David A. Wheeler's 'SLOCCount'. systemd 252.39 is 549427 lines of C, 26257 lines of Python, 18735 lines of sh, etc., not even counting its dozen or so dependencies.
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.
Sysvinit systems don't actually use sysvinit though, they just use sysvinit to kick off a complicated set of shell scripts on boot. The real boot code is in the shell scripts and the shell.
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.
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.
"""
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.
"""
People didn’t seem to believe me when I said that hardware engineers have a better time than software engineers.
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.
Hardware is not starting from scratch every time. You might think that if you've never worked with hardware, but there are plenty of SDKs out there that support 300 device types from the same extended family with different combinations of ifdefs.
>You can point an LLM at any large codebase and it will find vulnerabilities, so "patch the planet" isn't very scalable.
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.
The solution needs to be convenient, in practice that trumps security every time. If i need to run my existing apps in Linux VM under seL4, others, fully featured hypervisors will look more enticing.
You cannot trust compiler generated machine code and/or significantly sized runtimes. Some simple binary specifications with some assembly implementations (could be on several ISAs, x86_64, RISC-V, etc).
BIOS is massive. It implements a ton of interfaces that nobody cares about any more but they have to be there for compatibility, so vendors just shove in some code modules someone else wrote and hope for the best. Nobody writes their BIOS from scratch because it wouldn't run something and someone would certainly complain, and there's no benefit to it. And to top it off you've got this weird execution environment that nobody has the right toolchains for unless you buy them.
[1] https://tinfoil.sh/blog/2026-10-25-less-is-more