Both from a technical academic nature, and a pure R&D perspective this is very weak argumentation. I'll put it this way: "weak confidence" as you call it never passes the cut. Applying silly non-concrete statistics is more expensive than actually doing the real complete test runs with all possible parameters in many cases. Additionally small sample sizes like this are horribly biased in many cases. Since the technical ones are more iffy (the reasons are often obscure measurement errors), so let me give you a psychology example: We all know the psychology major handing out flyers on campus for a survey, he promises a particular gift (e.g. a can of redbull) and hands out these flyers in a few very specific locations (e.g. faculty of electrical engineering) Then your entire sample group will be highly educated early 20 year olds, and maybe some university faculty. So if you combine that with a small sample size of about 50 you get the most biased world view possible. The same with technical datasets, your small samples will usually be from a single manual production run which means environmental conditions and operator skill and error have a huge impact on the end result.

Considering this is really really basic statistics I'd say anybody we want on Slashdot is already very familiar with these things. If we wish to introduce post quality standards I suggest we give it an IEEE Spectrum approach: low quantity of quality articles with decent journalism about technical subjects. Not to say they never publish bullshit, but in general they seem to get it right. Then again, I think I'll just move over there.

What we should really do is shut down the psychology and sociology departments and insert a symlink to McDonalds, Burger King, and Starbucks application forms. I should put it this way: Having a bunch of pissed off folks, who would normally study psychology and then kept whining about how they couldn't find a job, serving your coffee or heart attack inducing burger is better than having them publish crap like this.

Well, a lot of USB hosts and hubs at this point are really just 8051 MCUs. The question is at which point we'll end up with the transputer again if we proceed down this line?

Oh yeah, don't tell me about those. I still have a headache of getting those PowerPC cores to work on those old Xilinx FPGAs. It was possibly the worst ever experience of my life to get that one going. And then the entire thing was missing a few bytes of memory to fit the entire character set in it... A configurable crossbar is already quite common in embedded systems, though there isn't much use for them in a general purpose CPU I guess since the DMA controller is in charge of those things.

The on the fly FPGA reconfiguration is currently still quite the hassle, at least based on my personal experiences with it. The hardware support for it is quite ok by now. Its mostly due to the software tools not really supporting it. If you manually write the files and tell the floor plan management software to leave a gap in a certain spot you can usually fit it in. Now I don't think you'll really need a new OS for it, but the drivers for such a thing would get quite complicated if the FPGA cores aren't standardized. And that folks is why I ran away to do analog electronics!

True, there is a need for speciality IP blocks though for those few applications where it does matter. But at that point using an ASIC is probably not the best choice.

What I do expect to see, given the recent Intel announcement, is FPGAs showing up more and more as co-processor. There is a lot of speed to be gained by reconfiguring the hardware for when you have to crunch through a few gigabyte of data like decoding/encoding a video stream or running a query on a massive database. The only real "speciality" processors that you do still see showing up quite often are DSP processors, but that's simply because that is a market with a rather high demand for cheap chips that can process a lot of data quickly without having to care too much about anything else.

But if you're running into a low volume special purpose application, just throw an FPGA at it. Saves you the headache of working your way around ASIC design errors afterwards, and you can transfer all the blame for hardware failures to Altera, Xilinx, etc.

AGAIN, the clones are not defective and behave like the standard product from a software point of view. Detecting them is tricky at the best of times, so you can't do it by accident. So yes, by changing the device ID to 0 you are breaking the law.

And DEC priced themselves out of thed market in combination with horrible management making terrible decisions. If you can't quite decide which business you're going to aim at and then have guys like IBM chasing you down you're not going to live long.

To be frank, I'd use the clones if I had a choice. The clones often perform better and are more reliable. FTDI makes crappy chips, have you ever used one? I found on many occasions that half-arsed attempts using software USB libraries on low end microcontrollers worked better than FTDI products. Another thing FTDI has going against it is that the moment their driver crashes it often takes the entire Windows USB driver with it. Which is fine, until you realise most keyboards and mice these days work through USB. So not only is FTDI expensive and unreliable, their documentation is horrible at the best of times, and their chips don't pass any ESD test, not to mention that the diode test setting of a household multimeter is enough to fry the internal voltage regulators on these things. The main reasons to use FTDI chip are: you have half an hour to design the hardware, you don't know about anything else, student lab sessions, torturing the academic staff supervising previously mentioned lab sessions, and your boss told you to do so. And while I could continue my rant about FTDI, I'll keep it at this: Don't use FTDI chips in your products, use the cheapest MSP430 you can find. Not only is it cheaper, it performs better and you can put quite some intelligence in it. And TI is nice enough to deliver chips that can withstand existing in a world where non-neutral charges exist,.

Also the ESD test is also one of the best ways to detect if its a clone or not in the case of a FTDI chip.If it passes its most likely a clone...

Throw a large block of solid argon in a sealed container of water.

Now to be serious for a minute, give me whatever you have under your kitchen sink and 10 minutes and I'll blow up your toilet. Drain cleaners ought to be banned by the logic of H2O2 can be used to make bombs, sure its a potent source of oxygen for chemical reactions but so are many other house hold chemicals. And lets not forget how damned easy it is to make nitroglycerine. You might not survive it but its not like its hard to do, and the chemicals separated are quite safe to handle. So yes, lets ban glycerine as well!

The main victim of these dual-use laws are industry and research.

They're not THAT hard to get, just about every large test equipment supplier sells these things these days. Either way, most high speed cameras don't have the necessary imaging sensor for this type of tests anyway, so the export ban is kind a useless.

Take your political news to a political news website, we really don't give a damn about American politics. Returns Slashdot to its former glory, we want technology news!

It is not, I'm familiar with cases like this. Its not like manufacturers trying this sort of thing is new, but its the first time a large one has tried it on this scale and abused Windows Update for it. (Microsoft will have their heads for this by the way based on their response to this.) But in all cases I know about it ended badly for the manufacturer. So yes, when I am stating this I am serious about the legal implications for them. It only requires one large company to have lost a significant amount of revenue because of this and they hang.

And again, you show you have no clue how these "clones" work. They are not defective, the driver on the other hand is... and they admitted this was their goal already so stop bothering to defend them. They lost and now they have to pay for the consequences. I can also tell you that most designers I know have already stated that they will never use FTDI hardware ever again because of this: so not only did they enter very slippery ground in a legal context, they alienated the engineering community.

And then there is another issue, after this one FTDI deserves to die. They broke the gentlemen's agreement within the electronics community about interfaces and bus systems. Bus systems can be patented (see IC), but you should never use that patent in an offensive way except if people are conflicting on your address assignments or are going "too far". Either way, this case does not apply here because we're looking at interfaces, and those are considered free-for-all. Its very common for IC manufacturers to make devices with the exact same specifications and a compatible pin-out in their own technology by going around the patents. These devices are perfectly legal and often support the same software drivers if PC interfacing is involved. A funny side fact is that many of these "clones", as you might call them, are in fact superior in performance compared to the original. It reached the point where claiming pin compatibility is a common marketing goal, this is good for all manufacturers involved because large companies will only use parts that they can source from multiple suppliers. So yes, by doing this FTDI broke the cease fire/gentlemen's agreement. This also means they'll probably be at the receiving end of several lawsuits involving their implementation of competitor's bus systems.

No matter how you wish to claim this is right, they still willingly gained access to somebody else's property and disabled it. This always has been, and still is a criminal offence with jail sentences and heavy fines. In fact considering this qualifies as a severe case of computer crime in many countries they might be looking at sentences of a few decades and fines that are multiple times their entire company's revenue.

And you are simply displaying you do not know the electronics industry at all. All drivers are written for a generic series of devices, any driver not written in this fashion is a waste of developer time and generally quite crappy. (See all those WiFi drivers from 10 years ago.) This is especially the case considering we often modify devices once they're in production, so we need to support several versions with a single driver that supports all. By writing it in a manner that its willing to work with almost anything that fits the specs you save yourself, and above all the user, quite some trouble. And if you have a particularity well working driver it'll be adopted as the de-facto standard. Do you think those Microsoft HID drivers started out in their current shape and form? The nice parts I'm referring to started out as support for Microsoft's own hardware line, they never complained about people using those for a wide variety of reasons. The main reason being that by turning your driver into the standard you gain quite some market leverage, you are the only one capable of signing the new versions of it. So if the functionality needs to be extended you are the only instance capable of doing it while maintaining good support for the older devices.

So no, these drivers aren't specific to a device made by a specific manufacturer. They are specific to a particular hardware-software interface that anybody can freely imitate that infact became the de-facto standard for USB-Serial interfaces. Now if they had stopped at detecting and just saying "sorry, can't work with this" they might have gotten off just fine depending on the jurisdiction, but they went ahead and actively bricked devices. And calling this freeloading is hardly the case, or do we forget that FTDI is "freeloading" on multiple other semi-conductor companies by providing default implementations of their chip-to-chip communication interfaces? If you're going to approach the electronics industry with this mentality you're going to get sued out of existence as a company within years.

This is not an update, this is a very specific modification to damage and disable equipment. There is a very large difference between the two from a legal point of view. So no, they f-ed up and now they have to pay for it.

This is why we can't have nice things. First of all, drivers aren't unique to one specific device. I can name countless devices from major manufacturers that piggyback on the driver originally made for another device. There are various reasons to do this, and it is perfectly legal to do so as well. One of the extreme examples are Microsoft's HID drivers, pretty much everyone uses those and many of the uses are for just about everything except HID devices. They have an excellent Bluetooth implementation, and its quite easy to implement a key for something you won't find on any existing keyboard and use that as trigger for another program. And that is only one of many uses, so yes it is a very common trick to piggyback on drivers to save costly development time and it does not infringe on any rights.

So it doesn't matter how you wish to interpret it, this is willingly and unlawfully modifying and disabling another person's property. Take it from me, I have more than ample experience in both reverse engineering devices and detecting bogus components. You can't accidentally check for this one considering what you have to do to detect these counterfeit chips, they were made to work with this driver. You can't do this by accident, nor can you claim this is in the name of safety since all these devices must pass EM compliance and safety tests. So get your head out of your ass and come back to reality, or stop working for FTDI (which is an awful company to be honest).

It was not malfunctioning, it happened to use the same driver. This is a very common situation, and willingly disabling that is in fact an antitrust lawsuit waiting to happen. Before you wish to claim something is malfunctioning I suggest you learn how the electronics industry works.

What they're doing is in fact even worse than trespassing, they're unlawfully gaining access to systems that aren't their property and changing configuration settings which lead to the system being disabled. That's not only trespassing, but willingly causing damage while digitally trespassing. (The latter has far higher punishments and fines on it in most countries by the way.) And a surgical robot refusing to work with non-OEM instruments is a very different situation. The surgical robot will not modify the configuration of the non-OEM instrument to disable it...

Refusing to work with a device can be legal under certain circumstances, modifying the device to disable it is not and is in fact a crime with a jail sentence attached to it.

There have been enough legal precedents for this one, if you willingly disable a functioning device of another manufacturer then at the very least you're breaching fair competition laws.

You have no idea how the electronics industry works clearly. You go to a distributor and you buy components, you have no clue where they came from, sometimes even the distributor doesn't know. Considering the profit margins they're used to dealing with weird ultra cheap offers, and they can't afford to ignore them. It can easily be that the people who designed and manufactured the device thought they were working with genuine FTDI chips. I've run into a few cases where I bought reels of high end components, and what I got was cheap Chinese knock off components, and this was from a major European distributor that normally doesn't trade in these types of components.

So by all intent and purposes, this is willingly damaging other people's property and they should pay for the damage. They have no right to do this, if they wish to do something they should go after the people who reverse engineered it, since the fab most likely doesn't even know what they made either.