I usually don't like TUI's and just want outputs into emacs text buffers, but this interface is beautiful, A nice thing to glance at that tells you everything you need to know about your systemd units. Well done.
Come to think of it I don't think I even have parallel boot enabled on my OpenRC systems since the Linux boot time is so much shorter than whatever the BIOS does before it hands control over (or before it even displays anything on some machines).
- Too many parts.
- Doing too many things, sometimes poorly.
- Fights with other services, no graceful fallback & logging (i.e. aggressive).
- As a result, unnecessarily complex, brittle and fragile.
- Harder to secure (at code level) than simpler tools.
- Project is too aggressive and want to replace any and every service.
- Sometimes break in unexpected ways.
- Not faster than Parallel Sys-V.
We can discuss these. I'm not the one who wants flame wars.
I'm using systemd for ages, never had a single issue at all with it.
But do you run systemd and complain or why do you even hate it?
its linux right, if a linux distribution decides to use it, its not systemds fault to be used and if you use it and don't take the time and effort to have it your way, you shouldn't complain either?
It has the exact right amount of parts. A modern Operating system just has a lot more to cover than 1970's Unix...
I can remember having to deal with SysVinit and thank god for Poettering and all the other systemd maintainers for bringing the Linux ecosystem to the 21st century
It doesn't have to replace the cron, resolver, time synchronization, system logs, bootloader, home folder management, all of the disk encryption, TPM, signing, users, and a whole lot to manage services.
I can understand the frustrations with Sys-V init scripts, but on the other hand, I never had a problem with that both as a sysadmin and a distribution developer.
To be honest, loginctl allowed us to pull some hacks, but to be fair, that hacks were to handle bad behavior from a very bad codebase. Any self-respecting development team wouldn't have written anything which needed OS/kernel level reaping to clean from system correctly.
We have been chatting recently, and someone who's more experienced than me said that they have never seen Nixie's cron to die spontaneously in the last 30 years. systemd's timers not only did that, the systemd didn't bother to restart it. Ironic, considering that the biggest feature of systemd is service supervision and unattended recovery.
I think the reasonable argument is not old thing is better ( like some people make, but it has its own problems that are usually because of it trying to do everything.
My main issues stem from it's prevalence in server Distro's especially for micro service images.
D-bus is one of the great offenders for me and I don't like having it on even my desktop system but systemd wants it for many things and some things will just break without it. On a small micro service image, it would be nice to be able to strip lots of it down but systemd fights you on this because of the amount of moving parts and interconnected subs-sytems it introduces.
I concur. My main pain point is the size and aggressiveness of the whole "subsystem". I compare it to Sys-V init, because it's the best example I have used until systemd.
The thing with the whole systemd hate thing is everyone now knows why people might hate systemd (I am not a fan). I think a lot of features around isolation and systemd containers where useful but now probably using your containerization system that best suits your needs.
For me when I get really mad at it is when I want to build small nixos Images and want to minimize the footprint of systemd and run few services (some of that is on nixos as well).
I think it's better suited for desktop systems then server systems and it's quite annoying how prevalent it is. D-bus is one thing that always annoys me and how everything in systemd wants to use it and you can run into issues disabling it (Also don't like D-bus even on a desktop system).
Overall I think and hope we will see a rise not necessarily in openrc but in simpler init 1 systems that try to do less and provide good strong primitives that allow for easily using what ever daemon configured how you want, rather then trying to provide coupled implementations for everything.
Again I know these criticism are something of a meme, but they still are true.
What i don't get is why booting still takes seconds. When power is on, the hardware is on.
You can initalize most hardware in parallel, reading the amount of operation system into ram is fast.
Why?
But do you run systemd and complain or why do you even hate it?
its linux right, if a linux distribution decides to use it, its not systemds fault to be used and if you use it and don't take the time and effort to have it your way, you shouldn't complain either?
I can remember having to deal with SysVinit and thank god for Poettering and all the other systemd maintainers for bringing the Linux ecosystem to the 21st century
I can understand the frustrations with Sys-V init scripts, but on the other hand, I never had a problem with that both as a sysadmin and a distribution developer.
To be honest, loginctl allowed us to pull some hacks, but to be fair, that hacks were to handle bad behavior from a very bad codebase. Any self-respecting development team wouldn't have written anything which needed OS/kernel level reaping to clean from system correctly.
We have been chatting recently, and someone who's more experienced than me said that they have never seen Nixie's cron to die spontaneously in the last 30 years. systemd's timers not only did that, the systemd didn't bother to restart it. Ironic, considering that the biggest feature of systemd is service supervision and unattended recovery.
My main issues stem from it's prevalence in server Distro's especially for micro service images.
D-bus is one of the great offenders for me and I don't like having it on even my desktop system but systemd wants it for many things and some things will just break without it. On a small micro service image, it would be nice to be able to strip lots of it down but systemd fights you on this because of the amount of moving parts and interconnected subs-sytems it introduces.
The thing with the whole systemd hate thing is everyone now knows why people might hate systemd (I am not a fan). I think a lot of features around isolation and systemd containers where useful but now probably using your containerization system that best suits your needs.
For me when I get really mad at it is when I want to build small nixos Images and want to minimize the footprint of systemd and run few services (some of that is on nixos as well).
I think it's better suited for desktop systems then server systems and it's quite annoying how prevalent it is. D-bus is one thing that always annoys me and how everything in systemd wants to use it and you can run into issues disabling it (Also don't like D-bus even on a desktop system).
Overall I think and hope we will see a rise not necessarily in openrc but in simpler init 1 systems that try to do less and provide good strong primitives that allow for easily using what ever daemon configured how you want, rather then trying to provide coupled implementations for everything.
Again I know these criticism are something of a meme, but they still are true.
edit: Having written that, this tool looks very cool and useful when you need to deal with a systemd distribution.
It may terrify windows and osx refugees, but that's a sacrifice I am happy to make ;)