Re: Another system management tool to disappear.
On 08/30/2015 02:44 PM, The Wanderer wrote:
On 2015-08-30 at 15:08, Renaud (Ron) OLGIATI wrote:
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 honestly doubt most of the people on this list would attempt to
upstream a patch to the systemd project, even if they had one. If you
personally prefer a Linux system sans systemd, it is very possible. I
know this because I have actually built 95% of base Linux from source by
hand - multiple times - over the last 17 years. In my opinion, if you
don't want to take the effort to do the work, then you simply have to
accept other's decisions regarding what they compiled in.
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.
With respect, I hope I do not sound pompous or arrogant when I say that
many do not have any idea what they are talking about because they never
dig into the code. If you have a legitimate complaint, then I am "all
ears." I am ready to stand up with you if I think you are right, but if
no one ever looks at the code, they are standing on shaky ground at
best. While there are some legitimate design arguments against systemd,
I honestly do not comprehend why most complain. Some only parrot
other's views, which I find very distasteful.
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.
That does not make the problem insurmountable. One programmer created a
systemd fork called "uselessd."
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.
The names are really arbitrary, so we can leave that one be for now.
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.
If I might suggest, you could start by looking at the systemd design
documents. One thing that virtually ALL of open source does horribly is
API documentation, so you can't just blame systemd if something falls
short of your expectations. That is why I advocate looking at the code
along with the docs.
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.
Speaking from experience, upstream projects are always going to go their
own way. That is WHY we use something like Debian in the first place.
Debian acts as a buffer between us, and the crazy ideas upstream.
Regardless of what upstream might do, Debian settles on a particular
version and supports it for at least 2-5 years with each release. That
means the Debian version of systemd is going to be stable enough to do
what you are suggesting. So you could replace components if you wanted
to make the effort.
Once stability becomes the expectation, other projects adopt the same
stance and upstream pays attention to that. I've seen this more than
once in my dealings with open source over the years. Upstream wants to
do whatever they want. Distributors want stability. Usually, they meet
in the middle.
T.J.
Reply to: