My very secure password, is well over 100 bits of entropy. Easily extendable when the time comes.

But that is not the problem. We're using a Secret for single factor identification. Real identification is multi-factor and requires non-secret means for identity, and then a secret for proof of identity. Non-secret identification requires a web of trust. Online systems have neither non-secret web of trust Identification nor proper secret proof of Identification.

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.

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?

I know not these "inches" of which you speak.

I want to know why no one has made an ELM327 replacement.

With CAN, USB, Bluetooth all becoming ubiquitous I think it's time to update the old ODB chip.

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.

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.

Because Bay Area is typical middle class neighborhood /sarcasm.

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.

That isn't actually so clear:

According to the die shots, the clone chips' implementation is more or less entirely different from the FTDI implementation. Intended to be pin-compatible, and exhibit the same behavior; but totally different silicon, not a cut and paste job.

The clones that are then labelled and sold as 'FTDI' are, certainly, in all kinds of violation of trademark law; but what of any that are just blob-topped or generically packaged and not represented as being actual FTDI? Not something FTDI likes, or is obliged to provide driver support for; but neither was the Compaq 'IBM PC compatible' BIOS.

Even if the (typically very harsh, though widely unenforced) laws regarding trademark infringing goods do actually allow FTDI to brick them in the field, they haven't actually established that a given chip is a counterfeit, rather than a mere clone, before bricking it. Unless they wish to claim that "0x0403" is entitled for trademark protection, the driver is hardly in a position to distinguish between the two.

I can only imagine that the lucky guy who picked up the call from Redmond about 'so, we understand that you...made a few changes...to the behavior of your WHQL drivers that frankly don't make Windows Update look very good...' got quite an earful.

Even if MS thinks FTDI is on the crusade of the righteous, it certainly isn't to their advantage to have Windows Update involuntarily pulled into the fiasco.

Why keep it civil? Seems only fair for whoever came up with this plan to spend some time stamping out license plates for Uncle Sam.

You know, most of the time, the truth lies right in the middle of the fighting sides. Having seen two kids fighting over a toy a time or two, it is the toy that ends up suffering (broken, destroyed, damaged etc). Slapping the kids across the back of the head, and taking away the toy is often the only "real solution". Being a parent isn't easy, but the grownups sometimes need to simply smack the back of heads and issue a timeout.

And when it is the grownups are acting like children, the parent role becomes the easy target. "Don't tell me how to think or what to do". Please don't make excuses.

Note: I'm not taking sides in the GG debate. I have no idea what it actually is. Except that it involves Gamers who often act like little children.

Somalia!

Generally speaking, hurt feelings strike a nerve. Barking dogs don't strike a nerve, therefore don't hurt feelings. However trolls telling tramps that they are sluts hits a nerve. Hell, even my using those terms will get me in trouble because they elicit a certain negative connotation on the female gender (and done to illustrate a point). If a girl is secure in their sexuality, then no hurt feelings, but if a girl is not comfortable with their sexuality hurt feelings ensue.

Just to make it clear, I don't care about who people sleep with, that is their own fucking (pun intended) business.

The real defense to "hurt feelings" is thicker skin. Which can be learned. But instead, we've become a society of victims of "hurt feelings" and the outrage that is a result.

What is real, is that troll exist. Have existed for ever, and will exist into the foreseeable future. It would be much better use of time and energy helping people ignore trolls, than letting them get the best of us with their trolling.