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

141–150 of 273 posts

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

#141

Post by kelnos »

tredre3 wrote: post #56
taeric wrote: post #33

Earlier quoted context omitted.

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. With drivers: --------------------------------------------------------------------------------------- Language files blank comment code --------------------------------------------------------------------------------------- C 32699 3332747 2610014 17218820 C/C++ Header 23690 712617 1373965 710…

> Delete most stuff in arch/ and samples/ ?

Probably? If you really want an apples-to-apple comparison, delete everything but x86_64 support from both Linux and Hurd. Remove sample code.

linux/net isn't strictly "drivers", but implements the base of the networking stack. That's 900k lines. Is that networking base code included with the Hurd figures? If not, delete it (or include in your comparison Hurd's base networking code).

Beyond that, this is getting a bit ridiculous. Who cares about the LoC comparisons? They're very different kernels with very different levels of maturity and number of features. I'm not even convinced you can call one "better" or "worse" based on this metric at all.

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

#144

Post by serf »

meepmorp wrote: post #128
PaulDavisThe1st wrote: post #122

Earlier quoted context omitted.

[flagged]

It's a good thing that you warned them off, or they might've accidentally gone and done something interesting or enjoyable.

I think it's a great project to tackle.

Here are my criticisms :

1) LoC doesn't indicate complexity. When you're looking at a code base and you see that it's 65000 lines, that by no means should be an indicator of whether or not a re-write is easily feasible -- especially with a filesystem.

2) Language shouldn't be a motivator for a re-write without considering why the language offers advantages, the end users don't care about which file extension is littered across the source tree.

Both of those tendencies (one to re-write everything in your favorite language, and two to come across with an idea that you understand how complex a mechanism is simply from LoC) indicate to me, anecdotally of course, a certain lack of experience; and I have a hard time imagining someone with those concerns tackling a re-write of a filesystem that gains 'the audience' any benefits.

If it's just for the sake of personal toys and fooling around with your own machine I feel as if those motivations are fine, but I have concerns if 'a new filesystem in Rust' comes from what I view as shaky initial motivations.

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

#145

Post by janneke »

Rumpdisk on a GNU Guix childhurd: https://toot.aquilenet.fr/@civodul/110848429561223704

just one simple `guix system reconfigure' away!

Guix Hurd on my thinkpad x60: https://todon.nl/@janneke/110451493405777898

yeah, that's real (old, but not ancient) iron.

Enjoy!

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

#146

Post by klodolph »

taeric wrote: post #54
klodolph wrote: post #41

Earlier quoted context omitted.

If your WiFi driver crashes and restarts, at the minimum, I think it could be treated as if you lost network connectivity for a short time. This is a situation that applications should be able to handle anyway, since it happens all the time on laptops. There are plenty of applications out there that just don’t respond to configuration changes gracefully. For example, if you have a music program running, and then you…

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 from all of my secrets the system can be between all parties.

To make an analogy—locking your front door doesn’t protect thieves from stealing your plastic flamingoes and garden gnomes, but it does make it harder to steal the $50,000 in cash you have hidden under the mattress.

The point of isolation is to reduce the effect of failures. If you have a buggy WiFi driver, in a monolithic kernel, that could be really bad—it could even be a remotely exploitable vulnerability in the kernel itself. In other words, you have no front door, and the thieves can steal the $50,000 hidden under your mattress. If your WiFi driver is unprivileged, then the thieves have only broken through your front gate, and they can only steal your garden gnomes and plastic flamingoes. They need to combine the vulnerability with a local privilege escalation vulnerability, or be happy with the value of plastic flamingoes.

> For fun, it is common for the "at rest" value of peddles to be discovered at connect time.

The keyboard itself does this, either when it’s turned on, or through the configuration menu (or not at all). It’s not something that has anything to do with drivers or connecting the keyboard.

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

#147

Post by edgyquant »

taeric wrote: post #55
darksaints wrote: post #42

Earlier quoted context omitted.

But that is the entire point of the comparison. I get that you think an apples to apples comparison is the most honest way to portray this, but the whole point is to portray that this is an apples to oranges comparison. Linux has millions of lines of code running in ring 0, a micro kernel does not. They may end up having the same lines of code for comparable total system size, but that isn’t the point of the comparis…

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.

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

#148

Post by lmm »

taeric wrote: post #84
anon25783 wrote: post #70

Earlier quoted context omitted.

The machines are different. Multicore 64-bit chips are now standard for consumer PCs. RAM and persistent storage are faster and much more abundant. The architecture of the modern x86-64 is much more sophisticated than that of the 386 for which the earliest Linux was written. Vectorization, predictive branching, and asynchronous code are all front and center in the modern programmer's ecosystem. In short, hardware is…

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

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

#149

Post by JohnFen »

winter_blue wrote: post #108
weberer wrote: post #78

Earlier quoted context omitted.

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.

Filesystems tend not to be all that complex to implement.

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

#150

Post by boricj »

einpoklum wrote: post #130
boricj wrote: post #63

Earlier quoted context omitted.

NetBSD has architectured their drivers to be basically static archives reusable anywhere. It's part of the NetBSD rump kernel.

What do you mean by "reusable everywhere"? I mean, where could they be used other than in a NetBSD kernel?

Anywhere. There are lots of examples on the topic ; running NetBSD driver code inside NetBSD's user-land is the simplest use-case (https://www.netbsd.org/docs/rump/sptut.html), but that code is portable without modifications to just about any context possible.

Check out Antti Kantee's The Design and Implementation of the Anykernel and Rump Kernels if you want details on the architecture.

Post reply on HN