Why Debian?

Most of the packages in 64 Studio come from the unofficial Pure 64 port of Debian testing, with some from Ubuntu, some from DeMuDi and some custom built. A more obvious choice might be Red Hat, given that many of the high end (which is to say expensive) proprietary tools used in Hollywood studios and elsewhere are sold as binary-only Red Hat packages. However, the split between Red Hat Enterprise and Fedora Core presents serious problems for any derived distribution. You could rebuild Red Hat Enterprise from source as long as you removed all Red Hat trademarks, but that’s a lot of extra work—and you’d have to follow Red Hat’s agenda for its distribution, which you couldn’t have any input to.

On the other hand, you could build a distribution on top of Fedora Core. It’s broadly Red Hat compatible, and there are the beginnings of a community process taking place—although it’s still far more centrally controlled than genuine grass-roots distributions. The key problem with this approach is that Fedora Core is not designed or built to actually be used. I can say this with some confidence because I was able to ask Michael Tiemann, former Red Hat CTO and now vice president of open source, this question myself. Fedora Core remains a technology preview for Red Hat Enterprise, and the Fedora Project has absolutely no commitment to stability or usability. If Red Hat wants to try a major update to see what breaks, it can.

The work of the Debian Pure 64 port team is of a very high quality

Debian does have a commitment to stability, and a bona-fide community process. There are other reasons for favouring Debian over Red Hat: apt-get is just better than rpm when it comes to upgrades, and on the creative desktop we’ll be upgrading continuously. The work of the Debian Pure 64 port team is of a very high quality, not to mention that of all the many Debian package maintainers.

I recognise that whatever packages we put into 64 Studio, users will want some of the packages that we haven’t included—so being able to use thousands of binaries straight from the Pure 64 port without modification would be a major advantage. Because we’re sticking very closely to Debian with the 64 Studio design, it’s our intention that users will be able to install any application from Pure 64 simply by enabling an additional apt source. This will include most of the well-known applications with the exception of OpenOffice.org, which just won’t build natively on x86_64 yet.

In fact, 64 Studio is not so much a distribution based on Debian as a Debian remix. 64 Studio maintainer Free Ekanayaka is a Debian Developer, so we hope to contribute our improvements back directly—where they are Debian Free Software Guidelines compliant. However, we do benefit from the flexibility of not being an official part of Debian. For example, the Debian project has decided that they do not want to package binary audio interface firmware, which is required to be loaded by the driver for the interface to work. That’s fair enough, and I understand the reasons for their decision, but it’s a major pain if you own that kind of interface, because it won’t work out of the box.

The alpha releases

There are a number of challenges we still have to face. The first is following the rapid pace of kernel development. We are currently using Linux 2.6.13 with Ingo Molnar’s real-time preemption code and a few other patches. Not so long ago, these patches didn’t build on x86_64 at all, and as far as I know, we are the only native 64-bit distribution using them. The first indications are that this combination works really well for audio with full preemption enabled, the most aggressive setting. For the time being we are using the realtime-lsm framework to give real-time priorities to non-root users, because we know it works. We may switch to rlimits in the future, as this has been merged into the mainline kernel now.

JACK running with realtime priority on a native x86_64 desktop

Another challenge is the issue of support for proprietary formats within free software. At the level of encoding and decoding, we think the best solution we’ve seen is the Fluendo plugin collection for GStreamer, which as far as we can tell meets the requirements of free software licences regarding linking, and also the legal requirements of the patent holders. It’s simply not sustainable to expect users to locate and download libraries of dubious legal status, and install these by themselves. Apart from any ethical problems, it’s impossible to support users properly in that situation. Downloading these libraries is certainly out of the question for any institutional user, such as a college.

It’s almost a mantra that “everyone mixes in ProTools”

At the level of project interchange, for example moving a complex project from Ardour to ProTools, there does seem to be a move among proprietary applications towards support for AAF, the Advanced Authoring Format. Free software must support this kind of high-level project compatibility format, otherwise it doesn’t stand a chance of gaining a significant user base. When I talk to people in the music industry, it’s almost a mantra that “everyone mixes in ProTools”. I’m not aware of any free software audio application that supports ProTools format import or export, but at least with AAF we have the chance of finding a middle way.

64 Studio version 0.3.0 alpha is currently available for download as an .iso image. Changes from stock Debian include X.org instead of XFree86, the custom kernel package, and a base selection of packages including the Gimp, Inkscape, Blender, Ardour, Jamin and Kino. Version 0.4.0 came out at the end of September with more packages and enhancements, and the distribution is seamlessly upgradeable from a 0.3.0 install with apt-get of course. We’d be more than pleased to hear your test reports and suggestions for the distribution—you can help us make free software the creative desktop of choice.