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

*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*

[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*

[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*

[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*

[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*

[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

it does not serve

[Anonymous Coward]

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

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

[Anonymous Coward]

Not completely useless:

Hmm...this DWL650+ is on sale, I wonder if it's a good deal. Hey, it's on the incompatible list, I think I'll pass.

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.

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

[Anonymous Coward]

Agreed.. The sooner the linux acpi project stops bitching that its MS and/or the BIOS vendors fault that ACPI doesnt work correctly the better. As has ben posted, ACPI works fine under XP, so as a consumer, I would expect the same under linux without any issues.

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.

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:My idea

[Anonymous Coward]

get coding!

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:My idea

[mcrbids]

Your idea brings me to my #1 axe to grind with Linux - no support for Binary drivers.

If there was a standard interface for drivers, vendors could be free to distribute drivers for *nix without giving away their "Secret sauce" to the OSS developers.

Alas, Linus is opposed to doing this for philosophical reasons, resulting in the horrible cludges that are available in order to remedy a problem that the kernel guys just don't want to address, but really should.

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

Is this the right idea

[Anonymous Coward]

It seems that when a driver is finally made then that hardware will have to be removed from the list which will make a huge hassle. I think compatibilty makes more sense here.

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.

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.

Re:Video cards

[Anonymous Coward]

Nowadays the only video cards that matter are nvidia or ATI

Yah, maybe if you're a gamer or have new hardware. Even on new budget hardware, you won't be getting those kinds of cards. Linux is used quite a bit on older hardware or budget hardware.

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

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

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.

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

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.

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.

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