To upgrade one’s version of Windows — Vista to 7, say — is by and large a pretty painless experience for the home user. Office, likewise — there’s no dread that your Office 2003 files will be completely unopenable in Office 2007. So why is the poor sysadmin not afforded the same easy upgrade path?

In order to move an existing SharePoint Services 2 website to a new network with Microsoft Office Sharepoint Services 2007, one must:

1. Learn more than is healthy about the workings of Sharepoint and IIS (2 days, d10 SAN)
2. Back up the original site to disk (using stsadm.exe not smigrate.exe, as the latter is broken) (5 hours, 13 GB)
3. Install Windows Server, IIS, SQL Server and Sharepoint Services 2 on a new machine (1 hour)
4. Configure said IIS, SQL and Sharepoint (1 hour)
5. Restore the Sharepoint site from disk onto the new machine (>8 hours, >120 GB, d10 SAN, fails unrecoverably when out of disk space)
6. Perform an in-place upgrade to Sharepoint Services 3 (Several hours, 40 GB, may fail unrecoverably)
7. Back up this site to disk (5 hours, 15 GB)
8. Configure MOSS 2007 on the destination server (2 hours, 24 Google searches, d10 SAN)
9. Restore the disk backup to the MOSS 2007 server (5 hours, 40 GB, may fail right at the end if previous step performed incorrectly, d100 SAN if this occurs).
10. Manually recreate permissions on every Sharepoint site since all the users are now part of a new domain (8 hours, d10 SAN)
11. Perform a ritual to offer Great Cthulhu the souls of Microsoft’s Sharepoint development team (d30 SAN, remarkably quick by comparison)

I began this task on Tuesday afternoon as a mildly knowledgeable Sharepoint user with virtually no admin experience. By Thursday afternoon, I may have been our company’s most experienced Sharepoint-wrangler. On Friday morning, I started the above procedure. We are now on Step 5. 200 people are expecting to have Sharepoint access tomorrow. They have not a snowball’s chance in R’yleh.

So why can’t my computer suspend and resume properly?

The concept of ‘suspend’ — or ‘sleep’, or ‘standby’ — mode, whereby the computer dumps its internal state to RAM then enters a low-power state with its processor and other hardware turned off, is not new. The ACPI standard has been kicking around for 14 years now, a very long time compared to the life cycle of an operating system. These days, with laptop use on the rise, it’s a very common thing for users to want to do. And yet resuming from suspend is still hit-and-miss.

Why do I find it more reliable in Ubuntu than openSUSE for the same base kernel? Why does GNOME fare better than KDE? Why does my WiFi sometimes not come back? Why, with Microsoft’s million– if not billion-dollar operating system budgets, with Intel and AMD and nVidia’s decades’ of driver experience, is suspend and resume still frequently an issue even on Windows?

Only Apple, with its closed hardware / software ecosystem, seems to have cracked it.

I’d hate to think of that as the only way to a bug-free existence — I’m very fond of the idea of an open ecosystem where I can run whatever software I want on whatever hardware I want. But I’m worried. Is the range of (IBM-compatible, ACPI-supporting) hardware out there just too diverse and too widely different in its support for suspend-and-resume? Is it just infeasible for software to perfectly implement it on all devices?

Has hardware created the one software bug that, for any reasonable number of eyeballs, isn’t shallow?