Linux Incompatibility List
Hi,
I'm reviving an idea I implemented several years ago, namely the Linux Incompatibility List.
The idea is simple: most hardware works fine with Linux, and the situation is generally pretty good, with Linux increasingly showing up on the corporate radar.
However, there are devices that don't work with Linux, for various reasons (no specs, too new and no one has written a driver, etc...), and it's easier to keep track of those devices so that people can avoid them (or the hero types can write drivers for them).
I have a site up that will serve as the focus of these efforts, but in order to guage interest/response and ramp up gradually, I'd like to ask that those interested in participating in the effort send me information via email. I'll respond with the wiki's address, so that they may then have a look around.
I think (correct me if I'm wrong) the information we would want to collect is:
Product Name:
Manufacturer:
Model Number:
Chipset:
How bad it is (1 to 10, 9 being it almost works and has only minor bugs):
Reason (no specs, driver still being worked on, ...):
Url for more info:
An email address of yours that we may publish (so that we can contact you if someone says "no, that works just fine!"):
Notes:
Ideas/comments/suggestions are welcome at this stage.
Thankyou for your time,
Signature · 5 lines
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/Quoted 2 lines
From David N. Welton on Saturday, 21 August, 2004:
Ideas/comments/suggestions are welcome at this stage.
Sounds interesting; is there a vendor blacklist (i.e. vendors that are
either hostile toward or simply don't care about Linux and their products just won't ever work with Linux?)
Signature · 2 lines
Joseph===============================================trelane@digitasaru.net
Graduate Student in Physics, Freelance Free Software DeveloperQuoted 5 lines
Quoted 1 line
Ideas/comments/suggestions are welcome at this stage.
Sounds interesting; is there a vendor blacklist (i.e. vendors that are
either hostile toward or simply don't care about Linux and their products just won't ever work with Linux?)
Broadcom's wireless chips come to mind...
Signature · 1 line
Lab tests show that use of micro$oft causes cancer in lab animals
Quoted 7 lines · Wakko Warner
Quoted 5 lines
Quoted 1 line
Ideas/comments/suggestions are welcome at this stage.
Sounds interesting; is there a vendor blacklist (i.e. vendors that are
either hostile toward or simply don't care about Linux and their products just won't ever work with Linux?)Broadcom's wireless chips come to mind...
Nvidia. AFAIK all nvidia Linux drivers are either binary-only or reverse-engineered.
To add insult to injury they have a stupid 20+page 'Nvidia Linux Advantage' whitepaper on their site that conveniently fails to mention the above. They probably spent more money for some marketroid to put that together than they ever spent on actually supporting Linux.
Lee
Quoted 10 lines
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Ideas/comments/suggestions are welcome at this stage.
Sounds interesting; is there a vendor blacklist (i.e. vendors that are
either hostile toward or simply don't care about Linux and their products just won't ever work with Linux?)Broadcom's wireless chips come to mind...
Nvidia. AFAIK all nvidia Linux drivers are either binary-only or reverse-engineered.
True, however, their video cards *DO* work on linux (even though it is binary-only). I have a laptop that has the chip. Does any broadcom wireless chip work on linux (ndis wrapper or that piece of junk from linuxant doesn't count)
Quoted 4 lines
To add insult to injury they have a stupid 20+page 'Nvidia Linux Advantage' whitepaper on their site that conveniently fails to mention the above. They probably spent more money for some marketroid to put that together than they ever spent on actually supporting Linux.
Haven't seen that myself.
Signature · 1 line
Lab tests show that use of micro$oft causes cancer in lab animals
On Sat, 2004-08-21 16:51:57 -0400, Wakko Warner <[email protected]> wrote in message <[email protected]>:
Quoted 7 lines
Quoted 2 lines
Nvidia. AFAIK all nvidia Linux drivers are either binary-only or reverse-engineered.
True, however, their video cards *DO* work on linux (even though it is binary-only). I have a laptop that has the chip. Does any broadcom wireless chip work on linux (ndis wrapper or that piece of junk from linuxant doesn't count)
Right, binary-only drivers and/or GPLed/OSS drivers should be counted separately. Think about AVM's ISDN cards (very popular over here in Germany, but the newer products require a CAPI-only binary-only driver:-(
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 10 lines · Jan-Benedict Glaw
On Sat, 2004-08-21 16:51:57 -0400, Wakko Warner <[email protected]> wrote in message <[email protected]>:
Quoted 7 lines
Quoted 2 lines
Nvidia. AFAIK all nvidia Linux drivers are either binary-only or reverse-engineered.
True, however, their video cards *DO* work on linux (even though it is binary-only). I have a laptop that has the chip. Does any broadcom wireless chip work on linux (ndis wrapper or that piece of junk from linuxant doesn't count)
Quoted 5 lines
Right, binary-only drivers and/or GPLed/OSS drivers should be counted separately. Think about AVM's ISDN cards (very popular over here in Germany, but the newer products require a CAPI-only binary-only driver:-(
Are there still vendors who release 'open source' drivers, but with preprocessed, obfuscated source code? If so then there should be a category for this.
Lee
Quoted 10 lines · Jan-Benedict Glaw
On Sat, 2004-08-21 16:51:57 -0400, Wakko Warner <[email protected]> wrote in message <[email protected]>:
Quoted 7 lines
Quoted 2 lines
Nvidia. AFAIK all nvidia Linux drivers are either binary-only or reverse-engineered.
True, however, their video cards *DO* work on linux (even though it is binary-only). I have a laptop that has the chip. Does any broadcom wireless chip work on linux (ndis wrapper or that piece of junk from linuxant doesn't count)
Quoted 5 lines
Right, binary-only drivers and/or GPLed/OSS drivers should be counted separately. Think about AVM's ISDN cards (very popular over here in Germany, but the newer products require a CAPI-only binary-only driver:-(
Also, it's probably best to focus on new products. Many vendors, VIA for example, are now very Linux friendly, but were not always so in the past, and may not be able to release OSS drivers for older products due to IP issues.
Lee
Salut,
Quoted 4 lines · Jan-Benedict Glaw
Right, binary-only drivers and/or GPLed/OSS drivers should be counted separately. Think about AVM's ISDN cards (very popular over here in Germany, but the newer products require a CAPI-only binary-only driver:-(
Actually I bought a Fritz!Card PCI some days ago in the Mediamarkt Basel and both the mISDN driver and the old i4l driver are working perfectly well. So what?
Tonnerre
Quoting Tonnerre <[email protected]>:
Quoted 3 lines
Actually I bought a Fritz!Card PCI some days ago in the Mediamarkt Basel and both the mISDN driver and the old i4l driver are working perfectly well. So what?
FritzCard DSL works with binary only driver, only.
Signature · 1 line
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
On Sun, 2004-08-22 16:30:09 +0200, Tonnerre <[email protected]> wrote in message <[email protected]>:
Quoted 9 lines · Jan-Benedict Glaw
Quoted 4 lines
Right, binary-only drivers and/or GPLed/OSS drivers should be counted separately. Think about AVM's ISDN cards (very popular over here in Germany, but the newer products require a CAPI-only binary-only driver:-(
Actually I bought a Fritz!Card PCI some days ago in the Mediamarkt Basel and both the mISDN driver and the old i4l driver are working perfectly well. So what?
So you bought one of the old version. The new cards are "Version 2.0" IIRC.
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoting Jan-Benedict Glaw <[email protected]>:
Quoted 6 lines
Quoted 3 lines
Actually I bought a Fritz!Card PCI some days ago in the Mediamarkt Basel and both the mISDN driver and the old i4l driver are working perfectly well. So what?
So you bought one of the old version. The new cards are "Version 2.0" IIRC.
Version 2.0 works perfectly well with the open driver. The v2 driver is a separate driver. But it's in the tree and working for ages.
Signature · 1 line
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
Wakko Warner <[email protected]> :
[...]
Quoted 2 lines
True, however, their video cards *DO* work on linux (even though it is binary-only). I have a laptop that has the chip. Does any broadcom
Mantra: linux is not x86 only.
Btw have you considered discussion with the people behind
http://www.linuxhardware.net/ ?
--
Ueimor
Quoted 4 lines
Quoted 2 lines
True, however, their video cards *DO* work on linux (even though it is binary-only). I have a laptop that has the chip. Does any broadcom
Mantra: linux is not x86 only.
I forgot about that. There's an alpha box sitting next to me =)
Quoted 2 lines
Btw have you considered discussion with the people behind
http://www.linuxhardware.net/ ?
Not sure if I've been there before. I may have.
Signature · 1 line
Lab tests show that use of micro$oft causes cancer in lab animals
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On August 21, 2004 04:51 pm, Wakko Warner wrote:
<snip>
Quoted 3 lines
Does any broadcom
wireless chip work on linux (ndis wrapper or that piece of junk from linuxant doesn't count)
Yeah, their wireless chips work fine on Linux if you are running just about any wireless access point / router that makes use of Broadcom's hardware.
That probably seems like a pointless nitpick, but I think that makes their non-support of Linux on general-purpose hardware even worse. They've already written wireless drivers for Linux, but simply refuse to work with anyone to get their hardware running under Linux for other architectures. They even refuse to simply recompile their driver for i386 and release it binary-only. For that matter, they won't even respond to e-mail on the subject. (The most I've ever got from them was a few engineers responding 'off the record'.)
Even more annoying is the way their Linux/MIPSel binaries are tied to a particular kernel version. (They've got the inlines from skbuff.h scattered all over their module --- at least they did in the driver included with the Linksys WAP54G v. 1.08 which was the one I carefully looked at.) This creates a serious problem for anyone who wants to get their wireless routers / access points to run a different version of the kernel.
They seem to be very selective about when they acknowledge Linux's existence. IMHO, this makes them even worse than a company that has decided to simply ignore Linux all together.
- -- Andrew
-----BEGIN PGP SIGNATURE-----
Comment: Key ID: EC3F6CCD (www.keyserver.net)
iD8DBQFBJ+CNTHKGaOw/bM0RAoGJAJoCJOZTuNayN2jCmzCfSbXAbUhkmgCfdk5G vLETYsG6DBPFZ5jBeq4MGbM=
=r+T+
-----END PGP SIGNATURE-----
Quoted 3 lines · Andrew Miklas
They seem to be very selective about when they acknowledge Linux's existence. IMHO, this makes them even worse than a company that has decided to simply ignore Linux all together.
http://www.scaramanga.co.uk/stuff/bcm94306/
There is at least 1 effort underway to reverse engineer it, although I don't have much time to work on it. IMO It would be good if such companies were consistently shown that we certainly don't need them to write drivers for us and even if they go out of their way, there isn't much they can do to stop us from writing them ourselves.
Signature · 3 lines
// Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On August 22, 2004 11:54 pm, Gianni Tedesco wrote:
<snip>
Quoted 5 lines
There is at least 1 effort underway to reverse engineer it, although I don't have much time to work on it. IMO It would be good if such companies were consistently shown that we certainly don't need them to write drivers for us and even if they go out of their way, there isn't much they can do to stop us from writing them ourselves.
I've been working with a few people to reverse engineer the drivers included with the WAP54G 1.08. We're about 50% done translating them back into C. Once we're done, we plan to study the driver in order to write our own from scratch, or ask someone else to cleanroom it.
However, it's likely that by the time we're done (if ever), the hardware will be supplanted by something else. We've learnt the hard way that reverse engineering a 420K binary, and completing in a reasonable time isn't as easy as it sounds. :) This is especially true when you can't simply make everything public (out of copyright concerns) and do the project in a real open source way.
- -- Andrew
-----BEGIN PGP SIGNATURE-----
Comment: Key ID: EC3F6CCD (www.keyserver.net)
iD8DBQFBLCqyTHKGaOw/bM0RAhsjAKCH6Ftt9gp5raK2PfPEfDoKb8bxPwCeNY7y ilSEs+jG1514W6zz/WGBNQg=
=QrAv
-----END PGP SIGNATURE-----
Quoted 11 lines · Andrew Miklas
I've been working with a few people to reverse engineer the drivers included with the WAP54G 1.08. We're about 50% done translating them back into C. Once we're done, we plan to study the driver in order to write our own from scratch, or ask someone else to cleanroom it.
However, it's likely that by the time we're done (if ever), the hardware will be supplanted by something else. We've learnt the hard way that reverse engineering a 420K binary, and completing in a reasonable time isn't as easy as it sounds. :) This is especially true when you can't simply make everything public (out of copyright concerns) and do the project in a real open source way.
I agreee, reverse engineering machine code is not trivial, especially with the tools currently available. However I don't think that the difficulty is intrinsic. It is possible (though obviously not simple) to wite software that is able to infer a great deal from machine code automatically and produce pretty good decompilations.
Also I think that the pciproxy[0] technique currently offers a simpler solution. Analyzing the data produced is more akin to reverse engineering a network protocol than machine code. Reverse engineering protocols is much less 'copyright sensitive' than decompiling machine code and, I think, more easily shared.
Anyway, perhaps once I've had some time to make a little more progress we would be able to compare some notes?
[0]. I should probably explain the technique. It basically involves running supported operating systems under a PC emulator, and trapping and logging i/o on the PCI bus.
Signature · 3 lines
// Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
Hi,
On August 25, 2004 03:21 am, Gianni Tedesco wrote:
<snip>
Quoted 5 lines
Also I think that the pciproxy[0] technique currently offers a simpler solution. Analyzing the data produced is more akin to reverse engineering a network protocol than machine code. Reverse engineering protocols is much less 'copyright sensitive' than decompiling machine code and, I think, more easily shared.
(Sorry for the long delay...)
Yeah, we tried that at first too (actually, we were using Frank Cornelis' patches to Bochs). The problem with dumping all the PCI activity (even while the interface isn't sending/receiving) is that there is a huge amount of data to sift through. Even capturing for just a for a few seconds generates megabytes of data. You also have to deal with various events (like the watchdog timer) going off at random times and getting mixed in with the send/receive data. We also found DMA a little tricky too (ie. you need to dump out any data that the chip will bus-master to itself to see how it is structured).
Also, we figured it would cause problems for supporting the whole range of devices that can be handled by the wl.o drivers. For example, from looking at the module, we can see that the driver will have somewhat different behaviour according to exactly what MAC and radio chips are present, the interface being used (ie. PCI, cardbus, etc.), the vendor, model number, and revision of the board itself, the contents of the ROM, etc. We decided that there was simply too many combinations to make the data capture approach useful over the entire range of Broadcom hardware, unless you repeat the process on every variation.
Quoted 2 lines
Anyway, perhaps once I've had some time to make a little more progress we would be able to compare some notes?
Sure, let me know when you're ready.
-- Andrew
Quoted 1 line · Andrew Miklas
(Sorry for the long delay...)
Thats OK.
Quoted 9 lines
Yeah, we tried that at first too (actually, we were using Frank Cornelis' patches to Bochs). The problem with dumping all the PCI activity (even while the interface isn't sending/receiving) is that there is a huge amount of data to sift through. Even capturing for just a for a few seconds generates megabytes of data. You also have to deal with various events (like the watchdog timer) going off at random times and getting mixed in with the send/receive data. We also found DMA a little tricky too (ie. you need to dump out any data that the chip will bus-master to itself to see how it is structured).
OK, exactly which drivers were you using to do this? When I had the interface brought up in win2k-server with the bcmwl5.sys driver I was seeing every few hundred milliseconds a batch of say 12 2-byte reads on the register space to check status...
Quoted 9 lines
Also, we figured it would cause problems for supporting the whole range of devices that can be handled by the wl.o drivers. For example, from looking at the module, we can see that the driver will have somewhat different behaviour according to exactly what MAC and radio chips are present, the interface being used (ie. PCI, cardbus, etc.), the vendor, model number, and revision of the board itself, the contents of the ROM, etc. We decided that there was simply too many combinations to make the data capture approach useful over the entire range of Broadcom hardware, unless you repeat the process on every variation.
Hrm, you're sure those variations aren't trivial? Although theres lots of checks, I would have thought they would just be stuff like "card A supports X, Y and Z features"?
The approach that makes the most sense to me is get 1 card working to the point where it sends/receives packets, then look at the binaries to see what the variations are, and how they apply to what cards and just go fill in the blanks...
Quoted 4 lines
Quoted 2 lines
Anyway, perhaps once I've had some time to make a little more progress we would be able to compare some notes?
Sure, let me know when you're ready.
I just need to improve logging support in my pciproxy patch and setup a 2nd machine with a working wireless card, then I can start in earnest.
Also, you mention DMA and sending/receiving packets, exactly how much progress have you made so far?
Signature · 3 lines
// Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
Hi,
On August 28, 2004 11:21 pm, Gianni Tedesco wrote:
<snip>
Quoted 4 lines
OK, exactly which drivers were you using to do this? When I had the interface brought up in win2k-server with the bcmwl5.sys driver I was seeing every few hundred milliseconds a batch of say 12 2-byte reads on the register space to check status...
I was never able to get it going myself (If I remember correctly, there was some issue with how the interrupts were being routed on my notebook. We were doing some strange stuff to forward interrupts from the host kernel into Bochs that didn't work on all configurations.)
However, Frank Cornelis was using the Windows 98 drivers running under Win98 on pcidev+Bochs. Kendall Blake was using the Windows XP drivers and a modified ndiswrapper running under Linux also on pcidev+Bochs. Kendall told me that he generated about 400 megs of logs just looking at the card initialization. I think it was at this point I decided that decompiling the thing would be easier. :)
Anyway, you could try asking Frank and Kendall for some of the data they gathered.
kendallb () eden rutgers edu
fcorneli () pandora be
<snip>
Quoted 4 lines
Hrm, you're sure those variations aren't trivial? Although theres lots of checks, I would have thought they would just be stuff like "card A supports X, Y and Z features"?
The differences between radio chips (ex. a vs. g) aren't going to be trivial. That is to say, entirely different code paths are executed in the wlc_phy.o component. The variations caused by different board configurations don't appear to be too big (at least from the code I've looked at). Some of the variations (probably bug fixes) caused by different revisions of the chips are also a little large. But, I think it will be pretty difficult to determine how the differences in the dumps relate to differences in the hardware configuration.
Quoted 5 lines
The approach that makes the most sense to me is get 1 card working to the point where it sends/receives packets, then look at the binaries to see what the variations are, and how they apply to what cards and just go fill in the blanks...
The problem is that all Broadcom's wireless hardware is supported by one big driver. If you wanted to be able to see the differences between what code is executed against each device, you'd pretty much have to decompile the whole thing, or at least do some serious debugger work. Assuming you don't want to do that, it seems you're left with doing the capture analysis on every variation, which doesn't seem practical.
<snip>
Quoted 2 lines
Also, you mention DMA and sending/receiving packets, exactly how much progress have you made so far?
I'm pretty sure that they were able to get packets to go back and forth. But, the last I heard from anyone using the capture method with pcidev and Bochs was about six months ago.
-- Andrew
Quoted 15 lines · Lee Revell
Quoted 11 lines · Wakko Warner
Quoted 8 lines
Quoted 3 lines
Ideas/comments/suggestions are welcome at this stage.
Sounds interesting; is there a vendor blacklist (i.e. vendors that are
either hostile toward or simply don't care about Linux and their products just won't ever work with Linux?)Broadcom's wireless chips come to mind...
Quoted 9 lines
Nvidia. AFAIK all nvidia Linux drivers are either binary-only or reverse-engineered.
To add insult to injury they have a stupid 20+page 'Nvidia Linux Advantage' whitepaper on their site that conveniently fails to mention the above. They probably spent more money for some marketroid to put that together than they ever spent on actually supporting Linux.
Vendors should understand that ACTUALLY supporting linux means adopting the free software philosophy. In many cases, vendors think that they should be the only one to be able to write drivers, since 99% of desktop users dont care about their software freedom. Vendors should not try to obscure the workings of their devices, they should show the world how they are innovating in hardware design by releasing specs on a freely-redistributable basis. This would greatly improve competiveness and innovation in the domain of hardware design. Give me a binary driver and i will buy from you once, give me the specs and i'll appreciate the effort you put in designing the device.
Quoted 9 lines · Jonathan Bastien-Filiatrault
Quoted 1 line
Vendors should understand that ACTUALLY supporting linux means adopting the free software philosophy. In many cases, vendors think that they should be the only one to be able to write drivers, since 99% of desktop users dont care about their software freedom. Vendors should not try to obscure the workings of their devices, they should show the world how they are innovating in hardware design by releasing specs on a freely-redistributable basis. This would greatly improve competiveness and innovation in the domain of hardware design. Give me a binary driver and i will buy from you once, give me the specs and i'll appreciate the effort you put in designing the device. -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I remember a computer from pre ibm-pc days. It came with a manual that included a detailed circuit diagram, so the user could make any repairs they wished. It also gave details regarding CPU instruction set, and memory layout, so that anyone could write any OS they liked for it.
If we do create a nice long list, we should also include Linux compatible hardware as well.
E.g. Latest XYZ laptop, it would list all the chips in the laptop, together with what level of support linux has for each one. The problem comes with actually identifying the parts.
For example, Creative have lots of different sound cards, all called the
SB Live, but they all have very different chips in them, with some
supported by linux, and some not. Don't you just love those Marketing people. :-(
We can use PCI IDs and PCI subsystem IDs, to identify Motherboards, and PCI cards. We might also have to identify revision numbers. We can use USB IDs to identify USB devices.
As an aid to this, I think we should create a script, that will gather the IDs in a consistent way, so that a user just runs the script, adds a comment, and submits it to the database.
Quoted 12 lines · James Courtier-Dutton
Quoted 9 lines · Jonathan Bastien-Filiatrault
Quoted 1 line
Vendors should understand that ACTUALLY supporting linux means adopting the free software philosophy. In many cases, vendors think that they should be the only one to be able to write drivers, since 99% of desktop users dont care about their software freedom. Vendors should not try to obscure the workings of their devices, they should show the world how they are innovating in hardware design by releasing specs on a freely-redistributable basis. This would greatly improve competiveness and innovation in the domain of hardware design. Give me a binary driver and i will buy from you once, give me the specs and i'll appreciate the effort you put in designing the device. -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 1 line
I remember a computer from pre ibm-pc days. It came with a manual that included a detailed circuit diagram, so the user could make any repairs they wished. It also gave details regarding CPU instruction set, and memory layout, so that anyone could write any OS they liked for it.
My dad had a thing like that(quick reference card) for an old motorola 6800(not 68000) processor. It only had 2 8-bit general purpose registers if I remember correctly. Doesn't even begin to compare with modern ppc processors.
Quoted 7 lines
If we do create a nice long list, we should also include Linux compatible hardware as well.
E.g. Latest XYZ laptop, it would list all the chips in the laptop, together with what level of support linux has for each one.
The problem comes with actually identifying the parts.
For example, Creative have lots of different sound cards, all called the SB Live, but they all have very different chips in them, with some supported by linux, and some not. Don't you just love those Marketing people. :-( We can use PCI IDs and PCI subsystem IDs, to identify Motherboards, and PCI cards. We might also have to identify revision numbers.
We can use USB IDs to identify USB devices.
Good idea, we should have something like two lists one for "chips" and one for "containers of chips" aka whole systems. That way it could be cross-referenced in a database-like way with a nice gtk frontend. The project probably ressemble the pci-ids project. That would pave the way for a free(as in speech) hardware purchasing guide.
Quoted 1 line · Jonathan Bastien-Filiatrault
My dad had a thing like that(quick reference card) for an old motorola 6800(not 68000) processor. It only had 2 8-bit general purpose registers if I remember correctly. Doesn't even begin to compare with modern ppc processors.
Hey! I built a primitive computer from one of those in a microprocessor class a year ago. 2 8-bit registers, 8-bit data-bus and 16-bit address bus. There were two interrupt pins, IRQ and NMI, and a simple condition code register. The CPU clock is the same as the bus clock. What fun!!!
Quoted 1 line
Good idea, we should have something like two lists one for "chips" and one for "containers of chips" aka whole systems. That way it could be cross-referenced in a database-like way with a nice gtk frontend. The project probably ressemble the pci-ids project. That would pave the way for a free(as in speech) hardware purchasing guide.
A well designed guide could go a long way toward convincing companies to release specs. When a well known hardware website has user testimonials that the drivers suck, the tech support are unhelpful, and the company just doesn't get it, said company will probably tend to listen.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-) ------END GEEK CODE BLOCK------
Quoted 6 lines · Kyle Moffett
Quoted 5 lines
Good idea, we should have something like two lists one for "chips" and one for "containers of chips" aka whole systems. That way it could be cross-referenced in a database-like way with a nice gtk frontend. The project probably ressemble the pci-ids project. That would pave the way for a free(as in speech) hardware purchasing guide.
Quoted 6 lines
A well designed guide could go a long way toward convincing companies to release specs. When a well known hardware website has user testimonials that the drivers suck, the tech support are unhelpful, and the company just doesn't get it, said company will probably tend to listen.
Takashi Iwai's 'Writing an ALSA driver' (google for it) is IMHO the exemplar in this area. It is written at *exactly* the right level. Several major vendors have come on alsa-devel and posted to the effect that they followed this guide and have their driver 99% working, they just need help with this or that, someone answers a question or two, and bang, one more Linux-supported device. There should be a document of this quality covering every major category of driver.
Lee
Quoted 5 lines · Kyle Moffett
A well designed guide could go a long way toward convincing companies to release specs. When a well known hardware website has user testimonials that the drivers suck, the tech support are unhelpful, and the company just doesn't get it, said company will probably tend to listen.
Or use [ your favorite new law of the day ] to bring the site and/or the comments down?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 9 lines · Geert Uytterhoeven
Quoted 5 lines · Kyle Moffett
A well designed guide could go a long way toward convincing companies to release specs. When a well known hardware website has user testimonials that the drivers suck, the tech support are unhelpful, and the company just doesn't get it, said company will probably tend to listen.
Or use [ your favorite new law of the day ] to bring the site and/or the comments down?
If it tries to, we'll only need to find a journalist searching for a story. ;-)
Greetings,
Signature · 5 lines
Rafael J. Wysocki ---------------------------- For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. -- Richard P. Feynman
Quoted 8 lines · R. J. Wysocki
Quoted 7 lines · Geert Uytterhoeven
Quoted 5 lines · Kyle Moffett
A well designed guide could go a long way toward convincing companies to release specs. When a well known hardware website has user testimonials that the drivers suck, the tech support are unhelpful, and the company just doesn't get it, said company will probably tend to listen.
Quoted 7 lines
Quoted 2 lines
Or use [ your favorite new law of the day ] to bring the site and/or the comments down?
If it tries to, we'll only need to find a journalist searching for a story. ;-)
Greetings,
How about mentioning it on /.? Thats usually good for a takedown if they don't have big iron and pipes to suit. :-)
Signature · 8 lines
Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.24% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Quoted 7 lines · Kyle Moffett
Quoted 1 line · Jonathan Bastien-Filiatrault
My dad had a thing like that(quick reference card) for an old motorola 6800(not 68000) processor. It only had 2 8-bit general purpose registers if I remember correctly. Doesn't even begin to compare with modern ppc processors.
Hey! I built a primitive computer from one of those in a microprocessor class a year ago. 2 8-bit registers, 8-bit data-bus and 16-bit address bus. There were two interrupt pins, IRQ and NMI, and a simple condition code register. The CPU clock is the same as the bus clock. What fun!!!
Here's where I feel my age... 6502 with ONE (That's 1) general purpose register (Called the accumulator)... Plus a couple of others used mainly for offsets (X & Y if I remember correctly)... No 16-bit maths... All 8-bit. (As were the registers). Boy the 6809 was easy to program after that sucker...
The 6809 (basically an extension of the original 6800) had 2x 8-bit registers IIRC, that you could actually treat as a single 16-bit register as well (i.e. multiply one 8bit by the seocnd & read the result from the '16-bit' register... The assember language on the 6800 series was way better than the 6502 (And the 6510).
but I digress... Even IBM were good with open source. I think I still have an IBM PC tech reference around here with the complete source code listing (In x86 assembler) of the original IBM PC Bios. Now that made for innovation... Open hardware & software. Heck most of these companies need a good reminder that if they hadn't had a leg up fro Open computing in the early 80's they wouldn't be here today.
H
Salut,
Quoted 2 lines · Jonathan Bastien-Filiatrault
Vendors should understand that ACTUALLY supporting linux means adopting the free software philosophy.
Actually look at what happened when the probing part of the NVidia driver was published: people looked at it and fixed bugs.
Opensourcing a driver can actually be a benefit for the company, since they don't need to pay some maintainer for it then plus they won't need to put up with problems after kernel changes and stuff and neither with bugs in the code.
The problem is that people still think that there is intelectual property and that it can be stolen. (The famous blackbird case (Yes, I said the B word!)) But look at UNESCO: maybe one day the world will be different.
Tonnerre
(Part-time UN coworker)
Quoted 2 lines · Lee Revell
Nvidia. AFAIK all nvidia Linux drivers are either binary-only or reverse-engineered.
The X 2D driver isnt too easy to read (although with the rivatv notes its quite easy). That was written by Nvidia employees and provided by Nvidia.
Alan
Quoted 7 lines · Alan Cox
Quoted 2 lines · Lee Revell
Nvidia. AFAIK all nvidia Linux drivers are either binary-only or reverse-engineered.
The X 2D driver isnt too easy to read (although with the rivatv notes its quite easy). That was written by Nvidia employees and provided by Nvidia.
As was the nForce AGP GART driver. Some folks in NVidia are trying to do the right thing wherever possible.
Dave
Quoted 11 lines · Dave Jones
Quoted 7 lines · Alan Cox
Quoted 2 lines · Lee Revell
Nvidia. AFAIK all nvidia Linux drivers are either binary-only or reverse-engineered.
The X 2D driver isnt too easy to read (although with the rivatv notes its quite easy). That was written by Nvidia employees and provided by Nvidia.
As was the nForce AGP GART driver. Some folks in NVidia are trying to do the right thing wherever possible.
This will be an interesting space to watch I guess.
Tyan is working on an LinuxBIOS to Nvidia's most recent
Opteron chipset as well. And Nvidia seems to be helping.
Eric
Quoted 7 lines · Wakko Warner
Quoted 5 lines
Quoted 1 line
Ideas/comments/suggestions are welcome at this stage.
Sounds interesting; is there a vendor blacklist (i.e. vendors that are
either hostile toward or simply don't care about Linux and their products just won't ever work with Linux?)Broadcom's wireless chips come to mind...
Sounds good. I wouldn't know one if it bit me on the leg, though, can you point to list archives, a web site, or reassure me that if I google for it I will get the right information? I'd like models or a range of models if possible, and why they don't work, and any notes or additional information about the situation.
Thanks!
Signature · 5 lines
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 1 line
Ideas/comments/suggestions are welcome at this stage.
Sounds interesting; is there a vendor blacklist (i.e. vendors that are
either hostile toward or simply don't care about Linux and their products just won't ever work with Linux?)
Quoted 7 lines
Quoted 1 line
Broadcom's wireless chips come to mind...
Sounds good. I wouldn't know one if it bit me on the leg, though, can you point to list archives, a web site, or reassure me that if I google for it I will get the right information? I'd like models or a range of models if possible, and why they don't work, and any notes or additional information about the situation.
The linksys G cards (pci/cardbus) both use broadcom chips. Not sure the exact model numbers. I have 2 at work that are broadcom.
Signature · 1 line
Lab tests show that use of micro$oft causes cancer in lab animals
Quoted 8 lines · Wakko Warner
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Ideas/comments/suggestions are welcome at this stage.
Sounds interesting; is there a vendor blacklist (i.e. vendors that are
either hostile toward or simply don't care about Linux and their products just won't ever work with Linux?)Broadcom's wireless chips come to mind...
Quoted 8 lines
Quoted 5 lines
Sounds good. I wouldn't know one if it bit me on the leg, though, can you point to list archives, a web site, or reassure me that if I google for it I will get the right information? I'd like models or a range of models if possible, and why they don't work, and any notes or additional information about the situation.
The linksys G cards (pci/cardbus) both use broadcom chips. Not sure the exact model numbers. I have 2 at work that are broadcom.
Most routers with 4 ethernet ports for internal network, 1 ethernet port for external network and a wireless output which have a lot of functionality run Linux with a closed-source wireless driver:
Linksys WRT54g, ASUS WL-500g/b, and probably more...
Signature · 3 lines
Rutger Nijlunsing ---------------------------- rutger ed tux tmfweb nl never attribute to a conspiracy which can be explained by incompetence ----------------------------------------------------------------------
Quoted 6 lines · Joseph Pingenot
Quoted 2 lines
From David N. Welton on Saturday, 21 August, 2004:
Ideas/comments/suggestions are welcome at this stage.Sounds interesting; is there a vendor blacklist (i.e. vendors that are either hostile toward or simply don't care about Linux and their products just won't ever work with Linux?)
That's part of the idea, but I'd rather stick to "just the facts ma'm". With enough entries, it will be evident who to avoid, so send lots of them to get things rolling!
Thanks,
Signature · 5 lines
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/On Sad, 2004-08-21 at 20:41, David N. Welton wrote:
I think the "compatibility list" side is the more important. Trying to punish non helpful products/vendors isn't as productive as helping stuff that is Linux friendly.
Quoted 7 lines
Product Name:
Manufacturer:
Model Number:
Chipset:
At what level is "Product" - do you need a category. How do you want to classify devices. I think this matters because you want eventually to be able to deal with things like tools that let users rate their setup functionality and submit it automatically.
Quoted 10 lines
How bad it is (1 to 10, 9 being it almost works and has only minor bugs):
Reason (no specs, driver still being worked on, ...):
Url for more info:
An email address of yours that we may publish (so that we can contact you if someone says "no, that works just fine!"):
Wikipedia has a discussion page tagged to each article/entry. This works extremely well because it provides a public forum for discussion of what does/doesn't work, why and when.
Could you add "Kernel.org bugzilla #" for not working ones, both to help people track them and to encourage submissions ?
Alan
Quoted 5 lines
From Alan Cox on Sunday, 22 August, 2004:
On Sad, 2004-08-21 at 20:41, David N. Welton wrote:
I think the "compatibility list" side is the more important. Trying to punish non helpful products/vendors isn't as productive as helping stuff that is Linux friendly.
Definitely. It's great to know that Linux works with a device, since
I know that I can buy it and actually *use* it. Double points if the *device* works with *linux*!
That said, there are lots of devices out there that aren't listed in the
compatibility list. I'd be nice to know if they *don't* work, since I won't feel tempted (if the price is right) to take it home and try it out. Although, as another point, it'd be nice to bring all of the various device compatibility lists together in one place, esp. for the HAL/D-BUS/Utopia system, so that they could potentially query the list over the net. Bonus points for a downloadable version for the distros!
Also, a known-helpful vendor list would be great, as I would be much more
inclined to buy stuff from vendors who support Linux (as opposed to Linux supporting them). It's important to me, and I like to put my money where my mouth is. :)
In short, we should definitely work on maintaining a big device and vendor
compatibility list ([butter]flies, honey, vinegar), but a known-bad/hostile list is also a nice thing to have, so that we can know to take our dollars elsewhere.
-Joseph
Signature · 2 lines
Joseph===============================================trelane@digitasaru.net
Graduate Student in Physics, Freelance Free Software DeveloperQuoted 5 lines · Alan Cox
On Sad, 2004-08-21 at 20:41, David N. Welton wrote:
I think the "compatibility list" side is the more important. Trying to punish non helpful products/vendors isn't as productive as helping stuff that is Linux friendly.
A "compatibility list" is going to be pretty big, and hard to keep up to date. My thinking is that keeping track of a few notable things that don't work is easier than running after all the stuff that does.
Of course, if automation can be brought to bear, that might make either one much easier, but I'm dubious, because "it doesn't work" is a vague concept, and really ought to be researched some.
A third concept "look, these guys support Linux really well!" (not just "ok, it works") might also be easy to do.
By the way, the concept is not really about punishing vendors, and I don't want it to come off looking like that. It's about "this piece of hardware does not work with Linux". Who knows, maybe the fault is with the kernel maintainers:-) It might be nice if that gave some incentive to the manufacturers to help bring the driver up to speed, though.
Quoted 4 lines
At what level is "Product" - do you need a category. How do you want to classify devices. I think this matters because you want eventually to be able to deal with things like tools that let users rate their setup functionality and submit it automatically.
I'd be worried about people who are just irritated that their system didn't work out of the box hitting a button to submit this information.
I suppose some sort of vote system could be put in place so that the 1 guy who didn't get the hardware to work gets outvoted by the 10 who did, but there is more incentive to hit the button when you are irritated than when everything 'just worked'.
Quoted 5 lines
Quoted 4 lines
How bad it is (1 to 10, 9 being it almost works and has only minor bugs):
Reason (no specs, driver still being worked on, ...):
Quoted 8 lines
Quoted 4 lines
Url for more info:
An email address of yours that we may publish (so that we can contact you if someone says "no, that works just fine!"):
Wikipedia has a discussion page tagged to each article/entry. This works extremely well because it provides a public forum for discussion of what does/doesn't work, why and when.
It's a wiki, so for now I think placing comments on the bottom of the page would be sensible. We'll see if and how it grows.
Quoted 2 lines
Could you add "Kernel.org bugzilla #" for not working ones, both to help people track them and to encourage submissions ?
Excellent idea.
Thanks for your thoughts,
Signature · 5 lines
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/Quoted 3 lines · David N. Welton
A "compatibility list" is going to be pretty big, and hard to keep up to date. My thinking is that keeping track of a few notable things that don't work is easier than running after all the stuff that does.
Its already been kicked around on the Fedora list to actually build such a database automatically. I've seen similar Debian proposals a long time ago. That means some time post install you'd let the user fire up a system report tool which would ask things like
"Does sound work"
and then fire off PCI id/rating info to a central site. That would help deal with the data collection much as the Debian folks collect package popularity statistics.
Quoted 4 lines
I suppose some sort of vote system could be put in place so that the 1 guy who didn't get the hardware to work gets outvoted by the 10 who did, but there is more incentive to hit the button when you are irritated than when everything 'just worked'.
If you get enough data then the deviation tells you how varied and how reliable the opinions are likely to be, all this implies databases not WIki however
Alan
Quoted 16 lines · On Sun, 22 Aug 2004 21:45:27 +0100 Alan Cox <[email protected]> wrote:
Quoted 3 lines · David N. Welton
A "compatibility list" is going to be pretty big, and hard to keep up to date. My thinking is that keeping track of a few notable things that don't work is easier than running after all the stuff that does.
Its already been kicked around on the Fedora list to actually build such a database automatically. I've seen similar Debian proposals a long time ago. That means some time post install you'd let the user fire up a system report tool which would ask things like
"Does sound work"
and then fire off PCI id/rating info to a central site. That would help deal with the data collection much as the Debian folks collect package popularity statistics.
Quoted 9 lines
Quoted 4 lines
I suppose some sort of vote system could be put in place so that the 1 guy who didn't get the hardware to work gets outvoted by the 10 who did, but there is more incentive to hit the button when you are irritated than when everything 'just worked'.
If you get enough data then the deviation tells you how varied and how reliable the opinions are likely to be, all this implies databases not WIki however
This sounds very interesting indeed. We (OSDL) have been talking about how to extend our testing into the ISV space, and how to supply useful data. This type of post-install, post-test 'i look like this, and this runs' data capture would be real useful, especially if we could capture software info also. Who else was interested in this?
cliffw
Quoted 9 lines
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 2 lines
The church is near, but the road is icy. The bar is far, but i will walk carefully. - Russian proverb
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line · Michael Buesch
What about some Wiki based database?
That's what it is, more or less. I'm just putting the finishing touches on the wiki software, and I wanted to ask for a few entries to work with, and people interested in playing with the wiki before publicizing it.
Oh, just so it's clear, by the way, the contents of the wiki will be under a free license.
Signature · 5 lines
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/[BTW, please CC replies to me. Thanks! ]
As far as binary only drivers and things of that ilk, I intend to list them on the site, and describe the situation as accurately as
possible: "this does work, on x86, but only with one guaranteed kernel version, etc...". I would rate it around a 5 out of 10. With that in mind, specific model numbers/chipsets/whatever else is available for nVidia and broadcom equipment is welcome. I will put those on the wiki myself (still got some kinks).
I don't want to beat up on companies, or at least that's not the central idea. I want to provide a place for people to check quickly if they're thinking about buying something, or if they've just bought it, so they can see what the potential problems are.
Thankyou,
Signature · 5 lines
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/Quoted 14 lines · David N. Welton
Hi,
I'm reviving an idea I implemented several years ago, namely the Linux Incompatibility List.
The idea is simple: most hardware works fine with Linux, and the situation is generally pretty good, with Linux increasingly showing up on the corporate radar.
However, there are devices that don't work with Linux, for various reasons (no specs, too new and no one has written a driver, etc...), and it's easier to keep track of those devices so that people can avoid them (or the hero types can write drivers for them).
[...]
Quoted 16 lines
I think (correct me if I'm wrong) the information we would want to collect is:
Product Name:
Manufacturer:
Model Number:
Chipset:
How bad it is (1 to 10, 9 being it almost works and has only minor bugs):
Reason (no specs, driver still being worked on, ...):
Quoted 11 lines
Url for more info:
An email address of yours that we may publish (so that we can contact you if someone says "no, that works just fine!"):
Notes:
Ideas/comments/suggestions are welcome at this stage.
An idea: To really put some pressure on vendors, also have an entry for "alternate/better solution" where people can list a way to achieve the same result with someone else's product and open drivers. Example:
Product: Matrox parhelia (a triplehead graphichs card)
Reason: Bad binary-only 2D-only driver
Alternate solution: Achieve triplehead with two radeon cards (1 AGP dualhead + 1 PCI) instead!
This will be useful for anyone planning a upgrade but finding their favourite solution on the incompatibility list. And it'll sure put some pressure on the manufacturer to at least get a _good_ driver out (changing the reason), or even better, an open one which get rid of the incompatibility entry.
Helge Hafting
Quoted 7 lines · Helge Hafting
An idea: To really put some pressure on vendors, also have an entry for "alternate/better solution" where people can list a way to achieve the same result with someone else's product and open drivers. Example:
Product: Matrox parhelia (a triplehead graphichs card)
Reason: Bad binary-only 2D-only driver
Please add it here, using the 'template'.
Quoted 8 lines
Alternate solution: Achieve triplehead with two radeon cards (1 AGP dualhead + 1 PCI) instead!
This will be useful for anyone planning a upgrade but finding their favourite solution on the incompatibility list. And it'll sure put some pressure on the manufacturer to at least get a _good_ driver out (changing the reason), or even better, an open one which get rid of the incompatibility entry. Helge Hafting
And in the case where there are multiple possibilities? I think as a general rule, I don't want to get into pushing anyone's hardware as an alternative, although if someone were to mention a few alternatives in the comments or notes section I don't think it would hurt.
Thanks,
Signature · 5 lines
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/Quoted 13 lines · David N. Welton
Quoted 6 lines · Helge Hafting
An idea: To really put some pressure on vendors, also have an entry for "alternate/better solution" where people can list a way to achieve the same result with someone else's product and open drivers. Example:
Quoted 11 lines
Quoted 4 lines
Product: Matrox parhelia (a triplehead graphichs card)
Reason: Bad binary-only 2D-only driverPlease add it here, using the 'template'.
Done. I didn't recommend any particular brand when describing the "alternate solution", as you didn't want that. The reason for specifying a brand was only to create more pressure than "use a couple of supported cards instead".
Helge Hafting
Quoted 11 lines · Helge Hafting
Quoted 6 lines
Quoted 2 lines
Product: Matrox parhelia (a triplehead graphichs card)
Reason: Bad binary-only 2D-only driverPlease add it here, using the 'template'.
Done. I didn't recommend any particular brand when describing the "alternate solution", as you didn't want that. The reason for specifying a brand was only to create more pressure than "use a couple of supported cards instead".
It's certainly not a bad idea - maybe if we put it right next to the stupid google ad it would make it return something that made sense instead of the very hardware we are telling people to avoid.
On the other hand, the site and ads are not something I'm doing to get rich, so I'd rather avoid even giving the impression of impropriety.
Thanks for adding the card!
Signature · 5 lines
David N. Welton Personal: http://dedasys.com/davidw/ Apache Tcl: http://tcl.apache.org/ Free Software: http://dedasys.com/freesoftware/ Linux Incompatibility List: http://leenooks.com/