Über ein Jahr ist es her, da beschloss ich auf meinen neuen PC Gentoo zu installieren. Der Grund: Mein neuer PC sollte natürlich am Leistungslimit kratzen - und das geht natürlich nur, wenn man selbst kompiliert. Der Nebeneffekt sollte sein, dass man etwas über das System lernt. Es erschienen auch einige Artikel über Gentoo in diesem Blog. Meine Erfahrungen? Ein Rückblick.
Aller Anfang…
… ist ja bekanntlich schwierig. So auch - erst recht - bei Gentoo. Alles was man hat, ist eine Start-CD. Von da an wird man alleine gelassen. Alles, was ein Installer macht, muss man nun selbst machen. Das ist eine ganze Menge - spontan fällt mir ein:
- Partitionieren
- Partitionen einhängen
- Systemzeit einrichten
- Netzwerk einrichten
- Kopieren des Basissystems
- Grundkonfiguration des Systems
- Konfiguration des Compilers (und Linkers)
- Installation des Bootloaders
- Kompilation der ersten Tools
- USE-Flags, MAKE-Flags etc.
- Neustart
- Grafische Oberfläche und weitere Tools kompilieren
Das hätte ich damals alleine noch nicht geschafft - hier hat mir dankenswerterweise Matze geholfen. Das ganze Prozedere hat auf meinem core-i7-2600K auch noch weit über eine Stunde gebraucht. Puuuh, ist man froh, wenn man durch ist. Leider fehlt immer noch dieses oder jenes, bis das System läuft.
Kleinere Probleme
Networkmanager & NTP
Relativ früh ging es los, dass ich IPv6 einrichten wollte. Dazu wollte ich bei jedem Start meines Systems meine IP bei tunnelbroker.net aktualisieren. Problematisch war aber hierbei immer, dass die Systemzeit sich nicht korrekt stellte. Den genauen Grund kenne ich bis heute nicht (falsche Reihenfolge der Startskripte?), aber im Artikel zu Networkmanager & NTP habe ich immerhin einen Teilerfolg erreicht.
Nervensägen
KMS & Kernel
Kernel-Updates waren eines der größeren Probleme. Irgendwann habe ich angefangen, den Genkernel zu modifizieren - dafür war er nicht ausgelegt, aber es funktionierte - sogar sehr gut, als er irgendwann mal lief. Zwischendurch kam es immer wieder zu Problemen mit dem Kernel-Based Modesetting (KMS), welche aber bis zuletzt verschwanden. Die richtigen einstellungen in der Wiki sind nur die halbe Wahrheit.
X-Updates & Kernel
Auch mit dem Kernel hängt X11 (bzw. X.org) zusammen. Bei jeder Kerneländerung war es Pflicht, X11-Treiber (Kategorie im Portage: x11-drivers/) komplett neu zu emergen. Okay, dauert bei genannter Konfiguration nicht lange. Aber man vergisst es schnell - und schon funktionieren Maus und Tastatur nicht mehr. Die Lösung ist einzeilig:
emerge --oneshot $(qlist -IC x11-drivers/)
Die Option --oneshot (bzw. kurz -1 ) sorgt dafür, dass die neu kompilierten Pakete nicht als manuell installiert gekennzeichnet werden. Das ist wichtig, da die Pakete dieser Kategorie üblicherweise als Abhängigkeit zum X11-Server ihren Weg in das System finden. Entfernt man irgendwann den X-Server, so werden auch diese Pakete entfernt, da sie nur als Abhängigkeit installiert wurden. Damit das so bleibt, nutzt man dieses Flag.
Denkt man an diesen Befehl (bleibt ja etwas in der Bash-History), dann funktioniert auch der X-Server nach einem Kernelupdate. Aber möglicherweise nur dann! :-) Es ist durchaus sinnvoll, diesen Befehl seperat unter /root/bin in ein Bash-Script zu verbannen.
PulseAudio
Ein drittes Ärgernis war, dass bei PulseAudio meine Analogprofile von Zeit zu Zeit verschwanden. Die Lösung war denkbar einfach umgesetzt, aber dennoch ein unnötiges Ärgernis.
Abhängigkeiten: Dependency Hell
Ein großer Unterschied zu einer Binärdistribution, die nicht dem Rolling-Release-Schema folgt, ist die Abhängigkeitsverwaltung. Zwar weiß auch ein Paket unter Gentoo, welche Version einer Bibliothek mindestens benötigt wird. Dennoch sind momentäre unlösbare Zustände im Portage möglich. Oder händische Entscheidungen mehrerer Möglichkeiten. Ich weiß nicht, ob ich das will. Ich will nicht immer wählen müssen. Gibt es keine sinnvollen Standards? Nein, der mündige Benutzer muss bei Gentoo jedesmal selbst entscheiden (oder seine Entscheidung in Form von USE-Flags etc. dokumentieren)!
Ein weit größeres Problem liegt allerdings vor einem, sobald man - wie ich - seit einem Vierteljahr nicht mehr das System komplett aktualisiert hat. Ich hatte zuletzt für mich unlösbare Abhängigkeiten (siehe: Dependency Hell) zu diversen X11-Bibliotheken, so dass ich nur einzelne Programme aktualisieren konnte. Das war für mich kein tragbarer Zustand mehr. Selbst wenn: Die Zeit wollte ich einfach nicht mehr opfern, dort noch mehr Hirnschmalz und Rechenzeit zu investieren.
(K)Ubuntu - der Umstieg
Die Wahl der Distribution
Eigentlich habe ich gar nicht lange überlegt, bis ich zu Kubuntu gegriffen habe. Immerhin habe ich schon einmal mit Ubuntu und seinen Derivaten gearbeitet, andererseits wollte ich weiterhin einen KDE-Desktop benutzen. Und dann waren da noch diese schrecklichen Erinnerungen an das Wirrwarr der RPM-Tools in OpenSuSE. Zur Erinnerung: Unter OpenSuSE gibt es zig Tools, um RPMs zu installieren, darunter: yum, Zypper, apt-rpm (früher), und halt die Einzelpaketversion rpm. Allerdings wurde es inzwischen auf zypper begrenzt, so dass nur noch ein Tool genutzt wird.
Ein weiterer Grund ist, dass wohl Steam irgendwann für Linux erscheinen wird. Da auf jeden Fall Ubuntu direkt unterstützt werden soll, ist die Wahl eines Ubuntu-Abkömmlings eine relativ sicher funktionierende. Das ganze klingt schon sehr vielversprechend. Immerhin läuft Left 4 Dead 2 schneller unter Linux, als unter Windows (vor dem Backport des Patches).
Nebenbei wird ja öfters behauptet, Ubuntu habe mehr Pakete in seinen Repositories als etwa OpenSuSE. Gut, bleiben noch andere Distributionen, wie etwa Mint (welches durch die Wahl des KDE-Desktops faktisch gleich zu Ubuntu ist), oder auch Mageia (welches mir zu unbekannt ist) und auch Fedora, mit dem ich leider auch nur mangelnd gute Erfahrungen hatte. Faul ist der Mensch, ein Kubuntu kommt her.
Ebenfalls wichtig ist die Dokumentation: Die Ubuntuusers-Wiki ist derart umfangreich und gut geschrieben, dass sie bei mir oft vor dem Googlen die erste Anlaufstelle ist. Die Gentoo-Wiki war zum Beispiel weitaus weniger aktuell und wesentlich schlechter verlinkt, unübersichtlicher etc. - ein weiterer klarer Punkt für ein Ubuntu-Derrivat.
Der Wechsel - technische Details
Eigentlich sollte es unter Linux ganz einfach sein, die Distribution zu wechseln: Man überschreibt einfach alles bis auf /home mit dem neuen System, und macht einfach weiter. Soweit die Theorie. Bei mir sollte es also Kubuntu sein. Folgende Schritte führten bei mir zum Erfolg:
- Aufschreiben der Partitionszuordnungen inkl. Größe Man möchte ja nicht ausversehen doch seine Home-Partition mit /var verwechseln ;-)
- Sichern wichtiger Daten »Wie funktionierte die xorg.conf noch einmal genau?«
- Installation des Kubuntu-Systems. Aufpassen, die Partitionen korrekt zuzuordnen - und /home ja nicht zu formatieren!
- Neuen User anlegen ... damit der alte Home-Ordner nicht überschrieben wird. Vorsichtshalber...
- Umbenennen des Users in den alten Benutzernamen
- Anmelden
Der letzte Punkt hat bei mir leider nicht geklappt. Erst, nachdem ich einige KDE-Cache-Verzeichnisse aus meinem /home-Ordner gelöscht hatte, klappte die Anmeldung. Ein verzeihlicher Fehler - da die Anmeldung per Konsole funktionierte, war der Fehler schnell eingegrenzt.
Alle Tools (bis auf KDE) haben meine Einstellungen erfolgreich übernommen. VirtualBox erkennt alle virtuellen Systeme, meine Mails sind nach wie vor lesbar, Firefox erkennt meine Einstellungen.
… oder doch nur Au Revoire?
Was ich vermisse
Bereits jetzt fehlt mir etwas. Und zwar einige Tools, die bei Gentoo im Portage sind, bei Ubuntu aber nicht in den Repositories. Dazu gehört etwa kencfs, eine grafische Oberfläche für encfs - mit EncFS verschlüssele ich etwa Dropbox-Ordner.
Außerdem sind andere Pakete uralt. So ist etwa das freie HDR-Tool Luminance, über das ich auch schon geschrieben habe, hoffnungslos veraltet. Es heißt sogar unter Ubuntu 12.04 noch Qtpfsgui und zählt die Version 1.9.3, während bei Gentoo längst bei Version 2.3 veröffentlicht wurde. Außerdem heißt es dort korrekt "Luminance HDR", und nicht wie bei z.B. getdeb.net nur »luminance«, wodurch es schlecht zu finden ist. Leider klappt die Installation von getdeb.net auch nicht auf Anhieb.
Das Wiedersehen in der VM
»Ade« zu sagen ist so endgültig - warum, wenn es doch die VM gibt und man die Distro weiter nutzen kann (au revoire). Ganz sicher bin ich noch nicht - ich tendiere zu Sabayon als Ersatz. Das hat vielerlei Gründe. Zum einen ist es ein »erweitertes« Gentoo, um Binärpakete. Das heißt, es bleiben die anderen Tools, wie etwa das Portage und emerge, voll funtionsfähig. Andererseits ist das Portage auch nicht der Weisheit letzter Schluss. Es wurde zwar von den FreeBSD-Ports inspiriert, aber weist diesem gegenüber auch einige Nachteile auf. Eines ist die »Dependency Hell«, wie bereits weiter oben erwähnt. Sabayon nimmt aber als Vorteil das riesige Angebot von Ebuilds mit, also Massen von Software. Daher ist es sicherlich einen Blick wert.
Da der Wechsel auf Kubuntu eine gewisse Zeitersparnis bringen sollte, ist der Wechsel von Gentoo auf Sabayon in der VM eine nur konsequente Folge. Wer Nachteile von Sabayon gegenüber Gentoo sieht, den bitte ich dringend um einen Kommentar! Ich folge erst einmal der Masse. Auf Distrowatch steht Sabayon bereits weit über Gentoo.
Ein bisschen Gentoo bleibt: Selbst kompilieren
Auch Ubuntu/Kubuntu lassen sich durchkompilieren, ähnlich emerge -avuDp world . Der Trick heißt: apt-build. Es kompiliert alle Pakete oder eine Auswahl (wie emerge) und installiert diese dann. Dazu wird ein lokales Repository, sowie apt-pinning benötigt, um diesem Vorrang zu gewähren. Außerdem kann man ähnlich der /etc/make.conf seine Prozessorflags setzen. Der Geschwindigkeitsvorteil ist möglicherweise bei rechenintensiven Anwendungen wie x264 bemerkbar.In den Kommentaren eines Artikels von 2007 wird heftig über apt-build diskutiert. Eine etwas »sauberere« Anleitung findet sich auf AskUbuntu.com. Nach einem kurzen Test mit Gedit kann ich immerhin die Grundfunktionalität bestätigen.
Ausblick
Für diesen Blog hat mein Distributionswechsel sicher ein paar, aber nicht übermäßige Auswirkungen. Unter Gentoo habe ich noch viele Artikel zunächst auch in der virtuellen Maschine mit Ubuntu getestet, aber den Aufwand möchte ich mir jetzt sparen.
Alles in allem war es aber die Erfahrung wert, Gentoo als Hauptsystem einzusetzen. Man lernt unglaublich viel über den logischen Aufbau eines Linuxsystems, den Kernel (und wie man ihn kompiliert) sowie andere systemnahe Dienste, die einem sonst oft verborgen bleiben. Das Artikelbild ist natürlich viel zu reißerisch gewählt. Es geht nicht um einen Vergleich, sondern um persönliche Präferenzen.
Weblinks
Viele Themen wurden angesprochen, nicht alle interessanten Links im Text gesetzt. Hier sind noch weiterführende Links zu den angerissenen Themen:
- Valves Steam on Linux Blog http://blogs.valvesoftware.com/linux/
- Distrowatch, eine Übersicht über Distributionen und deren ungefährer Beliebtheit. http://distrowatch.com/
- Virtualbox in der Ubuntuusers-Wiki http://wiki.ubuntuusers.de/VirtualBox
- Weitere Anmerkungen zu Apt-Build: http://chronosbox.org/blog/compilando-facil-com-debianubuntu?lang=en
- KDE 12.04.1 Desktop amd64 als Torrent direkt laden: http://cdimage.ubuntu.com/kubuntu/releases/12.04/release/kubuntu-12.04.1-desktop-amd64.iso.torrent
- Sabayon 10 amd64 mit MATE-Desktop als Torrent: http://static.sabayon.org/sabayon/torrents/Sabayon_Linux_10_amd64_MATE.iso.torrent
- Gentoo Linux Packages http://packages.gentoo.org/
- Ubuntu Paketsuche http://packages.ubuntu.com/
- Luminance HDR (ehemals Qtpfsgui) für Hochkontrastbilder aus Belichtungsreihen http://qtpfsgui.sourceforge.net/