Speeding up ClearCase lost+found removals

Have you ever had a lot of unnecessary files in a ClearCase VOB’s lost+found folder? Have you ever tried to get rid of them and the best you can do is the following command from within the lost+found folder? (This is a Windows based command.)

cleartool find . -exec "cleartool rmelem -force \"%CLEARCASE_PN%\""

Try using that multiple times to speed things up and you’ll probably be presented with the heart stopping “cleartool: Error: Database identifier (dbid) not found in database” message? It turns out, this appears to be because the “find” command tries to read files as they are being rmelem’d by the other find command already running. Going at it this way, you’re limited to one mass removal operation at at time…but that’s slow, especially when you’re trying to get rid of 30,000+ files like me (a story for another day).

So what am I doing (at this very moment) to help alleviate this? (The actual command is all on one line. I’ve included the shell prompt for clarity of the working directory. The “delims=?” part is to prevent filenames with spaces from being cut off.)

FOR /F "delims=?" %A IN ('dir <mask> /b') DO cleartool rmelem -force

And it’s working! I’m using things like “a*”, “b*”, etc. for the mask in order to run parallel removals. It may not be the best tactic, but at least I’m watching four command line windows all removing elements from lost+found under the same repository. This will mean four times less waiting for me, and that’s something that (to me) is worth writing about.


Posted in Work | Tagged , , , | Leave a comment

FIPS 140-2 for Mere Mortals

I had a call today from someone who was experiencing an issue centered around SSL. While the subject of this post has absolutely nothing to do with that call, it did make me remember another article I wrote about FIPS 140-2. I never polished it up for publication and decided that today would be a good day to bring it out from hiding. For any of you going through issues with FIPS 140-2 compliance, perhaps it will shed some light to your path.

For those of you who don’t know what FIPS 140-2 is or how it might influence your overall wellbeing, go ahead and run for your lives. It’s not something you want to have in your life as a general rule.

The below diatribe was written by me while configuring an IBM HTTP Server instance (basically Apache Server) to be FIPS 140-2 compliant. Based on my experience, I have a feeling that several of the SSL implementations in the world don’t meet FIPS when it comes to negotiated ciphers and encapsulating RSA key strength. Maybe this is going too deep, but FIPS is definitely very specific once you really start to understand it.

Introduction to FIPS 140-2

FIPS 140-2 is a rather dull document. At first glance, it appears to not reference SSL or even software design. How on earth it applies to an Apache SSL configuration is beyond me. Indeed, with sections devoted to physical security of “cryptographic modules” people might be led to think this doesn’t apply to them. This is what I thought; however, closer examination and careful reading of additional FIPS (Federal Information Processing Standard) and NIST (National Institute of Standards and Technology)  publications started making the picture much clearer. Let’s start with a simple statement in FIPS 140-2, Section 1.1.

Security Level 1 provides the lowest level of security. Basic security requirements are specified for a cryptographic module (e.g., at least one Approved algorithm or Approved security function shall be used).

We can’t even read Section 1 without being bombarded by FIPS jargon. After reading through Section 1, a few things are obvious. FIPS 140-2 offers four different security levels. Each one builds on the previous. Since this is one of the basic requirements to be FIPS 140-2 compliant, it might be worth a closer look. So where can we find information about an “approved algorithm” or an “approved security function”? Well, it appears that the term “approved algorithm” isn’t the one for which we should be looking. Believe it or not, an “approved algorithm” is a subset of the “approved security functions”. Let’s do a search on “approved security function” and see what we find. Bingo, FIPS 140-2, Section 2.1.

Approved security function: for this standard, a security function (e.g., cryptographic algorithm, cryptographic key management technique, or authentication technique) that is either

a)       specified in an Approved standard,

b)       adopted in an Approved standard and specified either in an appendix of the Approved standard or in a document referenced by the Approved standard, or

c)       specified in the list of Approved security functions.

So we’re left with more questions. Where’s that “list of Approved security functions”? Further searching brings us to FIPS 140-2, Section 4.1.

A cryptographic module shall implement at least one Approved security function used in an Approved mode of operation. […] (Approved security functions are listed in Annex A to this standard.)

Compliant Ciphers

Ah, now we’re getting somewhere. Let’s take a detour from FIPS 140-2 and move into its first of four annexes. FIPS 140-2, Annex A is pretty straightforward if you understand what you’re reading. In the end, the following methods are the only approved cryptographic functions under FIPS 140-2.

  • Symmetric Key: AES, TDEA, and EES
  • Asymmetric Key: DSS (DSA, RSA, and ECDSA)

That’s a pretty narrow list. On top of that, only three of those are commonly tossed around: AES, TDEA (also know as Triple DES), and RSA. Let’s take a closer look at RSA and TDEA.

RSA is usage is defined in FIPS 186-2. Per that document, RSA is approved and detailed in ANSI X9.31. I don’t have any questions about RSA really (at the moment) so I’m not going to bother with an ANSI document. The fact that we’ve left the FIPS/NIST world and gone to an ANSI document at least makes me feel a little closer to reality.

TDEA is described in NIST SP800-67 (ooh, a “special publication”, this has my interest perked). Per NIST SP800-67’s forward,

With the withdrawal of the FIPS 46-3 standard:

1. Triple DES (i.e., TDEA), as specified in ANSI X9.52, Keying Options 1 and 2, is recognized as the only FIPS approved DES algorithm.

That’s nice. I’m not even sure what a keying option is, but I know that we can only use option numbers 1 and 2. That’s the government for you: restrict first, explain later. Reading on, NIST SP800-67, Section 2 states that

The DEA cryptographic engine is used by TDEA to cryptographically protect blocks of data consisting of 64 bits under the control of a 64-bit key. Subsequent processing of the protected data is accomplished using the same key as was used to protect the data. Each 64-bit key shall contain 56 bits that are randomly generated and used directly by the algorithm as key bits.

So each key is 56-bits wide. This is easily understood. Now we continue to NIST SP800-67, Section 3.2.

This recommendation specifies the following keying options for a TDEA key bundle (Key1, Key2, Key3)

1. Keying Option 1: Key1, Key2 and Key3 are independent keys (i.e., Key1 ≠ Key2 ≠ Key3 ≠ Key1);

2. Keying Option 2: K1 and K2 are independent keys (i.e., Key1 ≠ Key2), and Key3 = Key1.

Now it’s all making sense. TDEA supports three 56-bit keys. As a result, there are three configurations, or “keying options”, for the keys. According to this, the only approved TDEA modes of operation are 2TDEA (112-bits, 80 bits real security) and 3TDEA (168-bit, 112 bits real security). (Real security values are from NIST SP800-57, Section 5.6.1.) This makes it very clear (crystal in fact) that 56-bit DES encryption is not encryption in the eyes of FIPS 140-2. Speaking of FIPS 140-2, it’s about time to get back to that document.

This teaches me one important thing regarding Apache SSL configurations: I must limit the number of negotiable ciphers to this FIPS 140-2 approved list. In the end, I find I’m only going to be offering three ciphers: 3TDEA, AES-128, and AES-256. I configure my server to match these and now I’m at least partially compliant.

Server Security

Further investigation of FIPS 140-2 brings us to Section 4.3.3.

Authentication mechanisms may be required within a cryptographic module to authenticate an operator accessing the module and to verify that the operator is authorized to assume the requested role and perform services within that role.

I don’t know what that means to you, but to me it means that the server on which keys reside needs to be secure. We can’t have just anyone logging into this server and compromising the keys. Wow, I didn’t know FIPS 140-2 covered server security!

Further reading in Section 4.3.3 yields more information about the breadth of FIPS 140-2.

The strength of the authentication mechanism shall conform to the following specifications:

  • For each attempt to use the authentication mechanism, the probability shall be less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur (e.g., guessing a password or PIN, false acceptance error rate of a biometric device, or some combination of authentication methods).

This was another “wow” moment for me. Here’s proof that FIPS 140-2 requires passwords of each operator and keystore be secure. Don’t trust my math, but I think a simple eight character password exceeds these requirements. Still, FIPS 140-2 requires password complexity? That’s a new one for me.

As far as my Apache SSL implementation goes, I’m compliant here. I just need to make sure that I don’t compromise security with bad administrative practices and I’m good to go.

Miscellaneous Errata

Let’s read Section 4.7 of FIPS 140-2. There are several good nuggets in this one.

Cryptographic keys and CSPs encrypted using a non-Approved algorithm or proprietary algorithm or method are considered in plaintext form, within the scope of this standard.

There goes the idea of using “custom” or “in-house” encryption. Many people argue this is “more secure” since it’s not based on a method that is public knowledge. Obviously the government doesn’t fall into the classification of “many people.”

Public keys shall be protected within the cryptographic module against unauthorized modification and substitution.

Let’s keep this on in the back of our minds for later. I take this to mean that we need to protect our RSA keys in an acceptable manner (i.e. permissions, passwords, etc.).

Documentation shall specify all cryptographic keys, cryptographic key components, and CSPs employed by a cryptographic module.

You mean that FIPS 140-2 is telling me how to document my system? The answer to that rhetorical question is a resounding “YES!”

Key Exchange (or Encapsulating DES/AES Keys with RSA)

Deeper into FIPS 140-2 we proceed.

Section 4.7.3:

If key establishment methods are employed by a cryptographic module, only Approved key establishment methods shall be used. Approved key establishment methods are listed in Annex D to this standard.

If a key transport method is used, the cryptographic key being transported shall meet the key entry/output requirements of Section 4.7.4.

Section 4.7.4:

All encrypted secret and private keys, entered into or output from a cryptographic module and used in an Approved mode of operation, shall be encrypted using an Approved algorithm. Public keys may be entered into or output from a cryptographic module in plaintext form.

Documentation shall specify the key entry and output methods employed by a cryptographic module.

The common method used for “key transport” is RSA public key encryption (at least with SSL and TLS). Basically, if we’re transmitting an AES or DES key across the wire, we need to encrypt the key. FIPS 140-2 Annex D specifies that NIST SP800-56B provides insight into using Integer Factorization Cryptography (IFC…RSA fits into this) as a key establishment technique. Reading through NIST SP800-56B is pretty dry since it tells us a lot of things we already know about RSA. There is one important point in Section 6.1 that is a good argument against self-signed RSA certificates.

Public keys shall be protected from unauthorized modification. This is often accomplished by using public key certificates that have been signed by a Certification Authority (CA).

Let’s move back into FIPS 140-2 and continue reading. We’ll finish up with Section 4.7.5.

Cryptographic keys stored within a cryptographic module shall be stored either in plaintext form or encrypted form. Plaintext secret and private keys shall not be accessible from outside the cryptographic module to unauthorized operators.

Documentation shall specify the key storage methods employed by a cryptographic module.

These sections really help with my Apache SSL configuration. I know that using SSL or TLS is OK since RSA is approved for use in DES/AES key encapsulation. Furthermore, as long as my RSA private key is not open to the public I don’t have to encrypt it. I do have it encrypted using a Java keystore but I’m not sure what kind of encryption that uses (RC4 would be my guess). As long as I protect the location in which it is stored, I don’t have anything to worry about.

A Revisit to Section 4.7.3

I skipped a critical paragraph of FIPS 140-2, Section 4.7.3 earlier. I did this intentionally so we could revisit it now.

Compromising the security of the key establishment method (e.g., compromising the security of the algorithm used for key establishment) shall require at least as many operations as determining the value of the cryptographic key being transported or agreed upon.

This one is really important. This is saying that the underlying symmetric key (DES, AES) used in a secure connection (SSL, TLS) must be encrypted by a public key (RSA) of equal or greater bit strength. Unfortunately, the “bit strength” of an RSA key is not the same as its “bit length”. In other words, a 4096-bit RSA key does not provide 4096 bits of strength. So how do we know what strength a particular RSA bit length provides? NIST SP800-57, Section 5.6.1 provides the answers. Table 2 of this publication clearly illustrates the security required by an IFC method (RSA) to transport symmetric keys used by TDEA and AES. The common length of 1024 bits for RSA keys only provides 80-bits of strength. This is sufficient to protect a 2TDEA (112-bit DES) key but nothing more. 2TDEA is FIPS compliant but it is rapidly losing its credibility as secure. According to FIPS 140-2 IG, Section 7.5, page 63, 2TDEA should only be used through 2010. RSA with a 1024 bit key should not be used after 2010 either. When I check my calendar, it looks like 2010 is over in just eleven more days!

Are you using a 1024-bit RSA key? If so, it’s not FIPS 140-2 compliant regardless of the underlying cipher negotiation!

Here are the algorithms that FIPS 140-2 allows per Annex A and the RSA bit length needed to provide enough strength for encapsulation. Keep in mind the RSA length is the minimum required.

  • 2TDEA (112-bit DES) – RSA key length of 1024 bits – overall security strength of 80 bits
  • 3TDEA (168-bit DES) – RSA key length of 2048 bits – overall security strength of 112 bits
  • AES-128 – RSA key length of 3072 bits – overall security strength of 128 bits
  • AES-256 – RSA key length of 15360 bits – overall security strength of 256 bits

This section of FIPS 140-2 is critical to understand. Having AES-256 encryption is all but useless if you’re using a 1024-bit RSA certificate to secure it. The standard is clear here if you take time to read it. I’m honestly not sure that very many implementations meet these requirements.

For my Apache SSL implementation I have already decided I will be using 3TDEA, AES-128, and AES-256 ciphers. I’m working with a limitation imposed by IBM’s HTTP Server 6.0.2 of a maximum RSA key length of 4096 bits. I can relax in the knowledge that this RSA key can secure 3TDEA and AES-128 without any problem. While the key can’t protect AES-256 with sufficient strength, I can argue that is a risk imposed by the software with which I am working. Besides, 4096 bit RSA shows an end-of-life at 2030 (per FIPS 140-2 IG, Section 7.5). Hopefully IBM will have the 4096 bit limitation resolved by then.

A Note on Web Browsers

I have been unable to get Internet Explorer 6 or 7 on Windows XP to connect using AES encryption. It’s only a matter of time before TDEA is called into question as a credible encryption schema (in my opinion). FIPS 140-2 IG, Section 7.5 says 3TDEA will be good only through 2030. I’m not sure we can rest assured that this won’t change before 2030. This might be a reason for corporations to investigate alternate browsers (i.e. Firefox, Chrome) or upgrading to Vista or Windows 7 (I believe AES is supported on those operating systems).

And yes, I know of at least one good sized company that just upgraded to IE 7. And this same company is still running Windows XP on almost all workstations. Why they aren’t at least using something like Firefox or Chrome to help promote security is beyond me; but, a lot of things seem to be beyond me!

A lot of things other than FIPS 140-2. No, that one I feel I have a pretty good grasp on now. Hopefully after reading this, you do as well.


Posted in Work | Tagged , | 3 Comments

Delivering the goods…UCM style

I’m going to list several random terms and you tell me what they all have in common.

  • UCM
  • Deliver
  • Rebase
  • Activity
  • Integration
  • Development
  • Stream
  • View
  • ALBD Server

No guesses? Oh, come on…it’s not that hard. Or is it? Perhaps after spending over two years of my life immersed in this world, such a random and senseless list to most defines a sort of new home for me. And what is that home? What does this list mean?

IBM Rational ClearCase. Yeah, I have to admit, I’m one of those guys: a loved, hated, mutually respected, and downright feared (and fearless) ClearCase administrator. You’re going to stop reading this post right now as a result? Good for you, I probably wouldn’t read it either.

Unless I was a ClearCase administrator who needed to know how to invoke a deliver from one integration stream to another on the command line. Oh yeah, I’ve perked your interest now!

So, lucky me, I’m a would-be hacker (not in the colloquial sense) as well as leading the unfortunate double life of a ClearCase admin. Actually, I like my job pretty well, even when other developers seem to have it out for me. I can hold my own and defend myself against the relentless barrage of comments about how much better the world would be if every license of ClearCase was shredded, the original source code run through shred and the hard drives destroyed via thermite, and CVS, Mercurial, and Git reigned supreme. Now, I have nothing against those tools and use CVS for my personal projects off the job. The big thing is that most of them dislike ClearCase not because of ClearCase, but because of the UCM model imposed upon them by ClearCase. Give them base ClearCase and most would be pleased (dare I go so far as to say, happy?). But UCM is the way we’ve chosen (at least to some degree). Take the beloved CVS and impose a strict branching strategy where each project is placed into its own branch, and then impose strict regulations on branch promotion strategy, and link it with a workflow system like ClearQuest, and what you end up with would be a hated form of CVS. Again, not because of the tool, but because of the process. But that’s a post for another day.

Back on topic. Would be hacker (or ub3r programmer, whichever you prefer) gone ClearCase admin. What do you end up with? Someone who uses Process Explorer to find out how clearmrgman is called from inside Project Explorer (clearprojexp) when delivering from one integration stream to another.

See, if you just run clearmrgman -? all you end up with are arguments for delivering a development stream up to an integration stream. Useful, yes, but only when dealing with development streams. I’m in a situation where I need to move stuff from one integration stream to another on a regular basis. And let’s face it, Project Explorer is a painfully slow tool, at least at our installation. Me calling clearmrgman myself could save me 30 minutes or more each day. It’s also just plain cool to do.

So what do I do? Well, I crank up Process Explorer and then deliver from one integration stream to another. Now I have a new process in Process Explorer and I take a look at the command line arguments used to invoke clearmrgman. What’s this? An argument was passed that is not documented! What could this strange /del_bls argument mean? Is it the key to eternal life for a ClearCase admin? I’m afraid not…you’ll need to look elsewhere for that; however, it’s definitely a serious boon.

See, if you just try to invoke the following command, you’re going to get a not-so-helpful message (quite a common occurrence in the ClearCase world).

clearmrgman /deliver /stream <Integration Stream>@<PVOB>

The message states: “A deliver operation from the integration stream must specify baselines to deliver.” OK, so the message is helpful in the sense that it tells you, in no uncertain terms, “No, dummy, you can’t do this.” What’s not helpful is that it doesn’t tell you what command you might use to do this. That’s where this handy /del_bls argument comes into play.

Let’s try the same command with the /del_bls argument added.

clearmrgman /deliver /stream <Integration Stream>@<PVOB> /del_bls

Voilá! This time around we don’t get a list box for activities (which makes no sense when delivering from an integration stream…or at least less sense). Instead, we get a list box for baselines. This is exactly what we wanted.

So why do I need to know how to do this? Well, it’s complicated, and this post is already getting lengthy…but here’s an attempt at an overview anyway. We have a new stream model we’re implementing. In this model, there is one “root” or “production” UCM Project with, of course, an integration stream under it. This stores the current version of the application. In order to work on a project against this application, two UCM Projects are created. One is the “development area” and the other is a “staging area”. When development is complete, work is delivered from the development UCM Project to the staging UCM Project (from one integration stream to another). The changes are then tested in staging and approved to move on to production (which involves another integration-to-integration delivery). The big problem with delivering between integration streams is that there is no check to ensure the source stream is based on the latest foundation baseline from the target stream. So what do I need to do? I need to write an automation console (HTA in this case) that will perform this check first and then kick off a delivery if all is well (there are other checks as well, like baseline promotion level). In order to make this console complete, I obviously needed a way to start the delivery from the command line, and that’s why I needed this information.

I’ve posted this here for any others who are fortunate (or unfortunate, depending on how you look at it) enough to be in the same position. To me, ClearCase is a great product that really seems to be lacking on the admin tools side. I really wish that IBM would take a little more time to hire some real-life admins who could come in and boost the product’s palatability to the larger development/admin community. Of course, I only see one side of the story, but that’s how life works. I just am not sure that many of the IBM developers have worked in a ClearCase UCM implementation consisting of over 600 VOBs (including PVOBs) with upwards of 100 UCM Projects inside them. Yeah, our shop isn’t released based either…just ad-hoc projects all over the place. Yes sir, it’s a ton of fun.

Well, that’s all for now. I’ve got an automated console to write!


Posted in Work | Tagged | Leave a comment

The Curse of Rain Upon the Homeowner

I like rain. I didn’t in the past, but now rain and I have come to an understanding. Rain does its thing to keep me, my yard, my garden, and just about everything else alive. I keep my mouth shut and let rain do its thing. End of story.

Or so I thought. Until a few nights ago I thought to myself, “Man, it’s really coming down out there.” So I walked to the back door to check things out and was greeted by not only a torrential downpour but also my very own Angel Falls (or a very poor imitation thereof). Yep, you guessed it, my gutters were full and overflowing. Sure, I’d noticed the telltale signs of leaves sticking out the top of the gutter a few days before; however, being a relatively new homeowner I thought to myself, “Ah, it’ll last a few more days.” Besides, I had other projects I was working on at the time.

So much for lasting a few more days. I was now faced with the reality that my gutters would not clean themselves and that if I failed to act I would soon have a nice impression made in my deck from where my very own personal waterfall made its sudden, and noisy, end. (OK, so it wasn’t THAT bad…I’m exaggerating for effect, but you get the point.)

Lucky for me, I’ve owned my house for a while and have already dealt with this very same issue last season. Only last time I didn’t have any way to deal with it, so I just let it rain and rain and rain all while I waited for my gutters to be ripped off the side of my house by the sheer weight of so many leaves plus the deluge of water under a heavy rain. Oh, did I mention that one of my gutters is over twenty feet in the air? Oh, and there’s a slope under that side of the house. Oh yeah, roll, baby, roll…thud. No, I wasn’t going to risk a visit to the ER just to clean my gutters. There HAD to be another way.

What did I do? I started searching for “gutter cleaning tools”, “gutter cleaning methods”, “gutter cleaning high gutters”, etc. etc. etc. ad nauseum (loosely translated “until you puke” for you non-Latin types out there). I just couldn’t find anything to start with. Then I found the holy-grail of would be do-it-yourself-gutter-cleaner-people-with-homes-that-have-high-gutters.

Gutter Sense!

Sure, I thought “Is this legit?” to myself. But after reading, and reading, and reading again I just didn’t find the same “web copy” lingo that makes you want to buy something you either a) already own or b) can attain for free. (Hey, someone should write a book about writing such web copy.) No, I saw something that looked legit. Legit enough that I plopped down my, err, PayPal account and ended up $26.45 poorer than when I started looking for some help. Anxiously I awaited the receipt of my Gutter Sense tool. Would it work? Was this a scam? Could I get my money back if it never arrived?

And then it came. Nicely packaged and decent looking enough for me to give it a shot. I promptly hoisted the device into the air atop a 20′ extension pole and pulled the string. What happened? Leaves, loads and loads of leaves came out of the gutter as I lifted the hardened plastic hands out of the gutter. Plop! There was one bundle, now to the next. Thirty minutes later, my gutters were clean. In fact, my gutters were so clean that I was finally removing loose dirt from my gutters using the Gutter Sense tool.

So this year, during the rain storm, I walked about with a hat and rain coat and started working. I did wait for the torrent to subside a little, mind you, but it was still raining pretty good when I went out. And little by little I made my way down the length of each gutter removing the majority of the leaves and dirt that had accumulated during this past year. Less than an hour later, I’m back inside, nice and warm, with nothing but the beautiful sound of rain to listen to on my back porch.

Risking your neck every time you scale a ladder to clean your gutters (even on a single story house)? Try it out for yourself and I think you’ll agree: Gutter Sense really does make sense.


Posted in Home Life | Tagged , , | Leave a comment

Steroids to the Brain

I remember this old commercial about the U.S. Army (or one of the armed services…but I think it was the Army). It had this “band” in it that was being “interviewed” and they were really talking up what they had. I can’t remember too many details but two things do stick out in my mind. First, the music was awful. It was about the worst “death march metal” (if that’s a genre, you get the idea though) you could imagine and was basically composed of the main singer monotoning over a rather  unimaginative set of bad power chords. The second thing that stood out was the following line by the would-be main singer (keep in mind, this was a commercial intended to poke fun at this “band”): “Our music is like steroids to the brain.”

Simple, straightforward, no extra emotion. Just cold, hard facts regarding the steroid-like effect this awesome music has upon the brain. Steroids, huh? I remember feeling more of a numbing effect rather than a “boost” of anything. Well, to each his own I suppose.

So what’s the point? The point is that there is a genre of music I feel definitely is like steroids to the brain: 8-bit! Be it from an old C64 game (which, regretfully, I did not own as a child…only a TRaSh-80…with 128k of RAM mind you!), NES or SNES titles of the past, or some of the most creative demo-scene stuff ever, it’s all good to me. One particularly good stream I like is kohina.net. It’s not been updated in years but it works here at, er, work (heh, no pun intended) and on those days I just can’t find inspiration (like today), I plug in my ear buds, crank up the volume, and start feeling that surge of energy…in my brain! Oh yeah, there’s definitely a steroid quality to this music.

Those who didn’t grow up jamming out to those funky 8-bit tunes on a game console probably don’t understand it. They don’t see how on earth you could listen to this music…let alone dance, or worse, cry. Yes, I’ll admit, a stirring rendition of one of the many 8-bit ballads that accompanied the most emotional moments in video game history can nearly invoke such a response. After all, what hard core gamer hasn’t felt a little emotion every now and then? You mean you played simply to gain a level, an extra life, to beat the next boss? Well, I for one was after the story just as much (and sometimes even more) than the game play itself. That’s what usually interested me in a particular game more than awesome graphics or a particular genre. Give me a good story and I’m usually happy.

But for those who did grow up jamming out (or crying) to such tunes, I’m sure we can all appreciate the effect that a good 8-bit tune has. Be it a power ballad, a disco dance, a synth metal rock, or any other countless sub-genre of 8-bit they’re all good. Some favorites? Well there are so many…where should I start? Ah, I have an idea, let me get a shot of steroids to the brain. Yes, that’s better. There go those screeching sounds of good 8-bit. Wait, what was I trying to do? Nothing I suppose…must give in…to the power…..

Long live 8-bit!


Posted in Geekery | Tagged , | Leave a comment

How much we take for granted…

Hello all and welcome to my blog. I’ve wanted to get this started for a long time now and today just happened to finally be the day. Plus I finally noticed this nifty domain was available. Even though my WHOIS search said that this domain wasn’t previously registered, I could have sworn that it was for several years now. Regardless, it’s mine now and I’m glad to finally have a place to call “home” out here in the clouds.

So what’s on my mind? At the moment, the creation of this blog. From behind a corporate firewall I have been able to single-handedly register a new domain, reconfigure my existing web hosting to support this new domain (and shuffle around the others), download and install Word Press, and then start posting this post. What’s so impressive about that? Well, not much really…until you realize that half the work was done ON MY CELL PHONE. In fact, I used my cell phone to exclusively perform all the work on my hosting account, including SSHing into my account and using curl to download WordPress and then unpack it (gzip -d, tar -xf for those techies out there). That plus a lot of configuring inside my hosting provider’s control panel utility and we now have a working WordPress site.

So why go through the pain of using a 400×240 screen to configure a new web site? Well, first, it’s pretty cool to do ANYTHING useful on your cell phone other than call someone. I remember when cell phones were big, clunky, and had a simple 2 line numeric LCD panel (not alphanumeric, just numeric). Insanely ridiculous by today’s standards but an absolute God send back in the day. Second, I happen to be a security freak. My corporate intranet doesn’t play nicely with HTTPS over off-beat ports and I just don’t like the idea of connecting to my web host and allowing my password to fly through the air to all the good little boys and girls of the world. My cell phone on the other hand handles this with ease and is therefore my first pick when connecting to my host from work. Thirdly, forget SSH from behind this firewall. Nope, not going to happen. Why even try when I can use MIDPssh on my CELL PHONE.

“Alright,” you say, “Mr. Archimedes has finally made it into the 21st century and realizes that the little device he uses to call people can do more than make phone calls.” Yeah, it can do more, a lot more. And no, I wasn’t born yesterday but I also wasn’t born “when dinosaurs roamed the earth.” I’ll admit, I’m slower to adopt new technology, probably simply because of a lack of time while trying to fit into the corporate world and still find time for my family. Oh, and some form of social life. But still, the point is that I see hundreds of people on any given day using technology in the palm of their hands that just plain didn’t exist 20 years ago. Maybe in someone’s brain, but we probably all thought it would happen in the 24th century since that’s when Picard said it would happen.

So it’s time to wrap this first post up and, well, look at the calendar, tomorrow’s Thanksgiving here in the States (ooh, bad, I just gave out my general location to the known world…so shoot me). While I’m sure there are plenty who might read this post (and plenty more who won’t waste the time to do so) and say “What do I have to be thankful for?” I hope that at least a few of said people will think, “Wow, I’m thankful to be alive at a time like this!” Sure, the global economy sucks…bad. Sure, we might get to see another political-disaster-turned-war unfold before our very eyes in several areas of the world (Korea comes to mind…). And sure, you just plain are having a bad day. But when you think about it, even if you’re not as privileged as those of us living in a major super-power country, you’re probably better off than your previous generations. Maybe even a LOT better off. And this doesn’t even touch on those more esoteric things we can be thankful for like family, faith, or the fact that the Sun still hasn’t gone supernova.

Oh well, just be thankful in your own way each and every day and stay tuned for more just-as-pointless blog posts coming to a blog near you.


Posted in General | Tagged , , | Leave a comment