4 ms·

If it's highly modular then why (according to TFA) are they struggling to incorporate a fork of a systemd subcomponent? If that's not easy to do then it's not m

by flukus 7y ago

If it's highly modular then why (according to TFA) are they struggling to incorporate a fork of a systemd subcomponent? If that's not easy to do then it's not modular.

geofft 7y ago
As I understood the thread, the problem is not that it's hard to get elogind running, the problem is that getting applications to provide tested, supported non-systemd init scripts (or equivalent) requires a commitment from the packager and occasionally from the upstream community. 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.
- flukus 7y ago
  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/ 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.
  - sjwright 7y ago
    > It isn't modular just because it's divided into modules. Come on, that's literally what it means. Just because your modules aren't compatible doesn't mean it isn't modular.
  - geofft 7y ago
    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?
- makomk 7y ago
  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.

by flukus 7y ago

If it's highly modular then why (according to TFA) are they struggling to incorporate a fork of a systemd subcomponent? If that's not easy to do then it's not modular.

geofft 7y ago

As I understood the thread, the problem is not that it's hard to get elogind running, the problem is that getting applications to provide tested, supported non-systemd init scripts (or equivalent) requires a commitment from the packager and occasionally from the upstream community. 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.

flukus 7y ago
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/ 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.
- sjwright 7y ago
  > It isn't modular just because it's divided into modules. Come on, that's literally what it means. Just because your modules aren't compatible doesn't mean it isn't modular.
- geofft 7y ago
  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?
makomk 7y ago
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.