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-devel-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
