On Mon, Jul 22, 2013 at 2:28 PM, The Wanderer <wande...@fastmail.fm> wrote:
> My concern was that the integrated nature of it would make it harder to > replace any one part, especially if desiring to extend rather than just > reimplement. Having it made clear that it's more compatible with being > split out "piecemeal", as you put it - with being essentially modular - > than I'd thought does help somewhat in that regard, however. > We have a *zillion* libraries where we are *locked-in*. Just a few examples: 1. there's one big lock-in called dpkg :) 2. try to get rid of OpenSSL 3. we cannot use GTK+ for KDE and QT for Gnome - also a lock-in 4. just do dpkg --get-selections and see yourself I don't see a single reason why the modern sysvinit case should be any special. Yes, change is hard, but one should not resist the change just because it's a change. Few side notes: 1. As far as I have noticed - systemd is well documented, modular and have documented interfaces between modules. 2. The syntax of any declarative init files is and will be simple enough to write a conversion script. That's not possible to do with sysvinit shell scripts. Thus any possible future change will be *easier* and not harder that this step. O. -- Ondřej Surý <ond...@sury.org>
