A lot has been said and written about Ubuntu Unity, the new ‘shell’ that’s replaced the ‘classic’ default GNOME desktop in Ubuntu 11.04. Despised by many that interpreted Canonical’s break from the ‘open-source’ norm of restricting modifications to upstream platforms to a bare minimum, as a threat to the upstream projects’ existence (a valid point to an extent), that found it to be half-baked and offering little more (if anything) over the classic desktop and a couple of additional programs (e.g. a Dock, a launcher etc.) while much slower and kludgey (a totally valid point, but it’s a 1.0), Unity is here to stay.

It is true that, despite Shuttleworth’s ramblings on his blog, most of Unity is hardly innovative. Most useful things in there can already be found in most modern desktop environments (including some linux desktops) while Unity’s implementation of those very features is hardly the best. But there are also some unique offerings that are different, such as lenses and the proposed (but not yet included, thankfully) windicators. The question there is: are those features really useful? Are they well thought-out?

I think not. Take for example desktop search, a hot subject in mid 2000s desktops that’s been largely solved in an exemplary way in OS X by Apple’s Spotlight and a number of third party tools on that platform (LaunchBar and then Quicksilver are prime examples of early game changers), and even Windows 7 to some extent through the built-in search field in the start menu. Then, with five years of hindsight, Canonical decides to make things somewhat harder for users by exposing the search context to the user in the form of completely separate ‘lenses’ as opposed to keeping the distinction internal (in the same way OS X does) and presenting filtering options in an innovative way. Put it simply: I’d much rather have a single search field, ala Mac OS X’s Spotlight that searches for my input text across ‘data domains’ and contexts and returns useful, filterable lists of data, than the frustratingly badly designed ‘lens’ concept that forces a clear separation of searches while taking up screen real estate and wasting the users’ time with additional clicks and keystrokes.

Which begs the question: why on earth did the fine people at Canonical make such a bad design decision, when the stated mission of Unity was to streamline the desktop while taking less space etc. and at the same time there are numerous implementations of search/launch applications (even in linux) that work significantly better than Unity? Were they afraid of being labelled copycats? Is that worse than been called bad designers?

The same can be said about the new ‘global menu’ and AppIndicators that replace Gnome panel in Unity. Having few replacements for the staple Gnome Panel widgets of yesteryear is fine, given it’s a 1.0. Having botched the whole concept of a global menu through inconsistencies when windows are maximised and in multi-display scenarios betrays a badly designed (viz. not just incompletely implemented) system that shouldn’t have been out in the first place.

Unity has divided the GNOME community by introducing a new shell on the world’s most popular linux distribution. While it’s true that the state of linux desktop has been moving frustratingly slow for a number of years and that a quasi-open project, funded by a commercial entity with a focus on usabilty and æsthetics — exactly like Unity is on paper — could help accelerate its development and help reach parity with the two main desktops in some of the more difficult areas where linux has been falling back over the years. Still, Unity is largely incomplete, it’s missing many of the configuration options and functionality that linux users are used to — nay, demand — and, sadly, what’s there betrays a rushed, badly designed feature set that should never have gone past alpha inside Canonical, let alone be part of the world’s most popular distribution.

Upstart is the ‘new’ event-based sysvinit replacement by Canonical, that has been widely adopted in the linux world ever since it first appeared in late 2006. The idea is centred around causality, that is, defining relationships that are not loosely defined by some measure of time, but by the presence (at runtime that is) of processes that a service depends upon. For example, if you need service X to run after service Y, you shouldn’t have to ‘wait’ for Y to start before starting X, but, instead, you should be able to specify that X depends on Y in some canonical form and the system would try to start X as soon as Y was up and running. In other words as a user/administrator of a machine you shouldn’t have to go through all that S?? and K?? silliness from SysV.

Upstart is by no means the first such service management system; Apple has incorporated its own version of such a system, called launchd, since the mid 2000s and so has Sun Microsystems with SMF. In fact, launchd was considered as a sysvinit replacement for Ubuntu 6.10, before Upstart was anything but a crude replacement for the /sbin/init daemon, but the idea was scrapped due to licensing issues (launchd was at the time licensed under the somewhat controversial Apple Public License; it has since been relicensed under the Apache License).

In the upcoming Ubuntu 9.10 release Upstart has reached another milestone, ‘just’ three years since it first made its appearance as a project; a number of core scripts have been rewritten as Upstart jobs (yay). Despite the fact that Upstart has been adopted by a number of systems (including Fedora, Maemo and — soon — Debian, among others) there are numerous issues (and practically no documentation for most of the system) as well as extreme volatility in both the format and structure of Upstart jobs and — alas — the aimed featureset. The only thing that’s been ‘stable’ in Upstart is the actual daemon, while the configuration/job format has been changing (and being moved around) every few months.
»