2007/4/4, Bernardo Innocenti <bernie@xxxxxxxxxxx>:
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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
