OS X and Linux support CDC out of the box. RPi is not an OS.

Sure. A $2 MCU with a USB Device and a UART will do it just fine, and you can have it implement the comm device class, so that on Windows Vista and up the drivers come with the OS. CDC is supported out-of-the-box by both Linux and OS X.

Those chips make most sense if you have a legacy MCU that doesn't come with a USB Device peripheral. Otherwise, emulating the FTDI chip is only somewhat useful for compatibility with Windows XP. If you don't need to connect to XP, you can implement the communication device class, and then Windows Vista and newer has built-in drivers for it. The only reason I even bother using the FTDI protocol is to support XP-based customers. We have a cutoff date for that, and that date is near.

If you buy from legit vendors (DigiKey, Newark, Mouser, etc.), you're not gonna get counterfeit FTDI chips. Period.

If you want it cheap, there's really no point in even buying the FTDI-to-serial chips, counterfeit or not. A modern MCU with a USB slave will cost as much as the converter chip (or less!), and you get the MCU for free. Since most things need the MCU, that's like a no-brainer, really. No point in making counterfeit chips, just use your MCU.

Not only that, but the driver makes the assumption that the PID change is actually effective. I have implemented the protocol on an MCU, but still use a physical FTDI chip literally glued to the board but non-functional as a token against any claims of impropriety. The MCU pretends that a whole bunch of config requests that would do EEPROM writes and such "succeed", but all that's modified are values in RAM, and those values aren't used for anything else.

I actually ship a device that implements FTDI's protocol in an MCU, and simply glue an otherwise unused FTDI chip to the board as a physical "license token". It's more reliable that way, and I can offer way better buffering and sync than the FTDI chip would allow. As long as they don't use real crypto in their chip, I'm not worried - an afternoon with a protocol analyzer should solve any issues. And if they do use crypto, then I'll probably have my buddy decap the chip and look for the private key bits on the die.

I don't think it'd be inefficient at all if you use a modern compiler. If the compiler happens to notice some loops and vectorize stuff, it may be actually way more efficient per clock cycle than the original machine was.

Hungary is, sadly, turning into authoritarian regime focused on maintaining the power of those at the top. Anything that feeds their spending habits is on the table, I'm sure. We should expect more news like that coming from Hungary :(

On a modern cellphone, the whole thing could probably run in the baseband processor :)

It doesn't matter what the lawmakers' intentions were, the truth is that such laws will end with you killed or your car damaged. First hand experience.

A modern Intel Mac will boot into FreeDOS, no problem. It's more like a PC without the BIOS Setup, and supports booting straight into OS X :)

I've had plenty of success with Crucial and their M500 and M550.

If there are cars ahead of you blocking the intersection, how would you ever clear it in any time? Now you might argue that you shouldn't enter the intersection if you can't clear it. Great, so you'll end up rear-ended, or killed by the irate armed idiot who decides that you've sufficiently annoyed him. The law has to reflect the reality, not someone's lofty but patently useless desires.

"If the light goes red before you clear the intersection you ran it." That's false in quite a few U.S. states. In Ohio, for example, if you're in the intersection when the light turns red, you're merely required to clear the intersection ASAP. That's all, and it's perfectly legal to do so.