On the sickness of our community

Posted Oct 10, 2014 17:44 UTC (Fri) by Jandar (subscriber, #85683)
In reply to: On the sickness of our community by anselm
Parent article: On the sickness of our community

> With a software project of systemd's scope, there are bound to be dark corners and places where the initial solutions aren't quite right, and that can prompt people to reject the idea as a whole, which is shortsighted because such issues can be identified and fixed.

Systems's scope is the main problem for many people criticizing it. If systemd's developer would constrain it to an excellent init and service {starter,monitor} most complaints would go away. Why does it have to have a so large scope that in this bundle of solutions (to problems many don't have) there are dark corners and places where the initial solutions aren't quite right?

to post comments

On the sickness of our community

Posted Oct 12, 2014 6:10 UTC (Sun) by agrover (guest, #55381) [Link]

Sometimes when you're writing code and you do something new, and a whole set of assumptions that were baked into the old code no longer make sense. I think this has happened repeatedly: one, because init and startup is so central to how the overall system works, and two, because there is a huge amount of baggage that has built up over Unix's lifetime, actually not baggage but just no-longer-correct assumptions about amount of needed flexibility or about the resources on a system. The initial systemd fixed one, but there were a LOT more (and still are).

So many things we hold as foundational about Linux/Unix are actually accidents, or bugs-that-became-features. (see /usr -> /home transition, and dotfiles not showing up in ls). The reason that distros keep adopting it is even as new and possibly-buggy-in-corners, it does more, in less code and complexity overall than what it replaces, and if a problem is found it's going to be fixed.