On 11/08/2013 02:54 PM, Marko Randjelovic wrote:Exactly what vendor would we be locked into with systemd?
> 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
A bash script as glue code between the init daemon is simpler than the
> * 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)
simple descriptive XDG format used for systemd's unit files? I don't
think so.
The word here is "if". It's not going to happen. OpenRC has fundamental
> * If OpenRC's development continues in good direction, Debian could
> switch to OpenRC
issues which haven't been resolved for years now:
> https://bugs.gentoo.org/show_bug.cgi?id=391945
I don't think this is a viable alternative to anything. We can't work
with vaporware, we need software that actually works.
And who is going to do it? Are you?
> * 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
> abstraction
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.
The X.org developers were thinking to do the same with X.org but
> * 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
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:
> http://www.youtube.com/watch?v=RIctzAQOe44
No one cares about the "Unix philosophy" (TM), it's not some super
> 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.
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.
No, sysvinit doesn't even do the one thing it does right. It has been
> * 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
> right.
explained many many times before why that isn't the case.
If that should be a dogma we should always stick to, we should
> * More complex software has more bugs, old software is cleaned out of
> original bugs, and new software is not.
immediately abandon all efforts to improve software and go back
to Linux 0.01.
Your last statement doesn't hold at all without actually giving a
> * Software that is not well commented is hard to understand and find
> bugs
couple if examples where you think that systemd or upstart are
poorly documented.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Archive: [🔎] 527D0394.3010806@physik.fu-berlin.de" target="_blank">http://lists.debian.org/[🔎] 527D0394.3010806@physik.fu-berlin.de
--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org