Live data from Hacker News

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

mhatta.medium.com

61–70 of 273 posts

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

#61

Is it really alive? No SMP, no stable x64 port. No ARM port.

See https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038...

> * APIC, SMP, and 64bit support was improved a lot: they now do boot a complete Debian system, but some bugs remain to be fixed.

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

#62

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?

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.

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

#63
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?

NetBSD has architectured their drivers to be basically static archives reusable anywhere. It's part of the NetBSD rump kernel.

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

#64
post #45

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?

>You are not going to win going head to head with the entrenched competitors.

Linux, (not big and professional like gnu), is not going to win but could find a niche somewhere. Hm, ok.

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

#65
post #64
post #45

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?

>You are not going to win going head to head with the entrenched competitors. Linux, (not big and professional like gnu), is not going to win but could find a niche somewhere. Hm, ok.

Yep, it found a "niche": people could actually hack on it and get it to do stuff, rather than waiting around for the other thing, which wasn't even really a thing yet anyway.

Linux has a large, large established user base at this point. If you want to attract people to a different platform, you need a compelling reason.

For people just looking to look/experiment/learn/play, 'something new' that's more easily understood because it's small might be enough, but that's unlikely to be a large user base.

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

#66
post #23

> The GNU Hurd’s hardware support is poor, so trying to run it on modern physical machines is suicide. > ...one reason for using GNU/Hurd is that the Linux kernel has become too huge By any chance, are these two statements related? Is it smaller because it lacks the drivers?

I also recall it having some ridiculously low limit for partitions, like 1GB or something. Apparently because it mmaps the entire disk, and under 32 bit CPUs there's not enough address space. Which is a ridiculous technical limitation. You could have bigger disks than that by the mid 90s. Come think of it, my Ryzen 9 3950X supports 43 bits of address space which works out to 8TB. So if that limit applies, even the 64…

A 3950x has 48 bits of virtual address space, or 256TiB.

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

#67
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

Is that important, though? As soon as you start processing any meaningful amount of data, won't your OS be evicted from the cache anyway?

> 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'm not sure this is true. Device drivers are typically compiled as modules, which are only loaded into the kernel if needed. Common wisdom among Linux power users for the last decade or so has been that compiling your own kernel for any tangible performance/memory improvement is basically futile.

Are there exceptions to this that you are aware of, and can elaborate on?

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

#69
post #46

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…

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

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

#70
post #59

Earlier quoted context omitted.

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?

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 more capable, and so perhaps now we can afford to take more opportunities to trade a little bit of overhead for abstractions that are more modular and robust.

Post reply on HN