Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
yeah, there’s a lot of shit that should never have been allowed in the kernel and rust is definitely up there. May as well add npm dependencies to the kernel next.
I’ve never had much of an opinion on micro vs monolithic. I think either can be fine, but I will say that 99% of the reason I compile my own kernels is to take stuff out lol
I think Micro-Kernels are awesome because the actual Kernel is completely stable and only serves as a tiny (or Micro if you will) layer between the hardware and all the software. All Kernel modules run in userspace as daemons. So if something crashes because of a bug, say the Bluetooth driver, you can just restart that process and continue instead of having a hosed system that needs a hard reset. This is awesome for development because you can just run that buggy driver in a debugger and poke around without having to fear a Kernel panic. Also if you update your System and drivers get updated you don’t need to reboot, you just restart those driver daemons.
MINIX was really cool. It had a mechanism that could detect dead driver daemons and restart them automatically. They almost achieved full NetBSD compliance and all it really lacked was 64-bit and better hardware support. It technically still lives on because Intel forked it and baked it into every Intel chip. Except they changed the name to “Intel Management Engine”.
Hurd is GNU’s Micro-Kernel and to my knowledge it’s still being developed but at a sluggish pace. Last I checked they’re still working on full 64-bit support. It is apparently usable enough for Debian and Guix to have a Hurd port though.
Don’t get me wrong though, I still really like classic Monolithic UNIX-like kernels (especially when they’re simple and easy to compile like NetBSD) but I like Micro-Kernels overall a bit more because kernel modules as daemons is a very interesting concept to me that imo. should be explored more.
yeah, there’s a lot of shit that should never have been allowed in the kernel and rust is definitely up there. May as well add npm dependencies to the kernel next.
I’ve never had much of an opinion on micro vs monolithic. I think either can be fine, but I will say that 99% of the reason I compile my own kernels is to take stuff out lol
I think Micro-Kernels are awesome because the actual Kernel is completely stable and only serves as a tiny (or Micro if you will) layer between the hardware and all the software. All Kernel modules run in userspace as daemons. So if something crashes because of a bug, say the Bluetooth driver, you can just restart that process and continue instead of having a hosed system that needs a hard reset. This is awesome for development because you can just run that buggy driver in a debugger and poke around without having to fear a Kernel panic. Also if you update your System and drivers get updated you don’t need to reboot, you just restart those driver daemons.
MINIX was really cool. It had a mechanism that could detect dead driver daemons and restart them automatically. They almost achieved full NetBSD compliance and all it really lacked was 64-bit and better hardware support. It technically still lives on because Intel forked it and baked it into every Intel chip. Except they changed the name to “Intel Management Engine”.
Hurd is GNU’s Micro-Kernel and to my knowledge it’s still being developed but at a sluggish pace. Last I checked they’re still working on full 64-bit support. It is apparently usable enough for Debian and Guix to have a Hurd port though.
Don’t get me wrong though, I still really like classic Monolithic UNIX-like kernels (especially when they’re simple and easy to compile like NetBSD) but I like Micro-Kernels overall a bit more because kernel modules as daemons is a very interesting concept to me that imo. should be explored more.