I like how smartass respondents like to gloss over confirmations in their own reference as if they didn't exist, and wouldn't be caught.

It wasn't the light that was toxic you idiot.

It was the fluorescent molecules added to the specimen, and
constituents of standard culture media,
nuclear stains, dyes, etc.

Light itself is not toxic. Read reverseengineer's response http://slashdot.org/comments.p...

As best I can tell, even reading all the other replays, THIS reply is the only one that makes any sense at all.

Thanks for the explanation, very helpful.

Are there any issues with silicon solar cells that make them (protected against visible light, obviously) unsuitable? Compared to power silicon or anything for computation you can get enormous area for relatively little money.

No, just that chip+pin makes more sense for taking card payments on machines than... well, last time I remember using a card in a machine in the US it was swipe and... Hey, fingers crossed, who needs a PIN?

Plus, they do have an awful lot of those bill readers.

Oh, I know that. It just seems silly that the focus is on the i-beam, and not the things that the hat can actually protect against.

Does radiation detection(with actual accuracy, linearity, and repeatability, not just a quick demonstration that you can add some noise to a webcam by pointing a small sealed source at it) have currently good, or at least promising for the not too distant future, solid state options?

I'd imagine that for cost, robustness, and duration on battery power, the presence of little gas filled tubes, some with fairly delicate internal structure, that require a high voltage power supply is a necessary evil at best. In the case of a scintillation counter, the photomultiplier tube would be a similar headache.Are there better behaved options?

Call me when someone does a jump from the ISS :-P

Toxic light is a new one.
Having no substance, light can't carry any toxins.

The light might fry the specimen. But no rational definition of toxic applies here.

FTDI didn't choose that specific value(though, thinking back to Intel's amusing choice of '8086' as their PCI vendor ID, you probably can choose a VID if you push hard enough or have a cute reason); but there are still some commonalities(though arguably some differences as well):

The USB spec (and, probably more importantly, USB as implemented on basically all commercially relevant systems) supports essentially two mechanisms for telling the OS what driver your device requires:

If supported by a generic class driver; your device descriptors include a bDeviceClass field containing a defined USB device class code; but isn't 0xFF(which is valid; but means 'vendor defined'), a bDeviceSubClass field with a valid subclass code, and a bDeviceProtocol field with a valid protocol code.

If your device is supported by a specific driver(or one of the hybrid arrangements, not uncommon, where a versatile device class like USB HID will be used to do most of the low-level work; but a vendor-specific driver will implement whatever device specific behavior is offered on top of that), then you need to supply the correct VID/PID combination.

Now, let me be clear, I see absolutely no reason why FTDI should need to provide driver support for clones, so even if Windows(correctly, as an OS) responds to a USB device with an FTDI VID/PID by loading the FTDI driver, it is fully within their rights to have a driver that detects and ignores non-FTDI parts.

However, (and this is where the analogy to consoles and trademarked-but-technically-necessary really comes in), the USB spec does not offer a 'compatible with VID/PID' device description option. Either you specify the appropriate generic class, or you specify a VID/PID and a vendor-specific class. There is no other way (barring atypical configurations and kernel hacker tricks that aren't of much use in the wider world) to do it.

If you want a Game Boy or whatever to load your cartridge, you need that logo to be present at the appropriate address. If you want to specify "I need the driver that supports device X", you have to supply device X's VID/PID. There is no 'compatible with device X; but actually made by me' mechanism.

If you are buying fake FTDI gear to take advantage of FTDI's driver devs, then I have no pity. Not FTDI's problem to support you. However, there are 3rd-party FTDI-device-supporting drivers (notably on Linux and BSD, maybe somebody has ported one to Windows or OSX, maybe you plan to implement your own, whatever) that it would be perfectly legitimate for an FTDI-compatible device to request, and (so long as it doesn't involve copyright or patent infringement, or fraudulent misrepresentation) there are perfectly licit non-FTDI chips that implement FTDI-compatible behavior. The USB-IF certainly doesn't have enough power over short hex values to stop that; and I'm not convinced that we would want them to.

A large number of now standard or semistandard devices, protocols, and command sets we don't even think about today started life as dirty clones of the more popular brand: The PC BIOS, the (still spoken, in extended form, by a moderately alarming number of things) Hayes command set, the 16550 UART (originally a National Semiconductor model number; now register compatibility with those is practically a standard in itself, thanks to about a zillion clones), the NE1000/2000-compatible NICs that helped make ethernet ubiquitous and cheap...

Again, FTDI has every right to make the use of their drivers contingent on the use of their ICs (or some other licensing terms, if that amuses them). Also, non-FTDI parts being sold (with varying degrees of sophistication, from pure nonsense to nearly perfect fakes) as FTDI is a bad thing. For FTDI, for the buyer being defrauded, for the electronics supply chain generally.

However, we would not be well served to be blinded to the (generally desirable and helpful, as much as incumbents dislike them) history of 3rd-party interoperable parts by lumping all of them in with 'counterfeit' parts and taking measures that make it easier to suppress them, and easier for 'counterfeit' to mean 'compatible with someone who doesn't want you to be compatible with them' rather than to mean 'based on illicitly copied designs and/or sold under fraudulent label'. These are two very different things.

Sorry, but I'm not interested unless [profession] hates him because of it.

They could make the argument; but I'm not sure that they could win it.

It is widely accepted that you can use a protected mark, so long as you don't do so deceptively, to provide information about your product(the usual formulation is "Store brand product, compare to Product(tm) active ingredients). Not a trademark violation, even if the trademark holder might not like it; just telling the customer what your product is intended to be compatible with.

In computing applications, since the data are usually being sent to an (often inflexible and buggy) program rather than to a human, and since identifying information is often necessary for operation, even more blatant use is often accepted. Most browsers still claim to be "Mozilla/5.0" followed by a bunch of other stuff, often equally trademarked and equally false, because that particular string was the only way to get the correct output from assorted crufty HTTP servers. In more adversarial cases, like Lexmark's battle with Static Control Components over toner lockout chips, SCC ended up being allowed to duplicate an even larger chunk of Lexmark's firmware, over Lexmark's objections; because that was deemed a technically necessary part of producing an interoperable toner cartridge.

The USB VID/PID is conceptually in a similar position to the browser UA: it's not hard to find; but not really there for human readers and subject to fairly specific technical limitations if you actually want it to work. "0x0403" is a valid VID. "0x0403 (compatible; China Cloneshop)" is not. It won't even work, much less request the correct driver. USB does provide for purely descriptive, human readable, information fields ('Manufacturer String Descriptor', 'Product String Descriptor', and 'Serial Number String Descriptor') and those aren't subject to technical constraints.

I certainly wouldn't want to be on defense if I were selling a product with somebody else's trademark misused in the string descriptor fields; but the VID/PID would be much more defensible.

KFC and Burger King have been using touchscreen order & pay kiosks for some time, and I encountered it in a McD's for the first time about a month ago. The fact that we all use chip-and-PIN debit cards (and some people are already using NFC cards) probably helps - having to include the facility to feed dollar bills into a slot would put a crimp in it somewhat.

Why not? The USB IF won't be happy about it, and not being able to trust VID/PID pairs makes driver devs sad and prone to resort to ugly fingerprinting heuristics; but none of that establishes a legal monopoly on "0x0403" for FTDI.

Well... Let's just have a little test!