My wife has a couple of external hard drives that she keeps her pictures and other transportable files on.  Recently, she’s been doing some cleanup work on those drives, making sure all of the files exist on one of the drives so that the other can be set up as a synced copy.  She completed her work, and I told her that I could do the sync for her.  I was planning to use rsync and, probably, set up an Automator script so she can resync them anytime she wants.  I was quite amused the next time I came to her computer.  There, on her keyboard, was this:

I should back up and fill you in on the fact that my wife is quite the fan of all things Alice in Wonderland. Her iMac is named Tweedle, with her internal hard drive being named Dee, and her primary external hard drive being named Dum. Her portable drive, aptly enough, is named Dinah.

So, here I was staring at this note that she had written to me.  As I said, I was quite amused, because the whole thing struck me like surgery, namely the practice of writing in permanent marker which limb should be operated on - or removed in the case of amputation.  The similarities were uncanny.  And, in truth, I was quite appreciative that she left that note there - making sure that I did not, after all, amputate the wrong drive!

I listen to a number of podcasts in the TWiT network.  Actually, I’m normally playing catchup as I’m subscribed to a number of their podcasts. One of the podcasts I’ve been catching up on recently is TWiL - This Week in Law - hosted by Denise Howell. It’s definitely a bit on the dry side, not as funny or lively as the TWiT or MacBreak Weekly podcasts that I tend to keep up with. If you’re dealing with technology or doing business in a technology-related field, though, it’s definitely worth checking out.

The episode I’ve been listening to lately is Episode 16, Cloud Computing and EULA Law.  One of the topics that they delve fairly deeply into in this episode is the topic of ediscovery, or the laws surrounding the legal discovery process relating to electronic assets.  They approach the issue more from a corporate perspective, discussing, for instance, the proper policies for archiving email communications and such.  They do, however, mention the employee use of personal resources and how that use could open up those personal resources to the legal discovery process.  It’s this last bit that caught my attention, both as something that is more common of a practice than anyone probably cares to admit and as something that could have more serious privacy ramifications for any employee engaging in this practice than that employee likely realizes.

To understand how broad this could be, lets look at a couple of examples of use of personal resources for transacting company business:

1. Sending company-related email from a personal email account (using your Gmail account from your iPhone was an example given in the podcast)
2. Using a personal laptop to do your work instead of a company-provided machine
3. Keeping company-related files and information in a personal Google Docs account or other personal cloud storage account

Are you guilty of any of these?  If you are, and the company you work for is ever involved in litigation where the information you handle is pertinent to the litigation, you could be exposing your personal account, and all that is in it, to the legal discovery process.  What does this mean in real terms?  Simply, it means that attorneys, paralegals, and clerks could end up combing through everything in your account or computer looking for whatever evidence they need for their case.  While only pertinent evidence would be presented in that litigation, most people would shudder at the idea of an outsider having full access to their personal information.  Now, I am certainly no attorney, but I would imagine that there would need to be clear evidence that someone was using personal resources on a regular ongoing basis in order for a judge to grant a litigant access to his or her personal resources like this, but, if there is clear evidence that pertinent information could be stored on non-corporate resources, the judge would likely be obliged to grant such access.

So what can be done to keep this from happening?  The way I see it, protecting personal privacy in a corporate environment requires a two-fold approach.  As in many instances, the first approach is education.  Employees must be made to understand the risks they are taking with regards to their privacy when they use personal resources for company business.  The second approach is one the companies themselves must undertake.  Companies need to understand that employees are likely turning to various personally-owned resources because they are more convenient.  To make sure that employees are complying with applicable laws and company policies and aren’t opening themselves up to personal exposure, corporate IT departments must make sure that corporate electronic resources are readily available and easy to use.  If, for instance, you, as a company, expect your employees to be answering email while out of the office, but your email server is only available through a hard-to-use VPN, you’re setting your employees up for failure, because they’ll turn to services they have easy access to in order to fulfill the requirements of their jobs.

So, if you’re an employee reading this, think about the ways you may be unintentionally exposing yourself.  If you’re a corporate executive or IT person reading this, think about the ways in which your employees access company data and how they jive with the requirements of their jobs.  If you don’t, you may be putting your or your employees’ personal privacy at risk.

Yes, another politically-slanted post.  I’ll try to keep them to a minimum, I promise.

There has been much discussion lately on the subject of broadband deployment in the United States.  I fall on the side of the fence that says that our broadband deployment yardstick is long out of date.  I am happy to see the new administration seeking to update our broadband standards.  Regardless of this, though, I had some thoughts on broadband in general that I wanted to share.

First of all, I have been quite frustrated with ISPs for some time in the area of what was considered quality broadband connectivity.  This frustration stems from unimpressive download speeds, absolutely laughable upload speeds, quality of service issues, and even anti-competitive practices that have sparked the debate on Net Neutrality.  One of my largest frustrations, though, is that the American people, for the most part, don’t seem to mind.  Why is this?  My personal opinion is that they don’t know any better.  Call it patriotism, call it pride, call it whatever you want, but most people in this country tend to think that, because we’re America, what we have must be the best.  Is this the best I can get in the way of Internet connectivity?  Well, we’re America, what we have must be the best right?  WRONG.  While most households in the US contend with sub-5Mbps connections, many of the so-called broadband connections still being sub-1.5Mbps connections, users in places like Japan are enjoying 100Mbps to their residences.

It is my opinion that, since most users in America have not experienced what real, true, high-speed broadband connectivity feels like, they are content to enjoy their current sub-par speeds, naively believing that this is as good as it gets.  Were these users to experience what true fast broadband felt like, even for a short time, they would begin to clammer for that level of service from American broadband providers.  As it is now, those providers are perfectly content to sit on their laurels, not having any driving force for real innovation.  Some ISPs have begun to come around recently.  Verizon, for the most part, started by rolling out its FiOS fiber optice service, the service that I use and love.  This service began offering not only higher speeds, but higher quality.  Connections that didn’t cut out at all times of the day and the capability to actually sustain a download at or near the full speed of the connection were a welcome change for these users.  One other feature of the service that was unheard of at the time, but extremely welcome by people like me, were much higher upload speeds.  Even now, it’s not uncommon to find the uplink speed of a broadband connection set at 512Kbps or worse.  FiOS offered an uplink speed of 2Mbps or better.

Other ISPs are starting to come around, but the going is slow.  Comcast, for instance, is rolling out speed increases to many of its users.  Prior thinking on speed must be rethought.  Previously, uplink speeds were kept low.  Some of this dates back to the A in ADSL, or asynchronous, meaning the uplink speed was lower than the downlink speed by design.  For newer broadband technologies, though, the speeds really need to become more synchronous.  We as a society are changing how we use our connections.  More and more of our lives and our businesses are online.  More importantly, more of our data is living in the cloud.  Cloud services are great for end users since they provide for more efficient use of available resources.  For cloud services to work, though, users must be able to upload their data to the cloud in a fast and efficient manner.  The success of cloud services really does depend on better broadband deployment.  As more of our communcations depend on broadband connectivity, that connectivity simply must become better, faster, and more stable, and ISPs’ feet must be held to the fire to provide users with the level of service expected of a utility service.

I usually try to steer clear of political issues.  In areas where politics and technology cross paths, and perhaps collide in a blinding flash of light, I must make my two cents known.

I’m from the great state of Texas.  Until the other day, I had no opinions on one senator from Texas, Senator John Cornyn.  That all changed on Friday when I read this article on CNN.  Sen. Cornyn is the sponsor of Senate bill S.436, a bill to “…amend title 18, United States Code, to protect youth from exploitation by adults using the Internet, and for other purposes.”  While the stated purpose of this bill is fundamentally good, at least one provision in the bill is very bad.  I find child exploitation as utterly despicable as the next person, but I cannot get behind this bill from a technological and pragmatic perspective.  What’s my beef with this bill?  Take a look at Section 5 of the bill, entitled “RETENTION OF RECORDS BY ELECTRONIC COMMUNICATION SERVICE PROVIDERS.”  There has been much buzz going around the Internet since this first came to light, but I wanted to share my thoughts on the issue.

What Section 5 of this proposed bill states is this: “A provider of an electronic communication service or remote computing service shall retain for a period of at least two years all records or other information pertaining to the identity of a user of a temporarily assigned network address the service assigns to that user.”  In non-legalese, what does this mean?  Lets look at three very important parts: “temporarily assigned network address,” “provider of an electronic communcation service,” and the two year requirement.

First up: “a temporarily assigned network address.”  In the context of the bill, this most definitely refers to any IP address assigned temporarily, via DHCP, PPP, PPPoE, or other IP address assignment methods.  OK, so the government is wanting DHCP, etc. logs kept for at least two years.  Why?  Because it is considered “information pertaining to the identity of a user.”  Here’s the catch:  one of those assignment methods, the one in most wide use, may not carry with it the ability to identify a user.  The culprit: DHCP.  DHCP in and of itself is incapable of truly identifying a user.  With PPP or other authentication-based methods, the provider at least has the ability to see what account was used to access the network resource in question.  The only real identifying information with DHCP, though, is the hardware, or MAC address, of the network interface requesting the address.  As most IT professionals and hobbyists know, this information is easily discovered and manipulated.  Take a scenario such as this, a scenario that has long been used by security analysts:  User Joe is going to use the WiFi network at his favorite coffee shop.  He opens his laptop and associates his WiFi adapter to the coffee shop’s WiFi network, which causes his laptop to request an IP address via DHCP.  For ease-of-use, the coffee shop uses a widely deployed method of access: open WiFi network with a web based captive portal for access.  In theory, once User Joe has logged into the captive portal the portal would have a record of his identity from his authentication plus information from his DHCP transaction, including the temporarily assigned network address (IP address) and his MAC address.  Now, lets say that User Bob intends to perform nefarious acts on the Internet and is looking for a way to cover his tracks.  Knowing how easy it is to spoof a MAC address, he sets up his laptop in the same coffee shop as User Joe and begins monitoring the WiFi network.  User Bob’s sniffing activities uncover that User Joe is actively using the Internet from an authenticated account.  Any captive portal worth its spit will make sure that any traffic allowed through it matches what it knows for the MAC address and IP address of an authenticated user.  User Bob knows this.  So User Bob, using software built into many operating systems, sets the MAC address and IP address of his WiFi adapter to match that of User Joe.  User Joe may or may not realize that anything has happened, but most likely unbeknownst to him, User Bob is now masquerading as him performing his nefarious acts.  This is where the identity information breaks down.  User Joe stands to be falsely incriminated for acts he did not commit.  This is also how the vast majority of public access WiFi networks operate.  Those that don’t make use of a captive portal, or any authentication mechanism for that matter, have absolutely no real identity information to go on.  If law enforcement were to obtain DHCP records for such nefarious activity in this case, and even if they were able to track down the MAC address obtained from those records to an actual user, they would have no way of knowing whether the user they tracked down was actually the culprit.  This doesn’t even take into consideration the case where the true culprit does not use DHCP and just manually sets an IP address on the network in question.  No DHCP logs exist in this case.  As I mentioned before, DHCP is the most prevalent method for assigning IP addresses.  It is used on every broadband router on the market to assign addresses to its clients, by many broadband ISPs including cable, WiFi, and DSL, and just about every corporate, private, and government network in existance.  The only other mechanisms in real widespread use are PPP-based methods, such as dialup Internet access and PPPoE as used by broadband ISPs not using DHCP.  The only way around this is for a network that employs DHCP to also employ per-client authentication and encryption mechanisms such as Enterprise-level WPA2.  Now, WPA2 Enterprise, as used in WiFi does not, in and of itself, keep bad people from configuring the IP address manually, therefore not using DHCP, but it does make certain that every user on the network has individually authenticated and that the MAC address tied to that user has not been changed.  Even so, this is only capable of unequivocally identifying a perticular user when combined with logs of actual Internet connections as taken from the local network segment, where the MAC address is available for such logging.  This has been a very technical explanation, but it shows why DHCP records, in and of themselves, are not adequate for proving the identity of a perpetrator.

Next up is the “Who”:  “A provider of an electronic communication service or remote computing service.”  It took me some time to locate any even semi-accurate definition of this term.  Unfortunately, the original section of Title 18 that this bill is trying to amend does not define what or who a “provider of an electronic communication service” is.  To find a definition, I had to look to court rulings.  According to this page in the EFF’s Internet Law Treatise, referencing several court cases on the matter, including United States v. Mullins, 992 F.2d 1472, 1478 (9th Cir. 1993), a “provider of an electronic communcation service” is not limited to a traditional service provider, such as a Telco or ISP.  It covers any entity who may provide access to these services.  It is still unclear for certain whether individuals fall under this moniker, but given the wide definition used by the courts in various cases, it is entirely likely that individuals who provide Internet access do indeed fall under the umbrella of such a provider.  What does this mean in real terms?  Anyone who has a Internet connection and uses an off-the-shelf broadband router, or any Internet connection sharing technology (such as the Internet connection sharing features built in to Windows, Mac OS X, Linux, or even such a device as an iPhone with the briefly-available Netshare application) would be required to comply with this new records retention law.

Finally, we come to the two year requirement.  For Internet usage records (logs), especially in situations where the service is provided for free, two years is an extremely long retention requirement.  Most true ISPs will have no real trouble complying with such a requirement, since the logs can be compressed and archived to save storage space, and ISP equipment is designed to generate and keep such logs.  Given the above, however, requiring such logs for the purpose of identification may not even make any sense since such logs may not be capable of proving, beyond a reasonable doubt, the identity of a perpetrator.  Beyond that, though, is the fact that most equipment in use by smaller entities, such as home users, libraries, coffee shops, and most small businesses, is not even capable of keeping such records, or, if it is, configuring the equipment to do such retention is beyond the technical capabilities of the users of such equipment.

When I put all of this together, I came to a very unfortunate conclusion.  Most people or businesses that could potentially be affected by this law will actually be completely incapable of complying with it.  By enacting this bill into law, the lawmakers have essentially placed almost every broadband user in the United States in danger of being incriminated by not complying with this law.  And for what?  Will this portion of the bill truly assist in capturing those that would exploit innocent children?  No, unfortunately not.  This portion of the bill will actually serve to incriminate more innocent citizens than it will catch pedophiles.

This is a prime example of why poorly-researched laws can be problematic for everyone.  Such ludicrous requirements can also have the unintended side effect of stifling broadband deployment.  If would-be broadband providers are unduly burdened by such ineffective laws, they will be less likely to roll out new broadband services.  In a way, this may even fly in the face of President Obama’s broadband deployment initiatives.

During my time working in the Networking Services department at UT Dallas, I gave a presentation for the EDUCAUSE community about the work I did to transition our wireless LAN security from the static WEP security in place at the time to the more enterprise friendly 802.1X based security that it uses today.  I first gave the presentation live at the EDUCAUSE Southwest Regional Conference held in Austin, Texas in February of 2005.   After the live presentation, I was approached about giving this presentation to the larger international EDUCAUSE body at one of the (then) upcoming EDUCAUSE Live! web seminars they do every month.  I, of course, jumped at the opportunity, and gave the seminar on April 25, 2005.  It’s hard to believe that it’s been just over three years now.

One of the things that I liked about the EDUCAUSE Live! events was that, in addition to being a live web event, they were also archived so that viewers could benefit from the information in previously recorded sessions.  The Live! folks recently switched from the streaming system they were using before, based on Horizon Wimba, to a new system based on Adobe’s Acrobat Connect.  In the process, they unfortunately broke the links to all of the archives from the Horizon Wimba days.  This presentation still comes up when when I talk to folks about network security, as it’s a very good primer to what 802.1X is and how it works, so I still like to refer people to it when I can.  The good news is that the archives are actually still alive, just not readily accessible without instructions, so I thought I’d post the instructions for getting to my presentation here.

First of all, you can get to the information on the presentation and the PowerPoint slides by going to http://www.educause.edu/LIVE058 and clicking on the View Event Archives link at the top left.  To get to the full audio/video archive of the presentation, follow these instructions:

• Point your browser to the EDUCAUSE Live! Horizon Wimba Server
  
• Click on the Participant Login button
• Enter “educause” (without the quotes) in the Login ID field, and put anything in the Name field
• Once logged in, the Wimba service will run through a wizard to make sure you have all of the necessary components installed to run the presentation
• After finishing the wizard, you will be taken to the main Horizon Wimba window, click on the Archives tab
• Scroll down to the link titled “2005/04/25: Mike Griego, Wireless Security with 802.1X” and click on it to begin the presentation

Take a look if you’re at all curious.  If your organization is looking to implement enhanced security for your wireless LAN, whether it’s being required of your organization by privacy statutes such as HIPAA, or you simply need to be assured that your network and data are safe, Nearband Networks can work with you to achieve that goal.  We have years of experience under our belts that we can use to ensure that your wireless network is secure while also making the transition as smooth as possible for your users.

Next Saturday, March 22, a mere 11 days from now, the Intel Pentium processor will turn a grand 15 years of age. The Pentium marked a pretty dramatic increase in x86-based processor optimization capabilities, namely the introduction of multiple instruction pipelines. The optimization gains were so much so, that many software packages don’t usually enable CPU code optimization beyond the standard 386-level 32 bit code until you get to the Pentium/i586 architecture.

The age of the Pentium CPU was quite astonishing for me to realize. I remember our family purchasing our first Intel-based PC in 1993 with a 486 CPU. At the time, the Pentium was brand new. Those who were involved in the computer industry during this transition to brave new CPU-worlds will remember that the original Pentium chips, running at a blazing 60 and 66 MHz, had numerous heat issues. The 486 and earlier CPUs of the time did not have the heat dissipation issues that the Pentium chips had, so the older CPUs could usually get by with merely a heat sink attached to the chip. The Pentium was the first real introduction to computer enthusiasts of the requirement for not only a heat sink for the CPU, but a fan for active cooling of that heat sink as well.

Continuing in our early-to-mid-nineties throwbacks, the Pentium Pro will turn 13 in November of this year, reaching CPU adolescence. The Pentium Pro itself may not have seen wide adoption among computer enthusiasts, who instead opted to upgrade to the more consumer-friendly Pentium IIs, but the Pentium Pro left us quite a legacy of its own. The Pentium Pro ushered in the i686 instruction set, the prevailing 32 bit x86 instruction set to this day. The x86 instruction set would not see another serious upgrade until the release of the first x86_64 instruction set-based CPU, the AMD Opteron, in 2003. It would be approximately a year later before the first Intel CPUs sporting the new 64 bit architecture began shipping. It’s still amazing to me that the i686 instruction set, still the most widely used instruction set for x86 machines, is almost 13 years old. Around the time that Pentium Pro arrived on the scene, RISC architecture was becoming more and more prevalent, and the industry buzz was that RISC would become the architecture of choice, even for desktop CPUs. With the increasing optimization of the x86 architecture, including the inclusion of several RISC principles in the CPU, the i686 instruction set has lived on, and pure RISC has all but become a thing of the past, relegated to niche sectors of the computing world. Of course, the most recent, and high profile, casualty of this is the switch Apple, Inc. made during the 2006 year from its previous PowerPC based machines to its current Intel-based machines.

The first real usage of a brand for CPUs by Intel, the Pentium name is still with us to this day. With the introduction of the newer Core branding from Intel, the Pentium name has taken its place as the new moniker for lower-end processors from the silicon giant. Still, its been a great 15 years. Here’s lookin’ at you, kid.

One of the things I love about Zimbra as an administrator is the fact that it includes some decent graphing functionality in the administration interface. I can quickly see the health of my Zimbra servers and the affects of any configuration updates I’ve made.

Many companies and other organizations these days have multiple domains, and they want to be able to receive mail for the same addresses (local parts) at each domain. The standard way to handle this in Zimbra is to create an “Alias Domain”, or a domain with the zimbraDomainType set to “alias” and the zimbraMailCatchAllAddress and zimbraMailCatchAllForwardingAddress attributes set appropriately. Since Zimbra uses Postfix as its underlying MTA, this translates to setting:

@aliasdomain    @realdomain

in your virtual alias table. Herein lies the problem with doing that: using this sort of aliasing bypasses Postfix’s ability to properly check for valid addresses.

When Postfix, and hence Zimbra, begins receiving a message, in a normal configuration, it will check its final delivery tables (local, virtual, etc) to see if the recipient in question exists. If the recipient does exist, the message will be accepted. If the recipient doesn’t exist, Postfix will reject the message before queuing it. This is exactly what you want to happen when (not if) your server gets hit with a dictionary-style spam run. In this case, the sender is trying lots of addresses that don’t exist, so you want your mail server to reject them without processing them, since processing them likely includes sending them through your CPU-intensive spam and virus filtering systems. Postfix, however, only performs a one-level check to see if the recipient exists. By one level, I mean that Postfix only looks to see if any mailboxes or aliases exist without seeing what those aliases might result in. Because of this, Postfix will see that a catchall alias exists for a certain domain and decide that a match exists without seeing whether or not the target of that alias is valid, and, therefore, accepts the message for processing. This is actually correct behavior since its impossible to tell if an alias actually translates to a valid recipient in many cases, but it can have dire consequences for your mail server. It can even mean that your mail server can be blacklisted for sending out tons of non-deliverable reports for users who don’t exist, since many spam bots use invalid sender addresses as well.

To combat this problem on my Zimbra servers, I recently wrote a simple script that creates actual one-to-one aliases. One-to-one aliases, as opposed to catchall aliases, allow the Postfix server to reject messages for non-existant recipients since an alias won’t exist for that recipient. The script periodically runs through the Zimbra LDAP store and finds all addresses in the designated primary/real domain. It then checks for existing aliases in any domain that is “attached” (as opposed to aliased) to the primary domain. Any aliases that don’t exist get created, and any aliases that exist for addresses in the primary domain that no longer exist get deleted. Pretty simple in the end, but the results have been excellent. Below is a graph of the messages processed by the Zimbra Amavis (spam catching) process. Green represents the total number of messages processed, and blue represents the number of spam messages. As you can see, since the script was put in place four days ago, the amount of noise that is now being outright rejected and no longer processed due to this one seemingly simple change is pretty amazing.

I had occasion today to need to do some “creative” email routing for one of my Zimbra servers. Charter Communications appears to have either blackhole-routed or simply firewalled traffic coming from a block of IP addresses that I recently acquired. I guess that the last person/company to use these addresses may have upset them in some way. As far as the public RBLs are concerned, the block is clean, but Charter doesn’t like it, and they haven’t been very responsive to my requests to have the block re-evaluated. So, in the meantime, I decided to route email from that server headed to charter.net through another MTA of mine on a different address block that was not having problems.

Figuring out how to set up a regular transport in Zimbra was interesting. Searching in Google didn’t turn up any dead ringers for my issue. Of course, I could have just gone into the Postfix configs directly and set up the transport maps, but what I really wanted was to be able to do it from inside of Zimbra itself. After poking around at Zimbra’s Postfix configs, along with contextual clues from some of the articles I looked at on Zimbra’s wiki and forums, I came up with the answer.

Zimbra stores just about all of its transient configurations in the Zimbra LDAP server, and if you look at Zimbra Postfix’s transport configuration, it indeed does look up all transport configuration, by default, in LDAP, so I wanted it stored there. You can specify the zimbraMailTransport attribute for any domain or account, and the value is the value that would appear in a Postfix transport map (ie smtp:mx.domain.com, etc). So I knew I wanted a domain that has the appropriate zimbraMailTransport attribute, but, by default, a Zimbra domain also means that Zimbra’s Postfix will try to deliver mail for the configured domain locally. A quick look at the Zimbra Postfix virtual_alias_domains and virtual_mailbox_domains configuration provides us with the answer. The LDAP filters for each of these table lookups looks for the zimbraDomainType attribute to be either local, for a virtual mailbox domain, or alias, for a virtual alias domain. Nowhere else in the Postfix configuration is the zimbraDomainType attribute referenced. So, the answer in that case was to set the value to something other than local or alias. I used simply “transport“.

So in the end, it turns out that setting up a transport in Zimbra for charter.net was actually a very simple process from the command line:

zmprov cd charter.net zimbraMailTransport smtp:other.MTA.server zimbraDomainType transport

Indeed, once I did that and requeued mail headed for charter.net, Zimbra dutifully passed off the mail to my other MTA, who I had set up to accept relayed mail from the Zimbra server, and that MTA passed the mail on successfully to Charter. Just another day in the life of a postmaster.

I’m a Mac guy, but, as with many others, my position as an IT support person requires me to use Windows regularly (and know it inside and out, of course). As such, Parallels was a no-brainer when I got my MacBook Pro. When Parallels stopped working for me after installing the Mac OS X 10.5.1 update, and at that absolute worst time for me, when I needed my Windows system for some work I was doing right then, I had a choice. I had already been toying with the idea of playing with VMWare Fusion after reading some reviews, but nothing I had read was really pushing me over the edge to jump in and try it. Most of the reviews I were reading said that, yes, the performance was better in VMWare Fusion, but they were really neck and neck, all things considered. When Parallels stopped working, it became just as easy to download a trial of VMWare Fusion than to try an uninstall/reinstall of Parallels, so that’s what I did. The result for me was that I realized that the reviews I read were all wrong, and in a good way. The performance gain of VMWare is so noticeable that there’s almost no comparison. I can now boot my Boot Camp partition containing Windows Vista, and not have to wait 15 or so seconds to have enough available system resources for me to continue the work I was doing before. In addition, I can actually leave that Vista system running in the background constantly without having the noticeable drain on resources that was very apparent in Parallels. It’s just much smoother, seamless, and less of a drain on the main system.

There are a number of other small things I like about the VMWare product as well. I like the fact that the screen saver doesn’t activate while the VM is running (yes, I know I could have deactivated this myself, but its little touches like this that make a product better). One of the things before that had me really thinking about switching to VMWare Fusion was the ability to use the growing number of VMWare appliances, something that comes in handy as an IT support person. I like the fact that I have the ability to run 64 bit guest OSes. There are just a lot of features like this that really round out the product and make it a much better product for a serious user.

So, Parallels, you were first on the scene with a good product, but you’ve fallen behind. What happened? I tend to like to see the underdog win when possible, but you’ve lost the edge. As such, VMWare Fusion is my new friend, and I think we’re going to be pretty good friends.