But all inter-dependent. C.f. the massive effort and blogs about the PITA the folks who try to keep a fork of systemd's elogind alive. All of the tools are tightly coupled, which is why they violate the Unix philosophy. It's not that they're all under one umbrella; if that were the case, GNU itself would not follow the philosophy; it's because you can't run any single component without the whole systemd system. And it's hard - and sometimes impossible - to swap out something else for anything that systemd has assimilated. Try building a system that uses systemd for init but one of the other syslog projects instead of systemd's journald. And you can use crond instead of systemd timers, but you're gonna get systemd timers whether or not you use crond, so now you just have dead code that you can't remove or disable.

Coupling, man*. It's about tight coupling, not whether there are different executables for functions or not.

^(*) gender assumption disclaimer: used in the generic, not specific, definition^

[–] vrighter@discuss.tchncs.de 3 points 1 year ago (1 children)

"but all interdependent"

As it fucking should be! Yes the tools should be aware of each other. Yes the tools should be integrated. Yes, the tools should not have a bunch of different ways and formats for their config files.

These are not optional components of a system. I'd rather they work together, instead of needing yet another project in between as a kludge

[–] technom@programming.dev 3 points 1 year ago

The problem is that all of those interdependent parts and software that are dependent on it become entrenched. There is no freedom to replace individual parts with an alternative because something else will break. That's what I call 'Modular in theory, monolithic in practice'.

load more comments (1 replies)

load more comments (4 replies)