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

71–80 of 273 posts

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

#71

Post by dralley »

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…

>This inability to fully cache the kernel ends up negating the primary benefit that monolithic kernels have, which is performance.

OK then, so, which microkernel provides performance on-par with or better than Linux?

This is a strong claim and some evidence is warranted.

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

#72

Post by dale_glass »

monocasa wrote: post #66
dale_glass wrote: post #32

Earlier quoted context omitted.

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.

I'm honestly not sure which counts for this purpose, physical or virtual? And which fraction do you get to use on HURD?

But still, 256 TiB is just a dozen drives these days. Not a very consumer-like configuration, but very much a limit you can run against.

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

#73

Post by jacquesm »

Once upon a time the Hurd was the future. But that time is long in the past and nowadays the Hurd is a relic and I don't see any chance of a revival. Something entirely new probably stands a better chance at arousing some interest than the Hurd.

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

#74

Post by RoseRose »

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…

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

We could afford that before, it's just that Linus didn't see the value and put his foot down. Which is definitely a choice.

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

#75

Post by darksaints »

bityard wrote: post #67
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…

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

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

Writable caches yes. However many (most?) modern processors also contain a code-only cache which can be used for OS caching without any need to flush. The raspberry pi 4 can fit many modern microkernels in their tiny immutable cache, so it gains a massive caching benefit by being small.

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

You’re probably right, I was unaware of the extent of the kernel module usage. Regardless, the smallest common kernel in use that I know about is for alpine Linux and that is still at least 100MB, which is dramatically larger than the <1MB microkernels that are typically available.

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

#77

Post by darksaints »

account-5 wrote: post #51
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…

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

Fuschia is definitely interesting but I don’t really see a lot of non-Google work being done with it and while google is worth billions, it doesn’t seem like they’re investing billions into fuschia specifically. I’d say caution is warranted but it’s certainly a possibility if there were more non-google players in the ecosystem.

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

#78

Post by weberer »

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.

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

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

#79

Post by twic »

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

This makes no sense. The comparison that matters isn't kernel vs microkernel, its kernel vs microkernel plus all the userland code needed to implement system services. If my program wants to read a file and write to the network, then the code to do that has to be brought to the CPU to run before my program can finish doing that, and it doesn't matter whether that is in the kernel or userland.

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

#80

Post by taeric »

strbean wrote: post #38
taeric wrote: post #9

Earlier quoted context omitted.

I get that. But it is still an unfair dig when a large chunk of the code that is being pointed at is the code that they will have to write? (Granted, they can put an easier line in the sand on how far back they go on what they support hardware wise, but still...)

Code that will have to be written, but won't be part of the kernel. I think that's on the cusp of fair/unfair.

I agree it is defensible. But, it is code that has to run for me to use my computer. I'm not clear that I have reason to care about the kernel distinction, at this level. Would help the defense to lean in and show legit and not theoretical examples of it.
Post reply on HN