Live data from Hacker News

Debian GNU/Hurd 2023

lists.gnu.org

81–90 of 132 posts

Re: Debian GNU/Hurd 2023

#81
post #63

Earlier quoted context omitted.

check out genode

As I understand it Genode "just" runs Linux for many real-world applications, but with extra steps (via a VM). Either way, that doesn't really answer the question what real-world performance looks like.

I believe it can run chrome natively now and has a fairly robust POSIX layer, no idea on performance though

Re: Debian GNU/Hurd 2023

#82
post #22
post #9

Earlier quoted context omitted.

It's not quite that black/white, because drivers in Linux can and do crash without bringing down the whole system. I don't really know the technical details on how this works exactly, but I've seen drivers crash while the system remained running.

Yes. But a Linux driver can crash the whole OS. In micro kernel land, most driver will not be able to do that. As I see it a micro kernel has simply a narrower definition of what should be in "kernel land" and what should be in "user land".

You're almost there. Yes, there's a narrower definition. Yes, that means that crashes are outwith the kernel. But no that only means that the circle around what bit is named "the kernel" is smaller. Importantly, it does not mean that it is impossible to "crash the whole operating system".

Microkernels aren't a magic bullet against crashing an entire operating system, because a crash in a non-kernel component that the entire operating system relies upon, such as a central shared rendezvous server, or a server that handles "magic" values, or a central local security subsystem server, or a shared fundamental "personality subsystem" server, still crashes the entire operating system, no matter that the crash isn't in the part of the operating system that's labelled "the kernel".

* https://jdebp.uk/FGA/microkernel-conceptual-problems.html

Re: Debian GNU/Hurd 2023

#83

Earlier quoted context omitted.

> The debate is sort of obsolete really. Says who? > * Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. That has very little to do with real microkernels. > * The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. Not at all. The "modern" approach you are describing is many decades old an…

> Says who? I'm writing my comment, so me, based on observations over time. > That has very little to do with real microkernels. It doesn't matter if it's "real" or not. My point was that any selling point a microkernel can come up with can be grafted into a monolithic one. So one of the usual selling points of a microkernel is that you can run a filesystem in userspace and eg, can allow an user to mount a network dr…

Your grasp of history is terrible. The era of rare room-sized computers pre-dates (say) Minix by decades. Basing an argument upon that premise is highly fallacious.

Re: Debian GNU/Hurd 2023

#85
post #67

Earlier quoted context omitted.

> * Hardware became far more complex. A modern video card or anything else is its own computer, with a very uncomfortable amount of state and access to the host. If your video card driver does something wrong and crashes it's by no means a given that the situation is recoverable by rebooting the driver -- the video card itself may be left in some weird state. The rest of your points make sense but I don't understand…

>The rest of your points make sense but I don't understand fully how this is an argument for monoliths? Isn't recovery from an unknown state an equally hard problem in both cases? He's not saying that monolithic kernels make recovery easier in this case. He's saying that microkernels don't make these failures easier to recover from in practice, so you may as well take the performance gains that you will get from the…

Ah ok, that's fair

Re: Debian GNU/Hurd 2023

#86
post #64

Earlier quoted context omitted.

The debate is sort of obsolete really. * Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. * The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. * Hardware became far more complex. A modern video card or anything else is its own computer, with a very uncomfortable amount of state and ac…

Funnily enough windows actually manages your two points about videos cards pretty well. I've experienced full graphics driver crashes which were recovered from cleanly with only the process which triggered the crash as a casualty. But this needs more than just "slap it in a microkernel".

I’m impressed, as my RTX cards and drivers are the only things crashing my windows 11 machines recently.

Re: Debian GNU/Hurd 2023

#87

Having been quite interested in GNU/Hurd a long time ago (the years have become decades, I fear) and having lost track of the project, I wonder whether somebody can comment on where GNU/Hurd is being used nowadays.

> I wonder whether somebody can comment on where GNU/Hurd is being used nowadays.

Simply put: nowhere. It's an experimental kernel with limited hardware support (x86 only, very few device drivers) and a bunch of critical features missing (e.g. no multiprocessor support, no power management).

Re: Debian GNU/Hurd 2023

#89
post #42
post #40

Earlier quoted context omitted.

> > The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. You're making a lot of assumptions with regards to the operating environment. What about a probe being sent to Mars, the Moon or wherever? In fact let's just generalize to space-faring craft. That environment demands incredible resiliency and the ability to continue running e…

On a plane or missile I'd assume several computers, with the majority winning the decision

No, there's plenty of single purpose systems.
Post reply on HN