Tag: ArchLinux

Posted on

Ein Debianbenutzer zu Besuch bei Arch Linux

Auch wenn ich mich in Sachen Arch Linux oft wiederhole. Beißt euch durch die Installation durch, bleibt dran und gebt nicht auf - ganbatte kudasai!. Sie ist wirklich gut im englischen oder deutschen Arch Linux Wiki erklärt. Nachdem man diese vermeintliche Hürde nämlich genommen hat, stellt man plötzlich fest, dass man für den Rest der Lebenszeit seines Computers nicht mehr daran denken muss. Genauso wie bei Debian Unstable oder Testing ist Arch eine fortlaufend aktualisierte Distribution, weswegen der Teil mit der Installation wirklich nur einen Bruchteil der Zeit am Rechner ausmacht. Wie versprochen ist hier ein erster Eindruck, was mir bei regelmäßiger Benutzung von Arch auf dem Inspiron 4000 aufgefallen ist.

Das Netzwerk

Nachdem man den Installationsschritten gefolgt ist, muss man sich als Neuankömmling erst einmal ein paar Problemen stellen. Eine Interfaces Datei für Arch Linux gibt es nicht. Ist die nicht sogar bei Debian schon "deprecated"? Am leichtesten geht es, wenn man direkt in der /etc/rc.conf eine einzelne Netzwerkschnittstelle einrichten möchte. Für statische oder dynamische IP-Adressen-Konfiguration ist hier der richtige Ort.
Wenn es komplizierter werden soll aufgrund mehrerer Netzwerkkarten, sollte man sich netcfg anschauen. Ein Verhalten, das erst einmal gewöhnungsbedürftig ist falls man Befehle wie ifconfig, ifup und ifdown sofort nach einer Minimalinstallation von Debian gewohnt ist. Für einen Laptop gefällt mir außerdem noch Wicd, mit dem sich übersichtlich drahtlose Netzwerke einrichten lassen.

Aptitude und Pacman

Arch Linux ist kaputt, denn es hat kein Apt. Wahre Worte. 😛 Pacman ist zwar nicht Apt, erfüllt aber ähnliche Aufgaben, die man auch von Apt gewohnt ist. Die wichtigsten Befehle für den Anfang sind:

  • pacman -Syu : Das komplette System auf den neuesten Stand bringen
  • pacman -S "Paketname": Ein Paket installieren
  • pacman -Ss "Suchbegriff" : Nach einem Begriff/Paket suchen
  • pacman -Sc : Den Paketcache leeren
  • pacman -Rs "Paketname" : Ein Paket und dessen Abhängigkeiten entfernen, sofern sie nicht von anderen Paketen gebraucht werden

Man vermisst zwar ein wenig Aptitudes exzellente Suchfähigkeiten, bisher konnte ich mein Arch trotzdem immer nach meinem Geschmack einrichten.

Kleine Unterschiede

Arch Linux bezeichnet sich selbst als eine Keep-it-simple-Distribution. Das geht soweit, dass das Patchen von Dateien bis auf ein absolut notwendiges Minimum reduziert wird. In der Regel werden neue Feature und Sicherheitsaktualisierungen durch den jeweiligen Upstream-Autor erstellt und dann umgehend als Arch-Linux-Paket bereitgestellt. Das kann aber auch dazu führen, dass einige Fähigkeiten, die man aus Debian kennt, plötzlich nicht mehr funktionieren.
Am Beispiel scrot, dem Screenshot Programm, wird das ziemlich deutlich. In der Arch Version gibt es den Patch zum gezielten Aufnehmen eines Fensters, in der offiziellen Version leider nicht. (-u) Dafür wird eine inoffizielle Version in AUR bereitgestellt. Wie gut sie wirklich ist, lässt sich nur durch Ausprobieren feststellen. Im Moment hat sie nur zwei Bewertungspunkte.

Pakete aus AUR - der leichte Weg

Am Anfang genügt es vollkommen nur die offiziell verfügbaren Pakete und den offiziellen Paketmanager Pacman zu benutzen. Es stehen dann zwar nicht die gleiche Anzahl an Paketen wie bei Debian zur Verfügung, man kann aber durch geschicktes Substituieren das Problem meistens umgehen. In den letzten beiden Posts zu Arch Linux auf dem Inspiron 4000 habe ich die manuelle Methode mit makepkg -s vorgestellt, bei der man das PKGBUILD manuell herunterladen und ggf. Abhängigkeiten ebenfalls manuell bauen muss.
Wenn man sich erst einmal an dieses "Do-it-yourself"-Konzept gewöhnt hat, macht das Bauen von Paketen bei Arch Linux sogar richtig Spaß. Für den regelmäßigen Baumeister empfiehlt sich aber einer der sogenannten AUR-Helfer. Insbesondere yaourt scheint populär zu sein. Im Grunde genommen ist yaourt ein Wrapper für Pacman, der die gleichen Befehle unterstützt, gleichzeitig aber die Möglichkeit bietet direkt im Arch User Repository nach Software zu suchen und diese wie mit Pacman gewohnt zu installieren. Momentan benutze ich yaourt ausschließlich nur für das Installieren von AUR-Paketen, was eine große Zeitersparnis ist.

Zum Schluss

Ja, Arch Linux ist anders als Debian. Wenn man sich aber an die Unterschiede gewöhnt hat, macht es viel Spaß. Software zu verwalten ist einfach und unkompliziert. Pacman ist weniger mächtig als Apt, ist dabei aber auch fühlbar schneller auf älteren Rechnern. Ein Bonus ist sicherlich auch, dass man in Sachen Desktopumgebung nicht umdenken muss. Meine alten Openbox-Einstellungen konnte ich problemlos übernehmen.

Posted on

Textverarbeitung, Tabellenkalkulation und Präsentation auf der Konsole

Ich habe keine Probleme damit zuzugeben, dass ich mittlerweile eine große Anzahl von Konsolenanwendungen regelmäßig benutze und ich sie nicht nur als letztes Mittel für Jahrzehnte alte Laptops, sondern auch für eine leichtbedienbare und effiziente Alternative für moderne Computer halte.
Es gibt aber auch Bereiche, in denen der Einsatz von Programmen für die Konsole unbefriedigend ist oder wo ich gespaltener Meinung bin. Ich käme nicht auf die Idee Bild- und Videobearbeitung ausschließlich auf der Konsole durchzuführen, obwohl natürlich das massenhafte Zurechtschneiden und Konvertieren von Bildern mit den geeigneten Programmen und seiner Lieblingsshell hervorragend funktioniert.
Auch 3D-Spiele sind nichts, wofür ich zwingend nach einer Konsolenalternative suchen müsste. Und dann wären da noch die sogenannten Büroarbeiten - Textverarbeitung, Tabellenkalkulation und die viel geliebten Präsentationen.

Textverarbeitung

Bei der Textverarbeitung sehe ich die geringsten Probleme. Tatsache ist, dass zu viele Texte "zu früh" oder gar unnötig mit Bürosoftware formatiert werden. In vielen Fällen würde es eine gut strukturierte Textdatei auch tun, die mit Hilfe von Editoren wie Vim oder Emacs verfasst wird. Außerdem spricht oft nichts dagegen Texte solange wie möglich in der Rohfassung zu belassen bis sie im letzten Schritt in ein ansprechendes Format gesetzt werden können. Für private Korrespondenz benutze ich deshalb nach wie vor entweder LibreOffice oder AbiWord und ansonsten einen schlichten Editor.

Tabellenkalkulation

Tabellenkalkulation wird immer dann praktisch, wenn man eine Teilnehmer- oder Getränkeliste erstellen will oder seine Finanzen planvoll ordnen möchte. Doch selten kommt es in privaten Haushalten vor, dass man zehntausende Zeilen Daten auswerten und zahllose Makros für Datenimport und -export verfassen muss. Mal abgesehen davon, dass ich Tabellenkalkulation im Allgemeinen nicht für die interessanteste Aufgabe halte, sehe ich abseits von automatisierten Prozessen kaum eine Notwendigkeit für eine Konsolenapplikation.
Das soll aber nicht heißen, dass es hier keine Alternativen geben würde. Als Lektüre empfehle ich K.Mandlas Tutorial "How to use teapot like a pro" und "Howto: Use Oleo like..like...like..". Ich gebe zu, dass ich nach dem Lesen des Tutorials zu Teapot der Vorstellung einer Tabellenkalkulation für die Konsole positiver gegenüberstehe und mir nun nicht nur mehr vorstellen kann damit einmal zu arbeiten.
Meine ersten Schritte mit Teapot habe ich dazu genutzt, den Wert der Laptops im zuletzt vorgestellten Post als Beispiel zu visualisieren, wozu ich den Preis für einen Neukauf und den für die gebrauchten Laptops gegenübergestellt habe. Ich weiß nicht gerade eine Herkulesaufgabe, für die es auch etwas Kopfrechnen getan hätte. In Teapot lassen sich aber auch beliebige Formeln eingeben, die sich mit den entsprechenden Funktionen natürlich auch in mehrere Zellen kopieren lassen und deren Werte automatisch bei einer Änderung in einer anderen Zelle angepasst werden.

Leider findet sich zur Zeit kein Paket in Debian, weshalb ich kurzerhand Teapot mit meiner Archlinux-Installation auf dem Inspiron 4000 ausprobiert habe. Das entsprechende PKGBUILD lässt sich wie in diesem Beitrag schon vorgestellt in AUR finden und mit makepkg -s schnell selbst bauen. Man sollte nur sicherstellen, dass make installiert ist.
Teapot besitzt viele grundlegende Funktionen, die man von jeder Tabellenkalkulation her kennt, einen vollwertigen Ersatz für LibreOffice Calc oder Gnumeric sollte man aber nicht erwarten.

Präsentation

Ok, hier muss ich passen. Präsentationen sind genauso etwas wie Schlipse, von denen ich hoffe, dass in Zukunft die Welt davon nur noch in Geschichtsbüchern lesen und sich darüber köstlich amüsieren wird. Ich habe schon eine Menge Präsentationen erstellt, aber noch nie eine rein für private Zwecke. Auch wenn ihr nun vielleicht schmunzelt, das soll nicht heißen, dass es keine Alternativen für die Konsole gäbe. Erwähnt seien hier die Programme Beamer, tpp und xsw. Ich habe davon noch keines ausprobiert, obwohl die reine Vorstellung auf den entsprechenden Webseiten vielversprechend aussieht.
In Zukunft soll das heißen: Selbst wenn ich in Sachen Konsolenapplikationen auch einmal skeptisch sein sollte. In der Regel hat mich vermutlich vor Jahren schon irgendjemand eines besseren belehrt. 🙂

Posted on

Wenn Zwei zusammenkommen: Arch Linux und Debian

Eine Entscheidung zu treffen war. Tue ich es oder tue ich es nicht? Sollte ich den Inspiron 4000 verschrotten oder Arch Linux parallel zu Debian Sid installieren? Ok, es gab schon dramatischere Situationen, aber bevor ich Arch Linux installiere....Spaß, Spaß.
Der Dell-Laptop ist mittlerweile zehn Jahre in Gebrauch, dreieinhalb davon hat er bei mir verbracht und er hat sich gut gehalten. Nun ja zumindest bis vor kurzem. Nach dem Scharnierbruch ist er nicht mehr der Mobilste. Wäre ich ein geschickter Handwerker, dann würde die Sache schon längst repariert sein und ich käme nicht auf die Idee mich erneut an einem Multi-Boot-System zu versuchen. Nicht dass es besonders schwierig wäre, wie alles hat es seine Vor- und Nachteile.
Da der Laptop ansonsten immer noch einwandfrei funktioniert und nach wie vor der meistgenutzte Rechner ist, macht es Sinn einen kleinen Versuch zu starten. Debian Sid und Arch Linux im direkten Vergleich. Fairerweise muss ich hinzufügen, dass es mir nicht um das "bessere" Linux geht, sondern einfach nur darum herauszufinden, welche Unterschiede es zwischen beiden gibt.

Was man bei der Installation von Arch Linux auf dem Dell Inspiron 4000 beachten sollte

Keine Sorge, ich werde nun niemanden mit der Installation von Arch Linux langweilen. Eine der großen Stärken von Arch Linux ist die ausgezeichnete Dokumentation. In der Regel benutze ich das englische Arch Linux Wiki, weil es umfangreichere Informationen enthält. Für die Installation ist das deutschsprachige Wiki aber nicht schlechter.
Arch Linux verlangt von seinen Benutzern absichtlich mehr Aufmerksamkeit. Entscheidungen von Grund auf zu treffen, ist bei Arch die Regel. Für den Inspiron 4000 musste ich dennoch nur bei den schon bekannten Problemen aufpassen. Die xorg.conf muss separat für dieses Modell erstellt und angepasst werden. Für Arch Linux lautet der Xorg-Treiber xf86-video-ati. Da noch keine Linuxdistribution den X-Server perfekt eingerichtet hat, hatte ich schon etwas Erfahrung. Eine einfache Kopie meiner xorg.conf von Debian nach Arch Linux reichte vollkommen aus.
Zu Testzwecken probierte ich die Linksys-WLAN-Karte mit Broadcom-Chipsatz zum Laufen zu bringen. Wie gehabt wird sie mit dem freien Kernelmodul b43 aktiviert, lediglich die Firmware der Karte ist unfrei und muss separat installiert werden. Im Gegensatz zu Debian muss die Firmware aus AUR installiert werden. Konkret bedeutet das, dass ein Tarball mit einem sogenannten PKGBUILD manuell heruntergeladen und entpackt wird. Diese Datei enthält lediglich Informationen, von wo man die ursprünglichen Quelldateien bezieht und notwendige formale Einträge über die Zielarchitektur, den Uploader usw.
Man sollte sich diese Textdatei auf jeden Fall genauer anschauen, da sie auch für ein System schadhafte Informationen enthalten kann. PKGBUILDS lassen sich aber bewerten, es gibt Feedback dazu auf der offiziellen Webseite, so dass in der Regel diese Methode durch eine Vielzahl von anderen Nutzern getestet worden ist.
Hat man das PKGBUILD entpackt und das Paket fakeroot installiert, genügt lediglich ein makepkg -s, um ein Arch Linux Paket zu bauen. Dieses wird dann lokal mit Hilfe von Pacman installiert. pacman -U Paketname.
Nachdem ich sowohl Xorg als auch Openbox installiert hatte, musste ich lediglich noch meine Konfigurationsdateien von Debian nach Arch Linux kopieren. Hier gab es erwartungsgemäß keine Probleme, da ich viele Ideen aus dem Arch Linux Wiki schon umgesetzt hatte und sowohl Debian als auch Arch hier keine Unterschiede gemacht hatten.
An dieser Stelle könnte ich nun einen Screenshot präsentieren, aber das System sieht exakt so aus wie es die Screenshots z.B. hier oder hier zeigen.
Mein Fazit ist: Arch Linux verlangt von seinen Benutzern mehr Aufmerksamkeit als Debian, das einige triviale Optionen einfach als gegeben voraussetzt. Das macht es einfacher, ein System von Grund auf an die eigenen Bedürfnisse anzupassen. Arch Linux hingegen will ausdrücklich, dass sich der Nutzer mit jeder Systemeinstellung auseinandersetzt und versteht wie das Ganze funktioniert. Zeigt man aber Eigeninitiative und folgt den Anweisungen im Arch Wiki, lässt einem Arch Linux nicht im Stich. Es gibt bei Freien Betriebssystemen kaum eine bessere Dokumentation.
Positiv fiel mir wieder einmal die Geschwindigkeit und das simple Konzept von Pacman, dem Paketmanager von Arch Linux, auf. Mittlerweile hat man auch die Sicherheitsprobleme angepackt. Danke auch an Daniel für den Hinweis!
In Zukunft werde ich versuchen Unterschiede von Debian Sid und Arch Linux zu dokumentieren und einfach etwas mehr über diese Distribution zu schreiben ohne Debian Sid in irgendeiner Weise zu vernachlässigen.

Posted on

Pacman und das Bedürfnis nach Sicherheit

In den letzten Tagen und Wochen habe ich mich öfter mit Pacman dem Paketmanager von Arch Linux auseinander setzen müssen. Kurioserweise ist er mir bei der Konfiguration von ConnochaetOS vertrauter geworden und weniger beim Umgang mit Arch Linux selbst. Irgendwann habe ich mich gewundert, wie Pacman eigentlich die Integrität der heruntergeladenen Pakete sicherstellt und nach Parallelen zu Debian GNU/Linux gesucht.
Ein wichtiges Hilfsmittel sind MD5-Hashes um zu bestimmen, ob ein vom Server heruntergeladenes Paket auch tatsächlich intakt auf dem eigenen Rechner ankommt. Auch Arch Linux greift genau auf diese Methode zurück. MD5 gilt seit einiger Zeit nicht mehr als ausreichend sicher und eignet sich daher auch nicht um die Echtheit von Paketen zu verifizieren.
Mittlerweile weiß ich auch, dass im Gegensatz zu Debians apt der Paketmanager von Arch Linux noch über keine ausreichende Implementierung zur Überprüfung von sicheren Paketsignaturen mit Hilfe von GnuPG verfügt. Bei meiner Suche nach Informationen bin ich dann auf einige lesenswerte und interessante Artikel gestoßen.
Zum einen wäre da der LWN Artikel "Arch Linux and (the lack of) package signing" und die Antwort darauf von Dan McGee, einer der Hauptentwickler von Pacman und Arch Linux. Kurz zusammengefasst wurde die Problematik am 23. März 2011 deutlich in den Fokus der interessierten Öffentlichkeit gerückt, obwohl das Problem schon seit mehreren Jahren im Bugtracker und Forum von Arch Linux bekannt war. Nach dem ich mir beide Artikel durchgelesen habe, denke ich, dass die Behauptung zutrifft, dass eine funktionierende Paketsignierung bei Arch Linux nicht existiert.

Weniger schwer wiegen da die verletzten Befindlichkeiten der Pacman-Entwickler und des im LWN-Artikels zitierten Arch-Nutzers, der die ganze Sache "ans Licht brachte". Offensichtlich gab es seit Jahren aus verschiedenen Gründen kein Interesse ein solches Sicherheitsfeature zu implementieren und gleichzeitig auch keine echte Hilfe von Seiten der Community. Die Entwicklung stagnierte. Die Frage ist nur, ob man ein solches Problem nur zur Aufgabe einiger Paketentwickler degradieren oder es nicht doch besser zu einer Aufgabe und zu einem Ziel der ganzen Distribution hätte machen sollen.
Natürlich ist jeder User immer ein Stück weit selbst für die Sicherheit seines Systems verantwortlich. Dennoch sollte es eine Möglichkeit geben zu überprüfen, ob es sich bei den heruntergeladenen Paketen auch wirklich um die offiziellen handelt und nicht möglicherweise doch um kompromittierte.
Seit dem Artikel sind sechs Monate vergangen und ein Blick auf die offizielle ArchLinux-Seite zeigt, dass man das Problem zumindest nicht versucht zu verbergen. Es gibt eine eigene Wikiseite zum Thema "Pacman package signing" und auch die FAQ listet unter dem Punkt "Warum man Arch nicht nutzen sollte" auf, dass man dann auf eine sichere Paketsignierung nicht verzichten muss.

Arch Linux ist nicht die einzige Distribution, die eine solche Verifizierung noch nicht vorgesehen hat. Sie wird deswegen auch nicht nutzlos. Selbst Debian hatte nicht von Anfang an eine Möglichkeit um die Echtheit von Paketen zu überprüfen. Doch im Gegensatz zu Arch Linux gab es bereits vor elf Jahren eine breite Diskussion zu diesem Thema. In der Dokumentation zur Absicherung von Debian finden sich hier zwei Links zu den wöchentlichen Neuigkeiten aus dem Jahr 2000 und 2001.
Wenn man etwas daraus lernen kann dann das, man sollte jede Distribution darauf überprüfen, ob sie zu den persönlichen Anforderungen passt. Wenn ich mich auf meine Software zu 100% in jeder Situation verlassen muss, greife ich eher zu Debian Stable als zu Arch Linux. Wenn ich der Meinung bin, dass das Risiko auf ein paar älteren privaten Laptops vernachlässigbar ist und die Distribution ansonsten wunderbar für mich funktioniert, werde ich die betreffende Distribution auch weiterhin verwenden. Ganz allgemein gesprochen kann es nicht schaden die vielen Drittquellen, wozu z.B auch die PPAs bei Ubuntu gehören, genauer unter die Lupe zu nehmen und nicht jedes Paket blindlings herunterzuladen. Schließlich sollte doch ein zentrales und vor allem sicheres Paketmanagement Linux von anderen Betriebssystemen positiv unterscheiden.

Posted on

Drei Openbox-Distributionen kurz vorgestellt

Die Zeit fliegt im Moment, weswegen ich auf eine ausführlichere Vorstellung verzichten muss. Hier sind drei Linuxdistributionen, die sich älterer Hardware und einem ressourcensparenden Setup verschrieben haben, ohne dabei aber auf notwendige und sinnvolle Anwendungen verzichten zu wollen. CTKArch und Madbox habe ich seit Mai diesen Jahres auf meiner Liste als ich zum ersten Mal bei Kmandla über beide gelesen habe. WattOS geisterte als Name sogar noch länger umher, weswegen ich die Gelegenheit ergriffen habe das Ubuntu-Derivat mit den anderen beiden gemeinsam vorzustellen.

Was mir sofort an CTKArch gefallen hat, war die ehrliche und bescheidene Äußerung des Machers, dass CTKArch ein Setup von ArchLinux sei und keine Distribution, obwohl das kleine Projekt mittlerweile sogar schon auf distrowatch.com auftaucht. Viele andere fangen gerne damit an jeden Klon mit ein paar geänderten vorinstallierten Softwarepaketen als eigenständige Distribution zu bejubeln. Auf der anderen Seite entstehen viele neue Linuxideen genau auf diese Art und Weise. Man möchte selbst herausfinden wie eine Live-CD erstellt wird und nimmt sich eine andere Distribution als Vorlage. Bei CTKArch war es ähnlich und nach und nach entstand so seit 2009 eine eigenständige Live-CD auf Basis von ArchLinux und dem flexibel konfigurierbaren Openbox-Fenstermanager. Standardmäßig werden aber nur Französisch und Englisch als Systemsprache unterstützt.
Mir gefällt das ansprechende Design des Desktops und das man mit einem simplen Mausklick zwischen dunklem und hellem Thema wechseln kann. Ob es das FBPanel oder Tint2 als Panel sein soll, lässt sich ebenso leicht mit einem Mausklick festlegen. Für die wichtigsten Anwendungsfälle gibt es jeweils genau ein mitgeliefertes Programm und das Ganze lässt sich mit einem Textinstaller auch auf eine Festplatte installieren. Alles in allem macht CTKArch mit nur 50 MB Speicherauslastung nach dem Booten einen guten Eindruck und scheint mir der richtige Startpunkt zu sein, wenn man sich Zeit und Mühe ersparen möchte eine Openbox-Desktopumgebung auf Basis von Arch Linux selbst zusammenzustellen.

Madbox ist ebenfalls eine mit dem Fenstermanager Openbox vorkonfigurierte Distribution, die aber Ubuntu als Unterbau gewählt hat. Deutsch sucht man beim Start von der Live-CD ebenfalls vergeblich, auch hier ist Französisch und Englisch Trumpf und selbst die deutsche qwertz Tastatur muss man manuell einrichten. Was mir wirklich gut gefällt ist das ansprechende Design und das AdeskBar Panel am oberen Bildschirmrand. Scheinbar gibt es noch kein eigenständiges Debianpaket hierfür, aber zumindest auf Launchpad gibt es schon ein Repo. Gegenüber CTKArch vermisse ich ein paar interessante Ideen für das Openbox-Menü und ebenso einige vorinstallierte Programme. Vom reinen Speicherverbrauch her liegt Madbox mit ca. 100 MB zwischen CTKArch und WattOS nach dem Login.
Scheinbar gibt es bisher noch keine neuere Version von Madbox als die auf Ubuntu 10.10 basierende. Was mir aber auf jeden Fall fehlt ist ein wenig mehr Dokumentation und Information zu diesem schicken Ubuntu-Setup. Selbst die Links auf der offiziellen Homepage führen leider nicht zum Ziel.

WattOS ist eine auf Ubuntu basierende Distribution, deren Ziel es ist auf älteren Rechnern reaktionsfreudig und ressourcensparend zu bleiben und damit konsequenterweise auch weniger Strom zu verbrauchen, weshalb der amerikanische Hauptentwickler sich James Watt als Namensgeber augesucht hat.
In vielen Aspekten erinnert mich WattOS an Lubuntu. Gleicher Systemkern, LXDE als Desktopumgebung mit Openbox als Fenstermanager und klassisches LXPanel am unteren Bildschirmrand. Die größten Unterschiede: Anderes Standarddesign und Änderungen bei der Softwarevorauswahl. Insbesondere fielen mir fotoxx, ein Foto- und Bildeditor, rednotebook, eine Art Notizheft mit Kalenderfunktion ähnlich wie Tomboy und foobnix, ein Programm zum Musikhören, auf.
WattOS hat einen ähnlichen Ressourcenverbrauch wie Lubuntu, womit selbst ältere Computer problemlos funktionieren sollten. In Sachen Effizienz existieren aber noch bessere Alternativen. Das Projekt ist relativ klein und durch die Fokussierung auf ältere Rechner wird auch nur i386 als Architektur unterstützt. Etwas enttäuschend fand ich, dass es keine Auswahlmöglichkeiten zwischen verschiedenen Sprachen und Lokalisierungen beim Systemstart gegeben hat und man auch in der Live-Umgebung vergeblich nach offensichtlichen Einstellungsmöglichkeiten sucht.
Die Softwareauswahl war im Großen und Ganzen angemessen und ein paar unbekannte und interessante Alternativen waren dabei. Ob Firefox wirklich die sinnvollste Voreinstellung für Rechner mit weniger als 256 MB RAM ist sei dahingestellt.
Nach wie vor gefällt mir Crunchbang mit seinem ausgefeilten Openbox-Menü und den vielen sinnvollen und guten Voreinstellungen am besten. Auch wenn die hier vorgestellten Linuxdistributionen teilweise wirklich gute Ideen mitbringen, schätze ich Crunchbang als Gesamtpaket weiterhin höher ein. Auf jeden Fall zeigen alle, dass es kein Hexenwerk ist sein eigenes Linux zu erstellen und führen noch einmal vor Augen, dass die Kombination von Basisapplikationen und einem ausgefeilten Fenstermanager jeden noch so alten Rechner weiterhin produktiv sein lassen.

Posted on

Chakra: Energie mit Arch Linux und KDE

Vor einigen Tagen bin ich abtrünnig geworden und habe mir die Linuxdistribution Chakra GNU/Linux angeschaut, die sich vollkommen auf den KDE-Desktop konzentriert. Dabei hatte ich mich schon auf einen waschechten Verriss gefreut, denn Chakra verhielt sich äußerst merkwürdig in meiner Virtualbox Testumgebung. Zwar kam ich bis zum Login und konnte mich nach kurzer Suche nach dem Passwort im Internet auch einloggen, doch dann landete ich prompt wieder beim Loginmanager KDM. Der obligatorische MD5-Checksummen-Test konnte auch keine Fehler mit der ISO-Datei feststellen, weshalb ich noch einmal genauer nachforschte und die Systemvoraussetzungen fand.
Für eine Installation aus Virtualbox dürfen es schon mal 1 GB sein, auf jeden Fall war RAM die Ursache allen Übels. Natürlich war das mit dem Core Duo nicht wirklich eine Herausforderung und zur Sicherheit aktivierte ich auch gleich noch mal die 3D-Beschleunigung in Virtualbox. Danach war es kein Problem in die Live Umgebung zu gelangen. Später brannte ich das ISO auf eine CD, von der sich problemlos starten ließ. Die Benutzer sind übrigens "live" und "root" mit den gleich lautenden Passwörtern.


Das Chakra-Projekt entstand irgendwann im Jahr 2009 mit dem Ziel eine auf Arch Linux basierende KDE-Live-CD zu entwickeln. Später hat man sich entschieden eigenständig zu werden und sich von Arch Linux abzukoppeln, der Chakra GNU/Linux Fork war entstanden.
Die auffallendsten Merkmale der Live-CD entdeckte ich schon beim Booten. Chakra lässt dem Nutzer ausdrücklich die Wahl, ob er mit freien oder unfreien Treibern starten möchte. Danach ging es schnell direkt in den sehr ansprechend gestalteten KDE Plasma Desktop. Man kann über KDE vieles sagen, mangelhafte Optik assoziiere ich aber nicht damit.
Als ich später Chakra auch noch einmal auf CD brannte und ausführte, fiel der Ressourcenverbrauch von KDE nicht weiter ins Gewicht. Alle Programme hatten eine angenehme Startzeit und insgesamt ließ sich der gesamte Desktop flüssig bedienen.
Interessant ist der Spagat, den die Entwickler versuchen zu erreichen. Zum einen soll der Unterbau nach dem K.I.S.S. Prinzip wie bei Arch Linux gestaltet sein und technisch immer die einfachste Lösung gefunden werden. Zum anderen soll vermieden werden weitere Zwischenschichten einzubauen, die die Komplexität des Gesamtsystems weiter erhöhen und dennoch ein für das Auge wohlgefälliges Betriebssystem entwickelt werden.
Chakra ist kein reines "Rolling Release" System. Die wichtigsten Systemkomponenten wie z.B. der X-Server werden in einem Core Release stabil gehalten, d.h. erst nach einer längeren Testphase für ein Update frei gegeben, wodurch sich die Entwickler einen besseren Kompromiss zwischen Stabilität und aktueller Software erwarten.
Chakra bietet einige eigenentwickelte Werkzeuge an, darunter das Vorzeigeprojekt Tribe, ein auf QT4 basierender grafischer Installer, der im Hintergrund aber Bashskripte nutzt. Rein optisch gesehen ist Tribe bisher das Beste, was ich in dieser Form für den Linux-Desktop gesehen habe.
Natürlich könnte ich nun auch ätzen, inwiefern solche Optik nötig ist, wenn das automatisch nicht so leistungsfähige Hardware aussperrt. Schöner Schein für altbekannte Konfiguration? Gut, man muss klar sagen: KDE 4 ist wie das neue GNOME 3 keine echte Alternative für ältere Hardware, also für alle Pentiums, die einmal mit weniger als 512 MB RAM zu Recht kamen, aber immer noch wesentlich reaktionsfreudiger und leistungsfähiger als bekannte proprietäre Betriebssysteme.
Chakra und KDE möchten es aber auch nicht allen Recht machen. Entscheidet man sich für die beiden gibt es einen grafisch aufpolierten Desktop, mit dem jeder halbwegs moderne Rechner ohne Probleme nutzbar bleibt. Wer gerne bekannte GTK-Programme wie z.B. Gimp einsetzt, muss bei Chakra darauf auch nicht vollkommen verzichten. Zwar lautet die Devise: Keine GTK-Anwendungen, nur QT. Doch mit Hilfe vorgefertigter "Bundles" lassen sich diese KDE fernen Vorzeigeprojekte ebenso leicht auch bei Chakra installieren. Das Ganze ist eine Mischung zwischen den bei MacOS bekannten .img Dateien und einem abhängigkeitsauflösenden System wie bei Linux.
Viele weitere Informationen findet man bei Chakra entweder im Wiki oder im Forum. Leider gibt es dort noch viele Dokumentation nur in englischer Sprache. Wie bei allen Open-Source-Projekten wächst aber der Sprachumfang mit der Anzahl der Benutzer. Vergessen darf man auch nicht, dass Chakra nach wie vor im Alpha-Stadium ist und sich in Entwicklung befindet. Beschützt eure Hamster!
An Programmen kann man aus dem reichen Fundus des KDE-Projektes auswählen und natürlich durfte auch der gefühlt 23. Webkit-Browser namens rekonq nicht fehlen.
In jedem Jahr probiere ich immer mal gerne 2-3 Distributionen mit KDE-Desktop aus, nur um der alten Zeiten willen. Realistisch gesehen gibt es eine Grenze wie viele verschiedene Desktopumgebungen man tatsächlich nutzen möchte und kann. Um wirklich alle jederzeit präsent zu haben, müsste sich mein Hardware-Arsenal mindestens verdreifachen.
Auch wenn es wohl in Zukunft Gnome 3 mit Debian Testing auf meinem Multi-Boot-System werden wird, es war wieder mal nett einen Blick auf KDE zu werfen. Optisch hat es nach wie vor eine Menge zu bieten und wie oft schon erwähnt, das Gute an Linux ist: Die Wahl zu haben.

Posted on

ConnochaetOS: Moderne Software für alte Computer

Eine weitere interessante Linuxdistribution für alte Computer. ConnochaetOS basiert zwar auf ArchLinux, die Zielgruppe des Projekts sind aber Computer vom 586er bis zum Pentium III, wodurch sie sich von Archs Fokussierung auf die i686 und x86_64 Architektur unterscheidet.
Connochaet ist vom wissenschaftlichen Fachbegriff Connochaetes für ein Gnu abgeleitet und spielt natürlich auf das GNU-Projekt an. Ziel ist es ausschließlich freie Software nach den GNU-Richtlinien zu enthalten und mit so wenig Ressourcen wie nötig ein modernes und stabiles Betriebssystem auf die Beine zu stellen.
ConnochaetOS, ehemals auch als Deli Linux bekannt, befindet sich immer noch in einer Beta-Phase. Eigentlich wollte ich noch bis zur finalen Version warten, bevor ich einen Blick riskiere, doch die Neugier hat schließlich gesiegt.
Wer Archlinux kennt wird mit der Installation keine Probleme haben. Bis auf die Auswahl der Software sind es die gleichen Schritte. ConnochaetOS hat sich bei der Auswahl der Programme von den Gedanken freie Software, ressourcensparend und schnell leiten lassen. Das merkt man überall. IceWM ist als Fenstermanager voreingestellt, der bekanntermaßen versucht bewährte Konzepte des Windows- und Linuxdesktops zu kombinieren.


Mplayer ist standardmäßig sowohl für Audio als auch Video verantwortlich und Gnumeric und Abiword erledigen die Büroarbeit. Interessante Alternativen zu bekannten anderen leichtgewichtigen Programmen sind LilyTerm, ein Terminalemulator, und xxxTerm, ein Webbrowser. Letzterer basiert auf der WebKit-Engine und gibt sich sehr genügsam. Im Gegensatz zu Midori oder anderen Alternativen fehlen aber noch einige Funktionen.
Als Dateimanager wird PacManFM eingesetzt, so wie auch andere Komponenten der LXDE-Desktopumgebung um Systemeinstellungen zu konfigurieren. Ansonsten gibt es einige weitere, einfache grafische Frontends z.B. um das Hintergrundbild zu ändern oder Blinky, eine GUI für Archs Paketmanager PacMan.
Wie gesagt befindet sich ConnochaetOS noch in der Entwicklungsphase, weswegen man es mit vorschnellen Urteilen nicht übertreiben sollte. Momentan scheint ConnochaetOS stabil in Virtualbox zu laufen und die richtigen Designentscheidungen getroffen zu haben, um ein sehr leichtes und dennoch gut ausgestattetes Betriebssystem auf Basis von Archlinux zu entwickeln.
Als Hardwareanforderungen werden mindestens ein Pentium I und 64 MB RAM für eine grafische Installation empfohlen. Direkt nach dem Login mit Hilfe von xdm werden ca. 38 MB RAM belegt. Wem die anderen Distributionen auf der Liste der leichtgewichtigen Distributionen nicht zusagen oder wer sowieso für alles Archlinux einsetzt, der sollte sich ConnochaetOS merken.
Höchstens die fehlende Dokumentation scheint mir momentan noch zu den größeren Schwächen zu gehören, wobei man für grundlegende Probleme auch auf die Foren und das Wiki von Archlinux ausweichen kann. Hilfe gibt es aber im offiziellen Forum, auch auf Deutsch.

Posted on

CrunchBang + ArchLinux = ArchBang

Es ist ArchBang Zeit. Als ich meine Liste zum Ausprobieren von leichtgewichtigen Distributionen schrieb, bezeichnete ich noch Crunchbang als "das andere Bang". Wer war nun zuerst da? Archbang versteht sich selbst als Archlinux Derivat, welches dem Nutzer die Mühe abnimmt, Pakete für den Openbox Desktop selbst zu installieren und zu konfigurieren.
Archbang hat kaum eigene Dokumentation zu bieten und deshalb verwundert es auch nicht, dass neue Nutzer schnell an das herausragende Wiki von Archlinux verwiesen werden.
Ohne Umschweife, ist Archbang ein anderes Archlinux oder gar eine besondere neue Distribution? Nein.
Kurz zusammengefasst lässt sich der archtypische Installationsprozess durch Archbang ein wenig abkürzen, Paketquellen und Pakete müssen logischerweise nicht ausgewählt werden. Der Rest ist vollkommen identisch zur gewohnten Textinstallation.
Wenn man wie ich vor kurzem einen längeren Blick auf CrunchBang Linux werfen konnte, fallen sofort die frappierenden Ähnlichkeiten auf. Schwarz gehaltenes Desktopthema, Openbox mit einem nur in wenigen Punkten abgeänderten Rechtsklick-Menü und eine Konfiguration, die in vielen Punkten Crunchbang mehr als ähnlich ist.
Unterschiede in der Auswahl der vorinstallierten Anwendungen sind ebenfalls nur gering. Größte Auffälligkeiten sind MPlayer anstelle von VLC, das LXTerminal, geeqie als Bildbetrachter und das umfangreiche GIMP im Gegensatz zu dem auf einfache Grafikaufgaben beschränkten, aber dadurch auch schnelleren, MTPaint.


Natürlich ist das alles kein Zufall sondern auch ein wichtiger Bestandteil von Open Source. Mittlerweile gibt es vier Hauptentwickler des Projekts und irgendwann muss wohl dem Projektleiter und Initiator Crunchbang Linux so gut gefallen haben, weshalb er kurzerhand das ganze Konzept auf seine Lieblingsdistro Archlinux angewendet hat.
Im Gegensatz zu Crunchbang, welches auf das stabile Debian Squeeze setzt, hat Archbang sich die Vorteile einer rollenden Distribution wie Archlinux zu eigen gemacht. Einmal installiert und man erhält fortlaufend immer die neusten Versionen der Programme.
Wie halte ich es nun mit Archbang? Ich denke, wenn man eher zu Archlinux neigt und eine vorgefertigte, leichtgewichtige Distribution auf Basis von Openbox und Archlinux sucht, dann ist Archbang genau das Richtige. Da Archlinux-Nutzer sowieso zu den "Tu-es-selbst"-Kandidaten gehören, werden die sich auch kaum an der fehlenden Dokumentation stören und sich gleich am umfangreichen Fundus des Mutterprojekts bedienen.
Ist man mit Debian zufrieden, fällt es sicher leichter sich für Crunchbang zu entscheiden, wobei um das Projekt herum schon eine sehr aktive Gemeinschaft entstanden ist. Die Dokumentation ist zwar nicht perfekt, aber doch deutlich besser als bei Archbang. Persönlich neige ich mehr zu Crunchbang, nicht nur weil ich Debian favorisiere, sondern weil ich auch denke, dass Ruhm und Ehre für eine hervorragend konfigurierte Openbox-Distribution bei Crunchbang liegen sollte.
Beide Distributionen sind gleichermaßen geeignet, wenn man ein ressourcenschonendes Betriebssystem sucht. Am Ende ist die Frage scheinbar wirklich nur: Arch oder Debian?

Posted on

Teste dein Multi-Boot System

Wie findet man heraus, welche Linuxdistribution die "bessere" ist? In was besser eigentlich und wie misst man am besten?
Natürlich braucht man geeignete Werkzeuge und Irgendetwas, mit dem sich die Ergebnisse vergleichen lassen.
In meinem Beitrag zu Speicherverbrauch und Compiz von Ubuntu 11.04, habe ich versucht es etwas lockerer mit dem Systemmonitor und etwas Gefühl zu versuchen.
Für großangelegte Benchmarks gibt es für Linux aber schon eine Lösung - die Phoronix Test Suite.
Mit ihr lässt sich zwar nicht der Leistungsunterschied zwischen Programm X und Y messen, jedoch bietet sie umfangreiche Tests an, um Komponenten eines Computers auf Herz und Nieren zu prüfen. Wie performant ist mein Rechner gegenüber Modell xy eigentlich? Mit der Phoronix Test Suite kann man einer Antwort auf diese Frage näher kommen.
Mich interessierte für mein Multi-Boot System hingegen wie sich die drei unterschiedlichen Distributionen Ubuntu 11.04 (64bit), Debian Testing (32 bit) und Arch Linux (64bit) auf dem gleichen Rechner schlagen. Würde es große Unterschiede zwischen den beiden 64 bit Systemen von Arch Linux und Ubuntu 11.04 geben und wie würde Debian Testing als 32 bit Betriebssystem abschneiden?
Ich habe mich schließlich für die linux-system Test Suite entschieden, welche mit vielen Untertests nach eigener Aussage die Gesamtperformance eines Linux Systems im Vergleich zu anderen darstellen kann.
Die Phoronix-Test-Suite ließ sich wie gewohnt installieren. In allen drei Distributionen gab es schon vorgefertigte Pakete. Die Tests sind bei jeder Distribution die gleichen und mussten nur ein einziges Mal heruntergeladen werden. Danach genügte ein phoronix-test-suite make-download-cache, wodurch die Tests im versteckten Ordner ~/.phoronix-test-suite/download-cache abgelegt wurden und nur noch zwischen den Systemen kopiert werden mussten.
Die Test-Suite selbst wird mit dem Kommando

phoronix-test-suite benchmark linux-system

ausgeführt. Möchte man nur die Tests herunterladen genügt install anstelle von benchmark, zum Ausführen ist es der Befehl run.
Insgesamt sollte man für eine so umfangreiche Test-Suite genug Zeit einplanen, da die Pakete teilweise auf dem Zielsystem noch kompiliert werden und zusätzliche Pakete über die Paketverwaltung installiert werden. Bei Debian und Ubuntu verlief dieser Prozess meistens reibungslos, bei Arch Linux musste ich öfter manuell nachhelfen. Selbst dann gelang es mir nicht alle Tests erfolgreich auszuführen. Da es aber genug vergleichbare Tests auch mit Arch schafften durchzulaufen, sieht das Ergebnis am Ende meiner Meinung nach eindeutig aus.
Das Ergebnis habe ich der Einfachheit halber gleich auf openbenchmarking.org veröffentlicht. Dort finden sich auch Details zu den getesteten Komponenten des Rechners. Alle Distributionen waren zum Zeitpunkt des Tests auf dem aktuellen Stand. Kernel 2.6.38 und das ext4 Dateisystem kamen standardmäßig bei allen zum Einsatz. Als Desktopumgebung setzte ich bei Debian Testing auf Gnome 2.30, bei Ubuntu 11.04 auf Unity und mit Arch Linux auf Gnome 3.

Das Ergebnis

Phoronix-Test-Suite: pts/linux-system Intel Core 2 Duo e7400, Ubuntu 11.04, Debian Testing (wheezy), Arch Linux
Nicht ganz überraschend ist mein 32 bit Debian Testing System bei dieser Test-Suite abgeschlagen Letzter geworden. Lediglich bei Minion, dem Threaded I/O Tester und POV-Ray liegt wheezy vorne. Die restlichen Tests zeigen deutlich, dass zwischen den beiden 64 bit Distributionen Ubuntu 11.04 und Arch Linux kein großer Unterschied besteht. Wenn überhaupt liegt Ubuntu bei Encoding und rechenintensiven Tests, bei denen ein 64 bit System seine Vorteile deutlich ausspielen kann, knapp vorne.
Die größten Ausreißer gab es bei dem Postmark Test, wo wheezy komplett aus der Reihe fällt und dem Apache Benchmark, wo Arch Linux deutlich hinterher hinkt. Die Werte weichen zu deutlich von den anderen ab, weshalb ich denke, dass hier ein Messfehler vorliegt.
Die ganzen Tests haben nachträglich noch einmal bestätigt, dass es absolut sinnvoll ist für Audio-, Video- und Bildbearbeitung ein 64 bit Betriebssystem einzusetzen. Ob es nun Arch Linux oder Ubuntu 11.04 ist, scheint weniger wichtig zu sein. Letzteres war scheinbar keine schlechte Wahl.
Die Phoronix Test-Suite bietet aber auch Kritikpunkte. So sinnvoll ich es halte, dass es sich immer um die gleichen Tests handelt, es wird dadurch aber nicht einfacher herauszufinden, ob es eventuell distributionsspezifische Vorteile bei einzelnen Programmen gibt.
Des weiteren ist eine solche Test-Suite immer auch ein Extremtest und spiegelt nicht den alltäglichen Gebrauch eines Computers wider. Sollte ich aber irgendwann den ganzen Tag nichts anderes tun als 1GB große Dateien mit GnuPG zu verschlüsseln, mache ich das am besten mit Ubuntu 11.04 (64bit). Komprimiere ich Dateien mit LZMA sollte es wohl besser Arch Linux(64bit) sein.
Wenn ihr euch den Spaß machen möchtet und genau diese Testumgebung auf eurem Rechner ausprobieren wollt, können die Resultate direkt mit folgendem Befehl verglichen werden:

phoronix-test-suite benchmark 1105157-IV-20110514D92

Zum Schluss habe ich mir ein anderes Resultat vorgenommen, welches die Tests Unigine Heaven und Openarena schon ausgeführt hatte. Im Prinzip ging es um den Vergleich Radeon 4870 gegen meine Nvidia 9600 GT. 32 bit versus 64 bit spielte hierbei keine Rolle. Die Auflösung betrug 1680x1050 Pixel. Alle Distributionen konnten auf die aktuellen Nvidia Treiber zurückgreifen.
Unigine Heaven Test Nvidia 9600 GT Ubuntu 11.04, Debian Testing (wheezy), Arch Linux
Bedauerlicherweise erreichte ich mit keinem der Distributionen die vorgegebenen Framewerte. Am schlechtesten schnitt dabei Arch Linux ab. Ich versuchte es deshalb mit OpenArena erneut, wo Ubuntu 11.04 (+compiz) 346,23 fps erzielen konnte.
Debian Testing (+compiz) erreichte 330 fps und Arch Linux (Gnome 3) 329,57 fps. Die Unterschiede waren also nur marginal.
Ergebnis OpenArena Wheezy
Ergebnis OpenArena Arch Linux
Interessant wurde es noch einmal als ich den OpenArena Test mit wheezy ohne compiz wiederholte und dabei 376,27 fps erreichte.
Ergebnis OpenArena Wheezy ohne compiz
Das Ergebnis lässt den Schluss zu, dass 32 bit oder 64 bit bei den Tests keine große Rolle spielte. Wichtiger sind verwendete Grafiktreiber, die Grafikkarte selbst und ob ein Compositing Fenstermanager wie compiz aktiviert war oder nicht. Für Spieler lässt das nur den Schluss zu, dass weniger Compiz beim Spielen mehr ist.
Alles in allem zeigen die Phoronix Tests, dass die allgemeine Grundperformance bei vergleichbarer Architektur sehr ähnlich ist. Optimierungen und Verbesserungen einzelner Anwendungen konnte die Test-Suite aber nicht messen. Ob ein System mit speicherhungrigen Programmen überladen war oder dezent nur das Notwendige installiert war, ließ sich mit den Tests nicht feststellen.

Posted on

Die Vor- und Nachteile eines Multi-Boot-Systems

Mehr als ein Monat ist vergangen, seitdem ich Ubuntu 10.10 gegen ein Multi-Boot-System ausgetauscht habe. Falls ihr euch ebenfalls für ein solches System interessiert, findet ihr in diesem Beitrag eine Übersicht über die Vor- und Nachteile. Die gemachten Erfahrungen mit den drei neuen Betriebssystemen Ubuntu 11.04, Debian Testing und Arch Linux habe ich zusammengefasst und zu den einzelnen Schritten des Projekts verlinkt.

Warum überhaupt Multi-Boot?

Vorteile

Vergleichbarkeit: Mit einem Multi-Boot-System ist es unkompliziert sich die Vor- und Nachteile verschiedener Linuxdistributionen oder Desktopumgebungen unter realistischen Bedingungen anzuschauen. Zwar bieten Virtualisierungslösungen wie z.B. Virtualbox und Qemu einen weniger aufwendigen Überblick. Diese hinken in Sachen Performance einem Multi-Boot System in der Regel aber deutlich hinterher.
Klare Aufgabentrennung: Ein Multi-Boot-System eignet sich hervorragend, um typische Arbeiten am Computer zu trennen. So lässt sich ein Betriebssystem ausschließlich zum Arbeiten, ein anderes für Videobearbeitung und ein drittes vielleicht zum Spielen nutzen.
Flexibilität und Integrität: Nicht nur die Software kann flexibel an die eigenen Bedürfnisse angepasst werden, auch unterschiedliche Dateisysteme können eingesetzt werden, um die Performance für spezielle Anwendungen zu erhöhen. Bei getrennten Partitionen und Betriebssystemen wiegt ein Schaden am Dateisystem weniger schwer und Fehler wirken sich nicht auf alle Daten gleichzeitig aus.
Sicherheit: Ein Multi-Boot-System kann so eingerichtet werden, dass nur diejenigen Anwendungen installiert sind, die man tatsächlich braucht. Was nicht installiert ist, kann auch nicht kompromittiert werden. Nutzt man ein System z.B. ausschließlich für private Korrespondenz und Büroarbeit lässt sich mitunter auf einen Browser und diverse Internet- und Multimediaanwendungen als potentielle Einfallstore für Schadsoftware verzichten.
Performance: Je nach Geschmack und Vorlieben lassen sich Multi-Boot-Systeme für ihren jeweiligen Anwendungszweck optimieren. Ein Linuxsystem für Spiele braucht z.B. keine Textverarbeitung, kein Multimedia, kein Emailprogramm und auch kein Compiz. Nur das Spiel, ein Terminal, eventuell IRC- und VoiP-Client der Wahl, der aktuellste Grafiktreiber und ein auf das notwendigste optimierter Linuxkernel sind wirklich notwendig.
Eingewöhnung: Gerade bei einem Umstieg von Windows oder Mac auf Linux oder zwischen zwei verschiedenen Linuxdistributionen, macht es Sinn für eine Übergangszeit zwei Systeme parallel zu nutzen, zumindest solange bis man sich an die neue Umgebung gewöhnt hat.

Nachteile

Mehr Aufwand: Für ein Multi-Boot-System fällt zusätzlicher Installations- und Konfigurationsaufwand an. Nicht nur muss der Installationsvorgang ggf. mehrmals wiederholt werden. Auch die Wartung, Pflege und Administration der Systeme kostet je nach Distribution und Vorstellungen zusätzliche Zeit. Noch nicht vertraute Konzepte anderer Distributionen müssen erst erlernt werden.
Reboot: Um das System zu wechseln ist immer ein Neustart notwendig. Auch das kostet Zeit und kann manchmal störend sein, wenn man "nur mal kurz" etwas ausprobieren möchte.
Doppelte Funktionalität: Idealerweise gibt es für die Multi-Boot-Systeme jeweils einen spezifischen Verwendungszweck. Es besteht aber die Gefahr, dass Programme doppelt installiert werden und sich Aufgaben überschneiden. Beispiel Browser: Hiermit lassen sich schnell Informationen im Internet finden, was sowohl für reine Büroarbeit als auch für Videobearbeitung und Spiele sinnvoll sein kann. Um Redundanz zu vermeiden, muss man sich vorher genau überlegen, was man sich von seinem Multi-Boot System überhaupt erwartet.

Partitionierung und Installation

Debian Testing: Manuelle Partitionierung eines verschlüsselten LVM
Ubuntu 11.04: Download der Beta mit jigdo und Installation
Arch Linux: Installation mit der Multi-Arch CD

Überblick über das Partitionsschema

PartitionBeschreibung
/dev/sda1 (Primär)Unverschlüsselte Bootpartition für Debian Testing (ext2)
/dev/sda2 (Primär)Daten- und Austauschpartition zwischen den verschiedenen Distributionen (ext4)
/dev/sda5 (Logisch)LVM auf einem verschlüsselten Volume mit den Logical Volumes root, swap und home für Debian Testing
/dev/sda6 (Logisch)Ubuntu 11.04 installiert in eine logische Partition (ext4)
/dev/sda7 (Logisch)Swap Partition für Ubuntu 11.04 und Arch Linux
/dev/sda8 (Logisch)Arch Linux installiert in eine logische Partition (ext4)

Die drei Linuxdistributionen im Überblick

Debian Testing (Gnome 2 + Compiz)

Gnome 2

Ursprünglich wollte ich Linux Mint Debian mit verschlüsseltem LVM installieren. Mit LMDE beschäftige ich mich seit Ende 2010 und habe mich dann auf Basis einer Debian Netzinstallation für "The Debian Way" entschieden.
Nach einigem Rumprobieren und Abwägen zwischen Linux Mint Debian und dem reinen Debian, blieb ich schließlich bei Debian Testing. Zu gering erschienen mir die Vorteile und in der Tat war LMDE dann doch nur ein mint-meta Paket.
Debian Testing ist nun das Haupt- und Arbeitssystem, von dem auch die anderen Systeme mit Hilfe von GRUB im MBR eingebunden werden. Als Desktopumgebung nutze ich Gnome 2, das ich nach der Installation des gnome-core Pakets nur noch geringfügig konfigurieren musste, um die von Ubuntu gewohnten Eigenschaften zu erhalten. Zur Zeit bin ich wunschlos glücklich mit Debian und warte nun geduldig auf Gnome 3.

Ubuntu 11.04 (Unity+Compiz+Gnome)


Ubuntus Natty Narwhal dient mir seit neustem als Videoschnittplatz, worunter bei mir auch Bild- und Audiobearbeitung fallen.
Zukünftig möchte ich Ubuntu für die Realisierung kleinerer Videoprojekte einsetzen und dabei ausschließlich Open-Source-Software nutzen. Das Ganze ist ein Projekt im Entstehen. Sollten die Ergebnisse interessant und vorzeigenswert seien, gibt es eventuell auch einen Blogbeitrag. 😉
Die ersten Eindrücke zu Ubuntu 11.04 waren gemischt, aber mit ein paar kleinen Optimierungen lässt sich mit dem schicken Narwal leben.

Arch Linux (Gnome 3)


Arch Linux war schon seit längerem ein Testkandidat für mich. Obwohl etwas Einarbeitungszeit erforderlich ist, sind die erstklassige Dokumentation im Netz und das Ergebnis alle Mühen wert. Wer gar nicht auf ein gut getestetes Gnome 3 in Debian warten kann, hat mit Arch die besten Chancen die Zeit zu überbrücken.
Da ich Stabilität und Zuverlässigkeit bei Betriebssystemen sehr hoch einschätze, wird Arch vermutlich auch in Zukunft Debian nicht verdrängen. Zu unterschiedlich sind hier die beiden Ansätze. Das heißt nicht, dass Arch Linux notorisch instabil ist, aber allein aus grundsätzlichen Überlegungen kann ein Rolling Release, welches auf brandaktuelle Software abzielt, nicht genauso umfangreich wie Debian Stable getestet sein. Archs besonders hervorzuhebendes Qualitätsmerkmal ist die erstklassige Dokumentation. Für ein leichtgewichtiges Linux oder gerade wenn man auf neue Feature Wert legt, ist Arch mit Sicherheit eine Option, die man im Hinterkopf behalten sollte.

Fazit

Ein Multi-Boot-System ist nützlich, lehrreich und macht Spaß. So bleibt in Zukunft die Möglichkeit die Vor- und Nachteile verschiedener Distributionen unter realistischen Bedingungen zu testen. Insgesamt ist das Hauptsystem mit Debian Testing deutlich aufgeräumter und besser auf die Anforderungen angepasst als das eine Standardinstallation von Ubuntu naturgemäß vorher leisten konnte.
Die Reaktionsfähigkeit einer reinen Debian Installation gegenüber Ubuntu ist, nicht ganz überraschend, besser, obwohl es nicht leicht ist dieses Gefühl in Zahlen auszudrücken. Fakt ist aber auch, dass keine der Distributionen auch nur annähernd das gesamte Potenzial eines drei Jahre "alten" Dual Core Rechners unter durchschnittlichen Bedingungen ausreizen musste.
Für mich funktioniert ein Multi-Boot-System momentan sehr gut. Wer den Aufwand scheut, wird die gleichen Probleme aber sicher auch anders lösen können.