I use:

Tuesday, November 14, 2006

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.

Monday, November 13, 2006

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.