Doesn't matter due to the Due Process Clause of the Fourteenth Amendment and the Incorporation Doctrine.

Except for this:

...which is completely not true. If you serve up ActiveX controls, then yes, you need IE; however, there's nothing inherent in IIS or ASP.NET that requires IE on the client side.

Given the existence of the placebo effect, in what way do you suppose that the market -- consisting of individuals who operate on limited information -- will be able to tell the difference in efficacy between a non-steroidal anti-inflammatory and acupuncture? Especially given that so-called "alternative medicines" such as Zicam can effectively compete against science-based medicine even with FDA regulations in place? Do you propose we go back to the patent medicine era?

The reason we have the regulations we have by the FDA is because we tried working without them and, unsurprisingly, people died and a lot of unscrupulous hucksters made a lot of money. We have the same thing going on now with homeopathic medicine. What we need are good, functional, and smarter regulations, not merely fewer or more regulations.

Oh, and for what it's worth, FDA trial costs aren't even remotely the largest cost of a drug. Check out this study and its references. Marketing, in fact, is the largest cost of releasing a drug. Trials are considered R&D costs, which marketing dwarfs -- and bear in mind that according to this study and its sources, 13.2% of those R&D costs are in marketing-related trials. Please check your facts before posting; this took me all of a minute with a search engine to find in PLoS.

What's funny about this is that we *already* have this setup. SIPRnet, JWICS, and other networks running on the Defense Information Systems Network (DISN) are already segregated from the public Internet by an air gap. This is actually required for any classified data. Information can sometimes enter a classified network from the outside world, but the mechanisms for doing so are extremely circumscribed and a massive amount of analysis has to go into making such systems "provably secure." In practice, NIPRnet and SIPRnet require different physical terminals. That's why we have things like the presidential Blackberry, which is essentially two Blackberries in the same case with a physical switch to swap between the unclassified and classified systems.

As for utilities and the like, sure, you have two options. One is to airgap the communications network, which is what I'd advise given the shoddy quality and poor security record of SCADA systems. The other is to use secure communications from the transport layer up and using defense in depth principles. Of course, that requires building security into the system from the ground up, and very few companies and people are willing to do that. In light of that, an airgapped network makes sense. If a truly independent network isn't needed, every backbone provider is more than happy to provide MPLS virtual networks for the right price.

In the end, though, I think the problem is that utilities don't want to spend the money on what they feel has no deterministic ROI (cf. trying to get a company to buy a disaster recovery system). This is rational self-interest, especially when you consider the explicit guarantee of insurance and the implicit guarantee of the government for critical infrastructure. The solutions are simple: enforce proper controls through regulation or nationalize the infrastructure so rational self-interest is removed.

ABAP is sufficiently similar to COBOL that I think it'd be fair to call it a relative in the same language family.

And if you think the SAP user interface is bad, may I introduce you to BAAN or Daly & Wolcott, both of which make SAP look like god's own gift to UIs?

My company runs SAP as its ERP system, and the project was only a little late -- but on budget and met its initial goals. We were migrating from Daly & Wolcott on an AS/400. Then again, we only have about 260 employees, and we did a fair amount of the work using our own people. We didn't just foist the whole thing off on consultants, as is most often the way.

As someone who writes integration code with ERP systems, I can say that for all the problems SAP has, it's not nearly as terrible as others. I've worked with CORRIDOR, BAAN, and Quantum Control MaxDB, and all of them are terrible, horrible monstrosities that barely work, are wildly oversold, have terrible user interfaces, are mostly undocumented or improperly documented, and are apparently designed to be as difficult to interact with as possible. Add to that stupid programming decisions (CORRIDOR uses materialized views for all DB work as opposed to stored procedures; Quantum Control loads DLLs by reading them into memory as data then jumping to their entry points, causing massive issues with DEP and weird crashes periodically) and it's amazing anyone buys these pieces of crap. By comparison, SAP is a thing of pure beauty, with its (usually) correct documentation, rock-solid stability, and actual supported interface points (RFC and IDOC).

The problem is that ERP systems all stink. SAP just happens to stink the least.

You write the code that actually does the queries as stored procedures in the database, then write a DAL that essentially works as a database driver. Your code does nothing to the DB other than requesting that it execute an SP, and the SPs can be tuned for the specific database server.

Of course, if you use a persistence framework that makes SPs difficult or impossible to use or if you started out on a database without SP support, you're screwed. This is all the more reason to start with the free versions of DB2 or SQL Server during development and scale up to the higher performance (and cost) versions as needed. Note that I've explicitly excluded Oracle from that list, as I've never once seen a production Oracle database ever reach the performance of... well, any other database server, really. I don't doubt that Oracle can be made fast; I just doubt that getting the personnel who know how to do that and paying them to do so is worth the cost compared to easier to use, less expensive, and faster out of the box systems like, oh, DB2 and SQL Server.