Skip to main content


Showing posts from January, 2009

Rogue Sysadmin Sabotage Attempt

A terminated system admin attempted massive data deletion with a script that would have attempted to wipe out all disks on all servers."If this script were executed, the total damage would include cleaning out and restoring all 4,000 ABC servers, restoring and securing the automation of mortgages, and restoring all data that was erased."It was detected before it could execute. Think about your conversion from tape based backups to disk based backups. Would that script have wiped out the disk pools that store your most recent backups?Unless you have clear separation of duties and rights between system admins who support production and those who administer the backup software and servers, this would be a tough risk to mitigate. I‘ll bet that most shops have the same system admins for both the production servers and the backup infrastructure. If so, the rogue ‘wipe all’ script would take out the disk based backups also. That’d be a bad day.(Via Security Circus).

Hardware is Expensive, Programmers are Cheap II

In response to Hardware is Cheap, Programmers are Expensive at Coding Horror:The million dollar question: What’s wrong with this picture? 20% CPU utilization, that’s what’s wrong. It’s way too low. The hardware that’s running at 20% on a busy day is 32 cores of IBM’s finest x3950 series servers and a bunch of terabytes of IBM’s DS4800 storage. The application has three of them (active/passive and remote DR) at a total cost of about $1.5 m. That’s right, $1.5 million in database hardware running less than 20% CPU utilization on a normal day and barely 30% CPU on the busiest day of the year.How did that happen?Because a software vendor, run by programmers, thought that they were too expensive to design an efficient and optimized application. Instead they spent their precious and valuable time adding shiny new features. So the customer had no choice but to buy hardware. Lots of it. Then – after the hardware was bought, the software vendor figured out that they actually could write an app…

A Simple Solution, Well Executed

I’m trying out a new mantra:
All other things being equal, a simple solution, well executed, is superior to a complex solution, poorly executed. Since data destruction[1] discussions seem to have resurfaced again, I’ll try it out on that topic.

In Imperfect, but Still Useful Jim Graves writes
“Almost any method of data destruction is so much better than nothing that any differences between methods are usually insignificant.[2]”As Jim indicates, choosing a technical method or algorithm for destroying data shouldn’t be the problem that we spend significant resources solving. Ensuring that all media gets processed with any destruction method is the problem that needs to be solved. In other words, it is critical that all data on all media is destroyed, and that no media bypasses the process that destroys the media. This is a different problem that requires a different solution and a different skill set than the problem of determining the best method of destroying data. The problem …

Pack Rat or Prudent Record Keeping?

I've kept paper copies of all financial transactions that I've had with banks, credit card companies, utilities and the like ever since I opened up my first checking account 30+ years ago, and to this day I maintain a paper trail of all electronic statements, electronic bill payments, canceled checks and pay stubs, filed away in boxes stuffed into attics and basements. I've always assumed that someday I'd need those records, but I never knew why.

Now I know why. The victims of Madoffs ponzi scheme are being asked to provide records:
They are asked to provide their most recent account statements, and proof of wire transfers or canceled checks showing deposits "from as far back as you have documentation."  (Emphasis added)
The form also asks for all information regarding any withdrawals or payments received from Madoff.
Supplying such records could be nearly impossible for many longstanding clients, said Harry Susman, a partner at law firm Susman Godfrey LLP. &quo…

Hardware is Expensive, Programmers are Cheap

The case that Jeff Atwood attempts to make is basically that hardware is generally cheap enough that code optimization doesn’t pay (or – don’t bother optimizing code until after you’ve tried solving the problem with cheap hardware). I read & re-read the argument. I’m convinced that in the general case, it doesn’t add up.

In my experience, the ‘hardware is cheap, programmers are expensive’ mantra really only applies to small, lightly used systems, where the fully loaded hardware cost is actually is trivial compared to the cost to put a programmer in a cube. Once the application is scaled to the point where adding a server or two no longer solves the scalability problem, or in cases where there are database, middleware or virtualization licenses involved, the cost to add hardware is not trivial. The relative importance of software optimization versus more hardware then shifts toward smart, optimized software, and the cheap hardware argument at Coding Horror quickly falls apart.

The c…