Month: December 2009

As it turns out, a good friend was on that Northwest flight. I won’t identify him (though I know he reads this blog occasionally). What happened to him has made me think of my own responses in such a scenario. But it has also made me question the TSA’s kneejerk ineffective new guidelines.
Especially in light of the potential accuracy of this report, if true, suggests that real security measures ought to be taken. What the TSA proposed and implemented would not have stopped this.
Bruce Schneier, noted security guy in computing had this to say:

Read moreNon-theatrical security

A quick and dirty test on a JackRabbit Flash machine. This is a machine going to a proof of concept project soon.
A simple 8k random read against 256GB data spread out over 4 volumes. 1 machine. 48GB ram.
Open up the throttle on the stock config. Engines aren’t running at full speed, but its a baseline test.

Read moresimple minded sprints with JackRabbit Flash

Sometimes … sometimes … helpful utilities are helpful. Like installation systems that present the raw hardware with drivers to me, and let ME decide what I want to do with them.
Unfortunately … I often run head first into bad choices made by the installer coders or architects. Dm-raid is one of these cases. It is very hard to disable it from a Centos install. Very hard. Pretty close to damn near impossible.
Hold it … why would we want to disable this?
Simple. I (as in ME) want to control how my disks are configured.
This isn’t a Centos issue, as they repackage RHEL. This is a RHEL issue. Device mapper is used when a fake-raid is detected … correctly or otherwise. In this case, the fake raid is incorrectly being detected. And I want to … badly … turn off the fake raid detection. Badly.
brokenmodules=dm_… don’t seem to do the job.

Read moreWhat I really want to do is to disable device-mapper on install …

This is related to an issue we ran in to, today, and several other times. It sounds strange, but if you maintain rigid control over a huge swath of your stack, you run a fairly serious risk of being unable to respond to changing environments as quickly as your competition. The law of un-intended consequences bites you, fairly hard. Worse, you rarely, if ever, realize it, until it is too late.
For example. Suppose you are an iSCSI stack provider. You want to build iSCSI stacks. So you build a target and an initiator. But you decide you really want to make peoples lives simpler, by removing the complexity (read as “choices available”) in using your stack. So you decide to adopt a single platform. Time goes on, that platform that you are locked to ages, and isn’t updated as quickly (you are locked to it, but you don’t own it) as you might like. So you start falling behind in systems support.
All the while, more nimble competitors are grabbing up mind share and market share, as they are focused upon provide great tools, not a platform.
Sounds strange, but there is danger, fairly significant danger, in providing a complete solution platform.

Read moreThe danger of controlling too much of your stack …