On 2015-08-30 at 15:08, Renaud (Ron) OLGIATI wrote: > On Sun, 30 Aug 2015 13:56:18 -0500 "T.J. Duchene" > <t.j.duch...@gmail.com> wrote: > >> If you really have a problem with systemd's design, why don't you >> take the source, fix it and submit the patch? > > Sadly, considering the effort that has been spent (wasted ?) > developing systemd, the only fix would be to avoid adopting it, or > later to get rid of it completely
Not to mention that some of the changes which would be necessary to fix some parts of the design have already been pre-rejected by upstream; they've specifically and explicitly stated that patches to remove the interdependencies among the various components will not be accepted. I don't have a link handy for that, but I could dig one up if it were really necessary. I don't particularly want to dive as deeply into the systemd discussion environment as that would require, though. Plus, at least to all appearances, some of the problems with the design can pretty much only be fixed by removing features and functionality. The systemd developers seem to think that those features and that functionality are worth the cost, so of course they aren't going to accept patches to remove those things. Short of that, my own first step in trying to "fix" systemd would probably be to disambiguate the names, so that we don't refer to the binary which gets executed as PID1 _and_ the collection of other binaries which orbits that binary _and_ the project which develops all of these binaries by one single undistinguished name. So far as I can see, no one else seems to have the slightest interest in this. My second step would probably be to A: clearly define which of the interfaces involved in the project are "internal" (and subject to change without notice) and which are "external" (and guaranteed to remain stable in the long term, to be removed or see non-backwards-compatible changes only with a years-long deprecation process if at all), and B: define the boundaries in such a way that any interface which one of the project's "modular" components uses to communicate with another such component is considered an external interface. My reasoning in that latter is more or less as follows: * In order for a component of a system to be properly considered "modular", it must be possible not only to remove that component without interfering with the functioning of the rest of the system (except perhaps by way of explicitly declared dependencies), but to have the option of replacing it with an alternative component which is developed and maintained by a third party. * A third-party tool cannot safely use or depend on an internal interface of a different project. (I believe even the current systemd project would agree with this statement.) * Therefore, either the interfaces between the components are not internal interfaces, or those components are not modular. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
