Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way • Hacker News Board

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

#161

Post by askiiart » Tue, Aug 08, 2023, 12:47 AM UTC

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

For anyone wondering, drivers are 5205102 out of 7616785 lines, or about 68.34% of all lines.

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

#162

Post by mannyv » Tue, Aug 08, 2023, 1:00 AM UTC

mannyv wrote: post #152

In the commercial world the first release a new OS with GUI only takes about 4 years, depending. Hurd has exceeded that by a huge margin.

Also, given its velocity, 'strike back' is totally the wrong phrase. 'Strike back' implies speed and/or alacrity, neither of which gnu/hurd possesses in any appreciable quantity.

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

#163

Post by p_l » Tue, Aug 08, 2023, 1:18 AM UTC

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?

MacOS XNU is based on OSFMK which was also used by Tru64 and few others, and sometimes called "Mach 3.5" IIRC. One of the major differences was that it embedded the BSD server into kernel space.

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

#164

Post by thrillgore » Tue, Aug 08, 2023, 1:22 AM UTC

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've been playing with Redox a lot lately. By comparison, everything is big compared to Redox.

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

#165

Post by [deleted] » Tue, Aug 08, 2023, 1:24 AM UTC

kelnos wrote: post #136

darksaints wrote: post #69

Earlier quoted context omitted.

Okay, so there are a handful of massive $4k+ chips that can fit the Linux kernel in the L3 cache. Meanwhile, you could fit 5 copies of the SEL4 kernel in the L2 cache of a raspberry pi.

Which is fine for a program that does essentially nothing. But once a program wants to talk to the network or disk, or display something on the screen, it needs more system services that need to come from somewhere. Can you fit all of those in the caches too?

[deleted]

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

#166

Post by thrillgore » Tue, Aug 08, 2023, 1:25 AM UTC

I look at Hurd and how it took this long for it to boot X, and I look at Redox and its booting and pretty active. Hurd died the day Linux went GPLv2. It's a shame too, I trust the Redox design in every other regard.

Someday it'll have the fault tolerance of OpenVMS, where it'll somehow keep running when the hardware dies.

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

#167

Post by snvzz » Tue, Aug 08, 2023, 1:27 AM UTC

kelnos wrote: post #132

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. These days most Linux distros build pretty much any driver as a module that can be built as one. Bo…

>I agree that Linux is still larger than a microkernel, but very few users have a bloated kernel in RAM due to lack of customizations.

Most users run the distribution's kernel.

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

#168

Post by snvzz » Tue, Aug 08, 2023, 1:31 AM UTC

Other interesting microkernel-based OSs include Genode[0], HelenOS[1], Helios[2], Makatea[3], Managarm[4].

0. https://genode.org/

1. http://www.helenos.org/

2. https://sr.ht/~sircmpwn/helios/

3. https://trustworthy.systems/projects/TS/makatea

4. https://github.com/managarm

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

#169

Post by pard68 » Tue, Aug 08, 2023, 1:32 AM UTC

Weird that a lack of systemd was called out as a problem. Your pid1 can be any of a myriad of tools, systemd is just the (current) dominator. Only a few years ago I was working on RHEL machines without any systemd to speak of.

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

#170

Post by anonymousiam » Tue, Aug 08, 2023, 2:03 AM UTC

taeric wrote: post #16

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.

My memory was spending as much time learning on the different options as anything else. Though, I think most of my memory was all of the config for FreeBSD. Compiling Firefox was the beast that I remember. Only thing I still compile is Emacs, and that is silly fast on modern computers. Really, the speed of compilation is such that I understand why so many source distribution methods are as popular as they are now. Fe…

The big break (for me) in configuring the options was the very welcome addition of "make menuconfig" to replace the original "make config". As the number of supported filesystems/drivers/options increased, it could take more than an hour to get through a "make config".

I haven't built my own kernel for more than 15 years, but I probably built more than a dozen before that, each of them re-compiled upon every new release (going back to 0.98).