Alternative Init System

[Daniel Pittman]

Yuki Cuss <celtic at sairyx.org> writes:
> Rocco Stanzione wrote:
>> I'd be surprised if this hasn't been brought up before, but since I
>> haven't seen it I'd like to mention it here.  My experience with
>> supervisor-style init systems, specifically runit-run, has left me
>> with the opinion that the sysV system has served its purpose and is
>> ready to be replaced.  I spend a lot of time on the support channels
>> on IRC and I'd say startup times are among the top 20 complaints I
>> see.  Since most of the startup time is consumed by starting services,
>> and since supervisor-style init systems start services concurrently
>> and very quickly, this could make a huge impact.
>>
>> I don't think that this by itself constitutes an excuse to make such a
>> huge change, necessarily, but I do think it's a compelling argument
>> that should be part of the discussion, if there's to be one.
>> Stability is another.  I've experienced stability problems with poorly
>> written init scripts, but otherwise it's inherently more stable than
>> sysV by virtue of the fact that services are "supervised" and that
>> runit-run (for example) knows how to restart services that have
>> failed, crashed, locked up etc. without user intervention.
>>
>> Not all services are good candidates for such a system because it's
>> assumed that a supervised service can be un-daemonized and can write
>> its logs to stdout and/or stderr, and of course some services aren't
>> daemons at all.  But I think moving services that can be moved to a
>> system like this could make a significant impact on stability, startup
>> times, and in some cases performance.
>
> I am well in favour of this decision. At the moment, even something as
> simple as configuring network interfaces can cause a system to stall on
> boot, even indefinitely. I suspect a large number of services are not
> dependencies of the desktop system, or even of the server system, deeply
> enough to say that we must wait for them to finish (or even start)
> initialising before we can log in.

One thing to note: as a consultant I have a lot of clients running
Windows machines, and I can't think of a single one of them who has not
complained to me at some point about Windows being slow after a reboot
or login.

That slowness comes down to XP and 2000 implementing pretty much what
you are advocating here - booting enough to get the GUI up, and letting
the rest of the system run in the background.

If you are lucky enough not to deal with this, that can be anything up
to ten minutes on a relatively modern laptop, because the slow disks
keep things moving slowly, and running all the code in parallel makes
for a lot of seeking.


Obviously this isn't a terribly scientific study of preferences, but I
do feel that end users are not always entirely pleased with the
performance implications of booting services under the GUI.

	Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20060227/5698be6e/attachment.pgp