IRC meeting

[Scott James Remnant]

On Sun, 2007-11-25 at 18:24 -0200, Ismael Luceno wrote:

> Look at the following document:
> http://ismael.linuxdevel.net/init_issues.html
> 
A reasonably quick reply to the issues here in the interest of starting
debate.  There's almost no text backing up why you think these things
are important, so it's hard to discuss.


Debugging interfaces ... why spend time developing debugging interfaces
for when init crashes?  Why not spend that time making damned sure that
init can *NEVER* crash?

Whatever you invent is of little use; if the user knows how to debug
init, then they will do so anyway.  For the common case, a core file to
attach to a bug report is sufficient.

Upstart, in the extraordinarily unlikely circumstance that it might
crash (0.3.8 hasn't had a single report of one in the 1 year+ it's been
out), simply forks and dumps core in the child -- thus generating a
useful core file.  Ubuntu's apport hook will catch this and ask the user
if they'd like to file a bug report.


Control Events can be queued ... err, I have no idea what you mean here.
Control events come over a socket, so they're already implicitly queued
by the kernel and/or message bus.


Can be replaced while running ... Upstart can be replaced while running,
your "No" is wrong.


Can save snapshots of the system status ... And why is this useful?  If
you want to snapshot your system, hibernate it.


Monolithic ... yes, Upstart is monolithic.  This is a GOOD thing.
Effort is instead put into making sure that the IPC system is flexible
enough for other processes to ask Upstart to do things on their behalf.


Memory management ... this seems to be a simple critique of programming
style?  How is this relevant for feature comparison?


Logging ... Err, we have perfectly good logging daemons in Linux already
- why invent another and why build it into pid#1 ?


Services garbage collector ... You don't bother to explain what you mean
here, so it's impossible to discuss.


Multi-stage boot support ... Upstart allows you to have as many boot
stages as you want, e.g.:

	start on startup
	script
		initctl emit startup-phase 1
		initctl emit startup-phase 2
		initctl emit startup-phase 3
	end script

You can now run things "on startup-phase 1", etc.


Device to service mappings ... See this list passim.


Service availability monitoring ... Upstart has various mechanisms for
doing this, and is (afaik) the only one that supports supervising daemon
processes.


Scripts ... why does this matter?


Runlevel support ... Runlevels are ancient history, forget about them.
That being said, Upstart's sysv compat tools emulate them so you can't
tell the difference.


Dynamic service reconfiguration ... supported via D-BUS, but, why would
a service do it to itself?


Multiple service instances ... Upstart has this; instantiation of a
service can be limited to a singleton, limited based on environment or
unlimited.


Events ... "limited" ?  Why do you think so?


Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20071126/55a2c927/attachment.pgp