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."

Comments

Tough to stay with XP

[JorDan Clock]

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.

Re:Tough to stay with XP

[Anonymous Coward]

Plug famous brand USB storage devices into a Fedora Core or recent Red Hat and it will appear as a user-owned mountable device immediately. No reading system logs. No trying to understand mount flags, it Just Works(TM)

It would work with the off-brand ones if they only agreed any kind of rhyme or reason to the USB device name strings... and in FC3 it'll probably just work anyway thanks to some extra magic.

I hear the same complaint with video cards, USB MIDI, you name it. And I'm mystified. I bought a Radeon 9200SE for a home machine, turned it back on, FC2 auto-detected it and everything just worked. Where's the "complicated procedure" and the "hunting for clues on Usenet" ? I plugged the USB headphones from a nearby iMac in, and they appeared immediately as an output option in my Audio player app. No I didn't have to "configure" anything, or "mess around with the command line". When you plug a Playstation 2 keyboard into my USB capable FC2 laptop it just works, as you would expect.

So put the "Linux will never have working plug and play" complaints in the same category as "Linux will never be easy to install" complaints. Nothing is perfect, but as usual Linux (at least outside roll-your-own distros for the nerds) isn't any worse than any other system.

A hardware abstraction layer?

[ogl_codemonkey]

What, like a kernel?

Won't happen anytime soon...

[AntiGenX]

As the article points out Linus is vehemently against making the kernel API/ABI's stable. On the one hand this allows them to add knew stuff all the damn time, but it breaks drivers. In my opinion this is what's holding linux back. It contributes to Linux having crappy hardware support. (Yes it has crappy hardware support people!) Sure it supports LOTS of devices, but a lot of them require some voodoo to make them work. That's all fine and well for people like me, but average users don't want to dick around with modprobe.conf. I'm sure a lot of vendors would be more willing to put out their own drivers if they didn't think they'd have retest/recode every kernel release

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!

Re:Wating for this

[GreyPoopon]

too many egos in the way.

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.

Re:Neat!

[MBCook]

I agree. Windows has gotten MUCH better over the years. But I have noticed one thing that consistantly forces me to reboot my computer: disk activity. I can run my computer for weeks doing normal things and have no problem (XP Pro, 900mhz, 512mb for the record).

But disk activity kills the machine. It's a laptop, so disk access is a little slow, but if I work with large files (open, close, save, copy, etc) especiallyi zip/rar files (lots of file operations) the system begins to slow to a crawl. Now I understand that the disk activity can slow the computer, but after all the transfers are complete, the computer is still slow. Opening IE goes from near instant (before all that) to seconds of the computer chugging. After that if I close IE and open it again, it still has to chug to open it (so it's not some simple cache thing). The computer is just slow as heck to respond to anything untill I reboot it. At that point it's fine! The same happens after defragging my disk if it's bad (and requires lots of operations to fix it).

I swear, it's like there is some internal limit in Windows when after a certain number of file operations, the system purposly slows down. Frankly I wouldn't be suprised if a little box popped up saying "You are doing too much heavy disk activity. Please buy Windows Server .Net 2003 for better performance" or something.

Never happens with Linux on the same machine, so it has to be something Windows is doing. Windows has gotten much MUCH better from the 3.1/95 days, but it still has some problems.

Re:Could distros do this anyway?

[The Vulture]

Maintaining a stable ABI is pretty darned difficult without proper planning. Typically two of the things that pose difficulty are function calls (the API), and the internal data structures (new variables added or removed, which breaks binary compatibility).

Say you have a function, foo, and it takes three integer arguments. So, here's your theoretical function:

int foo (int a, int b, int c)
{
int d = 42;
... rest of foo...
}

Now, say all of a sudden, you decide that the variable d in foo should be passed in (maybe d being 42 is correct for all but one variant of hardware device). At this point, you have two options:
1. Update function foo to include support for parameter d:

int foo (int a, int b, int c, int d)
{
...code of foo...
}

This breaks the binary compatibility (well, and source for that matter). Probably you'd see segmentation faults/invalid memory accesses, etc.

2. Create a new function (say, foo2) that includes support for d, and maintains backwards compatibility:

int foo2 (int a, int b, int c, int d)
{
... code from function foo...
}

Then, update foo as such:

int foo (int a, int b, int c)
{
foo2(a, b, c, 42)
}

Existing drivers don't see that foo has changed, and new drivers needing the extra parameter can use foo2. Binary (and source) compatibility is retained, but it becomes a major pain in the butt for the developers. Imagine several of these changes happening, and you (possibly) end up with foo2 through foo15.

Quite frankly, I can see why Linus doesn't want to do it, for both technical and the ideals behind it. Personally, I believe it's the ideals that he favors, rather than the technical side of it. That said, on the x86, maintaining this might not be so bad, but maybe on other platforms it is more difficult. Back when software was typically written in assembly (my favorite example that comes to mind is GEOS on the Commodore 64, it had a huge API, which retained backwards compatibility with older versions), not only did you have to make sure that the parameters passed in were the same (usually on the stack, or registers, or inline), but you also had to make sure that the entry-point addresses stayed the same too (most often accomplished via a jump table).

-- Joe

Re:Neat!

[cbiltcliffe]

1. Cut and Paste don't work

Always worked fine for me, since about 1998.
Winboys complain that Linboys say Windows crashes. In 1998, it did. (Incidentally, it still does now. Admittedly, less often, but the only reason you never see it on XP is that it automatically reboots, rather than sitting there with the BSOD.)
Yet, the Winboys continually complain about problems with Linux that were solved in 2000 or earlier.

2. Games

There are plenty of Linux-only games available, and lots of the good ones that use OpenGL, rather than DirectX crap, have Linux ports. If a developer uses a platform-specific 3D API, then refuses to do a Linux port because it would be essentially a complete rewrite to use a platform-independent 3D API, that they could have used in the first place.....it's not Linux's fault. Blame the developer, for being short-sighted and stupid.

3. Font display is awful

Again, 1998 problem. Get yourself up to date, and see my answer to number 1.

4. Aplication installation is awful, poorly integrated with desktop(s)

KPackage, Synaptic, YaST, and many other package managers will install just about anything on most distros. Sure, there's the odd one that doesn't work, but you run across that with Windows, too. Ever try installing Norton Anti-Virus 2001 on Windows XP? Both released in the same year, but they're incompatible.
One more thing...if you'd been using Konqueror to post your message, it would have let you know that you spelled 'application' incorrectly. Nice to see IE being so innovative.....NOT!

5. 86 different text editors... why?

Notepad, Wordpad, DOSedit, TextPad, Boxer, Zeus, GWD Text Editor, EditPlus.....
All text editors for Windows. And the first three come bundled - and installed by default - with Windows XP.

6. Some very important web sites only work with IE

Like what? Windows Update? I have yet to run across any website that doesn't work with anything other than IE, with the exception of Panda Software's Activescan. Unfortunately, it's ActiveX only. Again, not the fault of Linux, but the fault of a poor programmer who used a platform-specific technology to provide a function that could be provided with a platform-independent technology. Trend's housecall, however, works with Java, so will run on just about anything.

7. General lack of polish, little (and some big) things inexplicably not working

Wireless networking randomly popping up and down. Unrecognized hardware being completely ignored and hidden during install, rather than warning the user. Running any old twit as admin by default.
All examples of lack of polish and foresight in Windows.

8. Cut and Paste don't work
9. Font display is awful

Can't find enough arguments, so you need to repeat yourself? Not only that, but you chose to repeat the arguments that aren't valid, as the problem was solved years ago.

I know I'm not supposed to respond to trolls, but they're just so fun to shred into tiny little pieces.....

Protected libraries

[mrogers]

What's needed is a hybrid between a library and a process - call it a protected library. It has its own privileges and its own data segment, like a process, but it doesn't have any threads: it exports an API and uses the caller's timeslice and stack segment, like a library.

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.