2 ms·
>I agree that Linux is still larger than a microkernel, but very few users have a bloated kernel in RAM due to lack of customizations. Most users run the distr
by snvzz 3y ago
>I agree that Linux is still larger than a microkernel, but very few users have a bloated kernel in RAM due to lack of customizations.
Most users run the distribution's kernel.
- viraptor 3y agoWhich distribution kernel specifically? If you're running on a VM, you get a cloud kernel in many distros, which is very stripped down for example. On other systems - the modules part still applies - how much are you actually trying to save on the kernel RAM usage? I've got a very average kernel from a distro at 20MB and initramfs at 35MB. They could be twice the size and I would never notice. I appreciate they could be smaller, but we're running a minimum of 8GB these days. The rest is in the modules and they're not loaded unless they're actually used. The parts baked into the kernel are mostly display, storage and various buses, which you would need to have immediately loaded in Hurd anyway to load the rest of services.
- snvzz 3y agoLiteral megabytes of code running in supervisor mode. What could possibly go wrong.
- viraptor 3y agoIt would be great if they didn't of course. But historically, I've never had issues with kernel patches. In large enough deployments you get everything rolled ahead of the publication, or care enough to run grsec and custom profiles. In smaller ones, the kernel side is far down the list of things you care about. So yeah, in the ideal world, let's have everything isolated. For now it would be great if they worked at all. Also... There's a bit of practical limitation to how useful the isolation is. It's cool that the FS module runs in the userspace. But if it can create a suid-equivalent file and point an arbitrary config at it, you're not gaining much.