Hacker News

points by FrasiertheLion 2 days ago | 0 comments

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.

[1] https://tinfoil.sh/blog/2026-10-25-less-is-more

[–] Maxion 2 days ago

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.

[–] dspillett 1 day ago

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.

[–] kragen 1 day ago

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.

[–] ses1984 1 day ago

When op talks of keeping code small I’m pretty sure they’re talking about all code including dependencies.

[–] apimade 2 days ago

Do one thing, and do it well.

The unix philosophy prevails!

[–] pjmlp 1 day ago

Ah the famous book quote, never seen in practice on real UNIX systems.

[–] shellwizard 2 days ago

Until you link against xz

[–] yjftsjthsd-h 1 day ago

I feel quite comfortable asserting that anything involving systemd is no longer associated with the Unix philosophy

[–] phs318u 1 day ago

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.

[–] some_furry 1 day ago

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.

[–] 59percentmore 1 day ago

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.

[–] AnthonyMouse 1 day ago

> 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.

[–] squidmaster 2 days ago

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.

[–] port11 1 day ago

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.

[–] vkou 1 day ago

A lean interface needs to have incredibly well-specified behaviour to not be a pain in the ass to work with.

[–] cowlevel 1 day ago

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.

[–] kps 1 day ago

GNU reimplementations showed up late enough not to care about running in a 64K address space.

[–] robinsonb5 1 day ago

> 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!

[–] Gibbon1 2 days ago

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.

[–] StilesCrisis 1 day ago

When Knuth wrote that, I don't think dependencies as we think of them today existed. Libraries were few and solved specialized, difficult problems.

[–] throwaway27448 2 days ago

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.

[–] yangm97 1 day ago

This is the year of microkernels.

[–] nostrademons 1 day ago

Unikernels and beyond, really. The future is small, single-purpose programs running on virtualized bare metal with minimal library dependencies.

[–] vitaflo 1 day ago

Screw dependencies, write your own. Software is cheap and fast now. No need to depend on someone else’s code as a possible attack vector.

[–] mncharity 1 day ago

70's software is closed-source bespoke reimplementation; 80's Dream of reusable software components; 90's Building the Dream; 00's Living the Dream; 10's Everything is amazing but; 20's transition to...; 30's what??? Open-{source, reference implementation, tests, specs, design docs, gist, ...?} bespoke reimplementation?

中国特色. And an even larger gap vis optimized-for-pharma US IP config (Industrial Policy).

[–] dal 1 day ago

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.

[–] mncharity 1 day ago

> I'm not sure we have been living the dream [of software reuse]

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.

[–] hulitu 3 hours ago

> downloads that Just Work without patching

Then why do you need Automatic Updates ? If it works, don't fix it. /s

[–] Grimeton 1 day ago

Javascript and people doing things with it that they shouldn't is at the core of the problem.

[–] cowlevel 1 day ago

If it wasn't JavaScript it would be something else. What's the slowest machine on this list? https://danluu.com/input-lag/

[–] mncharity 1 day ago

And there can be fast paths. An electron app, watching evdev directly, full-screen under a generic X11 window manager, running 60 or 120 Hz or more, on a fast display or ignoring vsync, can be... sprightly.

[–] viklove 1 day ago

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.

[–] Grimeton 1 day ago

Ah yes.

Systemic problems everywhere, Woody!

[–] snvzz 2 days ago

>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.

[–] Good4boothee 2 days ago

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.

[–] yangm97 1 day ago

Genode appears to be very convenient if you are looking into a way to run microkernels for general purpose computing.

[–] cowlevel 1 day ago

You still have to draw the rest of the owl though. A proven secure starting point is neat but it's not actually the system you want to build.

[–] snvzz 1 day ago

It is only possible to draw the rest of the safe owl if you have a safe crayon.

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.

[–] cowlevel 21 hours ago

Front page of HN today: a full exploit chain in Microsoft Edge using only logic bugs. seL4 would not have prevented this: https://news.ycombinator.com/item?id=50285319

[–] snvzz 21 hours ago

It would have prevented it. e.g.

>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.

[–] gjvr 2 days ago

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?

[–] b112 2 days ago

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.

But it is a different world. So, what can you do?

[–] kragen 1 day ago

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.

[–] gf000 1 day ago

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".

[–] crote 2 days ago

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.

[–] dv_dt 2 days ago

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.

[–] preg_match 1 day ago

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.

[–] cowlevel 1 day ago

The number of binaries installed on the system has little to do with how the software is developed - how many pieces of software is LibreOffice?

[–] preg_match 1 day ago

What matters is if they’re separate programs or not. They’re separate programs. Systemd is, like, 25 different pieces of software. It’s not 25 objects that are dynamically loaded or something. No, it’s 25 different pieces of software.

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.

[–] gf000 22 hours ago

Well, does the way spreadsheet cells are handled has any relevance to presentations? If not, then they don't increase each other's complexity budget.

systemd-init has nothing to do with network resolution.

[–] gf000 1 day ago

Well, my only gripe with it is that it's C. Otherwise it's very modular.

[–] radiator 1 day ago

> So, what can you do?

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.

[–] cowlevel 1 day ago

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.

[–] IshKebab 2 days ago

> It's a rock compared to systemd.

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.

[–] adrian_b 1 day ago

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.

[–] IshKebab 1 day ago

> Buggy initialization shell scripts are not unusual

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.

[–] edoceo 1 day ago

On Gentoo aren't you using OpenRC?

[–] nicce 2 days ago

"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.

[–] kode-targz 1 day ago

> Tailored hyperspecific firmware is much more usable now

"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.

[–] yjftsjthsd-h 1 day ago

> Most developers just didn't want to admit it because it meant more work

Sounds like it wasn't very usable

[–] nicce 1 day ago

> 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.

[–] jodrellblank 1 day ago

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.

[1] https://www.ranum.com/security/computer_security/editorials/...

[–] getcrunk 2 days ago

Yea I really like this idea.

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.

[–] jodrellblank 1 day ago

> “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”

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. """

[–] yangm97 1 day ago

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.

[–] cowlevel 1 day ago

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.

[–] Grimeton 1 day ago

Unless they work at Intel or AMD...

[–] kibwen 1 day ago

To be fair, the misery of software developers is often directly attributable to the decisions of hardware engineers.

[–] Imustaskforhelp 1 day ago

> https://tinfoil.sh/blog/2026-10-25-less-is-more

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.

[–] bananamogul 1 day ago

Dan Goodin is listed as the author on the Ars Technica article.

[–] Imustaskforhelp 1 day ago

Sorry but I wasn't talking about the Ars Technica article but the article that GP had shared that I had highligted under >

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!

[–] FrasiertheLion 1 day ago

I'm not sure why you believe this is written by AI. I can attest that it is not.

[–] Imustaskforhelp 1 day ago

My apologies, I take back what I say but I tested it on https://kouh.me/ai-text-detector because that's the only AI text detector which doesn't have some word limit. (It was recently submitted as a show HN[0])

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!

[0]: https://news.ycombinator.com/item?id=50220254

[–] sylware 2 days ago

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).

I guess this is what they are doing.

[–] ErroneousBosh 2 days ago

> to very minimal and hyperspecific firmware (300 lines of assembly)

So, just normal BIOS boot?

[–] cowlevel 1 day ago

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.