There are "they"s coming up repeatedly in this discussion.
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. (-:
I still haven't used Hurd, and at this point with the ridiculous diversity in hardware for desktop and laptops I don't think I could realistically use it for anything outside of playing with it in a virtual machine or something.
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?
They famously did better than the proprietary shell tools in the original fuzzpocalypse https://users.cs.northwestern.edu/~robby/courses/395-495-200... . I also think I recall reading, somewhere on jwz dot org, something which purported to be an internal SGI email giving a dismal account of the quality of the Irix tools. GNU tools often have expanded feature sets, too. But I think that GNU-tools adopters were probably also driven by a standardisation impulse to at least have the same bugs and quirks as everyone else.
I mean a lot of the stuff he's complaining about being crap aren’t exactly replaceable by the GNU coreutils.
People installed them on AIX/Solaris etc because the BSD/SysV tools they came with were basically abandoned. The GNU tools had a lot more useful features, not specifically more performant (although they probably were)
> I don't know but it seems people (or at least old geezers) install GNU on top of Macs these days.
Me, I do this! I like being able to tack flags on after positional args if I remember them after typing a command. I like some of the convenience flags added to the GNU versions coreutils, grep, and findutils. Even `parallel` implementation I've used before is GNU parallel. I've never really learned mawk, to the extent I know awk at all, it's gawk.
(I don't like the common convention of prefixing them with `g` on macOS, either. I install them with Nix and just preempt the system ones on my PATH.)
Missing the little detail that since Sun started charging for developer tools, all other UNIX vendors followed suit, thus GCC finally started to get mindshare.
GNU HURD is not like GNU/Linux. The latter stands for a combination of Linux kernel with GNU userland. They're distinct projects. GNU HURD on the other hand, is just a subproject of GNU. The entire OS is called just GNU, like how the BSDs are today. So if Torvalds meant the HURD, he would explicitly mentioned it.
I seem to recall the Hurd people talking about cool scenarios like filesystem drivers written entirely in user mode that don't require root. Something like that.
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.
Yeah, that's what I've always thought was interesting about microkernels; the ability to have a lot more stuff in user space always seemed like the obvious "correct" direction to me.
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.
> I played with RedoxOS a bit in a virtual machine a few years ago, and it seemed cool, so maybe that can be the logical successor to something like Hurd.
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.
Their matrix community (spaces) sees a healthy level of discussions. Even those related to project governance. The project is very much alive. And I believe that they're also porting the COSMIC desktop to Redox.
I have heard even more fantastic ideas. For example, the IPC and memory protection being served by userspace servers (I don't know how valid this is, or if I understood this correctly). You could have features similar to namespaces and cgroups by default, without the extra logic and code. You could have had native containerization from the start.
I feel like there's a difference between FUSE, an anomalous way to implement a filesystem, and having the user-space method be the primary mechanism to implement a filesystem. The latter ensures that the user-space thing doesn't have a quality gap with "real" FS drivers.
We have entire userspace network protocols, ePBF, and to some extent even ePool pooling ideas from microkernels. But A single disgruntled kernel dev is enough to stop Rust device drivers from existing, so no, the idea is still not here.
Even the Asahi Linux lead threatening Linus with a witchhunt against all kernel maintainers did not manage to finish off the ongoing Rust integration. People may not like it but it isn't going down easily.
No question, and especially now with Linux running on billions of devices (if you include Android in that at least), it would be kind of difficult to make a case for a brand new desktop operating system. A lot of the weird edge cases for Linux have been found and fixed and ironed out through decades of continued use.
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.
Speaking of BSD, in the hypothetical no-Linux universe, that would be the obvious candidate for taking the Linux spot, right? Rather than Hurd. BSD might even have won in the Linux-included universe, if some random events has panned out differently. Why not, right?
Didn't Linus even say that if he had known about BSD he wouldn't have bothered with Linux? I could totally see an alternate universe where BSD took over the world.
Yes and no. The gaming industry serves as an illustrative example because we know the Sony Playstation 4 and 5 are both based on FreeBSD[0].
Compare Sony PlayStation Network[1]
Monthly active users on PlayStation Network reached 123 million as of June 30, 2025.
with Valve's Steam[2]
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
With an optimistic estimate of current Monthly Active Users, if gaming on Linux grew overnight from 2.5% to 50% of total players on Steam, then it would still be slightly behind half of the people who are currently gaming on FreeBSD-based Playstation.
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].
> 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.
Off topic question, but wasn't that a violation of the BSD license? It does require a copyright notice.
Embedded for sure eats the world. If you're looking at that then QNX, FreeRTOS, and similar options are also big in the running. The thing is if you're targeting a particularly well-defined piece of hardware and application, and you know you're going to want to customize and optimize for that combination, then you're generally going to be better off with a smaller, simpler starting point than something which is designed to run on pretty much everything and for almost any application. The different licenses complement that, but I think even if the licenses swapped the design and goal difference would affect things more.
I’m not sure which comes out ahead if we count all of these kinds of devices. There are probably a lot of lightbulbs and routers out there running some variant of BSD or Linux, but only the manufacturer knows (I mean, you can often figure it out, but who cares?).
Anyway, it is important to keep in mind that the useful “size” metric of a community led open source project is the number of developer-hours being contributed to it, not the number of users. It is a fun bit of trivia that these devices are everywhere, and maybe good news for open source fans’ career prospects. But that’s all.
Keeping Android kernel development internal creates greater risk of binary blobs polluting the source code. Binary blobs might be a practical solution to bring products to market, but they are also a mechanism to circumvent the GPL. I doubt Google will take this problem seriously, but other Linux distributions have.
> FreeBSD code is also in iOS and macOS via Darwin […]
It is a common belief that Darwin has allegedly descended from FreeBSD, but there is not a lot in there: a pretty ancient snapshot of the FreeBSD userland, another snapshot of the TCP/IP stack that has now completely diverged from the current FreeBSD TCP/IP stack (or, more correctly, the other way round), plus a few borrowed kernel level API's (kqueue is the most notable one).
VMM, VFS, driver layers, file systems etc etc do not share the same lineage.
At one point it was [1], and I'm not aware that that has changed. I've also a memory of talking to the seL4 team at a NICTA open day, and them saying it was widely deployed on Qualcomm based devices. It's not part of Android per se, sitting underneath Android and acting as a secure hypervisor, so any Android vulnerabilities are contained.
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.
Curiously, in what no academic could have predicted, millions of people interact with a microkernel every day, and it was written by freaking Nintendo of all possible companies. (The Switch is a custom microkernel called Horizon; not FreeBSD, not Linux, not Android.) Almost every other consumer device is monolithic or hybrid.
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.
To be fair, microkernels are also highly successful in embedded devices and auxiliary processors. It’s just that you don’t usually directly interact with them. For example, Intel ME runs MINIX, and Apple’s Secure Enclave Processor runs L4. Also most OSes these days have some kind of hypervisor/secure monitor that’s more privileged than the regular kernel: TEE on Android, SPTM on Apple, VBS on Windows, and proprietary ones on all the game consoles. They vary in how much functionality they’re actually responsible for, but if it’s a significant amount then they tend to have a microkernel-ish design internally.
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.
If you're interested in what's going on with GNU in general, GUIX is awesome. It's a package manager like Nix but purely GNU (using GNU Guile scheme). It's developed in tandem with the GNU Shepherd init system (instead of sysvinit/systemd/openrc/etc.) and there are distributions based on GNU Hurd kernel (or the Linux-libre kernel).
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.
One of these days I'll try guix (currently on NixOS).
Two things that hold me back (aside from the obvious friction of switching):
1. nixpkgs is huge. If what I need isn't in 25.05, it's in unstable
2. I've been programming in Common Lisp for so long that I can't help but write buggy code any time I try writing in a lisp-1. It seems like it should be such a minor thing, but I invariably inadvertently shadow a function I'm using with some other variable.
[edit]
I forgot my third issue, which is all of my preferred setup options seem to be further off beaten path in Guix than NixOS (e.g. plasma, zfs)
I'm totally with you, though would note that running Hurd as your main kernel is difficult, but running childhurds on your linux kernel is fun and profitable.
Is that likely to keep working? With GNOME moving to depend on systemd even more strongly ( https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-... ), I kinda assumed that even non-systemd Linux distros may or may not keep it, let alone non-Linux OSs.
This is the reason why I don't like systemd. Make no mistake, systemd has some very good ideas. But when they say that it's modular, replaceable, maintainable etc, this is what actually happens. It's all that in theory. But the reality is very different. GNU Shepherd (guix's init) for instance, is something you can hack deeply using Guile Scheme - sort of like Emacs with Elisp. Much of the Guix OS is like that. Strongly integrated with Guile Scheme glue. But flexible and modular enough to be swapped out easily. Imagine doing the same with systemd init.
I'm so excited to try GUIX. Right now I'm on Apple Silicon so I can't get it to work even in a VM, but the second I've got an x64 ISA computer I'm using GUIX
To think Linus wrote linux to be a "good enough" solution until hurd was ready.
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.
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.
> 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.
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.
Yeah, projects like this really need people who will be into it for the long term, and using something like rust or zig is a big gamble. It eliminates a huge swath of potential long-term contributors who know C well and don't want to change, in exchange for an unknown group with an unknown amount of overlap.
> It eliminates a huge swath of potential long-term contributors who know C well and don't want to change,
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.
OTOH, I have zero interest in contributing to a C kernel. Even the experts can't write it without messing up with C's vastly many footguns. I'm not a C expert. What chance to I have to add a new kernel feature that doesn't literally destroy my system? It's too intimidating in the sheer amount of risky "surface area" I have to perfectly manage or else face dire consequences.
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.
Yeah and the rest of us don't want a kernel that mutates a heap-like structure for every minor operation. So until there's a language for writing software with a C-like approach to memory and lifetimes you're not going to see C or C software replaced.
> It eliminates a huge swath of potential long-term contributors who know C well and don't want to change
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.
> > They should retry rewriting it in rust (or zig)
> It's an antipattern to chase whatever language is being hyped the most at the moment.
Hype? Come on, Rust's 1.0 release was already over a decade ago. At this point it's pretty boring. How many more years will it take before people start taking it seriously and finally accept that those who prefer Rust over C do so because it's a much better language than C and not just because it's hyped?
I guess it sort of depends on how you define "success"; there's plenty of projects that still have some development and active users.
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).
There are several other important and relatively new GNU projects around - like GNU Radio, Jami, Poke (a semantics-aware binary editor), GNS (DNS alternative), Guile, Mailman, Octave, Parted, R, Shepherd, Taler, GnuCash, DDRescue and numerous others to name. But if you leave out the 'new' part, you'll discover a lot more fantastic gnu projects [1], including Linux's entire coreutils. If you spend enough time with some of them, you'll see how focused, clever, polished and well-integrated many of them are - like bc, units, wget and stow for example. You get the Emacs vibe from many of them. On top of that, a lot of important software are built on top of GNU software like glibc, gsl, gcc, groff, libjit, gmp, ghostscript, libtasn1, readline, aspell, tar (gnu format), termcap, bash, etc. And one thing in common with most of them is their longevity.
one of the GNU/Hurd maintainers is a neighbor .. he is over 70 now, with degree in physics from a top-ranked US university, most of his days are spent dealing with serious health problems.
It would be cool to have a Hurd project with a verified microkernel like seL4.
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.
I'm aware of that post! I did a video looking at the GNU Hurd and I believe it came up there.
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.
I've worked a fair amount with LLMs from a code generation perspective, and to be honest, I find them often to be better at reading and explaining code to a human than generating good code.
It's an interesting idea to think that LLMs could be used to not only explain the code but test the potentially tricky corner cases.
I'm pretty sure LLMs are here to stay, and we're just going to have to learn the best ways to work with them.
Genuine question, as someone who has only ever played with Inferno and Plan 9 in virtual machines and only for brief periods of time in the process: what does Plan 9 actually buy you?
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.
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.
Personally, I have only run 9front on VMs, but my understanding is that 9front will boot on most x86/x86_64 machines. There is also explicit work to keep it running well on RPi hardware, which is what adventuresin9 runs.
For a bit more nitty-gritty, the 9front FQA[0] is worth running through.
Plan 9's file system interface makes it a great way to build a network "mux". I added a reverse http(s) capable proxy using rc-httpd and webfs to effectively tunnel Shoutcast/Icecast streams from a Mac behind a firewall, with 9front being the only exposed endpoint.
It took an afternoon to figure out how, and was basically "cat".
Forcing everything into the single abstraction of the filesystem lets do useful things with less trouble than other systems. As an example: Plan 9 doesn't have any use for containers because in its world chroot is exhaustive. You don't need special namespaces to control ex. network access, because network access goes through a filesystem in your chroot.
Maybe, though what I was trying to get at with my comment still isn't really addressed. It seems like if you're making everything a filesystem and making it so that the OS doesn't care about where the filesystem is, it can be very easy for latency costs to pile up.
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.
Just because you can run it over the network doesn't mean you have to. Like, yeah, you can run Linux with root on NFS and yes it can make you vulnerable to latency problems, but you can also run Plan 9 completely on a single machine with all the myriad filesystems coming from from the local system (mostly virtual, but some actually hitting disk).
If you mean that microkernels ping-ponging between kernel and user space can impact perf: Maybe? I'd really want to see benchmarks.
> 64bit support is now complete, with the same archive coverage as i386 (actually a bit more since some packages are 64b-only)
> This 64b support is completely using userland disk drivers from NetBSD thanks to the Rump layer.
That's exciting news! I know it's a bit much to get excited about Hurd. But this is a big milestone. And though I'm not holding my breath, I really want to see how far they can take it. I'm not ready to write them off yet.
I didn't notice that until I saw your comment. Thanks!
I found that it's a bit surprising that the 64-bit support comes from NetBSD.
My initial thought was that porting code from Linux would be a more direct path, especially since a major goal for GNU Hurd is compatibility with the Debian archive.
I have not followed Hurd since ~2010 when development stalled, what is the purpose of Hurd at this point? Is it just hobbyists having fun and exploring the possibilities or are they still trying to become a viable option or something else or a little of a bunch of things? I think I will try installing Debian GNU/Hurd on an old laptop, always wanted to play with Hurd but I never succeeded in getting any computer I had to boot up with it and never had interest in running OSes in VMs.
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.
Well, prior to this release I would have said "there is no point", but it looks like Hurd has finally gotten rid of some of the major warts I remember when I first took at look at it over a decade ago.
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.)
I love how Haiku feels like it has its feet in two places at once. That it is both in the year 2000 and 2040 at the same time.
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.
I think things like compilation speed are fairly low on their priority list because they are focusing on the user and not the developer, the people who are not going to bother compiling anything and want the OS to be something they never have to think about. Lack of focus on the user seems a big part of why I think linux has failed to gain a real foothold, or perhaps it is more accurate to say that the linux community pushed too hard long before it viable for that use case and now there are alot of people out there who tried linux a decade ago and remember spending a lot of time fiddling with their system and jumping through hoops instead of just using the computer for those things they use a computer for. Some distros are viable these days for the average person, but a lot of those average people have a bad taste left in their mouth from when they tried <my favorite distro is perfect for you!>.
> Forgot that Chomium was opensource but ChromeOS is not, so I guess I had no need to play semantics.
I won’t argue the semantics, but I will be a pedant :-) “ChromiumOS” absolutely exists and is FOSS-licensed. It’s a mess to build — basically a bunch of ebuild overlays for Gentoo’s build system and a boatload of custom tooling/scripts which produce images for a given system configuration, if I remember correctly. I don’t know much about it honestly, but it is open source! At least in the same way Chromium is.
First: Hurd isn't a new operating system. It's a decades old project from last millennium.
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.
Hurd predates Linux by about a year, but was under stop/start development for several years before that too. https://en.wikipedia.org/wiki/GNU_Hurd It's as old as dirt, in computing terms. It was intended to be the final part of a fully GNU based operating system, everything else having been created by that stage.
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.
This is not correct. Look at what is happening in the Amiga retrocomputing area.
Some of them have Linux support along with AmigaOS/Morphos and Aros. Pretty succesful (expensive though) because they do not release 1000 different systems each year but 2-3.
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.
Off topic: this is from April 6, 2015; I'm impressed at the Elon Musk project guess. I would not discard someone's guess of some xOS appearing around 2028-2030 to quickly today.
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.
The HURD has been around for a while, and its architecture is archaic. It's from a world where Mach is the microkernel, and thus microkernels are slow.
There are "they"s coming up repeatedly in this discussion.
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.
I still haven't used Hurd, and at this point with the ridiculous diversity in hardware for desktop and laptops I don't think I could realistically use it for anything outside of playing with it in a virtual machine or something.
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?
The "gnu" in the famous email is GNU Hurd; we're still waiting:
>I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.
no it's not, the GNU system was already established by then,.and in use with other kernels. Linus was referring to GNU as a whole, not Hurd.
GNU was a toolchain in search of a kernel; which was supposed to be Hurd.
(It often got installed on top of “real” Unix because it was a damn good toolchain)
Still is.
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.
They famously did better than the proprietary shell tools in the original fuzzpocalypse https://users.cs.northwestern.edu/~robby/courses/395-495-200... . I also think I recall reading, somewhere on jwz dot org, something which purported to be an internal SGI email giving a dismal account of the quality of the Irix tools. GNU tools often have expanded feature sets, too. But I think that GNU-tools adopters were probably also driven by a standardisation impulse to at least have the same bugs and quirks as everyone else.
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 mean a lot of the stuff he's complaining about being crap aren’t exactly replaceable by the GNU coreutils.
People installed them on AIX/Solaris etc because the BSD/SysV tools they came with were basically abandoned. The GNU tools had a lot more useful features, not specifically more performant (although they probably were)
Sometimes they were faster but there certainly were more “bloated” - you can find people complaining about it from the era.
But they really did have tons of options and once you were used to them, you really wanted them.
But remember that GNU grew up in the era of multi-user systems; and Linux was the forefront of “personal computing Unix” where the user had root.
> I don't know but it seems people (or at least old geezers) install GNU on top of Macs these days.
Me, I do this! I like being able to tack flags on after positional args if I remember them after typing a command. I like some of the convenience flags added to the GNU versions coreutils, grep, and findutils. Even `parallel` implementation I've used before is GNU parallel. I've never really learned mawk, to the extent I know awk at all, it's gawk.
(I don't like the common convention of prefixing them with `g` on macOS, either. I install them with Nix and just preempt the system ones on my PATH.)
Missing the little detail that since Sun started charging for developer tools, all other UNIX vendors followed suit, thus GCC finally started to get mindshare.
GNU HURD is not like GNU/Linux. The latter stands for a combination of Linux kernel with GNU userland. They're distinct projects. GNU HURD on the other hand, is just a subproject of GNU. The entire OS is called just GNU, like how the BSDs are today. So if Torvalds meant the HURD, he would explicitly mentioned it.
I seem to recall the Hurd people talking about cool scenarios like filesystem drivers written entirely in user mode that don't require root. Something like that.
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.
Yeah, that's what I've always thought was interesting about microkernels; the ability to have a lot more stuff in user space always seemed like the obvious "correct" direction to me.
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.
[1] https://en.wikipedia.org/wiki/RedoxOS
> I played with RedoxOS a bit in a virtual machine a few years ago, and it seemed cool, so maybe that can be the logical successor to something like Hurd.
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.
Which is how most drivers now work across macOS, Windows and Android/Linux.
Unfortunely other UNIX clones rather keep going as "things were always done around here"
Oh, I thought that was going to die shortly after Jeremy moved to System76, but it didn't,
- https://www.redox-os.org/news/
Project seems quite healthy to me. I was intending on trying it over the weekend but dragged into chores instead.
I think there's some spark there.
Their matrix community (spaces) sees a healthy level of discussions. Even those related to project governance. The project is very much alive. And I believe that they're also porting the COSMIC desktop to Redox.
I have heard even more fantastic ideas. For example, the IPC and memory protection being served by userspace servers (I don't know how valid this is, or if I understood this correctly). You could have features similar to namespaces and cgroups by default, without the extra logic and code. You could have had native containerization from the start.
And now we have FUSE. The good ideas do get taken up by the mainstream.
I feel like there's a difference between FUSE, an anomalous way to implement a filesystem, and having the user-space method be the primary mechanism to implement a filesystem. The latter ensures that the user-space thing doesn't have a quality gap with "real" FS drivers.
We have entire userspace network protocols, ePBF, and to some extent even ePool pooling ideas from microkernels. But A single disgruntled kernel dev is enough to stop Rust device drivers from existing, so no, the idea is still not here.
That didn’t happen.
Even the Asahi Linux lead threatening Linus with a witchhunt against all kernel maintainers did not manage to finish off the ongoing Rust integration. People may not like it but it isn't going down easily.
> but I've always thought that the microkernel design was more elegant than the monolithic thing we ended up with.
The thing with elegant systems is they usually don't succeed if the alternative is something pragmatic that has been battle tested.
No question, and especially now with Linux running on billions of devices (if you include Android in that at least), it would be kind of difficult to make a case for a brand new desktop operating system. A lot of the weird edge cases for Linux have been found and fixed and ironed out through decades of continued use.
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.
Speaking of BSD, in the hypothetical no-Linux universe, that would be the obvious candidate for taking the Linux spot, right? Rather than Hurd. BSD might even have won in the Linux-included universe, if some random events has panned out differently. Why not, right?
Didn't Linus even say that if he had known about BSD he wouldn't have bothered with Linux? I could totally see an alternate universe where BSD took over the world.
It's arguable that the main reason Linux took off where BSD didn't was the fights and copyright arguments around BSD at the time.
Had they not existed, or BSD been obviously free and clear, Linux might have been a footnote.
A combination IMO of lingering issues around the AT&T lawsuit and various community issues within the BSDs.
I recall either Linus or a major Linux contributor (Alan Cox?) saying that if he had had a math coprocessor, he would have likely just ran BSD.
I don't think even 386BSD existed when Linus started Linux.
It could have been that more effort would have been put in Hurd if Linux hadn't taken off.
And then BSD could have won against Hurd anyway. Especially when corps like the permissive license and are afraid of the FSF.
Yes and no. The gaming industry serves as an illustrative example because we know the Sony Playstation 4 and 5 are both based on FreeBSD[0].
Compare Sony PlayStation Network[1]
with Valve's Steam[2] With an optimistic estimate of current Monthly Active Users, if gaming on Linux grew overnight from 2.5% to 50% of total players on Steam, then it would still be slightly behind half of the people who are currently gaming on FreeBSD-based Playstation.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...
> 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.
Off topic question, but wasn't that a violation of the BSD license? It does require a copyright notice.
Embedded for sure eats the world. If you're looking at that then QNX, FreeRTOS, and similar options are also big in the running. The thing is if you're targeting a particularly well-defined piece of hardware and application, and you know you're going to want to customize and optimize for that combination, then you're generally going to be better off with a smaller, simpler starting point than something which is designed to run on pretty much everything and for almost any application. The different licenses complement that, but I think even if the licenses swapped the design and goal difference would affect things more.
> 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.
Is this not even more true than with Linux in the billions strong Android?
I’m not sure which comes out ahead if we count all of these kinds of devices. There are probably a lot of lightbulbs and routers out there running some variant of BSD or Linux, but only the manufacturer knows (I mean, you can often figure it out, but who cares?).
Anyway, it is important to keep in mind that the useful “size” metric of a community led open source project is the number of developer-hours being contributed to it, not the number of users. It is a fun bit of trivia that these devices are everywhere, and maybe good news for open source fans’ career prospects. But that’s all.
Links 3 through 6 in my comment touched upon this. My point is that even companies behind commercial Linux products are trying to resist the GPL.
In 2021, it appeared that Google was planning a pivot to their own BSD/MIT-licensed OS named Fuscia.
https://arstechnica.com/gadgets/2017/05/googles-fuchsia-smar...
This pivot seemed to end around the same time tech layoffs were occuring in 2024.
https://9to5google.com/2024/01/15/google-is-no-longer-bringi...
Since then, Google has chosen to limit the amount of open source development done for the Android OS.
https://www.androidauthority.com/google-android-development-...
Keeping Android kernel development internal creates greater risk of binary blobs polluting the source code. Binary blobs might be a practical solution to bring products to market, but they are also a mechanism to circumvent the GPL. I doubt Google will take this problem seriously, but other Linux distributions have.
https://lwn.net/Articles/655519/
The move by Google mirrors the choice by Red Hat to keep RHEL source code private.
https://www.theregister.com/2023/06/23/red_hat_centos_move/
The common trend is product managers for these companies view the GPL as a bug instead of a feature.
Linux kernel, not GNU/Linux, which is what folks trying to misuse NDK always get wrong.
> FreeBSD code is also in iOS and macOS via Darwin […]
It is a common belief that Darwin has allegedly descended from FreeBSD, but there is not a lot in there: a pretty ancient snapshot of the FreeBSD userland, another snapshot of the TCP/IP stack that has now completely diverged from the current FreeBSD TCP/IP stack (or, more correctly, the other way round), plus a few borrowed kernel level API's (kqueue is the most notable one).
VMM, VFS, driver layers, file systems etc etc do not share the same lineage.
> it would be kind of difficult to make a case for a brand new desktop operating system
Google is sure trying with Fuscia: https://en.wikipedia.org/wiki/Fuchsia_(operating_system)
> especially now with Linux running on billions of devices
Aren't those billions of Linux/Android instances typically running on top of an seL4 microkernel?
Are they? I can't seem to find evidence of Android using it
At one point it was [1], and I'm not aware that that has changed. I've also a memory of talking to the seL4 team at a NICTA open day, and them saying it was widely deployed on Qualcomm based devices. It's not part of Android per se, sitting underneath Android and acting as a secure hypervisor, so any Android vulnerabilities are contained.
[1] https://web.archive.org/web/20120211210405/http://www.ok-lab...
You're talking about systemd right? :)
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.
Didn't Blackberry's OS have a microkernel?
Yes, it was based on QNX
> The thing with elegant systems is they usually don't succeed if the alternative is something faster.
FTFY
Curiously, in what no academic could have predicted, millions of people interact with a microkernel every day, and it was written by freaking Nintendo of all possible companies. (The Switch is a custom microkernel called Horizon; not FreeBSD, not Linux, not Android.) Almost every other consumer device is monolithic or hybrid.
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.
To be fair, microkernels are also highly successful in embedded devices and auxiliary processors. It’s just that you don’t usually directly interact with them. For example, Intel ME runs MINIX, and Apple’s Secure Enclave Processor runs L4. Also most OSes these days have some kind of hypervisor/secure monitor that’s more privileged than the regular kernel: TEE on Android, SPTM on Apple, VBS on Windows, and proprietary ones on all the game consoles. They vary in how much functionality they’re actually responsible for, but if it’s a significant amount then they tend to have a microkernel-ish design internally.
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.
If you're interested in what's going on with GNU in general, GUIX is awesome. It's a package manager like Nix but purely GNU (using GNU Guile scheme). It's developed in tandem with the GNU Shepherd init system (instead of sysvinit/systemd/openrc/etc.) and there are distributions based on GNU Hurd kernel (or the Linux-libre kernel).
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.
1. https://guix.gnu.org/
2. https://www.gnu.org/software/shepherd/manual/shepherd.html
3. https://en.wikipedia.org/wiki/GNU_Guix
4. https://www.gnu.org/software/guile/
One of these days I'll try guix (currently on NixOS).
Two things that hold me back (aside from the obvious friction of switching):
1. nixpkgs is huge. If what I need isn't in 25.05, it's in unstable
2. I've been programming in Common Lisp for so long that I can't help but write buggy code any time I try writing in a lisp-1. It seems like it should be such a minor thing, but I invariably inadvertently shadow a function I'm using with some other variable.
[edit]
I forgot my third issue, which is all of my preferred setup options seem to be further off beaten path in Guix than NixOS (e.g. plasma, zfs)
I'm totally with you, though would note that running Hurd as your main kernel is difficult, but running childhurds on your linux kernel is fun and profitable.
https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes...
Obviously I'm crazy, because I use Emacs with EXWM as my shell, but IMHO it's perfectly capable of being a "daily driver" already.
Is that likely to keep working? With GNOME moving to depend on systemd even more strongly ( https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-... ), I kinda assumed that even non-systemd Linux distros may or may not keep it, let alone non-Linux OSs.
This is the reason why I don't like systemd. Make no mistake, systemd has some very good ideas. But when they say that it's modular, replaceable, maintainable etc, this is what actually happens. It's all that in theory. But the reality is very different. GNU Shepherd (guix's init) for instance, is something you can hack deeply using Guile Scheme - sort of like Emacs with Elisp. Much of the Guix OS is like that. Strongly integrated with Guile Scheme glue. But flexible and modular enough to be swapped out easily. Imagine doing the same with systemd init.
Yeah, I don't know. I'm worried about that and for the BSDs and nom-systend Linux distros.
I'm so excited to try GUIX. Right now I'm on Apple Silicon so I can't get it to work even in a VM, but the second I've got an x64 ISA computer I'm using GUIX
Has anyone compared the HarmonyOS NEXT to Debian Hurd?
HarmonyOS NEXT is the world's most widely used microkernel system, reportedly used on approximately 800 million systems.
yeah. one is a communist's malware, another one is a closed source commercial os
I tried to get a copy of GNU Hurd via git a few weeks ago and it didn’t work. Can someone post a working repository link?
https://git.sceen.net/hurd/hurd.git
ref. https://www.gnu.org/software/hurd/source_repositories.html#i...
To think Linus wrote linux to be a "good enough" solution until hurd was ready.
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.
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.
> 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.
Rust's main toy/experimental OS RedoxOS is already there and has a microkernel.
> They should retry rewriting it in rust (or zig)
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.
Yeah, projects like this really need people who will be into it for the long term, and using something like rust or zig is a big gamble. It eliminates a huge swath of potential long-term contributors who know C well and don't want to change, in exchange for an unknown group with an unknown amount of overlap.
> It eliminates a huge swath of potential long-term contributors who know C well and don't want to change,
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.
At this point... if you want to contribute to a UNIX-like microkernel-based OS written in Rust, Redox is right there
I'll believe it when Netcraft confirms it
OTOH, I have zero interest in contributing to a C kernel. Even the experts can't write it without messing up with C's vastly many footguns. I'm not a C expert. What chance to I have to add a new kernel feature that doesn't literally destroy my system? It's too intimidating in the sheer amount of risky "surface area" I have to perfectly manage or else face dire consequences.
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.
Yeah and the rest of us don't want a kernel that mutates a heap-like structure for every minor operation. So until there's a language for writing software with a C-like approach to memory and lifetimes you're not going to see C or C software replaced.
So, Rust or Zig are OK, then.
So you've never written a rust program then. Or you don't know how to write C well.
Redox exists; are you contributing to it?
> It eliminates a huge swath of potential long-term contributors who know C well and don't want to change
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.
> > They should retry rewriting it in rust (or zig)
> It's an antipattern to chase whatever language is being hyped the most at the moment.
Hype? Come on, Rust's 1.0 release was already over a decade ago. At this point it's pretty boring. How many more years will it take before people start taking it seriously and finally accept that those who prefer Rust over C do so because it's a much better language than C and not just because it's hyped?
GNU mentality in a nutshell
Also I can't remember any more recent GNU projects that were successful
I guess it sort of depends on how you define "success"; there's plenty of projects that still have some development and active users.
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).
There are several other important and relatively new GNU projects around - like GNU Radio, Jami, Poke (a semantics-aware binary editor), GNS (DNS alternative), Guile, Mailman, Octave, Parted, R, Shepherd, Taler, GnuCash, DDRescue and numerous others to name. But if you leave out the 'new' part, you'll discover a lot more fantastic gnu projects [1], including Linux's entire coreutils. If you spend enough time with some of them, you'll see how focused, clever, polished and well-integrated many of them are - like bc, units, wget and stow for example. You get the Emacs vibe from many of them. On top of that, a lot of important software are built on top of GNU software like glibc, gsl, gcc, groff, libjit, gmp, ghostscript, libtasn1, readline, aspell, tar (gnu format), termcap, bash, etc. And one thing in common with most of them is their longevity.
[1] https://www.gnu.org/software/#allgnupkgs
A lot of those I think are > 20yrs now, so not necessarily "new" projects
> including Linux's entire coreutils
Ah yes I think I've heard of this GNU/Linux thing. To see if they will come ahead of Berkeley System Distribution. /s
Jami, or Taler come to mind. The latter just released, so... Yeah.
https://www.taler.net/en/news/2025-01.html
Guix as well. It's very good.
gnu less-is-more
one of the GNU/Hurd maintainers is a neighbor .. he is over 70 now, with degree in physics from a top-ranked US university, most of his days are spent dealing with serious health problems.
Which maintainer? Would like to save their websites to archive.org if they have any.
What was their day job?
It would be cool to have a Hurd project with a verified microkernel like seL4.
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.
I don't know why this got downvoted... Hurd was indeed investigating L4 as an alternative microkernel for some time.
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
I'm aware of that post! I did a video looking at the GNU Hurd and I believe it came up there.
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.
I've worked a fair amount with LLMs from a code generation perspective, and to be honest, I find them often to be better at reading and explaining code to a human than generating good code.
It's an interesting idea to think that LLMs could be used to not only explain the code but test the potentially tricky corner cases.
I'm pretty sure LLMs are here to stay, and we're just going to have to learn the best ways to work with them.
>It would be cool to have a Hurd project with a verified microkernel like seL4.
There's Genode[0]. Relative to the hurd, its design is much more advanced and it supports a range of modern microkernels including seL4.
0. https://genode.org/
thanks, I hadn't heard of Genode, this looks really cool
Genode is more an "OS construction kit" than an OS, isn't it?
Yes; but the project includes "Sculpt" which is more of an OS.
https://genode.org/download/sculpt
It has a distribution, Sculpt[0].
Many stories around using Genode in the Genodians[1] blog.
0. https://genode.org/download/sculpt
1. https://genodians.org/
I think of Plan 9 practically every day but I'm only reminded approximately once every few years to the existence of Hurd.
Genuine question, as someone who has only ever played with Inferno and Plan 9 in virtual machines and only for brief periods of time in the process: what does Plan 9 actually buy you?
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.
I use 9front heavily.
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
Interesting. Do you use it on real hardware? Are drivers an issue?
I have an old piece of shit laptop that’s not being used for anything, might be a fun excuse to try it out.
Personally, I have only run 9front on VMs, but my understanding is that 9front will boot on most x86/x86_64 machines. There is also explicit work to keep it running well on RPi hardware, which is what adventuresin9 runs.
For a bit more nitty-gritty, the 9front FQA[0] is worth running through.
[0]:https://fqa.9front.org/fqa3.html
I am having ideas about how I could build a firewall/router using 9p primitives now.
Damnit, I guess I know what I am doing this weekend.
Plan 9's file system interface makes it a great way to build a network "mux". I added a reverse http(s) capable proxy using rc-httpd and webfs to effectively tunnel Shoutcast/Icecast streams from a Mac behind a firewall, with 9front being the only exposed endpoint.
It took an afternoon to figure out how, and was basically "cat".
Forcing everything into the single abstraction of the filesystem lets do useful things with less trouble than other systems. As an example: Plan 9 doesn't have any use for containers because in its world chroot is exhaustive. You don't need special namespaces to control ex. network access, because network access goes through a filesystem in your chroot.
So, what you are saying is we need a cat with a phat wallet to fund development on the thing and make it sleek.
It would really be a real competitor with linux in the server market.
> we need a cat with a phat wallet to fund development on the thing
Yup. I tried to bounce the idea of Mark Shuttleworth when I last interviewed him, but he wasn't interested.
Maybe, though what I was trying to get at with my comment still isn't really addressed. It seems like if you're making everything a filesystem and making it so that the OS doesn't care about where the filesystem is, it can be very easy for latency costs to pile up.
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.
Just because you can run it over the network doesn't mean you have to. Like, yeah, you can run Linux with root on NFS and yes it can make you vulnerable to latency problems, but you can also run Plan 9 completely on a single machine with all the myriad filesystems coming from from the local system (mostly virtual, but some actually hitting disk).
If you mean that microkernels ping-ponging between kernel and user space can impact perf: Maybe? I'd really want to see benchmarks.
Poor Inferno on the corner, as everyone keeps forgeting that it was the next step after Plan 9 was considered done by AT&T.
Huh... the 64-bit release is news to me. I thought GNU Hurd was 32-bit only?
> 64bit support is now complete, with the same archive coverage as i386 (actually a bit more since some packages are 64b-only)
> This 64b support is completely using userland disk drivers from NetBSD thanks to the Rump layer.
That's exciting news! I know it's a bit much to get excited about Hurd. But this is a big milestone. And though I'm not holding my breath, I really want to see how far they can take it. I'm not ready to write them off yet.
I didn't notice that until I saw your comment. Thanks!
I found that it's a bit surprising that the 64-bit support comes from NetBSD.
My initial thought was that porting code from Linux would be a more direct path, especially since a major goal for GNU Hurd is compatibility with the Debian archive.
I have no special insight, but I know of 2 possible factors:
* the NetBSD "rump" unikernel is out there:
https://rumpkernel.github.io/
https://thamizhelango.medium.com/netbsds-rump-kernel-framewo...
* Secondly, this exists because NetBSD is much much smaller and simpler than Linux, which has undergone decades of enterprise-focussed optimisation.
No problem! I just figured it was worth a mention… because this alone renewed interest in GNU Hurd for me in a huge way.
I have not followed Hurd since ~2010 when development stalled, what is the purpose of Hurd at this point? Is it just hobbyists having fun and exploring the possibilities or are they still trying to become a viable option or something else or a little of a bunch of things? I think I will try installing Debian GNU/Hurd on an old laptop, always wanted to play with Hurd but I never succeeded in getting any computer I had to boot up with it and never had interest in running OSes in VMs.
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.
Well, prior to this release I would have said "there is no point", but it looks like Hurd has finally gotten rid of some of the major warts I remember when I first took at look at it over a decade ago.
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.)
So what would you say its point is now?
I love how Haiku feels like it has its feet in two places at once. That it is both in the year 2000 and 2040 at the same time.
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.
I think things like compilation speed are fairly low on their priority list because they are focusing on the user and not the developer, the people who are not going to bother compiling anything and want the OS to be something they never have to think about. Lack of focus on the user seems a big part of why I think linux has failed to gain a real foothold, or perhaps it is more accurate to say that the linux community pushed too hard long before it viable for that use case and now there are alot of people out there who tried linux a decade ago and remember spending a lot of time fiddling with their system and jumping through hoops instead of just using the computer for those things they use a computer for. Some distros are viable these days for the average person, but a lot of those average people have a bad taste left in their mouth from when they tried <my favorite distro is perfect for you!>.
> Forgot that Chomium was opensource but ChromeOS is not, so I guess I had no need to play semantics.
I won’t argue the semantics, but I will be a pedant :-) “ChromiumOS” absolutely exists and is FOSS-licensed. It’s a mess to build — basically a bunch of ebuild overlays for Gentoo’s build system and a boatload of custom tooling/scripts which produce images for a given system configuration, if I remember correctly. I don’t know much about it honestly, but it is open source! At least in the same way Chromium is.
Note that Guix also runs on the Hurd and has first class support for running a Hurd VM service if you just want to play around.
https://guix.gnu.org/blog/2024/hurd-on-thinkpad/
Is it still XNU/OSF-1 inspired? Are people running it on actual metal?
https://fosdem.org/2025/schedule/event/fosdem-2025-5490-mach...
Debian GNU/kFreeBSD should be revived.
Interesting! I ran some version of Hurd back in 1998, with ip masquerading and forwarding through a dial-up capable Linux box.
And now it's 64bit!?
Is any new operating system is able to emerge nowadays ?
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.
First: Hurd isn't a new operating system. It's a decades old project from last millennium.
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.
Hurd predates Linux by about a year, but was under stop/start development for several years before that too. https://en.wikipedia.org/wiki/GNU_Hurd It's as old as dirt, in computing terms. It was intended to be the final part of a fully GNU based operating system, everything else having been created by that stage.
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.
This is not correct. Look at what is happening in the Amiga retrocomputing area. Some of them have Linux support along with AmigaOS/Morphos and Aros. Pretty succesful (expensive though) because they do not release 1000 different systems each year but 2-3.
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.
At this point investing time (or money) into RedoxOS[1] would be more rational.
[1] https://redox-os.org/
Relevant XKCD: https://xkcd.com/1508/
Off topic: this is from April 6, 2015; I'm impressed at the Elon Musk project guess. I would not discard someone's guess of some xOS appearing around 2028-2030 to quickly today.
Dead link, at least for me.
... also, they're still working on Hurd?
You can read the announcement on the WWW archive of the debian-hurd mailing list, instead.
* https://lists.debian.org/debian-hurd/2025/08/msg00038.html
http://web.archive.org/web/20250810064049/https://lists.gnu....
The HURD has been around for a while, and its architecture is archaic. It's from a world where Mach is the microkernel, and thus microkernels are slow.
There's many more options[0] these days.
0. https://www.microkernel.info/
There is an attempt to rewrite GNU Mach
https://fosdem.org/2025/schedule/event/fosdem-2025-5490-mach...