WallWextra

Do you consider this likely?

It is true that exactly the same commands are sent to the genuine and counterfeit components, but on genuine FTDI parts it does literally nothing. Here is a commented decompilation: https://twitter.com/marcan42/status/525202516816842752

It is very hard for me to picture any purpose this code could serve other than deliberately bricking counterfeit devices. FTDI has offered no explanation. There were some tweets (now deleted) from FTDI which didn't outright admit to it, but rhetorically asked for a better way to fight counterfeits.

USB is sort of a baroque and unpleasant protocol, and much more of a pain in the butt than RS232. But it is probably less of a pain than depending on a supplier who will deliberately damage end users' property in the field and insist they did nothing wrong, before insisting they did nothing at all in a denial that insults the reader's intelligence.

Weren't they written in greek?

No, it's accurate to describe reality rather than hypotheticals.

Meanwhile, in reality, C is a compiled language.

This could be done mostly transparently, with the encryption in the memory controller. Addresses and data are already scrambled with a (non-cryptographic) scrambling code for EMI reasons. Of course, a sufficiently fast hardware crypto core would be required.

EDIT: Also, I forgot that the last generation of consoles (and I assume the current) have transparent encryption of main memory.

Also that they like ramming it down everyone's throats.

MIPS had trap on overflow.

The basic problem is that this was chiefly of use to companies making hardware, which is a highly competitive industry with very thin margins compared to software, so they won't pay for anything they don't have to pay for. Only in software are people fat and happy enough to actually fund open source development.

Avoid the hardware business.

I do not understand. Where is the memory backing /proc/pid/cmdline and who in the container has a COW copy of it? If nobody, how can reading it cause more allocations in the container?

Sometimes I wonder how much better off we'd be with something exactly like x86, but with a stack that grows upwards.

The 68k address/data register split is ugly, and the double-indirect addressing modes probably cause more difficulties for a fast implementation than any x86 quirk (though this can be cured with R&D money).

I wouldn't mind more focus on accuracy even among quartz movements. Development of temperature-compensated quartz watch movements seems to have stalled, and most watches with such a movement are only available on the Japanese domestic market.

The typesetting quality of web browsers doesn't even compare to that of TeX, which uses a dynamic programming algorithm to minimize the "badness" caused by line breaks in various places. This is aside from TeX's ability to typeset math.

The unoffical reason is Xamarin wants too much money.

They did recently announce two fab customers, an FPGA manufacturer and then something else that is also low volume and obscure. So maybe the DoD can make it worth their while.

It seems like this could pose some problem for the DOD, since IBM was the only trusted foundry with a cutting-edge process for logic. Presumably they don't want the government of Abu Dhabi fabbing chips for them.

I do believe SOI has some cost disadvantage, and this contributed to its unnpopularity. The POWER8 chips are huge and probably can't be made cheaply, or to consume sane amounts of power. IBM would have to take a very thin cut to compete with Intel.

Perhaps this post is already buried, but if anybody is reading, do you know where the row-selection and precharge latencies figure into the numbers he gave? He makes no mention of them.

I'd really rather not have my toaster running, e.g., bash, since a toaster will never get firmware upgrades.

Gosh, what a collection. I always feel a little sad when I see collections like this up for sale, since it's obvious that somebody loved them a lot.