|
|
|
|
|
|
Aktueller Überblick über freie Software und ihre MacherProjektekücheMartin Loschwitz |
|
Um Linux auch auf Desktops dauerhaft konkurrenzfähig zu machen, bedarf es nicht nur großer Events wie des Linuxtags in Karlsruhe, sondern auch kleiner, aber durchaus wichtiger Veranstaltungen der Linux-Usergroups in den Städten. Anfang Oktober lockte ein Informationswochenende der Linux-Usergroup Mönchengladbach mehr als 60 Leute an, die sich über diverse Aspekte in Verbindung mit dem freien Betriebssystem informieren wollten.
Das zeigt vor allem, dass Linux bei Privatanwendern auf reges Interesse stößt. Aber auch, dass es viele Fragen und Unklarheiten gibt. Deshalb hier ein Aufruf an alle Linux-Usergroups, nicht nur den persönlichen Zwecken zu dienen, sondern Linux allen Interessierten ganz praktisch näher zu bringen.
Wer heute auf einen Desktop-Rechner mit Linux stößt, sieht als grafische Oberfläche meist KDE oder Gnome werkeln. Ersteres verwenden inzwischen viele Distributionen als Standard, es bietet Anfängern einen leichten Einstieg und lockt anspruchsvolle Benutzer mit zahlreichen Features und Anwendungen. Einige finden den schier unendlichen Umfang von KDE aber überdimensioniert und die Oberfläche zu langsam. Zwar läuft sie auch auf älterer Hardware, aber es gibt spürbar schnellere Alternativen für langsame Rechner.
Eine von ihnen heißt XFce (siehe Abbildung 1). Die Desktopumgebung trat anfangs als einfacher, aber freier Klon des kommerziellen CDE (Common Desktop Environment) an. Dieses Image konnte XFce bis zur Version 4.0 nicht ablegen, heute jedoch zeigt es sich mit seinem GTK-2-Design in schickerem Gewand. Seit Version 4.0 erscheint XFce nicht mehr als ein großes Programm, sondern unterteilt in viele einzelne Stückchen, die der Anwender erst bei Bedarf installiert. Bald kamen neue Programme hinzu: ein passabler Dateimanager, eine Taskleiste und obendrein erhielt XFce auch noch ein eigenes System für die Konfiguration.
Version 4.2 steht nun als neue Major Release vor der Tür. Die verbesserte Unterstützung für Xinerama, den Multi-Monitor-Modus von XFree86, ragt dabei heraus: XFce 4.2 nutzt alle Funktionen, die Xinerama bietet. Zudem unterstützt es jetzt den so genannten Kiosk-Modus. Damit eignet sich die Desktopumgebung hervorragend für Systeme mit häufig wechselnden Benutzern, die die Einstellungen nicht verändern dürfen.
Die Taskleiste XFce4-Panel, die auch unter Benutzern anderer Oberflächen inzwischen viele Freunde hat, lässt sich nun in ihren Maßen anpassen - vorher nahm sie zwangsweise die gesamte Breite des Desktops ein. XFwm4, der Window Manager von XFce 4, unterstützt nunmehr die Standards der Free Desktop Group[4], obendrein gibt es neue Themes und Icons.
Für Menüs lassen sich künftig über PNG-Bilder Farbabstufungen bestimmen, sodass Menüschatten möglich werden. Auch das Konfigurationssystem MCS-Manager erfuhr einige Verbesserungen: So stellt man nun beispielsweise die Kantenglättung von Schriften direkt damit ein.
Eine der größten Veränderungen ist das Programm XFce4-Session: Damit hat XFce jetzt einen eigenen Session-Manager. XFce4-Session ist kompatibel zu KDE und Gnome und unterstützt ebenfalls Xinerama. Wer das Aussehen von XFce4-Session nicht mag, verschönert es mit Hilfe von Themes selbst.
Zahlreiche kleinere Verbesserungen finden sich bei XFdesktop, dem Desktop-Manager. Den Dateimanager XFfm erweiterten die Entwickler um einen Editor für Icon-Themes, das Panel namens XFce4-Panel passt seine Icons mit vereinfachter Konfiguration denen der gesamtem Umgebung an und der Printer-Dialog unterstützt nun sowohl Cups als auch BSD-LPR. Dabei verwendet er die Listen der Drucksysteme, um neue Geräte automatisch hinzuzufügen.
Wer Rechner mit nicht ganz aktueller Hardware trotzdem mit einer grafischen Oberfläche verwenden möchte, sollte einen Blick auf die neue Version dieser KDE-Alternative werfen.
Es gibt viele Gründe, einen Teil des Systems vom Rest abzutrennen. Eins haben sie gemeinsam: Der abgetrennte Bereich soll seinen Benutzern keinen Zugriff auf das Hauptsystem ermöglichen und selbständig laufen. Wenn jemand im abgetrennten Teil einbricht, bleibt das Hauptsystem verschont; potenziell unsichere Serverdienste lassen sich hier auslagern. Nach einem Einbruch ist der entsprechende Abschnitt leicht zu entfernen und neu aufzusetzen.
Chroot ist die älteste und einfachste Technik. In einem Verzeichnis bildet der Administrator ein Linux-System nach, das alle nötigen Dateien enthält. Chroot täuscht allen in diesem Verzeichnisbaum gestarteten Programmen vor, das oberste Verzeichnis darin sei das Wurzelverzeichnis des Systems und die Prozesse könnten ausschließlich auf Dateien in diesem Umfeld zugreifen.
Doch Chroot hat auch Nachteile. So teilen sich die Programme der Chroot-Umgebung alle Ressourcen des Computers mit dem Hauptsystem. Spielt hier ein Programm verrückt, zwingt das den kompletten Rechner in die Knie. Zudem kann ein geschickter Angreifer aus dem Chroot ausbrechen und ins Hauptsystem vordringen.
VMware bietet schon seit Jahren eine Lösung, die einen kompletten PC emuliert. Der VMware-Server ermöglicht es sogar, auf ein und derselben Hardware mehrere Umgebungen mit verschiedenen Systemen getrennt voneinander zu betreiben. Der Quellcode ist, wie bei kommerziellen Produkten üblich, leider nicht einsehbar; der Preis treibt zudem manchem Admin Tränen in die Augen.
Als freie Software gibt es VServer, siehe[1]<@> und <@90 IZ>[2]. Wie bei Chroot legt man hier in einem eigenen Verzeichnis ein vollständiges Linux-System an. VServer besteht aus zwei Teilen: Einem Kernelpatch sowie den VServer-Utils, die den Userland-Part der Arbeit übernehmen. Jeder VServer lässt sich separat starten und bekommt sogar einen eigenen Init-Prozess und kann somit Serverdienste mit eigenen IP-Adressen starten. Zusammen mit den VServer-Utils lässt sich ein VServer mit allen seinen Prozessen umstandslos wieder beenden. In neuen Versionen beschränkt VServer zudem bei Bedarf die Ressourcen, die ein einzelner Server verwenden darf. Die virtuellen Server verwenden aber wie bei Chroot den Kernel des Host-Systems.
Einen anderen Ansatz verfolgt User Mode Linux[3], bei dem ebenfalls ein System im System startet. Allerdings lädt UML einen eigenen Kernel ins Userland des Host-Betriebssystems. Im Gegensatz zu VServer verwendet UML ein eigenes Dateisystem, das sich als Image-Datei selbst anlegen oder von der UML-Homepage kopieren lässt. Auch hier gehört ein Kernelpatch zur Grundausstattung, ohne das die Suite nicht funktioniert. Einige Distributionen, zum Beispiel Suse, haben es jedoch bereits in ihre Standardkernel integriert.
UML kann sehr genau steuern, welche Hardware das Gastsystem benutzen darf. Denn im Gegensatz zu VServer emuliert UML sogar Hardware, die es im Hauptsystem nicht gibt. Leider funktioniert nicht jede Distribution ohne Probleme in eine UML-Umgebung, VServer läuft dagegen überall, wo bereits ein Host-Linux seinen Dienst tut.
Xen [4] greift noch tiefer in den Kernel ein: Es bootet keinen gewöhnlichen Linux-Kernel, sondern ein spezielles Xen-Image. Es versieht jedes System auf dem Computer, also das Host-System sowie alle virtuellen Clients, mit Nummern und steuert sie als einzelne logische Einheiten, so genannte Virtual Domains. Als Besonderheit bietet Xen, dass es bei den Gast-Domains keinen vollständigen Computer nachbildet, sondern einen idealisierten PC. Die virtuellen Domains laden einen für Xen optimierten Kernel. Er enthält nur die für den Betrieb notwendigen Treiber. Die Ausgabe von »dmesg« nach dem Booten veranschaulicht dies: Sie bringt es auf nur 50 Zeilen. Trotzdem verhält sich jede virtuelle Domain wie ein vollwertiger Computer. E
Die vorgestellten Projekte lassen hoffen, dass sie eines Tages sogar VMware im professionellen Umfeld ersetzen könnten. Für ein virtuelles System auf dem eigenen Rechner reicht als erste Wahl oft schon Chroot; die Einrichtung von UML, VServer oder Xen dauert zumindest beim ersten Mal wesentlich länger.
Gentoo Linux sieht seine Existenzberechtigung vor allem in seinem Package-Build-System namens EBuild. Es übersetzt ähnlich wie das Port-System der BSD-Systeme Anwendungen schnell und unkompliziert und optimiert sie für den verwendeten Rechner.
Ob diese Optimierung tatsächlich große Tempogewinne erzielt, sei dahingestellt. Fakt ist derweil, dass jeder, der ein umfangreiches Projekt wie KDE vollständig manuell bauen möchte, in einem Schlamassel steckt. KDE besteht aus vielen einzelnen Modulen, die teilweise wieder voneinander abhängen und sich folglich nur in der richtigen Reihenfolge kompilieren lassen.
Wer das per Aufruf der einzelnen Configure-Skripte über die Bühne bringen will, hat einen großen Packen Arbeit vor sich. Zudem steht mit jeder neuen Version von KDE dieselbe Prozedur erneut ins Haus. Es bedarf deshalb einer generellen Lösung: QBuildkde[6] (Abbildung 2) vereinfacht Anwendern die Installation von KDE aus den Quellen. Es bietet ein Frontend für das CVS-Verzeichnis von KDE, erweitert um die Funktion, nach dem CVS-Checkout einen Build-Vorgang anzustoßen.
Die Oberfläche ist einfach und intuitiv gestaltet. Nach dem ersten Start öffnet sich zunächst der Konfigurationsdialog, der die nötigsten Einstellungen erledigt; die Standardwerte stimmen im Normalfall. Das Hauptfenster zeigt dann eine Liste der verschiedenen CVS-Module, mit denen das Tool funktioniert. Dazu gehören zum Beispiel der KDE-QT-Zweig QT-Copy, aber auch KDE-Basispakete. Um ein Modul zu übersetzen, setzt der Anwender in der Modulliste lediglich ein Häkchen vor den Namen des Moduls und drückt den Startknopf.
Der rechte Teil des Fensters führt dann Protokoll über den Ablauf. Seit Version 6.1 gibt es sogar ein Interface für eine Client-Server-Kommunikation. Das ermöglicht es, QBuildkde auf einem Rechner laufen zu lassen und aus der Ferne per Telnet zu kontrollieren. QBuildkde ist übrigens nicht das einzige Programm mit dem Ziel, Anwendern das Kompilieren von KDE zu erleichtern. Konstruct[7] beispielsweise hat sich dasselbe zur Aufgabe gemacht.
Viele Male hat die Projekteküche bereits über den Fortschritt von Debian GNU/Linux Sarge berichtet. Dass eine neue Release der bekannten Distribution mit jedem Tag mehr drängt, leuchtet angesichts des Alters der letzten stabilen, kaum noch als aktuell zu bezeichnenden Release ein. Debian Woody hat bereits über zwei Jahre auf dem Buckel. Die neue Ausgabe war für Mitte September schon angekündigt. Daraus wurde nichts und wer jetzt nach dem Release-Datum für Sarge fragt, erhält wieder die Antwort: Es wird veröffentlicht, wenn es fertig ist. Zeit genug also um auszuloten, wo momentan noch die größten Baustellen sind.
Da wäre zunächst das größte Projekt, das Sarge mit sich bringt: der neue Debian-Installer, der die veralteten Boot-Floppies vergessen machen soll. Offenbar schreitet die Arbeit nicht so schnell voran, wie Release Assistant Steve Langasek noch im August hoffte. Noch immer liegt keine offizielle erste Version des Installers vor, die Pre- und RC-Versionen lassen sich aber bereits zur Installation verwenden.
Es erscheinen jedoch weiterhin neue Ausgaben, die immer noch zusätzliche Funktionen implementieren. Die erste Vorabversion des Release Candidate 2 enthält beispielsweise erstmals die Möglichkeit, NTFS-Dateisysteme während der Installation zu vergrößern und zu verkleinern. Außerdem hat sich die Unterstützung für LVM (Logical Volume Manager) verbessert, sodass es nun auch möglich ist, den Debian-Installer für das Booten von einer LVM-Einheit zu konfigurieren.
Weitere Veränderungen im Großen und Kleinen sollen das Projekt stabiler machen. Der Hauptverantwortliche des neuen Installers, Joey Hess, äußerte sich in den letzten Wochen verhalten optimistisch. Demnach befindet sich der Installer sicher, aber sehr langsam auf dem Weg zur stabilen Release.
Auch im Debian-Release-Team gab es eine Neuerung: Es hat Andreas Barth als neues Mitglied aufgenommen, er arbeitet nun zusammen mit Colin Watson und Steve Langasek. Im Hauptteil der Distribution gibt es derweil wenig neues zu melden. Die Base- und Standard-Teile sind mittlerweile eingefroren, doch wann der Rest der Distribution in diesen Zustand übergeht, bleibt unklar. Bevor ein Paket für einige Zeit eingefroren war und nur noch kritische Fehler ausgebessert wurden, veröffentlicht Debian es nicht. Die Liste der als kritisch eingestuften Fehler schrumpfte in letzter Zeit immerhin kontinuierlich, dieser Trend weckt Hoffnungen auf eine baldige Veröffentlichung von Sarge.
Steve Langasek geht zurzeit von einem ganz anderen Faktor als Grund für die Verzögerung aus: Bei Debian werden alle Pakete, die ins Archiv gelangen, für eine Architektur manuell gebaut und erst dann von den so genannten Buildds oder Autobuildern übernommen. Sie kompilieren das Paket für je eine bestimmte Architektur automatisch, ohne dass der Paket-Maintainer eingreifen muss. Er versieht am Ende lediglich die aus dem Build hervorgegangenen Pakete mit einer GPG-Signatur für das Archivsystem.
Für den Unstable-Teil arbeitet dieses System meist problemlos, anders sieht es bei Testing aus. Hier fehlt es momentan an Autobuildern, die Sicherheits-Updates für Sarge bauen könnten. Für ein solches Update müssten im jetzigen Zustand die Mitglieder des Security-Teams betroffene Pakete auf jeder einzelnen Architektur händisch bauen. Das ist besonders bei großen Exemplaren äußerst mühsam und dauerhaft nicht realisierbar. Solange eine Lösung für diesen Missstand nicht einmal in Sichtweite liegt, wird es laut Steve Langasek keinen spürbaren Fortschritt bei der Release geben. Man könne den Anwendern wegen der mangelnden Sicherheitsunterstützung nicht empfehlen, Sarge auf dem eigenen System zu verwenden.
Die Spielverderber bei Sarge scheinen also ausgemacht. Sobald der Security-Support für Sarge funktioniert, will Steve Langasek durchstarten und die neue Debian-Release so schnell wie möglich auf den Weg bringen. Die Benutzer können derzeit am besten bei der Arbeit helfen, indem sie den Debian-Installer gründlich testen und ihre Erfahrungen mit den Entwicklern teilen. Wann Sarge wirklich veröffentlicht wird, bleibt unklar - obwohl schon jetzt diverse Anbieter Sarge-CDs verkaufen.
Zutaten: zwei Eier, 250 g Butter, 250 g Zucker, 250 g Mehl, ein Teelöffel Backpulver, ein Päckchen Vanillezucker, eine Prise Salz, zirka ein Kilo Boskop-Äpfel, ein bis anderthalb Päckchen blättrige Mandeln, ein Päckchen gemahlene Mandeln, Zimt.
Zunächst Eier, Butter, Zucker, Backpulver, Vanillezucker und Salz zusammen zu einem Rührteig verrühren. Dazu alle Zutaten in eine Schüssel geben und untermischen.
Danach die Boskop-Äpfel schälen und in Spalten schneiden. Dann Zimt und Zucker untereinander mischen, die geschnittenen Apfelspalten in dieser Mischung wenden.
Eine Backform mit Butter ausstreichen und mit Paniermehl bestreuen, in diese Form den Teig geben und anschließend mit den gemahlenen Mandeln bestreuen. Die Apfelspalten auf dem Teig verteilen, dann die blättrigen Mandeln auf den Äpfeln verteilen. Schließlich etwas Butter zerlassen, zu der Butter Zucker geben und diese Mischung über dem Teig verteilen.
Die Form sollte in einen vorgeheizten Backofen bei 180¡C für zirka 60 Minuten gegeben werden. Zum Verfeinern beim Servieren Schlagsahne reichen.
Für alle, die sich vom Kampf mit den Apfelhälften schon wieder erholt haben, kommt noch der obligatorische Hinweis: Wer ein Tool schätzt oder entwickelt hat und es an dieser Stelle gerne vorgestellt sehen möchte, der sende eine entsprechende E-Mail an[8]. (csc)
| Infos |
|
[1] Linux-VServer-Projekt: [http://www.linux-vserver.org] [2] Kurt Huwig, "Teile und herrsche - VServer": Linux-Magazin 01/03, S.54 [3] User-Mode-Linux-Seite: [http://user-mode-linux.sourceforge.net] [4] Xen, ein PC-Emulator: [http://xen.sourceforge.net] [5] Freedesktop.org-Projekt: [http://www.freedesktop.org] [6] QBuildkde-Website: [http://www.sf.net/projects/qbuildkde/] [7] Konstruct-Website: [http://developer.kde.org/build/konstruct/] [8] Hinweise und Vorschläge: [projektekueche@linux-magazin.de] |