I’ve been using systemd on most of my systems since it was released; I was an early jumper to upstart as well.
The thing I don’t like about systemd is how pervasive in the OS it is. It violates the “do one thing, do it well” Unix philosophy, and when systemd went from an init system to starting to take everything over, I started liking it less.
My issues with systemd is that it isn’t an unmitigated success, for me. journald is horrible: it’s slow and doesn’t seem to catch everything (the latter is extremely rare, but that it happens occasionally makes me nervous). There are several gotchas in running user services, such as getting in-session services working correctly (so that user services can access the user session kernel keyring).
Recently I’ve been using dinit on a system, and I’m pretty happy with it. I may switch all of my systems over to it; I’m running Arch everywhere, and while migrating Arch to Artix was scary the first time, in the end it went fairly smoothly.
Fundamentally, systemd is a monolithic OS system. It make Linux into more of a Windows or MacOS, where a bunch of different systems are consolidated under a single piece of software. While it violates the Unix philosophy, it has been successful because monolithic systems tend to be easier to use: users really only have to learn two command-line tools, vs a dozen. Is it categorically better, just because the user interface is easier for new Linux users?
Systemd is modular not monolithic. Distros choose which parts of system d to implement and it just happens to be most of it since its really good at what it does.
You cannot even decouple SystemD from Glibc, never mind separating the various components from each other. It is a bunch of processes but it is designed as a monolith.
It is not modular. This is a lie Poettering keeps pushing to defend building a huge edifice of interdependent systems.
Look at the effort required to factor out logind. It can’t just be used in it’s own; it has a hard dependency on systemd and needs code changes to decouple.
I will repeat that journald is really bad at what it does, and further assert that you can not run systemd without journald, or vice versa. That you can not run systemd without getting timed job control. Even if you chose not to use it, it’s in there. And you can not get time job control without the init part. In most unix systems, init and cron are utterly decoupled and can be individually swapped with other systems.
Systemd is not modular if you can’t swap parts out for other software. Systemd’s modularity is a bald-faced lie.
The one exceptions are homed and resolvd, which are relatively new and were addedlong after systemd came under fire for being monolithic. And, ironically, they’re the components most distributions don’t use by default.
I’ve been using systemd on most of my systems since it was released; I was an early jumper to upstart as well.
The thing I don’t like about systemd is how pervasive in the OS it is. It violates the “do one thing, do it well” Unix philosophy, and when systemd went from an init system to starting to take everything over, I started liking it less.
My issues with systemd is that it isn’t an unmitigated success, for me. journald is horrible: it’s slow and doesn’t seem to catch everything (the latter is extremely rare, but that it happens occasionally makes me nervous). There are several gotchas in running user services, such as getting in-session services working correctly (so that user services can access the user session kernel keyring).
Recently I’ve been using dinit on a system, and I’m pretty happy with it. I may switch all of my systems over to it; I’m running Arch everywhere, and while migrating Arch to Artix was scary the first time, in the end it went fairly smoothly.
Fundamentally, systemd is a monolithic OS system. It make Linux into more of a Windows or MacOS, where a bunch of different systems are consolidated under a single piece of software. While it violates the Unix philosophy, it has been successful because monolithic systems tend to be easier to use: users really only have to learn two command-line tools, vs a dozen. Is it categorically better, just because the user interface is easier for new Linux users?
Systemd is modular not monolithic. Distros choose which parts of system d to implement and it just happens to be most of it since its really good at what it does.
You cannot even decouple SystemD from Glibc, never mind separating the various components from each other. It is a bunch of processes but it is designed as a monolith.
It is not modular. This is a lie Poettering keeps pushing to defend building a huge edifice of interdependent systems.
Look at the effort required to factor out logind. It can’t just be used in it’s own; it has a hard dependency on systemd and needs code changes to decouple.
I will repeat that journald is really bad at what it does, and further assert that you can not run systemd without journald, or vice versa. That you can not run systemd without getting timed job control. Even if you chose not to use it, it’s in there. And you can not get time job control without the init part. In most unix systems, init and cron are utterly decoupled and can be individually swapped with other systems.
Systemd is not modular if you can’t swap parts out for other software. Systemd’s modularity is a bald-faced lie.
The one exceptions are homed and resolvd, which are relatively new and were addedlong after systemd came under fire for being monolithic. And, ironically, they’re the components most distributions don’t use by default.
What do you mean by modular though? I assume there’s serious coupling amongst systemd modules that make “modularity” just theoretical