Funny E-Mail of the Year...

In a note to the help desk at one company, the user's note was a simple request:

"All of my passwords were written on my calendar and I threw my calendar out. Can you help me?"

{smirk} "Yes I can."

Begging Is NOT Being Professional.

'Tis the season for gift baskets from vendors. They're everywhere and they are designed to make us plump little IT people. This does NOT mean they're not appreciated!

It seems to me that while these gestures of appreciation flow graciously in the direction of customers, potential customers, employees, and management, they are often used as a manner of sucking up. In fact, it seems they are almost exclusively that, though the intent is truly a gesture of kindness, a reminder that the sender is thinking fondly of the receiver.

The employees are the only one's potentially honoured without the idea of sucking up, though the demands on them may seem enhanced post-gift. This is truly an honour.

The one thing I've witnessed this year is the shameless and unprofessional act of calling up a vendor and asking where their basket was. It was a truly horrid to see this, though the benefits of this morning's basket were highly favourable. No, I did NOT make the call.

Begging, for anything, is unprofessional. Whether it's your job at the point of termination, your Christmas basket, your seasonal bonus, or an hour off when it's required.

Good Dog.

The new Paint program you will want...

The Paint program, a descendent of the Windows Paintbrush tool that has not gained significant features in all its days has a replacement. Allow me to introduce you to a freeware/donationware tool that is sure to please and dead simple to use, Paint.net.

The tool is wonderful, handy and fills a few gaps between the less-than-adequate features of Microsoft Paint, and a pricey product that is for professional graphics and web building.

Please have a look at their site, for the common user, download and install a non-Beta version. If you're courageous and can accept the risk, go for the version 3.0 Beta and enjoy some additional features.

Manual thinking over technology wins... sometimes

I'm in the middle of creating a PRINT IMAGE for a HCFA 1500 form and I'd set about making a text grid and mapping it out based on Courier 10pt. I'm drawing boxes on the paper with a pen of all things and my co-worker and Linux mentor, fires me this link.

As they say, "LMAO."

Didn't Chip get shot down (as a kid) by the simple approach of a non-nerd solution. It's a gem to remember to be sure.

It's good to remember when technology is too complex for the solution.

That reminds me, I need a new head for my electric toothbrush.

All Hail the Early Adopters

We owe a great deal to those people who take the leap of faith with the newest technologies. I do it from time-to-time, but lately I've taken to the, "wait and see", accepting the lower prices of the older technologies and letting these heroes give me bouts of jealousy.

You need a certain degree of bravery to be the first with the newest thing, there are almost always bugs and quirks with the first-offs for the new thing, the technology is tested by the bit-heads that invented it and shown off to the executives to gain funding for future R&D, but the public have only been teased about it. It's a true test of your financial bravery.

There are many means of sacrifice in the EA forum, there's the risks taken with beta software, the trials of shareware, and the pain of major version upgrades out-of-sync with your partners or co-workers. The initiative to jump on the bandwagon comes with a bungie tied to you. The skill comes from jumping on and getting comfortable while leaving enough time to untie the bungie or drag along the crowd you co-exist with.

If you're willing to be the hero, be the guinea-pig, or be labelled the rebel, go for it. If not, thank them for being courageous enough to jump in, step up, or leap off for the sake of advancing technologies.

My Early Adopter Moves:

• XBOX (success)
• High-Speed Cable (painful but worth the experience)
• Some MP3 player (Mattel) for mydaughter (failure, no support, poor design)

The Pitfalls of Virtual Computing

I'm caught up in a rather common mess it seems, something that shakes my beliefs and challenges my new-found conversion to the Linux Realm. The problem seems to lie in the virtualization of the Linux OS under ESX 2.x. The process of virtualization creates issues with the system clock on the Linux box causing, in our case, a slow-down. In day we can lose more than an hour or 3+ minutes on 10.

Now, there is a fix. The real fix involves recompiling the kernel to watch the hardware clock, I'm not brave enough for that on the production server, so I took the quick-fix, the syncing of the clock to our time server. That's fine. It works, somewhat. The scheduled task runs at 4:01, 8:01,... 20:01 and it grabs the time from the time server and sets the system time and hardware clock from that. You see the problem, as it was originally, was that the guest OS (Red Hat Enterprise Linux) lost time against the vitual machine's BIOS. The entire machine is virtual and so it was keeping accurate time in the VM, but not under the guest OS. Well, about a week or so back, the VM lost sync with the HOST hardware and it hasn't recovered yet. So, what had worked, syncing with the hardware clock of the VM, now doesn't work so we're running this new script to get an "accurate" time from the time server.

But this isn't running well. The time-loss is so great that we, I, am just about ready to go back to a physical box. BTW: Our windows systems are having similar problems now, but that's not supposed to happen.

Okay, I've vented. I'm worried too. This reflects on our I.T. reputation and while I'd rather be Linux-free, The time to re-create this particular application is a nightmare. I do hope our VM vendor can find a solution soon.

Process & Change vs. Sarbanes-Oxley

Sarbanes-Oxley is meant to ensure companies are responsible to the shareholders and that checks and balances are in place to prevent fraud, etc. ITIL is meant to stabilize the IT organisation ensuring reportability and reliability.

I am a firm believer in process. I also have a decent respect for change management and the stability that adds to an organisation's infrastructure and applications. It seems that even though a number of organisations are experiencing a latex-gloved exposure to SOX, they're not learning about ITIL or understanding the impact of a mid-day change. The real problem it seems is that when a cowboy is in a management position, a technical manager, the risk is that they will implement at will. They will implement regardless of the rules and observed best practices of the organisation.

One such folley was the recent change to a corporate WAN that allowed all sites to see all other sites and the resulting traffic was such that at 9:30AM, the networks slowed to a crawl and the plethora of Active Directory servers started chattering. An unwise move to say the least.

It's this sort of hap-hazard management that should be eyed with concern.

A good business has several tools that ensures it functions well, people being the foundation of that. The people hired must embrace the tools and use them wisely to ensure business success with efficiency. The tools I am referrign to are Documentation, Processes, and Systems.

Systems are the hardware, and software that make up the means by which to run the business. This is a combination of infrastucture and applications that serve the staff in fulfilling thier duties and the reliability of these systems is critical. The Processes that are used by business are the standardized methods and manners in which the business is run. It is much like a how-to or manual, but any process that is not documented is prone to change and variance from the standard. This is why Documentation is the key to keeping all of this wrapped together and prevents or removes chance from any person, new or old, making an error because they failed to follow process.

Large-scale operations departments strive for excellence in maintaining systems by counting errors that occur when an operator follows a process. The count can be below 5 for a year in a well-run shop, but effective documentation can push this towards zero.

Processes are as much a path as a rule, but rules do need tuning. Just as in the Systems themselves Changes are welcomed when properly considered, often through a committee or Change Advisory Board (CAB). This is essential, and changes outside of the designated Change Window are only under break-fix or very special circumstances. This is defined well by ITIL, but in truth this is common sense. Those who object are likely developers or cowboys, but this is not meant to offend. A developer (web for example) is often expected to maintain a site and make changes daily, hourly, or more. While this is not signficant for content normally, for fundamental changes or business applications a Change Window helps ensure the application is available when it is needed and outages are planned in a timeframe to minimize the impact on the customer/business.

References:
ITIL, Sarbanes-Oxley Act