Debian GNU/Hurd 2023
lists.gnu.org
lists.gnu.org
(If you're making sense, clarity might help for me/others?)
This story has been floating around in various tech areas. Here’s a podcast about it: https://corecursive.com/android-with-chet-haase/
https://www.theatlantic.com/technology/archive/2013/12/the-d...
Simply put: nowhere. It's an experimental kernel with limited hardware support (x86 only, very few device drivers) and a bunch of critical features missing (e.g. no multiprocessor support, no power management).
And limited x86_64 :)
Also I just found that they have a directory for packages here: http://ftp.ports.debian.org/debian-ports/pool-hurd-amd64/ but none have been added yet.
But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.
The difference would be if there was a seperate "kernel" that handled disk devices. Imagine being able to upgrade it without swapping out anything to do with process control.
I mean; we already do this with userland programs of course.. but I think we're not used to this in kernel land conceptually.
The closest we have is kernel modules which are simply not in the same arena.. like comparing function calls to RESTFul RPC; they just operate too differently to compare mentally.
Graphics cards and other accelerators are trickier since they can also access main memory. Therefore, restarting its driver might not resolve the problem, and the whole system has to be rebooted anyways.
Anyways, the system might not be that usable anymore if a critical driver keeps crashing and restarting...
In a microkernel, the various modules run as separate processes rather than as part of the kernel. For example, if your network driver crashes, your kernel keeps running. Whereas in a monolithic kernel, a driver crashing crashes the whole kernel.
As I see it a micro kernel has simply a narrower definition of what should be in "kernel land" and what should be in "user land".
Microkernels aren't a magic bullet against crashing an entire operating system, because a crash in a non-kernel component that the entire operating system relies upon, such as a central shared rendezvous server, or a server that handles "magic" values, or a central local security subsystem server, or a shared fundamental "personality subsystem" server, still crashes the entire operating system, no matter that the crash isn't in the part of the operating system that's labelled "the kernel".
The fact that driver bug in theory could overwrite any other part of the kernel is what makes it monolithic.
* Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now.
* The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore.
* Hardware became far more complex. 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.
* 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.
* 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.
* 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.
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.
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.
You're making a lot of assumptions with regards to the operating environment. What about a probe being sent to Mars, the Moon or wherever? In fact let's just generalize to space-faring craft. That environment demands incredible resiliency and the ability to continue running even if the hardware is having problems - at least enough so ground control can assess the situation and send updates.
Weapons systems are another environment you'd prefer to have resiliency. You'd hate to lose control of a missile while in mid-flight.
Automotive systems are another environment that comes to mind.
There are a lot of embedded/remote environments where the "redundant hardware" solution isn't applicable.
Edit: I'm fully-aware these systems have redundant hardware in modern implementations. I'm also fully-are that monolithic kernels are unable to cope with a failure of any of the hardware comprising the system. Hence my calling out this point.
At some point, a military device / weapons system recognises that it's not operating to spec and either disables itself or diverts and destroys itself in a non-target region.
Keep in mind that for most weapons, not activating when not specified is far more useful than failing to activate where and when specified. See the case of several "broken arrow" nuclear weapons incidents in which failsafes prevented unintended detonation. In once case with only a single fail-safe preventing that detonation which would have been in a civilian populated region of the United States.
Also, redundant hardware is quite common (and mandatory by most standards), look up TMR, triple modular redundancy
The idea that "RTOS" and "fully fledged OS" are incompatible with each other is outdated.
seL4 advanced the state of the art with its formally-verified support for mixed criticality, years ago already.
(But seriously, it’s a homegrown microkernel RTOS. Look up “Nintendo Switch System Software” if that sounds bizarre.)
https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...
You probably mean the other way around: the system comprising hardware.
The rest of your points make sense but I don't understand fully how this is an argument for monoliths? Isn't recovery from an unknown state an equally hard problem in both cases?
He's not saying that monolithic kernels make recovery easier in this case. He's saying that microkernels don't make these failures easier to recover from in practice, so you may as well take the performance gains that you will get from the monolithic kernel instead of giving up those gains for theoretical recoverability advantages that you won't actually usually see in practice.
Says who?
> * Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now.
That has very little to do with real microkernels.
> * The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore.
Not at all. The "modern" approach you are describing is many decades old and single systems are still extremely common.
I'm writing my comment, so me, based on observations over time.
> That has very little to do with real microkernels.
It doesn't matter if it's "real" or not. My point was that any selling point a microkernel can come up with can be grafted into a monolithic one.
So one of the usual selling points of a microkernel is that you can run a filesystem in userspace and eg, can allow an user to mount a network drive. Well, no need to switch kernels just for that since they added FUSE to Linux.
As an user I don't care if it's pure, I care that the job gets done.
> Not at all. The "modern" approach you are describing is many decades old and single systems are still extremely common.
Modern compared to the very old idea of the microkernel, I mean. I can see that the idea had a lot of appeal back in the era of rare, room sized computers. Keeping a single machine going is far less important in modern times, where most serious uses try their best to treat any single machine as disposable.
then there's the minix3 approach with process respawning, lots of good ideas
You can run a modern web browser, with 3d hardware acceleration, on Genode itself.
It has Virtualbox support, which is super convenient for covering any functionality gaps, but you don't need that for the above.
Virtualbox simply enabled the developers to dogfood Genode years ago already, instead of today.
So how does the real-world performance compare? That's what I'm interested in, because I keep hearing "performance is not an issue" and every time I ask for details, measurements, or something I never really get an answer.
Reality beats theory every day of the week. Communication and isolation is never free.
> But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.
Whether it has modules or not have no bearing on whether kernel is monolithic or not
A proper microkernel isn't like Linux with a bunch of modules. It's something that can your game direct access to the GPU, while restricting access to a pseudo-root on your disk, and to an edited raw RAM that pretends the spyware from the game's DRM is running on the main system while it's actually sandboxed.
You can do something like that in a microkernel because you can replace it piecewise for a single application. You can technically do something like that on Linux, but you will never manage to.
RISC-V and seL4 cooperate closely, ensuring this does not apply anymore.
They have to pass data between themselves to communicate by exposing data and mapping memory regions/structures across, which otherwise could be a function call with a pointer.
A monolithic kernel is either running or panicked, with either valid or invalid memory. The microkernel adds more failure modes - such as previously always present parts of the system going away, resetting their internal state, hanging, being upgraded on a live system, and so on.
The costs of the protections and of IPC recovery are what push towards monolithic designs. Modern microkernels have had a lot of focus on those two areas - often being little more than memory management and IPC at the core.
I'd say even though new microkernel systems haven't displaced the current ones, research on these newer "nano kernels" have borne fruit in various hypervisors.
I've done so in this case.
> * APIC, SMP, and 64bit support was improved a lot: they now do boot a complete Debian system, but some bugs remain to be fixed.
https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038...
I'l admit I'm not really sure what market segment Hurd is targeting. Presumably the goal is to replace in the GNU stack Linux at some point? If so only supporting niche/hobbyist CPUs (unless we're talking about really low power embedded applications) seems not like the best approach
The CPU is boring -- x86 instruction encoding is a bit ugly, but it works. It's all the stuff hanging off them that make the difference, and as far as I'm aware, risc-v hasn't done anything interesting here. It hasn't even enhanced discoverability (eg, by hanging internal peripherals off a virtual PCI bus).
I don't see how could it be more open that ARM longterm since there are no incentives to release high-end core designs for free. I mean I full see the potential for more competition between different companies designing proprietary cores which seems like an improvement over x86 from the consumer perspective but that's it..
Refer to OS-A Platform.
RISC-V is going beyond anybody else, standardizing peripherals that are common and very much solved problems, but aren't standardized elsewhere.
Things such as GPIOs, watchdogs, uart, timers and what not.