The Linux Incompatibility List 422
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."
Wow, looks like they'll need new hardware (Score:4, Funny)
Re:Wow, looks like they'll need new hardware (Score:2, Funny)
Re:Wow, looks like they'll need new hardware (Score:4, Funny)
Re:Wow, looks like they'll need new hardware (Score:5, Funny)
Re:Wow, looks like they'll need new hardware (Score:3, Funny)
Re:Wow, looks like they'll need new hardware (Score:5, Informative)
It's not IIS, it is of course, Apache with Rivet [apache.org]. 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 (Score:5, Interesting)
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 (Score:5, Interesting)
Old newsgroup posting... [google.com]
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 (Score:3, Insightful)
Re:Wow, looks like they'll need new hardware (Score:3, Informative)
The list is empty since I couldn't get to the original server. So, as time permits...
No they shouldn't (Score:3, Informative)
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:Wow, looks like they'll need new hardware (Score:4, Insightful)
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 (Score:3, Funny)
Difficult to maintain? (Score:4, Interesting)
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? (Score:2)
Re:Difficult to maintain? (Score:5, Interesting)
They need another list..... (Score:4, Insightful)
Re:They need another list..... (Score:3, Insightful)
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
Re:They need another list..... (Score:3, Insightful)
Re:They need another list..... (Score:3, Interesting)
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.
The Kodak DX4530 *IS* supported... (Score:5, Informative)
Most digital cameras these days support both of these protocols [teaser.fr];
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... (Score:5, Funny)
Re:The Kodak DX4530 *IS* supported... (Score:3, Funny)
LOL, I had the same kind of, um, epiphany when I bought my Fujifilm S3000 last winter
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
Re:The Kodak DX4530 *IS* supported... (Score:4, Informative)
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:Difficult to maintain? (Score:3, Insightful)
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
Re:Difficult to maintain? (Score:5, Funny)
Also missing from the list: Women.
Re:Difficult to maintain? (Score:3, Funny)
Or maybe around here it would be a +1 Sexist? Wink wink, nudge nudge...
Re:Difficult to maintain? (Score:3, Funny)
Video cards (Score:5, Funny)
Re:Video cards (Score:5, Interesting)
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 (Score:3, Interesting)
Re:Video cards (Score:5, Funny)
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.
Oh come on.. (Score:4, Interesting)
If you run Linux, you run Nvidia, it's as simple as that.
Re:Oh come on.. (Score:3, Insightful)
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.
Re:Video cards (Score:3, Interesting)
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
Re:Video cards (Score:3, Interesting)
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 (Score:4, Informative)
clicky [leenooks.com]
Re:no no no (Score:3, Funny)
yes yes yes (Score:2, Informative)
Incompatibility #1 (Score:2, Funny)
List of Hardware with Linux Problems (Score:4, Funny)
Vendor: *
That was easy...
Re:List of Hardware with Linux Problems (Score:3, Insightful)
By which time someoen most likely reverse engineered the thing and made a linux driver anyway..
*raises hand* (Score:3, Insightful)
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* (Score:5, Informative)
Ask nVidia, VMware, and.. what's that modem with binary Linux drivers, can't remember.
Re:*raises hand* (Score:3, Informative)
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* (Score:5, Insightful)
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* (Score:5, Interesting)
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* (Score:3, Insightful)
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
Re:*raises hand* (Score:3, Interesting)
Re:*raises hand* (Score:3, Funny)
Re:*raises hand* (Score:5, Interesting)
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* (Score:3, Insightful)
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 squeezin
Re:*raises hand* (Score:3, Insightful)
Re:*raises hand* (Score:3, Informative)
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 [sf.net]. 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 tec
Re:*raises hand* (Score:4, Informative)
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* (Score:5, Insightful)
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* (Score:3, Insightful)
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
Re:*raises hand* (Score:3, Insightful)
Re:*raises hand* (Score:3, Interesting)
Linux Incompatibility (Score:2, Funny)
Slashdot compatibility (Score:3, Funny)
it does not serve (Score:2, Insightful)
My idea (Score:5, Interesting)
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 (Score:5, Informative)
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 (Score:4, Informative)
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.
Re:My idea (Score:5, Interesting)
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 (Score:4, Insightful)
It sounds like what you're after is an operating system that positively encourages binary drivers and is only readily available on x86 [microsoft.com]. And we all know how well that works...
Re:My idea (Score:5, Insightful)
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
Wireless (Score:3)
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... (Score:3, Funny)
.
.
. oh. sorry.
Bad drivers (Score:2, Interesting)
That's easy! (Score:4, Insightful)
Actually later distros have mproved my situation, but I seem to pick the turkeys right off the bat.
This will be useless (Score:5, Insightful)
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 (Score:5, Informative)
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 (Score:3, Interesting)
Re:This will be useless (Score:3, Insightful)
Of course it's not there (Score:3, Informative)
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
Good idea (Score:5, Interesting)
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 (Score:3, Informative)
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 [sourceforge.net]. 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 (Score:5, Interesting)
Another project on the same website was to find the best(!) linux distrubution in a wiki - you can see the result here [schottelius.org]. 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 (Score:5, Insightful)
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 (Score:3, Insightful)
Re:ACPI (Score:5, Informative)
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 [sourceforge.net]), 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 (Score:3)
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.
How about not detected and installed? (Score:3, Insightful)
Free Software incompat. list more appropriate (Score:3)
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? (Score:4, Insightful)
Mirror (Score:5, Funny)
www.compaq.com [compaq.com]
we need this (Score:5, Insightful)
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" (Score:3, Insightful)
haha.. (Score:3, Funny)
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"
one caveat (Score:3, Insightful)
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.
Hahaha, open drivers (Score:3, Insightful)
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 (Score:4, Insightful)
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.
Black or White should not be exclusive (Score:4, Insightful)
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
Re:Isn't a compatibility list better? (Score:3, Interesting)
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 (Score:5, Insightful)
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! (Score:4, Interesting)
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.
Re:I like that idea! (Score:4, Informative)
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.
Re:Start an alternate area for Cisco/Linksys (Score:3)