[throw-8462682]

How likely is it that the prolific systemd team and tech decision makers in Linux distributions don’t have a design instinct and came up with this ball of mud full of accidental and unneeded complexity? Have you considered that there may be teams and requirements outside your current sphere of experience?

[mjw1007]

It certainly does sometimes happen that difficult software projects end up being implemented by people who (at least at the start) don't understand the problems involved, for reasons related to the "winner's curse" [1].

That is, people who underestimate the difficulty of a project are more likely to attempt it, and people who don't understand the area well are more likely to underestimate its difficulty.

[1] https://en.wikipedia.org/wiki/Winner%27s_curse

[throw-8462682]

It happens but it’s not clear what you intend to say with that, so maybe just say it? I don’t think the systemd team could have imagined the success and scope of the project from day 1. Another explanation for their success is that the team was onto something, and by using proper engineering practices (work incrementally on pieces that are individually useful) became successful. Think T S Kuhn’s progressive research program.

[iso1210]

Maybe there are, but that doesn't help me.

The systemd way seems to be "one tool of complexity 40 to 50 things" rather than "50 tools of complexity 1 each doing one thing".

When you only need 10 things, you only need 10 simple tools of complexity 10, rather than one tool of complexity 40.

[kaba0]

That’s not how complexity works. Inherent complexity can’t really be outsourced meaningfully.

[baybal2]

For SystemD, I see none.

Though, I see unfulfilled urge to give Linux "serious enterprise grade" twist, and bog everything in "serious enterprise frameworks of doom"

[throw-8462682]

If you think that systemd is an ‘enterprise framework of doom’ then you must not have worked in Java enterprise software development.