Leider habe ich bis jetzt noch keine Zeit gefunden, mein schon länger angedachtes Multimediaprojekt in die Tat umzusetzen. Es wird definitiv kommen, nur später. 😉 Zuerst möchte ich die ganzen Artikel, die ich zum Thema "alte Computer", leichtgewichtige Software und Konsolenanwendungen schreibe in einer größeren Howto-Seite bündeln, damit es einfacher wird schnell das Wesentliche zu finden.
Mein Ziel ist es, irgendwann eine Übersichtsseite zu haben, wo man eine Debian-Netzinstallation Schritt für Schritt nachvollziehen kann und sich je nach eigenem Interesse und Wunsch das eigene Desktopideal mit Debian zusammenbasteln kann. Aus eigener Erfahrung weiß ich, dass Debian sich schon mit 64 MB RAM auf einem 12 Jahre alten Laptop mit dieser Methode zufrieden gibt und gleichzeitig diese so flexibel ist, dass man damit sowohl ein modernes, minimales System für Spiele oder eine verschlüsselte Arbeitsumgebung auf einem modernen Dual Core Rechner installieren kann.
Die passende Software, mit der sich das alles realisieren lässt, bekommt eine Extraseite und wird kurz vorgestellt und Howtos zu bestimmten Themen damit verlinkt. Sofern es die Zeit zulässt erscheint später dann ein vergleichbarer Guide auch für die Rechner mit weniger als 64 MB RAM. Distributionen wie Slitaz machen es einfach selbst solche Oldies noch produktiv nutzen zu können.
Meiner Meinung nach liegt es nicht an Linux, dass ein bekanntes Vorurteil heißt, Linux sei nur was für Geeks. Ich glaube auch nicht, dass Linux nur aus Extremen besteht. Vielmehr ist für jeden etwas dabei. Ich hoffe, es gelingt mir am Ende zu zeigen, dass man vollkommen generisch mit der gleichen Methode sich praktisch seine eigene Linuxdistribution erstellen kann unabhängig von der Leistungsfähigkeit des eigenen Rechners.
Was bedeutet eigentlich alter Rechner? Wirf es weg, nur weil das neuste Spiel nicht mehr flüssig darauf läuft? Was vor 15 Jahren mit einem Bruchteil der Rechenpower funktionierte, wird heute belächelt und als Schrott und Hobby für Nostalgiker abgetan. Dabei ist es gar nicht so schwer sich vorzustellen, was in 15 Jahren einmal sein wird. USB 3.0 ist ein alter Hut. Viel zu langsam um die weiter gestiegenen Datenmengen adäquat noch zu beherrschen. SSD sind mittlerweile so günstig, dass sie im dreistelligen TB Bereich für weniger als 50 Euro zu haben sind und schon wieder ein Auslaufmodell sind. 100 GB RAM ist schon lange nichts Besonderes mehr und Petabyte verdrängt Terrabyte als Schlagwort für Speicherplatzgrößen.
Für mich ist vollkommen klar, dass in 15 Jahren heutige Rechner genauso belächelt werden wie die alten Kisten zuvor. Die Frage ist, ob man nicht genauso gut wie heute Aufgaben damit erledigen kann? Wir werden sehen. Anpfiff für die zweite Halbzeit!
Die Mozilla Foundation legt offenbar einen Zahn zu und hat sich von dem längeren Entwicklungszyklus zwischen zwei Firefox Versionen verabschiedet. In Zukunft erscheinen kleinere Updates nun regelmäßiger, enthalten dafür aber weniger umwälzende Änderungen.
Debians umbenannte und von problematischen Markenrechten befreite Firefox Version namens Iceweasel, befindet sich ebenfalls auf dem aktuellen Stand und wird von den Paketverwaltern auf http://mozilla.debian.net gepflegt. Update 17.08.2011: Für Iceweasel 6 und hoffentlich auch alle kommenden Versionen, habe ich die Installation hier noch einmal übersichtlicher zusammengefasst. Ansonsten gilt das hier Geschriebene. Die Installation gestaltet sich ähnlich einfach wie bei einem Ubuntu PPA. Update 07.07.11: Vielen Dank an Simon, der in den Kommentaren auf das neue Versionsschema von Iceweasel in der sources.list hingewiesen hat. Im Blog des Debian Paketverwalters für Iceweasel wurde heute angekündigt, dass Iceweasel als Release Version (5.0), Beta (6.0) und Aurora (7.0) in Zukunft zum Download bereitsteht. Für den 15. Juli kündigte er auch an, dass Iceweasel 5 direkt für Debian Unstable ohne den Umweg über den mozilla.debian.net Spiegel oder Experimental verfügbar sein wird. Wann allerdings der Browser in dieser Version für Testing zur Verfügung stehen wird bleibt vorerst ungewiss, da zuvor erst alle Paketkonflikte aufgelöst sein müssen. Für alle, die wie ich gerne mit der aktuellen Iceweasel Version browsen, geht es wie folgt am einfachsten.
mozilla.debian.net in sources.list freischalten
Für Debian Unstable und Testing lautet der Eintrag in der /etc/apt/sources.list
Für Iceweasel Release: Ist nun in Unstable bzw. Testing Für Iceweasel Beta deb http://ftp.de.debian.org/debian experimental main Für Iceweasel Aurora deb http://mozilla.debian.net/ experimental iceweasel-aurora Schlüssel importieren für mozilla.debian.net (gilt für alle Debian Versionen) Wie bei Debian üblich werden alle Pakete mit gpg vom Paketverwalter signiert. Der Schlüssel zur Verifikation lässt sich mit root Rechten so importieren.
Die APT Quellen updaten aptitude update Iceweasel für Debian Unstable und Testing installieren aptitude install -t experimental iceweasel
Debian Stable alias Squeeze
Es ändert sich nur der Eintrag in der sources.list und der Installationsbefehl. Release (5.0): deb http://backports.debian.org/debian-backports squeeze-backports main deb http://mozilla.debian.net/ squeeze-backports iceweasel-release Beta (6.0): deb http://backports.debian.org/debian-backports squeeze-backports main deb http://mozilla.debian.net/ squeeze-backports iceweasel-beta Aurora (7.0): deb http://backports.debian.org/debian-backports squeeze-backports main deb http://mozilla.debian.net/ squeeze-backports iceweasel-aurora Installation aptitude install -t squeeze-backports iceweasel Wer auch zukünftig schnell in den Genuss der neusten Firefox/Iceweasel Version kommen möchte, sollte mozilla.debian.net in der sources.list eingetragen haben. Iceweasel 5.0 reagiert besser und rendert Seiten fühlbar schneller als das derzeitige Iceweasel 3.5.19 in unstable. Der Nachteil: Außer Englisch stehen momentan keine weiteren Sprachpakete zur Auswahl und das Addon "Torbutton" funktioniert mit Firefox/Iceweasel 5 leider auch nicht mehr. Update 24.06.2011 Im Blog des Debian Paketverwalters für Iceweasel und Icedove konnte ich heute den Tipp lesen, wie man ganz leicht deutsche Sprachunterstützung erhält. Wie ein Kommentator schon treffend bemerkte wird dadurch aus Iceweasel in Teilen wieder Firefox. Nehmt es mit einem Lächeln. Deutsch ist für den Paketverwalter nicht die einzige Sprache, die er als Paket zur Verfügung stellen muss. 😉 1. Es muss lediglich die Sprachdatei von Firefox installiert werden. Für Deutsch ist das de.xpi. http://releases.mozilla.org/pub/mozilla.org/firefox/releases/ In Iceweasel genügt ein Klick auf die Datei de.xpi und die Sprachdatei wird installiert. Auf einem System mit voreingestellter deutscher Spracheinstellung sind keine weiteren Schritte nötig. Ansonsten noch folgendes erledigen: 2.about:config in die Adresszeile von Iceweasel eingeben 3. Suche nach general.useragent.locale und ändere es von en-US zu de-DE Update 04.07.2011 Torbutton ist seit dem 30.06. aktualisiert worden und kann beim Torprojekt heruntergeladen werden.
Zu meiner Openbox-Einführung habe ich das Lxpanel als Standardpanel empfohlen, da es für mich dem klassischen Design am nächsten kommt und die Eingewöhnungsphase kurz ist. Auf der anderen Seite ist Tint2 eine ebenso gute, wenn nicht sogar bessere, Option. Tint2 sticht insbesondere durch geringen Speicherverbrauch und wenige Abhängigkeiten mit anderen Paketen hervor. Das Aussehen ist elegant und unkompliziert. In der Voreinstellung des vorgestellten Crunchbang Linux befindet sich das Panel z.B. am unteren Bildschirmrand. Geöffnete Anwendungen werden direkt auf den virtuellen Arbeitsflächen angezeigt, die das Panel aufteilen. Rechts davon befinden sich die "Tray Icons" laufender Programme und daneben dann die Uhr. Positionierung, Farbgestaltung, Größe und das gesamte Aussehen lassen sich über eine einzige Konfigurationsdatei manipulieren, die ~/.config/tint2/tint2rc. Die Dokumentation ist gut und die letzten Fragen werden durch die FAQ beantwortet. Mit Tint2 wird ein kleines grafisches Installationsprogramm namens tint2conf für das Einrichten der .tint2rc mitgeliefert. Beispiele finden sich bei Debian in /usr/share/doc/tint2/examples oder direkt auf der Entwicklerseite zum Download. Ein paar Beispiele: Mit tint2conf nimmt man schnell die erste Hürde beim Ausprobieren. Genug Beispiele finden sich überall im Netz z.B. auch im Crunchbang Forum. Tint2 wurde zwar für Openbox 3 entwickelt, lässt sich aber auch mit anderen Fenstermanagern kombinieren. In Openbox genügt lediglich der Eintrag tint2 & in die ~/.config/openbox/autostart.sh. Tint2 ist leicht,elegant und effizient. Ich mags.
Ich gehöre zu denjenigen, die an ein Musikprogramm nur eine wirkliche Anforderung stellen: Es muss Musik abspielen können. Darüber hinaus hätte ich gerne Funktionen für Playlist, Pause, Vor- und Zurückspulen, Shuffle und Wiederholung. Zwar sind Datenbanken, um die Lieder nach id3 Tags zu sortieren, nett und nützlich. Dennoch hätte ich gerne auch die Möglichkeit meine im Dateisystem schon geordneten Musikdateien auszuwählen und zwar dort, wo ich sie auch abgelegt habe! Mein Weg zum passenden Musikprogramm war lang. Angefangen hatte ich im letzten Jahrtausend noch mit Windows und Winamp, bis es sich irgendwann entschied in eine schwerfällige Grässlichkeit namens Winamp 3 mit eingebauten Videoplayer zu mutieren. Mit Linux ging es dann nicht zufällig mit XMMS und später Audacious weiter. Zu KDE-Zeiten kam ich an Amarok natürlich nicht vorbei, bis schließlich mit Ubuntu Rhythmbox und seit 11.04 nun Banshee Einzug hielt. Um so mehr ich meine älteren Laptops benutzt habe, desto mehr fiel mir auf, was ich eigentlich von guter Software erwartete und an der bestehenden vermisste. Sie musste schnell auf Eingaben reagieren, kein Warten, nur weil ich die Ansicht in einem Programm ändere. Sie sollte genügsam mit Systemressourcen umgehen. Wenn schon eine Datenbank für Musik, dann sollte diese schnell synchronisiert und eingelesen sein. Ich wollte Musik hören. Um die Verwaltung meiner Musiksammlung kümmere ich mich selbst. Viele Anwendungen gehen einen anderen Weg. Das geht soweit, dass die Suche nach Musik in Musicstores und das Brennen von Audiodateien in den Vordergrund gerückt wird und Musik hören selbst zur Nebensache wird. Deshalb verschwand irgendwann Rhythmbox und wurde durch den Music Player Daemon (mpd) und einen Client wie Ario, Sonata oder ncmpc ersetzt. Mittlerweile dient der zwölf Jahre alte Toshiba Portégé 3110 CT problemlos als MPD-Server. Dann kam die Zeit, wo ich mit MOC und C*mus experimentierte und mit dem letzteren das Musikprogramm gefunden hatte, welches alle Kriterien guter Software zum Musikabspielen erfüllte. Egal ob es der Laptop aus dem letzten Jahrtausend oder der (mittlerweile schon wieder LowEnd :roll:) Intel Dual-Core-Rechner ist, Musikabspielen war nie einfacher, nie schneller und nie reaktionsfreudiger.
Banshee vs. cmus
Ich kann gut nachvollziehen, warum nun nicht jeder sofort jubelnd seinen aufgeblasenen Player von der Platte tilgt. Eine grafische Oberfläche bietet etwas fürs Auge. Nicht jeder lässt sich von der Tatsache begeistern, dass cmus auch ohne X auf der nackten Konsole die gleiche Funktionalität und Performance zeigt und ich mir nicht extra einen neuen PC für das Programm kaufen muss. Es gibt viele gute Gründe ein anderes Musikprogramm zu wählen: "Ich mag es", "Ich brauche die Dinge, die du für überflüssig hältst", "Ich nutze das Programm, weil ich es kann?!" Dem kann ich nichts entgegensetzen. Doch wenn du an den Punkt kommst, wenn dein Rechner vor lauter Kraft nur noch in den Swap-Speicher schreibt oder du einfach nur Musik hören möchtest, dann lass dich verzaubern vom Charme und der Schönheit des Schlichten!
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:
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.
Eine kleine Erinnerung für alle, die nicht auf Gnome 3 oder Iceweasel 4 warten können. Genau vor einem Monat hatte ich einen Blick auf Gnome 3 geworfen und dabei schon auf das Blog von Raphael Hertzog, einem Debian Entwickler, verlinkt, der erklärt wie sich Gnome 3 aus Debian Experimental mittels Apt-Pinning installieren lässt. Schon am 18.04. hat er einen aktualisierten Beitrag veröffentlicht, der auch ein paar Fragen zu häufigen Problemen mit Gnome 3 beantwortet. Dank einer neuen Version von apt ist mittlerweile auch die APT-Pinning Datei etwas kürzer geworden. Den Status von Gnome 3 in Debian kann man am besten auf dieser Seite verfolgen. Zur Zeit befinden sich 30 von 118 für Gnome relevante Pakete in Debian unstable. Der überwiegende Teil ist aber weiterhin in Experimental. Iceweasel 4.0 befindet sich zur Zeit ebenfalls noch in Experimental, lässt sich aber auch schon je nach Debian Version installieren und produktiv nutzen. Wie es geht, erklärt ein schicker Guide auf http://mozilla.debian.net/. Man muss lediglich auswählen, welches Debian man selbst verwendet und welches Iceweasel oder Icedove man haben möchte und schon gibt es eine kurze Erklärung. Für den Fall, dass man sowieso schon Debian Unstable auf einem PC/Laptop benutzt, muss lediglich
deb http://ftp.de.debian.org/debian experimental main
in die /etc/apt/sources.list eingetragen werden. Mit aptitude install -t experimental iceweasel wird danach Iceweasel 4.0 aus Experimental installiert.
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.
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.
Erneut bin ich im Blog von Raphaël Hertzog auf ein zur Zeit heiß diskutiertes Thema gestoßen. CUT oder Constantly Usable Testing ist die Idee, Debians Testing Zweig zu einem echten Rolling Release umzuwandeln und wenn möglich sich als Debians zweites Standbein neben Stable zu etablieren. Zur Zeit ist es noch so, dass Testing vor allem dazu dient Bugs vor der nächsten Veröffentlichung von Stable auszumerzen. Schon heute bringt Testing die richtigen Werkzeuge mit, um fortlaufend aktuelle Software aus dem unstable Zweig zu beziehen. Im Gegensatz zu Stable ist Debian Testing deshalb vor allem für Anwender interessant, die an einer Balance zwischen Stabilität und regelmäßigen Updates mit neuen Feature interessiert sind. Die Idee Debians starren Zyklus von Veröffentlichungen zu durchbrechen ist nicht neu. Gerade aus diesem Grund hat es Ubuntu geschafft viele Anwender für sich zu begeistern. Raphaël Hertzog hat in seinem Blog unter dem Schlagwort CUT und in einem Artikel auf lwn.net seine Vorstellungen von einem verbesserten Debian Testing dargelegt. Zur Zeit wird intensiv auf der Debianentwickler-Mailingliste die Vor- und Nachteile eines solchen neuen Rolling Releases diskutiert. Insbesondere soll der sogenannte "Freeze" vermieden werden und Sicherheitsupdates für Testing schneller bereitgestellt werden. Das größte Problem scheint momentan zu sein wie man weiterhin sicherstellt, dass aus Testing/Rolling das nächste stabile Debian Release wird. Zur Zeit wird Testing irgendwann eingefroren und nur noch Fehler werden bei den bestehenden Paketen ausgebessert. Durch diese Methode erreicht Debian die extrem hohe Stabilität und Qualität seiner Distribution. Ein Rolling Release sollte idealerweise nie eingefroren sein und fortwährend neue Pakete erhalten. Als Alternative bietet sich aber auch an, ein solches Rolling Release zu einem bestimmten Zeitpunkt in eine eingefrorene Version abzuspalten, welche dann bis zur Fertigstellung parallel zum neuen Rolling betreut und als neues Debian Stable veröffentlich wird. Lucas Nussbaum hat den momentan Verlauf der Diskussion in seinem englischen Blog zusammengefasst. Das Ganze ist zur Zeit, wie man so schön sagt, im Fluss. Das Faszinierende an Debian ist, dass es durch eine Gemeinschaft weiterentwickelt wird. Solche potentiellen und gravierenden Änderungen werden deswegen vorher ausführlich auf Mailinglisten besprochen. Ich persönlich denke, dass Debian Testing allemal das Potenzial zu einem Rolling Release hat und für mich auch schon ist. Das Problem ist zum einen, dass Debian den Testing Zweig nicht als Rolling Release kommuniziert, obwohl andere Distributionen, wie z.B. das Debian-Derivat Linux Mint Debian, damit offensichtlich kein Problem haben. Testing ist in Debians Fachsprache "nur" die Plattform um RC-Bugs für die kommende stabile Version zu beseitigen. Wie Lucas Nussbaum in seinem Blog geschrieben hat, glaube ich, dass CUT ein Schritt sein könnte um Debian wieder mehr in das Rampenlicht zu rücken, das momentan einige Derivate für sich in Anspruch nehmen. Ich konnte zum Beispiel kaum einen Grund finden, warum man als Debian Testing Nutzer zur Zeit LMDE bevorzugen sollte. Wie so oft hat alles Vor- und Nachteile. Der technische und logistische Aufwand für eine solche Umstellung ist natürlich nicht trivial. Trotzdem würde ich mich freuen, wenn es dazu kommen würde.
Scheinbar bin ich nicht der Einzige, der die alten Gnome Applets im Panel vermisst. Es gibt schon verschiedene Projekte auf launchpad.net, die versuchen das alte Gefühl zurück in das Panel von Unity zu bringen.
Es gibt für indicator-sysmonitor ein Deb-Paket, welches sich nach dem Herunterladen mit einem simplen Doppelklick installieren lässt. Der Multiload-Indikator ähnelt und verhält sich auch so wie das alte Gnome-Applet. Lediglich Tooltips, die den zugehörigen Zahlenwert zeigen, fehlen noch. Der Sysmonitor hingegen ist recht schlicht. Die Anzeige von CPU-Auslastung und Speicherverbrauch genügen mir aber schon. Wie immer gilt der übliche Haftungsausschluss. Bei beiden Programmen handelt es sich nicht um offiziell unterstützte Software. Fehler können natürlich jederzeit auftreten. Ich kann mit beiden Applets gut leben. Trotzdem halte ich gerne die Anzahl der zusätzlichen Softwarequellen gering. Wichtig ist mir ein PPA nur für Wine, die neusten Nvidia-Treiber oder für Openshot und Blender, wenn es um Videobearbeitung geht.
Conky
An Alternativen mangelt es nicht. Conky gibt es auch schon viele Jahre und stellt als Systemmonitor praktisch jede erdenkliche Information zur Verfügung.
aptitude install conky
Die globale Konfigurationsdatei befindet sich in /etc/conky/conky.conf und sollte am besten für den normalen Nutzer nach ~/.conkyrc kopiert werden. Zur individuellen Konfiguration von Conky lassen sich wahrscheinlich ganze Bücher füllen. Wer es deshalb einfach mag, muss die Standardkonfiguration aber nur an zwei Stellen anpassen und erhält das Ergebnis auf dem folgenden Screenshot.
Die zweite Zeile muss hinzugefügt werden. Dadurch erscheint es, als ob conky direkt auf dem Desktop liegen würde. Damit conky auch jedes Mal beim Systemstart angezeigt wird, muss es als Startprogramm unter Systemeinstellungen->Startprogramme hinzugefügt werden. Als Befehl genügt conky. Die Systemeinstellungen befinden sich neuerdings oben rechts, wenn man auf den Ausschalten Knopf klickt. 🙄 Auf das Wesentliche reduziert könnte Conky auch wie im folgenden Bild aussehen. Die Ausgabe wurde auf RAM und CPU beschränkt. Mit der Option double_buffer yes verschwindet zwar das Flackern, wenn man own_window no gesetzt hat und somit den Fensterrahmen um conky vermeidet. Nautilus wehrt sich aber dagegen und zeigt danach keine Bilder mehr auf dem Desktop an. Die Position der Ausgabe lässt sich mit den Optionen gap_x und gap_y ändern. Im Netz existieren wahre Conky-Kunstwerke. Wer mit dem Ergebnis nicht zufrieden ist, findet mit einer Suche nach conkyrc schnell viele weitere Beispiele. Mehr Informationen zu conky und mögliche Problemlösungen gibt es auf ubuntuusers.de Meine Mini-Conkyrc:
alignment bottom_right
background no
border_width 1
cpu_avg_samples 2
default_color white
default_outline_color white
default_shade_color white
draw_borders no
draw_graph_borders yes
draw_outline no
draw_shades no
use_xft yes
xftfont DejaVu Sans Mono:size=12
gap_x 735
gap_y 419
minimum_size 5 5
net_avg_samples 2
no_buffers yes
out_to_console no
out_to_stderr no
extra_newline no
own_window yes
own_window_transparent yes
own_window_class Conky
own_window_type desktop
stippled_borders 0
update_interval 1.0
uppercase no
use_spacer none
show_graph_scale no
show_graph_range no
TEXT
${color grey}RAM:$color $mem/$memmax
${color grey}CPU:$color $cpu%
Obwohl ich nicht rundherum zufrieden mit Ubuntu 11.04 bin, gibt es dennoch gute Gründe, warum es sich trotzdem lohnt Natty als Videoschnittplatz einzusetzen. Zu allererst lässt sich Ubuntu schnell und einfach installieren und wenn man sich mit den Voreinstellungen und Eigenheiten von Unity anfreunden kann, ist Ubuntu auch nicht schwer zu konfigurieren. Als erstes habe ich alle Programme entfernt, die ich zur Erstellung von Videos nicht brauchen werde. Deshalb sind sowohl Evolution, Empathy und Gwibber als auch LibreOffice erst einmal verschwunden. Anstelle von Firefox nutze ich Chromium, was nichts mit der Qualität von Firefox zu tun hat, sondern damit, dass der Fuchs schon auf dem parallel installierten Debian-System läuft und ich mir gerne die Vor- und Nachteile der verschiedenen Browser anschaue. Das Briefsymbol auf dem Panel, das Paket indicator-messages, habe ich schließlich ebenfalls deinstalliert, Chat und Email-Benachrichtigungen brauche ich hier nicht und auf Ubuntu One lässt sich im Startmenü schon zugreifen. Womit wir bei meiner momentanen Softwareauswahl für kleinere Videoprojekte angekommen wären:
Ich denke, das sollte für den Anfang reichen. Kino und Stopmotion sind als Alternative bzw. Ergänzung zu Openshot gedacht. Damit sind die wichtigsten Programme aus dem Beitrag zu Ubuntustudio 10.10 in meiner Natty Installation enthalten. Ubuntustudio bietet auch Unterstützung für einen Echtzeitkernel an, der speziell für Audioaufnahmen geeignet ist. Ich denke für Heimprojekte zur Videobearbeitung brauche ich ihn erst einmal nicht. Inwiefern noch zusätzliche Treiber und Einstellungen notwendig sind, die Ubuntustudio schon standardmäßig anbietet, welche aber in Ubuntu 11.04 fehlen, werde ich mit der Zeit herausfinden. Das Wiki von ubuntu.com listet noch ein paar Ideen und Workflows auf, die sich im Zusammenhang mit Video- und Audiobearbeitung ergeben. Der Eintrag ist nicht vollständig, aber beim Durchstöbern sollte ich für meine Zwecke alle wichtigen Programme erwischt haben. Besonders praktisch finde ich bei Ubuntu die Möglichkeit, mit dem Synchronisationsdienst Ubuntu One alles automatisch mit der "Cloud" abzugleichen. Beim Backup wichtiger Konfigurationen oder Plugins von einzelnen Programmen wie z.B. Gimp, muss ich mir deshalb keine grauen Haare wachsen lassen. Bleibt noch festzuhalten, dass ich genauso wie schon bei Ubuntu 10.10 Openshot und Blender aus einem PPA installieren musste. Um animierte Intros oder Schriften zu erzeugen, benötigt Openshot die Blender Version >=2.5. Natürlich war Blender auch bei Natty Narwhal noch auf Stand 2.49. Die Installation aus dem PPA ist aber kinderleicht. Wie es geht, habe ich schon hier beschrieben. Jetzt fehlt nur noch das Material und Ideen für den großen Durchbruch auf Youtube. 😉
