4 ms·

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 f

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?

baybal2 5y ago
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 5y ago
  If you think that systemd is an ‘enterprise framework of doom’ then you must not have worked in Java enterprise software development.
  - josephcsible 5y ago
    Having suffered under both, I'd totally spend the rest of my life developing enterprise Java if it meant systemd went away forever.
mjw1007 5y ago
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 https://en.wikipedia.org/wiki/Winner%27s_curse
- throw-8462682 5y ago
  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 5y ago
    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 5y ago
      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.
deleted 5y ago
[deleted]
iso1210 5y ago
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 5y ago
  That’s not how complexity works. Inherent complexity can’t really be outsourced meaningfully.

baybal2 5y ago

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 5y ago
If you think that systemd is an ‘enterprise framework of doom’ then you must not have worked in Java enterprise software development.
- josephcsible 5y ago
  Having suffered under both, I'd totally spend the rest of my life developing enterprise Java if it meant systemd went away forever.

mjw1007 5y ago

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 https://en.wikipedia.org/wiki/Winner%27s_curse

throw-8462682 5y ago
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 5y ago
  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 5y ago
    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.

deleted 5y ago

[deleted]

iso1210 5y ago

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 5y ago
That’s not how complexity works. Inherent complexity can’t really be outsourced meaningfully.