6 ms·

The debate is sort of obsolete really. * Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. * The modern approach

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.

senko 3y ago
> The debate is sort of obsolete really. Microkernels are not obsolete (see seL4), but HURD unfortunately is. > Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. FUSE is far cray (capability, security and performance-wise) from real microkernels. Linux is a monolithic kernel and unashamedly so. > The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. This would imply operating system developers (in any) OS are not that much interested in reliability of the system they're working on, which I don't believe is true. Also, to give just one counter-example, I don't think many people have redundant mobile phones in case one of them crashes. > 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. This was more-or less true from the moment discreete GPUs started shoping up. Modern PCs have dozens of independent processors (some of them running their own opertaing systems)! If anything, that's more reason for microkernels. * 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. Microkernels aren't written like that. In a MK architecture, your system survives video card driver dying by restarting it and taking over serving its clients (in this case, the compositor). Of course, Linux doesn't work like that, but we've already established Linux is not a microkernel. > 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. Yeah, I agree Linux will never changi its system architecture, but that doesn't mean thinking, researching and building other operating systems using different architectures is obsolete. > 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. Ah yes, ye olde "just don't write bugs!" argument :-) More seriously though, I would agree with you that replacing GNU/Linux with GNU/Hurd will never happen. I just want to emphasize Hurd is not be-all and end-all of microkernels (even open source ones). In fact, it never was.
- dale_glass 3y ago
  > Microkernels are not obsolete (see seL4), but HURD unfortunately is. Why HURD specifically? But I didn't mean microkernels, but the debate. Basically my view is that nothing stays pure. If microkernels have significant upsides a monolithic kernel like Linux doesn't have, then the logical outcome is that Linux copies the required feature like eg, FUSE. Yeah, it's not a true microkernel, but who cares? It can do the cool thing. Nobody cares about purity. Computing is about getting stuff done. > Also, to give just one counter-example, I don't think many people have redundant mobile phones in case one of them crashes. A modern cell phone has a tendency to forget stuff anyway. I mean Android will just randomly stop background programs when it pleases, so every app has to deal with that possibility. So the phone rebooting has little effect, other than taking time. > This was more-or less true from the moment discreete GPUs started shoping up. Modern PCs have dozens of independent processors (some of them running their own opertaing systems)! If anything, that's more reason for microkernels. How so? I have two overall points here: 1. With hardware being complex and stateful, rebooting the driver may just not help. If something inside the video card is locked up, no amount of rebooting the driver is going to fix that. 2. There are complex webs of dependency, which often aren't easy to resolve in a fault tolerant manner. Most stuff will probably just crash anyway even if recovery is theoretically possible. Recovery paths are very rarely exercised. > Yeah, I agree Linux will never changi its system architecture, but that doesn't mean thinking, researching and building other operating systems using different architectures is obsolete. No, I mean it's not worth it to the average person to switch to a different OS for the sake of a benefit that might materialize extremely rarely. I'm not itching for a better OS which can survive a driver crash because the time when that happens for me is essentially never. I think in the last 3 years I might have seen one kernel panic. Switching to a very different OS for the sake of having a system that can survive such a freak occurrence would be wasting my time. I'd spend far more time learning HURD than I'd gain in productivity. > Ah yes, ye olde "just don't write bugs!" argument :-) This, but unironically. If you're concerned about reliability, then the better approach is to avoid failures to start with. Rather than having a system that can tolerate something overflowing a buffer and crashing, how about a system that doesn't allow you to even compile something that does that? Huge advancements have been made in creating languages that lack many of the stupid pitfalls of C.
taylodl 3y ago
> > 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 even if the hardware is having problems - at least enough so ground control can assess the situation and send updates. Weapons systems are another environment you'd prefer to have resiliency. You'd hate to lose control of a missile while in mid-flight. Automotive systems are another environment that comes to mind. There are a lot of embedded/remote environments where the "redundant hardware" solution isn't applicable. Edit: I'm fully-aware these systems have redundant hardware in modern implementations. I'm also fully-are that monolithic kernels are unable to cope with a failure of any of the hardware comprising the system. Hence my calling out this point.
- iso1631 3y ago
  On a plane or missile I'd assume several computers, with the majority winning the decision
  - taylodl 3y ago
    One of those computers just went out. Now how do you form your majority? Besides which, in such systems there's a governing system coordinating the election. What happens if your governing system goes out?
    - Volundr 3y ago
      Your governing system isn't a single system, it's multiple using a suitable algorithm to establish quorum. This is a well studied problem in distributed systems.
    - iso1631 3y ago
      So one computer is out and the other 2 are giving different answers to the same question?
rcxdude 3y ago
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".
- b33j0r 3y ago
  I’m impressed, as my RTX cards and drivers are the only things crashing my windows 11 machines recently.
- kjs3 3y ago
  YMMV...video drivers (esp 3rd party) are one of the things that still mange take the whole machine out for me.
lucideer 3y ago
> * 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 fully how this is an argument for monoliths? Isn't recovery from an unknown state an equally hard problem in both cases?
- krger 3y ago
  >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 monolithic kernel instead of giving up those gains for theoretical recoverability advantages that you won't actually usually see in practice.
  - lucideer 3y ago
    Ah ok, that's fair
goodpoint 3y ago
> 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 and single systems are still extremely common.
- dale_glass 3y ago
  > 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 drive. Well, no need to switch kernels just for that since they added FUSE to Linux. As an user I don't care if it's pure, I care that the job gets done. > Not at all. The "modern" approach you are describing is many decades old and single systems are still extremely common. Modern compared to the very old idea of the microkernel, I mean. I can see that the idea had a lot of appeal back in the era of rare, room sized computers. Keeping a single machine going is far less important in modern times, where most serious uses try their best to treat any single machine as disposable.
  - JdeBP 3y ago
    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.

senko 3y ago

> The debate is sort of obsolete really. Microkernels are not obsolete (see seL4), but HURD unfortunately is. > Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. FUSE is far cray (capability, security and performance-wise) from real microkernels. Linux is a monolithic kernel and unashamedly so. > The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. This would imply operating system developers (in any) OS are not that much interested in reliability of the system they're working on, which I don't believe is true. Also, to give just one counter-example, I don't think many people have redundant mobile phones in case one of them crashes. > 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. This was more-or less true from the moment discreete GPUs started shoping up. Modern PCs have dozens of independent processors (some of them running their own opertaing systems)! If anything, that's more reason for microkernels. * 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. Microkernels aren't written like that. In a MK architecture, your system survives video card driver dying by restarting it and taking over serving its clients (in this case, the compositor). Of course, Linux doesn't work like that, but we've already established Linux is not a microkernel. > 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. Yeah, I agree Linux will never changi its system architecture, but that doesn't mean thinking, researching and building other operating systems using different architectures is obsolete. > 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. Ah yes, ye olde "just don't write bugs!" argument :-) More seriously though, I would agree with you that replacing GNU/Linux with GNU/Hurd will never happen. I just want to emphasize Hurd is not be-all and end-all of microkernels (even open source ones). In fact, it never was.

dale_glass 3y ago
> Microkernels are not obsolete (see seL4), but HURD unfortunately is. Why HURD specifically? But I didn't mean microkernels, but the debate. Basically my view is that nothing stays pure. If microkernels have significant upsides a monolithic kernel like Linux doesn't have, then the logical outcome is that Linux copies the required feature like eg, FUSE. Yeah, it's not a true microkernel, but who cares? It can do the cool thing. Nobody cares about purity. Computing is about getting stuff done. > Also, to give just one counter-example, I don't think many people have redundant mobile phones in case one of them crashes. A modern cell phone has a tendency to forget stuff anyway. I mean Android will just randomly stop background programs when it pleases, so every app has to deal with that possibility. So the phone rebooting has little effect, other than taking time. > This was more-or less true from the moment discreete GPUs started shoping up. Modern PCs have dozens of independent processors (some of them running their own opertaing systems)! If anything, that's more reason for microkernels. How so? I have two overall points here: 1. With hardware being complex and stateful, rebooting the driver may just not help. If something inside the video card is locked up, no amount of rebooting the driver is going to fix that. 2. There are complex webs of dependency, which often aren't easy to resolve in a fault tolerant manner. Most stuff will probably just crash anyway even if recovery is theoretically possible. Recovery paths are very rarely exercised. > Yeah, I agree Linux will never changi its system architecture, but that doesn't mean thinking, researching and building other operating systems using different architectures is obsolete. No, I mean it's not worth it to the average person to switch to a different OS for the sake of a benefit that might materialize extremely rarely. I'm not itching for a better OS which can survive a driver crash because the time when that happens for me is essentially never. I think in the last 3 years I might have seen one kernel panic. Switching to a very different OS for the sake of having a system that can survive such a freak occurrence would be wasting my time. I'd spend far more time learning HURD than I'd gain in productivity. > Ah yes, ye olde "just don't write bugs!" argument :-) This, but unironically. If you're concerned about reliability, then the better approach is to avoid failures to start with. Rather than having a system that can tolerate something overflowing a buffer and crashing, how about a system that doesn't allow you to even compile something that does that? Huge advancements have been made in creating languages that lack many of the stupid pitfalls of C.

taylodl 3y ago

> > 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 even if the hardware is having problems - at least enough so ground control can assess the situation and send updates. Weapons systems are another environment you'd prefer to have resiliency. You'd hate to lose control of a missile while in mid-flight. Automotive systems are another environment that comes to mind. There are a lot of embedded/remote environments where the "redundant hardware" solution isn't applicable. Edit: I'm fully-aware these systems have redundant hardware in modern implementations. I'm also fully-are that monolithic kernels are unable to cope with a failure of any of the hardware comprising the system. Hence my calling out this point.

iso1631 3y ago
On a plane or missile I'd assume several computers, with the majority winning the decision
- taylodl 3y ago
  One of those computers just went out. Now how do you form your majority? Besides which, in such systems there's a governing system coordinating the election. What happens if your governing system goes out?
  - Volundr 3y ago
    Your governing system isn't a single system, it's multiple using a suitable algorithm to establish quorum. This is a well studied problem in distributed systems.
  - iso1631 3y ago
    So one computer is out and the other 2 are giving different answers to the same question?

rcxdude 3y ago

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

b33j0r 3y ago
I’m impressed, as my RTX cards and drivers are the only things crashing my windows 11 machines recently.
kjs3 3y ago
YMMV...video drivers (esp 3rd party) are one of the things that still mange take the whole machine out for me.

lucideer 3y ago

> * 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 fully how this is an argument for monoliths? Isn't recovery from an unknown state an equally hard problem in both cases?

krger 3y ago
>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 monolithic kernel instead of giving up those gains for theoretical recoverability advantages that you won't actually usually see in practice.
- lucideer 3y ago
  Ah ok, that's fair

goodpoint 3y ago

> 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 and single systems are still extremely common.

dale_glass 3y ago
> 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 drive. Well, no need to switch kernels just for that since they added FUSE to Linux. As an user I don't care if it's pure, I care that the job gets done. > Not at all. The "modern" approach you are describing is many decades old and single systems are still extremely common. Modern compared to the very old idea of the microkernel, I mean. I can see that the idea had a lot of appeal back in the era of rare, room sized computers. Keeping a single machine going is far less important in modern times, where most serious uses try their best to treat any single machine as disposable.
- JdeBP 3y ago
  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.