Assumptions: All computer operators are programmers

As a technical person that came through the DOS/OS2/NetWare/Windows path, it has been an interesting set of challenges learning to install and support Linux systems.  One of the biggest has been that many in the open source world that Linux is a part of, is that everyone who isn't a total end-user, must be a full programmer.  This is so clear in much of the documentation (man/info pages) as it is in many of the forums/chat groups. 
An example is the documentation for the Linux 'free' command which tells you all the switches for the command, but without any indication of what the output of the command really means, because it is supposedly obvious.  I think I have it mostly figured out at http://www.konecnyad.ca/andyk/freemem.htm, but that is only through lots of Googling and finding blogs that actually go into it to explain different points.
In too many of the forums, I've seen people trying to learn being told that it was simply obvious and beneath requiring an explanation, or that the answer was a tiny bit of programming and therefor 'simple'.  This sounds like the arrogance you see in academia, like a physicist that showed that the physics of a fusion reactor was proven and it 'only' needed some engineering to finish (over 5 years ago and we still don't have that reactor design adding power to the grid that I can tell). 
I would say this is one of the biggest obstacles to Linux getting anywhere near mainstream, because so many supporters keep treating mainstream as not worthy of the support they need.  I can only think that many of them crying for mainstream acceptance are really just elitists who really don't want to share. But I will keep pushing to break those barriers as I believe that open source is still the most efficient way forward for the bulk of IT.

Gamma testing

While software is being developed, it goes through the well known steps of alpha testing (all in house) and beta testing (invited customers through to anyone).  What is less well known is the next logic step, that when the software is released to customers (i.e. the developers start charging for it), can be referred to as gamma testing.
When a piece of software has a major release, there are all kinds of pressure to "get it out the door" so that the vendor can start making a return on their investment. From the customer perspective, they can now start piloting this new (version of) software in their own environment, during which they sometimes find major problems that should have been caught in the beta testing.  This can make using brand new software a bit risky, which is why I often refer to that first while as gamma testing.  Gamma testing can be just the first month of the release on products that turn out to be running well out the gate, where as for the more troublesome products it might not be until the first service patch has been released.
Gamma testing is certainly the time where we find out if the product is the greatest yet for its kind, or if it is likely to be a dud (i.e. Windows Vista, Microsoft Bob, even a few service packs some to mind) and a proof that the phrase "the latest and greatest" often used incorrectly as if the latest is always the greatest and is also greater than the versions that are yet to be created.
And why has this come to mind now you might ask.  Well I have to decide for a client whether some new servers to be built next week will be the old, stable, but with known problems version of the OS, or the shinny new one that was release a week ago.  Now back to watching those OES forums.

How to scare nosy Managers

For those managers (aka, manglers, PHB, the suits, etc...) who like to poke around the server room, just post http://xkcd.com/627/ where you can refer to it at the servers, and pretend to follow it when they are in the room. Ideal if you can do that the morning of April 1st, because the managers should know better than enter that day.
It also makes a nifty t-shirt http://store.xkcd.com/xkcd/#TechSupport

Trumped adrenaline rush, or why I don't bother with Roller Coasters

As a young kid, I got to fly a fair amount as my Dad and my Grandfather(my mom's dad, and a former test pilot) were a private pilots and flying was still relatively cheap compared today. These flights were typically in 2 or 4 seat unpressurized planes that flew 'close' to earth, typically under 1000m, where the air is still nice and thick with lots of 'texture'.  Flying on a nice sunny weekend afternoon was always a joy for me, and even when it was a smooth flight there were still usually some bumps as we'd fly though thermals (you just can't see those rising columns of warmer air). Usually there were at least a few of those unexpected bumps where the only reason we didn't hit the roof was because of the seat-belts, and they were just the thing you had to deal with to be soaring in the air like we were. So to be on a fix track that is a much rougher ride than flying, where you can generally see where the 'bumps' are, that at their best/worst barely match what I experienced flying, I find boring. To the point I haven't bothered with a roller coaster in years. On a commercial flight that happened to be in some bad turbulence (like in http://movieclips.com/krt3-the-hunt-for-red-october-movie-turbulence/ ) where I couldn't hold a book still enough to read, I turned to see a fellow passenger turning a bit green, to whom I proclaimed with a smile "This is so much better than a roller coaster, fun stuff eh?"  That brought enough of a giggle that he made it through the flight with his stomach contents intact.

So yes roller coasters bore me, but for this I might just bother to get on some more.
http://xkcd.com/chesscoaster/

Memory Blurs

An instance of memory blur is also called a Brain F*rt. As people get older and have more of those, younger folk start calling such people 'Old F*rts' because of how far back those memories may have been clear.  Alcohol consumption can accelerate this process, leading excessive consumers to becoming 'young old f*rts'.
Of course how we react to our brain f*rts can lead to fun naming of these reactions, just like the biological f*rts that one can find many such descriptions on the internet.


Inspired by a client having forgotten the details of something I had emailed him months previously.

Binary hotel shower controls

Why is it that so many hotel showers only have on or off as flow rate options?  So many have the single axis leaver/knob that you turn to bring the cold water to full flow and then add hot water, with the only other controls are tap/shower and drain/stopper. Sometimes the pressure is so high that the water is feeling over harsh. Sometimes the flow is higher than the drain can handle and you end up standing in water over your ankles even for a 5 minute shower even with the drain fully open. 
A) This prevents many from having their preferred shower rate that they are likely used to at home.
B) This causes waste of resources in both energy(which cost is increasing) to heat water as well as the water itself that is becoming a constrained resource in many places.
It feels like the hotel industry thinks we are so dumb that we can't manage the controls in the shower that most of us handle without issue at a sink.

I really treasure those hotels that have the dual axial like so many have for their sink taps with flow rate separate from temperature selection.  This does factor into my hotel choice, and I do let them know this I as I go (both positive where they get it right, and negative when they flood me out).

Best practices: not always the best choice

Most vendors have well defined 'Best Practices' for how to deploy/use/support their products that are a great starting point, but there are many times where sticking to them as an only practice will get you in trouble.  'Best Practices' are typically aimed at a hypothetical 'typical' environment which most do not match even if they are close. While the 'Best Practice' may work well for a given environment, if is not likely to be the optimum.

Ex.1) Microsoft Exchange 2007 has a best practice that assumes about 1000 end users and therefor recommends deploying each component on 7 separate servers. If you were to try to sell that to a small 12 person company, you'd likely be shown the door very quickly as that is an impossible investment for most companies that size. For organizations under 100, a single server will do just fine, and the only reason that isn't front and center of that best practice is that Microsoft would love the extra revenue of the server licenses as would the hardware vendors. 

Ex.2) Cisco router sizing guides show what should work for given sizes of typical networks, which is great if your network is typical. But if you add in site to site data replication between multiple VPNed sites, the 'Best Practice' routers can become sufficiently overwhelmed as to interrupt those data replications. In one case I was involved with one  install project where 4 sites were replicating to each other for backup and disaster recovery purposes (tape backup at one site covered all 4). The first router guy I was using kept insisting the connection drops were not the fault of the routers even though they were clearly getting saturated. In the end we had to drop some of the higher end fancy firewall filtering to keep the data flowing. After that, I refuse to use that particular router guy.

Another catch with 'best practices' is that they can change. I once had to migrate an entire cluster off of one SAN to another simply because the SAN vendor found that their original best practice had 'issues' and this client encountered those 'issues' requiring a total flush to fix.  The new SAN was built to the newer best practices and the vendor was made to provide the new SAN in exchange for the old one.

So when you see a best practice, try to find out their assumptions before using. Then you can knowledgeably use that best practice as a starting point, modifying it to best suit your environment.