sysvinit VS initng VS upstart VS launchd (Was: Future New Init for FC7?)

[Rudolf Kastl]

2007/4/4, Bernardo Innocenti <bernie at develer.com>:
> Rudolf Kastl wrote:
>
> > actually i am using und helping with development of initng since
> > around a year now on my boxes and it wfm. i boot graphically into gdm
> > in about 15 seconds with some basics and NetworkManager started.
>
> My experience was similar: initng brings up the system so quickly that
> I can't even *see* what's going on before X replaces the console.
>
>
> > initng will also get an event plugin for event functionality and also
> > has a nice modular design.
>
> This is IMHO a "must have" for next generation's Linux init system.
> It's not worth breaking a mature critical system such as SysVInit just
> to save a few seconds of boot time.
>
>
> > with the next release iteration there will also be a new init script
> > system using posix compliant init scripts.
>
> This is also important in my opinion: those .i files with their custom
> syntax are the reason why I said initg looked a bit kludgy in my original
> posting.
>
>
> > yet i only saw upstart running in compat mode and upstart in compat
> > mode has exactly 0 benefits towards systemV because it still uses the
> > systemV init scripts without parallel execution plus it adds yet
> > another useless sleeping process in that state.
>
> What do you mean by compatibility mode?  I've only seen Upstart in
> Ubuntu Feisty.  Booting was so fast that I assumed it was parallel
> already.

actually what i mean is simply that if you use upstart with the
backwards compat option all it does is exactly behave like systemV
with no benefits at all.

if you are interested i could send you an upstart src rpm that should
also install in parallel cleanly and boot up fedora. boot time is
exactly the same as with sysV as in this mode it exactly behaves like
sysV.

>
> The nice thing about Upstart is that it looks and feels familiar
> to anybody who's used to sysvinit.  Except that /etc/inittab is
> gone, but nobody will ever miss it ;-)
>
>
> > launchd doesent build on linux for me yet. if anyone has patches it
> > would be great if he could make em public.
>
> Maybe the APL could be a problem for such a core component.
>
> The design of launchd also appears less orthogonal to me than the
> alternatives, altough I understand that crond and inetd should
> somehow coordinate with the init system to get a number of corner
> cases right.
>
> Also, a radical approach such as launchd is less likely to become
> mature enough to replace sysvinit in the short term.  You'd need
> massive coordination between hundereds of package maintainers.
>
> And by the way: the init system is not something I'd like to see
> forked in every Linux distro.  Ubuntu adopted Upstart early and
> Debian will most probably follow soon or later.
>
> LSB had just finished standardizing the init scripts and now we're
> going to break things again.  Users *are* going to complain.
> Analysts *are* going to say Linux is fragmented.  Microsoft *is*
> going to publish studies saying that Linux has higher TCO because
> of multiple init systems ;-)
>
> So maybe it would be wise if the remaining mainstream distros,
> including Fedora and SuSE, followed their lead quietly instead
> of starting a pointless init war.

its not about politics here... in my eyes it must be a plain technical
evaluation and decision based on technical facts rather than looking
at what other distros do. if i wanted exactly what other distros do id
just use those.

all distros also have their own config tools... their own installer...
their kernel flavour with their own patchsets etc etc. i dont see
where this really hurts development. as someone else pointed out its a
good idea to make it parallel installable (my upstart test package is
parallel installable and initng in fedora-extras is aswell) and see
where those systems go in the future. having 2 solutions ready is
generally better than only one.

>
> This doesn't mean there should be a single codebase.  Multiple
> systems could compete as long as they are 100% (or maybe just 99%)
> compatible config files and user interface.

those need a new standard then or the existing standards need to be
enhanced to reflect the additional functionality. from my current
point of view the init scripts we use today are bash hacks with lots
of workarounds in it and the current "standards" encourage to do those
hacks instead of getting the things fixed upstream and the daemon
functionality properly done.

that was one of the positive things about the .i files because it
encourages upstream / maintainers to clean up the init script
functionality actually and not to use workarounds scripted with bash.

regards,
Rudolf Kastl


>
> --
>    // Bernardo Innocenti - Develer R&D dept.
>  \X/  http://www.develer.com/
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>