IRC meeting

[Rob Ubuntu Linux]

On Nov 27, 2007 3:05 AM, Ismael Luceno <ismael.luceno at gmail.com> wrote:
> El Mon, 26 Nov 2007 23:43:58 +0000
> Scott James Remnant <scott at netsplit.com> escribió:
>
> > On Sun, 2007-11-25 at 18:24 -0200, Ismael Luceno wrote:

> Yeah, that's good, as long as you don't end implementing too much
> functionality in the core, the main reason for InitNG being
> plug-in based is that you can replace parts of it without disturbing the
> rest.

That's  a good point.  I just wonder if you don't get more benefit by
having seperate processes with their own address spaces, and use IPC.

> > Logging ... Err, we have perfectly good logging daemons in Linux
> > already
> > - why invent another and why build it into pid#1 ?
>
> Well, there's no reason to implement it, but there's no general
> facility for that InitNG, that's why it says "Limited". I like to
> have a generic interface for this just because some embedded systems do
> not have syslog, in these cases it could be replaced by a simplistic
> logging plug-in.

On those boxes, isn't a good solution to implement a simplistic
syslog?   You could do this by conditional compilation to init(8),
rather than a plug in, couldn't you?

But if a lite syslog is created in it's lite weight libc, then that
embedded system would benefit from the general facility, that would
not need re-implementation.

If you mean init(8) is then providing logging daemon features to whole
system, in 1 process, don't you get problems with prioritisation?
When the new init(8) is responding to events, is very probably the
time when log messages are going to be created and want buffering in a
process.

In general don't RT ppl like to have time guarantees on response to
events, but have logging and such done as a low priority background
task?

I also wonder about stack limititations in small machines, which could
make complicated programs, unpredictably unreliable under load.

> D-BUS is not an option in some systems. For example, I have an old
> Pentium III as server, and it doesn't uses D-BUS, why it should?

But if removing the dependancy means re-implementing the features,
then what do you gain by not using the original?

According to http://www.freedesktop.org/wiki/Software/dbus

"The D-Bus low-level API reference implementation and protocol have
been heavily tested in the real world over several years, and are now
"set in stone." Future changes will either be compatible or versioned
appropriately.

The low-level libdbus reference implementation has no required
dependencies; the bus daemon's only *required* dependency is an XML
parser (either libxml or expat). Higher-level bindings specific to
particular frameworks (Qt, GLib, Java, C#, Python, etc.) add more
dependencies, but can make more assumptions and are thus much simpler
to use. The bindings evolve separately from the low-level libdbus, so
some are more mature and ABI-stable than others; check the docs for
the binding you plan to use."

Surely a PIII 800 Mhz can handle XML parser of the low-level libdbus?
There's a PIII 128MB RAM running Compiz-Fusion quite nicely on youtube
at the moment!