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

171–180 of 273 posts

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

#171

Post by anonymousiam »

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…

As well as QNX, which is excellent, GHS Integrity is also a very nice, but closed/proprietary microkernel.

https://www.ghs.com/products/rtos/integrity.html

https://en.wikipedia.org/wiki/Integrity_(operating_system)

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

#172

Post by effie »

JohnFen wrote: post #149
winter_blue wrote: post #108

Earlier quoted context omitted.

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.

Filesystems tend not to be all that complex to implement.

Simple filesystems - those oriented at speed, without integrity checking, compression, encryption and raid-like features. Which are extremely useful and desirable in a filesystem.

When people tried to do a full-featured filesystem, with a remarkable exception (ZFS) it's either a disappointing unfinished mess (btrfs) or a promising, but a long-term project taking years (bcachefs).

Making a filesystem with strong support of important features is an extremely demanding project.

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

#173

Post by effie »

bonzini wrote: post #95
praptak wrote: post #88

Earlier quoted context omitted.

Do we have more hardware isolation? There was a pretty strong argument against microkernels - a driver running in userspace can still bork the whole machine if the hardware being controlled can write to memory at arbitrary addresses.

Yes, there's IOMMUs. On the other hand, datacenters have become so large that a 1% performance improvement can amount to millions of dollars in hardware and energy savings, so the extra cost of a microkernel might not be very welcome outside consumer devices.

We did not yet have a big publicized hack of whole cloud infrastructure causing massive economic harm. When that happens (the buggy PC/Linux architecture running the world is ripe), more secure architectures will become commercially interesting despite the 1% performance penalty.

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

#174

Post by janneke »

slim wrote: post #143
phant0mas wrote: post #133

You can try using it through Guix :)

how?

By reading the fine manual (https://guix.gnu.org/manual/en/html_node/Virtualization-Serv...>) or blog post (https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes...>).

TL;DR; Add this

    (service hurd-vm-service-type
             (hurd-vm-configuration
              (disk-size (* 5000 (expt 2 20))) ;5G
              (memory-size 1024)))             ;1024MiB
GNU Shepherd system service description to your system configuration, and reconfigure; then just do something like

    sudo herd start childhurd
    ssh -p 10022 root@localhost
If you're not using Guix System, you can still download a prebuilt QEMU image from https://guix.gnu.org/en/download/latest/>:

    wget -O hurd-latest.img https://ci.guix.gnu.org/search/latest/image?query=spec:images+status:success+system:x86_64-linux+hurd-barebones.qcow2
and do something like:

    qemu-system-i386 -m 2048 --enable-kvm --hda hurd-latest.img
Enjoy!

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

#175

Post by taeric »

lmm wrote: post #148
taeric wrote: post #84

Earlier quoted context omitted.

In a very real sense, the hardware has given a realization of microservice ideas, but at the hardware level. My WIFI card, the common and popular example, probably has more processing power than some of the early desktop computers back in the day. Certainly SSDs are getting much more complicated. They aren't general purpose, but I presume microkernel "services" would also not be general purpose?

Often they are general-purpose. There's a blog from maybe 10 years ago of someone launching Linux on a hard drive (it refuses to fully boot because the hard drive doesn't have an MMU, but they get some familiar log output).

Yeah, I vaguely remembered that, but couldn't find the details in a quick search. So, sadly assumed I may have imagined it. :D

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

#176

Post by themerone »

darksaints wrote: post #112
mcv wrote: post #103

Earlier quoted context omitted.

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

Who's used QNX in automotive for anything other than infotainment? A lot of people seem to think it's being used for vehicle control systems, but I've never been presented with a credible evidence of widespread use in production vehicles.

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

#177

Post by taeric »

edgyquant wrote: post #147
taeric wrote: post #55

Earlier quoted context omitted.

Fair. I'm not a fan of apples to oranges comparisons without leaning into more of it. Especially not when the obvious driver for difference between two things is that one is old and has a ton of the code you are currently behind on writing. I do question if process isolation isn't fundamentally hard. Separate processes for separate things entirely is not fundamentally hard. That, I agree. But, so much of what we do i…

>obvious driver for difference between two things is that one is old and has a ton of the code you are currently behind on writing. In this case they’re both old though, as Hurd predates Linux by a year.

Fair, if amusing. Hurd "predates" Linux in name only. And, if anything, this would serve as a strong piece of evidence that microkernels have a hard time getting traction.

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

#178

Post by taeric »

klodolph wrote: post #146
taeric wrote: post #54

Earlier quoted context omitted.

It really depends on what all is done "in the driver," though? Since, per the application, the data may have been passed off to the driver with a successful message pass. And if I have to have secrets in the driver for it to be able to connect to access points and such, it seems dubious how protected from all of my secrets the system can be between all parties. MIDI is actually an easy example, all told. If I unplug…

> Since, per the application, the data may have been passed off to the driver with a successful message pass. The application already knows that the data is not guaranteed to be delivered, or even sent at all. That’s just the nature of network programming—it’s inherently unreliable. > And if I have to have secrets in the driver for it to be able to connect to access points and such, it seems dubious how protected fro…

Applications are usually written to know that anything sent over the network could be lost. You don't usually do the same for sending to the different devices. Are you expecting retry logic in all places sending to a device?

We /could/ turn all computation into remote procedure calls. There is plenty of precedence that that will not end well. You do it where you have to. Not everywhere.

And fair point on the device learning its "off" position at startup. Though, that really leans into another point I made in another branch. That level of "isolated and can restart" is already largely accomplished by having extra compute on the devices you are connecting to. I really can't see much benefit it doing everything in the RPC paradigm.

I get the promise. I'm not buying the evidence that you can solve this by making it transparent that all things are "servers" and some are remote.

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

#179

Post by defrost »

themerone wrote: post #176
darksaints wrote: post #112

Earlier quoted context omitted.

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

Who's used QNX in automotive for anything other than infotainment? A lot of people seem to think it's being used for vehicle control systems, but I've never been presented with a credible evidence of widespread use in production vehicles.

It's probable that QNX would underpin any future Mitsubishi Electric autonomous driving system, and more certain that it would underpin sensor integration etc. in future Mitsubishi car models.

But it's not being used there in current mainstream production.

https://www.meaa-mea.com/advanced-mobility/

https://www.blackberry.com/us/en/success-stories/mitsubishi

It's certainly difficult to pick through the Blackberry QNX hype to see where it's actually headed outside of infotainment, lot's of fuzzy weasal phrasing:

https://blackberry.qnx.com/en/industries/connected-autonomou...

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

#180

Post by midoridensha »

effie wrote: post #172
JohnFen wrote: post #149

Earlier quoted context omitted.

Filesystems tend not to be all that complex to implement.

Simple filesystems - those oriented at speed, without integrity checking, compression, encryption and raid-like features. Which are extremely useful and desirable in a filesystem. When people tried to do a full-featured filesystem, with a remarkable exception (ZFS) it's either a disappointing unfinished mess (btrfs) or a promising, but a long-term project taking years (bcachefs). Making a filesystem with strong suppo…

Don't forget: buggy filesystem code can easily lead to catastrophic data loss, which ruins your filesystem's reputation.

Lines of code isn't the only important metric. A project with a smaller number of LoC can take a long time to fully test and debug and validate.

Post reply on HN