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.
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.
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.
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 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
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.
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
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.)
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.
Is Ironclad "Almost There"?
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