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!"
Received on Tue Jun 16 2015 - 21:12:48 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC