Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

I love how much things have progressed. I remember I used to have to set up a clean build to run while I was at school so it could be done when I got back. Now it is done within seconds.

The drivers aren't part of the microkernel and run with limited privilege. So, yeah, OK, if you wrote all those drivers you'd have a lot of code, but not all of it would have total control of the system. You can't really make a direct comparison.

Linux has a hell of a lot of system calls and weird bells and whistles in non-driver code, too.

That's the big unknown question with microkernels. It was (in the 90s) a reasonable theory that a microkernel could be much more robust and secure and easy to develop than a monolithic kernel.

It would be more robust because individual services could crash and restart. That could really work for, say, WiFi drivers. It doesn't quite work for disk drivers or the file system, since how do you even restart something without a file system?

It would be more secure because drivers would live in isolated memory spaces. So a non-critical piece like a printer driver couldn't read memory from something more critical like a file system. Part of what changed since microkernels were originally proposed is that drivers are often split into low- and high-level parts. So a printer driver in Linux consists of a standard USB or network driver in the kernel, plus a user-level driver that can be worked on like a microservice. And the WiFi driver is a low-level driver plus wpa_supplicant running at user level. The USB and network drivers are shared with critical services, so you can't easily restart them anyway.

It would be easier to develop because you can restart just the piece you're working on without rebooting the whole kernel. That's a plausible argument, but somewhat undermined by HURD taking 30 years to develop. But there were many other reasons for that.

I guess the way to convince yourself one way or another is to try writing a driver for both.

This... didn't answer my question? For many that are concerned with containers and such, they also have to audit the container process code. Such that, fine, try to use that to inflate the numbers on Linux.

Pointing at literally decades of device drivers as why the size of the code is bad, while acknowledging that it will take time to write device drivers so this will work on a respectable amount of hardware just feels weird.

That all said, please don't take this as a criticism of any of these ideas. I confess seeing Hurd in the headlines gave me a smile. Is nice to see people can still work on many ideas out there. I am only questioning the "size of code bad!" right next to "it will take us a long time to replicate a large portion of the code we just pointed at."

I understand what you're saying, but both are true.

1. Linux is too big. Even if we exclude the drivers, which are a majority of the kernel codebase, linux is still a massive kernel. Most microkernels are small enough to fit in the L3 cache, some are small enough to fit in the L2 cache. Linux, even if we could exclude the drivers, doesn't even come close. This inability to fully cache the kernel ends up negating the primary benefit that monolithic kernels have, which is performance. Linux spends more time bouncing around the cache than a modern microkernel takes to do an extra syscall.

To add to this, unless you are compiling your kernel specifically for your machine, your kernel is going to be a bloated compromise of the set of drivers that your system is most likely to see. That means that you will have dozens, if not hundreds of drivers compiled into your kernel which will never need to be used.

It's also too big in the sense that there are now far too many lines of code to be able to effectively monitor for vulnerabilites. That codebase size won't change when having a microkernel with the same number of drivers, but what will change is the ability of a single vulnerability to compromise your whole system. You have effectively compartmentalized vulnerabilities to their own address space. So in that sense, big codebases are a huge problem for monolithic kernels, but only a small problem for microkernels.

2. It will take time to write a ton of device drivers, simply because most of them aren't written yet. To that extent, Linux most definitely has an incumbent advantage. But that isn't to say that microkernels also have an advantage here. Anyone who has written a driver knows how much the ability to iterate quickly is helpful. Drivers in userspace can be written directly on the system that they will run on, with no virtualization or kernel reboots necessary, and with incredibly fast start/restart/stop. Userspace drivers are dramatically simpler to write, simpler to build, simpler to monitor, simpler to test, and simpler to distribute.

With all that being said, I definitely don't think Hurd is the future. But what could change the world is already out there but not really ready to use at the moment. One possibility would be an open-sourcing of QNX which is an amazing and incredibly mature microkernel OS, possibly the most mature in the world. If there are any bored billionaires out there reading this, please buy QNX from Blackberry and do that. Another possibility would be to put a shit ton of effort behind the SeL4 userspace, which is just too damn hard to do anything practical with at the moment.