Years ago I was met with derisive laughter from everyone when I said Haiku would hit 1.0 before Hurd. I also said that Haiku would beat linux to the opensource desktop widely used by the average person who is not concerned with opensource, but I think that was mostly stirring the pot because of the reaction to my previous statement. All these years later and Haiku hitting 1.0 seems inevitable and even the idea of it becoming a widely adopted opensource OS does not seem that far fetched. I would like to see Hurd hit 1.0, but I am fairly skeptical at this point.
I suppose ChromeOS/linux beat Haiku to the punch for the opensource desktop, but I think I will stick to my guns on this one and play semantics, many in the linux/oss view ChromeOS as linux/oss in name only. A cheat but I think Haiku has earned it.
Edit: Forgot that Chomium was opensource but ChromeOS is not, so I guess I had no need to play semantics.
I think that it's important to remember that Debian Hurd is not some massive project with thousands of anonymous people behind it. Like Tribblix and Peter Tribble, Debian Hurd's driving force is someone whom you can name: Samuel Thibault.
And although there are a few others that appear on the debian-hurd mailing list from time to time, it is amply clear that this is one of those (many) projects with a core group of very few dedicated people, with very limited resources for development and testing. There is no many hands making light work, here.
This isn't Debian as you may know it for other kernels. (-:
* https://lists.debian.org/debian-hurd/2025/07/maillist.html
So, in some ways, if microkernels interest you, Debian Hurd is a place to contribute where the ground has yet to be completely trodden.
Wikipedia has a pretty good rundown [3] but I recommend booting up a VM image. It's actually quite beautiful. I love the purity of GNOME on a GNU/Hurd system with GUIX and Shepherd where the whole thing is configured in Guile[4]. There's just something very aesthetic about the combination. I wish I could use it as my daily driver.
2. https://www.gnu.org/software/shepherd/manual/shepherd.html
There's many more options[0] these days.
And now it's 64bit!?
https://fosdem.org/2025/schedule/event/fosdem-2025-5490-mach...
Still, a part of me wishes we lived in the alternative universe where Hurd had taken over the world instead of Linux. I don't know much about kernel design so I'm speaking out of my ass here, but I've always thought that the microkernel design was more elegant than the monolithic thing we ended up with. I don't know that the alternate universe would be "better", and maybe realistically a design like Hurd would never be able to take over the world like Linux, but it always seemed cooler to me.
I honestly didn't really realize that they were still working on Hurd. Does anyone here use it for anything?
HarmonyOS NEXT is the world's most widely used microkernel system, reportedly used on approximately 800 million systems.
AI is getting good enough to help with the verification process and having a hardened kernel would guard a bit better than the current strategy of using containers everywhere.
The entire hurd system is a literal metaphor for how waiting till you're perfect means you'll never be good enough.
At the risk of getting downvoted, I think hurd is cooked at this point. It certainly has some solid ideas that could live on in a modern system. They should retry rewriting it in rust (or zig) and at least have the opportunity to catch mindshare with new engineers just dabbling in systems engineering.
... also, they're still working on Hurd?
each week there are (in C, in Rust, in JS...)
What are their hardware support ?
at best they can run in a virtual machine
End of debate.
There's Genode[0]. Relative to the hurd, its design is much more advanced and it supports a range of modern microkernels including seL4.
https://www.gnu.org/software/hurd/history/port_to_another_mi...
Neal Walfield was working on a new microkernel as well: https://www.gnu.org/software/hurd/microkernel/viengoos.html
> 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.
It's an antipattern to chase whatever language is being hyped the most at the moment. And it's probably bad from a community POV to deliberately attract developers who are chasing hype.
Also I can't remember any more recent GNU projects that were successful
Like, I've read about how you can mount lots of things like filesystems and that sounds kind of neat but that also seemed like it might obscure latency and make things ridiculously slow, though it's entirely likely that I am misunderstanding how things work.
lists.gnu.org. 1800 IN A 209.51.188.17
17.0-24.188.51.209.in-addr.arpa. 1800 IN PTR lists.gnu.org.
64 bytes from 209.51.188.17: icmp_seq=1 ttl=42 time=219 ms
curl: (7) Failed to connect to 209.51.188.17 port 443 after 208 ms: Couldn't connect to server
curl: (7) Failed to connect to 209.51.188.17 port 80 after 212 ms: Couldn't connect to server
ssh hey__your_http_is_down@209.51.188.17
The authenticity of host '209.51.188.17 (209.51.188.17)' can't be established.
ED25519 key fingerprint is SHA256:fKT2Sr7vshZxNytNKcnQgXhqtDYptpayjVTa1upy46w.* https://lists.debian.org/debian-hurd/2025/08/msg00038.html
The thing with elegant systems is they usually don't succeed if the alternative is something pragmatic that has been battle tested.
I booted it on real hardware sometime in the early 2000s, and it worked but was very anticlimactic.
I do know that the Mach microkernel they based it on (also the basis for Apple's XNU kernel) is considered dated. Later microkernels are supposed to have better performance.
A lot of software fails to build on Hurd because it makes (often dangerously) false assumptions that the software really needs to think about properly. `PATH_MAX` is the most visible one, but others exist as well.
(By contrast, I have found that software that fails on one of the BSDs is often failing because the particular OS completely lacks some essential feature, or at least lacks a stable API/ABI thereto.)
It does feel a lot more user ready than a lot of alternatives. Although I did find it funny that on their last release a big milestone is that it can now compile code a little faster than half the speed of Linux. So performance is still lacking but gaining. Considering their team size compared with Linux, that is a big achievement.
While the Switch was broken early, this was due to NVIDIA's buggy boot code. The operating system itself... you could literally pwn WebKit or the Bluetooth driver, and get absolutely nowhere. SciresM famously reimplemented the kernel in an open source fashion (Mesosphere) and the secure monitor code (Exosphere), and has publicly stated they have zero possible security bugs in his eyes. That was in 2020 and there have not been any reports of kernel security bugs since.
I suspect that there is a place for elegant systems - they just have to be pragmatic in how they launch.
Start small, do a limited function, or replace an existing limited function, and grow from there.
Thing is, linux is a kernel, but its driver support and hooks into the rest of userspace makes it more than just a kernel. Harder to replace with something more elegant/better.
FTFY
Another example of microkernel-based systems you do interact with is car infotainment systems, where QNX has apparently seen a lot of use – though I think these days it’s being displaced by Linux and Android Automotive? I don’t actually know much about that industry.
It definitely would not be a trivial amount of work.
Honestly, I think the downvotes were for mentioning AI may have a role in validation. LLMs are increasingly being explored in the theorem prover space, but it's still controversial to talk of them approvingly on some HN threads.
Latency is never a problem in my experience unless you're mounting in resources from a different continent, where ssh is slow anyway. Even in those cases, the UX is closer to mosh, since rio remains local.
In general, plan 9 is fast. Compiling all of userspace and the kernel tanker just a couple minutes on my 11th gen Framework. Grepping a large repo also feels closer to ripgrep than gnu grep.
One well-known user runs his home network and automation system all as a 9grid. He even frequently shares details on his YouTube channel adventuresin9[0]. It's binge-worthy IMHO.
It's hard to convey how cohesive the whole system is. It's ridiculous how many things are reduced to trivial shell scripts, and the source code is so darn grokkable, greppable, and small that treating it as documention is actually sensible. Granted, this is almost necessary to become proficient in Plan 9 since there are so few network effects producing StackOverflow answers, blog tutorials etc.
Anyway, I hope you do end up jumping in!
[0]:https://www.youtube.com/channel/UC7qFfPYl0t8Cq7auyblZqxA
It took an afternoon to figure out how, and was basically "cat".
>I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.
I tried installing FreeBSD on a laptop years ago, which isn't really an "obscure" operating system or anything, but even that had a lot of compatibility problems with regards to drivers for wifi and GPUs, and even that would have a considerable head-start over something like Hurd if it were to try and take on the desktop world.
I played with RedoxOS a bit in a virtual machine a few years ago [1], and it seemed cool, so maybe that can be the logical successor to something like Hurd.
And then: Doing research in operating systems serves a lot of purposes. For some it's just fun. For some it's experimenting which may lead to ideas which may be incorporated into other OSs later, where eit is a lot simpler to do in a small kernel. For some it is an attempt to take over the world, few of those will, but maybe one might. At least for a small part of the world.
Stallman et. al. have promised since the late 80s that this would be the future, and at various stages promised that it will be ready for production work within the next year (or two). Like any promises made by Elon Musk, everyone in the tech industry has long since learned to ignore them. Maybe some day it'll be done, but I'm highly skeptical it has any chance of building up the momentum it needs.
Also, you do not have to support every system.
For example if they support these cheap n150 mini pcs, I am more than fine. Something common.
Macos runs fine because it works in a specific space.
It would really be a real competitor with linux in the server market.
Google is sure trying with Fuscia: https://en.wikipedia.org/wiki/Fuchsia_(operating_system)
Aren't those billions of Linux/Android instances typically running on top of an seL4 microkernel?
A problem with RedoxOS is that it is not GPLed: contributors have no assurance that they and others will be able to use software built with their contributions.
Microsoft, Apple, Google and Facebook all have plenty of money to pay engineers; they don’t need my contributions for free.
I really should properly play with it, but it always seemed to me that it has the potential to add milliseconds of cost to each operation and that could be very slow.
(It often got installed on top of “real” Unix because it was a damn good toolchain)
TeXMacs was release in the late 90's (I think) and it's pretty neat and I think has at least some user base, and I think GNU Parallel was released in the mid 2000s and I know a number of people who use that (including myself).
And then BSD could have won against Hurd anyway. Especially when corps like the permissive license and are afraid of the FSF.
I think there's some spark there.
If you mean that microkernels ping-ponging between kernel and user space can impact perf: Maybe? I'd really want to see benchmarks.
The standard tools were always sort of unergonomic on all of AIX, Sun/Solaris, DEC/Alpha, SCO, and *BSD.
I don't know but it seems people (or at least old geezers) install GNU on top of Macs these days.
Compare Sony PlayStation Network[1]
Monthly active users on PlayStation Network reached 123 million as of June 30, 2025.
Valve reported 132 million active monthly players (that is, they used Steam within the month, as opposed to being logged in at exact the same time) at the end of 2021...
This isn't scientific, but if the same ratio of active monthly to peak concurrent users held through to today, back of the napkin math would put Steam's current active monthly users at 221.5 million
FreeBSD code is also in iOS and macOS via Darwin, the Nintendo Switch, and the Microsoft Windows networking stack.
Evidently BSD is a go-to choice for consumers today, but many don't realize it, and those of us who do often do not think about it. That's because the BSD license and the companies that use it result in products that bear no resemblance to the BSD we know.
A similar situation occurred with Minix - to the extent that it's creator Andrew Tannenbaum had no idea it's install base was arguably bigger than Linux until 2017. Intel had put Minix into the Management Engine on their professional grade CPUs for years. The BSD license allowed Intel to put it everywhere without the knowledge of the wider Minix community.
In some key ways, BSD is already taking the Linux spot, however, I'd argue that BSD can't truly take the Linux spot because the GPL license makes the Linux spot what it is. I honestly can't say if this makes Linux better or worse off. The most advanced technology of our time is largely not choosing copyleft licenses, and for those who did choose it, they've taken steps to distance themselves from it[3][4][5][6].
Given all this, I think Hurd has more of a chance to be the spiritual successor to Linux (if it disappeared). The only caveat is there is zero chance for a big-tech-dominated $200M "Hurd Foundation" to arise due to Hurd's's affiliation with the Free Software Foundation. Not much of the Linux Foundation's money actually goes to Linux, so it may not matter in the grand scheme of things[7].
[0] https://wololo.net/2023/03/22/new-freebsd-vulnerabilities-co...
[1] https://www.psu.com/news/psn-hits-123-million-monthly-active...
[2] https://www.pcgamer.com/gaming-industry/steam-just-cracked-4...
[3] https://arstechnica.com/gadgets/2017/05/googles-fuchsia-smar...
[4] https://www.androidauthority.com/google-android-development-...
[5] https://www.theregister.com/2023/06/23/red_hat_centos_move/
[6] https://lwn.net/Articles/655519/
[7] https://blog.desdelinux.net/en/The-annual-report-of-the-Linu...
Yes, here it is: “Software Usability II” by Tom Davis, the “Irix bloat memo” https://www.seriss.com/people/erco/sgi-irix-bloat-document.t... . Mind you, that bloat would probably look very modest nowadays.
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.
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.
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.
Had they not existed, or BSD been obviously free and clear, Linux might have been a footnote.
I don't think even 386BSD existed when Linus started Linux.
It was too new. Linus' mail was in August; GNU only announced its new OS in May:
https://www.gnu.org/software/hurd/history/hurd-announce
I think the GNU OS didn't even have a name yet.
The second announcement was in 1993 and by then it had a name:
https://www.gnu.org/software/hurd/history/hurd-announce2
So, no, I think that, as generally accepted, he meant the entire GNU OS.
That's what I meant too - Torvalds was talking about the OS, not just the kernel. I don't understand the difference or the mistake that you're trying to highlight.