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

[mjw1007]

I'm saying that I don't think reasoning by considering questions like

« 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? »

is likely to be fruitful.

If people want to discuss whether systemd is well designed, it would be better to look at the design directly.

[throw-8462682]

Agreed that this line of questioning is not likely to be fruitful. The alternative of discussing the design would have my preference normally, but i am not sure that it works any better for this hyper polarized topic.

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

[josephcsible]

Having suffered under both, I'd totally spend the rest of my life developing enterprise Java if it meant systemd went away forever.