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.
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!
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.
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...
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.
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.
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.
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).
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.
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.