IRC meeting

[Rob Ubuntu Linux]

On Nov 29, 2007 5:36 AM, Ismael Luceno <ismael.luceno at gmail.com> wrote:
> El Mon, 26 Nov 2007 20:10:17 -0700
> "Shawn Rutledge" <shawn.t.rutledge at gmail.com> escribió:
> > On Nov 26, 2007 4:43 PM, Scott James Remnant <scott at netsplit.com>
> > wrote:
> > > 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?
>
> Because that means limiting functionality.
>
> > > Can save snapshots of the system status ... And why is this
> > > useful?  If you want to snapshot your system, hibernate it.
>
> They are good to tell what happened to the system between two events,
> "rewinding", and even to make easier to reproduce some bugs.

If you don't have complicated linking of external features into the
process, but have seperate process address spaces, you are far less
likely to have to do this.  Similarly fork-ing an external process,
rather than running code in same process (possibly long running
external plugins) also avoids complications like multi-threading to
avoid blocking when it fails to respond in timely way to events.

> > > Services garbage collector ... You don't bother to explain what you
> > > mean here, so it's impossible to discuss.
> >
> It's better to keep some things in memory for some time, so if they are
> needed again, you have them already, otherwise you have to recreate
> them, and that costs time...

So Upstart can use messages to the daemons, via communication
protocol.  When the process has finished a task on one instance,
rather than shutting down, it can sleep on a control event, which
could task it to another instance.  If the daemon has been unused for
a long time, then Upstart can send "TERMINATE" message and restart it
on demand later if it's used again.

There's going to be an overhead off CPU cycles and memory bloat,
adding fancy features, that a "minimalist" implementation does not
pay.  An event driven init daemon, mostly starts other processes,
which are relatively long running, where rapid event rate is expected
the client daemons probably would arrange to receive them directly, or
support operation via a pool of worker processes.

> > If you look at the list of plugins for init-ng, it's longer than I
> > would have guessed.  They made everything into a plugin...
>
> Yeah, almost every functionality in initng is implemented by a plug-in;
> that makes the development of new/experimental features a lot easier,
> just because the new features can coexist with older ones.

But this is feeping creaturism, features to ease implementation of
other features, few of which seem to be justified by end-user
requirements.

Sys Admins are concerned with security and stability.  When I look at
a page like http://www.initng.org/wiki/Documents_Pluginsl frankly it
scare the willies ouf of me.  For example :

libchdir.so   - Change Directories "Change current workdir before
current launch code is executed"

What is wrong with having a shell script wrapper, around a daemon to
do that on few occasions it's required?   A configuration script
option that causes the chdir(2) in the child on forking as a  general
facility, should reuse script parsing code, and add a few lines only,
plus a chdir(2) call in the child after forking before exec.

In the Init NG example for libchdir.so
http://www.initng.org/browser/initng-ifiles/trunk/initfiles/daemon/vdr.ii
it looks like you end up with quite a tricky script anyway.  So it
doesn't look like there was a real gain.

As for "libcpout.so initng's colorful output" and in light of our
convesation "libdbus_event.so" I think I stop digging now.