(and other identifying information) to be associated with a particular
driver. Each driver could have an embedded unique ID to simplify
identifying drivers. The driver IDs in the database are then
associated with URLs for downloading. A simple driver package format
(like a zip file with a manifest that describes where the driver is to
be installed) could be used to automate installation. That is what the
URLs would point to.
Upon installation of Haiku, users are urged to join the "Haiku Driver
Management System", which will take all the hardware devices they have
working and upload that information to the web application (PCI IDs
and the working driver ID.) Any non-working devices will be queried
for on the web application. If a matching driver is found, it is
downloaded and installed. If no match is found, the user is politely
informed that unfortunately there is no driver for that device, but
the HDMS can query the system weekly to see if a driver has been
provided in the meantime.
We in the Haiku project can regularly query the hardware management
database to see which devices lacking drivers are the most popular.
This information can then be used by Haiku or other third party driver
writers to implement the most needed drivers.
Sounds pretty darn good to me :)"

Comments (1)

Subscribe to this comment's feed

thenerd said:

I think a service similar to what you describe would be excellent. I also like this statement "We in the Haiku project can regularly query the hardware management database to see which devices lacking drivers are the most popular. This information can then be used by Haiku or other third party driver writers to implement the most needed drivers." This would be much better than developers guessing what hardware is being used or relying on incomplete user feedback. I like the bounty idea as well. It seems to work for eComStation (and OS/2) software.

report abuse vote down vote up

June 05, 2007 | url
Votes: +0