The problem that Poeterring tried to address with things like systemd is very obvious when you fire up emacs.

There's so, so much old code. There's very few tests because it was all written hacker style. Because of this "hackable to the core" philosophy these codebases are piles of unmaintainable tech debt. Someone had an itch to scratch, wrote code to scratch it, then submitted a diff for merging. But nobody took a step back and said: "Wait! We need to rearchitect <this> to accommodate this new functionality." This is understandable because GNU projects are volunteer projects and it's a lot more fun to submit a diff than do a refactor to get a small change in.

Old Unix init systems, much like Emacs, were just piles and piles of kludges that kept things going. The insight that Poeterring had was that if you reduce the hacking surface to mere configuration then you only need to maintain the configuration layer and not a huge kaleidoscope of functionality.

The modern Unix layer of having opinionated, config-driven tools talk over pipes won out in this environment because you only really need to maintain the contract at the pipes (even if you are just outputting terminal escape codes.) Beyond that tools can be composed, but the surface area of each tool is small. This is why vim is so much more commonly used and easily maintained than emacs.

(This is distinct from the "Unix philosophy" stuff that was popular before where folks wrote small, composable tools instead of larger, monolithic, config driven ones.)

A more modern approach of "hackable to the core" I feel would be to standardize around a sturdy, opinionated, well maintained core and then to allow extensibility around this core. Helix is exploring this (using Scheme as its extensibility layer.) But I think Helix and other projects (maybe Lem?) need to prove this approach out before it can come close to challenging the modern configuration-driven ecosystem of tools.

(I say this as a user of emacs and Zed by the way and someone who recently started hacking on Lem, so this comes from some experience.)

> It eliminates a huge swath of potential long-term contributors who know C well and don't want to change

I don't think that swath is as huge as you think it is in 2025.

We were saying the same stuff during the Golang heydays ~8-9 years ago, and the C experts were already pretty fucking MIA.

The Linux and systemd projects are both suffering from a lack of new blood interested in writing plain old C, and the old guard is aging out. Linux is embracing Rust, which should help. I imagine systemd will do the same thing once a Rust toolchain is required to build the average distro kernel.

> It eliminates a huge swath of potential long-term contributors who know C well and don't want to change,

that pretty much described the current hurd dev community and its dying. I wouldn't advocate a full RIIR for most things but I think its a solid hail Mary to maybe make hurd relevant. The alternative is its going to be dead in a few years when the contributors all age out to spend time with their grandkids.

OTOH, I have zero interest in contributing to a C kernel. Even the experts can't write it without messing up with C's vastly many footguns. I'm not a C expert. What chance to I have to add a new kernel feature that doesn't literally destroy my system? It's too intimidating in the sheer amount of risky "surface area" I have to perfectly manage or else face dire consequences.

Nah. I'd much rather use a newer language that's explicitly designed for writing the same sorts of things that C is but with a teensy portion of the footguns.

I'm not saying C is bad. I am saying that if the Linux kernel devs still write buggy code sometimes — not because of logic errors or other design-level mistakes, but because of some goofy memory issue or accidentally wandering off into the wilderness of UB — then I guarantee I'm going to screw it up.

If it were in Rust or Zig or whatever, I'd feel like I had at least a fighting chance of making a tweak that didn't immediately format my hard drive and kick my cat.

A lot of those I think are > 20yrs now, so not necessarily "new" projects

> including Linux's entire coreutils

Ah yes I think I've heard of this GNU/Linux thing. To see if they will come ahead of Berkeley System Distribution. /s

Guix as well. It's very good.

I've never had success getting Jami working FWIW.