I had a friend who got involved with Hurd many years back, and I asked him why he thought Hurd wasn't going to be a thing for non-hobbyists. He shared this (re-shared with permission but anonymously as he's still somewhat involved in GNU projects), which is just one guy's perspective of course. Would love to hear from others if this echoes their experiences.

> GNU is full of brilliant people who can write great code, but there are a few issues that I don't see fixing: Rampant disagreement and individuals who like to work solo. This can be good sometimes, but for a project with that scope it just isn't possible. The group is also aging and isn't getting new blood. This can be good because people have more free time, but it also traps us in old familiar/comfortable patterns that make onboarding younger contributors even more difficult than it already is. The philosophy is also quite rigid. For good reasons I think as more "permissive" licenses have been used to abuse users extensively, but the limitations do come up quite a bit, mainly with adoption. I think too many people are just scarred still from an earlier world where proprietary was often the only real alternative, and change is hard.

▲

goku12 4 days ago | parent | next [-]

> The group is also aging and isn't getting new blood.

This is very sad, because the GNU project pioneered a way of software design that's very different from anything we see on proprietary platforms, or even common Linux/BSD applications for that matter. This is best exemplified by Emacs - hackable to the core, with more than enough documentation and context help baked in to help you do just that. You can see the same philosophy at play in the Guix OS, the Shepherd (init), GNU Poke (semantics-aware binary editor) and many many other GNU software. It can be used easily by anyone, but it's absolute heaven for those who like to poke around (not a pun) the system. It nudges normal users towards becoming system hackers. The difference between GNU software and corporate-sponsored components (like systemd, avahi, gnome, policykit, PAM, Chrome, Firefox, etc) is stark. I have heard similar things about NetBSD and OpenBSD to a lesser extend, but I'm yet to give it a good try. The only other alternative I've seen is the suckless suite of software where the configuration is done in the source code itself, before it's compiled. But it can be slightly daunting even for power users. With the loss of that knowledge and philosophy, an entire generation will grow up without ever knowing a different way of computing that treats you as something more than just a consumer to be squeezed for every last penny, and the true power and potential of general purpose computing.

	▲	Karrot_Kream 3 days ago \| parent [-]
		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.)

▲

hitekker 4 days ago | parent | prev [-]

Thanks for sharing. It sounds like they're playing house. Going through the motions but unwilling to sacrifice for their supposed goal.