128
GNU Hurd Is "Almost There" With x86_64, SMP & ~75% Of Debian Packages Building (www.phoronix.com)
submitted 3 weeks ago by potatoguy@lemmy.eco.br to c/linux@programming.dev
13 comments fedilink hide all child comments

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.

top 13 comments
sorted by: hot top new old
[-] bitcrafter@programming.dev 39 points 3 weeks ago

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.

[-] potatoguy@lemmy.eco.br 22 points 3 weeks ago* (last edited 3 weeks ago)

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.

[-] potatoguy@lemmy.eco.br 9 points 3 weeks ago* (last edited 3 weeks ago)

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

[-] Solemarc@lemmy.world 8 points 3 weeks ago

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.

[-] potatoguy@lemmy.eco.br 9 points 3 weeks ago* (last edited 3 weeks ago)

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

[-] SlurpingPus@lemmy.world 5 points 3 weeks ago* (last edited 3 weeks ago)

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.)

[-] Sturgist@lemmy.ca 5 points 3 weeks ago

still working on things like SMP

Know what has SMP? PonyOS

[-] bitcrafter@programming.dev 14 points 3 weeks ago

Yes, but they have it easy because their operating system only has one pony, whereas GNU is working with an entire hurd.

[-] Sturgist@lemmy.ca 4 points 3 weeks ago

........

...............

Fuck you for making me laugh.....

[-] Skullgrid@lemmy.world 5 points 3 weeks ago

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.

[-] Digit@lemmy.wtf 2 points 3 weeks ago

When I last tried hurd (around 2014 iirc), it was "there" enough. I'm not sure what this other "there" others are on about, like it's a hard binary transition point to being usable, as if it might as well not be working at all. It's there enough to give it a go. Long time.

[-] potatoguy@lemmy.eco.br 2 points 3 weeks ago

Yeah, 64 bits isn't working on bare metal (wd0 problems, seems to be the disk from the netbsd drivers), 32 bits is tho, trying dwm right now hahaha.

[-] Digit@lemmy.wtf 1 points 3 weeks ago

Is Ironclad "Almost There"?

this post was submitted on 01 Feb 2026
128 points (100.0% liked)

Linux

12535 readers
373 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago
MODERATORS
Ategon@programming.dev
anzo@programming.dev
dwraf_of_ignorance@programming.dev