Slashdot Mirror
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."
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
Hardware makers could develop modules
:-)
Ain't this what we usually call drivers or am I misunderstanding your idea?
Because right now the problem isn't really (or only) that we do not have proper gui to support hardware (or should I say to support users) but really that not all hardware have linux drivers.
Your idea sounds ok, but when you say "Their drivers are just modules in this control center." you forget that this is only the visual part of the story. On the other part, the system need to know how to talk to said hardware, what feature it can use etc etc, and this is really what a driver do.
For example, there is many sound card out there, but everyone of them has different set of features. In order to be able to use my Audiophile 2496 I need and interface (a driver) which will "route" my date thru it and let me access its fonctionality.
I think that a universal control center may be a nice thing to have in the future, maybe not, but for now I would really like to just have drivers for all the hardware I have.
Sorry if this sounded pedantic, I don't know how much you already know about all this!
I'd rather be sailing...
No one knows, because there are umpteen different chipsets used in the DWL650 line. Early DWL650+ units had a prism2 chips, but later ones do not.
D-Link as the prime adherent of the business practice known as "reusing model numbers to confuse the customer". You have carefully examine the serial number to know for sure just what particular card you have. I had three DWL650 cards a month ago that had identical boxes, identical labels, and identical prices, but with three different chipsets. The only indication of the differences was a single letter on the serial number sticker.
Netgear isn't much better, though they do have the civility to mark the version number on the box. Of course, they still won't tell you what version number you'll get if you order online...
I've given up on wifi and am boycotting the entire technology until the manufacturers stop screwing over the customer. Even Windows users should be outraged, because they can't updgrade their drivers or firmware, because they will not know exactly what card they have.
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.
ACPI is an open standard, but unfortunately, vendors' closed source BIOS implementations for the last few years are written against the Microsoft ACPI parser, bugs and all. Consequently, many machines fail to work at all with the Linux implementation (written against the standard) unless kludges or more relaxed syntax checking are used. This is not a failing of the Linux ACPI implementation or the ACPI specification. It is a Windows interoperability issue.
It is unknown how many machines have bugs in their ACPI BIOS code. The only way the ACPI developers find these and special-case them is when users mail in their bug reports and DSDT (check here), because the developers don't have access to every machine on earth to perform testing on. Even when a bug is found, it can only be worked around, because most system BIOS in the field are no longer supported by the respective vendors. So you'll see messages from the ACPI layer regarding syntax errors or known bugs in a particular BIOS, which the developers are helpless to fix in any way other than a special-casing.
Even worse is that many ACPI BIOSes return different values depending on which OS the vendor's ACPI code thinks you're running. Most of the time, any BIOS code path other than for an OS which calls itself "WindowsNT" is broken, so AFAIK, all ACPI layers simply spoof themselves as "WindowsNT" to the BIOS to avoid problems. Rather sad, isn't it?
As a final note, some vendors like Tyan, HP, Intel, etc are extremely active on the ACPI and LinuxBIOS mailing lists. HP has fixed ACPI-related bugs in their system BIOSes due to the Linux ACPI code rooting them out.
So the moral of the story is, don't assume poor ACPI operation on a specific machine is the fault of the Linux ACPI project. More often than not, it's the fault of the BIOS vendor not caring to implement the standard correctly beyond what it takes to get Windows up and running on the machine, which doesn't correspond 1:1 to whether or not they've implemented the standard correctly.
LRC, the best-read libertarian site on the web
Ha ha...
It's not IIS, it is of course, Apache with Rivet. We were in the middle of some work on the server, and as I commented elsewhere, I *just* created this and am still tweaking the software. It's still at the stage where I'm doing research for hardware to put in myself in order to make it a useful resource.
Neither the list, nor the server, nor anything else was ready to be published on slashdot, or anywhere else high-traffic for that matter. I guess I shouldn't have linked it on kerneltrap, but it was handling the traffic there no problem.
In any case, you can read more about the idea, and some other people's comments on it at here, which also has a link to the thread on the kernel mailing list:
http://kerneltrap.org/node/view/3695
http://www.welton.it/davidw/