Modularity requires more than being a "set of interconnecting components" (otherwise, all codebases with more than one source file would be "modular", and there would be no monoliths).

Modularity implies formalization and restrictions about how components communicate and depend.

One of the goals: the ability to replace the implementation of one component without having to modify/adapt the others (the top-level component (also called 'main' or 'composition root') used to instantiate all the others doesn't count).

If your components can be compiled separately (e.g without having to recompile the whole app), then you know you're modular (however, modularity doesn't necessarily involve dynamic linking).

Real world examples of modularity:

- device drivers of the Linux kernel

- SDL device backends

- decoders/demuxers in VLC

- Cubase VST effects

- Filters in DirectShow and Gstreamer

Real world non-examples:

- LLVM backends: in practice front-end implementations need to know about the various backends, so you can't simply add one.

- GCC frontends: almost modular, however, there's some bunch of places you still need to modify so they know about your new frontend.

- GCC plugins: although no line of code in GCC know about your plugin, your plugin can depend upon almost anything from the GCC implementation itself, in other words, the plugin API is too big (=the density of interconnections is too high).

- Descent 1&2 (the game) enemies: the list of enemies appears at several places in the codebase, so you can't simply add one (=the density of interconnections is too high).

> Descent 1&2 (the game) enemies: the list of enemies appears at several places in the codebase, so you can't simply add one (=the density of interconnections is too high).

I'm not sure why you picked such a specific example, but it looks like read_robot_info() will happily read in additional robots from descent2.ham if you increase MAX_ROBOT_TYPES and stick them in the same global. There might be specific behavior info sprinkled elsewhere in the game, but that is probably code you'd need to touch to implement the uniqueness of new enemies anyway.

The interfaces between those components are not stable and so outside projects cannot reimplement them, which is the entire problem with monoliths. Indeed systemd does not even maintain a stable interface with nominally separate components; it's tightly coupled to particular versions of udev and in turn the kernel.

Can one easily enough substitute the binary logger for something else?

You can redirect logs to a different agent, or you can use systemd's journald and set it to forward to syslogd.

Binary logger is one of the few parts which are considered the core.

Exactly. Systemd is highly modular, and for the most part can work with a variety of different alternatives and interconnections. There a few hard dependencies but for the most part I don't think it's fair at all to call it monolithic.

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.