Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mhatta.medium.com

Post reply on HN
Print view View original

41–50 of 273 posts

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

#41

Post by klodolph »

taeric wrote: post #31
tlb wrote: post #26

Earlier quoted context omitted.

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 with…

Right, I remember parts of that history. Memory protection schemes in other operating systems didn't exactly stay static, though. And a ton of the optimizations that monolithic kernels (mostly looking at windows) did went away just with the lack of need for them. Heck, at the time, Mac wasn't even a preemptive multitasking operating system. And "drivers" could just restart is laughable with a role play of it. Ok, you…

If your WiFi driver crashes and restarts, at the minimum, I think it could be treated as if you lost network connectivity for a short time. This is a situation that applications should be able to handle anyway, since it happens all the time on laptops.

There are plenty of applications out there that just don’t respond to configuration changes gracefully. For example, if you have a music program running, and then you plug a MIDI keyboard in, is the new MIDI keyboard recognized by your music program? Maybe so, and you can use it immediately. Maybe not, and you have to restart the application.

If your MIDI driver crashes, maybe the music program doesn’t handle it gracefully, and you have to quit and relaunch the program. But that is miles better than crashing the system and rebooting.

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

#42

Post by darksaints »

taeric wrote: post #33
darksaints wrote: post #30

Earlier quoted context omitted.

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…

I'm very open to that debate, but then show it. Exclude the drivers from the numbers. To do otherwise feels very dishonest. Process isolation and selinux are things that exist. You even mention it. Turns out, having complete isolation between basically everything in your system is hard. I don't see how microkernels will make that difficulty disappear?

But that is the entire point of the comparison. I get that you think an apples to apples comparison is the most honest way to portray this, but the whole point is to portray that this is an apples to oranges comparison. Linux has millions of lines of code running in ring 0, a micro kernel does not. They may end up having the same lines of code for comparable total system size, but that isn’t the point of the comparison.

Process isolation actually isn’t fundamentally hard…it’s just hard on a system that wasn’t designed for it. And SELinux doesn’t do what microkernels do. Even with a tightly locked down SELinux configuration, a driver vulnerability can lead to root access. SELinux can protect your userland the same way that microkernels do, but it can’t put your drivers in userland.

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

#43

Post by darksaints »

sterlind wrote: post #37
darksaints wrote: post #30

Earlier quoted context omitted.

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…

how different is the Hurd driver model from Linux's? is it a straightforward but tedious process to port drivers, or does it require major rethinking? I wonder if machine translation is possible, or even LLM-assisted automatic ports as a starting point. disastrous to think about, as careful as kernel code has to be, but maybe with enough static analysis and guardrails it's doable?

It is quite different, and porting drivers from Linux would be very hard to do en masse. However, other open source kernels have drivers that are much easier to port. NetBSD, for example, has a whole host of drivers that can and are used almost unchanged in other microkernels.

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

#44

Post by marcosdumay »

taeric wrote: post #3

Kind of weird to see linux called out as too big, and then the ack that writing a ton of device drivers is hard and will take time. Isn't that a large part of the source tree? Realizing I haven't even tried compiling a kernel in a long long time. Feels oddly sad to say.

> Isn't that a large part of the source tree?

For Linux, yes. For a microkernel, those are different trees of userspace software.

Not to say, Hurd itself is userspace software, that runs over a microkernel (included on the distribution).

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

#45

Post by davidw »

An idea from the 'Crossing the Chasm' book is to find a niche where whatever characteristics of the product you're working on can win. You are not going to win going head to head with the entrenched competitors.

What does that look like for Hurd?

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

#46

Post by irdc »

darksaints wrote: post #30
taeric wrote: post #3

Kind of weird to see linux called out as too big, and then the ack that writing a ton of device drivers is hard and will take time. Isn't that a large part of the source tree? Realizing I haven't even tried compiling a kernel in a long long time. Feels oddly sad to say.

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…

> Most microkernels are small enough to fit in the L3 cache

Have you looked at the size of L3 caches lately? You could fit a whole ‘nother OS in one of those.

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

#47

Post by Analemma_ »

Hizonner wrote: post #25

Can anybody compare the state of Hurd with, or point to good comparisons with, similar projects like Genode?

Even rms gave up on Hurd and it stopped being a core priority of the GNU Project a long time ago. The current maintainers/developers are doing it as a solo hobby. Which is fine, but that's what you should keep in mind as far as support if you decide to use it.

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

#48

Post by taeric »

klodolph wrote: post #35
taeric wrote: post #33

Earlier quoted context omitted.

I'm very open to that debate, but then show it. Exclude the drivers from the numbers. To do otherwise feels very dishonest. Process isolation and selinux are things that exist. You even mention it. Turns out, having complete isolation between basically everything in your system is hard. I don't see how microkernels will make that difficulty disappear?

> I'm very open to that debate, but then show it. Exclude the drivers from the numbers. To do otherwise feels very dishonest. You can ask for numbers without casting aspersions like that. This is HN. It is something like a casual conversation. You are free to ask for numbers, other people are free to provide or not provide them, and we should be able to have this conversation without leveling accusations of dishonest…

I didn't say they were being dishonest, I said it feels dishonest. Consider it a critique of the message with my reasoning given.

I was actually trying to find the numbers myself, and it was surprisingly more involved than I'd care for. I didn't want to give someone else more work, but happy to see the numbers expanded. I stand by my criticism, though. It feels off. If you want to say it is justified, spend more effort justifying it.

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

#49

Post by pessimizer »

ye-olde-sysrq wrote: post #29
AdmiralAsshat wrote: post #27

Earlier quoted context omitted.

Could one not make the case that maybe device driver support doesn't belong in the kernel itself?

Isn't this this mono vs micro kernel debate all over again?

Isn't that the subject of this entire thread?

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

#50

Post by anon25783 »

ye-olde-sysrq wrote: post #29
AdmiralAsshat wrote: post #27

Earlier quoted context omitted.

Could one not make the case that maybe device driver support doesn't belong in the kernel itself?

Isn't this this mono vs micro kernel debate all over again?

Things are perhaps a bit different now than when Torvalds and Tanenbaum debated the issue on comp.os.minix over thirty years ago.
Post reply on HN