This has now been discussed ad nauseam. Can we please stop posting about this on -devel and let the tech-ctte work?
Thanks, Paul On Fri, Nov 8, 2013 at 10:30 AM, John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > 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 > think so. > > > * 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: > > > 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. > > > * 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 > > 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: > > > http://www.youtube.com/watch?v=RIctzAQOe44 > > > 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 > > right. > > 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 > > bugs > > Your last statement doesn't hold at all without actually giving a > couple if examples where you think that systemd or upstart are > poorly documented. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > -- > To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/527d0394.3010...@physik.fu-berlin.de > > -- :wq
