Re: [Utopia] Roadmap to Utopia

[David Zeuthen <david fubar dk>]

> As far as discovery, I think that hardware should just start working.
> The user should have minimal interaction with the system in that regard
> - if the user attaches a new device, that act alone should signify that
> the new hardware works.  E.g., plugin a printer, now you have a new
> printer to print from.  Plugin a new drive, and a new drive appears in
> Nautilus.
> 

Yep, right, but these are the simple use-cases.

> For device browsing, something like hal-device-manager is fine.
> 

Emphasis on "like" :-) hal-device-manager is just a crude hack I wrote
one evening last year! I think an application like this is key - it
should probably be hidden somewhere though.

> >  3. What happens when hardware is removed? How is the user notified?
> >     (Both questions probably needs to be answered both when the system
> >     and/or GNOME is running and when it's not)
> 
> We could use a little glowing GNOME applet for this.  Or, do nothing -
> again, the user ought to know that they just unplugged something.
> 
> >     Does the user have to do something before unplugging a device when
> >     the system is running?
> 
> I think we should definitely aim for a big definite NO here, except
> where otherwise impossible.  E.g., users have to unmount storage volumes
> before removing the backing device, and they are going to have to learn
> to live with that.  But, otherwise, the user should be able to rip
> anything out at anytime.
> 

Come on, people are going to yank out the device anyway :-) But yeah, we
concur here.

> >  4. How does the presence of hardware notification and configuration
> >     affect the ecosystem of applications at the GNOME level? 
> > 
> >     To be more concrete, look at gnome-volume-manager - currently it
> >     can start applications like totem and gthumb. Is there a need for
> >     a richer model? Should applications be able to register themselves
> >     with g-v-m on installation? For instance, if I install Rhythmbox
> >     should it register itself as handler for music players (e.g. ipod)?
> 
> Yes, applications should be able to register themselves, although not
> with g-v-m I do not think but with a generic MIME-like responsibility
> database.  E.g., "music player" should be a type.  Or, "CD Burner" or
> "Video player".  Just like we do today under default applications for
> text editors and web browsers.
> 
> Then g-v-m just queries those preferences.
> 

Sounds good.

> >  5. How does auto configuration play with different distributions and
> >     operating systems? 
> > 
> >     I mean, presently we use HAL to abstract all the hardware
> >     which is all good, because we believe that it can run
> >     on other OS'es than those based on a Linux 2.6 kernel. But HAL is
> >     deliberately designed to avoid policy decisions and e.g. rely on
> >     the OS/distro to load kernel modules and so forth.
> > 
> >     In other words: How does software at the GNOME level apply
> >     configuration parameters that is OS/distribution specific?
> 
> At some very high level, unless distributions unify their settings,
> these things are going to remain vendor-dependent.  Take networking
> configuration, for example.  I am working on callout code for that now.
> Different vendors can obviously share HAL, the callout scripts I am
> writing, and maybe some other glue.  But since we have different
> configuration files, and different configuration utilities, that stuff
> will remain separate.
> 
> But that is not any change from the status quo today - e.g., whether or
> not Project Utopia is implemented on a given distribution, you still
> have vendor-specific configuration utilities.  If vendors ever unify
> around a single configuration utility, then that code too will be
> shared.
> 
> The further up the stack you get, the more vendor-specific and
> policy-specific you get, so naturally the less and less that will be
> shared.  I think our goal is to make the infrastructure as rich,
> flexible, and kick ass as possible so as little nontrivial stuff as
> possible is not shared.
> 
> For example, take the current system stack in Red Hat: the kernel,
> MAKEDEV, kudzu (and all of that stuff), and the redhat-config tools.
> Plus all the RH-specific stuff such as initscripts, networking scripts,
> configuration files, and other magic.
> 
> Project Utopia could unify almost all of that, but not all of it.  The
> big thing to get rid of in the above is kudzu, imo ;-)
> 

Right, this is all spot on. They are real issues. In addition, there are
several reasons, not only technical, a distribution has it own
configuration tools and we should probably not try to change that. There
is also g-s-t to factor in.

Hopefully, most configuration can happen as hal, udev or linux-hotplug
callouts without user intervention; very related to the mantra "device
should just work without user intervention".

What I do think we need, though, is to have some kind session-space
daemon running, much like g-v-m, to help the user with configuration of
devices that needs user intervention. And display a glowing icon saying
"yup, your device is ready for use" or complain "dude, you pulled out
your storage device without unmounting etc."

So, this hypothetical daemon, let's call it gnome-device-manager or
g-d-m (in search for a better name), would react to events from hal. In
the future it might even callout vendor specific configuration tools? Or
something. I'm not sure.

> > I'm hoping that at some point we can identify a) existing apps/
> > components that can be enhanced as part of the Utopia process; b) new
> > apps/components that needs to be developed; and c) end at some kind of
> > roadmap. For this identification process, maybe it's useful to look at
> > one device type at a time, e.g. networking devices, storage devices,
> > input devices, music players (e.g. ipod), cameras and so forth. 
> 
> We did this here at Ximian.  Joe and I sat down with our lead designer
> and hashed out use cases for a whole bunch of hardware.  I posted most
> of those to my blog a week or so ago.
> 

Yeah, I saw them, they're a great start. 

> I think the initial goal for Project Utopia is laying the infrastructure
> to do neat stuff with the hardware.  As we move out of that phase (and
> we are - HAL is maturing, etc.) we can start figuring out how the
> hardware events we are generating fit into the GNOME world and what we
> can do about them.
> 
> I think g-v-m solves the storage issue pretty well (although we still
> need some gnome-vfs loving), Joe hacked HAL into CUPS, and I am working
> on some callout scripts for networking stuff as we speak.  So we are
> getting there! :>
> 

Yeah!

> > However, I think it might be best to have a discussion on the generic
> > level first, e.g. how does the user relate to hardware, cf. points 1-6
> > above.
> > 
> > Oh, and there's probably a bunch of technical issues, we'll get to them
> > at some point :-)
> 
> I feel that if you look at all of the current Project Utopia work (dbus,
> udev, HAL, policy stuff like g-v-m), plus the 2.6 kernel work that went
> on, we have a lot of the technical issues solved.  It is all the other
> "stuff" that needs to be done. ;-)
> 

Exactly - and I believe, this is why we are having this conversation :-)

Take care,
David