[openbeos] Re: Automatic hardware installation / system updates
- From: Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 04 Apr 2005 21:25:06 -0400
This really belongs on the GE list. :-)
On 2005-03-30 at 17:47:11 [-0500], Linus Sarnhult wrote:
> - I hate, how whenever I want to get a new piece of hardware.. I first have
> to find out what kind of hardware is supported (ofcourse this is the case
> with any non m$ os.. not much you can do about it..)
This isn't going to change. We can only work toward ubiquity. :-D
> - I hate, how most of the time, I end up with just a bunch of chipsets, for
> lets say.. eeeehm... a wireless card.. (can't write drivers for ALL hardware
> ofcourse.. so it's acceptable) .. but does the average user even know what a
> chipset is?
This is a problem that is pretty tough to solve technically. The biggest
problem is that when company X puts out a chipset, any company Y can come along
and use X's chipset (usually pretty easily) to put out a card. Or embed it on a
motherboard. Or in a USB device.
> - I hate.. how I then.. have to find out what hardware got that chipset..
> (painful painful process) .. at BEST.. the hardware is listed on bedrivers..
> but even if people get other hardware to work.. I'm pretty sure most don't
> bother to send that info to bedrivers.. cause most people are as lazy as me.
Yes.
> - And then finally.. I get a brand spankin new piece of hardware..
> supposedly working with beos.. then BAM.. the new revision of that hardware
> had a chipset modification, and therefore isn't compatible.. THE F**L??
Yes.
> Anyways... When I launch up beos.. it identifies my hardware and (I think)
> iterates through all the drivers.. trying launch any drivers who found their
> supported hardware (or chipset)..
Yes.
> THE IDEA..
>
> - I would love.. that whenever I lack drivers on my local computer.. and I
> got an internet connection.. it could just look there for drivers, and ask me
> to select/download/install potentially working drivers (selecting from user
> reported success ofcourse) .. as fully automatic BUT user
> configureable/selectable (if wanted) as possible.
This is possible, assuming that some site wants to maintain this. It would
basically be a simple web service. In Python, I think that this would be pretty
simple. With the lack of web service libraries in BeOS, I think that it would
be a little tougher.
> - I would love.. that if I can't find workin drivers, I could still browse a
> tree with drivers, and download/install/try em out..
A small enhancement of the above.
> - And if I get something to work.. I would love to share that information,
> back without having to write a whole bunch of pci id's or whatever is needed..
Could be done, but, the information would only be "somewhat" usable without
comments like "sound out works but sound in does not".
> - Let's say I get that new soundcard to work.. I could go to a
> devices-lookin-application.. select "audio" or "sound" and then "report
> working driver" and then select the driver from the driver database tree..
How is that different than the above?
> - That would result in a record in the databse.. possible.. I could add some
> instructions, or other link other files needed..
That would be the responsibility of the serving website.
> - Then whenever the next user gets that same hardware, it would find that
> record.. give him download/install buttons and whatever instructions is
> needed for the drivers ( and needed other files )..
Yes.
> THE QUESTIONS..
>
> 1. Can anyone point me to websites/code/bebook entries that instruct me on
> how to do the same identification of hardware that the "devices" application
> in beos does?
Take a look at /bin/listdev.
Source is in our tree (src/apps/bin/listdev).
> 2. I can create the server counterpart for this system, since I handle
> client-server and database stuff everyday at work... does anyone want to help
> out to create the client application(s)?
The client should be pretty easy, for what can be done... AFAIK, there is no
way to find out what driver is using what device and what device is using what
driver. You could *assume* that the driver in the server side DB should at
least be offered, but there is no way to report the data back at this time,
again, AFAIK.
> 3. Is this a good idea?
Probably, yeah, it seems to me that it is.
> 4. Is there a packaging system in haiku, and if not, and if I would want to
> make one for identifying dependencies and such.. have anyone got any
> suggestions?
I have talked about my suggestions a whole lot on GE.
> I thought of using the BeFS and just some new filetype for hardware entries
> (that you can upload, if you don't have an internet connection and get a list
> of drivers to download) and for packages that you have installed (so it can
> notify you of updates and such)..
> 5. Should this application/server perhaps be extendible to even handle
> normal software and ofcourse SYSTEM UPDATES (user selectable for different
> versions of tracker and forked application)
I would say probably not. Small tools for small jobs.
> Am I wrong in thinking that with all the stuff that is sooooo easy to do in
> beos.. this one thing with hardware support/drivers is still pretty hard (for
> lets say.. eeehm.. grandma?)
You are right about this one.
Other related posts:
