The Linux Incompatibility List

Jonathan Lassoff writes "The Linux Incompatibility list is a wiki project that attempts to document hardware that is incompatible with Linux rather than list what is compatible. In the wiki, it is possible to add alternitives so as to push hardware manufacturers to make good binary drivers, publish specifications, or even better, publish open drivers."

Comments

Wow, looks like they'll need new hardware

[ScytheBlade1]

0 comments and it's already /.'d into the ground.

Re:Wow, looks like they'll need new hardware

[ravenlock]

Perhaps they just shut down their database to save us the trouble? :)

Re:Wow, looks like they'll need new hardware

[chimpo13]

That's because the server is IIS. Someone glanced sideways at it and down it went.

Re:Wow, looks like they'll need new hardware

[Iron Clad Burrito]

You mean WINE won't run IIS?

Re:Wow, looks like they'll need new hardware

[BoldAC]

In college I maintained the "Moan and Groan List" of hardware and software incompatibilities.

Old newsgroup posting...

That was around 10 years ago when HP, Packard Bell, iomega, and several other companies were learning that they could release cheap, buggy hardware and make an assload of money.

I got tons of traffic and was in several "best of" lists over the next couple of years. Several companies were trying to sue me but luckily several of my faithful users were lawyers and helped me through it.

Uptime was a problem because we had no way at that time of making money on the project. We bounced from server to server trying to keep up with traffic. I understand how these guys feel.

After a couple of years, I went to med school and didn't have time to keep it up. I'm such a shmuck... If I would have focused on that page instead of my medical career, I could have made millions, gone bankrupt, and then made money again!

AC

Re:Wow, looks like they'll need new hardware

[nacturation]

... which makes you wonder why they didn't just put up a few pages on Wikipedia for this. The infrastructure is already there and as long as they're not doing any really custom wiki coding (and it's not outside of Wikipedia's intended scope), they might as well let someone else do the hosting who has everything in place.

Re:Wow, looks like they'll need new hardware

[sparkywonderchicken]

Maybe it's really a modded Xbox and they decided to play Halo instead.

Re:Wow, looks like they'll need new hardware

[robslimo]

I agree that they should have done it on Wikipedia... therefore, I started it (link from Usability section of the Linux topic to a new topic Linux Incompatibility)

The list is empty since I couldn't get to the original server. So, as time permits...

Re:Wow, looks like they'll need new hardware

[stratjakt]

Maybe they just have a little more class than to dump a potentially large bandwidth load onto wikipidia.

Once upon a time, people on the 'net weren't a bunch of assholes, and would politely inquire before knowingly burdening your machines with a ton of bandwidth. (*cough* slashdot)

Or maybe, the info might be a little dynamic for wikipedia to handle effectively, I dunno.

This list could change daily, or even hourly.

"GooberTech PCI Master Xtreme is incompatible"
No wait
"GooberTech PCI Master Xtreme is supported with kernel patch 3432-231"
no wait
"GooberTech PCI Master Xtreme is unsupported again" (patch withdrawn because of patent infringment)
no wait
"GooberTech PCI Master Xtreme is supported from rev 2.6 and up, excluding rev 3.4"
etc, etc..

This list is a good idea though. I hope they're smart and put a good "cellphone/PDA" compatible interface on it. This is the type of search I'd like to do while standing in the checkout line of CompUSA.

Re:Wow, looks like they'll need new hardware

[DavidNWelton]

Ha ha...

It's not IIS, it is of course, Apache with Rivet. We were in the middle of some work on the server, and as I commented elsewhere, I *just* created this and am still tweaking the software. It's still at the stage where I'm doing research for hardware to put in myself in order to make it a useful resource.

Neither the list, nor the server, nor anything else was ready to be published on slashdot, or anywhere else high-traffic for that matter. I guess I shouldn't have linked it on kerneltrap, but it was handling the traffic there no problem.

In any case, you can read more about the idea, and some other people's comments on it at here, which also has a link to the thread on the kernel mailing list:

http://kerneltrap.org/node/view/3695

Re:Wow, looks like they'll need new hardware

[valkraider]

Rule #1: If you are going to set up a website with ANYTHING cool, drop all /. referrels, or at a minimum send a "low bandwidth" version to people coming from /.

Rule #2: make sure Google gets a hold of your site, then just use the Google cache. ;)

Re:Wow, looks like they'll need new hardware

[Ray Radlein]

Well, there goes a new entry for the Slashdot Incompatability List Wiki...

Re:Wow, looks like they'll need new hardware

[xgamer04]

Wow, what a great idea!

Except for the fact that Wikipedia is supposed to be an encyclopedia, not a tech support forum...

Difficult to maintain?

[garcia]

This is going to be difficult to maintain. The numbers of unsupported hardware are huge. I just tried to add my digital camera (Kodak DX4530) but kept receiving an error that someone else was making a change at the same time.

As new devices are usually intended for a Windows audience I really doubt that this will do anything but tell people something they already know...

Re:Difficult to maintain?

[ccharles]

Yes, but hopefully the list will grow at an ever-decreasing rate. I have been using Linux almost exclusively for about three years and I know that I've had fewer problems with hardware as time has gone on.

Re:Difficult to maintain?

[mikeyrb]

But I would call it a step forward. I would like to see integration of sites listing working drivers and a site like this, where we see what doesn't work. If you're out to purchase something new, you don't know if someone's tried it yet because sometimes you just can't find it listed. It'd be nice to see just one page, yes this works, or no this doesn't. Even better, you could then look at the whole list and pick one that works. Or in the nature of the new site, see one that works for one platform and hope for the best that it will work for yours soon. Oh, and after the /. effect dies out, the site should probably maintain well.

Re:Difficult to maintain?

[pvcf]

But this is brilliant...

Put up a nearly empty site, make it publicly editable, advertise on /. and *poof*...

Hordes of slavering technophiles come and fill up your site. Assuming it stays up long enough under the onslaught that is...

Re:Difficult to maintain?

[DavidNWelton]

I didn't advertise it on slashdot... actually, I would have preferred that it didn't go near slashdot for a while untill it was good and ready. Bleagh.

Re:Difficult to maintain?

[yuri benjamin]

just tried to add my digital camera (Kodak DX4530)

I went to check out a camera that my father-in-law was buying. Took my Linux laptop with me (Mandrake 10), plugged in the camera and a few seconds later a harddrive icon appeared in KDE. Opened it and a few folders/directories deep I found the thumbnails of all the photos. Clicked on one and it came up full size.

As new devices are usually intended for a Windows audience I really doubt that this will do anything but tell people something they already know...

The above experience told me that there are two types of hardware manufacturers. Those that use standard interfaces (eg USB mass storage) and those who invent their own (and only release windows drivers). This wiki will be a useful reference, and might encourage manufacturers to just use a standard that's already there.
Meanwhile, I will always take the laptop when checking out peripherals.

Re:Difficult to maintain?

[spidereyes]

Drum roll please --

Also missing from the list: Women.

Re:Difficult to maintain?

[Benwick]

In fairness to the ladies (for whom I am not the best spokesmodel, being male), there should be a -1 Sexist moderator option... Who brings me dinner when I've been coding for hours at home?? I'm not that easy to maintain myself!

Or maybe around here it would be a +1 Sexist? Wink wink, nudge nudge...

Video cards

[Brento]

Make life easy - somebody just please copy the entire list of video cards from Epinions or Cnet.

Re:Video cards

[oGMo]

Make life easy - somebody just please copy the entire list of video cards from Epinions or Cnet.

Funny? Maybe in 1992. Nowadays the only video cards that matter are nvidia or ATI, and the latter don't comprise "the entire list" on either site. NVidia has very good linux drivers; ATI has shoddy ones.

So if you want to make it easy, just paste any hardware made by ATI and anything with "made for Windows" after it. (Even the latter list is shrinking slowly.)

Re:Video cards

[r_j_prahad]

I wish you'd gone into detail on what makes ATI shoddy, because I'm running an ATI Radeon 9200 at home, and it literally blows the socks off the Nvidia card I had at work. My 9200's had no problems since day one. Install was a breeze, just dropped the card in the slot and powered up. I had to tweak XF86Config to get DRI, but that was hardly a problem. I guess I was just lucky that I had all the latest drivers and complete docs to work with.

Re:Video cards

[Anonymous Coward]

I'm running an ATI Radeon 9200 at home, and it literally blows the socks off the Nvidia card I had at work.

Literally, you say? Maybe the Nvidia card was clocking itself down because the socks were impeding heat dissipation.

Re:Video cards

[Karora]

Yes, the 9200 is OK, but subsequently ATI have not released good drivers for 9500 and higher.

I have a laptop with a 9700 in it, and the XFree86 or X.Org drivers are not 3D accelerated. The download from ATI doesn't work with ACPI suspend / resume in my laptop, which kind of sucks with a laptop. Until recently they also just kind of crashed randomly, etc, etc.

At home I had an ATI 7500 in my wife's machine. I had endless problems with the binary drivers from ATI and eventually replaced it with an NVidia card which has been excellent, even if I do have to use binary drivers.

While I dislike the fact that the drivers are binary, the likely fact is that both of these companies infringe each other's patents and copyrights to a large degree, and if they open-sourced their drivers they would end up with lawsuits forever, kind of in a deadly embrace.

For this reason I don't expect to see binary drivers any time soon. Maybe a new company can come along, and produce decent video hardware, and open-source drivers, without infringing patents and copyrights. That would be great, but I won't hold my breath.

Re:Video cards

[Trejkaz]

So if you want to make it easy, just paste any hardware made by ATI and anything with "made for Windows" after it.

My last webcam said "Made for Windows" on it, even though it had an OV511 chipset, and thus worked on Linux pretty much perfectly. A lot better than my ATI graphics card works, anyway. :-)

no no no

[machine of god]

It's not slashdotted, the link is just wrong.

clicky

Re:no no no

[flosofl]

and now this link is salshdotted... Well done! :)

Re:no no no

[McLoud]

Now, thanks to you, it is.

Incompatibility #1

[bherman]

Their hardware and Frontpage Slashdot article. Looks like it's time for some new stuff!

List of Hardware with Linux Problems

[manual_overide]

Device: *
Vendor: *

That was easy... :p

Re:List of Hardware with Linux Problems

[SillyNickName4me]

> I will not buy it if it does not support Linux, even if it is for a Windows PC as I know someday I will run Linux and not windows with it.

By which time someoen most likely reverse engineered the thing and made a linux driver anyway..

*raises hand*

[AKAImBatman]

so as to push hardware manufacturers to make good binary drivers

Question? When did Linux start allowing binary drivers that were not kernel specific? Last time I checked, Linus has jury-rigged the kernel to only allow drivers compiled against a specific version of the kernel. This was in order to force hardware manufacturers to release the source code.

Personally, I think Linux should allow binary drivers. Most hardware is useless in a few years anyway, so what good is having the source? Compare that to the OS, where it can live on for decades.

Re:*raises hand*

[salimma]

You *can* have good binary drivers. It's the interface between the binary drivers and the kernel that is normally provided in source form, and that needs to be recompiled against the target kernel.

Ask nVidia, VMware, and.. what's that modem with binary Linux drivers, can't remember.

Re:*raises hand*

[IANAAC]

Most hardware is useless in a few years anyway...

Not always. I have some perfectly good parallel port midi hardware that no longer works in WinXP or Linux. It's precisely because nobody's written drivers that I can't use it. It's not like the MIDI spec has changed any.

Re:*raises hand*

[Abcd1234]

This was in order to force hardware manufacturers to release the source code.

Not at all. This is to prevent people from running old modules against a new kernel version, where symbol names and other internals may have changed, thus resulting in potential crashses, instabilities, etc. As I understand it, you can turn this off by disabling kernel module versioning, but the module itself may refuse to load if it detects the wrong kernel version.

Fortunately, there's a really easy way around this that nVidia and other folks use. nVidia distributes their drivers as a binary driver, along with some source which acts as a thin layer between the binary code and the kernel itself. This layer is then compiled for the specific kernel version, while the binary driver portion remains the same. This is, incidentally, how I install the driver (since they have no modules for my specific kernel version).

Most hardware is useless in a few years anyway,

Holy crap, HIBT? This is the dumbest thing I've read in a *long* time. Hardware is *far* from useless, even long after it's been "obsoleted". It's only the silly gamerz that require the latest and greatest... most people get by with fairly modest equipment. Heck, my firewall ran on a 486 DX/100... that is, until the power supply died. *sigh*

Re:*raises hand*

[AKAImBatman]

This is true for graphics cards. Which you *don't* have the source for. On the other hand, you *do* have the source for a wide variety of network cards. All of which does very little good. Manufacturers of these cards revamp the interfaces every few years to meet the new standards in throughput and features. Drats, foiled again!

Re:*raises hand*

[Stevyn]

I agree. If the manufacturer has some secret technology that makes my scanner better than the competition and will only release a binary driver, then I'll gladly install it to use it. Take NVIDIA for example, they don't release the source code, but the installer "compiles" a kernel module so the user can take advantage of the 3d acceleration that they bought.

I'd rather see hardware supported by closed source drivers than getting stuck with a $200 paperweight because I bought a camera, and THEN switched to linux.

Binary drivers used to cause a lot of problems with windows. But Microsoft and the manufacturers got better and hence no more BSODs (despite the bad jokes that still exist here).

Since the kernel is open, I think it could be easier for manufacturers to develop drivers as opposed to writing them for windows.

Re:*raises hand*

[oudzeeman]

I agree on binary drivers. I'm all for open source software, but if a company wants to release binary-only drivers for its products, then my attitude is "well at least they support the product under linux". Trying to 'force' hardware companies into releasing source isn't going to work (especially highend hardware like video cards). Source for drivers does have some educational value, but most people would just like native support for their video cards or whatever in linux.

Re:*raises hand*

[AKAImBatman]

Not at all. This is to prevent people from running old modules against a new kernel version, where symbol names and other internals may have changed, thus resulting in potential crashses, instabilities, etc. As I understand it, you can turn this off by disabling kernel module versioning, but the module itself may refuse to load if it detects the wrong kernel version.

I haven't heard this, but I believe you. It's still an unnecessary restriction. Every other OS is careful to build in a driver interface that is independent of the OS version. Only Linux seems to force things right down to the level of kernel options.

Now if we had to switch drivers between major releases of the Linux kernel (e.g. 2.2 to 2.4), then there'd be no real issue.

Hardware is *far* from useless, even long after it's been "obsoleted". It's only the silly gamerz that require the latest and greatest... most people get by with fairly modest equipment.

It's not a matter of the hardware still being used. Usually you have old copies of software to go with it, too. The real issue is that hardware is a moving target. Chasing around new hardware items to create drivers for, is an exercise in futility. By the time you create the drivers, the hardware has already been replaced with the new model. This means that you HAVE to run old hardware to stay 100% compatible with Linux.

Why bother, when you can get the driver from the manufacturer? The driver can be used for as long as both the hardware is manufactured and Linux doesn't change its driver versions. Once the hardware is no longer supported by the manufacturer and Linux, you can continue running with the older copies of the OS software until an upgrade. That should give you AT LEAST five years before you can't upgrade your core OS.

Re:*raises hand*

[david.given]

When did Linux start allowing binary drivers that were not kernel specific?

I'm posting this using a desktop machine running Linux that's talking to a server running Linux via two wireless ethernet cards using Windows drivers.

Check out ndiswrapper. It's a surprisingly elegant system for letting you use WLAN drivers written to the NDIS standard (e.g., Windows network drivers) under Linux.

It's wonderful. It's simple and highly effective. It lets you use drivers written by people with access to actual technical documentation, it's small, it's adequately fast, it's easy to manage... it also lets me use my two network cards under Linux, which I can't do otherwise. (One's a RTL8180, which is unsupported under Linux, and the other's a ACX100, for which a driver does exist but which sucks.)

Didn't NDIS start out as a portable driver standard, anyway? Netware, OS/2 and Windows, wasn't it? What would be really elegant is to use some sort of code translation to allow the drivers to be used on non-ix86 machines...

Re:*raises hand*

[Brandybuck]

Most hardware is useless in a few years anyway, so what good is having the source? Compare that to the OS, where it can live on for decades.

The exact opposite is true. The hardware is going to live on for a very long time, while the kernel is going to change rather quickly.

Let's say you buy a SnafuCard.v2 today in August 2004. In five years which do you think will be more likely: the SnafuCard.v2 driver for Linux 3.2 will be available on the Snafu website even though they have not sold that card in four years; or; Linux 3.2 will have a source based driver for the SnafuCard.v2 that has been continuously updated along with the kernel? While the later isn't guaranteed, I think it's much more likely than the former.

The hardware is hardware. It's a material item whose characteristics will not change unless it corrodes or you break it. But the kernel is an ever changing dynamic collection of software. It WILL change. Unless you plan to be running Linux 2.6 five years from now, you had better not rely on today's binary-only driver.

p.s. There are reasons for Linux to allow binary drivers, but hardware obsolescence is not one of them.

Re:*raises hand*

[jburroug]

Damn skippy - I still have the internals from every system I've built, all still running and doing useful things on the home network. My firewall is a old (now caseless) Celeron 300a (no longer overclocked since it's not a desktop) system with some surplus 3COM cards in it, I have my old Pentium MMX 200mhz system (again caseless) hooked to my stereo as a networked MP3 player, my file and general purpose server is an old K62 seutp, and I'm currently finalizing the setup on an old PIII/Pro 500mhz system someone gave me for use as a "media station" I'm going to use as a dedicated machine for ripping/burning CD's and talking to my digital camera.

With forwarded X sessions I can run all these apps as though they were local to my desktop or laptop at once without using up valuable system resources better left to interactive processes. Old hardware rocks, I can't get enough of it :)

Re:*raises hand*

[Abcd1234]

The former. Wait... HIBT??? ;)

Re:*raises hand*

[Greyfox]

We used to have a major problem in the OS/2 camp with OEM binary drivers causing TRAP000Ds. Of course, IBM got blamed for all those third party kernel traps, and OS/2 got a reputation for being unstable. Fact of the matter is, the OS/2 kernel was rock solid until you started adding third party drivers to it.

I suspect that Microsoft fixed the problem by getting all those OEMs by the balls and telling them that they'd squeeze real hard unless the drivers were solid. Microsoft is pretty good at ball squeezing. Competing OSes can't just squeeze good drivers out of OEMs the way Microsoft can. They just don't make up a big enough demographic to be able to get a good solid grip on OEM balls.

Re:*raises hand*

[david.given]

No what would be really elegant is if there was an NDIS interface written into the linux kernel so you could nativly load NDIS drivers in linux.

Um, that's what ndiswrapper is. It currently builds as a module for ease of development but it would be trivial to compile it in to the kernel binary itself. It looks in a special directory for files describing the NDIS drivers, and if it finds the hardware, loads them and binds them. The end result is you end up with a bunch of standard ethernet devices. No userspace tools required anywhere, except for setting up the special directory in the first place...

Yes, it really would be possible to have an option in your favourite distribution's installer saying 'Install network driver from floppy disk'.

Re:*raises hand*

[Brandybuck]

...why would it not work with later versions of the OS?

That is where your argument completely falls apart. That binary is *NOT* going to work with different kernels. My friend has a Canon printer that will not work under WinXP desptite the fact that he has binary drivers for Win98. A coworker has a card that will not work with Linux 2.6 even though he has a binary driver for 2.4. I myself have experienced extreme difficulties using an binary video driver with FreeBSD for the same reasons.

The source code will at least let you keep up with minor kernel interface variances, and easily port across major interface variances.

Another drawback to binary drivers is that you have no fix if they start interfering with hardware you by later on. While there won't be tens of thousands of developers eager to fix the source based driver for you, there will still be scads more than that bankrupt hardware company will provide.

Re:*raises hand*

[dossen]

Well, the hardware stops working when you have to upgrade to an OS version that is not compatible with the old driver, obviously. And your claim that the old driver should keep working with newer OS versions makes some very broad assumptions: That the driver interface in the old OS is sufficiently well designed to keep it around (or that legacy drivers remain supported through some kind of wrapper), that there is no security/stability/whatever issues with the interface (would you like to keep a driver interface around if a root exploit was found in it?), and that the binary driver (which nobody can inspect) does not cheat and rely on some feature/bug/randomness not documented in the driver interface.
Are there any major OSes out there where you can pick up a piece of unmaintained (by the vendor) hardware, without OS-vendor supplied drivers, and run it with a driver from a few versions back? I'm not thinking like Win2K -> WinXP, more like Win98 -> WinWP, or Mac OS 8/9 -> OS X? I really would like to know. And as I said, if the new version includes a driver, it doesn't count.
And if we were aiming for such compatibility, it would at least require developers with access to the hardware, and a sufficient supply of machines and other hardware for testing, if you want it to mean anything. If the specs and/or drivers are open, those testers at least have the option of attacking problems from both the kernel and the driver, whereas they are left guessing if the driver is closed.

Re:*raises hand*

[shadowbearer]

Huh?

I was saying that your statement that other OS's maintain driver compatibility between versions is simply not true, nothing about linux.

But just to put my few cents in there, I recently bought a ultra-cheap Walmart webcam, which I thought would work with windows (was gonna use it as a laptop webcam for my winlaptop, turns out it barely works at all and causes frequent lockups); a couple hours investigation brought me to a few people who are in the process of writing linux drivers for this chipset, and they are near full-functionality at this point; so it ended up being connected to one of the linux laptops.

This particular cheapie was introduced by a UK company just last fall. Hardly a "year or two". The company who makes the chipset is not exactly forthcoming on it's specs, either, like Not At All (bastards).

Considering the amount of time it often takes companies to tweak their hardware drivers to full functionality in windows, it seems to me that you are underestimating the determination and resources of the OSS community.

I'll grant that back in the late 90's and even the first couple years of this century, I'd have agreed with you (and did in fact in many ways as I struggled to make hardware work with linux); but all that is changing incredibly rapidly, and thank the many selfless devs out there for that!

As for cameras, as a amateur photographer, if the camera manufacturers stay with the simple USB storage specs, they aren't a problem. I have a last-year model Fuji camera that required nothing more than plugging it in and figuring out which scsi device it showed up as then mounting it. There was nothing whatsoever on the web about it when I bought it. I'm currently tweaking a simple script that is easily launched to download the camera pix and open the viewer of one's choice.

Scanners are problematical, I'll admit - I've heard a lot of bitching - but if they'd stick to the specs (which also makes the windows drivers more reliable) then it wouldn't be a problem. In any case there is a huge number of people out there willing to write SANE interfaces; and those scanners which don't work are often the ultra-cheapies which are junk anyway, meh.

NICS, as I pointed out in another reply, are a minor problem, and I doubt that'll change.

Here's one for ya; I even got my Radio Shack clearance sale Phoebe wireless setup ($50 for the NIC-AP and two USB WAPs) to work with Gentoo with nothing more than an hour or so's research and source compiling, and it's proven reliable. If I had time I'd write a simple python script for dealing with the setup. Someday maybe :D

OT: You should have seen the look on the face of the manager of the local Shack when I stopped in the next morning and told him it was working - I don't think he believed me. :D ("That doesn't work with Linux and never will, I know, I run Redhat linux at home!" I'll treasure that moment for a long, long time, believe me. )

The old view that "it doesn't work" is changing to "it'll work with some effort" - and if those who do the effort share the info, and someone else down the line writes simply setup scripts to use that work, well, maybe that'll wake some of these corporate asshats up, eh?

No, AKA, things are changing, and changing rapidly. Sure, a lot of this stuff isn't for the average home JoeJill yet, but as the work gets done and the distros incorporate it, that'll keep changing, eh?

Cheers,
SB

Linux Incompatibility

[hawley Griffin]

wow, a linux comminuty is incompatible with the servers hardware neat

Slashdot compatibility

[fmlug.org]

Their servers dont look like there /. Compatible. I wonder if thats in their database?

yes yes yes

[Haxwell]

It is slashdotted, even if the link is wrong..

it does not serve

[Anonymous Coward]

If my hardware is not in the list, does not assure to me that that is compatible

My idea

[Stevyn]

I had this idea the other day and I'm going to rehash it on this thread. Maybe it's redundant or overreaching, but I'll try and relate it in words anyway.

A set of standards called "Desktop Linux". From a PHB and marketing viewpoint, it makes sense. Nothing to do with servers or embeded systems or that old 486 dhcp server sitting in someone's basement. It's just a concept that represents the computer that sits in people's homes and cubical.

So the idea I'm kicking around is a set of standards. As far as the end user is concerned, the heart of this is a GUI interface similar to what distros include in their base install. The Mandrake control center comes to mind, but I hear YaST and Yum (I may be wrong on that one) are similar to this. I'm proposing a common "control center" where all the hardware that the user is concerned with such as scanners, cameras, mice, printers, graphics card, monitor, USB drives, Firewire drives, etc can be controlled and configured from. Hardware other than that like IDE controllers, USB controllers, internal hard drives, and other devices people generally don't have to worry about that are either hidden or not existent in this at all. This control center is independent of window mangers so gnome, kde, and icewm for example would not have to worry about it directly, just interfacing with it.

The goal is to be able to walk into a store like best buy, see a little sticker on the box of a printer that says "Desktop Linux Compliant" and to purchase it knowing it's promised to work with their computer. So they take it home, out of the box, plug it in and something in the background like hotplug detects it first. It passes that information along to the control center. The control center informs the user of it's detection and either downloads the driver or asks for the CD the manufacture included.

I know that sounds too good to be true, but let's pretend it's still possible.

The manufacturer doesn't have to worry about supporting all linux distros and platforms, just the "Desktop Linux" standard. Their drivers are just modules in this control center. Printer modules can then connect up to something like cups to do the rest of the work.

What makes this special is that as long as distros and manufacturers are compliant with these standards, everything should work properly. Drivers can be compiled for i386 or some other low common denominator or just delivered as source for simplicity.

Same idea for a usb flash drive. It's inserted and the control center mounts it and opens up a konqueror window and displays it's contents. It's up to KDE to provide that part. The control center just gets the information from hotplug, mounts it, and tells the window manager to open a window.

This whole concept is where open source should try to be. Central and enforced standards. The control center is probably just a bunch of interfaces for the distro, hardware maker, kernel, and window manager. But the goal is to bring them all together in one central location that's easy to use.

I'm not suggesting to rewrite hotplug, cups, samba, or sane, but just to agree on a simple yet powerful interface for the user to trust. Hardware makers could develop modules for the control center that would be standard across all platforms and window managers.

This still preserves one of the initial goals of linux to be customizable and compact. If someone doesn't want "Desktop Linux" then they don't have to install it. But distros would like this idea so they don't have to repeat the work SuSE and Mandrake did to get a scanner working. It also allows people to use lighter window managers because the hardware controlling ability in KDE is a reason I use it.

So that's the idea I'm kicking around. Comment as you wish. I'll admit I don't know the technical difficulties this might entail, but distributing it across hardware, distros, and window managers could make it feasible.

Re:My idea

[NorthDude]

Hardware makers could develop modules

Ain't this what we usually call drivers or am I misunderstanding your idea?

Because right now the problem isn't really (or only) that we do not have proper gui to support hardware (or should I say to support users) but really that not all hardware have linux drivers.

Your idea sounds ok, but when you say "Their drivers are just modules in this control center." you forget that this is only the visual part of the story. On the other part, the system need to know how to talk to said hardware, what feature it can use etc etc, and this is really what a driver do.

For example, there is many sound card out there, but everyone of them has different set of features. In order to be able to use my Audiophile 2496 I need and interface (a driver) which will "route" my date thru it and let me access its fonctionality.

I think that a universal control center may be a nice thing to have in the future, maybe not, but for now I would really like to just have drivers for all the hardware I have.

Sorry if this sounded pedantic, I don't know how much you already know about all this! :-)

Re:My idea

[GreyWolf3000]

The proposed solution is DBUS and HAL. HAL is just an abstraction layer--it is a common library API that allows software to deal with hardware installation in a platform-independent manner. DBUS is a bit more sophisticated--from what I hear it's going to be an entire interprocess messaging system that will allow software to communicate with hardware via the HAL.

Essentially what this means is that pretty soon, you can plug in a USB camera and have your shiny Gnome desktop popup a window telling you that you have just installed a camera, and providing you with some basic configuration options.

The problem with a unified control panel is the various differences between distributions would make it impossible to maintain.

What I would like to see is more standards defining how files in the /etc directory should be placed and formatted. This would allow a control panel that doesn't know everything about each configuration file, but rather serves as a more advanced text editor with a tree view to browse through configuration files. It would of course provide documentation for each file (like what each option does).

Then we'd have a tool that both intermediates and advanced users would appreciate. It would also be simple enough to teach novices how to use (providing the documentation is good enough).

Re:My idea

[adrianbaugh]

This is a feature, not a bug. Linux runs on more than x86, you know - but have you ever seen a binary driver for anything other than x86? Making it such a pain in the arse to get binary modules to work is an encouragement for companies to release source (which can be compiled on anything you care to run linux on, probably including your dishwasher...)

It sounds like what you're after is an operating system that positively encourages binary drivers and is only readily available on x86. And we all know how well that works...

Re:My idea

[ComputerSlicer23]

Nope, try again. Linus is opposed to doing it for technical reasons, NOT for philosophical ones. You have him confused for someone else. He won't support a crappy interface once a better interface is designed. Linus thinks Open Source is better the closed source for the OS for Engineering reasons (it's better Engineering), then he does because he believes you have a god given right to see the source code for every binary you run (That'd be RMS's way, and it's associated with the term "Free Software").

One of the reasons the Linux kernel has improved so much, is so stable, and can scale as well as it can, is that when there is a technical reason to dictate a change, the changes is made. They don't have to support bad decisions made years and years ago (actually they do if it affects userspace applications, but if it's internal to the kernel, it gets killed with impunity). To pick a particular example from Windows, the GDI memory goop that Win95, Win3.x and Win98 had. When you ran out of that, your machine was cooked. It didn't matter how much RAM you had, that amount of that was relatively fixed. It was a stupid problem, that caused me no end of pain, but there it was. I'm sure Solaris has one. Well, heck, I hear the TLI/STREAMs interface is vile, but it was one of the two standard driver models that was easy to write. However, it had very poor performance.

The other thing that's nice about Open Source only drivers, is that there's one and only one implementation of a lot of stuff. Tons of network cards have essentially the same structure for a lot of the driver. All that gets refactored out into common modules for all drivers to use. If a bug is found in that shared code, it's fixed in all of them at once.

Linus doesn't support Binary interfaces, because he has to choose between making it easy for you to have a non-open driver, or for making it easy for him to make the Linux kernel be as good as it can be. I'm all for making Linux as good as Linux can be. You might want him to choose "support a driver model for the lifetime of a kernel series", but I just buy hardware that is known working with Linux. Yeah it sucks at times that I can't get a specific piece of hardware that sounds cool, but I get Linux for free. I'll take that trade 8 days a week.

Kirby

Re:My idea

[yuri benjamin]

But if I'm a manufacturer I have to decide what how to get the camera to work with linux. Do I try to get a driver in the kernel? Make one for gphoto or some other project?

Neither. Just make your camera a USB mass storage device or make it talk PTP (Picture Transfer Protocol) so existing drivers can already talk to it.
Ditto for printers - make it talk PS or PCL and release a PPD file. PPDs can be used with any OS.
Have a similar protocol for scanners.

Drive manufacturers did this decades ago with SCSI and ATAPI. Seagate and Maxtor don't need to create linux drivers, just make their HDD talk ATAPI, or SATA, or SCSI.
Standards, folks. STANDARDS.

Wireless

[digitect]

I like the idea. I've just spent the last week trying to get a wireless PCMCIA card working, finally assembling enough documentation to understand exactly what chipset it has, what source is available, what packaging is not available (a non-developer's laptop), and the likelyhood of the distribution ever supporting it. (Binary wrapping, etc.)

I often use Red Hat's compatibility list to find stuff that is known to work, but it would also be useful to have a list of stuff I'm wasting my time over.

Sounds good...

[teamhasnoi]

but does it run Linux?

.
.
.
. oh. sorry.

Bad drivers

[Outsider_99]

What happens if vendors just write some bloated rubbish driver just so they dont have to be on the list? Then we have badly supported hardware aswell?

That's easy!

[JoeCommodore]

Just about every piece of hardware I bought thinking I could use it with Linux...

Actually later distros have mproved my situation, but I seem to pick the turkeys right off the bat.

This will be useless

[codefungus]

Ok. This incompatability list is gonna be useless...why?

Hmm...I wonder if my DWL650+ is incompatable. Well...I don't see it in the list.

I wonder if it's because it's compatable, or no one has assessed it yet!

Jee...I guess I'll STILL need to search a million websites, etc. etc.

Re:This will be useless

[Brandybuck]

No one knows, because there are umpteen different chipsets used in the DWL650 line. Early DWL650+ units had a prism2 chips, but later ones do not.

D-Link as the prime adherent of the business practice known as "reusing model numbers to confuse the customer". You have carefully examine the serial number to know for sure just what particular card you have. I had three DWL650 cards a month ago that had identical boxes, identical labels, and identical prices, but with three different chipsets. The only indication of the differences was a single letter on the serial number sticker.

Netgear isn't much better, though they do have the civility to mark the version number on the box. Of course, they still won't tell you what version number you'll get if you order online...

I've given up on wifi and am boycotting the entire technology until the manufacturers stop screwing over the customer. Even Windows users should be outraged, because they can't updgrade their drivers or firmware, because they will not know exactly what card they have.

Re:This will be useless

[HermanZA]

The best way to get a compatible WiFi card is to buy a discontinued card on Ebay.

Re:This will be useless

[bobbis.u]

Yeah, I came across this too. I bought two D-Link switches a few months apart - same model number, same box, same manual, but DIFFERENT PSU VOLTAGE!!! It never did work right after I got the wrong PSU one day.

Good idea

[fishbowl]

I never got over the frustration with the Wireless compatability list. See, the list is well done, and has lots of cards, and people seem to be working hard on it. The problem is, you cannot use the list as a resource to help you purchase a card! Many of the cards listed as compatable are either discontinued, have been changed to incompatable chipsets without changing the product model info, or else were only ever available in some regions.

What I always wanted, instead of a long list of cards that are not available, was a short list of cards that will definitely work, together with addresses of vendors who will sell such a card with a written assurance that the product I receive will indeed work under linux.

I was very upset when I bought a Broadcom device, thinking I was buying a Prism2 device. Even when you think you know what you're doing, you can get burned.

Re:Good idea

[fo0bar]

I was very upset when I bought a Broadcom device, thinking I was buying a Prism2 device.

See, that's your problem. "Broadcom", translated into common English, roughly means "screw the customer".

Though I have yet to find a Broadcom chipset wireless card that doesn't work under ndiswrapper. Of course there are downsides (can't use with kismet, not open source and still relying on windows drivers, etc), but at the very least it allows you to do wireless.

Wikis need moderation

[tmk]

I have seen a project like this once before, it failed as foreseen. Someone put on a website, but he did not take much time to consider how users should and could use this list, how could it be updated and so on.

Another project on the same website was to find the best(!) linux distrubution in a wiki - you can see the result here. Do I have to mention that the best distribution was not found?

When you put on a wiki, you need clear questions and rules, you need moderators, who pick the useful infomation out of the chaos and set an reasonable structure for wiki readers and contributors.

ACPI

[chaffed]

I'm probably going to end up with a troll mod but...

I think the first thing should be ACPI. ACPI support plain sucks under linux. I would pay the same amount for a linux distro as I do for MS XP pro ($200+/-) if that distro supported ACPI just as well as the MS operating systems.

Re:ACPI

[ArmorFiend]

Whoa, you're getting really ahead of yourself there. Before we work on getting ACPI supported, we need to figure out what the heck it is. As far as I can tell, based on talking to about 100 linux people, its "something to do with power management", but if you ask specific questions like "does it handle turning off the monitor", the answer is always "no". Also, if you try to establish its relationship with APM, you'll usually get a vauge reply like "the same but different". Mainly it seems to be another booby trap kernel module, that if you compile it you'll get inexplicable panics later. I love modules like that, especially when they've got cryptic names! We need more of them!

Re:ACPI

[runderwo]

You're not trolling, but your last few words show a lack of understanding of the situation.

ACPI is an open standard, but unfortunately, vendors' closed source BIOS implementations for the last few years are written against the Microsoft ACPI parser, bugs and all. Consequently, many machines fail to work at all with the Linux implementation (written against the standard) unless kludges or more relaxed syntax checking are used. This is not a failing of the Linux ACPI implementation or the ACPI specification. It is a Windows interoperability issue.

It is unknown how many machines have bugs in their ACPI BIOS code. The only way the ACPI developers find these and special-case them is when users mail in their bug reports and DSDT (check here), because the developers don't have access to every machine on earth to perform testing on. Even when a bug is found, it can only be worked around, because most system BIOS in the field are no longer supported by the respective vendors. So you'll see messages from the ACPI layer regarding syntax errors or known bugs in a particular BIOS, which the developers are helpless to fix in any way other than a special-casing.

Even worse is that many ACPI BIOSes return different values depending on which OS the vendor's ACPI code thinks you're running. Most of the time, any BIOS code path other than for an OS which calls itself "WindowsNT" is broken, so AFAIK, all ACPI layers simply spoof themselves as "WindowsNT" to the BIOS to avoid problems. Rather sad, isn't it?

As a final note, some vendors like Tyan, HP, Intel, etc are extremely active on the ACPI and LinuxBIOS mailing lists. HP has fixed ACPI-related bugs in their system BIOSes due to the Linux ACPI code rooting them out.

So the moral of the story is, don't assume poor ACPI operation on a specific machine is the fault of the Linux ACPI project. More often than not, it's the fault of the BIOS vendor not caring to implement the standard correctly beyond what it takes to get Windows up and running on the machine, which doesn't correspond 1:1 to whether or not they've implemented the standard correctly.

Re:ACPI

[runderwo]

It is worthless to support a standard that nobody implements.

You're out of your mind. Using your logic, there is no value in supporting any new standard, because at that point nobody has implemented it yet.

ACPI is a usable and solid platform; unfortunately it just so happens that the only vendor who embraced it from the very beginning has done a bang-up job of, well, banging it up. Netscape did a great job pissing all over HTML in the old days, and Microsoft followed them by pissing all over DOM and CSS. Does this mean that nobody should bother doing things the right way? How is progress made if everyone just follows the leader?

The linux ACPI project needs to figure out how Windows manages to work reliably and emulate that

<sarcasm>Sure, because reverse engineering a binary-only operating system is obviously the most efficient way for people interested in ACPI to spend their time.</sarcasm>

Anyway, this isn't an issue of "reliability". With few exceptions, the ACPI code works fine if your machine isn't broken. I run at least 10 desktop systems in ACPI mode and never have any ACPI-related trouble.

Re:ACPI

[808140]

Certification is a load of crap. Standards provide a clearly written definition of how something is supposed to work; if an implementation doesn't work the way the standard outlines it, it is by definition buggy. We don't need certifiers to "look it over" for us; they're just humans anyway and in an open source project we have many more eyeballs than they do. Witness how POSIX compliant the Linux kernel is, despite having never been certified.

Certification is a marketing thing, really. An appeal to authority (ie, standards org says we comply, and since you trust them, you can trust us!)

As for just "doing what Windows does", this is a very bad idea, for a number of reasons. First and foremost is that if we accept this, we'll always be playing catchup to MS's latest bug. Everytime they release a new ACPI parser, it's gonna have some new quirk in it -- they'll probably start doing it on purpose once they realize we're trying to emulate them.

No, far better to get the OEM manufacturers on the standards boat. They claim to comply with a published standard; we can use this against them when they obviously don't. It would be bad form for them to claim to comply when they don't -- in the US, this is even illegal (false advertising), and as such a lot of them are willing to fix their bugs if we just report them. Since they mostly only test with Windows, I'll wager, they may honestly not even be aware of them.

Linux is becoming more and more important, believe it or not. People might not run it on the desktop much, but they run it on servers, and they want stuff to just work. It's becoming stupider and stupider for OEM manufacturers to break compatibility with Linux, because if word gets out that their hardware won't run Linux or runs it poorly, they'll get bad press. This is why they care.

We're past the point (really) of chasing MS's coattails. Most small web companies are using low end PC-compats running Linux, not dual Xeons running Win Server 2k3. We don't need to be the world's main desktop OS to matter.

We're already very important.

Isn't a compatibility list better?

[Kiyooka]

That way, you can be assured that, if it's listed, it works.

With an incompatibility list, you don't know whether some obscure hardware actually works, or whether nobody's bothered testing it yet. Even if they have tested it, hundreds more will have to test it again because, again, it still won't be on the list, so they don't know whether it's been tested or just forgotten.

Re:Isn't a compatibility list better?

[cant_get_a_good_nick]

Two different purposes. If I'm going out and buying a new system I check the compatibility list, and ignore this. If I have a flakey install, and I'm not sure if it's my mistake or just a bad driver, I can check this.

Also, it serves as a central point for advocacy, let everyone who has an issue with one of these products collect and aggregate themselves to complain to manufacturer.

Re:Dead

[Zocalo]

I submit my #9 Imagine128 graphics card, which I never did get to work under RH9, despite it being in the list of supported cards.

That touches on a problem that is probably going to make this project a lame duck. There are far more people out there who will give up or accept a compromise after repeated failures than there are those who keep going until they get things working. I suspect a large number of "x doesn't work" entries are more likely to represent "I couldn't get x to work". Clearly the latter doesn't necessarily mean that the device is incompatible with Linux, although it certainly implies there is room for improvement.

No harm in trying though. ;)

Re:I like that idea!

[Paladine97]

Uh yeah video cards do work on the same plug and play concept. It's called VESA. And it sucks.

You can setup X to work with VESA just fine. Oh wait, you don't know how to do that? I wouldn't call it 'not' compatible just because you don't know how to configure X.

NVidia has some great binary drivers you can use with X. Download them from NVidia.com; an installer is included.

How about not detected and installed?

[silicon not in the v]

Depending on how they define this, it may not be of much use to many non-1337 Linux users. Detectability is what would be a lot more useful. My first experiences trying to install Linux (about last year, so not too long ago) were that my sound card and (S3) video card were not found on install from any distro. From searching the web, I found several places where people would say they had gotten those devices to work, but it involved running some script they wrote, compiling and loading modules, or compiling a custom kernel. I wouldn't really consider that as being very "compatible".

Re:I like that idea!

[Lispy]

I have that very special GeForce 5200 and it rocks with Slackware-Linux. The NVidia Binary Drivers work just fine. If you can't get them to work maybe Linux isn't for you. The installer is really easy compared to other Linux hardware.

The card is not the best one out there but given the real cheap price it is a good value for the money. If you are like me and like to play Neverwinternights or any other 3D game (except maybe for Doom3) that is available for Linux you will have a lot of fun with this card. Most of these, rather old, games are fully supported at very high resolutions with this 50$ card.

I'd recommend it anytime, especially because it's passive (i.e. silent) and can be easily overclocked with nvclock.

Am I the only one?

[jayloden]

Am I the only person in the world who's had almost zero issues with linux and hardware? With the exception two wireless cards that had proprietary chipsets, I have had zero issues with linux and hardware. I've used Slackware 10, mandrake 9.2 and 10.0, Suse 9.1 pro, College Linux, RedHat 7.3, Slax, Knoppix, morphix, -lost count of the rest of them- on computers ranging from PII AOpen computers to my AMD64 desktop to my Dell Inspiron laptop.

Actually, I'll amend that, I haven't gotten any of the modems to work (never tried, not counting dial-up access among my needs).

When I did run into my first issue, with supporting a wireless card running a TI proprietary chipset(meant to double 802.11b to 22mbps ONLY with SMC hardware), I went online and purchased a cheap Netgear card that has proceeded to work on every single distro I've tried without even having to configure it, it just worked.

People complain about linux hardware support, but I do a heck of a lot less work after installing linux than I do installing Windows drivers after a reformat.

Maybe I'm lucky **shrugs**

The Kodak DX4530 *IS* supported...

[Spoing]

Take a look here.

Most digital cameras these days support both of these protocols;

1. USB mass storage
2. Picture Transfer Protocol (PTP)

The Kodak is probably one of them. If it is using another mode, or if one of them does not work well enough (typically PTP), switching to the other mode will fix the problem. This is a camera setting, not an OS setting.

This means; no special software for each specific camera. All PTP camera-aware tools work the same. All mass storage cameras work just like flash storage drives.

In addition, most distributions support linking known USB cameras to the /camera or /mnt/camera mount point automatically; plug it in and a camera shows up.

Re:The Kodak DX4530 *IS* supported...

[adrianbaugh]

I overjoyed when, having bought a Fujifilm camera, I realized I could justify having /mnt/fuji on my system. Oh well, little things please little minds I suppose... ;-)

Re:The Kodak DX4530 *IS* supported...

[Spoing]

Gphoto is a library and does not require X. Early versions did have a GUI, though mostly as a practical demonstration.

Additionally, if the camera has USB mass storage support, and you can use a USB thumb drive, you can plug in your camera. Check the camera documentation for how to enable this mode.

Re:The Kodak DX4530 *IS* supported...

[shadowbearer]

LOL, I had the same kind of, um, epiphany when I bought my Fujifilm S3000 last winter :) /mnt/fuji just seemed so... intuitive :D

Been damned happy with that camera. Having one that mounts as a usb storage device can also be really handy, I use it's ability to connect to a TV/VCR to upload images to it and record them to VCR so I can send them to my internet-impaired relatives :)

Cheers,
SB

They need another list.....

[JohnTheFisherman]

...of hardware that has released open source drivers several years ago and *still* doesn't work reliably in Linux. Take the Soundblaster, for example - a very common item, that still doesn't work a lot of the time, across multiple (all major ones, certainly) distributions. I duplicated this time and time again with my Soundblaster Live! card. IIRC, Fedora Core 2 and Mandrake 10 Official finally started working again, but I gave up on them after the myriad of other problems I had (none of which were driver-related). See the Linux's Achilles Heel article and the follow up.

Re:They need another list.....

[kinko]

I don't think that's the purpose of this list. The linux kernel (both 2.4 series and 2.6 series) have supported both SB16 and SBLive for *years*.

If your distribution doesn't automatically work out the correct settings for the hardware, then that's not the kernel support's fault. I think this list is for hardware that can not be made to work on linux using open-source drivers.

Having said that, ISA cards can be fiddly to get going cos you need to fiddle around with irq and ioports settings, or get the bios and kernel working is isa-plug-and-pray.

Re:They need another list.....

[JohnTheFisherman]

True, but the gripe as stated in the story summary is often that the hardware vendors haven't released drivers or specs, and that isn't always the reason the parts don't work. Creative released open source drivers, and while it certainly has (from time to time) worked, and works fine out of the box for *some* people, it has consistently been an issue for me and several other people. Mine was PCI, and I tried it (several SB Lives through work and home) with several mobos, and hardly ever had a good configuration out of the box. Sometimes I got it working, but a lot of the time, I just gave up, and waited for the next release or another distro to hopefully fix the problem.

The typical caveats: I've always used good quality hardware, I've tried Intel/AMD and several mobos, almost always the same result: no/bad sound. I can't seem to ever convince a lot of people here that the issue is real, and they instead attack me or blame the hardware, which (yikes!) works fine in Windows. As evidenced by the Achilles Heel articles and replies from other people, I'm not alone.

It would also probably be easier to convince manufacturers to release more information if they knew it would be well cared for and not make them look dumb, since a lot of people aren't going to understand why a card doesn't work and just return it to the store saying it's broken. The SBLive! driver sets a bad precedent for this.

Re:They need another list.....

[Drakon]

I don't think anyone was blaming the hardware.
The hardware is probably fine. The user or the distribution are much more likely to be at fault.
Occasionally I compile a kernel that breaks support for a previously working piece of hardware, but at that point I can regress to my previous kernel or recompile the kernel with correct options.
I believe in 2.6.7 my SBLive didn't work when the driver wasn't a module but that was more likely my fault.

Free Software incompat. list more appropriate

[paulproteus]

What's more interesting than a "Linux" incompatibility is a Free Software incompatibility list. When users trade their freedom for convenience in using the non-free NVIDIA drivers, they fall into the same trap as a Windows user: they're trading their ability to share and comment on others' work. In the case of NVIDIA, we've seen the problems the lack of freedom have caused - there are technical users who would be happy to fix bugs or add features, but they are simply not allowed to.

What matters is a list of hardware compatible with the freedom so fundamental to the development of Linux and other Free Software packages. Hardware developers should take note and distribute specifications to encourage free software drivers - and it's great for the bottom line because it all happens at no cost to them.

(I would have checked what the site had to say about these issues if only their database server was working. I do plan to contact them as well, because I recognize that a comment on Slashdot is not enough to change the world. ;-)

How much compatibility do you want?

[iabervon]

There are a lot of devices which aren't supported but don't need specific support. For example, most digital cameras aren't supported, but they act as USB storage devices, so you don't need anything special for them. I'm happily using an nVidia card at home with free drivers, and it works fine for 2D stuff, which is all I've tried doing. Devices often have extra features which aren't supported under Linux but which aren't necessarily good ideas anyway.

Mirror

[throbbingbrain.com]

www.compaq.com

we need this

[Wouter Van Hemel]

Last week I had to return 3 webcams from 2 manufacturers. No support for linux at all; or even worse, a flat out refusal to release any form of specifics. I think it's outrageous.

We need this list. Maybe not for the most common hardware, but there is a lot of stuff out there that has no driver support for Linux (and other opensource OSes) at all. I rather know in advance there is no way of getting it to work, or when there is only an incomplete 'experimental driver' made from sniffing usb devices.

And then we could also reward companies that do make opensource-friendly products and drivers by buying their products, which hopefully has an impact on the other, windows-oriented companies.

"Or even better"

[Dwonis]

Publishing specifications is far more useful than publishing drivers. Unless, of course, you don't care to see any improvement in open-source technology.

Hardware needs drivers

[devinjones]

Hardware for MS Windows 'just works' because there is a Windows compatibilty test lab that hardware manufacturers use to prove that their binary drivers are compatible with Windows. If they don't pass the tests, they don't get to use the Windows logo.

It is up to the hardware vendors to make sure their drivers are compatible with the linux kernel. If the vendors don't see a market need for Linux drivers, they wont spend the time & money to create them. Without drivers, the market stays small.

The easiest way for vendors to get and maintain Linux drivers is to release the specs or source code to the kernel developers and let them maintain it! But vendors are nervous about competitors learning secrets from the driver code about the internals of the hardware, so often they dont.

The rest of the problem is handled by Project Utopia

Project Utopia is really an umbrella project of a bunch of smaller open-source projects. Included are the 2.6 Linux kernel, udev, HAL, and other policy pieces like gnome-volume-manager. From the end-user perspective, the idea here is plug-and-play in the non-techinical sense. When you plug in a piece of hardware, it should Just Work.

haha..

[destiney]

So much for all those postgres zealots screaming about how it handles load sooooo well..

Connection to database failed
could not connect to server: Connection refused
Is the server running on host localhost and accepting
TCP/IP connections on port 5432?

while executing
"pg_connect -conninfo $conninfo"
(procedure "DBOpenHost" line 5)
invoked from within
"DBOpenHost [config db_host] [config db_user] [config db_pass] [config db_db]"
(procedure "DBOpen" line 2)
invoked from within
"DBOpen"
(procedure "DBRawQuery" line 3)
invoked from within
"DBRawQuery $query"
(procedure "DBQuery" line 7)
invoked from within
"DBQuery "SELECT id FROM yakuwiki_page WHERE id='%s'" $id"
(procedure "checkPageId" line 2)
invoked from within
"checkPageId $id"
(procedure "show" line 4)
invoked from within
"show $page"
("show" arm line 1)
invoked from within
"switch -- $op {
show {show $page}
edit {edit $page}
update {update $page}
history {history $page}
diff {pagediff $page $rev}
upload {wikiupload ..."
(procedure "main" line 13)
invoked from within
"main"
("uplevel" body line 1)
invoked from within
"uplevel main"

Oh come on..

[leathered]

The reason why DRI drivers work so well is because ATI didn't write them. But as you should know DRI only supports older cards such as your 9200. If you own a card that is only a little newer, then you are forced to use ATI's proprietry drivers. These, as everyone seems to know except yourself, suck ass. My 9600Pro gets a least 30% less fps in games than in Windows, not to mention the numerous glitches I encounter.

If you run Linux, you run Nvidia, it's as simple as that.

Re:Oh come on..

[MartinG]

I know about 20 linux users. Probably two of them use nvidia hardware.

For some of us, free software matters and closed drivers are not an options. For some others, closed drivers are okay, but not much good when you're on ppc and the drivers are x86 only.

one caveat

[perlchild]

I have a suggestion, if you're going to encourage people to make binary-only drivers, make a list of GOOD ones too.
Some of those binary-only drivers attempt to lock you onto specific kernel versions, otherwise refuse to work in normal usability conditions or cause otherwise troublesome behaviour. I also know at least once "hardware compatiblity list" where hardware is listed as compatible, even if it doesn't perform the function you bought the hardware in the first place, provided it doesn't crash the system. Now normally this wouldn't be a problem, but the storage controller in question performs as an ide controller "without its special storage magic". People see the device name on the compatibility and expect the magic and expect it to work with the full magic, yet it's not "compatible".

If we are going to pressure people into making things, let's make sure they make "good" things.

Re:The Kodak DX4530 *IS* supported... Canon

[davidsyes]

Imagine the Jesuit geeks mounting canon... /mnt/canon

and realizing they've got a blessed machine...

it's been "canon"ized.

DOH!

Hahaha, open drivers

[TwistedSpring]

Many hardware manufacturers will simply not provide open source drivers for their products, mainly for marketing reasons. Imagine you're a video card manufacturer. You realise people are overclocking your previous line of cards instead of buying the new faster range of cards. So you try to disable overclocking in the driver (presumably by making the driver reclock the card to the correct frequencies, thus undoing the work of any overclocking software). If you release open source drivers, it'd be pretty easy for hacked drivers to be released that allow people to overclock, even though you dont want them to.

I think the precise reason that OEMs are releasing closed source drivers for Linux is so that they can get in before someone tries to reverse engineer their hardware and pass off some shoddy drivers that cast their hardware or their development team in a bad light. They want to be sure that people use the original drivers for Linux that they support, not some crazy third party ones. They certainly do not want support requests about drivers that they didn't even develop. Releasing open source drivers creates a lot of questions. How do you distribute the drivers? If someone out there fixes bugs in your driver, what's the procedure for implementing these fixes into the main distribution? What legal rights does anyone who adds fixes to the driver have if their fixes are implemented into the main distribution? Do you pay them or do you just thank them? Will you lay off your own developers once you notice that the community is developing the drivers and not you? Will you become lethargic in your testing of new drivers when you realise that you can release shoddy open source code quickly, and the community will fix it for you?

From an OEM's perspective, open sourcing drivers is a pain in the ass. It sounds like it'd make the development team feel less secure in their jobs (if there's a bunch of people out there that will do their job for free, why are they still employed?) and less determined to write good code when they can pass the buck to an external community.

You hit a serious problem when you're a professional company earning money from selling hardware, and then outsource one sector of your company to the community. People like Intel have done this, but have dissociated the Intel brand from the open source project as much as possible and turned it into a kind of "novelty" project like "this is what our guys work on when they go home in the evening!". I think that to a lot of companies, open source is merely a device used to improve the company image, to make them seem more forward thinking and relaxed, and get them some damn good press and the lifelong devotion of a great deal of short-sighted nerds ("These guys make things open source, so I'll buy their products because I support open source, even though they're moneygrabbing assholes in everything else that they do").

The only drivers regular profit-making companies can support are closed source drivers developed in-house. As soon as you implement the code of other people or allow some random guy you don't know access to your CVS to do a few check-ins, you cannot claim to offer any support for the product whatsoever, because people who have worked on it are not your employees and you are not responsible for anything they do, and are consequently no longer responsible for work done on your own driver, which you would like to be able to legally own, support, endorse and distribute with your product as your own (unless you claim responsibility for all work done on the driver by third parties, which would be incredibly foolish). There are also various laws concerning how companies can may make use of contributions from third parties, and what rights anyone who contributes to a company has. Laws concerning competition may also apply here - once the community develops your driver and effectively does work for free that you'd normally pay people to do, isn't that a seriously unfair advantage? Can you give an example of any company that ha

Re:Hahaha, open drivers

[foonf]

You realise people are overclocking your previous line of cards instead of buying the new faster range of cards. So you try to disable overclocking in the driver (presumably by making the driver reclock the card to the correct frequencies, thus undoing the work of any overclocking software). If you release open source drivers, it'd be pretty easy for hacked drivers to be released that allow people to overclock, even though you dont want them to.

The number of people who overclock their hardware is probably far below even the number of linux users at this point. I have never seen any evidence it has impacted sales of high-end products. The main concern CPU manufacturers have with overclocking is remarking, where an overclockable slower chip is relabled by a third party as a faster chip and then resold. That is both illegal and damaging to the company's reputation (because the remarked chips are going to be, on average, less reliable) so they take measures to prevent it. Thats not a problem with video cards since the only practical means to overclock them is via software.

I think the precise reason that OEMs are releasing closed source drivers for Linux is so that they can get in before someone tries to reverse engineer their hardware and pass off some shoddy drivers that cast their hardware or their development team in a bad light.

This is partly true, but it also represents a valid response to customer demand: They have customers who want to use their products under Linux, and they are providing semi-official drivers in the only legal way they can (see below).

The only drivers regular profit-making companies can support are closed source drivers developed in-house. As soon as you implement the code of other people or allow some random guy you don't know access to your CVS to do a few check-ins, you cannot claim to offer any support for the product whatsoever, because people who have worked on it are not your employees and you are not responsible for anything they do, and are consequently no longer responsible for work done on your own driver, which you would like to be able to legally own, support, endorse and distribute with your product as your own

This isn't a big deal really. You can require third parties to contribute code under a license giving you either outright ownership or very broad redistribution rights, and carefully control outside code contributions (see Mozilla, OpenOffice, etc.); there is no reason that model can't be applied to drivers. There are two other main reason that drivers are not released as open-source: First, often times the driver contains source code which the manufacturer licensed from a third party and has no right to redistribute (this is the case with NVIDIA). Second, the driver can contain some highly proprietary intellectual property, possibly representing most of the value of the product (this is the case with most software modems). There is no way around the first case unless the manufacturer wants to completely rewrite their existing driver, and no way at all around the second.

What is most discouraging, generally, is not that hardware companies don't open-source their drivers; the driver is the hardware company's property and if they don't want to port it to Linux or release source for it, that is their right. The problem is when vendors won't even release specifications to their hardware to open-source developers. There are people who are willing to sign all sorts of restrictive NDAs to get access to specifications and write open-source drivers for hardware; a hardware company does not have to release the full specifications to be released to the public, only allow the final driver to be released as open source. In the past this was how most drivers for Linux were written, but, especially graphics card companies, are providing much less access than they were 5 years ago, even as more companies are paying lip service to Linux support.

Of course it's not there

[DavidNWelton]

Because I just created the site a few days ago. It should not be on slashdot.

I hope it will work, because people will add their hardware there, and it will show up with google. I also plan to add things myself as I see them.

If you want a more informative article than slashdot, look at kerneltrap, where I made the mistake of linking to the thing in a comment:-/

http://kerneltrap.org/node/view/3695

Start an alternate area for Cisco/Linksys

[Anonymous Coward]

I've been complaining to Linksys and now Cisco, over their routers. Wired, befsr41, vpn 2 client, vpn multi, and other versions. According to them, you need windows to upgrade their firmware.

So when a vulnerability comes out (there are vulnerabilities for the model above, and other versions), I, and other users with Linux only or mixed Linux/Mac have to shut down a computer temporarily, install an old version of Windows (98), patch the router, then overwrite the install with Linux again so I can herd the computer back into the flock, and back into production.

If Cisco/Linksys can put in permanent, non-removable back doors into their routers for the spooks, then they can at least give a little more than a rat's ass of help to their customers. Their consideration for their customers (or lack thereof) shows in the sudden dropoff of firmware fixes/revisions after Cisco bought out Linksys. They went from monthly more frequent fixes and releases, to many months/close to a year between.

Won't matter much for me, since I currently have some test boxes where I'm giving myself a severe lesson in iptables, combined with sarge getting attention from the security team now, and sarge about to enter stable so I can auto update nightly, so I won't need the Linksys boxes for anymore. Iptables will take care of the firewalling, and up-to-date packages and minimal services (and some other "hardening") will take care of the other end.

So I won't need your routers anymore, Linksys/Cisco, solely because of your lack of respect for your non-windows on every lan clients. Had you enabled Linux users to patch the routers, and made the info known on your web site where it is easy to see, I would have stuck with your routers, rather than use Linux for filtering and nat. I'd prefer to use the 8w-14w (iirc) routers you sell, rather than the 90w+ of the upcoming AMD processors at idle (don't even mention Intel which is close to double at any point). In the long term, the nat appliances come out ahead in electrical consumption costs, but those stats are pissed on by the fact that one has to keep a windows computer running or on hand, just to patch a Linksys/Cisco router.

Linux is arguably #2 in server revenue now, with a 50%+ growth rate (not counting free downloads). So if not this year, then next year. And in lans, there are a high percentage of Linux desktops that it is inexcusable for Linksys/Cisco to fail to provide a solution to non-windows users for patching your routers.

All the executable appears to be/do is to upload the firmware, telnet style, to the router, similar to telnetting into a zyxel router (much higher quality btw) and get/putting the firmware. Except it is shrouded and covered as an executable that only runs on windows according to your website.

Stop the bullshit Cisco/Linksys. Support the clients that purchase your products. All of them. Post the info, issue a patch if necessary to enable Linux firmware upgrades, do whatever has to be done, and get it over with.

If HP can get their multi-function printers to support Linux, then you can get your firmware updates to work with more than just windows.

Re:Start an alternate area for Cisco/Linksys

[Trejkaz]

You know what, though, the Linksys router I bought allowed you to upgrade the firmware via the web interface. And via TFTP from Linux, too. Maybe you just bought the wrong router. ;-)

No they shouldn't

[Anonymous Coward]

Wikipedia is an encyclopedia not a Hardware guide. Expect it to end up on Votes for deletion soon.

And another thing, Slashdotters are abusing Wikipedia as a tool in nerd erotica in general, just look around. There is going to be some REAL cracking down soon.

Re:Desktop Linux: it's free if your time is worthl

[Gigantic1]

>>>>>>>

Compared to Linux? Hardly anything.

Hey...my life, and work, is not centered on being a computer geek: I need something that works and is compatible. Linux just doesn't cut it on the compatibility side.

See...with Linux on the Desktop, it always something, isn't it? I mean, something that prevents you from hooking up that Digital Camera, enjoying that Sound Card or getting the Video Card to work at it's spec'd resolutions.

And...worst yet, the dearth of decent Linux applications is areal "Pain in the Arse". Sure...there's lot's of free Apps out there for Linux - they just also happen to be buggy, clunky and have poor user interfaces.

Like I said: Desktop Linux is free if your time is worthless.

Black or White should not be exclusive

[POPE Mad Mitch]

Sites like this which only list what doesnt work, and other such sites that only list what does work, all suffer from the same problem: you cant distinguish unknown from does/doesnt work.

The printer people (linuxprinting.org) have the right idea, the site lists every printer thats known, and wether it does, or doesnt work, how well, and why.

This way you can more easily tell the difference between 'my device is too new, nobodies tried yet' and 'the manufacturers a pest, itll never work' and the more common 'theres half a driver that mostly works, give it a go or wait a bit'

If the same philosophy was applied to all devices it would be a really useful resource