FWD: Re: [rfc] The Big Picture

[uwesmail2005-lkml at yahoo.de]

Sorry, my mailer dropped the list. Didn't show until after send.

--- uwesmail2005-lkml at yahoo.de schrieb:

> Datum: Mon, 30 Oct 2006 14:36:00 +0100 (CET)
> Von:  <uwesmail2005-lkml at yahoo.de>
> Betreff: Re: [rfc] The Big Picture
> An: "John (J5) Palmieri" <johnp at redhat.com>
> 
> 
> --- "John (J5) Palmieri" <johnp at redhat.com> schrieb:
> 
> > On Fri, 2006-10-27 at 11:14 -0400, David Zeuthen wrote:
> > > Hi,
> > > 
> > > (No, you didn't include the list in the reply (and it's also bad
> > form to
> > > move private mails to lists). Anyway, whatever.)
> > > 
> > > In my opinion I'm not sure it's a good thing right now to make
> > D-Bus
> > > depend on Upstart with the current concerns that a number of
> > > distributions (including at least Fedora) now have wrt. what
> > Upstart
> > > really is cf. my previous mail. There's also some problems if
> > Upstart
> > > starts depending on D-Bus but that's probably solvable.
> > 
> > D-Bus will never depend on an outside tool period.  It is designed
> to
> > run as a generic desktop bus on many platforms, not just Linux.
> > 
> Then upstart should be part of D-Bus, but as separate process. Or
> we call it "privilege separation" and develop from the separate
> privilege process the same that upstart is. We will get to the same
> goal eitherway, but later if we try to NIH.
> > > If you or the Upstart team wants D-Bus or HAL teams to use
> Upstart
> > for
> > > stating processes... then it would probably be good for them to
> > explain
> > > why this is useful on their respective mailing lists. I'm not
> sure,
> > > being the HAL maintainer and a D-Bus developer, why it's
> desirable
> > > though and I don't think Upstart developers do either from what
> > Scott
> > > said on this list a few weeks back.
> > 
> What I got from this discussion (yes I lurked in the archives) is
> that
> upstart, system bus and HAL need to be very conscious about security
> and implement essentially the same function (starting external
> programs)
> in three slightly different modes. Because upstart does nothing else
> (the events I explain later (away)) it is logical to call that part
> of
> the infrastructure upstart although it's shared among D-Bus,HAL and
> init. Because HAL is a combination of a database that sends events
> about
> its keys and procedures that run at hardware discovery, I think it's
> good to separate this into the database and that what fills the
> database
> eg. coldplug (which shouldn't be in memory after boot). So these
> parts
> have to communicate. The best tool for this is the system bus.
> Because
> all programs need to find the database it will get the name HAL. Now
> we
> have a database (really an array of key-value pairs) on the system
> bus.
> This database could get the configuration for the init process too.
> That
> means which daemons to run in which runlevel and which daemons are
> running already. Not how to run which daemon. Because of security
> concerns, and because it elegantly solves the problem how to start
> the
> database daemon (where that config would live otherwise) without
> having
> that config. Because that database informs its clients with signals
> on D-Bus about changes in content, the events the ustart init needs
> are
> automagically falling of from this implementation. Before anybody
> asks;
> Yes, there could be a separate program that turns these signals into
> tasks upstart (the program loader) has to do, but I think because it
> has
> to run anyway all the time, it should better live in the upstart
> process.
> I think there are three areas of expertise for three software
> projects:
> * secure starting of processes
> * secure authentic communication
> * memorizing system(hardware) state with access rights and
> notification
> I recognize the central aspects of upstart,D-Bus and HAL there, but
> not
> the exact perimeter of these software projects. By shifting these
> boundaries along the lines above I think we could get
> * less memory footprint
> * more security
> * and for the desktop
> ** a session manager who understands the session bus
> ** the session bus with optional user bus functionality without
>    implementing an user bus
> ** a platform neutral session configuration with cangeable backends
> > Bigger picture views shouldn't go into a spiderweb of details on
> > specific technologies.  It should spell out the general goals of a
> > project with small bite sized sections where we can go down and
> talk
> > about details of implementation (D-Bus and HAL were spawned from
> such
> > a
> > high level document).
> > 
> My Big Picture was the cooperation of these three projects and
> possible
> points of extension (SSH,login) in a way that gets most of the other
> goals for free.
> > > (The train kinda already left the station with D-bus though... I
> > mean,
> > > with D-Bus 1.0 coming out RSN and all.)
> > 
> > True, D-Bus is concentrating on stability right now instead of
> flash
> > in
> > the pan sexiness.
> > 
> Ok, D-Bus came into my Big Picture with the fewest changes, so even
> that
> goal is reachable. But that is because it already has settled in the
> sweetest spot, expertisewise;-).
>  
> 
> 
> 
> 		
> ___________________________________________________________ 
> Telefonate ohne weitere Kosten vom PC zum PC:
> http://messenger.yahoo.de
> 





	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de