31–40 of 132 posts
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 L4 folks showed that it could be done with acceptable overhead. Since then I have been a microkernel fan.
then there's the minix3 approach with process respawning, lots of good ideas
[flagged]
Earlier quoted context omitted.
> really shows how irrelevant the GNU foundation (and even the FSF) have become I've seen several posts here in the last month about proprietary software being used to basically exploit the users: steeply increase fees, hold files ransom (upgrade for money or loose access to files), spying on users. My conclusion is very different from yours: GNU Foundation and FSF are very relevant! They seem to lack in the PR dept,…
Open source and software freedom are relevant, the FSF is not. In an era of insane surveillance, AI technology, mass corporate insanity, the FSF is still arguing about firmware blobs on hardware vs loaded in by the OS, or advocating for switching from .docx to .odt when the world has moved on from even having document files.
Also, isn't the whole .docx / OOXML thing just a published standard? The process may not be as "open" as one might like (i.e. not everyone can contribute) but that seems like a detail. IIRC there was a lot of FUD simply because it came from Microsoft.
That said: I don't think it's entirely irrelevant; e.g. my country's parliament publishes a lot of their files in .docx. But I can read them on my Linux machine and you don't need a byte of non-free software for it, and I had a lot more trouble with the .doc files they published 20 years ago, so...
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 ac…
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.
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 L4 folks showed that it could be done with acceptable overhead. Since then I have been a microkernel fan.
[flagged]
[flagged]
Earlier quoted context omitted.
Open source and software freedom are relevant, the FSF is not. In an era of insane surveillance, AI technology, mass corporate insanity, the FSF is still arguing about firmware blobs on hardware vs loaded in by the OS, or advocating for switching from .docx to .odt when the world has moved on from even having document files.
> switching from .docx to .odt Also, isn't the whole .docx / OOXML thing just a published standard? The process may not be as "open" as one might like (i.e. not everyone can contribute) but that seems like a detail. IIRC there was a lot of FUD simply because it came from Microsoft. That said: I don't think it's entirely irrelevant; e.g. my country's parliament publishes a lot of their files in .docx. But I can read t…
It was annoying because we already had odt as open format and OOXML was reported to be more of a text dump of what Microsoft did in binary than a standard meant for interoperability.
> But I can read them on my Linux machine and you don't need a byte of non-free software for it, and I had a lot more trouble with the .doc files they published 20 years ago, so.
OpenOffice was already better at reading old doc files than Microsoft Word was well before OOXML was a thing. Meanwhile my last few attempts to deal with power point or excel sheets where still a gigantic mess of missing content.
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 ac…
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.