Simplifying Linux Driver Installation
prostoalex writes "O'Reilly Network posts an update on Project Utopia that produced Hardware Abstraction Layer for Linux simplifying device changes. They also link to the Driver on Demand project on SourceForge, whose goal is to create a central database to enable Linux desktops download the drivers automatically when the user plugs in her new hardware device."
Next thing you know there won't be any reason anymore to stay with XP :)
StarTrek.org Free Webmail
What gets me is that this would be geared for either for distributions trying to enhance the user's "linux experience" or just to help newbies configure their devices "painlessly".
Meanwhile, anyone with an ATI card, for example, would still be just as dead in the water as before. Of course, I would be curious to see how well this turns out.
Join the TWIT army now!
StarTrek.org Free Webmail
would be great if i could simply #apt-get install sblive or #apt-cache search wintv not neccessarily wanting apt to do it but just something as easy as apt.
What do want to do then? Write assembly in your application to get to a device? Read out loud Hardware - Abstraction - Layer.
If getting drivers becomes that easy, I'll be considering atleast dual-booting. Drivers have always been something that have kept me away from Linux, but if they're as easy to find as plugging in a device, I'll switch in no time. Now, if only those manufacturers would put out some decent quality drivers, I wouldn't have much reason to stay on Windows.
What, like a kernel?
For what it's worth, I'm somewhat sympathetic to Linus. Look at what HAL did for/to Windows. Crappy driver/HAL implementations were responsible for a lot of Windows perceived and real stability problems. Now Microsoft likes to certify drivers (WHQL), so they only take the blame for their own damn bugs.
Basically, it's a double-edged sword. Convenience vs. Stability. Personally, I think if Linus is serious about the desktop there needs to be some compomise. Me, I just dumped Linux on the desktop for my sweet new OS X system. Viva la UNIX!
Just as soon as KDE and Gnome merge, and XP gets Final Cut Pro - never gonna happen.. too many egos in the way.
It is obvious that I as an corporate user, would refuse to install *anything* on my Linux system that has not gone through my distributor. After all, that's why I pay them. And pushing third-party binary modules in my running kernel would be a very quick way of nullifying their support agreements.
For the home user, things might well be different. But most people are running a distribution anyway, and would probably feel more comfortable getting drivers from them. That's how they get the security updates, so both the trust and the technical procedure is already in place. So if the distributors are to share the workload of getting these drivers, then a open project may be the right way -- but only for distributing the module source. Not many users would get drivers from here (Gentoo users come to mind).
The article has an ivory-tower stance to it and I think they solve the wrong problem. First we need to establish what the problem actually is. If the drivers are few and small then all drivers could be included in a typical distribution and updated with the rest of the system. Perhaps all that is needed is for distribution to update their kernel packages more often?
In the article the ABI was mentioned as the interface of the drivers to the kernel. Maybe it could be possible to create a higher level driver API on top of that? This API could then be ported to newer linux versions?
Dunno, but as a computer developer I'm having serious trouble setting up my computer for linux. I've seen a few full crashes already, which are probably due to flaky drivers. Not all my devices have been picked up automatically either. Currently my HP deskjet printer is not working, even though it should be supported by the kernel, and is USB, so it should be plug and play.
The way v4l and scanners are working on linux are great examples, I would like to see higher levels and even user space processes dedicated for this kind of hardware. Let the disk IO, memory etc. be left to the kernel, but try to lift all non-critical drivers to a higher level. A common API for that would look to me as a great idea.
As cute as that little pun is, PnP on WinNT 5.x Just Works(TM) the vast majority of the time and life is good. It's one area were Windows has a clear advantage over Linux and it's great to see the gap is finally starting to be closed.
Though I fear Linus' hardliner stance on ABI compatibility will hinder all this. Idealogical issues aside, from a user's standpoint a stable ABI for drivers is a significant plus for a desktop OS. I can only hope at some point the Linux kernel becomes stable enough for it to be considered.
That's only part of the issue. Lots of people don't want a KDE and Gnome merger because of philosophical differences on what a desktop should be like. I do, however, wish that on many forked or duplicated projects people would take just a second to think about who, besides themselves, a fork (or duplication) would actually benefit. When the forked or new version provides no significant new features, it's probably doing more harm than good.
GreyPoopon
--
Why is it I can write insightful comments but can't come up with a clever signature?
My wife installs all the new hardware on both our computers. This started when I got her a few gigs of memory, large HDs, better video card, etc. for birthdays, Xmas,etc. Rather than wait for me to have time to install the gadgetry, she RTFMed and took off the side panel and went to work.
I never have any trouble finding a present for her. BeastlyBuy, CircusCity, and CompUGH are all on the way home from work and allow last minute shopping.
I in turn have the simple pleasure of working six and seven days a week at a nontechnical job. The General Manager once asked me about a problem with a monitor. I went to the tool cart, returned with a 10lb. sledgehammer, and asked where it was. I have never been asked a computer question since.
what I'm scared of:
>unkown hardware device detected
>please wait while linux installs drivers for your new hardware
Is it too late to contribute to the openBSOD project...?
http://request-header.info
How does a Computer know that when I plug in a USB mouse that the computer knows it is a mouse, and what drivers to use with it?
It would be interesting to incorporate the drivers onto the pice of hardware. I mean what if insead of including a CD [that these days are filled with crap] with the hardware, that they just put a small flash memory onto the item, and stored the drivers there. Then as new drivers were avalable, the OS would update the flash mem with new drivers as they were avalable. This may raise the cost of the item, but I would rather have a item that I can use anywhere on any machine without having to search for drivers, or cary a cd around with me.
[blue] - The Ministry of Information approved this message...
Question for the Kernel coders, what perctage of drivers are reverse engineered?? 60-70%
The percentage would be near 0% if not 0%. Plenty of hardware manufacturers have released open or open-enough programming specifications for their hardware. Intel, AMD and National Semiconductor are a few examples.
For example, here are the programming specifications for my network card, a Netgear FA312 - DP83815 10 100 Mb s Integrated PCI Ethernet Media Access Controller and Physical Layer (MacPhyter)
Companies like NVidia and ATi are the exception, not the rule.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
I'm actually quite satisfied with the way linux handles devices and their drivers right now (this is stuff for nerds after all).
But I always wonder why there isn't a huge effort to build an abstract abstraction layer... it could look like this:
Every piece of hardware is equipped with a standardized storage chip, which contains detailed information about the purpose of the device and instructions on how to "talk" to it. Basically I'm looking for a way to enable any OS to figure out a driver on its own.
I know that many vendors (like nvidia) would never support such an idea, since they prefer to keep the source of their drivers secret. And I also doubt that it would be easy to write something like this for modern video cards. But something like this would be great for input devices or nics.
I don't read replies by ACs.
So, someone creates a stable as in abi/api HAL for linux. Then all sorts of manufaturers start releasing binary only drivers. Hypotheticly these are of good quality and we don't wind up with the windows BSOD type problems, this is very unlikely. We still get lots of binary only drivers with wierd licensing that limits distribution and what you can do with the hardware. Because drivers for stuff are avalible noone have interest in maintaining open drivers. Linux becomes as encombered as windows when you want to do anthing with it besides desktop PC. Forget having a cheep OS with lots of hardware support to build and sell your custom solutions with. Now since the hardware support will still probably be better and more complete on that M$ os all those little embeded things are gonna end up with winCE/pocketPc200X/XPembeded or whatever. This will kill the one market where Linux is begging to become the player to beat rather then the other option. If this takes off linux is gonna end up where it was five years ago on the desks of us geeks, rather then were it is now on half of the little and BIG network appliences out there even if it is unknow to the user. Once that happens we will lose lots of the corporte support and contributes to the kernel as well. Linus made the right call to not stabilize the ABI and force vendors to either make open drivers or at least have to put up with a wrapper.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
and see how stable it is. Much as I hate Microsoft (and I do), Windows XP is a stable operating system when it's running good quality, name brand software/hardware. At least the desktop is, no comment on server stuff. Where you run into problems is all the crappy 3rd party drivers and add ins that run in the background and make tons of changes to they system. If you start adding that stuff to Linux you'll have the same problems. On the other hand, Linux's openness makes adding this crap harder, and often unecessary...
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Already development is taking place in the 2.6 branch rather than a 2.7 one, as used to be the case. It is now up to the distros - as far as I've understood - to provide a stable kernel and update it with selected patches.
Couldn't a distro create and maintain a stable ABI for the kernel line it distributes? I'm assuming if one of the major distros does it, others will follow suit and will create a de-facto standard if lots of drivers spring up for it (perhaps with backing from major hardware vendors).
Would such a move significantly limit the applicability of patches with future work from the developers, to the ABI-stable version? My simplistic thinking is that the distro would leave out anything that breaks the ABI spanning a reasonable time-frame (e.g. 2 years). Only when something really cool happens, it would introduce a new "stable" ABI including any blocked functionality. This would suck if often cool new stuff can only be added by breaking the ABI and thus the distro gets left behind.
Could someone with the necessary technical knowledge enlighten us regarding the feasibility of such a thing? Is the ABI so constantly morphing?
To err is human, but to forgive is beyond the scope of the Operating System...
I don't know why people are marking the original poster flamebait. Even I am skeptical of drivers on demand. Last time I installed linux with a HBA with storage area network, it was the most work I have ever seen.
.o using the source .o as a module
1.) Download the driver
2.) rpmbuild kernel source
3.) update kernel to new kernel rpm to be compatible with driver
4.) compile the
5.) insert
6.) modify lilo / grub
7.) reboot and pray
Now I don't know about you, but Hardware Abstraction layers probably work for some video game control pad driver. Unfortunately any real device needs serious attention in linux land.
So? You're asking people who are doing things *in their spare time* to give you a deadline for fixing something that may be needed by exactly one person (you).
If you want help feel free ask what the current state of the driver is, but don't expect anyone to do anything about it unless you're prepared to help, or give them money.
btw. MS are exactly the same. Try asking them when 'feature x' will work. They'll want money before you'll get a sensible answer about it (in that case you don't even have the option of doing it yourself).
I was actually just thinking about this sort of thing the other day ... with a Gentoo slant of course.
I'd just set up hotplug, which I'm now using for a number of reasons, my Alcatel USB ADSL modem, Canon Digital Camera, USB MP3 player, etc. It dawned on me that these devices are supposed to have unique identifer codes, and that it would be great if *someone* would keep a centralised database of codes against software / config changes. Then I thought a device being added could trigger an 'emerge' process on my Gentoo box and an 'etc-update' to merge in the config file changes.
Of course there are a lot of missing pieces in my ideas. But anyway, I agree with the general idea. Good on 'em!
"Hardware Abstraction Layer cos we all know how well that worked in Windows NT "
Yeah, all my hardware works.
"Derp de derp."
what I'm waiting for is linux programs to include all the headers and such that they need to install. Package developers need to do more like Gentoo so all required files for any given program are downloaded automatically or included with the program... until then Linux will never make it main stream onto desktops.
.DLL's"... don't you think that user is going to be a bit stumped, then become angery because they have to hunt on the internet for stuff they have absolutely NO CLUE about??
Take the average windows person. If they install a program, and that program says "This requires this other 'program' to run, and also needs these
I think this would be great.
Once I had the experience of trying to install Linux on my Dad's machine, and Linux was up and running, and all that was left is to get the computer online using the USB wireless dongle.
But when I googled around looking for drivers, apparently that dongle has 3 revisions, each with totally different drivers. Still, I wasn't discouraged and try then all in turn!
But somehow it doesn't work!
Then I found a thread in a forum somewhere which says I have to look at the stuff that is displayed during bootup, copy down something, and type a command. I did that, still doesn't work.
Then I did the same for each of the other 2 drivers in turn, ditto.
End up, defeated, I reinstalled Windoze on that machine. That so sucks man. Cos months later I got a phone call from my folks asking me how to get rid of those pr0n popups and stuff.
If only those drivers worked back then.
Currently it is really quite a challenge getting some bits of hardware to work right on linux. In fact, it is not currently, it has always been an issue. Once this is improved, I don't see why Linux won't fly.
2005 is the year of Linux on the desktop (and if John Titor is right, the end of US of A as we know it)
Online backup with Mozy, sounds like Ozzie, but more!
Run hardware drivers in userspace with binary compability to major kernel (or abstraction layer) versions. This will allow manufacturers to make binary-only drivers with no GPL restrictions that will not crash the kernel and the OS even if they are full of bugs.
Do this before Longhorn comes out. If I had enough knowledge I'd do it myself.
Easy solution:
fork();
Why?
As much as I like and respect Linus and his decisions, it seems the kernel has become an "entity" of sorts. Times are changing and certain problems will arise when one uses time-honored policies instead of progressive thinking (not to say Linus is not a progressive thinker, on the contrary...)
A fork, based on a recent stable release, that is kept current by applying patches and fixes while preserving the existing driver ABI. Redhat does this when it back-ports features from newer kernels into its production kernels. Basically, let Linus and co. write the bleeding-edge kernels while said fork makes catastrophic changes to the driver ABI every two years or so instead of every three weeks.
I may be wrong in my thinking, but a fork wouldn't hurt anything in my opinion. This wouldn't be a fork due to policy decisions e.g. FreeBSD + OpenBSD or XFree86 + Xorg, but a fork of necessity to provide hardware manufacturers a stable interface for supporting linux, therefore allowing them to focus more on improving their drivers' performance than on keeping up with each kernel release. Then, they can release binary drivers and rest assured that they will work for some period of time.
Just my $0.02
While this is a bit off topic, its relevant.
Don't misunderstand me, as I have the up most respect for the guy, but after reading some of his comments about vendors approaching him about drivers, and his refusal to even discuss a HAL layer ( which IS the right way to, even if he doesnt want to deal with it ), I can see that the arrogance of the Linux community is starting to rub off. ( actually, if the article is correct, it may have actually reduced my respect for him as he's acting more like a child.. ).
Yes its his kernel and he can do with what he pleases, I understand this. But I also understand he would like it to continue to succeed, and being an ass wont advance that cause a bit. Look where it gets Theo..
I do expect to be modded down for this of course, but I see the 'attitude' as the #2 problem with Linux in general. ( #1 being the convoluted un-structured nature in general, which effects things in a detrimental way a lot more then many want to admit. ).
Until people get off their high horse and start acting professional instead of condescending, things here will have just about topped out, and the market share will be stagnant.
---- Booth was a patriot ----
Its not borrowing ideas at all... Alot of things MS does are just simple steps, but the trick is they generally implement them in the poor and easy way, instead of the proper way. The truth is that Linux has had the equivilent of Microsofts Plug and play system for a very long time. All their system is, is a bunch of modules, we do exactly the same thing, the difference is that since people dont notice it because distro's have most fo the drivers included, so you dont notice them existing.
Also, Microsoft charges for getting drivers digitally signed to get on their database, and I severely doubt many are of decent quality (I know the nvidia ones they have are useless). Its easy to code somethign when you charge for addition to the database, because its just like any other database.. But to do full, dynamic driver management where you can get drivers that dont even exist on your system, thats what MS is NOT able to do. In fact, because they put poor drivers in their database, I'd say you get driver upgrade warnings which wipe out your already working drivers and replace them with poor copies.. Evidence of poor design.
Either way. I dont believe either HAL or Driver on demand is really a clone, but then again, I am the author of Driver on Demand, and I'm biased. The focus in recent times for driver on demand has been to create a driver search engine anyway first.
What is needed is telling me what applications I could use with the devices. Many Linux applications use libusb and don't need a driver (in fact you can't use libusb against an interface that a driver has claimed).
So if I plug in a cell phone, I should be told about BitPim for CDMA phones, and whatever is used for GSM phones. Whatever the scanner app is should appear for scanners. Epson printers should cause me to be told about mtink etc.
And all this can be done outside the kernel.
Although gentoo specific you still get the gist to get this to work on other distros.
http://forums.gentoo.org/viewtopic.php?t=217412/
I suggest you look up "Context Switching", then get back with me what a good idea user space drivers would be.
GDI used to be in user space (WIndows if you are oblivious), but it was moved to kernel space because thats where that stuff belongs.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Hell, I had trouble with a Lexar JumpDrive (a USB solid-state storage device) today on Windows XP. Had the thing in my pocket, at my parents' house, and they wanted me to touch up a photo but seemed reluctant for me to take the original. OK, no problem. So I sat down at their computer, fired up their image-editing software, and set the scanner to scan at 1200dpi, grayscale. Then:
/dev/sda1. /etc/fstab.
1. I plugged in the Lexar JumpDrive.
2. I went to My Computer, and was delighted to learn that the JumpDrive hadn't been detected.
3. Unplugged the Lexar JumpDrive.
4. Went into the Control Panel and Device Profiles, only to find that some sort of obscure-sounding USB device was misconfigured. Since they have a largely from-the-factory-setup Dell, I thought that had to be my hardware. Let Windows search for the drivers; it failed.
5. Plugged in the Lexar JumpDrive.
6. Unplugged the Lexar JumpDrive.
7. Plugged in the Lexar JumpDrive.
8. Restarted the XP machine, because my parents said they'd had the machine "acting squirly for a while."
9. Waited for restart, opened My Computer.
10. Unplugged the Lexar JumpDrive.
11. Went to the Lexar website looking for 3rd-party drivers. None available or needed.
12. Plugged in the Lexar JumpDrive.
13. Went to the Dell website. Waited for an eternity for the site to load.
14. Unplugged the Lexar JumpDrive to get a specific model number, and typed it into a Search box.
15. Plugged in the Lexar JumpDrive.
16. Raise an eyebrow since the device was autodetected and properly configured without human intervention.
Contrast this with my experience with a relatively user-unfriendly Linux install:
1. Plug in the Lexar JumpDrive.
2. Do some command-line magick to find that it's set up as
3. Edit
4. Set up a KDE device icon.
5. Click on the icon. Note: from now on, clicking on the icon mounts the device and opens a Konqueror window, while right-clicking gives me an unmount option.
Or, on Mac OS X:
1. Plug in the Lexar JumpDrive.
Stating on Slashdot that I like cheese since 1997.
The real problem isn't the kernels and the device support therein, rather, its the devices. Really, how many different ways do you need to send data to a printer, or a disk, or get images off a digital camera or webcam, or sound to and from a soundcard, or a 3d command pipeline to a vid card ? The plethora of different device interfaces for substantially identical devices is the real problem.
Instead, I think there should be a (small set of) _device_ standards.
That is, something like a architecture standard: a standard category of devices which the manufacturers will agree to provide standard interfaces for
Combine that with a standard, architecture independent way of allowing devices to carry their own drivers. Perhaps something like a fast Forth like bytecode interpreter.
Maybe not the best approach, but a lot better than what we have now.
-- Pat
The biggest problem with communication is the illusion that it has occurred
Do you get that little pop up about "not enough virtual memory, increasing swap file size" or something to that effect? Once you're past the minimum virtual memory size, Windows does something to increase the swap file size.
I haven't properly tested or researched this, so YMMV, but several times now, that process has slowed my PC to a crawl - during AND after the increase.
Though, that shouldn't have anything to do with a disk defrag...
then exercise your freedom of choice, and stop using Linux.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
You could, for example, have a graphics library that was setuid root, to allow non-root users to access the graphics hardware through a rectricted API.
This gives you the advantages of a shared library (no context switching, driver is distributed and managed separately from the kernel) without the disadvantages (processes must run as root because the library requires root privileges to access the hardware). There's only one disadvantage that I can think of: all arguments must be passed on the stack because the caller and the protected library have different data segments. If the protected library can be given access to the caller's data segment as well as its own, that problem disappears - the 386 supports six segments so that should be possible in principle. But passing arguments on the stack might be a better solution because it would allow arbitrary nesting of protected libraries.
I guess you never heard about yum. Or apt. Or urpmi...
This package dep sorting out thing is not xxx distro specific - you can get it on many many distros. Sure, some don't, but gentoo, debian, redhat/fedora, SuSE and mandrake do.
im in ur
Can there be binary only drivers or will the GPL interfere?
There can be binary only drivers with no GPL problems. The steps you must take to perform this:
1. Publish an API which is independent of any Linux kernel internals (and is therefore not a derivitive of the kernel and can freely be released under a non GPL license)
2. Make a GPL implementation of it and integrate it into the kernel
3. Make a non-GPL implementation of it. It doesn't need to be fully functional, but while we're at it, it might be useful to have a user space test harness for driver development. This can be BSD (or equivalent) licensed.
4. Write binary drivers.
5. ???
6. Profit
8. Restarted the XP machine, because my parents said they'd had the machine "acting squirly for a while."
Couldn't have possibly been because there was a problem on the machine in the first place...especially as you mentioned a USB configurations problem.
Conor "You're not married,you haven't got a girlfriend and you've never seen Star Trek? Good Lord!" - Patrick Stewart
Segfault anyone?
Wow...after countless revisions and a decade of work , programs and drivers are still a nightmare to install on Linux. Dependency this, dependency that, oops wrong GCC version and of course "Oh shit I updated the kernel so I have to recompile my graphics card drivers again."
Can't remember the last time I had to do anymore than a single mouseclick to start installing a program or drivers in Windows.
Conor "You're not married,you haven't got a girlfriend and you've never seen Star Trek? Good Lord!" - Patrick Stewart
I have installed Linux several times over the last few years, on practically all of my hardware configurations.
But none of the times has it been plug'n play. Often drivers that worked in one version didn't work on the next. So after the having a system where the graphics worked, It wouldn't on the next, because that driver had been left out. But now the sound would work. And so on.
I don't remember ever having a painless installation. Untill I do, I won't bother with Linux as my workstation. It will keep running on a simple server with old and safe hardware where the drivers will allways work.
Windows is more than stable enough for my desktop, and I can easily earn the price of XP Pro in the time I save not fiddling with drivers.
The quality of the desktop really isn't the main problem for my Linux usage. I don't find it worse, just different. But using too much time installing the OS is a problem.
I don't do it as a hobby. The OS is a tool, and so has to be efficient.
Max M - IT's Mad Science
First thing I did when I saw this article was shudder. Why? The majority of problems I've ever had with XP have been with the shoddy implementation of a Hardware Abstraction Layer, and the associated problems that an 'all your eggs in one basket' approach can bring you. You can see for yourself: Just Google for 'Missing Hal.DLL' and you'll see just how easy it is for this file to be corrupted / disappear etc etc.
I don't think the above post deserved to be flamebait - he made a valid point, just somewhat uneloquently.
Sunday you're Thinking Different, Monday you're a huge tool, paying too much and waiting to think like everyone else.
And for balance, contrast it with the way it works on a properly-maintained linux machine:
1. Plug in USB mass storage device.
it works.
PHP is the solution of choice for relaying mysql errors to web users.