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

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

#131

Post by mike_hearn » Mon, Aug 07, 2023, 9:51 PM UTC

anon25783 wrote: post #70

dpe82 wrote: post #59

Earlier quoted context omitted.

What, specifically, is different?

The machines are different. Multicore 64-bit chips are now standard for consumer PCs. RAM and persistent storage are faster and much more abundant. The architecture of the modern x86-64 is much more sophisticated than that of the 386 for which the earliest Linux was written. Vectorization, predictive branching, and asynchronous code are all front and center in the modern programmer's ecosystem. In short, hardware is…

Being a microkernel doesn't automatically make you more robust. If you look at their docs, Hurd has only one feature that's different to Linux and that's a sort of souped up FUSE. But as they realized later, allowing arbitrary unprivileged programs to extend the filesystem like that doesn't mesh well with the UNIX security model. You can write a "translator" that redirects one part of the filesystem tree to another, so you get the same issues as with chroot or symlink attacks. Their proposed solution (never implemented?) is to stop programs paying attention to translators by default if they are running as a different user. There are other cases where translators can DoS apps or do other undesirable things.

The basic problem is that the kernel boundary is a trust boundary. You assume that anything in the kernel is legit and won't try to attack you, which simplifies things a lot. In the microkernel world the original idea was that all the servers would be just ordinary programs you could swap in and out at will. But then the threat model becomes muddied and unclear. Is it OK to run a server that's untrusted? If so, to what extent?

The Hurd seems under-designed as a consequence. To make that vision work you'd need to be willing to depart from UNIX way more, which really means being a research OS.

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

#132

Post by kelnos » Mon, Aug 07, 2023, 9:51 PM UTC

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.

These days most Linux distros build pretty much any driver as a module that can be built as one. Boot-critical modules (like NVMe drivers) are included in the initramfs so they're available before the disk is mounted.

I agree that Linux is still larger than a microkernel, but very few users have a bloated kernel in RAM due to lack of customizations.

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

#133

Post by phant0mas » Mon, Aug 07, 2023, 9:51 PM UTC

You can try using it through Guix :)

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

#134

Post by heavyset_go » Mon, Aug 07, 2023, 9:55 PM UTC

AdmiralAsshat wrote: post #27

dwheeler wrote: post #8

Earlier quoted context omitted.

I agree, it's odd. I don't have anything recent, but back in 2004, the majority of the Linux kernel code was in its drivers: https://dwheeler.com/essays/linux-kernel-cost.html I expect that most of the current Linux kernel code is also for handling hardware (that is, drivers + the code to handle various architectures).

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

The Linux kernel driver API/ABI isn't stable so there's no permanent/versioned interface you can program against that would make out-of-tree drivers non-headache inducing: https://www.kernel.org/doc/Documentation/process/stable-api-...

> You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.

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

#135

Post by Affric » Mon, Aug 07, 2023, 9:57 PM UTC

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…

You can get 32MB L2 cache on an Intel i9 13000k and maximum size of a compiled Linux Kernel appears to be around 8MB.

I am not going to pretend I have any idea because I have just googled these numbers but it seems to me that an amount of cache could be reserved for the kernel without too much of a hit to applications on what are currently high end machines.

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

#136

Post by kelnos » Mon, Aug 07, 2023, 9:57 PM UTC

darksaints wrote: post #69

irdc wrote: post #46

Earlier quoted context omitted.

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

Okay, so there are a handful of massive $4k+ chips that can fit the Linux kernel in the L3 cache. Meanwhile, you could fit 5 copies of the SEL4 kernel in the L2 cache of a raspberry pi.

Which is fine for a program that does essentially nothing. But once a program wants to talk to the network or disk, or display something on the screen, it needs more system services that need to come from somewhere. Can you fit all of those in the caches too?

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

#137

Post by lutoma » Mon, Aug 07, 2023, 9:58 PM UTC

winter_blue wrote: post #108

weberer wrote: post #78

Earlier quoted context omitted.

Yes, its mostly drivers. Here's a breakdown of the Linux kernel by lines of code: https://upload.wikimedia.org/wikipedia/commons/f/f5/Sankey_D...

Wow, I'm surprised by how small the file systems are. On the smaller side, Ext4 at just 21,515 lines, and on the larger side, Btrfs at 55,758 lines. It almost makes me think that writing a new file system in Rust, might actually be a tractable project.

I'm writing a hobby kernel/operating system and one of the things that surprised me was how simple ext2 is. It really isn't much different from fat32 in many ways, just a bit more flexible and designed in a more future-proof way.

Obviously ext2 is a very outdated filesystem by today's standards, but considering ext3 and ext4 are essentially just some extensions slapped onto ext2, I still didn't expect it.

Another thing I found really impressive was just how resilient e2fsck is. During early development of my ext2 code I frequently mangled the file system in a myriad of weird ways, but no matter how much I broke things, e2fsck was almost always able to restore the file system into a reasonable state.

(For the curious, there is some excellent documentation on the ext2 file system at https://www.nongnu.org/ext2-doc/ext2.html that I mostly used for my implementation of it. Sadly no such thing seems to really exist for ext3/ext4).

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

#138

Post by PaulDavisThe1st » Mon, Aug 07, 2023, 9:58 PM UTC

meepmorp wrote: post #128

PaulDavisThe1st wrote: post #122

Earlier quoted context omitted.

[flagged]

It's a good thing that you warned them off, or they might've accidentally gone and done something interesting or enjoyable.

Yep, because everyone who is going to do something interesting or enjoyable starts with the question "should I use language X because it's cool?".

Look, I'm as into cool FS-hacks as anyone, but writing a new filesystem has 99+ problems and the language used is either the last of them, or it isn't even in the set.

Granted, you could (on Linux) write a little pseudo-filesystem (e.g. /proc or /sys) and not face any of the issues involved in extN or btrfs etc. I didn't get the sense that this was what the OP intended, but I could be wrong.

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

#139

Post by PaulDavisThe1st » Mon, Aug 07, 2023, 9:59 PM UTC

actionfromafar wrote: post #127

ssrc wrote: post #62

Earlier quoted context omitted.

I think it's monorepo vs multi-repo, and since Linux maintainers update the drivers (I believe) when internal APIs change, and the internal APIs are not stable, monorepo seems more practical.

Maybe I’m missing the joke, but in or out of kernel context is orthogonal to how the source code is stored.

"how the source code is stored" is what leads to "wow, the linux kernel is really big". Nobody's measuring kernel size by the number of resident pages it takes up.

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

#140

Post by anyfoo » Mon, Aug 07, 2023, 10:00 PM UTC

marcosdumay wrote: post #52

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

> 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. [..] For some reason (maybe related to costs and licensing), people never adopted the idea...

I personally think it's a pipe dream, and the way history worked out seems to confirm that.

Truly transparent networking never really worked out anywhere. The better RPC solutions in use, for example, make it very obvious that an RPC is an RPC, instead of looking like a local function call. In file transfer, it has been common to e.g. replace NFS with something HTTP based for quite some time. "Cloud" file systems seem to operate at a much higher layer, preferring external syncing and special high level APIs with only some actual OS support sprinkled in.

For Operating Systems, a lot of Mach breaks down when you want to do things fast and securely.

It's a testament to APIs better being shaped by locality. Roughly and informally spoken, the closer you are to the actual CPU, the more "lightweight" and "direct" your API can and should be. The further you move away, the more resilient you need to become, and the more control and insight you need to give the caller about the actual transport.

To pick two very real extremes as an example: When writing to a register on a local bus, you often just assume it will work. If it doesn't, a panic is sensible (sometimes even worse, like a lockup leading to a watchdog timeout). When trying to invoke a function on another server, obviously that's not acceptable. Then you want to be able to timeout, retry, inspect transport failures, fall back to other servers, configure endpoints, be picky and explicit about payload (and result), and so on and so forth.

The immense cruft necessary for the latter case becomes unnecessary and expensive the more local you are. It affects security, and can even pose chicken and egg problems.