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.
Doesn't kudzu do something to that effect?
This sig no verb.
The worst thing that can happen is that your project evolves into something else entirely, and in the meantime you find out if it works.
People hate change, so sometimes you just have to do what you want.
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
I don't think such a system is any worse than your normal package management system that automatically calculates dependencies and grabs all the relevant libraries.
I assume you'll want to set it up so you only download the drivers from a trusted mirror, not just any yoho website you get from google.
If it's compromised it's compromised. Just like if the package archive on debian or gentoo gets compromised you're screwed.
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
I think it's a great idea, and you should go forward full steam ahead.
Seems like the key is the database. Keep that open and if there are real security issues, a darn good competing project will spring up (with more security) from the same folk who pooh-poohed your initial project. And that is EXACTLY what you and the community need.
Remember what happend with CD signature databases (CDDB) -- it was well populated, but the owner of the data was... well... the OWNER.
Keep it open, and this project won't fail -- it'll morph into three others.
Will this be full automation, complete with an automatic deduction of $699 from your bank account for each update that contains code disputed by SCO?
Don't blame Durga. I voted for Centauri.
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!"
New ideas in Free software always meet with resistance if there is already a 'solution.' If you have a good idea, just impliment it and ignore what anyone has to say about it unless it's a constructive critisism on how to improve it. Otherwise nothing'll get done.
If you get it working, and no one uses or codes on it, THEN you can consider dropping it, but until then, just code away.
i believe that before doing that, the OSS community should reach a level of infulence to convince the big hardware makers to release their hardware as Linux compliant. Cause you can write a driver, and tomorrow morning the same harware vendor will release an upgrade thats gonna waste your few years effort down the drain.
The lunatic is in my head
Ok, let's take a look at the practical side of this.
I pop in a new card. If my distro kernel (and this is mostly aimed at people using distro kernels) supports it the driver is already there it just may take some config, i.e. sound cards and the like.
Otherwise I need a new kernel. Debian's woody release defaults to a 2.2 kernel but has the option of 2.4. Many newbies install the 2.2 and then have non-supported hardware. A project like this won't help them.
The real problem here is the Linux kernel changes often enough and the hardware supported changes often enough that you need to go and grab the latest code to use the latest stuff.
This works on Windows and OS X because the kernel is know and has not changed recently. Every WinXP user has the same kernel and driver needs.
All I see this project helping with are the people with closed source drivers which the user's distro may not have shipped. But even then, only if the kernel versions match -- and they usually don't.
*OR* I see it being a boon to someone like Lindows (aka Linsprire). They could run this server and guarantee that drivers exist for new hardware when users run the Lindows kernel.
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
this would really help a lot! The only problem I can see is: Linux(Linus?) don't want non GPL-Drivers. But IMHO it would give LINUX a big boost if propietary drivers would be officially allowed, even for desktops.
On Windoze the opposite is true.
If more people would automatically run Windows Update there wouldn't be so many worms.
Most worms use security holes that Microsoft fixed long time ago.
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?)
It only becomes a security issue if it decides to install things without prompting or without telling the user where a driver is coming from. As long as it's possible to see what the system is doing and potentially override a bad decision, it's no more dangerous than installing drivers the old fashioned way.
Giving the user a chance to say "no" is vital. There are a lot of people who would be willing to run a signed binary driver from someone like nvidia, but would *not* be willing to install a binary driver compiled and submitted by some random dude somewhere. (And no, I'm not a proponent of closed source drivers. The key word here is *binary*. Given a choice, I'd much rather install an open source driver written by some dude somewhere.) Just don't expect us to trust you that a particular driver is safe.
Offering the option of an "install everything without asking questions" mode is okay, but at least force them to actively acknowledge that they're putting the security of their system in your hands. Many will probably choose it, and that's great. But the linux newbie who plugs in a second network card for the first time ought to be given fair warning.
That said, I'm probably not going to use a system like this any time soon. So far every attempt at hardware auto-configuration I've tried has turned out to be a bigger pain in the neck than just installing things by hand. It also seems like making it work would be really tough. What version of the kernel/kernl-options/kernel-patches/x11/alsa/etc is a person running? Trying to support all possible options isn't easy.
On the other hand, if you've found a way to make it work, more power to you! I'm sure a lot of people will find it useful.
We all know that Windows is not any easier than Linux to use or install.
Linux is both easy enough and secure, but the big obstacle is OEMs still holding out. Most users do not want to install or configure their operating system, they want to just plug in their new computer and have it work, be it OS X or Linux.
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.
Just a few suggestions however.
First, you'll need the distro's working with you on this. But develop first, the distro's will ignore you until you actually have something.
Develop this with support for local module configuration as well. If the module is already there, great, this should pick up on it and configure the module (this resolves the issue of there being a single module for 200 different pieces are hardware which are functionally similar but different model numbers, vendors, etc and all called under the module name which mirrors some ancient piece of hardware nobody has anymore). It also resolves the "nic and the egg" issue.
Make sure it handles simple autoconfiguration of X-Windows. As a technician, I can say of the big barriers to linux on the desktop is that I can't usually take someone elses system grab it, and stick it onto my keyboard, monitor and mouse and load the gui without making a single adjustment, and then when it's done give them their tower back knowing they will be able to plug it in and go.
X is great, it's just missing the part that checks for a new monitor on every boot, it sounds like that would be part of this utilitie's forte even if it would require code that strays a bit from the main body of the app.
Get the distro's in on it, redhat will be against it, because they have kudzu, but once every other distro ships it that won't matter anymore. Right now Kudzu is the best hardware detection out there and gives i386 plug and play a whole new meaning.
Give it a good solid flexible and easy to use interface, make sure it has few dependencies to run local, this way distro's will add it to the installer.
Oh, that should you do it thing, DUH.
This isn't a bad idea, but it already exists. It's called Kudzu and has many other names. You just grab the list of PCI ID's and cross-ref them with your driver signatures. What would be cool is offering a prompt for different versions of the same driver, or alternate drivers for the same hardware (in case one of them bombs on your rig).
What I'd rather see effort pumped into is NOTEBOOK DRIVERS. Please people I have this shiny screaming Dell hotness but I can't get anything to run on it because I'm lacking an Ethernet driver/sound/whatever. Notebooks have become modular things just like desktops, with many models sharing the same chipsets. Maybe an easy X setup that deals with non-standard screen resolutions and dimensions (1680x1050 anyone?).
Make it work on more machines, and more people will be able/want to use it.
-Billco, Fnarg.com
But there is resistance for the following reasons:
1) Encourages companies to release binary-only drivers, which hampers porting efforts and slows debugging (no better than windows)
2) Sometimes changes to the kernel are far reaching and make certain assumed behaviors incorrect (even if certain APIs didn't change). Memory leaks are the least of your worries here.
So then the only other option is to have all the drivers in source form, and built right at the time the kernel is built, all in one shot.
I think the hybrid approach NVidia and Dell are taking is the right idea. That infrastructure should be standardized (where the drivers are ALWAYS built during the install phase, or at least LINKED) And each driver would be versioned and attached to one kernel (perhaps call it a "profile"). You could use the same system across x86 and PPC and such, which would be ideal (esp for USB devices and stuff which should work everywhere without firmware, etc.)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
You should consider basing it on DKMS. This is a Dell sponsored project to help manage the multiple kernel/source vs. binary/multiple driver versions mess that can result.
You can turn a DKMS-ized driver package into an RPM or SRPM too. You could then just shunt it off to RPM or YUM or APT to handle keeping track of them at a package level, using the distro's built in package system. (It'd still require DKMS to be installed for RPM to call the scripts that work the magic)
But having a central repository (or just running a service to point to where drivers would be, and offer to do that other stuff if possible) can not be a bad thing.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
One of the major problems I've had in learning Linux is in configuration. While it isn't too bad to add a line to load a module when my kernel contains almost everything I need(except nvidia of course), I get squeamish about really dealing with it, because I don't know exactly what I have in the system, not down to the last part at least. Autodetection helps but there are different solutions and each one only goes so far.
I think a unified driver/configuration solution would be optimal for desktop users like me. I would love the "idealized scenario" that's presented on the main page.
The weak link, though, is that DoD can't help in the case where the hardware can't even get connected. But that's an issue for other projects to resolve...
--
I just spent the last 4 HOURS trying to find and isntall the correct 3d drivers for an SiS620 onboard chipset. It still doesn't work.
Anyone who says Linux is "too hard to install" has probably NEVER installed any version of Windows.
I've installed or reinstalled every version of Windows from 3.11 to XP, Slackware, Mandrake, Redhat, Fedora, and Debian, on a wide variety of hardware - 486's, Dual CPU PII's, etc. There is no doubt in my mind that on WINDOWS is generally the harder operating system to install, and on average supports less hardware out of the box. Period.
455fe10422ca29c4933f95052b792ab2
activex is completely different.. No one reviews the code for that, and bad activex controls dont even get their certificites revoked, and they just hand out their certs without checking.. This is completely different.. There will be lots of checks to ensure that the vendor certs actually belong to the vendor, and if one is found to be compromised, or their or files with worms, they will just be taken off the server to protect ppl.. This system is no less secure then apt-get, RPM's, or whatever, and just about everyone these days uses package management.. In the cases of stuff like RPM's, actually more secure (its especially more secure then services like RPMfind)
I had a similar idea a few years ago - like August 2000. It was slightly more elaborate though. Basically, it was create a linux distro closely integrated with the internet and other users of the distro. Their would reside a main database that maintained the state of each individual installed OS. The OS would evolve through the following mechanism. Expert users would be allowed to change the OS as they see fit and install drivers as optimally as possible. The beginner users would then be "bound" to a list of experts that have identical matching hardware and one of those experts' "driver profiles" (set of drivers installed and similar configuration) would be used. Same thing could apply for software installation (minus the ultimately required custom sections - hostname, etc.). Intermediate users could switch between expert and beginner as they saw fit to optimize the system. Of course credentials for experts would have to be established and in essence the evolution of the OS is tied directly to the non-malicious nature of the expert and the level of trust that individuals have in others. Changes could be checked by a central body to validate some changes.
Yes yes. I know the privacy issues of this could be overwhelming, but it would have been opt in.
Is this a feasible approach for you? Probably not - multiple distros to hit in your solution.
---- The geek shall inherit the Earth.
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
...and the drivers are installed automatically when the hardware is detected by most distributions. Why is this even posed as an issue? What's the fuss?
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
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!
This is true, I really can't see what the fuss is unless they are new users to linux and are trying to get their video card drivers installed. But hey, if the process is automated, then they're not going to learn anything. ;p
It's always hard to do the first time but once you do it, next time is a piece of cake.
Driver headache is the #1 reason while I stick to Windows. I have better things to do with my time than trying to get my OS working. A system that finds, download configure drivers would be a huge boost to Linux.
One thing that would be important though is having a GUI to also view basic parameters for the drivers (MAC address, ATA mode, etc.)
because those are the drivers which are already installed.. This handles even the drivers which aren't yet, and it can automatically install them
Whats ultimately needed is a standard ABI for the linux kernel - in this way drivers compiled for say, 2.4.8 would still work on 2.4.26.
Binary drivers (regardless of whether the source was available or not) could be distributed, and it would, in general, make it a lot easier for users to understand and manage the drivers present on their system.
However, this meets resistance because:
a) the linux kernel is rearchitected too often to preserve an ABI across more than 4 point-versions, it seems.
b) Kernel developers are unwary of giving manufacturers an easy way to ship binary drivers, thus making it easier for them to make the choice to withhold source. - Be aware it does not preclude this choice.
c) The idea is that all drivers are maintained as part of the kernel - breaking out driver development and support, with the associated organisational, management and security problems that poses is too big a risk to take - If all drivers were like NVidia drivers, for example, almost nothing could possibly work 'out of the box' in most Linux distributions because of licensing issues.
It should be remembered that Linux has not been built solely to provide a platform for people who are sick of Windows who want something that works exactly the same but for free, and as such, the goals of the kernel developers, and others associated with developing the core pieces of Linux, are often quite different to the average clueless user who 'just wants it to work'.
Personally, I think the right way to approach this is to maintain and promote a 'driver interfacing layer', which can be added by distros to the stock kernel, and provide a simple way to package and distribute binary drivers - similar in function to the NDISWrapper package for Windows network card drivers.
If binary Windows drivers can be wrapped and made to work with the kernel, surely this is a possibility for binary Linux drivers too.
Don't try and force a specific way of doing things on the kernel developers - if the idea has true technical merit, and offers real benefits to the user without compromising other aspects of the kernel, it will be adopted in time.
I gots ta ding a ding dang my dang a long ling long
I am new to linux. First time getting my video card drivers to work was a hassle, but eventually worked. Now I have upgraded my card, I am running into other problems. It is not easy. I am having to learn a whole new set of things than the first time. For me, this is OK - I WANT to learn. But not every one does want to be an OS-engineer, like most people who drive carsdo not want to be mechanics.
b3 4phr41d 0f my 4bov3-4v3r4g3 c0mpu73r kn0wI3dg3!
MadDwarf