From what I’ve read, wouldn’t this tool become a replacement in the same way wayland replace x11 (different method of escalation and all)? I guess what I was thinking is more like a sudo alternative, like doas for example. In any case, would change like this break a lot of workflow? If so, I doubt it will be the replacement soon.
Wayland took a monolithic system (Xorg) and broke it apart (Wayland, compositors) to try to make a smaller, cleaner codebase with separation of concerns.
systemd took an already separated system of discrete, interchangeable components and, like a katamari, rolls along absorbing services and clumping them together into one giant monolithic system. It started out as a replacement for init.d, and then decided it needed to absorb syslog, and then crond, and then mounting /home, and now it wants sudo.
systemd is the “see:” in the definition of “feature envy.” Of you look up the “the Unix philosophy”, systemd is the exact opposite; people who oppose systemd don’t do it for no reason; they oppose it because it violates every tenant of the Unix philosophy.
I would guess the Wayland people would be aghast at the comparison.
But all inter-dependent. C.f. the massive effort and blogs about the PITA the folks who try to keep a fork of systemd’s elogind alive. All of the tools are tightly coupled, which is why they violate the Unix philosophy. It’s not that they’re all under one umbrella; if that were the case, GNU itself would not follow the philosophy; it’s because you can’t run any single component without the whole systemd system. And it’s hard - and sometimes impossible - to swap out something else for anything that systemd has assimilated. Try building a system that uses systemd for init but one of the other syslog projects instead of systemd’s journald. And you can use crond instead of systemd timers, but you’re gonna get systemd timers whether or not you use crond, so now you just have dead code that you can’t remove or disable.
Coupling, man*. It’s about tight coupling, not whether there are different executables for functions or not.
^(*) gender assumption disclaimer: used in the generic, not specific, definition^
As it fucking should be! Yes the tools should be aware of each other. Yes the tools should be integrated. Yes, the tools should not have a bunch of different ways and formats for their config files.
These are not optional components of a system. I’d rather they work together, instead of needing yet another project in between as a kludge
The problem is that all of those interdependent parts and software that are dependent on it become entrenched. There is no freedom to replace individual parts with an alternative because something else will break. That’s what I call ‘Modular in theory, monolithic in practice’.
I mean systemd didn’t force any distro to use their software nor force any other developer to assume systemd is present. Any software that assumes systemd is present is not the fault of systemd itself, in fact I’d argue it is a sign of its success. Argue all you want about systemd being monolithic and single point of failure, at the end of the day, software dev needs some tools, and if systemd already provides it but other software doesn’t, of course they will choose systemd.
I mean in the sense that they are replacing the method of escalation, I will not talk about its overall architecture as that is a whole can of worms. I am well aware of how SystemD works and its problem too.
From what I’ve read, wouldn’t this tool become a replacement in the same way wayland replace x11 (different method of escalation and all)? I guess what I was thinking is more like a sudo alternative, like doas for example. In any case, would change like this break a lot of workflow? If so, I doubt it will be the replacement soon.
systemd is the opposite of Wayland.
Wayland took a monolithic system (Xorg) and broke it apart (Wayland, compositors) to try to make a smaller, cleaner codebase with separation of concerns.
systemd took an already separated system of discrete, interchangeable components and, like a katamari, rolls along absorbing services and clumping them together into one giant monolithic system. It started out as a replacement for init.d, and then decided it needed to absorb syslog, and then crond, and then mounting /home, and now it wants sudo.
systemd is the “see:” in the definition of “feature envy.” Of you look up the “the Unix philosophy”, systemd is the exact opposite; people who oppose systemd don’t do it for no reason; they oppose it because it violates every tenant of the Unix philosophy.
I would guess the Wayland people would be aghast at the comparison.
Systemd is not really an one giant monolith, it’s a set of smaller tools
It’s a set of smaller tools that are developed in the same repository and all released together, all sharing some amount of code.
That basically makes it monolithic, even if there’s separate binaries that the user calls.
Doesn’t you description make Linux monolithic?
You mean the Linux kernel specifically? I think most people do regard it as a monolithic kernel, even if there are modules you can load and unload.
But all inter-dependent. C.f. the massive effort and blogs about the PITA the folks who try to keep a fork of systemd’s elogind alive. All of the tools are tightly coupled, which is why they violate the Unix philosophy. It’s not that they’re all under one umbrella; if that were the case, GNU itself would not follow the philosophy; it’s because you can’t run any single component without the whole systemd system. And it’s hard - and sometimes impossible - to swap out something else for anything that systemd has assimilated. Try building a system that uses systemd for init but one of the other syslog projects instead of systemd’s journald. And you can use crond instead of systemd timers, but you’re gonna get systemd timers whether or not you use crond, so now you just have dead code that you can’t remove or disable.
Coupling, man*. It’s about tight coupling, not whether there are different executables for functions or not.
^(*) gender assumption disclaimer: used in the generic, not specific, definition^
“but all interdependent”
As it fucking should be! Yes the tools should be aware of each other. Yes the tools should be integrated. Yes, the tools should not have a bunch of different ways and formats for their config files.
These are not optional components of a system. I’d rather they work together, instead of needing yet another project in between as a kludge
The problem is that all of those interdependent parts and software that are dependent on it become entrenched. There is no freedom to replace individual parts with an alternative because something else will break. That’s what I call ‘Modular in theory, monolithic in practice’.
I mean systemd didn’t force any distro to use their software nor force any other developer to assume systemd is present. Any software that assumes systemd is present is not the fault of systemd itself, in fact I’d argue it is a sign of its success. Argue all you want about systemd being monolithic and single point of failure, at the end of the day, software dev needs some tools, and if systemd already provides it but other software doesn’t, of course they will choose systemd.
I mean in the sense that they are replacing the method of escalation, I will not talk about its overall architecture as that is a whole can of worms. I am well aware of how SystemD works and its problem too.