They also wanted the MySQL customer lists, to migrate them over to Oracle tools.

Sun's hardware was, indeed, bulletproof. But at the end of 6 years, the extra money you spent on that single set of bullet proof hardware would have been better spent on 2 cheap sets of x86 hardware, with the second set 3 years newer and thus vastly more powerful, yielding an enormous improvement in available resources, with spare older hardware available for testing rigs or non-critical use. And their ongoing choices to develop their own processor technologies, combined with their decision to switch to AT&T style UNIX from BSD style UNIX, made cross-compatiblity and porting of open source software more and more difficult.

Sun and their developers created or helped foster some very useful technologies. But critical, "business school" type decisions actively hampered the use of their hardwe, ranging from the their old mishandling of the "OpenWindows" as a forked and proprietized and thus incompatible version of X11, to their propietary serial port connectors on hardware servers, to their misnaming of JDK RPM packages as a filename that does not even resemble the actual installed package name, etc.

Or the obligatory xkcd reference, "sudo make me a sandwich".

          https://xkcd.com/149/

> separate each platter and mount the platters on a lathe and mill them down to bare aluminium

Given the prevalence of aluminum platters with iron oxide coatings, this seems extraordinarily dangerous. Although, thinking about the possible thermite reaction this could trigger, I think that _would_ destroy the data.

Unless it's not. I'm afraid I've been handed several systems by military software developers that were never scrubbed before they were loaned to me for software projects. I did try to arrange a quiet talk with their IT personnel about their security practices, and on one occasion felt compelled to write a registered letter, with copies to their and our legal staff, to warn about the dangers. (There were poorly protect system passwords stored in plaintext on the system.)

I have to deal with this a great deal with systems being passed from company to company or releasing hardware between departments inside a company.

The "scrub" utility, built into most Linux distributions and available on the Knoppix CD and DVD images, works very well. The time taken really depends on the level of scrubbing. The "nnsa" and "dod" standard scrub options do take many hours, because they use patterns like all zeros, all ones, 10101010, 01010101, and then randomized data of various sorts. That's at least 5 passes over the entire disk, and disks are getting cheaper and larger. Given the size of modern systems with, that can easily take 6 hours to zero a Terabyte drive with reasonable hardware writing 80 MBytes/second.

Many people consider these standerds to be excessive, and settle for a simple zeroing of the entire drive as sufficient protection to save time. (Generating sudo random data for overwriting really slows down the process.) Even then, the big expense is connecting the systems up somewhere with the shelf space and engineer time to do it, and to verify that it's been done. Since so few people are willing to give up control of their old system until the new system is in place, you usually can't scrub them before the new hardware is in, and replacing an entire department means an entire department of machines to scrub. And some of them may be seriously screwed up and require engineering time to get the disks into a system that can actually read and write to them.

I'm afraid I went over the top here. You may mean well for your customers, and may in fact resist unconstitutional data requests. But there is a compelling amount of legislation that is aimed _precisely_ at controlling corporate data gathering, ranging from the tax code to the SEC's regulations about business finance to the HIPAA regulations about medical information, the TeleCommunications Privacy Act and its poorly writt4en regulations bout consumer protection, and the export encryption regulations of the department of commerce. Those are not merely about what you must turn over from current records, they are about what you must keep or what you must not publish.

CALEA is aimed at voice communications, and is not particularly relevant to this except that it was aimed squarely at controlling and preventing changes to business practices. Exemption or not for search engines, it prevented the use of new telecomm technologies that would prohibit easy wiretapping.

> All the existing US laws are about turning over existing business records and not about compelling you change your business practic

This is a *BLATANT* lie. The US encryption regulations are precisely about controlling corporate behavior, especially the encryption export regulations HIPAA, FISA, and the more fascinating regulations of the misnamed Telecummincations Privacy Act. And it *does not matter* that the request is unconstitutional, your servers can be shut down while the non-court-approved, unconstitutional Patriot Act request is shoved up your backside. And you *would not be allowed to admit it had happened*.

Any corporate president too stupid to lie better than that is too stupid to protect their client's privacy, or money, or electronic documents and should not be trusted to hold a spoon by the right end. Nice job costing yourself any customers you had left who read Slashdot.

They do go out of their way to please regulators and governmental agencies that can interfere with their business. The USA still has extensive regulations on the export of encryption technologies, regulations that could require compliance reviews and delay major commercial releases by months or force expensive splitting off of encryption technologies as separate packages requiring expensive, separate registration to download. This has occurred repeatedly with older technologies, such as the "3DES" and other password encryption tools used for commercial UNIX password handling.

Governmental access to the consumer's escrowed keys in an easily accessible location, namely Microsoft's databases, is critical to Microsoft's modern "UEFI" and "Trusted Computing" initiatives. The use of such a central escrow for client recovery of their own keys is one reason to have it, but the access for government or even business agencies for doing decryption of customer secured contents is another compelling reason to have it, and to centralize it, and to keep the access policies completely secret and unexamined by their own customers, which is what seems to be the case.

I've been technical lead and technical contributor on numerous such projects, it's an absolutely core part of my work. And it is incredibly difficult in large environments, where numerous groups have evolved distinct usage and workflows and are often very resistant to change. Coupled with the amount of money being managed in this project, and the military and security requirements, such a project is well beyond the capabilities of any group I've ever met.

Trust is not a sufficient factor, I'm afraid. Competence, and communications among the groups, is critical. That requires corporate buyin, and ledership and technical and business acumen that are extremely rare and will not be found by a "lowest bid" process.

And _that_ is why so many A/D systems fail miserably: because people have been very, very confused by sampling theory.

Just because it takes 100 msec to respond does not mean that the eye motion takes anywhere that time, and the motion is not "clocked" or linked to some discrete frequency. It's analog, and to measure its impulse driven movements properly you need to oversample temendously, or use some sort of triggered sensor that can record its triggers very accurately.

I, and many of my technical colleagues, are quite senior. We'd find work there, but would almost be forced into management, because by "lines per day" metrics and "tickets closed" we're not as fast as the average youngster. However, our abilities to deal with problems the youngsters have never even _heard_ of, and to do things cleanly so the problems don't occur, and the mastery of older and stable technologies, certainly keeps us busy.

You can see the difference in our software, and our hardware. If we buy a pair of switches for high availability, we make sure that the computers connected to them are correctly connected to both switches, with pair-bonding or other failover software. When we get involved with backup systems we actually test restoring the data. When we write new web applicatons, we sanitize the inputs before feeding them to the database. (Obligatory XKCD: http://xkcd.com/327/) And when we deal with "object oriented programming", we use different functions for different classes of input, despite the protests of the Java and C++ youngsters, because we have learned the harsh and bitter lesson: distinct functions get distinct names..

My colleagues and I are also a bit odd in that when someone shows up with a new technology, we don't just demean it. Replacing racks of expensive hardware with commodity disk drives was a real rethink of how we did things, and we oldsters had to get them to slow down and invest in bandwidth to allow offsite replicaton instead of sending tapes. (http://en.wikipedia.org/wiki/Sneakernet for an example) We also had to bring in the experience that if you triple people's space, they will fill it _very quickly_: But it worked out really well, and it's a replicatable technology suite.

Actually, it's very interesting. It shows that even with the very extensive testing and layers of planning and managerial processes to prevent such errors, they can still creep in. And it shows that very expensive, one-off projects remain vulnerable to subtle design errors, so the tools to do field updates are _critical_.

Note that designing for spacecraft can be a real artform: they have extremely limited computational resources, due to the inherent risks of bit errors in increasingly small modern silicon exposed to radiation and temperature changes, and you cannot simply shield the electronics: the shielding adds weight and itself becomes radioactive over time. So you often wind up using quite old but far more stable technologies. That means tools that may be considered quite obsolete by the time your design phase is complete and the device is ready for launch. And by the time it arrives _on Mars_, the techonology is very obsolete indeed.

My respect for the programmers and designers of interplanetary spacecraft is enormous: systems like Voyager and the Mars Rover, Spirit, that exceed their lifespans by years fill me with pride as an engineer that we could build so well. And the obligatory XKCD on the subject:

        http://www.xkcd.com/695/

> I don't really want to live in a world where I have to actively hide shit from people or they'll try to take advantage of me. Lack of privacy is a social problem soluble by bringing up people with a better attitude toward their fellow man, not a technical one soluble with an arms race (which you will lose, btw).

Goodness, you are an optimist. The military, economic, or social advantage to accessing private communications is very large, and the social and economic and political advantages are _tremendous_. Education won't solve that: the first person in the "educated" world who starts copying test answers, or reading their boss's private correspondence, will have tremendous advantages socially and in the workplace. That's part of what the NSA was doing to EU communications: industrial espionage to benefit American companies.

Yes, I do know what he makes. He's on call even more than I am and works harder: I get to go to a movie occasionally.