I like the simplicity of openrc and runit, they are as stable as a rock and their functions are easy to grasp. Systemd, on the other hand, while I can understand some of the motivation behind it, it still seems like a bad idea and an even worse implementation. In my experience –and I do understand that this might not be the case for many users– it and its modules has been the cause for some really cryptic bugs that took me valuable time to resolve, and which would not have occurred if it was just a init/service management system. On the contrary, openrc just does one job, and does it well. Haven’t much experience with BSD but heard they are rock solid too.
Both openrc and runit are great; simple, stable, secure and fast. I had some huge problems with systemd even before it was considered usable. Since then, watching it becoming a bloated CVE monster by needlessly sucking up dozens of userspace components has really made me lose a lot of faith in the direction of GNU/Linux. Linux was supposed to be a free and open version of unix for desktop users, but it’s being reshaped into a cheap tool for capital and prone to all the pitfalls of corporate / techbro thinking.
I’ve worked on Linux for decades, but I might ditch Linux altogether if FreeBSD had better hardware support. There’s only so much I can write and maintain, myself. I love OpenBSD for servers and network appliances since it’s very hardened, straightforward and very well documented.
I might ditch Linux altogether if FreeBSD had better hardware support. There’s only so much I can write and maintain, myself.
I’ve been feeling that way since they decided to introduce that rust crap in the Kernel. I have a second drive in my main PC with FreeBSD 14.1 and the only things that prevent me from using it as a daily driver are the buggy amdgpu drivers and the terrible bluetooth stack. My dream would be a Micro-Kernel system though. Too bad MINIX was dropped. Maybe Hurd will become usable in 20 years from now lol.
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.
I like the simplicity of openrc and runit, they are as stable as a rock and their functions are easy to grasp. Systemd, on the other hand, while I can understand some of the motivation behind it, it still seems like a bad idea and an even worse implementation. In my experience –and I do understand that this might not be the case for many users– it and its modules has been the cause for some really cryptic bugs that took me valuable time to resolve, and which would not have occurred if it was just a init/service management system. On the contrary, openrc just does one job, and does it well. Haven’t much experience with BSD but heard they are rock solid too.
Both openrc and runit are great; simple, stable, secure and fast. I had some huge problems with systemd even before it was considered usable. Since then, watching it becoming a bloated CVE monster by needlessly sucking up dozens of userspace components has really made me lose a lot of faith in the direction of GNU/Linux. Linux was supposed to be a free and open version of unix for desktop users, but it’s being reshaped into a cheap tool for capital and prone to all the pitfalls of corporate / techbro thinking.
I’ve worked on Linux for decades, but I might ditch Linux altogether if FreeBSD had better hardware support. There’s only so much I can write and maintain, myself. I love OpenBSD for servers and network appliances since it’s very hardened, straightforward and very well documented.
I’ve been feeling that way since they decided to introduce that rust crap in the Kernel. I have a second drive in my main PC with FreeBSD 14.1 and the only things that prevent me from using it as a daily driver are the buggy amdgpu drivers and the terrible bluetooth stack. My dream would be a Micro-Kernel system though. Too bad MINIX was dropped. Maybe Hurd will become usable in 20 years from now lol.
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.