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."
0 comments and it's already /.'d into the ground.
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...
Make life easy - somebody just please copy the entire list of video cards from Epinions or Cnet.
What's your damage, Heather?
Device: *
:p
Vendor: *
That was easy...
If bad puns were like deli meat, this would be the wurst
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.
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.
Michel
Fedora Project Contribut
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.
-- A cat is no trade for integrity!
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.
-fb Everything not expressly forbidden is now mandatory.
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.
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*
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.
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.
What could possibly go wrong?
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.
Javascript + Nintendo DSi = DSiCade
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. ;)
UNIX? They're not even circumcised! Savages!
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.
Don't blame me, I didn't vote for either of them!
Most digital cameras these days support both of these protocols;
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.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
www.compaq.com
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.
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.
For all intensive porpoises your a bunch of rediculous loosers
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