The Ark Linux project is pleased to announce the release of Ark Linux NT (New Technology).

As the name implies, this new version is built around entirely new technologies – in particular, we have replaced KDE SC with a much more user friendly desktop known as “wine explorer.exe”, and OpenOffice.org/LibreOffice with the vastly superior “wine msoffice.exe”. Crappy open source games have been replaced with proper equivalents from the professional world (wine minesweeper.exe). Konsole and xterm have been replaced with dosemu to provide a much better command line experience.

Unfortunately given the licensing restrictions on some of the new technologies, this version can not be downloaded or freely distributed – Ark Linux NT is available for just $1999.99 at your favorite Linux shop. Ark Linux remains a non-profit project – the fee is entirely for the cost of creating the DVDs (we had to get away from the 1 CD installer in favor of 7 DVDs to retain the same level of functionality) and 3rd party licensing fees – $250 for the office suite, $560 for Windows 7 Ultimate neeed to get the revolutionary explorer.exe desktop, and $950 for replacing Krita and Scribus with the Adobe Creative Suite.

Nevertheless, this release has found high praise in the press and among the community.

Feedback ranged from “Replacing that crappy KDE with a desktop that actually works was a very smart idea, and it gets rid of that non-free Qt crap! This is the first version of Ark Linux I’m actually going to look at.” (Miguel de Icaza of the GNOME project) over “We hereby certify that this is the only version of Linux that is legal to use.” (Steve Ballmer, Microsoft) to “This is great! I’ve never seen a better version of Linux (and finally we’ll have a market on Linux too)!” (Mark Bregman, Symantec, Antivirus division).

The only slightly less enthusiastic – but less than devastating – comment came from a Free Software Foundation spokesperson: “It should be called Ark GNU/Linux NT.”

If you believed any of this, look at a calendar. But on a positive note, the next release that actually exists will be ready rather soon – I’ve been running development builds on all of my boxes for a while now, the most important remaining unfinished piece is the new network config tool.

The sad shape of apt-rpm, especially in combination with rpm5, has caused us to look at alternatives. Our decision to go with rpm and apt-get was made when we started 8 years ago – since then, a number of new things have come up and a lot of things could have changed.

Looking at the basic package managers out there, a lot of things have remained the same – while rpm and dpkg both made some progress, they’re basically what they used to be — both work, both have their own set of problems, but we do still believe our decision to go with rpm was the right one: rpm spec files are much easier to understand especially for non-programmers, and for experienced users, they take less time to write.

The problems people commonly talk about when saying rpm sucks are often not related to rpm — e.g. the “dependency mess” is caused by people trying to mix packages from Ark, Fedora, SuSE, Mandriva, Yoper, … – all of which are different core systems, using different package naming conventions, and slightly different filesystem layouts.
dpkg would have the exact same problem – if someone actually used it to build a fresh distribution with dpkg that didn’t share Debian’s core system (or something close to it), you’d run into the exact same thing as soon as people tried to mix packages from that new distribution with one of the traditional Debian derivates.

In addition to the big 2, there have been some newer entries into base package managers – most notably Pacman and PiSi.
Both of these are quite nice, and would be serious contenders if we were starting a new distribution from scratch – but neither of them offers enough of an incentive to make us want to put in the effort of converting our existing packages to something new. They also come with some drawbacks. While e.g. PiSi’s XML package descriptor solves a few problems, it is also harder to read or setup for a newbie, and we’re still trying to make creating packages newbie friendly (of course, a graphical package generator wouldn’t have too hard a time writing XML). Pacman’s idea of subpackages differs quite a bit from rpm’s idea (Pacman has different DESTDIRs for different subpackages, while rpm goes by file lists), and the way Ark packages tend to be split, creating subpackages using pacman would involve moving around files after installation – making it a bit more cumbersome than doing things rpm’s way.

In terms of package managers that run on top of the base package manager, lots of things have come up, not all of which existed back in 2001 — smart, yum, zypper, urpmi and poldek can do the job of apt-rpm.

smart, yum and urpmi are written in scripting languages (Python for smart and yum, perl for urpmi) – which has a drawback for something important for system recovery: If you break the interpreter (e.g. if the user does something stupid like trying to manually compile a shiny new Python 3.x to replace the “obsolete” 2.6 installation that came with the OS), the package manager won’t help you recover.

Of course, people might argue that you can break libc.so.6 or libstdc++.so.6 too, but if you do that, chances are your system is messed up so badly that you can’t fix it without booting from some other device anyway.

This is not a major showstopper (you can still boot from a live CD or install CD and run the package manager from there), but it is a reason for us to prefer a package manager written in C++ or C.

This leaves zypper, poldek and apt-rpm as our favorites — looking at the code of each, we’ve decided that, if further testing doesn’t prove us wrong, our next release will be using zypper.

It is readable code, porting it to rpm 5.x took us only a few hours, and the upstream developers were very responsive to our questions.

One potential source of problems with zypper is the order in which it does some things – e.g. when installing a package with many dependencies, zypper downloads a package, installs it with –nodeps, downloads the next package, installs it with –nodeps and so on [while apt-rpm downloads all packages first, then installs them in one go, avoiding the need for –nodeps].
This slightly increases the chance of corrupted packages when aborting a package installation.
This should be fixable with a bit of work though – and isn’t as big an issue as it may sound, another call to zypper will fix the corruption, and aborting package installations isn’t exactly recommended everyday use.

Those of you who have been watching our development tree will have noticed x86_64 packages being built over the last year or so — in the last week, I’ve extended the installer and CD build scripts to handle them the right way, and an initial snapshot build is available at http://arklinux.osuosl.org/dockyard-devel/iso/arklinux64.iso.

Of course, this is a development snapshot, so it shares all the features of the upcoming release — but also all the reasons why dockyard-devel isn’t being released as 2009.1 or even 2009.1-beta. Among other things, support for hotplugged devices is suboptimal, applications that should go to root mode crash on startup, apt-get doesn’t work, and there’s no splash screen.

That said, I’m using this version on my main machines these days, and if you know how to get things done without GUI helpers, it works pretty well. It is definitely ready for developers to prepare their code for the next release.

As of today, packages built on dockyard-devel will automatically generate -debug subpackages, containing symbols that make it easier to trace application bugs.
The debug packages will remain out of the standard installation to save space, but they can be easily installed through apt-get.

We’ve put this on hold a bit longer than many other distributions – mostly because we prefer doing things right over doing them quickly. The approach many others have taken is adding a %debug_package statement to the spec files for every package that should have a debug subpackage — effectively causing a lot of work for packagers, making sure not all packages get the debug subpackage, and not making sure packages built by 3rd parties get debug packages.

We’ve opted for (and finally implemented) the opposite — any package that contains binaries will automatically produce a -debug subpackage, unless the packager explicitly requests it not to, by putting “%define no_debug_package 1″ into his spec file.

This should make debugging problems much easier for users of the upcoming release.

We’ve been thinking about switching libc implementations in Ark Linux for quite some time — the thing holding us back was primarily that a small distribution like ours should try hard not to break compatibility with the big guys, to keep non-free software running.

Now that Debian is switching to eglibc, nothing is holding us back, and the eglibc 2.10 package is currently making its way through the build system.

We would still be interested in seeing the performance difference if we built the entire OS on top of uClibc or even dietlibc — but there are more important things to do right now.