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

51–60 of 273 posts

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

#51

Post by account-5 »

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…

What are your thoughts on Fuchsia? Not QNX but definitely got billions behind it (until Google kill it that is).

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

#52

Post by marcosdumay »

OfSanguineFire wrote: post #15

I’m surprised to see that Mach is still the microkernel for Hurd. When I last (very casually) followed Hurd development two decades ago, Mach was generally regarded as obsolete and there were hopes to base Hurd on a new microkernel like seL4.

Oh, interesting, people created a GNU clone of Mach, removing the licensing problem that all but killed the project early on its life.

For the ones not in the know, Mach is an OS designed after the idea of "the network is your environment, not the computer" where it should make little difference if the resources you are accessing is on your computer or not. And "resource" here is really generic, meaning things like files, login information, printers and other periferals, CPU, whatever.

For some reason (maybe related to costs and licensing), people never adopted the idea... and insisted on reimplementing it with unreliable hacks and lots and lots of problems on top of every other OS out there instead of just having it on the OS itself.

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

#53

Post by toast0 »

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…

> 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.

I imagine there's two pools of Linux users: those that compile their own kernel, probably with only the drivers they use; and those that use distribution kernels, which have a small set of compiled in drivers, and a huge initrd with all the drivers. Neither one of those groups ends up with all of the drivers loaded into memory: the compile their own have a small set, the distro kernel people end up with only the drivers they need loaded; both groups have a relatively small kernel footprint.

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

#54

Post by taeric »

klodolph wrote: post #41
taeric wrote: post #31

Earlier quoted context omitted.

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…

It really depends on what all is done "in the driver," though? Since, per the application, the data may have been passed off to the driver with a successful message pass. And if I have to have secrets in the driver for it to be able to connect to access points and such, it seems dubious how protected from all of my secrets the system can be between all parties.

MIDI is actually an easy example, all told. If I unplug and replug a keyboard in, I expect it to probably not handle any persistent state of the keyboard correctly. (For fun, it is common for the "at rest" value of peddles to be discovered at connect time. Good luck with that if the driver crashes.)

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

#55

Post by taeric »

darksaints wrote: post #42
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?

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

Fair. I'm not a fan of apples to oranges comparisons without leaning into more of it. Especially not when the obvious driver for difference between two things is that one is old and has a ton of the code you are currently behind on writing.

I do question if process isolation isn't fundamentally hard. Separate processes for separate things entirely is not fundamentally hard. That, I agree. But, so much of what we do is integrated together. Is why early attempts to make it so that some programs can't see my whole hard drive are bonkers annoying. I specifically want access to the picture I just saved in that editing program so that I can email it.

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

#56

Post by tredre3 »

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?

> I'm very open to that debate, but then show it. Exclude the drivers from the numbers. To do otherwise feels very dishonest.

With drivers:

    ---------------------------------------------------------------------------------------
    Language                             files          blank        comment           code
    ---------------------------------------------------------------------------------------
    C                                    32699        3332747        2610014       17218820
    C/C++ Header                         23690         712617        1373965        7109290
    Assembly                              1336          48534         101884         234314
Without drivers:

    ---------------------------------------------------------------------------------------
    Language                             files          blank        comment           code
    ---------------------------------------------------------------------------------------
    C                                    13200        1031558         951267        5356551
    C/C++ Header                         13760         300309         535100        1643611
    Assembly                              1321          47500         100899         230638
Seven million lines without drivers. Linux is huge. I'm sure you'll move the goalposts further though, so what should I do next? Delete most stuff in arch/ and samples/ ?

Numbers obtained by running cloc 1.96 on current kernel master.

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

#57

Post by taeric »

strbean wrote: post #40
taeric wrote: post #31

Earlier quoted context omitted.

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…

> Ok, your wifi driver restarted. What are the protocols to get everyone caught up between that driver and your application for what messages were lost and the messages that are now arriving? TCP?

Doesn't fully help? Could actually be more difficult if you let the driver do the TCP ack. And you are likely going to back yourself into a situation where you need TCP between the application and the driver... Remember, at that point, it is just a message pass, as well.

There is a good article somewhere about how you have to do end to end for any of this to really work.

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

#58

Post by taeric »

tredre3 wrote: post #56
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. With drivers: --------------------------------------------------------------------------------------- Language files blank comment code --------------------------------------------------------------------------------------- C 32699 3332747 2610014 17218820 C/C++ Header 23690 712617 1373965 710…

This seems to just support my criticism, though? Even without the drivers, it is still a big number, but is literally less than half the lines of code shown before? Why inflate what you show just to get an absurd comparison?

I think many are misunderstanding my criticism here. I offer it more as a way to strengthen the message than I do to question it entirely.

To that end, the only "goal post shift" I would add is to ask how many of the 17 million lines of driver code have to be done for Hurd to support hardware that would make it more relevant for a ton of users?

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

#59

Post by dpe82 »

anon25783 wrote: post #50
ye-olde-sysrq wrote: post #29

Earlier quoted context omitted.

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.

What, specifically, is different?

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

#60

Post by rekado »

gattilorenz wrote: post #20
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.

Heh, not a particulary in-depth article in any way, to be honest. "the GNU/Hurd is Unix(POSIX)-compatible, so most things work"... well that's to be said for MacOS, QNX, etc. In practice, where is the "65% of the Debian archive can be built for the Hurd" figure coming from? I'm sure it can be built in theory, how much does it require source modifications?

Here's a list of failing packages with reasons for failure: https://people.debian.org/~sthibault/failed_packages.txt

And here's the overview on how many packages have successfully been built vs how many have failed: https://buildd.debian.org/status/architecture.php?a=hurd-i38...

The number of packages that can be built have been built; it is not a theoretical number.

Post reply on HN