Ubuntu’s Unity interface (image credit: webupd8.org)

It’s a fairly bold new direction for Ubuntu’s UI, and the first time their default interface has really diverged from what the upstream GNOME project provides. Now I don’t like it for a number of reasons: it’s slow, it doesn’t provide some basic functionality, other functionality is really well hidden (Go on, re-order your icons. Try it.) and it’s got an “our way or nothing” approach to handling workspaces.

On one hand, as a software guy whose main specialisation is user interface design, I understand the urge to try new UI paradigms as often as possible, on the grounds that sooner or later you’ll discover something that really is better than what you currently have. On the other hand, I quietly despair at how far off that “something better” seems.

Take, for example, me. I’m a UX person, and a perfectionist when it comes to interfaces. I’m irritated by slightly-wrong fonts and icons a couple of pixels out of alignment. I love new things, new ways of organising and displaying data. I’m big on augmented reality. And my desktop looks like this:

Now I think that’s aesthetically pleasing, but in terms of functionality, it resembles nothing quite so much as:

Yeah, that.

The only notable exception is GNOME-Do (think Launchy on Windows or Quicksilver on OS X), which I use exclusively for launching apps. The main menu, lower left, only gets used if I forget the name of something. Aside from that, I’m using my computer in exactly the same way I was 16 years ago.

The reason for that, as far as I can tell, is that it is the UI of least resistance. In sixteen years, probably 99% of my computer-using time has involved an interface that’s very similar to that one. Sure, there are certainly better UIs out there. Maybe from an objective point of view, Unity is one of them. But for more than half of my life, my brain has been slowly optimising itself for the Windows 95 style interface.

To become the “next big thing” in desktop UI, a new paradigm must not only be better than what came before, it must be so much better that our brains don’t mind losing half a lifetime’s worth of learning.

That’s a milestone I haven’t seen reached lately on the desktop, and a fear we may not see it reached before “the desktop” stops being a thing.

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?