Standardised Hardware Support Spec - Please Review

[Matt Zimmerman]

On Fri, Apr 06, 2007 at 02:36:50PM +0100, Alex Jones wrote:
> On Fri, 2007-04-06 at 14:03 +0100, Matt Zimmerman wrote:
> > Your proposal seemed to call for one: "something not too unlike the
> > Restricted Drivers manager".
> 
> Right, but then you don't /need/ gnome-app-install. It's useful, but you
> can live without it. It's a tool that interfaces with the package manager
> for a specific purpose, the same way that update-manager deals with
> updating system packages, restricted-manager deals with restricted driver
> packages and a hypothetical hardware-support-manager deals with HSPs.

restricted-manager is needed because of the special requirements of the
restricted driver setup.  It ties together the X server configuration,
kernel modules, licensing, the package system, etc.  It would be preferable
if they didn't require such complex handling, but for now this is the best
solution available.

> > Similarly, I don't see how a new set of metapackages for every supported
> > device (even if that were possible) helps to simplify this.
> 
> You say that as if it isn't possible. Why?

Because of the size and rate of change of this data.  Who would collect,
formalize and maintain it, and how?  Tens of thousands of devices are
supported by Ubuntu.

> And I suggest it helps to simplify this because currently if I want to
> install an exotic piece of hardware that isn't supported out of the box,
> I may have to chase down several different packages if there isn't a
> metapackage to bring it all together for me.

The examples you've provided so far are all for common devices, where I
think that providing support by default is a more effective option.  Do you
have particular devices or packages in mind here?

Your proposal includes as an example a metapackage which depends on:

- The USB storage kernel driver - an 88k module included with the kernel
  supports hundreds of different devices by default

- The HAL FDI data for your phone - 140k of similar data included in the hal
  package covers hundreds of devices by default

- Icons from Tango - I'm not sure which ones you mean, but Tango includes
  thousands of icons which are generally a few kilobytes each, and the
  hardware-related ones apply mostly to a wide range of devices

I don't see the value in splitting these into separate packages; the current
scheme works very well and is much simpler.  The package metadata and
maintenance overhead would easily outweigh finer granularity for the end
user.

> If all of the hardware in the world was supported in Ubuntu (even if
> that were possible :P), by both Linux kernel modules, and by the huge
> number of userspace services and configuration tools required (/further/
> padding out the default System Preferences menu), then no, this wouldn't
> be an issue. I leave it to anyone who reads this to decide if it is an
> issue or not.

I don't think there is a tangible general problem to be solved here, and
that the issues you raise are likely to be more easily addressed directly
(as with gnome-pilot) rather than by new infrastructure.

> > > I've noticed that in my restricted drivers manager, it has chosen to
> > > install "Lucent/Agere lindmodem controller driver". I didn't even think
> > > I had a modem, and even if I did, I certainly have zero use for it.
> > > What's the point in knowingly "infecting" my system with closed-source
> > > kernel modules when you don't even know if I want it?
> > 
> > The point is that you don't have to care unless you're interested.  Most
> > users don't want to think about installing drivers; they just want their
> > hardware to work.
> 
> > Linux includes hundreds of device drivers, and although most users only
> > require a small number of these, and some of them are used only by a very
> > few users, we bundle as many as we can.  The disk space they consume is a
> > trivial concern compared to enabling hardware out of the box.
> 
> I still don't understand why you use this argument as a case AGAINST
> this specification. I am merely suggesting that we formalise and
> reorganise the hardware support policy -- the same myriad of devices can
> be supported out of the box if you so desire. If I'm missing the point,
> please elaborate.

I was primarily answering the question you asked above.  The reason this
driver is on your system is that some users do need it, and the approach
we've taken in Ubuntu is to support a wide range of hardware by default.
This involves a tradeoff in disk space and (occasionally) a menu item, in
exchange for simplicity.

Other distributions take different approaches to this problem.  Guadalinex,
for example, uses a system called Hermes, which dynamically installs new
packages when hardware is detected.  This is very much along the lines of
your proposal, and so perhaps that project would be a good place to explore
these ideas.

-- 
 - mdz