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.

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.

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.

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.

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?

> 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.

It's only modular when it's used like that in practice. I write a lot of "modular" stuff, but it tangles violently first time you actually try to use it in a modular fashion.