Funnily Unix and C are also examples of "worse is better".
(Mildly NSFW)
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).
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.
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.
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.
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?
Come on, that's literally what it means. Just because your modules aren't compatible doesn't mean it isn't modular.
It's monolythic in the same what that the GNU project or FreeBSD is monolithic.
It's a large number of utilities, tools, and daemons that is designed to provide the low-level features application developers and users demand from a modern operating system.
> It's much more than an init system;
Systemd is a init system, but systemd is also a major project that has taken on the task of unifying low-level Linux OS features.
> "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture.
All these systems have their own init systems they designed with no regard towards Linux and replaced older systems and obsoleted them.
> It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
Lies and misrepresentations.
> OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.
Which is why people are working on replacing both X and SysV.
You want to know the real problem with anything-but-systemd crowd?
This:
> Of course, this approach is not viable if it turns out that too few people are interested in init system diversity sufficiently to do the reasonably substantial implementation work required to maintain a competing implementation of the systemd unit features we care about.
There is no 'If' there. Some people don't want systemd, but the only people doing the work are Systemd. So their choice is to stick with Linux from 2000's or use systemd. Because nobody wants to commit to making any alternative actually work.
Making noise online is annoying, but it ultimately is not something that goes into the decision making of people designing operating systems. People willing to do the work are the ones that get to make the choices.
If somebody comes along and makes a better init system then systemd then they can do it and if it is better it will get adopted.
You can pretend that this is all Redhat's fault, but they are the only real enterprise that made the transition from sysv in Rhel 5, to upstart in 6, and then to systemd in 7.
And, ironically with systemd, migrating to another different init system is massively simplified compared to the work it took to migrate from sysv init. So now moving to a new init system is easier then ever.
Why do I say this?
Because systemd has unified OS design for Linux in a way that never happened with sysv init. Sure people were using 'sysv' and all used shell scripts, but they were all fundamentally different from one another. Only the most complicated shell scripts imaginable (think Apache init) or the most trivial could be made to work on more then one Linux distribution. Meanwhile systemd uses a declarative configuration syntax that all you need to do is create a parser and you could effectively import any systemd application configuration into a system with equivalent or better capabilities in any operating system.
The same can't be said for any of the bash scripts developed by any of the distributions prior to this for their own sysv variant.
> It's monolythic [sic] in the same what that the GNU project or FreeBSD is monolithic.
The FreeBSD system initialization artifacts are not monolithic.
> > "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
> FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture.
This is straw man incarnate.
> > It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
> Lies and misrepresentations.
Not according to here[0].
If you want to be a "systemd warrior", fine, feel free to be so. But don't lump FreeBSD and other Unix systems into your crusade.
BTW, when you wrote:
> Because systemd has unified OS design for Linux ...
Know that an init system, any init system, does not design nor define an Operating System.
And while your disdain for shell scripts is readily apparent, what you proffer as the benefit of "... systemd uses a declarative configuration syntax that all you need to do is create a parser ..." ignores the fact that POSIX shell scripts provide this feature by definition. Including, but not limited to, being able to source other files which define requisite variables.
And nobody claimed that... . The claim was that FreeBSD is monolithic in the same way that the systemd project (logind, nspawn etc. ) is monolithic.
> Not according to here[0].
Okay, let's click on that. First sentence "It doesn't". What were you trying to argue again?
> Know that an init system, any init system, does not design nor define an Operating System.
Are you purposely confusing systemd-init and systemd the project? Because your argument is the same as "GNU does not design or define an OS", which many people would call plain wrong.
> Okay, let's click on that. First sentence "It doesn't". What were you trying to argue again?
And the second sentence says:
What it requires is a service that
implements the same set of APIs as
systemd-logind.
So what are you trying to argue again?
> > Know that an init system, any init system, does not design nor define an Operating System.
> Are you purposely confusing systemd-init and systemd the project?
No, what I stated I thought was quite clear: an init system does not design nor define an Operating System.
This is orthogonal to the question you present.
IMHO, that's not the best way to say what I think you really meant.
There are alternatives for just about every single systemd function (e.g. there are other init system that are not sysvinit). It is true though, that the people implementing these alternatives are far more levelheaded regarding systemd than the haters - at least in my experience.
I dare say there's bit of an irony in that assertion. 4 different operating systems, each of one of which uses a different init system. Pardon me, but that looks like the exact opposite of a monoculture.
Also, the rc system in FreeBSD could probably be ported with not too much effort into other operating systems, as it uses pure sh (not even bash). Surely, that cannot be considered monoculture. I would dare say that porting systemd into FreeBSD (or any of the other OSes you mentioned) should be more difficult.
It's much more than an init system; it obviates a number of other components. This may be a desired quality for some. "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
The fact that systemd did not have the highest reliability for years did not help its popularity. It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.