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."
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?
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?
That's no joke. Why haven't I switched permanently to Linux? The list of reasons is quickly becoming shorter and shorter.
Games? - The biggest games (and more games in general) are getting Linux ports.
Office suites/productivity? Done.
Plug 'n' play hardware and peripherals? Getting better, but the actual hardware manufacturers sure seem to be dragging their heels.
Low cost? Can't beat free.
Easy to configure? Again, getting better, but still a long way to go.
Easy to learn? Well, I haven't done any studies on this, but from various "switch" stories, it's at least as easy to learn (if not easier) than windows.
Security? Pretty dang good, but I'm not going to fool myself. If Linux were as widespread on the desktop as MS Windows, there would be a whole lot more exploits. Not necessarily more than on Windows, but more than there are now.
Help find a cure for cancer. Join the [H]orde
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
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
Hardware Abstraction Layers are VERY old. Even the 6502 based Commodore computer series (PET, VC20, C64 et. al.) had some kind of HAL, it was called the Kernel ROM, and developers were strongly encouraged to use the I/O-Routines provided by the Kernel ROM instead of writing their own.
The whole point of the VM/CMS operation system from IBM was hardware abstraction. That's where the name comes from: Virtual Machine CMS. VM/CMS was providing an abstract CMS system (CMS being the predecessor of VM/CMS) for each process or task, so you could use multiple virtual CMS systems on your hardware.
Just because WinNT uses hardware abstraction doesn't make it an innovative idea from Microsoft.
Same about KDevelop. Ever used an OSF Motif Toolkit? They are around since the early days of Motif (around 1988), and the Visual series from Microsoft could easily be called an ripoff. Not to forget the Turbo Pascal/Borland Pascal/Delphi IDEs or again IBM with the VisualAge series of compilers.
The real power of Microsoft is not innovation, it is the sheer manpower and organisation they have to integrate ideas that proved to work into a single, quite coherent system (even though in the beginning, Microsoft's offerings didn't integrate very well into each other... The first MS Office suites for instance had different file dialogs in every program, and different ways to set up the printer... but it got better every version).
And for becoming "more and more similar to Windows": If the default installation is in a substantial way different than Windows, the whining goes: "Steep learning curve! It's too different!". If the differences are hidden, then the whining is: "It's becoming more and more Windows! Where is the innovation?" It seems as if the GUI developers have to choose between Scylla and Charybdis here.
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.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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).
Say you have a function, foo, and it takes three integer arguments. So, here's your theoretical function: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: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:Then, update foo as such: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
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.
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.
Again, 1998 problem. Get yourself up to date, and see my answer to number 1.
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! 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.
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.
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.
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.....
"City hall" in German is "Rathaus" Kinda explains a few things......
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.
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
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.
LOL!!
Uptime of WindowsXP box at university when I start using it is less than 7 minutes. I'm not kidding you.
simple things like looking up my schedule tend to crash IE
to the point where system locks up. Opening PDFs leads to similar result.
These are all dell p4 2.4ghz boxes. we have more than 500 of them. I can reproduce effects on any single box.
Then there are some boxes which dual boot to linux. Never had a single problem. Not a single crash or hang.
And don't get me starting about scanning on windows with HP printers.
Scan->wait 8 seconds for pretty HP scan wizard to show up then it hides then scanner starts scanning, then you save the file one by one. On linux: start xsane (UI is ugly but does the job nicely). Specify base name and counter length. Then just keep clicking 'Scan' and feeding a new page.
Also users need to do control+C control+V windows instead of select and pressing scroll mouse in most linux GUIs.
No Virtual desktops on windows.
List goes on and on.
I honestly don't know of a better way to constupate your work then to use a Windows enabled desktop. Your productivity approaches 0.
So those who say Linux is difficult to use should just fuck off. They have spent years and years learning how to do things in Windows and LEARNING the WORKAROUNDS to things that should have worked and then complain that the workarounds don't work and you have to do things propertly.
ok, rant is over.
~omi