That's one thing I don't get about American health care though. How is it that no state has implemented universal care?

Check out the history of this in Tennessee and Massachusetts. (The fact that you're unaware of it will tell you something straight off.)

The mileage-adjusted accident death rate of automobiles has dropped significantly with the added safety features.

That's what I meant to say: the accident rate has stayed very roughly the same but the injuries and the severity of the injuries to the occupants are down.

conserving energy doesn't reduce energy use, but spurs economic growth and more energy use

This fits with an observation by insurance companies (or at least mine, USAA) that building safer cars results in people continuing to drive them to their preferred safety margin. We still end up with about as many crashes (but injuries are less).

I'm using Debian stable right now as the solution for my particular requirements (development desktop that's a good Xen Dom0), but I'd much rather be using a BSD (the first machine I bare metaled was BSD 2.x onto a PDP-11/44 in 1981 (sic)) or Solaris (it took me most of a decade, but I eventually got over their switch to AT&T :-).

The big problems with FreeBSD when I made my decision were no Dom0 support and an immature ZFS, and the problem I've always had with Solaris is solid mass storage device driver support, at least for vaguely affordable controllers that don't require a PCI-X bus. E.g. when I last checked nVidia SATA chipset support was iffy (which was odd since a classic workstation they shipped had a rebadged Tyan motherboard with a nVidia chipset; I've got two of those Tyans in prodution and they're rock solid ... with Windows XP :-( hey, I'm not willing to put my parents on Linux or whatever quite yet )).

This may have improved since then, but be sure to check for problems in the field.

Having dirt between you and the bullets is good.

True enough, and it is best to remember the difference between cover and concealment ... but perhaps it's best (in this sort of thing) to be somewhere no one is shooting at. If you must shoot, then fire only once---very hard to tell where a supersonic bullet comes from due to the sonic boom it makes---and then "scoot".

Ignoring for the moment that I generally grab what I might want from the net in the future as I find it (too many sites go "poof"), the only context in which "they" would turn off the Internet would be one of dire civil war (e.g. worse than what recently happened in Iran).

I doubt I'd actually be in a foxhole (that sort of implies you're fighting by the other side's rules), but I wouldn't take it laying down, nor would a lot of people like me.

Did I miss some way where it would be easy to hard wire a fiber connection to a boat when it wasn't near land?

Heh, no, I was just thinking, a supercarrier is often compared to a small city, it's got the population and a lot of technical expertise. You could imagine one having a couple of Google/Sun type shipping containers stuffed full of computers tucked away in different corners (not likely a problem with powering them!) ... except for that minor detail that they're going to have a seriously constrained link when out of port.

Just thinking off the top of my head, this would be an interesting challenge for caching and pre-fetching, the latter to use otherwise wasted bits when the link isn't so busy.

This makes a lot of sense, the military has unique requirements of all sorts, from security to e.g. their inability to hook up an aircraft carrier to fiber (except while at dock) to their need to carry both operational and personal traffic (the latter to keep their people in touch with home) over necessarily constrained links.

There's lots of non-military uses for wireless or satellite links. If you need to carry both operational and personal traffic, you establish multiple links and keep the networks separated.

But won't there generally be in a lot of circumstances just one physical (radio/satellite) link to "back home"? So those multiple links must still go over one pipe and very possibly one with high latency. I'm sure there's useful stuff than can be done here to make that sort of thing work better, and that might help the civilian users of satellite broadband as well.

The military's requirement for security is most certainly not unique, either.

They're rather unique in the consequences of security failures, at least when combined with their often ad hoc situation with links, e.g. in forward bases, and in a lack of network specialists that far forward.

There's also the social links back home, where civilians send forward based troops all sorts of useful stuff including satellite stations. Most of the rest of the national security community has it a lot easier.

This makes a lot of sense, the military has unique requirements of all sorts, from security to e.g. their inability to hook up an aircraft carrier to fiber (except while at dock) to their need to carry both operational and personal traffic (the latter to keep their people in touch with home) over necessarily constrained links.

I like the bit about "self configuration capabilities to ... reduce the need for trained network personnel and lower overall life cycle costs for network management". While the current state of the art keeps us well employed, things could be easier. Heck, the more the systems I maintain for my parent self-configure, the happier I am.

A single data center apparently without even a geographically distinct failover site is about as far as I can imagine from being a "cloud". Old fashioned best practices in the form of having two or more sites each capable of handling the entire load would have prevented this particular mess, let alone classic cloud approaches like that of the Google File System (GFS) which keeps at least three copies of a file's contents.

(Granted, if you're storing vital stuff in GFS or Amazon S3 you still have a logical single point of failure (e.g. a mistaken delete command) and therefore you aren't freed from the duty of doing your own backups, but that's a separate issue.)

Or we could just say that trusting Microsoft for anything is relatively unwise compared to other "higher tier" companies. Or that if you're depending on a service provider that's massively laying off staff you need to take action before something seriously ugly happens, because it likely will.

I'm sure these were as far as the bank could tell proper and secure transactions.

Based on what? That the thief had the routing and checking account numbers? Those numbers are so easy to get it's equivalent to no security at all.

Agreed.

But that's how checks themselves work. In fact, a number of companies now digitize and then destroy the paper checks you send them, see the Check 21 Act for more details.

It's up to you to catch mistakes as well as fraud. Heck, I can't remember if I've ever gotten a bank statement that didn't have a form on the back for you to fill out to balance your checkbook.

Obviously the account of this guy was too complicated for that, but as others have noted, it's a bit unlikely he was personally filling out 1,000 checks per month. This is the sort of thing you hire a bookkeeper as well as a CPA to manage.

And who does his taxes? It's very unlikely he does them on his own, and if he's not proactively managing his money he'll pay quite a bit extra to that CPA who will have to do a fair amount of forensic accounting just to reconstruct the last year's taxable transactions. That's an equivalent of the classic nightmare of a CPA being handed a shoe box full of receipts, etc....

How about if automated clearing house transfers only worked if you'd authorized the payee in advance? This would probably mean some practices would need to change, but isn't that better than what we have now, where anybody you've ever written a check to can scoop money out of your account any time they want?

Indeed. Practices would have to change, and given the flakiness of people that would be impractical, plus it would cost a lot of money.

How many would fail to proactively notify their bank? Plus they'd have to tell the bank correctly some magic info identifying the payee. This would really only work if they were the ones to initiate the whole thing through the bank instead of through the billing company. Wikipedia says that in Western Europe both methods are used, frequently to the exclusion of paper checks altogether.

If you want to keep the current system (at least in part) but insert your authorization requirement, then how many people, if called up ($$$) or otherwise asked in some way to authorize a payee, would either reflexively OK or deny it?

In practice (and not just in the US), everyone works on the assumption of honesty and verifies after the fact. Since you really really should reconcile your accounts each month to catch honest errors, extending that requirement to catching fraud is the cheaper approach.