Samuel Thibault offered up a status update on the current state of GNU/Hurd from a presentation in Brussels at FOSDEM 2026. Thibault has previously shared updates on GNU Hurd from the annual FOSDEM event while this year’s was a bit more optimistic thanks to recent driver progress and more software now successfully building for Hurd.
GNU/Hurd continues to lag behind the Linux kernel and other modern platforms for hardware driver support. But driver support for Hurd has been improving thanks to NetBSD’s rump layer.
Hurd has always seemed cool from the purist viewpoint of, “Let’s prove to the world that we can do everything using a microkernel!”-- and to be frank, as a Haskell lover, it would be hypocritical for me to fault anyone for this level of purity!–but development has been plodding along for decades, with the article claiming (unless I misread it) that they are still working on things like SMP and 64-bit support.
I mean, as long as the people tinkering with this are having fun then that is all that really matters, and more power to them! However, that really seems to be the entirety of its purpose at this point, which is a shame given the lofty ambitions with which the project was launched.
still working on things like SMP
Know what has SMP? PonyOS
Yes, but they have it easy because their operating system only has one pony, whereas GNU is working with an entire hurd.
…
…
Fuck you for making me laugh…
I mean, as long as the people tinkering with this are having fun then that is all that really matters, and more power to them!
also so that we can have the inverse GNU/Linux memes.
It seems x86_64 is finished, the article cites that too:
Similarly, Hurd for the longest time was predominantly x86 32-bit only but the x86_64 port is now essentially complete and there is even eyes toward AArch64 support.
Now it’s arm64.
I’m more hopeful, I wrote a very basic userland thread scheduler in rust, like tokio, for full virtual threading (yielding instead of blocking), from a Java Virtual Thread inspiration and damn, the performance is amazing, just changing kernel scheduling to userland scheduling. I think Hurd would be the perfect kernel for that kind of next generation performance bump, a global scheduler with userland virtual processes and virtual threads. A microkernel has some advantages that weren’t event thought if not for recent developments, imagine what it could do, docker, kubernetes, podman, (the containers, not the engines) all inside subhurds or virtualized in a thin layer without cgroups or anything.
I think it’s the future, but it’s the future since the 80s hahaha.
Edit: the virtual thread scheduler is just a toy project, but I was impressed.
I think microkernel’s are weird but everything I hear does seem to imply they are better then what we currently have. That being said, “microkernel’s are the future” is a pretty old take now and I don’t know any OS that has one.
Linux is monolithic. Windows is somehow monolithic, bloated and extremely minimal. Don’t know about apple but I would guess they’re also monolithic since they are old and Unix based and that combination generally means monolithic.
MacOS’ XNU kernel is derived from the Mach microkernel, the same one on which Hurd is built. (Or at least approximately the same, since apparently there were various editions of Mach.)
Look at my other comment, there’s something cooking at GNU, idk but i’m hyped. I think Windows and MacOS (darwin/XNU) are hybrids, some parts in userspace, other parts in the kernel.
Edit: the macos kernel
I just discovered pth (not the new one npth), yielding threads in 1999, wtf happens at GNU? 20 years before anyone applied that and said “holy shit”. 1999.
Edit:
The thread scheduling itself is done in a cooperative way, i.e., the threads are managed by a priority- and event-based non-preemptive scheduler.
1999
