That's a really bad analogy. Peering at someone's credit card - even if it is under a napkin - is quite obviously very bad manners indeed. If you're saying unauthorised penetration testing is like peering at someone's credit card, then it's clearly wrong.

And speaking as someone who has his own little toy server out in the cloud, I'd very much prefer to do my own damn penetration testing, thank you.

You forgot to include lifetime costs for VA health care for surviving vets, who tend to have fairly difficult to treat injuries that would have killed people in prior wars.

This is why there's such a backlog in the VA.

No it's not. The majority of the people at the VA are mostly Vietnam vets with a few WWII and Korean War vets hanging on. Most of your Iraq/Afghanistan vets are under the age of 50, meaning they have their own health insurance through the company they work for. For example, ME! I've never been to a VA hospital. Never had to. I always had my own insurance.

As for the total cost, right now, it ranks at about $1.5 trillion for 14 years. Since the expensive part of launching million dollar missiles to blow up a $100 tent and fueling tanks that get gallons to the mile are over, the rate at which the cost is increasing is slowing substantially. It is unlikely that it will reach $2 trillion.

Either way, you said "wastED", meaning past tense. We haven't spent $2 trillion and won't for many years, if ever.

Finance guys are so cute.
I was an IT guy so....

For example a retail bank needs two tables in it's accounts database. One for the account, a second to record the transactions.
The DB needs a customer table (name, address, phone, address, ect), transaction table, account type table, account table, interest rate table, payee table, payroll tables (complete with more account data from other banks, employee names, etc) etc. There's a LOT of data involved, and this still doesn't include the cutesie stuff banks throw in like customer preferences.

The database may be queried by other databases (ie: the guy approving loans), but it is not actually a part of those databases.
Actually, different systems maintain different databases. For example the Internet Banking side will maintain it's own database. the ATM side will have it's own side. Then there's the credit card system, ACH systems, wire systems, the core system itself and others. All of these systems must interact with eachother. For example, the a customer may log into the Internet banking side, which will have to hit the core to get the current balance, EOD balance from yesterday, unprocessed transactions, processed transactions, interest rates, any messages from the bank, and so on. It also has to be able to inject transactions such as payroll into the core system, wires into the wire system and so on.
Of course, all of these systems are different. The ACH system uses a flat text file. The core is usually an UNIX based system with a terminal interface. The Internet Banking is probably an Apache Tomcat connecting to a MSSQL system. Then, there is the bank end that is comprised of DB front-ends, screen scrapers, batch files, transaction injectors and so on.

You could probably convince a bunch of PHB-English Majors your database is more complicated because you have six different, totally unrelated databases in the same file, but don't try that shit in front of engineers.
Not just different DB's but completely different architectures. And, of course, different states have different laws. For example, all states that take income taxes have a different method to pay them. Then their are business taxes, both federal and for all 50 states, loan laws, interest rate laws etc.

And there is much much more, but this is getting out of hand. Suffice to say that you have no friggin' clue as to what you are talking about when it comes to everything a bank does, much less when it comes to tying all those systems together.

Compare that to the ACA system which involves user data, finance data, what companies are available per state, what plans available per company, and an interface system to communicate between the handful of ACA authorized insurance companies per state and the back-office system. Many states run their own system. The government has claimed that their system doesn't even keep the data!

HealthCare.gov does a lot of actual calculations itself. Once it knows your location it has to ask several other databases for your income level, at which point it compares that income level to the poverty rate. This is step one of determining your subsidy. Step 2 is to query a second database for a list of plans in your area. The second lowest cost silver plan is the "Base Plan" which is the second number used to calculate your subsidy. That's not just a database query, it's executable code.
Everything you described here can be done within a database engine, making HealthCare.gov essentially a database frontend that reinvented part of the wheel.

Moreover the database front-end is probably the most complicated database front-end in actual production anywhere.
No. No it's not, or at least it doesn't need to be. I would say credit card authorization databases would be the most complicated, followed closely by the banks. There are also several customer databases that are outright huge. You have parts inventories for large companies and databases used by engineers designing various components for bridges, air liners, jet fighters, combat vehicles, electric cars, etc. Of course, let's not forget the databases used by Internet companies like Google, government agencies like the IRS, census, and the Fed, and the multitude of databases need to run our phone and communication systems. All of these systems require front-ends. The frontend my bank uses for their online banking system is more complicated than HC.gov and deals with a more complicated system of DB's on the backend.
If this is one of the most complicated database front-ends in existence, that is proof that it is designed and written by incompetents.

it's querying multiple completely different databases, most of whom weren't designed to be compatible with each-other. It all needs damn-near-perfect security. It needs to deal with complex legal questions such as what happens when Louisiana decides some insurer has been cheating a bit on some legal requirement? Is the desired result under Louisiana law different then Ohio?
So, it's the type of system you find running every bank in America, minus the need for international transactions.

(disclaimer: I've worked in Internet Banking Systems and the defense industry)

First, the cost of both wars was less than $2 trillion, making the 's' on the word "Trillion" misleading and dishonest.

Next, we have a government run, single payer, health care system now. It's called VA. How's that working out?

Dead reckoning - navigation where you have no accurate fix - has been around for literally hundreds of years, and it is spelled 'dead reckoning' - because it's reckoning (of position) without a live fix. When I learned to navigate small boats fifty years ago, it was still pretty standard - because sun sights are awkward, and in any case using sun sights alone you can't get two position lines at the same time, so you have to do a running fix (which involves some dead reckoning). Even in coastal navigation you can't always get bearings on two good landmarks at the same time.

You're not thinking at all, you're just emoting.

If you were thinking you would realise that drone strikes on a civilian population - on women, on children, on funerals, on weddings - recruit a thousand terrorists for every one they kill. Of course the CIA and the military promote this policy. More terrorists means more money for the CIA and the military, terrorism and counter-terrorism are inherently symbiotic. But foreign policy should not be dictated by the needs of inter-agency pissing matches in Washington DC.

I have never, ever bought an Apple product of any kind, but considering build quality the MacBook Air is probably better value for money than the very similar Asus Ultrabook which I do have.

I suspect because the part of their system which changes passwords is seriously overloaded. I'm trying to change mine, but so far can't even get the page to load.

In the modern world, only those who are harmful to society are financially successful. Sad, but true.

Quotes like this that make me miss the defunct Forum 2000. This sounds like a great quote from The Cube SOMAD.

I agree with the GP though. I recall a guy I used to work with who used hyperbole a lot. I recall that he once referred to a so-called "fiasco" which, upon deeper inspection, translated to him trying to schedule a conference call where he couldn't get the other people to agree on a time. Once I figured out his hyperbolic tendency, I could safely moderate the "disasters" he was warning of. I shudder to think what would happen if his emails are ever discovered for a lawsuit.

The whole purpose of these treaties are to carve out new opportunities for special interests and rent seekers to harvest wealth from the small folk like you and me. Whatever you think of the benefits of free trade, these treaties are created to prevent it, and for no other reason.

Right. And that is science!

I'm not disagreeing with you. The ISS is the only place to do that kind of science, which the parent you were responding to seems to think there is some cheaper way of doing.

I used these things. They really existed. And they made modern IDEs like Eclipse and IntelliJ and Netbeans and Visual Studio look really crude and primitive. The Lisp machines were horrendously expensive, though. The last one that the nice Government bought me cost £25,000 at a time when a Sun workstation cost £4,000. And so we really have forgotten what was possible.

However, the machines we have now are enormously more powerful than the machines we had then. My Xerox 1186 in 1987 had (I think) 8Mb of real RAM and about 80Mb of disk, and ran at two MIPS. My desktop machine at home has 16Gb of RAM and runs at 18,000 MIPS. We really could begin to run the big software development environments of the 'golden age' again, on machines everyone can afford. Clojure and LightTable are a real step in the right generation; but they're still a long way behind where we were thirty years ago.

InterLisp (and a number of other things coming out of Xerox PARC in the early eighties) had the same feature. You saved the running state of your system to file, you invoked the function (sysout). To restore the running state of your system from a file, you invoked (sysin filename). Essentially this was a memory dump of the heap, but it had the special property that the 'spaghetti stack' - the branching stack structure through which InterLisp managed multitasking - was implemented in the heap rather than as a separate structure, so loading in the heap also loaded in the stack, for all threads.

Obviously, in InterLisp as in Smalltalk, everything in memory was inspectable and editable, and when you edited a function that didn't mean editing and reloading a file, the source code was an in-memory structure. It wasn't entirely without problems - there were small semantic differences between interpreted code and compiled code (if I remember correctly interpreted code implemented shallow binding while compiled code implemented deep binding), so that when you compiled your code its behaviour could change. Also it was possible, if you added a comment in the wrong place, that it could change the semantics of a function. For example if you added a comment as the last form in a function body, that function would always return nil. Nevertheless in terms of programmer productivity these environments were streets ahead of anything that's commercially available now; and although I love LightTable and hope that it is the shape of things to come, even LightTable isn't a patch on InterLisp's DEdit.