Maybe it’s not so great how monolithic systemd is, but it has brought a lot of great functionality to the Linux world. Not as if Linux has ever been married to the Unix philosophy anyways.
I think for those people it boils down to systemd being an init system that does more than an init system maybe should. Combine that with it being more complicated to work with and with Redhat not really being that open to feedback.
The funny thing is that the init part is working really really well. At least from a user perspective. Writing a unit file is soooo much easier than writing an init script. You just point it at the executable of your service and are done. Systemd does the complicated rest.
Mundane tasks weren’t really the focus. This was a debate between Redhat and the Linux old guard where the points were all based on the extremes. They follow different ideas on how tools should work, though. Init systems focus on doing one or few things but doing them very well (the traditional UNIX approach). Systemd is a suite of many moving parts to accomplish a whole range of tasks (more modern). Init is mostly just bootstrap and services, but systemd is that plus networking, plus user sessions, plus logging, etc etc. More moving parts means increased complexity and more chance for failure. Systemd as a suite then becomes a potential single point failure where init based systems would not be. Scripting for either can be involved, but generally speaking init is/was easier to write things for.
I think most users today focus on Redhat’s control and not putting too much faith in one setup for diversity’s sake rather than the other points, but the original debate really was a philosophically based one. There isn’t a right or wrong on these, but some really interesting history.
There are only 2 types of people. Who hate systemd and those who don’t know what systemd is. \s
Maybe it’s not so great how monolithic systemd is, but it has brought a lot of great functionality to the Linux world. Not as if Linux has ever been married to the Unix philosophy anyways.
i know what systemd is, don’t really get the hate.
I think for those people it boils down to systemd being an init system that does more than an init system maybe should. Combine that with it being more complicated to work with and with Redhat not really being that open to feedback.
The funny thing is that the init part is working really really well. At least from a user perspective. Writing a unit file is soooo much easier than writing an init script. You just point it at the executable of your service and are done. Systemd does the complicated rest.
for my mundane tasks, i don’t notice much complication. what makes it more complicated to work with?
Mundane tasks weren’t really the focus. This was a debate between Redhat and the Linux old guard where the points were all based on the extremes. They follow different ideas on how tools should work, though. Init systems focus on doing one or few things but doing them very well (the traditional UNIX approach). Systemd is a suite of many moving parts to accomplish a whole range of tasks (more modern). Init is mostly just bootstrap and services, but systemd is that plus networking, plus user sessions, plus logging, etc etc. More moving parts means increased complexity and more chance for failure. Systemd as a suite then becomes a potential single point failure where init based systems would not be. Scripting for either can be involved, but generally speaking init is/was easier to write things for.
I think most users today focus on Redhat’s control and not putting too much faith in one setup for diversity’s sake rather than the other points, but the original debate really was a philosophically based one. There isn’t a right or wrong on these, but some really interesting history.
It is another word for patriarchy, right?