Given that even a 25GB BD-R(which is more expensive per unit than the mass produced pressed flavor) only costs a dollar or two, with case, the economics of using SD cards are a trifle questionable...

The, er, superb performance of the diskless PSP Go probably didn't help. And that was a design that axed a disk that everybody loathed and mocked...

Our old friend the burst cutting area can fairly trivially assign a machine-readable unique ID to a disk.

Assuming a locked console(not implausible, unless the next generation is weaker than the present one), it would take next to no bandwidth and local storage to keep a local database of 'authorized' disks, refuse to play any others, and, upon encountering a new disk, query the server to insure that it hadn't already been authorized elsewhere.

If you had to work with no bandwidth at all, a modification of the disk format, allowing the first console that encounters the disk to permanently modify it in some way(eg. tiny sliver of writeable area, that the console writes a signed block of data to on first insertion(and verifies on subsequent insertions, so you can't just cover it with tape).

Not 100% foolproof; but you just have to make resale uneconomic...

Now, I wouldn't put an American banker or insurance company in charge of somebody else's counterfeit nickel; but surely the IMF isn't much better...

I'll be interested to see if this arbitrary TLD nonsense merely expands the TLD-ghetto that exists beyond the top few into a nearly infinite morass, or whether the sheer confusion throws us back to a google-based equivalent of the old days of 'AOL Keywords', where virtually everybody has abandoned any hope of knowing the URL, and just plugs in some stuff in the search bar and hits enter...

In the imaginary humans-are-rational-animals land, I'd agree with you.

Empirically, I'd strongly suspect that only relatively strong tugs of either appetite or repletion drive most people to either get a refill or discard a partially full cup. You just sort of suck on the straw until the fluid stops coming out, without thinking about it much, across a surprisingly large set of cup sizes.

The consumer psychology research people seem to consistently be able to pull hilarious stunts in changing the amounts people eat just by changing their cutlery, or using different sized plates, or changing whether or not the waiters clear away used dishes in an 'all-you-can-eat' scenario...

Any bets on how much hand-wringing about 'big government' 'nanny state' and 'paternalism' there will be now that Bloomberg is targeting large sodas rather than the terrifying marijuana, assassin of youth?

I honestly don't much care for either reefers or Fructose-Extreme Big-Gulp Edition; but I find it endlessly curious how mere time seems to change perception of given public health and public safety crusades. Some city tells smokers to do it outside, or restarauants to cut down on their trans-fats, on pain of some paltry fine and the editorialists are ready to tell you that fascism has finally come to America; but the ones that get hunted down by actual cops and sent to real jail? Apparently not a concern...

These 'ISP record' attempts are doubly pointless(in addition to the fact that they never indicate the slightest enthusiasm to actually offer something even approaching that speed, at any reasonable price, to any of their customers) because they typically are markedly slower than the already-standard high-speed interconnects that tie more central sites together.

If you are going to play pure speed-racer games, it really makes more sense to just have a set of categories based on medium(eg. 1km legacy POTS copper, 1km legacy coax, 1km single-mode fiber, 10km of each, etc.) There are real engineering challenges, and nontrivial advances, in the ability to shove more data over a link of a given nastiness; but 'records' based on unrealistic location stunts are just pointless(Telco B could just pull some fiber to a convenient school tomorrow and pull off a 'first-to-deliver 10,000mbps internet connection! and Telco C could just pull a few more strands and deliver twice that, and so on).

If you want to boast about how cool an ISP you are, you need speed, breadth, and price. If you want to boast about your super-sneaky transmission methods, just tell us about the medium, the distance, and the bitrate; but this nonsense is a pure stunt.

Oh, I'd be the last to disagree with the notion that terminal servers suck. I have the pleasure of fighting with several on behalf of a client.

My point was just(in response to hairyfeet's point that 'cloud' is 'thin client' all over again) that 'thin client' didn't actually change staffing patterns too much(slightly fewer desktop hardware monkeys, though not too many fewer because thin clients still have to be deployed, cabled, etc. just not drive-swapped as often); but an increase in junior server admins because terminal servers require all the babying of a desktop(with the additional quirks that come with desktop applications that aren't validated or supported to run multiple-concurrent-user on server OSes. Also, nothing brings out the true horribleness of common printer drivers quite like running in an environment where one user's print job can crash the spooler for everyone and you can't 'just reboot'...). A modest change in staffing patterns; but not actually as much of a reduction in staff as one would expect.

In a true 'cloud' scenario, though, most of what you are paying for(and enduring the risk/lag/bandwidth demand of offsite delivery for) is a reduction in application management. All those exchange admins, application server jockies, low-end DB guys, and so forth. In the (at present hypothetical) 'pure cloud' environment, you'd pretty much have nothing but the junior techs who deliver replacement computers to users who need them, and rebuild the stock image every six months(assuming you haven't gone full Chromebook or something, in which case that happens remotely as well) and the network guy who makes sure that LAN and WAN keep talking to one another...

While I expect that the data security/control concerns and UX deficiencies will be(if anything) worse with served-from-offsite-across-a-WAN-by-who-knows-who 'cloud' stuff than they were with served-from-our-datacenter-over-the-network-by-IT thin client stuff, it does seem likely to me that the impact on local IT staff will be different.

In my rather painful experiences with thin clients, the client hardware itself is practically bulletproof; but the terminal servers are more than touchy enough to make up for it. Each one combines the worst aspects of managing a desktop and a server and the whole exercise largely ends up saving you a modest amount of money on clients that you spend on server gear instead.

With 'cloud', however, the care and feeding of the application server is(at least in theory) also abstracted for you. User plugs in URL, user receives email. This generation often doesn't feature particularly 'thin' client hardware, running a contemporary web browser is far more intense than running an X11/RDP/ICA client; but you hide much more of the server complexity behind the vendor.