As a matter of fact, I'm releasing a product soon that falls exactly into this category. I specifically chose to keep the VID/PID unmodified, as the product has a mode where it needs to look like an ordinary serial port.
Sure, I could get modified OSX, Windows and Linux drivers to teach it about a new PID so that ordinary comms software works, but it's far simpler and less risky for a small guy like me (we're talking a few hundred units total) to just go with the flow and make it work with the generic drivers everyone likely already has.
You're technically correct that the chip hasn't been physically damaged. However, it's effectively dead, and FTDI's EULA revision makes it clear that they intend to render non-functional any clones they detect:
Use of the Software as a driver for, or installation of the Software onto, a component that is not a Genuine FTDI Component, including without limitation counterfeit components, MAY IRRETRIEVABLY DAMAGE THAT COMPONENT.
I recently built a big pile of boards with an FTDI USB chip on them, as part of my retrogaming hobby. I bought from a reputable source, I think. But if it turns out that I got an illegitimate batch of FTDI chips, I now own a pile of bricks until I pay to get them reworked. I don't know yet, since I haven't tested them in Windows with the latest driver.
Counterfeiting harms the original producer of the chips, and this extends the harm to OEMs that use the chips (who may or may not be innocent), and their customers (who most certainly are innocent).
I can't see how this is a good thing for anyone.
As someone said recently at work: "Deposits to the 'trust bank' are always small. Withdrawals are always large." In other words, it takes years to build trust, but you can obliterate it in seconds. FTDI may have done just that.
My work laptop has 4GB of RAM on it and Windows 7 and it runs just fine. The only thing that slows it down is when the corporate-mandated management scripts run and start pegging the hard drive with virus scans, audits and the like. More RAM wouldn't help that. Switching to an SSD did.
According to Resource Monitor, I'm using about 3GB, with 850MB of that used as cache. A bit over 1GB of that is Firefox.
So, yeah, I could see 1GB really sucking when used with a modern web browser and many tabs open (like I do). 4GB, though, hasn't really held me back much.
Apparently, at least part of Vista's memory woes stemmed from the poorly tuned "SuperCache" feature, that would aggressively try to pre-cache data in RAM. Its appetite was apparently too large. It apparently also didn't manage its disk buffers very well. (This is all third or fourth hand knowledge and so could be shaky. I've never run Vista myself. If someone has more details, pipe up!)
Thank you for the detailed, thoughtful reply, including all the numbers.
Ah yes. I knew there was a term for it. It's been a while since I took my thermo class. Specific heat is normalized to mass, though, and both granite and basalt are more dense than seawater. Granite is ~2700 kg/m^3, basalt is ~3000kg/m^3, while seawater at high depths is around 1050kg/m^3.
When you factor that in, water still wins, but only by a factor of 1.5 to 2.
Allow my naivete to shine: What's the temperature of all of the rock that water is in contact with, and what's its thermal capacity relative to the water? Could it be that it's slow to warm as you need to warm all the rock it's in contact with?
Oh, yeah, I definitely remember the pain of bank-switching vs. segmented memory. I was there and programmed both. It stunk.
At least the Apple ][gs could directly address 16MB, although the 65816's addressing modes I hear were less than awesome. I must admit I never wrote any native 65816 code.