[deleted]
Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way
81–90 of 273 posts
Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way
#82Kind 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...
That’s a neat way of visualizing it.
It is interesting that the “remainder” chunk of the drivers is so big. Wonder if they need some more categories.
Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way
#83Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way
#84Earlier 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 a very real sense, the hardware has given a realization of microservice ideas, but at the hardware level. My WIFI card, the common and popular example, probably has more processing power than some of the early desktop computers back in the day. Certainly SSDs are getting much more complicated.
They aren't general purpose, but I presume microkernel "services" would also not be general purpose?
Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way
#85Earlier 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…
>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.
Linux IPC syscall latencies benchmark in the 10s of microseconds typically. SeL4 has worst case execution guarantees that are better than that, even counting the fact that you have to do two syscalls for every one Linux syscall. We’re talking less than a thousand cycles total, which would be less than a single microsecond.
Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way
#86Kind 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.
With a microkernel model, most of those drivers would run in user space, not kernel space. So it's possible for the device drivers to be large but the GNU HURD kernel itself to be much smaller than the Linux kernel.
Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way
#87Kind 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.
> Isn't that a large part of the source tree? For Linux, yes. For a microkernel, those are different trees of userspace software. Not to say, Hurd itself is userspace software, that runs over a microkernel (included on the distribution).
> For Linux, yes. For a microkernel, those are different trees of userspace software.
If that were the argument, then the comparison with Linux would be meaningless. Hurd is much bigger than freertos, should everyone switch?
Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way
#88Earlier 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…
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.
Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way
#89Kind 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.
Can get a sense of how long it takes to compile here https://openbenchmarking.org/test/pts/build-linux-kernel surprisingly fast with modern processors.
I used to compile kernels on a 2012 HP quad-CPU, 80 thread machine. It would finish in a minute and a half or so. I got a ryzen 5850 to replace it, it also takes a minute and a half or so - but uses 1/4th the power at the wall. 32 threads vs 80, 250W vs 1000+W
Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way
#90Kind 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.
And given what the modern Linux kernel does, alongside the power of modern systems (even embedded ones), it's also difficult to argue that the Linux kernel is too large by any stretch of the imagination.
my entire kernel, including all drivers needed for my system except the nvidia blob is 11MB - 10876160 bytes. i don't optimize for size, necessarily, i'm sure i could get it down a lot more if i disabled most of the "default enabled" stuff in a modern kernel that assures it will boot on a majority of systems.