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

111–120 of 273 posts

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

#111

Post by cesarb »

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…

> 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 files, login information, printers and other periferals, CPU, whatever. For some reason (maybe related to costs and licensing), people never adopted the idea

To me, the reason is obvious: what happens when someone unplugs the network cable? This is #1 in the list of distributed computing fallacies (https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...): "the network is reliable". The other fallacies on that list might also be relevant.

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

#112

Post by darksaints »

mcv wrote: post #103
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…

> 1. Linux is too big. Too big for what exactly? Because it's clearly not too big to run. It's been running very well for decades, and Hurd has not. I've known for decades that on paper, microkernels and Hurd should be superior, and I've wondered for nearly as long why then they aren't taking off. If they're so good, they should at least be thriving in some niche where that performance matters, shouldn't they? And no…

> I've known for decades that on paper, microkernels and Hurd should be superior, and I've wondered for nearly as long why then they aren't taking off. If they're so good, they should at least be thriving in some niche where that performance matters, shouldn't they?

They (microkernels) thrive in Automobiles, Aircraft, Spacecraft, Security systems (such as hardware encryption devices), Defense Munitions, Embedded Devices, Maritime devices, radar systems, and many other areas. The common thread here is that they are not just resource constrained and performance sensitive, they are also typically very specialized and mostly write-from-scratch.

That last part is the key to understanding why general purpose operating systems mostly use legacy kernels that are decades old. We want to preserve as much as we can from what came before.

> But why is Linux the incumbent when Mach and Hurd were conceived 3 years earlier?

Because Linux worked earlier. Nobody in the GNU ecosystem knew how to develop a microkernel that worked, let alone drivers for a constantly changing target OS.

> I would love to believe that, but then why has that advantage not paid off for 30 years?

Again, they have. Almost all RTOSes are microkernels, and the most popular embedded OSes are microkernels. When you're writing something from scratch, it is always going to be easier with a microkernel. Don't mistake Hurd with the concept of a microkernel. Hurd sucks because it has always sucked. It's bloated, poorly documented, relies on a very janky GNU ecosystem that has already mostly adapted to Linux out of practicality concerns, and there is no ecosystem tooling around it.

But the advantages of microkernels in general are very real. The best one out there in terms of maturity is QNX, and while practically every modern car on the planet runs on it, it's licensing pretty much precludes it from being used as a general purpose OS.

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

#113

Post by mschuster91 »

dralley wrote: post #101
darksaints wrote: post #85

Earlier quoted context omitted.

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. https://www.sel4.systems/About/Performance/home.pml

Does SeL4 have all of of the speculative execution mitigations that Linux has? Syscall latency also is not the end-all-be-all of performance. Does that actually translate to faster disk and socket I/O on average?

> Syscall latency also is not the end-all-be-all of performance.

That depends on what you're doing. If you're running some digital signage display or whatever, no one cares about a missing display frame or whatever. But if you're running a car's HUD or, worse, its steering system, you absolutely need the execution time guarantees or your code won't make it past certification.

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

#114

Post by stavros »

bee_rider wrote: post #82
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...

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.

I was expecting a block chart, kind of disappointed it isn't.

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

#115

Post by winternewt »

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…

RAM is faster but CPU is even faster. The latency chasm between CPU and RAM has increased.

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

#116

Post by davidw »

ssrc wrote: post #62
ye-olde-sysrq wrote: post #29

Earlier quoted context omitted.

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.

There's something clever to say about the author of Linux vs the author of Git, but it's not coming to mind right now...

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

#118

Post by dralley »

mschuster91 wrote: post #113
dralley wrote: post #101

Earlier quoted context omitted.

Does SeL4 have all of of the speculative execution mitigations that Linux has? Syscall latency also is not the end-all-be-all of performance. Does that actually translate to faster disk and socket I/O on average?

> Syscall latency also is not the end-all-be-all of performance. That depends on what you're doing. If you're running some digital signage display or whatever, no one cares about a missing display frame or whatever. But if you're running a car's HUD or, worse, its steering system, you absolutely need the execution time guarantees or your code won't make it past certification.

I'm not saying it's not an important space, because it is. But the majority of use cases are not that latency-sensitive. And if you're not that latency-sensitive, it's not obvious that microkernels like SeL4 and QNX are faster than Linux, for the relevant definitions of faster.

And likely it's not even close when you take into consideration the capability gap between Linux and competitors, that is to say, the "fatness" comes from legitimately useful functionality, or compatibility, that any alternate kernel may need to implement to replace Linux for its own use cases, and not because something is wrong with Linux.

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

#119

Post by bpye »

cmrdporcupine wrote: post #104
johnny22 wrote: post #34

Earlier quoted context omitted.

Redox seems like it's a bit farther along than hurd in some repects https://www.redox-os.org/

It's very cool, but the MIT license on that means it will never fit the niche (mainly ideological) that the Hurd was aiming at. I actually think GPL is key in long-term adoption and is part of at least the early part of Linux's success. To prevent fragmentation. To coax commercial entities to contribute. And to generally encourage community development, rather than forks (since forks require distributing source anywa…

I'm not convinced that the license is the biggest motivator today for vendors getting code to upstream Linux. Look at LLVM - Sony has spent significant effort landing support for PlayStation targets there, the license doesn't require it, but it means they aren't chasing such a moving goalpost with some internal tree.

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

#120

Post by marcosdumay »

cesarb wrote: post #111
marcosdumay wrote: post #52

Earlier quoted context omitted.

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…

> 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 files, login information, printers and other periferals, CPU, whatever. For some reason (maybe related to costs and licensing), people…

> what happens when someone unplugs the network cable?

About the same thing that happens when you unplug your corporate Windows machine. You only have cached and local resources.

People insist on using all of that functionality. People also insist on implementing it by hacks everywhere with nothing talking with each other and each part failing for its own reasons.

Post reply on HN