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

31–40 of 273 posts

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

#31

Post by taeric »

tlb wrote: post #26
taeric wrote: post #17

Earlier quoted context omitted.

But that is silly? If I have to audit the code for my system running, I would have to audit the code for each of the "servers" as well? If not, why not? To that end, how different is it, actually? And what are the other tradeoffs?

That's the big unknown question with microkernels. It was (in the 90s) a reasonable theory that a microkernel could be much more robust and secure and easy to develop than a monolithic kernel. It would be more robust because individual services could crash and restart. That could really work for, say, WiFi drivers. It doesn't quite work for disk drivers or the file system, since how do you even restart something with…

Right, I remember parts of that history. Memory protection schemes in other operating systems didn't exactly stay static, though. And a ton of the optimizations that monolithic kernels (mostly looking at windows) did went away just with the lack of need for them. Heck, at the time, Mac wasn't even a preemptive multitasking operating system.

And "drivers" could just restart is laughable with a role play of it. Ok, your wifi driver restarted. What are the protocols to get everyone caught up between that driver and your application for what messages were lost and the messages that are now arriving? This is effectively no different from any distributed application where similar things are unsurprisingly hard to achieve well.

I'll state that I think this is a laudable goal. And I'm happy to see people working on it. Would be thrilled to be shown I'm wrong.

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

#32

Post by dale_glass »

mhaberl wrote: post #23

> The GNU Hurd’s hardware support is poor, so trying to run it on modern physical machines is suicide. > ...one reason for using GNU/Hurd is that the Linux kernel has become too huge By any chance, are these two statements related? Is it smaller because it lacks the drivers?

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 bit version would be limited on modern hardware.

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

#33

Post by taeric »

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…

I'm very open to that debate, but then show it. Exclude the drivers from the numbers. To do otherwise feels very dishonest.

Process isolation and selinux are things that exist. You even mention it. Turns out, having complete isolation between basically everything in your system is hard. I don't see how microkernels will make that difficulty disappear?

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

#34

Post by johnny22 »

pengaru wrote: post #18
pshirshov wrote: post #6

Is it really alive? No SMP, no stable x64 port. No ARM port.

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/

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

#35

Post by klodolph »

taeric wrote: post #33
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…

I'm very open to that debate, but then show it. Exclude the drivers from the numbers. To do otherwise feels very dishonest. Process isolation and selinux are things that exist. You even mention it. Turns out, having complete isolation between basically everything in your system is hard. I don't see how microkernels will make that difficulty disappear?

> I'm very open to that debate, but then show it. Exclude the drivers from the numbers. To do otherwise feels very dishonest.

You can ask for numbers without casting aspersions like that.

This is HN. It is something like a casual conversation. You are free to ask for numbers, other people are free to provide or not provide them, and we should be able to have this conversation without leveling accusations of dishonesty (which the word “feels” does not really temper).

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

#37

Post by sterlind »

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…

how different is the Hurd driver model from Linux's? is it a straightforward but tedious process to port drivers, or does it require major rethinking? I wonder if machine translation is possible, or even LLM-assisted automatic ports as a starting point. disastrous to think about, as careful as kernel code has to be, but maybe with enough static analysis and guardrails it's doable?

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

#38

Post by strbean »

taeric wrote: post #9
_8j50 wrote: post #7

Earlier quoted context omitted.

Hurd is a microkernel so it is lean by design. I suspect that statement was a dig on perceived architectural flaw of Linux.

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.

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

#40

Post by strbean »

taeric wrote: post #31
tlb wrote: post #26

Earlier quoted context omitted.

That's the big unknown question with microkernels. It was (in the 90s) a reasonable theory that a microkernel could be much more robust and secure and easy to develop than a monolithic kernel. It would be more robust because individual services could crash and restart. That could really work for, say, WiFi drivers. It doesn't quite work for disk drivers or the file system, since how do you even restart something with…

Right, I remember parts of that history. Memory protection schemes in other operating systems didn't exactly stay static, though. And a ton of the optimizations that monolithic kernels (mostly looking at windows) did went away just with the lack of need for them. Heck, at the time, Mac wasn't even a preemptive multitasking operating system. And "drivers" could just restart is laughable with a role play of it. Ok, you…

> Ok, your wifi driver restarted. What are the protocols to get everyone caught up between that driver and your application for what messages were lost and the messages that are now arriving?

TCP?

Post reply on HN