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

101–110 of 273 posts

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

#101

Post by dralley »

darksaints wrote: post #85
dralley wrote: post #71

Earlier quoted context omitted.

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

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

#102

Post by naasking »

rayiner wrote: post #19
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.

HURD (the parts that aren't the rest of the GNU OS) is mainly a set of servers for Mach. These are closely coupled to how mach handles IPC, how it handles virtual memory, etc. Apparently, there were also shortcomings in L4 itself, or at least with respect to what HURD wants to do with its microkernel: https://www.gnu.org/software/hurd/history/port_to_another_mi...

> Apparently, there were also shortcomings in L4 itself, or at least with respect to what HURD wants to do with its microkernel

Yes, that was the issue as I recall. But seL4 is an excellent, secure high-performance microkernel. If something is painful to do in L4, it will likely not be faster or more secure running under any other microkernel, and so you should arguably question the wisdom of what you're trying to do.

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

#103

Post by mcv »

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…

> 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 now I hear that even after 3 whopping decades, it still doesn't run on real hardware! Entire operating systems have been born and died in that time.

What is the problem that's making Hurd still not work?

> 2. It will take time to write a ton of device drivers, simply because most of them aren't written yet. To that extent, Linux most definitely has an incumbent advantage.

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

> But that isn't to say that microkernels also have an advantage here.

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

> With all that being said, I definitely don't think Hurd is the future. A Why not? And is this why nobody has been writing those drivers?

I don't mean to be shitting on Hurd, but it's been really promising for so long, and not delivering, that it's starting to feel like fusion power: always in the future, nearly there, but never quite here.

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

#104

Post by cmrdporcupine »

johnny22 wrote: post #34
pengaru wrote: post #18

Earlier quoted context omitted.

I used to idle in the hurd irc channel and there was definitely someone working on smp support, but it was just one person's pet project apparently. They seemed to have things working in an experimental setting, but I don't think anything landed upstream. It was clear there's a severe lack of manpower on the project. I think it'd have to be rewritten in rust or something hip to get new blood today.

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

But others disagree, and these days Apache/MIT type licenses proliferate.

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

#105

Post by cesarb »

twic wrote: post #79
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, 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 mak…

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

And also, what matters for performance is the size of the "hot" code. A lot of code, both on a monolithic kernel and on the userland code implementing system services for a microkernel, is going to be "cold" code which executes rarely. This includes initialization code, shutdown code, most of the error handling code, code to react to uncommon hardware events, and so on.

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

And given that the essential complexity is the same, it's very likely that the size of the relevant code is similar.

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

#106

Post by toast0 »

Dah00n wrote: post #97
toast0 wrote: post #53

Earlier quoted context omitted.

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

Can you use vulnerabilities in a driver that's there but not currently loaded?

Not unless you can trigger the system to load it.

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

#107

Post by emptysongglass »

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…

On the topic of the Linux kernel, why is it that modules and config options are so poorly documented, often not at all? I remember when I was compiling my own kernel, many options and modules I'd just have to guess based on my hardware. I understand Torvalds to be an incredibly demanding BDFL. I'd assume he'd insist on clear helper docs for any modules that wish to merge.

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

#108

Post by winter_blue »

weberer wrote: post #78
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...

Wow, I'm surprised by how small the file systems are.

On the smaller side, Ext4 at just 21,515 lines, and on the larger side, Btrfs at 55,758 lines.

It almost makes me think that writing a new file system in Rust, might actually be a tractable project.

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

#109

Post by mschuster91 »

Dah00n wrote: post #97
toast0 wrote: post #53

Earlier quoted context omitted.

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

Can you use vulnerabilities in a driver that's there but not currently loaded?

No, and this is what saved a lot of people's arses many times over. A lot of the CVEs for the Linux kernel turn out to only be exploitable under very specific circumstances.

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

#110

Post by m463 »

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.

Isn't macos Mach?
Post reply on HN