From Reddit I learn that a new generation of LLM bots is getting really really good at finding exploitable vulnerabilities in large C codebases, and making exploits for them.
Good.
Maybe it will result in the destruction of the entire C-based software industry before the LLM industry self-immolates. Slight snag: it may take human civilisation with it.
I am vaguely working towards some kind of overall Liam's Theory of Software thing in some of my recent Reg articles, like the "Starting Over" series about an Optane-based pure-object-storage-no-files OS, based on FOSDEM talks.
https://archive.fosdem.org/2018/schedule/event/alternative_histories/
https://archive.fosdem.org/2021/schedule/event/new_type_of_computer/
https://archive.fosdem.org/2024/schedule/event/fosdem-2024-3095-one-way-forward-finding-a-path-to-what-comes-after-unix/
... but it's not easy. Obviously the problem space is vast. That's one. Secondly, it'd help if I could find a way to do it iteratively. It's a big big and nebulous for me to grapple with while being a nearly-60-year-old-dad in an isolated country with nobody to bounce ideas off in person.
The other recent one that's relevant is this:
https://www.theregister.com/2026/02/08/waves_of_tech_bs/
Sketchy ideas as relevant here:
- OSes are hard. (We all know this, right?)
- Therefore you need to keep it simple. I mean you need to be insanely radically obsessive about extreme simplicity.
- Ken Thompson realised this very early on. He merits more respect.
- Dennis Ritchie saw the signs and jumped on board very early. He, I fear, gets more than he deserved.
- They worked out...
- We need a tiny focused core OS. That's Unix v0 to v3.
- We need something tiny and simple to make it portable. That's C.
That got us to Unix v4, just rediscovered.
Unix was a good idea, but just one good idea in a space of good ideas. Key point:
- It is not the alpha and omega. There are others. This is vital to remember. Much of the world knows nothing but Unix and thinks it's (insert christian metaphor about one truth here).
Unix grew to v9 or v10 -- can't remember, not well, don't want to go do a ton of research -- and several times industry took a snapshot and run, not realising it was unfinished.
Somewhere around 5-6-7 -- it gets confused -- we get everything that grew into the BSDs, System III, 4, V, all commercial Unixes, and then, a copy of a copy, Linux.
They are copies of an obsolete design, built for an obsolete type of computer nobody has any more. Copies of copies of copies of something obsolete.
- Den & Ken went on to realise: "Hey, we don't have minicomputers, we have networked workstations."
The result was Plan 9.
Unix, but grown up. Much simpler, much cleaner, conceptually much harder on the fakers pretending to Know Computers. (I am one too.)
Parenthetical excerpt:
Forget terminals. Forget the terminal existed. Terminals are bad. Stop being obsessed with terminals. It is not about terminals.
Network at the core. Containers at the core. Everything is a container all the time. All namespaces (files, processes, PIDs, network addresses): they are all virtual. They must be. If your design does not allow that, throw it out.
Things that don't fit well, like legacy 20th century stuff like Linux, you stick in a VM and you don't emulate any hardware. Virtual drives for VMs? Stupid. Throw them out. Filesytem in a file on a filesystem? What are you, retarded? No!
Cut down Linux so the only hardware it can talk to are virtual network sockets, with the filesystem over 9p, display over X11, and run microVMs on demand for every big fat old Linux app you need.
I don't run Plan 9, because sadly, I need Firefox and Thunderbird and Ferdium and a bunch of bloated stuff like that, and they are to avoid SaaS and stuff.
By 2000 the entire FOSS Unix world had Linux and Plan 9 and VMs and Jails and it should have realised, hey, crap, the baseline has moved, we should move.
By 2006 or so, the baseline moved more: hardware virtualisation, lots of cores, 64-bit so lots of RAM.
By 15 years or so we should have had a modern 9front with integrated microVMs for those bloated GUI apps we all need.
Linux folks get Linux microVMs. xBSD folks get xBSD VMs for their native apps.
- But Den & Ken didn't stop there.
Plan 9 was Unix done right, but in C. They tried Aleph but couldn't make it fly.
Snag: you compile to native binary code, then your process can't migrate around the cluster.
You know how all Arm boxes have bigLITTLE cores? x86 is getting on board? Well do it right and your little efficiency cores are Arms and the big fat performance cores are x86 and your binaries can't see the difference.
Next they did Inferno. Plan 9 with a better UI and CPU independence. Embed a very fast VM in the kernels, target that for everything not performance critical.
Great idea, but premature obsession with phones didn't help -- commercial, gotta find a market! -- and Java killed it.
Half-assed Linux misunderstandings: eBPF, WASM. They grope in the direction but are in the dark and don't know there is a road.
The real lesson: the people who invented C realised it was a profoundly flawed plan and gave it up.
What to learn: well, Rust is finally learning it but if you include the toolchain it's 1000x bigger and even the fans say it's complicated. The way to sanity is to make it smaller and simpler. They did the reverse.
Oberon is smaller and simpler than C and it's much more capable.
- Inferno flopped. The team dispersed. The people that wrote Unix could not find a place in the Unix industry. This tells you how totally fscked the Unix industry is.
Some of the Inferno folks landed at Google. There they did Go.
I don't know much detail about this stuff but I suspect from the history that much of what Go does, it does right, and Rust probably does wrong.
But the latest facet of the Unix congenital insanity is "Go bad Rust good".
Oberon is just an example. No it's not a mistake that the OS and the language have the same name. That's like saying the problem with wheels is that they're round. The machine is flawed -- it keeps rolling away!
The core FOSS OS should be something that a smart kid can understand, top to bottom, read and follow every line. But it should also be so easy and colourful and pretty and fun that they'd want to.
Let's make a better modern 64-bit Oberon with elements of Go. Let's build a modern Inferno in it. Let's equip it with microVMs so all the legacy apps we all love, the broken bad ideas we all need, like the WWW and so on, can run on it. But if it's built in C or Rust, it's dangerous toxic waste and should be kept in an airtight box until it suffocates. We can make it work in the meantime though.
Take all the existing billion-line OSes and burn them to the ground. If aside from human language translation the only thing of lasting value to come from LLMs is destroying the C-based software industry, I'll buy that.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
I think there are many.
Some examples:
* The fastest code is the code you don't run.
Smaller = faster, and we all want faster. Moore's law is over, Dennard scaling isn't affordable any more, smaller feature sizes are getting absurdly difficult and therefore expensive to fab. So if we want our computers to keep getting faster as we've got used to over the last 40-50 years then the only way to keep delivering that will be to start ruthlessly optimising, shrinking, finding more efficient ways to implement what we've got used to.
Smaller systems are better for performance.
* The smaller the code, the less there is to go wrong.
Smaller doesn't just mean faster, it should mean simpler and cleaner too. Less to go wrong. Easier to debug. Wrappers and VMs and bytecodes and runtimes are bad: they make life easier but they are less efficient and make issues harder to troubleshoot. Part of the Unix philosophy is to embed the KISS principle.
So that's performance and troubleshooting. We aren't done.
* The less you run, the smaller the attack surface.
Smaller code and less code means fewer APIs, fewer interfaces, less points of failure. Look at djb's decades-long policy of offering rewards to people who find holes in qmail or djbdns. Look at OpenBSD. We all need better more secure code. Smaller simpler systems built from fewer layers means more security, less attack surface, less to audit.
Higher performance, and easier troubleshooting, and better security. There's 3 reasons.
Practical examples...
The Atom editor spawned an entire class of app: Electron apps, Javascript on Node, bundled with Chromium. Slack, Discord, VSCode: there are multiple apps used by tens to hundreds of millions of people now. Look at how vast they are. Balena Etcher is a, what, nearly 100 MB download to write an image to USB? Native apps like Rufus do it in a few megabytes. Smaller ones like USBimager do it in hundreds of kilobytes. A dd command in under 100 bytes.
Now some of the people behind Atom wrote Zed.
It's 10% of the size and 10x the speed, in part because it's a native Rust app.
The COSMIC desktop looks like GNOME, works like GNOME Shell, but it's smaller and faster and more customisable because it's native Rust code.
GNOME Shell is Javascript running on an embedded copy of Mozilla's Javascript runtime.
Just like dotcoms wanted to dis-intermediate business, remove middlemen and distributors for faster sales, we could use disintermediation in our software. Fewer runtimes, better smarter compiled languages so we can trap more errors and have faster and safer compiled native code.
Smaller, simpler, cleaner, fewer layers, less abstractions: these are all goods things which are desirable.
Dennis Ritchie and Ken Thompson knew this. That's why Research Unix evolved into Plan 9, which puts way more stuff through the filesystem to remove whole types of API. Everything's in a container all the time, the filesystem abstracts the network and the GUI and more. Under 10% of the syscalls of Linux, the kernel is 5MB of source, and yet it has much of Kubernetes in there.
Then they went further, replaced C too, made a simpler safer language, embedded its runtime right into the kernel, and made binaries CPU-independent, and turned the entire network-aware OS into a runtime to compete with the JVM, so it could run as a browser plugin as well as a bare-metal OS. Now we have ubiquitous virtualisation so lean into it: separate domains. If your user-facing OS only runs in a VM then it doesn't need a filesystem or hardware drivers, because it won't see hardware, only virtualised facilities, so rip all that stuff out. Your container host doesn't need to have a console or manage disks.
This is what we should be doing. This is what we need to do. Hack away at the code complexity. Don't add functionality, remove it. Simplify it. Enforce standards by putting them in the kernel and removing dozens of overlapping implementations. Make codebases that are smaller and readable by humans.
Leave the vast bloated stuff to commercial companies and proprietary software where nobody gets to read it except LLM bots anyway.