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

151–160 of 273 posts

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

#151

Post by broodbucket »

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 arch/arm (which is 32bit) is bigger than x86 and powerpc which have 32/64 under the same subsystem. I guess it's mostly device tree bindings?

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

#153

Post by nephanth »

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…

Going in that configuration screen, looking up all those modules to check whether you need them, and checking / unchecked them takes so much time I would imagine some people who compile their own kernel don't bother

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

#154

Post by TheMagicHorsey »

The concept of microkernels is cool for security ... the only thing cooler in OSes is maybe unikernels :P

And certainly the time is ripe since we have such powerful and capable machines even in the pockets of our pants ... we can certainly waste a little bit of resources to work with more secure layers of abstraction ... yes?

But Hurd has taken so long, I feel like Google Fuschia might dive in and capture everyone's imagination with a more modern and practical implementation of the concept. To be clear ... neither Hurd nor Fuschia are really practical today ... I just feel like its more likely Google might throw a few hundred million at the project if it pans out in the few places its currently being field tested (like in Google Home devices).

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

#155

Post by abhiyerra »

stusmall wrote: post #22
muixoozie wrote: post #13

Earlier quoted context omitted.

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 love how much things have progressed. I remember I used to have to set up a clean build to run while I was at school so it could be done when I got back. Now it is done within seconds.

Ha. Yeah. Remember taking a whole day or more for a clean build of the 2.4 kernel on my childhood Pentium machine. Would go to school hoping I’d come back to a completed build but it would just keep going for another day.

At this point I don’t remember the last time I’ve compiled a kernel.

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

#156

Post by rany_ »

bpye wrote: post #119
cmrdporcupine wrote: post #104

Earlier quoted context omitted.

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.

When they don't get the code upstream, it's usually because they know the code doesn't pass the stringent requirements for upstreaming and don't want to get embarrassed during review.

What you do get in that case is code dumps from those companies so someone interested at the very least does not have to reverse engineer the driver to rewrite it and get it accepted upstream.

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

#158

Post by quickthrower2 »

heavyset_go wrote: post #134
AdmiralAsshat wrote: post #27

Earlier quoted context omitted.

Could one not make the case that maybe device driver support doesn't belong in the kernel itself?

The Linux kernel driver API/ABI isn't stable so there's no permanent/versioned interface you can program against that would make out-of-tree drivers non-headache inducing: https://www.kernel.org/doc/Documentation/process/stable-api-... > You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in…

This is a great Conway's-law-busting approach.

Just because the driver creator is a different human/org to the Kernel maintainers, doesn't mean their code needs to be separate if it makes more practical sense to bundle it all together.

Also the "proof of work" of being allowed to add your driver is probably that you are designing and producing actual hardware, so it is hard to troll.

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

#159

Post by mr_toad »

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 some reason (maybe related to costs and licensing), people never adopted the idea

The network is relatively slow and unreliable. Whenever you access a network resource error handling, asynchronous operations and possible inconsistencies have to be the first things you deal with.

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

#160

Post by mr_toad »

m463 wrote: post #110
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?

A distant descendant.

https://en.wikipedia.org/wiki/XNU

Post reply on HN