On 6/16/2015 1:32 PM, post-sysv wrote:
Soon systemd arrives with its promise of being a unified userspace toolkit that systems developers can supposedly just plug in and integrate without hassle to get X, Y and Z advantages. No more writing initscripts, no more setting policy because systemd will do as much as it can for you. A lazy package maintainer's dream, ostensibly.
That last sentence is telling. It's also why a master catalog of settings is so badly needed.
In my not very humble opinion, we really need a single point of reference, driven by the community, shared and sharable, and publicly visible. I could envision something like a single website which would collect settings and store them, and if you needed settings, it would build all of the envdir files and download them in one giant dollop, probably a tarball. Unpack the tarball and all of the envdir settings are there, waiting to be used. You could even be "fancy" and track option flags through various daemon revisions, so that if you have an older service running, you tell it "I have older version x.y.z" and you get the "correct" flags and not the "current" ones.
This service would not only act as a repository but it would also be a clearinghouse, a place where distributions could come and take what is needed.
Everyone hops on the bandwagon and there you are. Now we get to hear about how systemd solves so many long-standing problems with the distributions, but I can't shake the feeling that many of them were self-inflicted through indifference and/or incompetence.
After learning so much from my own odyssey, I'd like to be a little more forgiving and chalk it up to inexperience. I have this scene running through my head as you describe the vendors looking for software nearly 20 years ago: "We need an init...and something to start services...look, there's this Sys-V thingy lying around, grab it and make it work!"
