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."
Bahahah! Kill opensource drivers! right!
Anytime you come with a new and potentially revolutionary idea, you are going to run into old stick-in-the-muds who will try to bury you in a flood of FUD. FUCK THEM! If you think it's a good idea, GO FOR IT. PROVE that it works, then let the community sort it out.
-73, de n1ywb
www.n1ywb.com
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.
expect a million people saying "dont do it, it's the end of the world as we know it"
if you write it and it works it'll be an amazing feature that will make the world a better place
if you write it and it doesnt work, no one will use it and no worries. it'll be a learning experience
everyone else has an agenda up their butt =)
shaolin punk, activist post-industrial
one of the things that always bothers me is the amount of programming knowledge i have to have if a driver doesnt autodetect and autoload
i dont want to nessecarily start debugging drivers under linux or having to compile them
thats for developers of the drivers.. not the users of the drivers
so a thumbs up to your vision
back in the day we didnt have no old school
Prevent email address forgery. Publish SPF records for y
Forget the naysayers. Looking over what you have done I have to say its a start. It could even help users who are afraid of linux because of driver issues. However after seeing this comment alot "
-Money to allow me to spend more time on this project, so i dont need to run off and get a job anytime soon. ", I'd recommend possibly toning that down a bit. It struck me in a negative fashion as I am sure it will strike alot of people. Thats just my 2 cents. As to hardware however, I may look through my piles of stuff to see if there is anything I can send you to help out.
"why don't you just slip into something more comfortable...like a coma!"
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.
What happens when "Driver On Demand" trys to get a driver for my network card, but it can't, since my network card needs a driver? :-P
Tough luck for them. They don't need to use your software,and they don't need to include it in their distributions.
If it were built into Mandrake or Knoppix or Fedora, I'd love the feature and never think twice about it.
The world will not get better through technology. We must seek to be better people.
I agree that it's wonderful to have devices work easily. The way I've achieved this historically, has been to have a current kernel. Most Distros add all the usefull drivers into their release of the kernel.
I know that people are afraid of it, but compiling the kernel isn't that big a deal ( especially if you don't mess with the config and just include everything ).
On the other hand, as someone who has to deal with supporting end users, I like the idea that people will be forced to learn wtf they're doing before they're able to do it.
Most of the 'stupid' users out there are simply lazy, and feel that if they whine long enough the computer will do for them.
Sitting Walrus Blog
The centrino wifi drivers I have agonized over for the past two months. I am so frustrated with the overall driver config that I'm about to throw my laptop out a window.
I am tired of having to recompile my kernel because some function isn't enabled by default (hotplug in this case.) Frustration with the 2.4.25/6 kernel forced me to dig around looking at the 2.6 kernel. Then finding out that the (2.6.6) kernel version has a problem with my laptop in atkbd so whenever I press a certain key I get a kernel error, oh but now modprobe ipw2100 works as long as I make sure I compile the driver in legacy firmware mode bypassing hotplug. Not to mention the fact that there are little inconsistencies in procedure between kernels and packages. Not that this is the kernel developers fault, but having to enable PCMCIA support in the 2.6 to get HOSTAP to compile and having to disable it in 2.4 is something that the joe-blow consumer isn't even going to comprehend, let alone know how to do via config/menuconfig etc.
Automatic driver installation would be a headache to secure, but the need is surely there. My headaches are those of someone who's had to do this before... I can only imagine the headaches of someone un-initiated.
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
I am a computer geek (both personally and professionally) and I _hate_ spending long amounts of time trying to get my hardware working in Linux.
I welcome something like Kudzu matched with an automatic driver download / install service.
There are ways to help with the security aspects, like requiring digital signatures, giving the user plenty of information about who is providing the driver, etc etc.
And frankly, I don't care if the driver is open source or not. Yes, I do prefer open source drivers, but when it comes down to it, if I have to deal with binary only to make a great piece of hardware work well, I can cope. (NVIDIA drivers, anyone?)
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
Looks like a big potential security risk to me. And the same reason why it's disabled on future Windows OS's.
-- I don't buy it, I grow it.
Why only drivers? Why not all software on demand? Perhaps package by package (apt-get & such almost do this already).
Even better: file by file on demand. Why should I install all the 100 files of a package X today if my usage habit only really accesses 10 of them today, and 10 more tomorrow, and others never.
Hmm... While we are at it, why stop at file level. Why not memory map the remote files to local VM and fetch them page by page on demand from the network? Persistent local page cache (a new sort of swap file) would make it fast after first fetch.
Anssi Porttikivi / app@iki.fi
The Linux driver situation is a disaster right now. The Linux kernel folks are unwilling to do any work to make it easier to load new drivers. Everything must be compiled from source. There is no standard way to figure out where the kernel source is. The process always emits threatening messages about kernel taining, or warnings about SUBDIRs, or other things that scare the hell out of customers. Binary kernel modules are the answer, not because developers are dying to write closed source modules, but because the idea that every single customer must compile these drivers from source is a support disaster!