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.
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.
Systemd boot, Systemd network and elogind I’m pretty sure can be decoupled. There’s 69 modules so I’m not entirely sure about all of them just the ones ive encountered.
I know logind can’t easily be, because I ran Artix for a while and they were using a decoupled version of it, and there was a big discussion about swapping it for something else because it was so hard to maintain.
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.
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.
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.
Systemd boot, Systemd network and elogind I’m pretty sure can be decoupled. There’s 69 modules so I’m not entirely sure about all of them just the ones ive encountered.
I know logind can’t easily be, because I ran Artix for a while and they were using a decoupled version of it, and there was a big discussion about swapping it for something else because it was so hard to maintain.
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.
What do you mean by modular though? I assume there’s serious coupling amongst systemd modules that make “modularity” just theoretical
Its like 70 different files and not all are required. You can swap out parts of systemd like run a different init system.
Sure but I wouldn’t say something is modular just because some things are modules. LIke yeah you can swap out networkd, but how about journald?
I would. There are a lot of modules only a few have hard systemd dependencies