Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Linux

Thoughts on Automating Driver Installs for Linux? 129

Posted by Cliff from the for-better-or-for-worse dept.
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."
This discussion has been archived. No new comments can be posted.

Thoughts on Automating Driver Installs for Linux? More

Thoughts on Automating Driver Installs for Linux?

Comments Filter:

  • Huge boost for me (Score:5, Interesting)

    by NanoGator ( 522640 ) on Friday May 14, 2004 @02:54PM (#9154898) Homepage Journal
    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.
    • 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.
      • Yep. I'm aware of Linux's advantage here. I do like that it's more 'out of the box' friendly than Windows in some cases. At the same time, though, I've had much better luck finding unsupported (out of the box I mean) stuff for Windows than I have with Linux. I hated that defeating "Damn, I just can't use it" feeling I had with Linux. Bear in mind, most of my attempts have been with laptops than with desktops. Painful painful painful. I do try again every year or so, though.
        • Yeah, I imagine in laptops this is still a painful experience. Hell they don't even work with windows versions they weren't shipped with half the time.

          For instance we just had a customer with a toshiba laptop we sold him last year. It shipped with XP but he wanted 2000 (per his corporate requirements) so we loaded it and all worked for a year. And then recently they did a windows update and bam, thing won't boot in normal or safe. Repair install does no good (and neither did 2 days of everything else).

          • Have you consulted with your local lug? One of the most annoying things I've seen has been that linux driver modules often group the past 5yrs of functionally similar hardware under a module named after a 10yr old piece of hardware. Alot of the time the guru's at your local lug will know where the driver you need is hidden.

            what would really be interesting is a site or chart that attemps to link the hardware to the driver name. I mean how many cards/nics does a tulip driver support? And most of the stuff

      • I've got a scanner which is 5 years old, and still perfectly good. UMAX isn't interested in writing drivers for it anymore, so the only OSs I can use it with are:

        Mac OS 8
        Windows 98
        Linux/FreeBSD/OpenBSD

        Free/Oss software emerges as a great way to avoid the planned obsolescence generated by the windows 2 year update cycle.
        • I have a Nikon Slide Scanner that only works with the oldest version of Windows 95, or Windows 3.1. I guess there's a SANE driver that I should fiddle around with sometime, too. But it seems to be an old unmaintained piece of code. Still would be worth putting on a system with an old version of Linux if it made the Slide Scanner go well, though. But I am starting to need an 8-port KVM switch, my 4-wide switch isn't cutting it anymore. Dual-boot is against my religion.

        • Speaking of UMAX and drivers. What the hell is their problem? I have a UMAX 1200S scanner, that I've lost my driver CD for. So I naively head off to their web page, and try to download the driver [umax.com], only to find:
          • This software IS NOT downloadable.
            Available on CD-ROM only. This product is non-returnable and non-refundable

          But for some reason, the German page [www.umax.de] has the same damn driver available for download for free.

          Meanwhile SANE [rauch-domain.de] for Linux supports it out of the box.

    • I also would like to automate the driver installation. I don't want to look to tens of pages just to find a suitable modem driver or something else. By automating driver installations, maybe manufacturers put drivers to P2P networks so that everyone can find suitable drivers. Although I think automation shouldn't be a must, there should be a disabling option.
      • I have actually thought about hooking this up with a P2P like system for large drivers, but if I end up doing that, its way in the future.. Such a system would probably use gnutella or something like that, but at this time, I think its better the manufacturers handle the entire traffic, because even if we P2P'ed the drivers, they probably still wouldn't bother dropping prices :(
        • You should consider basing it on DKMS [dell.com]. 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
    • How to install linux drivers in a few easy steps.

      First, you must have the source code to your kernel, it is located in /usr/src/linux.
      Download the new driver in source code form and mix it in with the linux source code. You either do this via the patch command or by just untar/zipping it on top of the source.
      Next go to the source directory and type make menuconfig. You will get a nice menu with all the kernel configuration options. Find your driver, it will be in its logical place. Network card drivers in
      • Download the new driver in source code form and mix it in with the linux source code

        What driver is that? I've been using Linux for a long time, and I've never heard of such craziness. Why wouldn't they just allow you to specify a location to find the kernel headers, and build outside the kernel source tree?
      • If you are installing a binary driver, like nvidias or anything else out of the ordinary it comes with its own instructions. If not, screw it, it's not worth it.

        ja, ja, were it so that we could all ride beside you on ze high horse, sire!

  • Fear, Uncertainty, and Doubt (Score:5, Insightful)

    by n1ywb ( 555767 ) on Friday May 14, 2004 @02:55PM (#9154916) Homepage Journal
    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.
  • 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.

    • Re:You should ask yourself... (Score:5, Insightful)

      by n1ywb ( 555767 ) on Friday May 14, 2004 @03:00PM (#9154984) Homepage Journal
      Security and ease-of-configuration are NOT mutually exclusive. In fact, the simpler the configuration is, the less likely it is for a user to make a configuration mistake that will lead to a security hole.
      • I agree that they are not mutually exclusive.

        You have the distro come with a pgp key, the drivers are signed against that, and put on some website. The url of that website is also put in the tools. The tools grab the ID's of your hardware, grab the ID's of the supported hardware on the remote site, compare them, and download the drivers where they match.

        You check the signed drivers, and install.

        Where are the security flaws in that extremely easy and automated system?

        • 1. you get a hacked package.
          2. the package is signed with evilGuy's key
          3. evilGuy changes the url in the package to be his site that you can verify the package against.
          4. you install the hacked package.
          • How exactly do you do step 2?
            And if it's easy, why hasn't anyone managed to get any of the 800 or so debian developers private keys and signed a bad package.

            • 2.a evil guy generates his own key to sign with. read the rest of the steps above.
              • That is always a threat. Any newb looking at these packages won't have a flipping clue on if a package is from a good site, signature or not! It is either them searching for the internet for driver X then who knows what they'll get back, or else they get a signed drivier that has a better chance of success. Ideally, if you approve the root cert for linuxdriversondemand.org or whatever site, any driver from that site should be able to get certified against that site's keys. If you don't know where the driver
                • We were talking about the program getting them automatically.
                  There is no threat of someone just creating a key and signing against it. The program will check the signature and know it's not trusted.

                  • if the program is hacked, you can't trust what it will do. you assume security to prove that this situation is secure.
                    • The program is in the distribution. I keep saying this.
                      For something like this, it's going to be extremely difficult to get a backdoor in.
                      Take debian for example. Something like this is going to have it's source code checked over before it's signed. It's going to be very difficult to get a hacked packaged signed by a debian developer.

                      So far, I don't think any cracked package has ever managed to make it into debian.

                    • And I keep saying over and over: if you get your package or distribution or whatever from an untrusted source, it can have signatures out the wazzu, but that doesn't make it safe.

                      no cracked package has made it into debian... but by the time debian discovered that their distribution server was hacked, you can bet a few people had already installed potentially compromised packages that were supposed to be safe.

                      This type of thing happened about 3 times last year to high profile software sites (debian, openss
                    • people can break into debian servers all they want. They still can't put up their own package that will be downloaded and installed.
                      The debian developers are extremely anal about security.

                      I'm not talking about whether is it theoritcally possible to crack the system - of course it is.
                      But realistically, I think it's going to be very difficult for someone to.

                      Theoritically you could put a back door in the MS Windows's source code. But it's going to be damn difficult to do so.
                    • wow... you are welcome for the help.

                      you went from asking the question Where are the security flaws in that extremely easy and automated system? to defending debian's and windows' security. you have lost your focus.

                      if you ask a question... be happy you got an answer, and try to listen to it. instead you have dragged this puppy out for several days and probably are none the wiser for it.

                      welcome to my foes list.

                    • Perhaps I should have phrased it better, and said "Where are the practical security flaws in that?".

                      I compared it to windows security because what you would need to do is very similiar. In both cases you would have to somehow crack into the cvs server, modify it without being noticed, and then that code being pulled downstream into a package.

                      Yes it could be done, but there's no weakness in this system that isn't in the system already. It's no less secure than it is as the moment.

                      Perhaps I should have s
              • I specifically said that the the signature would be checked against the public key that would come as part of the distro.
                • specifically, if I give you a hacked package... you don't get to decide what I do with it. sure it checks against whatever key.... but it also hacks you up. you can only trust automated systems if you can manualy verify them. catch 22.
    • Windows is ubiquitous because it's easy.

      Are you sure it's not the other way around?

      • You bring up a good point there. Windows works pretty much the same on all computers its installed on. Linux (GNU stuff included, not just the kernel) varies from distribution to distribution (e.g. Debian is different from Slackware is different from [fill in the blank]) in the way the configuration files are stored, the startup scripts are run, etc.

        If I want to configure something on my Windows machines (Win98, WinXP) I know I can go to the control panel and do it there using basically the same interfa

        • That's true; there's a lot of diversity between Linux distributions. It's well worth keeping that in mind.

          I meant something else, however. The more people who run Linux, the more motivation hardware developers will have to write or to help to write drivers. Things are much better now than they were five years ago. I think this will continue.

      • Maybe. Personally, I think Windows is easy because it has low self-esteem and a bad coke habit.

  • Doesn't kudzu [redhat.com] do something to that effect?
    • Kudzu only detects and install driver modules found on the computer, as far as I know.

      From the frontpage of http://driverondemand.sourceforge.net/

      Overview of Driver On Demand

      Driver on demand is an attempt to ease driver installations in linux. Basically, what happens is that a user installs a PCI, PCMCIA, or USB (not implemented yet) device, if a driver isn't found, the client connects to a CGI server, to check if the device is known, if it isn't, then the driver lookup fails and the user is no worse off

    • My thoughts (Score:3, Interesting)

      by 0x0d0a ( 568518 )
      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
  • 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.

  • yes, do it. (Score:4, Insightful)

    by Miriku chan ( 168612 ) on Friday May 14, 2004 @03:00PM (#9154990) Homepage
    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 =)

  • cooool (Score:4, Insightful)

    by drfrog ( 145882 ) on Friday May 14, 2004 @03:02PM (#9155015) Homepage
    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

  • Sounds like a fantastic idea (Score:5, Interesting)

    by FattMattP ( 86246 ) on Friday May 14, 2004 @03:05PM (#9155068) Homepage
    This sounds like a great idea. The majority of computer users want stuff to just work. Being able to plug something in and then tell the system to get and install the driver for your new hardware automatically is something I've always wanted.
    there has been some strong negative feedback, including comments such as that it will kill open source drivers in Linux
    You don't address any of these objections on your web page, at least that I could tell. It's hard to comment on this one since I can't see the original objection nor your response.
    a system which employs digital signatures could never be secure enough to stop worms
    I don't see how this system is much different than using apt-get under debian. People trust Debian's repository and its mirrors to install software all the time. It's not that much more of a stretch to trust a system like that to install drivers. Before you draw a distinction between drivers and packages, keep in mind that the install process in both instances is going to require root. If something nefarious is going to be installed it could happen via either process.
    • The difference is that Debian is a trusted source. Anyone can get a certificate. The point being that being "trusted" and "accountable" are 2 different things. You'd have to bring a lawsuit or otherwise litigate against someone that caused damage to your install. The fact that you can track the person makes it easier to seek damages, however, it doesn't make them a "trusted" source by any stretch.

  • 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 f
    • I don't think the community needs two competing sources for drivers. In fact, that would be horrible. They just want one that does it well, not two that are trying to compete.

      CDDB is one thing, but it's not tied into someone's OS, and stops their computer booting if it mis-recognises a celine dion CD. :)

  • 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?

  • go for it (Score:2, Insightful)

    by rogabean ( 741411 )
    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
  • 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.
    • Linux should first get a marketshare large enough to warrant that approach.

      Hardware mfrs create hardware. They then spend 95% of their time working on drivers that run on 95% of desktop computers (windows). Why should they have to spend more than 5% of their time to support 5% of users?

      When linux is large enough, and on enough machines, hardware mfrs will sit up and take notice. After all, if your latest graphics card doesn't work on linux, and linux is 50% of the market, they'll make linux drivers.

  • 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 cha
    • 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.

      It would be more accurate to say that it works because Microsoft and Apple had the foresight to define a stable ABI for drivers. The Linux kernel developers refuse to do this.
      • 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 t
    • Remember, pleasing everyone is almost never the goal.

      That said, if the driver is available as a module for a 2.4 kernel, but the user has a 2.2 kernel, the process could be handled in one of two ways.

      Feedback to the driver writer that lets them know that there is a (or several) users who could use the driver compiled for the 2.2 kernel, and would they please compile such.

      Ask the user if they would like to contribute to a bounty fund for that device, such that when someone sees the available bounty, they

  • Keep working. (Score:3, Interesting)

    by NotoriousQ ( 457789 ) on Friday May 14, 2004 @03:23PM (#9155308) Homepage
    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?

  • Network Card Drivers. (Score:4, Funny)

    by et289807 ( 311853 ) on Friday May 14, 2004 @03:26PM (#9155361) Homepage
    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
    • Thats a obvious drawback of the system :P Network cards very rarely have problems though (in fact, never seen anyone object that their's doesn't work).. Wireless networks though very commonly have problems.. I didn't think that was that much of a concern because users could just use a hardwired network to install the drivers and get them running.
    • > 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

      Huh? Obviously you'll put in a distribution (or independent) CD that contains a large set of drivers.

  • You can't please everybody (Score:4, Insightful)

    by Doug Dante ( 22218 ) on Friday May 14, 2004 @03:44PM (#9155603)
    there has been some strong negative feedback

    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.

  • I'm of two minds on this one (Score:3, Insightful)

    by ignorant_newbie ( 104175 ) on Friday May 14, 2004 @03:48PM (#9155653) Homepage
    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.
    • Most of the 'stupid' users out there are simply lazy, and feel that if they whine long enough the computer will do for them

      And the obvious question to ask is why the hell doesn't it? It's perfectly capable of doing so after all.

      It is ridiculous to require a user to do things that can be easily automated. That includes compiling a kernel on a system where regular kernel upgrades are a requirement.

  • Intel Drivers (Score:5, Insightful)

    by Oriumpor ( 446718 ) on Friday May 14, 2004 @03:49PM (#9155657) Homepage Journal
    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.
    • The fear is that this system will somehow take away the ability to compile one's own drivers. Whether or not you think that this could happen, you must respect this sentiment.

      On the issue of drivers, this is related with reverse engineering, one of the hacker qualities on which the open source movement has been based. Alienating driver hacks would greatly undermine Linux.
      • "The fear is that this system will somehow take away the ability to compile one's own drivers. Whether or not you think that this could happen, you must respect this sentiment."

        Why? This is an open source project, for an open system. If it were to do so then we'd simply change it. If the original maintainer goes in a different direction we just fork it and declare a new official release.
        • Notice that I'm not talking about anything logical. Fear isn't logical. It's a feeling. I specifically used such words as "fear" and "sentiment" to indicate as such.

          Just because it can't happen doesn't mean that people won't be afraid that it will.
          • "Just because it can't happen doesn't mean that people won't be afraid that it will."

            I'm not saying people won't be afraid it will. I'm saying that since it cannot happen there is no reason to RESPECT the sentiment, only to dispel it.

  • Bring it on! (Score:3, Insightful)

    by nvrrobx ( 71970 ) on Friday May 14, 2004 @04:14PM (#9156076) Homepage
    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 driv

  • How would this work? (Score:3, Interesting)

    by ratboy666 ( 104074 ) <fred_weigel@[ ]mail.com ['hot' in gap]> on Friday May 14, 2004 @05:02PM (#9156702) Journal
    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

  • No thanks (Score:2, Insightful)

    by smurf975 ( 632127 )
    automatically locate and install
    Sounds a lot like Internet Explorer and Active X and one of the biggest reasons why I use firefox.

    Looks like a big potential security risk to me. And the same reason why it's disabled on future Windows OS's.
    • "Automatically locate and install" doesn't have to mean "without the user's permission". No reason you can't have a box pop up once in a great while, "hey, I've found an updated driver for your Blah Brand sound card, do you want me to install it? []Yes []No, don't ask again []Not right now, ask later"
      • No reason you can't have a box pop up once in a great while, "hey, I've found an updated driver for your Blah Brand sound card, do you want me to install it? []Yes []No, don't ask again []Not right now, ask later"

        and there is also no reason why you could not have a SECOND boox that pops up and asks for the root password (if your installing it system wide). This is something I like with OSX, when something is going ot be installed system wide it pops up and asks for a root password. theres a lot of app's
    • 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 a
    • You're confusing unsigned, web-based applications with "windows update". Windows update gets drivers solely from microsoft, and are digitally signed. A system that works very well, funnily enough.

      I love it when people have opinions differing from me, I just hate it when those opinions are based on nothing.

  • 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
  • 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 lac
    • kudzu is a bit different.. That just looks at a list of installed devices and finds an appropriate driver (only installed ones).. Mine looks at a list of installed devices, and if no driver is found, it goes online and downloads one.. The lists of devices can contain many drivers on the db, and so if a driver doesn't work in the list, it tries the next.. Think of mine as kudzu/hotplug with an unlimited amount of drivers for every device out (included ones not installed yet).. Kudzu just uses installed on
  • 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 lik
  • AFAIK, RH/Fedora plan to use HAL [freedesktop.org] which communicates using D-BUS [freedesktop.org] to extend the plug-n-play functionality already provided by Kudzu. Leveraging these projects will probably aid acceptance of DoD.

    --

  • 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,
    • 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.

      Err.. if it wasn't obvious from the rant, I was trying to install them under Win2k. I found the drivers for the exact motherboard from the manufacturers site in .tw but they just don't seem to work.

      It's late. I'm tired and frustrated, but for fucks sake will you all get OFF this "Linux is too hard to install" shit. In my far-from-insignificant experience, Windows is much ha
    • I've installed plenty of both, and windows is far easier. Network-based automatic installation? You don't even have to touch the keyboard.

      Also, windows has a "sysprep" utility which you can use before ghosting the hard disk. Install your windows (including office suite, firewall, whatever), run sysprep, then take an image off the computer. I single-handedly installed windows on 10 PCs one afternoon. It only took me about an hour, and no CDs.

  • 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
  • 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 o
  • ...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?

  • Go for it! Something has to give (Score:3, Insightful)

    by Voivod ( 27332 ) <cryptic.gmail@com> on Saturday May 15, 2004 @10:17PM (#9164553)
    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!
  • 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.)
  • 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 de
    • 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.

      You don't see a lot of standard APIs (let alone ABIs) in the Open Source world because programming has to be enjoyable to attract programmers and let's face it, coding around standards generally isn't enjoyable. Not to mention the fact that the kernel is notorious for doing huge overhauls to support greater scalability, etc. The kernel is a great example of a project th

Slashdot Top Deals

"Ninety percent of baseball is half mental." -- Yogi Berra

Close