A warning goes out to all campers: Protect your beer from intruders!

Who are the intruders? Visiting friends? Neighborhood kids? No, they are the local bears! And apparently they can’t hold their alcohol as well as one might think!

Read it at: Bear Passes Out After Only 36 Beers.

As the Windows XP Service Pack 2 upgrade rapidly approaches–unlike it’s upgrade cousin, Longhorn–companies are forced to evaluate whether they are ready to undergo the compatibility headaches that Microsoft is knowingly and willingly imposing on them. IBM, on the other hand, is not interested in playing that game.

Check out this InfoWorld article:
IBM tells employees not to install Windows XP update.

Unlike most OS service packs, XP SP2 is being treated like a major OS rev. It almost is, since it is the only OS revision Windows will see until Longhorn finally grows up. However, that very interim-like nature of the service pack begs the question, “Should companies upgrade to XP SP2, or should they save themselves the headache until Longhorn arrives?” This is a good question.

For software developers, the question is irrelevant. You must upgrade your testing and development boxes and make your software compatible with XP SP2 so that all who do upgrade will continue to use your software. Many probably are already in the process of doing this with beta or release candidate versions of XP SP2.

Where the question is really pertinent is regarding non-IT personnel and their computers. How soon do you deploy XP SP2 on all of their computers? As a programmer, I know that I will want to run compatibility tests on all of my applications in XP SP2 before I will be comfortable with our personnel upgrading. This will involve hours of testing and bug fixing. Thanks, Microsoft.

Then a realization sends a sinking feeling into your stomach: Doing nothing could potentially be more disastrous than recklessly deciding to upgrade without compatibility testing your software! Eventually Microsoft will release XP SP2 via Windows Update, where employees will be free to download and upgrade themselves. If you have mission-critical software that will break in XP SP2, this easy accessibility will result in catastrophe.

Fortunately, as the InfoWorld article points out, Microsoft will help companies in such a situation by providing them instructions to disable Windows Update from installing XP SP2. Nevertheless, it is a regrettable dilemma that Microsoft forces action to be taken to avoid catastrophe. And applying registry settings to all company computers to disable Windows Update from installing XP SP2 (which is the solution Microsoft is providing) may not be as easy as it sounds for some companies. If your company has hundreds or thousands of computers and you have no automated method in place for applying these settings across all of those computers, you could have a serious problem. These are precisely the scenarios that nurture disdain for Microsoft.

So when XP SP2 arrives, will your company nix it? Or will you upgrade? I am a strong believer in staying current, even if it means added expense. Especially in this case, the deplorable condition of XP’s security makes upgrading necessary. But I promise you we will be applying those registry settings to delay the installation of XP SP2, just like IBM. Sorry Microsoft, we just don’t have time for disaster today.

We are living in a world that is becoming increasingly virtual. As computers house more and more of our information of and about our lives, we feel ourselves becoming virtually–no pun intended–fish out of water, that is, physical beings stuck in a virtual world.

Without any further ado, let me introduce an article:
Taming the Paper Tiger

Granted, this article was much more concrete than my commentary. It actually spoke to printing documents and reports, and software that addressed the issues behind the glut of printing in the corporate world, elicited by the easy accessibility of information provided by computers. But for a moment, consider the thrust of the article on a far more conceptual level.

For those of you who have bought into the digital camera game, when is the last time you actually printed all your photos from your vacation and placed them in your physical photo album? Or, rather, did you create a photo album available electronically either locally on your machine or over the web? I know I haven’t printed many photos, despite having a nice photo printer and spare ink sitting on the shelf. Not that I never print a picture, but I find myself using electronic photo albums much more frequently. Nevertheless, my wife and I were looking for a couple good photos awhile ago (ironically, to scan into the computer), and even thought it was just for a few minutes, I thoroughly enjoyed looking through our physical photo albums.

And let’s consider the topic of document printing for a moment. In the article, the author said, “It used to be that we would print and distribute; now we distribute and print. Instead of making 50 copies to send around, we send one e-mail and everyone prints it out individually.” I got quite a kick out of this. There is a lot of truth behind this statement. As I write this, I’m referring to the printed magazine version of the article, even though I provide you the electronic link to the same article, because it’s much more relaxing to read on real paper. And these facts apply more so in the corporate world, where email may contain information that we need to study and reference, unlike a lot of personal email that we may just read and file (or delete).

Don’t get me wrong. I think that digital music, photos and documents are a great idea. But it certainly is noticeable that as physical beings, this increasing amount of virtual content imposes a certain amount of discomfort on our non-virtual selves. Until our bodies become completely virtual, that predicament will always exist. And unless you’re changing your name to Neo, I don’t think that will be happening anytime soon.

I knew of HTTP Compression and for some reason never checked to make sure that my webserver had it turned on. The thought was prompted while reading Chad Dickerson’s series of articles about RSS and the related bandwidth issue it has caused, albeit not a “crushing” issue, as Chad acknowledged in the second article, “RSS Bandwidth Blues“.

What a concept, compress webpage code and content before transferring it, in cooperation with browsers that can transparently decompress the page upon receiving it. In other words, utilize that under-used CPU power to decrease web slowdown where it’s bottleneck really exists: Bandwidth.

If you want to know more about HTTP Compression (not terribly grimy detail, just a nice overview), try this WebReference HTTP Compression article. I take exception at some of the wording about IIS on the second page in the bulleted list, however, because it says, “If it finds a pre-compressed version of a requested document it might send it but has no real-time compression capability. It will, however, use precompressed files if they are available.” This makes it sound like some special process has to be ran to compress your site’s pages before IIS can send compressed versions of the pages. But as described in Microsoft’s HTTP Compression documentation, if no compressed version of a static document is available, IIS will send the document in an uncompressed form on that first, initial request, and compress the file in the background immediately thereafter. Thus, the static document will be available in it’s compressed form on any subsequent requests, automatically. I can live with that. Further, dynamically generated documents are compressed on-the-fly. Granted, the article does explain this a little more clearly in the following paragraphs, but the introductory paragraph is very misleading.

All that being said, I’ve enabled HTTP Compression on my webserver for static documents, which is what Blogger.com uses, since it publishes the blog as HTML files every time a change is made. Cool.