Because Hurd is (in my understanding) exactly the solution in search of a problem you're talking about. It's microkernel for the sake of being microkernel, but tied to the past (POSIX/UNIX model).
Actually innovative microkernels can do things Linux or other mainstream monolithic OS can't just copy (and that's why they're interesting).
Again using L4 as an example, have a look at discussion here: https://news.ycombinator.com/item?id=35842240 (but there are also other interesting designs, eg QNX)
Nobody forces you to switch to a differnent OS, but that doesn't mean it's pointless to research and build different systems.
Because we have shipped products with those and boy I wish we had used Linux instead!
Limited, expensive, developer unfriendly and surprisingly, quite unstable under certain loads.
I believe you the developer experience was years behind Linux. That doesn't invalidate my claim that microkernels are interesting (and that these two are innovative), unless your pain was explicitly due to the microkernel nature of things.
But just last month we have had some _serious_ issues with QNX (which is supposed to be the top dog ukernel in 2023). For example IPC performance takes a nosedive in certain (not very uncommon) situations, which is not good for an RTOS. Talked to other people working with QNX and they have had similar problems.
Linux in a similar product has worked far far better. I understand the hype around microkernels and all that, but there is a reason they are not used in anything but the most basic products.
It would be great if all firmware and drivers was open source, but that's not going to happen anytime soon.
FSF is largely a joke in the way they certify RYF hardware. Proprietary blobs are all good as long as they're loaded from a separate flash that can't be updated by the main CPU, but if you load exactly the same firmware from the filesystem it's not okay.
And while Guix/Hurd isn't there yet as a daily driver (Debian/Hurd is much more polished), progress has been pretty exciting lately and it now runs on my IBM x60 -- https://todon.nl/@janneke/110451493405777898
Why HURD specifically?
But I didn't mean microkernels, but the debate. Basically my view is that nothing stays pure. If microkernels have significant upsides a monolithic kernel like Linux doesn't have, then the logical outcome is that Linux copies the required feature like eg, FUSE.
Yeah, it's not a true microkernel, but who cares? It can do the cool thing. Nobody cares about purity. Computing is about getting stuff done.
> Also, to give just one counter-example, I don't think many people have redundant mobile phones in case one of them crashes.
A modern cell phone has a tendency to forget stuff anyway. I mean Android will just randomly stop background programs when it pleases, so every app has to deal with that possibility. So the phone rebooting has little effect, other than taking time.
> This was more-or less true from the moment discreete GPUs started shoping up. Modern PCs have dozens of independent processors (some of them running their own opertaing systems)! If anything, that's more reason for microkernels.
How so? I have two overall points here:
1. With hardware being complex and stateful, rebooting the driver may just not help. If something inside the video card is locked up, no amount of rebooting the driver is going to fix that.
2. There are complex webs of dependency, which often aren't easy to resolve in a fault tolerant manner. Most stuff will probably just crash anyway even if recovery is theoretically possible. Recovery paths are very rarely exercised.
> Yeah, I agree Linux will never changi its system architecture, but that doesn't mean thinking, researching and building other operating systems using different architectures is obsolete.
No, I mean it's not worth it to the average person to switch to a different OS for the sake of a benefit that might materialize extremely rarely. I'm not itching for a better OS which can survive a driver crash because the time when that happens for me is essentially never.
I think in the last 3 years I might have seen one kernel panic. Switching to a very different OS for the sake of having a system that can survive such a freak occurrence would be wasting my time. I'd spend far more time learning HURD than I'd gain in productivity.
> Ah yes, ye olde "just don't write bugs!" argument :-)
This, but unironically. If you're concerned about reliability, then the better approach is to avoid failures to start with. Rather than having a system that can tolerate something overflowing a buffer and crashing, how about a system that doesn't allow you to even compile something that does that?
Huge advancements have been made in creating languages that lack many of the stupid pitfalls of C.