Re:Debian reconsiders init-system diversity
by makomk on Tuesday November 12, 2019 @12:26PM
(#21515941)
My understanding is that the problem is that extracting logind from systemd required such major surgery that they're worried the other applications which use logind won't be compatible with the modified version. There's also a seperate concern about init scripts for other applications.
Re:Debian reconsiders init-system diversity
by flukus on Tuesday November 12, 2019 @03:48AM
(#21512595)
What you just described is still very much what I'd call a monolith. Much like if you have a microservice architecure (that we had a system level prior to systemd) then each component should be testable, upgradeable and swappable in isolotation, if you don't have that then what you've really got is a distributed monolith (obligatory xkcd: https://sebiwi.github.io/comics/distributed-monolith/).
What we have here is a dependency chain that pulls in all of systemd, therefor it isn't modular.
It isn't modular just because it's divided into modules.
Re:Debian reconsiders init-system diversity
by geofft on Tuesday November 12, 2019 @07:29AM
(#21513513)
Each component is testable, upgradable, and swappable in isolation. There are no technical issues with doing so. What is missing is interest in implementing and testing a full-featured alternative to some of the components. As soon as that alternative exists, it's usable.
You wouldn't say that a company lacks a microservice architecture simply because they don't have unused reimplementations of each microservice lying around, would you?
This is an entirely unrelated question to modularity - the "problem" is that systemd supports certain features and if you want to run without systemd, some other component needs to support them. Such components could be designed pretty easily, sure, but people who are using those features are typically happy with systemd's implementation so there's little motivation to write them.
In the article, systemd's tmpfilesd mechanism is given as an example. It's straightforward to reimplement as a standalone component, but someone has to actually be interested in writing the implementation and writing tests that it behaves like systemd does and keeping it up to date.