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.
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
That does require the compositor (and its applications) to help the new driver instance to re-establish its full state (which will typically consist of GBs of VRAM, among other things).
If your video card driver died, something is deeply wrong with your system, hardware or software, and blindly (literally) continuing is dangerous to the integrity of the data on that system. Things don't crash for no reason, this isn't a canned test where we're sure that only the one component is being fuzzed, this is reality.
Not really. IOMMUs have been a thing for a while. As for the GPU's hardware, it can be reset w/o affecting the rest of the system.
Even Linux and Windows can do that, it isn't a microkernel-exclusive thing. The latter just handle it better architecturally.
You can check with this script: https://pastebin.com/4t3WD5R1
On quite a lot of hardware you can't really isolate devices from each other properly.
Microkernels are not obsolete (see seL4), but HURD unfortunately is.
> Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now.
FUSE is far cray (capability, security and performance-wise) from real microkernels. Linux is a monolithic kernel and unashamedly so.
> The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore.
This would imply operating system developers (in any) OS are not that much interested in reliability of the system they're working on, which I don't believe is true. 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 video card or anything else is its own computer, with a very uncomfortable amount of state and access to the host. If your video card driver does something wrong and crashes it's by no means a given that the situation is recoverable by rebooting the driver -- the video card itself may be left in some weird state.
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.
* Software is also far more complex. Great, your system theoretically can survive a video card driver dying. Too bad the compositor can't survive that, and the applications can't survive the compositor crashing, and at that point you might as well reboot anyway.
Microkernels aren't written like that. In a MK architecture, your system survives video card driver dying by restarting it and taking over serving its clients (in this case, the compositor). Of course, Linux doesn't work like that, but we've already established Linux is not a microkernel.
> Modern testing and debugging is excellent and having a system kernel panic is something that happens very, very rarely. It's not really worthwhile to change the system architecture for the sake of something than happens less often than I accidentally unplug my desktop's power cable.
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.
> For HURD specifically, if you're in need of extreme reliability today, C is probably not something you want to use. Rather than dealing with stuff crashing you probably want to write code doesn't suffer from such issues to start with.
Ah yes, ye olde "just don't write bugs!" argument :-)
More seriously though, I would agree with you that replacing GNU/Linux with GNU/Hurd will never happen. I just want to emphasize Hurd is not be-all and end-all of microkernels (even open source ones). In fact, it never was.