Bug#727708: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
On 11/08/2013 02:54 PM, Marko Randjelovic wrote:
> Additional arguments in favor of sysvinit:
> * systemd and upstart lead to vendor lock-in; it will be complicated
> later to return back or change to third option, as well to change from
> first to second option
Exactly what vendor would we be locked into with systemd?
> * I don't have a feeling that configuration can be very simpler than
> shell scripts; there are things such as 'events' and such things have
> to be properly defined)
A bash script as glue code between the init daemon is simpler than the
simple descriptive XDG format used for systemd's unit files? I don't
> * If OpenRC's development continues in good direction, Debian could
> switch to OpenRC
The word here is "if". It's not going to happen. OpenRC has fundamental
issues which haven't been resolved for years now:
I don't think this is a viable alternative to anything. We can't work
with vaporware, we need software that actually works.
> * If our shell scripts are a mess, then we should clean up the mess,
> not trying to escape it by changing whole init system; more precisely,
> we should correct mistakes we made in past, such as not enough
And who is going to do it? Are you?
People constantly stating that systems like OpenRC and sysvinit
are actually viable alternatives if someone improved them without
actually stepping forward themselves leaves me up to the impression
that those people actually don't have interests in pushing sysvinit
or OpenRC but just blocking the adoption of systemd or upstart.
> * existing software (sysvinit+initscripts) can be enhanced:
> (1) add new features to sysvinit; e.g. start-stop-daemon could be
> extended, to return only when service is ready, or if timeout exceeds
> to return with error status (2) add new software in addition to sysvinit
> (3) make init scripts more correct (abstraction)
> (4) extend configurability (more options in /etc/default/*)
> (3) makes (4) easily possible
The X.org developers were thinking to do the same with X.org but
at some point figured out that the sources they are dealing
with were such a mess that it's better to start over altogether and
started Wayland, see:
> If sysvinit is in accord with UNIX philosophy, and as they say it is,
> than I don't see why (1) and (2) would not be possible, too, and with
> not to much effort.
No one cares about the "Unix philosophy" (TM), it's not some super
holy cow we're not allowed to touch. Additionally, original Unix
sucks, it's all the GNU- and Linux-specific extensions that
actually made it usable.
> * What is alleged to be disadvantages of sysvinit (lack of features),
> is not really to blame sysvinit, because it does one thing and do it
No, sysvinit doesn't even do the one thing it does right. It has been
explained many many times before why that isn't the case.
> * More complex software has more bugs, old software is cleaned out of
> original bugs, and new software is not.
If that should be a dogma we should always stick to, we should
immediately abandon all efforts to improve software and go back
to Linux 0.01.
> * Software that is not well commented is hard to understand and find
Your last statement doesn't hold at all without actually giving a
couple if examples where you think that systemd or upstart are
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - firstname.lastname@example.org
`. `' Freie Universitaet Berlin - email@example.com
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913