Slashdot Mirror
Thoughts on Automating Driver Installs for Linux?
Auzy asks: "Originally I thought that the implementation of a system in Linux which could automatically locate and install drivers would revolutionize Linux usability, however, there has been some strong negative feedback, including comments such as that it will kill open source drivers in Linux, and that even a system which employs digital signatures could never be secure enough to stop worms. I believe the opposite, and now I want to know from the Slashdot crowd, if they think I should drop the project now and potentially save Linux from possible security problems, or if I am right in saying that potential problems can be avoided, and that this system can become successful."
One of the reasons I *don't* want to switch to Linux is that I don't want to deal with driver installs with stuff that came out later than whatever flavor of Linux I have. If they could automate this, boy would I be strongly interested in attempting the switch again. Frankly, any steps the community takes to minimize the actual maintenance aspect of Linux would be greatly appreciated. Surprisingly, not all of us want to sit there and tweak the damn thing.
"Derp de derp."
Do I want it easy or secure? Windows is ubiquitous because it's easy. Linux is secure, but complicated and therefore mostly ignored (for desktop use anyway--something that demands drivers be installed). I like Windows because installing drivers is easy. I'd like Linux, but it's hard to install and configure drivers.
GOBACK.
Prevent email address forgery. Publish SPF records for y
It is not a bad idea really. Security and trust can be dealt with. No one on the server will ever run this, some users might. Make sure to have an option of using only open source drivers, or some kind of notification of what is loaded. I would be afraid of silent installs.
Technical issues...
How do you plan to deal with all the different kernel versions? Are you providing your own image version? How do you deal with different architectures?
badness 10000
I don't normally have the latest cutting edge hardware, and so my kernel usually has all of the needed drivers already available. Have you ever tried getting drivers for older hardware in windows? I had an ethernet card that was correctly detected and set up in Linux, and that I had to go download the driver from a shady site in windows.
No. Kudzu is strictly an autoconfiguration utility. It doesn't download and install new drivers.
While I'm posting anyway, I'll drop in my other thoughts on the story to avoid multiple posts:
I could see something like this happening, but I think that it's going to need heavy interaction with the big distros to come out.
If money is a concern (as it apparently is, based on your requests for it) you could try to get hired on at one of the distro companies, though I wouldn't count your chickens (especially since this isn't in a " v1 state" yet). This is stuff related to end-user-experience and configuration, which has traditionally fallen more into the hands of the distro people.
Personally, I don't see any reason this couldn't be used with GPLed drivers or even source distributions of drivers-- download, build, install. I still don't intend to purchase hardware that only has a binary driver.
I'm not entirely sure that it wouldn't be better to extend existing (well supported) management and distribution systems like apt, yum, or red-carpet. It'd be a little weird to have a completely different system for providing driver downloads. Furthermore, your system seems to require that one be online when installing drivers. A caching mechanism may be more useful.
I don't think that you maintaining full control over the distribution server is feasible. Some software vendors will complain ("Why do we need to go through you to make updates available? Are you providing serious testing and QA services for us, or is it just a speed bump?"), and some distros may want to provide reliability guarantees. I really think that, at the least, this should be a distro vendor-provided service (if the drivers undergo distro QA), and if not, the server should basically be a "server tracker" that links to drivers on manufacturer-provided sites.
A couple of issues:
* Because you're specifically providing third-party services, almost all Linux kernel hackers will be much less interested in fixing drivers, and those drivers will not be maintained. Users of binary-only drivers are generally SOL when it comes to kernel hackers providing fixes, and even thirt-party people that don't merge drivers into the mainstream kernel run the risk of having the Linux folks break their driver at every release. Linux provides very weak binary backwards compatability guarantees -- the field is strongly tilted toward open-source drivers. It is difficult to produce and support a binary-only driver.
If you use a signing mechanism, I would recommend GPG rather than a homebrew. It's well-built, widely-available, and there are keyservers already out there. It's what RPM uses.
Remember that signing is *only* useful to the end user if it leverages some degree of trust. Signing on Windows is useless to the end user, because Microsoft does little effective testing of signed drivers -- the only reason the signing mechanism is present is to give them control over who can release hardware products for Windows. It doesn't provide the user a whit of good to have a "signed" driver. That means either letting the end user or distro designate manufacturers that they trust (having a system where any "manufacturer" can be add themselves to the list and their drivers trusted just doesn't work), having distro vendors sign the software after testing it, or signing it yourself after testing (which I'm assuming that you don't have the resources to do).
You should provide a GUI, given that that's all the rage when it comes to configuration these days. It should be optional, as a number of folks only have a TUI available (or only want to use a TUI).
You should provide a mechanism for drivers superceding others (for example, Tulip Ethernet chipsets have a couple of drivers out there -- one is designated as "recommended").
IMHO, you should have a non-interactive mode in which drivers can be installed without users being asked for parameters (and the driver is required to attempt
May we never see th
The Linux kernel runs on x86, mips, ibm mainframes, alpha, sparc and etc.
There are multiple versions of the kernel, smp and non-smp.
Typically, to load a driver module requires building it against the source tree for your particular kernel, which requires a kernel C compiler, and build environment to be installed.
A possible solution is to provide an architecture neutral layer (forth, byte-code) in which drivers could be written. A layer can introduce this to the kernel, giving only a single module to move. Perhaps existing drivers could be "compiled" into this intermediate (C -> driver language or byte-code).
Then, only the interface layer would need to be added into a Linux system -- and if built once, could be distributed as a binary. The "binary" drivers could be compiled into native code on the fly. Perhaps even x86 code could be used as the intermediate system (use something like QEMU to do the translation). Self-modifying code wouldn't be a problem. The "shim" layer for x86->x86 is simply an interception layer.
In principle, this could be done. And yes, I would use such a thing. As it is, whenever I upgrade a kernel, I have to rebuild all non-vendor modules (only 2 -- shfs and wlan-ng) and it is a pain in the ass.
Would sandboxing be of interest? Easier if not, but could be done if something like forth was used (declare the ports that the driver will touch -- provided for inspection to the operator, and trap all other references -- can also be filtered by kernel call).
Of course the shim would have to be GPLd, but would make proprietary drivers even easier than Windows (because they can be cross-platform).
Yes, this is a good idea.
Ratboy
PS I would be interested in working on this - contact me at fred (at) hotmail.com
Just another "Cubible(sic) Joe" 2 17 3061