Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian GNU/Hurd 2023

lists.gnu.org

Post reply on HN
Print view View original

1–10 of 132 posts

Re: Debian GNU/Hurd 2023

#2

Post by bluenose69 »

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.

Re: Debian GNU/Hurd 2023

#5

Post by mo_42 »

This micro kernel vs. monolithic kernel still puzzles me. From a computer science perspective micro kernels make so much sense.

But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.

Re: Debian GNU/Hurd 2023

#6

Post by dijit »

mo_42 wrote: post #5

This micro kernel vs. monolithic kernel still puzzles me. From a computer science perspective micro kernels make so much sense. But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.

With Linux it makes sense to go with the one file approach because it's a monolith.

The difference would be if there was a seperate "kernel" that handled disk devices. Imagine being able to upgrade it without swapping out anything to do with process control.

I mean; we already do this with userland programs of course.. but I think we're not used to this in kernel land conceptually.

The closest we have is kernel modules which are simply not in the same arena.. like comparing function calls to RESTFul RPC; they just operate too differently to compare mentally.

Re: Debian GNU/Hurd 2023

#7

Post by nequo »

mo_42 wrote: post #5

This micro kernel vs. monolithic kernel still puzzles me. From a computer science perspective micro kernels make so much sense. But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.

Linux is not a microkernel, whether you compile it with modules or as one file.

In a microkernel, the various modules run as separate processes rather than as part of the kernel. For example, if your network driver crashes, your kernel keeps running. Whereas in a monolithic kernel, a driver crashing crashes the whole kernel.

Re: Debian GNU/Hurd 2023

#8

Post by dale_glass »

mo_42 wrote: post #5

This micro kernel vs. monolithic kernel still puzzles me. From a computer science perspective micro kernels make so much sense. But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.

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

* Software is also far more complex. Great, your system theoretically can survive a video card driver dying. Too bad the compositor can't survive that, and the applications can't survive the compositor crashing, and at that point you might as well reboot anyway.

* Modern testing and debugging is excellent and having a system kernel panic is something that happens very, very rarely. It's not really worthwhile to change the system architecture for the sake of something than happens less often than I accidentally unplug my desktop's power cable.

* For HURD specifically, if you're in need of extreme reliability today, C is probably not something you want to use. Rather than dealing with stuff crashing you probably want to write code doesn't suffer from such issues to start with.

Re: Debian GNU/Hurd 2023

#9

Post by arp242 »

nequo wrote: post #7
mo_42 wrote: post #5

This micro kernel vs. monolithic kernel still puzzles me. From a computer science perspective micro kernels make so much sense. But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.

Linux is not a microkernel, whether you compile it with modules or as one file. In a microkernel, the various modules run as separate processes rather than as part of the kernel. For example, if your network driver crashes, your kernel keeps running. Whereas in a monolithic kernel, a driver crashing crashes the whole kernel.

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.
Post reply on HN