Die Leckerbissen aus der Welt der freien Software sind dieses Mal: Yast-2-Portierung auf Debian, KDE 4 und Qt 4, Bluetooth-Headsets und die Fehlerjagd beim Debian-Projekt. Außerdem: Woher kommen eigentlich die Debian-CDs? Als Nachtisch gibt es Fanta-Schnitten.

Abbildung 1: Das Partitionierungsmodul von Yast 2 teilt Festplatten auf und legt Mountpoints fest. Das Projekt Yast4Debian hat diesen Programmteil bereits erfolgreich portiert.

Als Yast 2 zum letzten Mal Aufsehen erregte, betraf dies seine Lizenz: Kurz nach der Suse-Übernahme stellte Novell das umfassende Konfigurationswerkzeug der Distribution unter die GPL. Die Yast-2-Quellen waren zwar bereits vorher frei zugänglich, die Lizenz schränkte Verwendung und Weiterverbreitung des Programms jedoch ein.

Yast4Debian

Novell hatte diesen Schritt damit begründet, dass man Yast 2 zu einem weitläufigen Standard machen wolle. Deswegen sollten die verschiedenen Distributoren den Quellcode für ihre Produkte entsprechend anpassen und als universelles Werkzeug für die Konfiguration des Systems etablieren. Das erste größere Projekt, das sich dieser Aufgabe annahm, war Debian. Dieser Distribution fehlt bislang ein zentrales Konfigurationsprogramm, das von null an sehr aufwändig zu programmieren gewesen wäre. Das Projekt Yast4Debian portiert derzeit die mit Suse 9.1 ausgelieferte Yast-2-Version; ein Upgrade auf die Suse-9.2-Version steht bevor.

Yast 2 besteht aus der Bibliothek Libyutil, einem Programmkern und diversen Zusatzmodulen. Beim Kern handelt es sich wiederum nur um einen Interpreter für die Yast-2-eigene Programmiersprache YCP, die diverse Elemente der verschiedenen gängigen Skriptingsprachen vereint und zum Erstellen neuer Module dient. Sowohl die Yast-2-Bibliothek als auch der Kern sind in C++ geschrieben und mit den Autotools vorkonfiguriert, sodass sie sich auf jedem Linux-System kompilieren lassen.

Der Hauptaufwand bei der Portierung betrifft also die Module. Unter diese Kategorie fallen auch die Bedienoberflächen, von Suse bereits bekannt sind das Text-Interface Yast-2-Ncurses und das grafische Yast-2-Qt. Beide Module lassen sich ebenfalls problemlos auf anderen Linux-Systemen kompilieren. Die Portierung der restlichen Komponenten erweist sich jedoch als mühselig. Die zahlreichen Module – sogar die einzelnen Yast-2-Icons bilden jeweils ein eigenes – stehen häufig in Abhängigkeiten zueinander, die auf den ersten Blick wenig Sinn ergeben.

Wer beispielsweise das Partitionierungsmodul kompilieren will, braucht zunächst das Modul Autoyast. Dies zieht einen Rattenschwanz weiterer Abhängigkeiten hinter sich her, denn es setzt das X11-Konfigurationsmodul voraus, das wiederum das X11-Maus- und das X11-Keyboard-Konfigurationsmodul verlangt. Außerdem hängt Autoyast vom Yast-Online-Update-Modul und vom Konfigurationsmodul für den Bootloader ab.

Unter der Haube

Noch komplizierter, als Yast 2 mit den Modulen zu kompilieren, ist es, die auf Suse ausgerichtete Infrastruktur an die Zieldistribution anzupassen. Im Falle von Debian betrifft dies beispielsweise das Paketmanagement. Ein Yast-2-Modul kommuniziert mit der RPM-Datenbank, unter Debian kommt aber das Debian-Paketformat zum Einsatz. Andere Module hingegen bedürfen glücklicherweise geringerer Modifikationen, etwa die Benutzerverwaltung. Weil Debian wie Suse und mittlerweile fast alle anderen Distributionen dabei mit »shadow« verschlüsselte Passwörter einsetzt, können die Entwickler das Modul beinahe unverändert übernehmen.

Erste Erfolge kann Yast4Debian schon aufweisen; außer dem Benutzerkonfigurationsmodul funktioniert nunmehr auch der Partitionierer (Abbildung 1) einwandfrei. Doch der bevorstehende Umstieg auf Yast 2 aus der aktuellen Suse-Version bringt viel neue Arbeit mit sich. Wer sich an der Portierung beteiligen möchte, findet auf der Projekt-Homepage [7] eine Anlaufstelle.

Qt 4 und KDE 4

Der KDE-Entwicklungszyklus orientiert sich traditionell an dem der zugrunde liegenden Grafikbibliothek Qt. So entstand kurz nach Veröffentlichung von Qt 4.0 auch ein Entwicklungszweig für KDE 4.0. Darin wollen die Programmierer die Möglichkeiten der neuen Qt-Version in KDE übernehmen und zugleich Designschwächen des aktuellen KDE 3 ausbügeln.

Dass sich beim KDE-Unterbau Qt einiges getan hat, deutete schon die erstaunliche Zeitspanne zwischen den Erscheinungsterminen an: Am 27. Juni kam Version 4.0 der Grafikbibliothek heraus, fast drei Jahre nach dem Vorgänger, der am 21. Oktober 2001 erschien.

Eine bedeutende Qt-Neuerung betrifft nicht den Programmcode, sondern die Lizenz: Bislang konnten Qt-Benutzer nur unter Linux eine freie Lizenz wählen, seit Qt 4 bietet Hersteller Trolltech auch Windows-Entwicklern neben der Commercial License für proprietäre Programme die GPL an. Einige Programmierer planen nun sogar, KDE auf Windows zu portieren – wenn die rechtlichen Hindernisse aus dem Weg sind, bleiben nur die technischen übrig.

Auch für die Endanwender birgt Qt 4 spürbare Vorteile. So funktioniert die Bibliothek nun auf 64-Bit-Architekturen, sogar mit üppigen Performance-Gewinnen. Zahlreiche Funktionen, die nur noch aus Gründen der Rückwärtskompatibilität vorhanden waren, haben die Entwickler von Trolltech entfernt.

Besondere Erwähnung verdient die neue Engine namens Arthur. Sie ermöglicht es Entwicklern, auf bequeme Weise Mal- und Zeichenfunktionen in Qt-Anwendungen einzubauen. Arthur arbeitet merklich schneller als das in Qt 3 verwendete Qpainter und schafft Schnittstellen zu den grafischen Oberflächen aller von Qt unterstützten Betriebssysteme. Damit brauchen sich Programmierer keine Gedanken mehr um die speziellen Eigenschaften einer Oberfläche zu machen. Die neue Font-Engine Scribe räumt außerdem die unter Qt 3 zu beklagenden Schriftprobleme aus.

Damit steht den KDE-Programmierern eine mächtige Grundlage für den Desktop der nächsten Generation zur Verfügung. Für den kürzlich eröffneten KDE-4-Zweig enthält das Wiki [1] des Projekts bereits jetzt eine beachtliche Liste vorgeschlagener Features. Unter anderem planen die Entwickler das Icon-Rendering und die optische Aufbereitung der einzelnen KDE-Teile zu verbessern. Die Bedienung soll KDE 4 unter anderem dadurch vereinfachen, dass es die Qt-internen Zugriffsmethoden für alle Icons und Knöpfe verwendet und somit deren Aussehen vereinheitlicht.

Abbildung 2: KDE 3 verfolgt das klassische Desktopkonzept: Auf dem Hintergrund liegen Icons, unten Menü und Kontrollleiste; die Anwendungsfenster landen darüber im Vordergrund. KDE 4 soll dagegen alle Komponenten miteinander verschmelzen.

Das Projekt Plasma [2] will die Optik von KDE 4 komplett erneuern. Laut Plan integriert es mehrere KDE-Elemente, darunter eine stark überarbeitete Version des Kontrollzentrums, die Kontrollleiste Kicker und KDesktop, das als KDE-Hauptfenster alle anderen KDE-Fenster beherbergt. Fürs Design soll das bislang nur als eigenes Zusatzprogramm erhältliche Superkaramba sorgen, das mit wenig Programmieraufwand fast alle Teile des Desktops verschönert, es gestaltet zum Beispiel die Taskleiste im Mac-OS-X-Stil (Abbildung 3) oder legt aktive Programme auf den Hintergrund.

Abbildung 3: Das als Zusatzprogramm für KDE 3 verfügbare Superkaramba verziert fast alle Ansichten des KDE-Desktops. Mit dem Plasma-Projekt soll es unter KDE 4 für ansprechendes Design sorgen.

Als Resultat ihrer Mühe schwebt den Entwicklern ein modernes und “völlig neues Konzept des Desktops” vor. Eine eigene KDE-3-Kompatibilitätsbibliothek wird dafür sorgen, dass die Brücken zwischen KDE 4 und dem Vorgänger nicht ganz abgebrochen werden.

Ein Datum für die Fertigstellung nennen die KDE-Programmierer jedoch noch nicht. Fakt ist aber, dass nicht nur die freien KDE-Entwickler selbst ein hohes Interesse an einer erfolgreichen Entwicklung haben: Qt-Hersteller Trolltech stellte vor einigen Wochen den KDE-Programmierer Aaron Seigo fest ein, damit er seine gesamte Aufmerksamkeit KDE widmet. Für Trolltech ist die bekannteste Qt-Applikation offenbar ein Prestigeobjekt ersten Ranges.

Bluetooth-Headsets unter Linux

Bluetooth-Headsets sind praktisch: Im Auto ersetzen die meist relativ günstigen Kopfhörer mit eingebautem Mikrofon die teureren handyspezifischen Freisprechanlagen. Auch sonst arbeiten sie mit allen Bluetooth-Geräten mit passenden Audioprofilen zusammen. Mit Hilfe eines zusätzlichen Kernelmoduls sorgt das Alsa-Soundsystem dafür, dass sich zumindest einige Bluetooth-Headsets auch am heimischen Linux-Rechner als Kopfhörer eignen. Auf den Einzug in den offiziellen Alsa-Entwicklungszweig wartet das Alsa-Bluetooth-Projekt allerdings noch. Das Kernelmodul »snd-bt-sco« gibt es aber bereits auf der Homepage [3], zusätzlich den Quelltext und eine Installationsanleitung.

Über das A2DP-Protokoll (Advanced Audio Distribution Profile) unterstützt die Bluetooth-Erweiterung für Alsa auch Stereo-Sound. Es beschränkt sich jedoch in der Praxis bislang auf den Empfang; das Senden schlägt fehl, weil die Hardware aktueller Headsets mit dieser Funktion nicht umgehen kann. Doch neue Bluetooth-Geräte, die auch den Stereo-Empfang beherrschen, sind bereits in Planung, der »snd-bt-sco«-Treiber stellt die nötige Funktionalität schon bereit.

Bug-Squashing-Party

Nach der Veröffentlichung von Debian Sarge setzt im Entwicklungszweig des Projekts eine rege Betriebsamkeit ein. Beispielsweise stellen die Entwickler die Distribution auf die GCC-Version 4.0 um; die Migration führt allerdings noch zu zahlreichen Fehlern, die Zahl der Release-kritischen Bugreports schoss auf fast 600 hoch. Vor der Aufgabe, diese nun auszubügeln, stehen die Debian-Entwickler jetzt.

Um die Arbeit voranzutreiben, hat Frank Lichtenheld Anfang August eine Bug-Squashing-Party initiiert. Bei derartigen Veranstaltungen treffen sich Entwickler in einem IRC-Kanal, um in den von ihnen selbst, aber auch in von anderen betreuten Debian-Paketen koordiniert auf Fehlersuche zu gehen. Dazu lockern die Administratoren die Regeln für den Paket-Upload, sodass alle Beteiligten ihre Patches direkt hochladen. Das Ergebnis der gemeinsamen Jagd nach Bugs Anfang August waren 32 behobene Release-kritische Fehler sowie eine Menge vom »unstable«- in den »testing«-Zweig übertragene Pakete.

Gegen Ende der Sarge-Entwicklung hatten Bug-Squashing-Partys beinahe im Wochenrhythmus stattgefunden und halfen der neuen Version schließlich entscheidend weiter, bis sie endlich den veröffentlichungsfähigen Status erreichte – die gemeinsam unternommene Fehlersuche trug also schon in der Vergangenheit sichtbare Früchte.

Die Zukunft des Debian-CD-Tools

Die Debian-Softwaresammlung ist mit Sarge auf etwa 15500 Pakete angewachsen. Wer für die Installation keinen schnellen Internetanschluss hat, braucht die Software auf DVDs oder CDs, das gesamte Repertoire beansprucht eine Dual-Layer-DVD oder 14 CD-ROMs. Mit Netzanschluss genügt die etwa 180 MByte große Netzinstallations-CD, um den Rechner aufzusetzen und den Rest danach herunterzuladen. Damit sie diese Aufgabe erfüllt, muss sie alle wichtigen Pakete enthalten. Darüber hinaus dürfen keine Abhängigkeiten auf Pakete anderer Datenträger verweisen.

Das Debian-CD-Tool [4] kümmert sich um diese Voraussetzungen. Es bereitet allerdings in zweierlei Hinsicht Sorgen: Der Quelltext des Programms ist kaum mehr verständlich, weil ihn verschiedene Entwickler über Jahre hinweg nach und nach an die jeweils neuen Voraussetzungen von Debian angepasst haben. Wer mit den CD-Tools sein eigenes Set für spezielle Bedingungen anfertigen möchte, muss sich zunächst mühsam in den Code einlesen, um das Programm zu verstehen.

Das soll sich aber bald ändern: Auf der Debian-Entwicklerkonferenz Debconf in Helsinki haben sich Programmierer um Steve McIntyre zusammengesetzt und neue Mittel und Wege diskutiert, um das Tool einfacher zu gestalten. Im Vordergrund steht die Restrukturierung des Quelltextes, zugleich wollen sie auch die automatische Prüfung von Abhängigkeiten erneuern und verbessern. Etliche weitere Ziele hat McIntyre auf der Debian-Devel-Announce-Mailingliste beschrieben [5].

Ein gibt aber ein noch größeres Problem für das CD-Tool: Um festzustellen, welche Pakete auf welchem Teil des 14-teiligen CD-Sets landen, verwendet es die Ergebnisse des Popularity Contest. Das ist eine Art Hitliste der Debian-Pakete. Wenn Debian-Benutzer »popularity-contest« einrichten, schickt es wöchentlich eine Liste der auf ihrem System installierten Pakete an den Popularity-Contest-Server. Aus den resultierenden Statistiken ergibt sich die Reihenfolge der Pakete auf den Datenträgern.

Doch immer weniger Benutzer senden ihre Paketlisten ein, sodass die Daten an Zuverlässigkeit verlieren. Petter Reinholdtsen warnte auf der Debian-Devel-Mailingliste [6] davor, dass es schon in absehbarer Zukunft keine verwertbaren Paketlisten mehr geben werde. Ohne diese Daten wäre aber das Debian-CD-Tool wertlos.

Fanta-Schnitten mit Pfirsichschmand

Zutaten: vier Eier, 250g Zucker, ein Päckchen Vanillezucker, 125ml Speiseöl, 150ml Fanta, 250g Weizenmehl, drei gestrichene Teelöffel Backpulver. Für den Belag: zwei Dosen Pfirsiche (halbe Früchte), 600ml Sahne, drei Päckchen Sahnesteif, fünf Päckchen Vanillezucker, 500g Schmand, Zimtzucker.

Zubereitung: Eier, Zucker und Vanillezucker mit dem Rührstab auf höchster Stufe schaumig schlagen. Öl und Fanta unterrühren, Mehl und Backpulver sieben und vermischen. Danach portionsweise auf mittlerer Stufe des Rührstabs unter die Mischung rühren. Den Teig schließlich auf ein gefettetes Backblech geben. Den Backofen bei Ober- und Unterhitze auf 180°C oder bei Heißluft auf 160°C vorheizen, danach den Teig 25 Minuten backen.

Für den Belag zunächst die Pfirsiche in einem Sieb abtropfen lassen und dann in Stücke schneiden. Anschließend die Sahne mit Sahnesteif und drei Päckchen Vanillezucker steif schlagen. Den Schmand mit dem restlichen Vanillezucker unterrühren. Die Pfirsichstücke unter den Schmand heben, die Sahne danach ebenfalls locker unterheben.

Die Masse auf dem gebackenen Teig gleichmäßig verteilen und das Ganze kühl stellen. Schließlich mit Zimtzucker bestreuen.

Am Ende der obligatorische Aufruf: Wer ein gutes Programm kennt, schätzt oder vielleicht entwickelt und es in der Projekteküche vorgestellt sehen möchte, schreibe eine E-Mail an [8]. (csc)