A First Look at Specifix Linux

With new Linux distributions being created just about every week, very few of them end up making headlines on Linux news sites. Specifix Linux, first announced in July this year, was different for two reasons. Firstly, it was founded by well-known former executives at Red Hat, Inc. - Erik Troan and Kim Knuttila, and joined by two more ex-Red Hat software engineers - Michael K. Johnson and Matt Wilson. Secondly, Specifix Linux was to be built around a new package management system, called "Conary".

Upon hearing the words "new package management", many readers will probably react with a "oh, no - not another one", fearing further incompatibilities and fragmentation in a market already split between RPMs, DEBs, TGZs, ebuilds, and many other "novel" ideas. But the fact that Conary was being coded by several high-profile developers, with extensive experience in helping to build Red Hat Linux, did arise more than just slight curiosity among many Linux users. After all -- and let's be honest about it -- the RPM package manager was created in 1995, when it was a radical idea that helped Red Hat gain converts from the then dominant Slackware Linux, but is it still the best we have, some nine years later? Isn't there a better, more universal way of managing software on a Linux distribution?

Enter the world of Specifix Linux and Conary. Since the original announcement, the project has been moving along at a rapid pace, producing new ISO images on a (more or less) weekly basis. The latest version of Specifix Linux is 0.11, complete with a graphical installer (Anaconda) and inclusive of Linux kernel 2.6.8, X.org 6.8.0, GNOME 2.8 and the usual range of software packages on two CDs, with more available on the distribution's FTP repository. At first sight, there isn't much unusual about this distribution - that's until one starts examining its star application: Conary.

In the words of its developers, Conary is a distributed software management system for Linux distributions meant to replace traditional package management solutions (such as RPM and dpkg). It operates around two principal characteristics - shadows and changesets. Shadows provide a simple way of maintaining customizations in applications and libraries that change often - a common feature of most open source work these days. While in the traditional package management model, any newly introduced package version would have to have any customizations manually applied after each upgrade, shadows allow for individual maintenance of the original package, and its customization. This is done by keeping the customization as a separate component of the "Conary package", or "trove" in Conary-speak, together with other components, instead of merging all customizations into the package itself.

The above process is further facilitated by the use of changesets. In a traditional package management system, any package upgrade will mean that all files present in the original package will be replaced with files in the upgraded package, irrespective of whether the files have changed or not. This represents unnecessary overhead in terms of hard disk storage, processor use, and, if the upgraded package is fetched from a remote repository, bandwidth use. On the other hand, the concept of changesets, as implemented in Conary, merely fetches and upgrades those files that have been modified upstream. An interesting indication of this feature's intelligent design is the fact that the changesets are not cached on the Specifix FTP server, but rather generated dynamically with every remote request, depending on the version of the package already installed on the system and the desired version of the upgraded package.

The concepts of shadows and changesets are not particularly easy to explain in a couple of paragraphs, but further understanding can be gained from white papers published by Specifix and available in PDF formats on the Specifix Wiki pages. Additionally, investigating the structure of troves and their components within conary-gui (a GTK2-based graphical frontend for conary, see screenshot) will further clear things up. However, it is important to stress that much of these technical details will only be relevant to developers and system administrators, rather than end users of the distribution. [Editor's note: see also LWN's description of Conary from last July.]

Despite the many sound concepts and rapid development progress, the Specifix Linux is still alpha status. The code powering Conary has not been optimized for speed and in its current state, it feels sluggish, especially when using its GUI frontend. It also misses essential features found in other graphical package management tools (Conectiva's Synaptic comes to mind), such as package searches, remote repository definitions, listings of dependencies, etc. These will likely be added in time, but right now the application feels rather bare-bone.

Once you start comprehending the basic concepts of Specifix Linux, it is easy to understand the company's sales line, which revolves around the term "customization". While users of other enterprise distributions are often unable to customize the purchased software to fit their needs without invalidating the accompanying support contract, with Specifix Linux, and its idea of maintaining all customizations separately from the base product, this is no longer an issue. The customers will maintain their own customizations, while Specifix will continue providing support for the base system. It should be a win-win situation for both parties, at least in theory.

---

(Log in to post comments)