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

Post by gattilorenz » Mon, Aug 07, 2023, 8:21 PM UTC

rekado wrote: post #60

gattilorenz wrote: post #20

Earlier quoted context omitted.

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 by molticrystal » Mon, Aug 07, 2023, 8:35 PM UTC

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.

Post by bonzini » Mon, Aug 07, 2023, 8:45 PM UTC

praptak wrote: post #88

anon25783 wrote: post #70

Earlier quoted context omitted.

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…

Do we have more hardware isolation? There was a pretty strong argument against microkernels - a driver running in userspace can still bork the whole machine if the hardware being controlled can write to memory at arbitrary addresses.

Post by Dah00n » Mon, Aug 07, 2023, 8:50 PM UTC

toast0 wrote: post #53

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…

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

Post by AtlasBarfed » Mon, Aug 07, 2023, 8:50 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…