Review: Gentoo Linux
Verfasst: Dienstag 2. Oktober 2007, 18:12
Hallo,
nachdem ich schon das kurze Arch Linux-Review geschrieben habe, gibt es nun heute meine Erfahrungen mit Gentoo Linux.
Gründe für Gentoo
So viele Gründe für Gentoo wie die Gentoo-User gerne sagen gibt es nicht. Ich würde sogar dahin gehen und sagen, dass der Durschschnitts-Linux-Nutzer mit Gentoo eher schlecht beraten ist. Meine Gründe waren die große Anpassbarkeit an die eigenen Bedürfnisse sowie die angeblich hohe Performance. Den Lerneffekt sollte man auch nicht außer acht lassen. Nachteil sind natürlich die Kompilationszeiten, wobei hier noch ``distcc`` einen Versuch wert ist.
Ein anderer Grund ist der angeblich so tolle Support in den Gentoo-Foren. Praktisch ist, dass das mehrsprachige Foren sind die unglaublich viele angemeldete User haben ansonsten habe ich bisher keine Probleme dort erörtern müssen, die ich nicht hätte selbst lösen können (oder bei denen mir das Wiki oder auch birkenfeld nicht hatten helfen können)
Hardware
Hat sich seit dem Arch Linux-Review nicht geändert. Ich habe aber inzwischen eine USB-Maus angeschlossen Der Wrong PCI ID Vendor-Bug ist immer noch nicht behoben, aber ich fahre gerade mit ``pci=conf1`` hoch, das funktioniert auch ganz gut.
Nachdem ich jetzt aber jahrelang x86-Linux genutzt hatte (auch das Arch im Review davor war ein 32-Bit Linux, obwohl es einen 64-Bit Port gibt), dachte ich mit dass ich das EM64T meines Core 2 mal ausnutzen kann und wählte diesmal den amd64
Installation
Die Installation von Gentoo Linux 2007.0 verläuft bei weitem nicht so schnell wie die von Arch. Man könnte sagen, dass Gentoo einen Rekord bei der Installationslänge aufstellt. Das liegt aber zum großen Teil daran, dass es schlichtweg keinen Installer gibt und man die Installationsanweisung (die eigentlich ziemlich gelungen ist) abarbeitet. Das hat den Vorteil, dass das ganze dadurch sehr flexibel ist und den Nachteil, dass man ohne die Anleitung auch mal Dinge übersehen kann.
Das es keinen Installer gibt, ist mehr oder weniger falsch - es gibt auf der LiveCD einen grafischen Installer. Aber ich habe die Minimal-CD benutzt und außerdem läuft bei mir der freie X11-Treiber nicht mit meiner Grafikkarte. Noch dazu fehlt einem das Gentoo-Feeling, dann erinnert es eher an den Ubuntu-Installer.
Software-Konfiguration
Ich hatte einige Bedenken was den proprietären ATI-Treiber angeht, weil der bei meinem letzen Gentoo-Versuch (auf x86) ziemlich schlecht lief. Jedoch war es diesmal kein Problem, inzwischen habe ich die ``make.conf`` auch so eingestellt, dass X11 automatisch den richtigen Treiber mitinstalliert und nicht sinnlos irgendwelche anderen Treiber mitzieht. Als ich X.org das zweite mal kompiliert hatte, habe ich auch den Synaptics-Treiber zum laufen bekommen, mit dem ich mein Touchpad genauer einrichten konnte. Funktioniert bisher Klasse (habe unter Arch auch mal die Clickwheel-Funktion angetestet, aber leider ist das nicht für produktiven Einsatz sinnvoll).
Da ich immer noch GNOME-Nutzer bin, habe ich mir GNOME installiert, was aber vergleichsweise lange zum kompilieren brauchte so dass der Laptop mal über Nacht an blieb.
Das war etwa der erste "Wow"-Moment: So wie GNOME unter Arch vergleichen mit Ubuntu schnell ist, so setzt das GNOME unter Gentoo da locker noch etwas drauf (ich habe Ubuntus GNOME 2.14.x mit jeweils 2.18.3 verglichen). Es ist wirklich schnell: ich würde es von der Performance mit einem frisch installiertem Windows 2000 vergleichen. Damit kann man dann schon sehr anständig arbeiten.
Nett finde ich, dass ich unter Gentoo problemlos MP3-Dateien abspielen kann, ohne irgendwelche zusätzlichen Pakete installieren zu müssen. XviD funktioniert bisher noch nicht, aber ich denke dass das auch hinzubekommen ist (gst-plugins-bad sind leider masked und die enthalten das XviD-Plugin). Das System-Menü in GNOME ist besser ausgestattet als das in Arch jedoch musste ich bei einem Applet einen kleinen Berechtigungs-Bug beheben.
Im Gegensatz zu vielen anderen Systemen bekommt man unter Gentoo auch den Firefox als Firefox und nicht als Firedove oder Bon Echo: aber auch dafür gibt es ein entsprechendes USE-Flag.
Was die Programaktualität angeht hinkt Gentoo etwas nach und ist etwas hinter Debian Testing, zumindest was das "stable" Gentoo betrifft. Das unstable ist mit Testing vergleichbar, aber so aktuell brauche ich die Pakete gar nicht. Aber man kann auch testing-Pakete in Gentoo ohne weitere Probleme installieren.
Ich habe natürlich auch wieder das gleiche Cursortheme installiert wie unter Arch, was genauso simpel ging und auch einen anderen GDM-Splash (Blue Swirl) welcher noch trivialer einzurichten war. Die GNOME-Integration ist gelungen, das GNOME-Overlay ist schon fast vollständig auf GNOME 2.20.0 aktualisiert und wird sich wohl nach einiger (wohl langer) Testphase in Portage finden.
Hardware-Konfiguration
Zuerst lief Sound gar nicht, da in dem Standardkernel den ich mit den Einstellungen des LiveCD-Kernels gebaut habe keine ALSA-Unterstützung dabei war. Wie ich es von Arch wusste habe ich das Modul ``snd-hda-intel`` verwenden können um die Azalia-Karte verwenden zu können. In den Standardeinstellungen funktionierte Autosensing der Ausgänge Leider nicht, so dass die Lautsprecher auch mit eingesteckten Kopfhörern/Stereoanlage noch an waren. Ließ sich aber mit dem Parameter ``model=hippo`` für die Realtec ALC262 ziemlich gut beheben. Hat nur lange gedauert das herauszufinden.
Ähnlich sah es leider auch mit den ATI-Treibern aus: bei bestimmten Kernel-Einstellungen führen sie zum Freeze - ich habe letztendlich herausgefunden, dass ich die Einstellung von 8 CPUs nicht auf 2 CPUs setzen darf, sonst geht es nicht. Ansonsten habe ich die gröbsten Optimierungen etwa Core 2-Optimierter Code, Preemptiven Kernel + Lock, und den Timer beschleunigt. Viel hat es nicht gebracht aber nun bin ich zumindest was die ATI-Treiber angeht schlauer.
USB-Hotplug funktioniert mit HAL und GNOME ziemlich gut. Allerdings musste ich den Eintrag des CD-ROM -Laufwerkes aus der ``/etc/fstab`` rausnehmen, da ich sonst Fehlermeldungen bekam. Das Einbinden von Massenspeichern wie meinem USB-Stick oder meinem Mediaplayer funktioniert klasse und wenn man die Volumes unmountet, wird extra gefragt, ob man den Trash-Order auf dem Volume leeren will (ansonsten bleibt der drauf - so kann man sogar drei verschiedene Trash-Order haben: XP, Vista, GNOME). Ist eine Kleinigkeit, aber da hat jemand drangedacht.
Probleme
Es ist natürlich nicht so, dass alles bei Gentoo unproblematisch ist, wobei ich zugebe, dass ich mir alles schlimmer vorgestellt habe. Von dem CD-ROM Mount-Problem habe ich schon berichtet. Auch die Umstellung des System auf ein locale und UTF-8 war nicht ohne Probleme. So habe ich es gerne wenn mein System zu mir in Englisch spricht - das Datumsformat sollte aber dennoch deutsch bleiben. Nachdem ich den Fehler gemacht hatte, in ``/etc/env.d/02locale`` die Variable ``GDM_LANG`` zu setzen hat es mit folgenden Inhalt geklappt:
Dummerweise zeigt die GNOME-Uhr die Zeit momentan im Format "Mi Okt 3" an wohingegen ``date`` korrekt "Mi 3. Okt" anzeigt.
Dabei habe ich immerhin den Unterschied zwischen ``LANG`` und ``LC_ALL`` verstanden, weil das im deutschsprachigen Wiki gut erklärt ist.
Ein weiteres Problem war die Tastatur (auch in Arch hatte ich ein Tastatur-Problem, aber ein anderes) - die Taste mit der Pipe und den Größer/Kleiner-Zeichen ging einfach nicht. Aber nachdem ich in der xorg.conf die Tastatur von ``pc104`` auf ``pc105`` geändert habe und diese Änderung auch von GNOME bemerkt wurde funktioniert sie sehr gut.
Weitere Optimierungen betreffen die zu bauenden Module: ich habe in der Kernelkonfiguration viele Module rausgenommen, weil sie beim booten unnötig geladen wurden. Letztendlich gibt es in der Datei ``/usr/share/genkernel/<arch>/modules_load`` eine Datei die die zu ladenden Module auflistet. Naja, zumindest baut sich der Kernel nun schneller und es ist unwarscheinlich dass ich plötzlich Unterstützung für OHCI bräuchte. Was mir bisher noch nicht ganz klar ist wozu mdev statt udev beim booten startet, da werde ich noch hinter den Sinn steigen müssen.
Interessanterweise löst Kernel 2.6.23-rc9 den ich mal wegen eines Bugs ausprobiert habe, einige udev-Probleme, so dass die ACPI-Module automatisch geladen werden und der ATI-Treiber weiterhin funktioniert. Finde ich sehr praktisch.
Leider habe ich ``pam_keyring`` noch nicht komplett einrichten können - so ist der Ebuild von ``pam_keyring`` in Portage schlicht unbrauchbar, weil das buggy ist. Im entsprechenden Bugreport ist dies schon länger bekannt - die dort von Debian kopierten Patches funktionieren bei mir auch sehr gut (nur dass ich das Passwort doppelt eingeben muss, aber auch dafür ist eine Lösung im Bugzilla vorhanden) nur scheint der Entwickler sich tot zu stellen. Die PAM-Configdateien zu modifizieren ist nicht ganz so trivial, aber die aktuellen Patches dem Ebuild beizulegen ist echt nicht so schwer, insbesondere da schon mehrere (sowohl Debian-, Ubuntu- als auch Gentoo-)User diese Patches ausprobiert haben.
Was funktioniert
GNOME. GNOME 2.18.3 funktioniert Klasse - ohne da an Configdateien schrauben zu müssen (außer der einen für ``startx``, aber die ist Optinal, wenn man GDM verwendet). Die ATI-Treiber funktionieren. Zumindest der größte Teil, denn ``rebuild-revdep``, ein Gentoo-Tool beschwert sich weil einige Binaries der ATI-Treiber 32 bittig sind und ich die benötigten 32-bit Kompatibilitätsbibliotheken nicht installiere. Ansonsten funktionieren sie recht brauchbar und durchaus stabil. Alle Mäuse die ich versucht habe funktionieren. Das Touchpad funktioniert. Die Netzwerkkarte arbeitet sehr stabil. Die WLAN-Karte zwar gar nicht, aber mit dem Madwifi OpenHAL könnte irgendwann Besserung kommen. Meine am meisten Programme funktionieren - sowohl XChat, als auch Claws Mail, Firefox etc. Brennen funktioniert auch absolut problemlos. Ich habe auch nur recht konservative Compiler-Optimierungen eingeschaltet, aber das ist auch ganz gut so, denn bisher ist mir nur ``emerge`` einmal eingefroren.
Das Paketmanagement
Eines vorweg: Ich habe mir eix noch nicht ansehen können, aber nutze sehr oft die Programme des ``gentoolkit``. So wie ich sehe ist ``eix`` nur eine verbesserte Suchfunktion. Die Suchfunktion finde ich aber gar nicht so schlecht, außerdem nutze ich oft gentoo-portage.com.
Das Paketmanagement ist das was mir bisher am wenigsten gefällt. Ich habe über lange Jahre APT benutzt (zusammen mit den verbesserten Dependency-Handling von Aptitude, welches nun auch in APT selbst integriert wird) und war damit zumindest was Binärpakete angeht ziemlich zufrieden. Unter Arch Linux habe ich einige Wochen ``packman`` benutzt, was auch recht nett war - leider bot es keine so Klasse ncurses-Oberfläche wie ``aptitude``, aber ok.
``emerge`` wirkt auf mich dagegen etwas arg minimalistisch. Ja, die Ebuilds sind sehr simpel (obwohl die PKGBUILDS in Arch kürzer sind, na egal, sei's drum), und die Idee mit USE-Flags ist nicht wirklich schlecht, aber außer Installieren von Paketen (und derer Dependencies) kann ``emerge`` nicht wirklich viel. Die Option überflüssige Pakete zu löschen ``--depclean`` ist auch nicht wirklich sicher, denn sie hat mal eben das Paket ``db`` gelöscht, (``libdb4.3`` in Debian-Sprache) und nicht gemekrt, dass viele Programme gegen diese Bibliothek gelinkt waren (warum die das nicht als Dependency haben wundert mich jetzt etwas), so dass ich sie gegen das neue ``db`` Paket (``libdb4.5``) linken musste. Hat nicht wehgetan, da es mit ``revdep-rebuild`` ein brauchbares Programm gibt, dass das automatisch erledigt, aber es ist nicht unbedingt berauschend, wenn so etwas passiert. Es wunder mich sowieso, wo db-4.3 her kam, vermutlich aus dem stage3-Tarball.
Der Portage-Tree ist riesengroß (im Vergleich zu den Cache-Verzeichnissen anderer Systeme) und die Pakete nehmen vergleichsweise viel Festplattenspeicher weg (da die Development-Dateien immer installiert sind). Mit ``emerge --sync`` kann man den Tree über einen Mirror synchronisieren, was angenehm ist, da nur die veränderten Dateien übertragen werden. Einige Mirrors sind auch gut (schnell ist eigentlich alle), andere brauchen aber lange um die Synchronisation zu beginnen. Ein Update des Systems verläuft ziemlich gut, denn ``emerge`` kompiliert alle Pakete und mit ``etc-update`` kann man sich die geänderten Konfigurationsdateien ansehen und verwalten.
Die Verwaltung der Pakete selbst hingegen ist noch ein Buch mit sieben Siegeln. Ich weiß leider immer noch nicht, welche Pakete ich eigentlich installiert habe und welche ich gefahrlos löschen kann. Mit ``emerge --unmerge`` kann ich ein Paket zwar löschen, aber ich weiß eigentlich nie, was das für Folgen haben kann. Schön wäre es, wenn Dependencies die der Ebuild mit sich gezogen hat, auch automatisch zumindest wieder zum Löschen vorschlägt, statt das an ``--depclean`` zu delegieren. Folgende Situation: ich will ``gawk`` gegen ``mawk`` ersetzen. Nun kann ich ``gewk`` unmergen und ``mawk`` emergen, aber unter Debian werde ich gewarnt wenn da etwas schief laufen kann. Bei Gentoo passiert es einfach.
Ich werde wohl noch länger brauchen, um mich mit ``emerge`` anzufreunden. Viele Beklagen die Geschwindigkeit von ``emerge``, aber das ist etwas woran ich Ausnahmsweise eigentlich nichts zu meckern habe. Im Vergleich zur Kompilationszeit fällt das nicht wirklich ins Gewicht.
Community
Ich muss zugeben, dass ich kaum motiviert war irgendwas in der Community zu machen. Das Forum war bei meinen Problemen wenig hilfreich (ich gebe ja auch zu, dass ich keine simplen Probleme hatte) und im Bugtracker gehen meine gefundenen Bugs auch eher langsam vorran. Bisher ist keiner FIXED. Naja.
Aktualität
Dies gilt hier hauptsächlich für das Keyword amd64, also stable. Aber das meiste lässt sich auch auf x86 übertragen.
Manchmal bin ich echt überrascht, wie lange es dauert, bis Pakete nach stable migrieren. Das liegt größtenteils am Mangel der Infrastruktur. GNOME 2.20 war schon einen Monat nachdem Ubuntu es hatte verfügbar, gerade mal zwei Monate nach dem 2.20 Release. Dumm ist auch, dass viele Bugfix-Releases immer noch nicht in stable sind, wie Evince 2.20.2, welches einen großen Druck-Fehler behebt. Ebenso ist IPython in stable in einer antiken Version. Ähnliches gilt für Io, wo der Ebuild seit Jahren nicht entstaubt wurde.
Das ist zwar störend, aber zum Glück recht simpel lösbar indem man in der ``package.keywords`` für bestimmte Pakete ``~amd`` akzeptiert, d.h. die Unstable-Pakete installiert. Das verläuft problemlos, denn sie werden sowieso kompiliert und daher gibt es keine ABI-Mismatches wie bei Debian.
Das die Development-Sachen immer installiert sind hat noch einen weiteren Vorteil: ich kann mir immer die aktuellen Versionen von Io, GNU Smalltalk, Python 3, Ruby 1.9 etc. in $HOME installieren. Gut, könnte ich woanders auch, aber da wärs mir dann um den Plattenplatz zu schade
Portage-Probleme
Bis auf dass ich Portages Dependency-Verwaltung ziemlich blöd finde, hatte ich kaum Probleme. Ich habe von Bekannten gehört, dass das System nach einiger Zeit gegen die Wand fährt, aber bisher habe ich nicht das Gefühl dass es da irgendwo Probleme geben würde. Was manchmal nervt sind die Conflicts die nicht aufgelöst werden können. Ein Beispiel war letztens ``util-linux(-ng)``, welches die Funktionalität von ``setarch`` bot und einen Konflikt mit dem ``setarch`` EBuild hatte. Nach dem Löschen von ``setarch`` war das aber kein Problem mehr. Die Lösungen (und Gründe) der Konflikte kann man sich meist via Suchmaschine finden und problemlos anwenden.
Ausblick
Vielleicht werde ich mir Paludis und pkgcore ansehen - den Konkurrenten von ``emerge``. Möglicherweise bieten sie ja irgendwelche schönen Vorteile.
nachdem ich schon das kurze Arch Linux-Review geschrieben habe, gibt es nun heute meine Erfahrungen mit Gentoo Linux.
Gründe für Gentoo
So viele Gründe für Gentoo wie die Gentoo-User gerne sagen gibt es nicht. Ich würde sogar dahin gehen und sagen, dass der Durschschnitts-Linux-Nutzer mit Gentoo eher schlecht beraten ist. Meine Gründe waren die große Anpassbarkeit an die eigenen Bedürfnisse sowie die angeblich hohe Performance. Den Lerneffekt sollte man auch nicht außer acht lassen. Nachteil sind natürlich die Kompilationszeiten, wobei hier noch ``distcc`` einen Versuch wert ist.
Ein anderer Grund ist der angeblich so tolle Support in den Gentoo-Foren. Praktisch ist, dass das mehrsprachige Foren sind die unglaublich viele angemeldete User haben ansonsten habe ich bisher keine Probleme dort erörtern müssen, die ich nicht hätte selbst lösen können (oder bei denen mir das Wiki oder auch birkenfeld nicht hatten helfen können)
Hardware
Hat sich seit dem Arch Linux-Review nicht geändert. Ich habe aber inzwischen eine USB-Maus angeschlossen Der Wrong PCI ID Vendor-Bug ist immer noch nicht behoben, aber ich fahre gerade mit ``pci=conf1`` hoch, das funktioniert auch ganz gut.
Nachdem ich jetzt aber jahrelang x86-Linux genutzt hatte (auch das Arch im Review davor war ein 32-Bit Linux, obwohl es einen 64-Bit Port gibt), dachte ich mit dass ich das EM64T meines Core 2 mal ausnutzen kann und wählte diesmal den amd64
Installation
Die Installation von Gentoo Linux 2007.0 verläuft bei weitem nicht so schnell wie die von Arch. Man könnte sagen, dass Gentoo einen Rekord bei der Installationslänge aufstellt. Das liegt aber zum großen Teil daran, dass es schlichtweg keinen Installer gibt und man die Installationsanweisung (die eigentlich ziemlich gelungen ist) abarbeitet. Das hat den Vorteil, dass das ganze dadurch sehr flexibel ist und den Nachteil, dass man ohne die Anleitung auch mal Dinge übersehen kann.
Das es keinen Installer gibt, ist mehr oder weniger falsch - es gibt auf der LiveCD einen grafischen Installer. Aber ich habe die Minimal-CD benutzt und außerdem läuft bei mir der freie X11-Treiber nicht mit meiner Grafikkarte. Noch dazu fehlt einem das Gentoo-Feeling, dann erinnert es eher an den Ubuntu-Installer.
Software-Konfiguration
Ich hatte einige Bedenken was den proprietären ATI-Treiber angeht, weil der bei meinem letzen Gentoo-Versuch (auf x86) ziemlich schlecht lief. Jedoch war es diesmal kein Problem, inzwischen habe ich die ``make.conf`` auch so eingestellt, dass X11 automatisch den richtigen Treiber mitinstalliert und nicht sinnlos irgendwelche anderen Treiber mitzieht. Als ich X.org das zweite mal kompiliert hatte, habe ich auch den Synaptics-Treiber zum laufen bekommen, mit dem ich mein Touchpad genauer einrichten konnte. Funktioniert bisher Klasse (habe unter Arch auch mal die Clickwheel-Funktion angetestet, aber leider ist das nicht für produktiven Einsatz sinnvoll).
Da ich immer noch GNOME-Nutzer bin, habe ich mir GNOME installiert, was aber vergleichsweise lange zum kompilieren brauchte so dass der Laptop mal über Nacht an blieb.
Das war etwa der erste "Wow"-Moment: So wie GNOME unter Arch vergleichen mit Ubuntu schnell ist, so setzt das GNOME unter Gentoo da locker noch etwas drauf (ich habe Ubuntus GNOME 2.14.x mit jeweils 2.18.3 verglichen). Es ist wirklich schnell: ich würde es von der Performance mit einem frisch installiertem Windows 2000 vergleichen. Damit kann man dann schon sehr anständig arbeiten.
Nett finde ich, dass ich unter Gentoo problemlos MP3-Dateien abspielen kann, ohne irgendwelche zusätzlichen Pakete installieren zu müssen. XviD funktioniert bisher noch nicht, aber ich denke dass das auch hinzubekommen ist (gst-plugins-bad sind leider masked und die enthalten das XviD-Plugin). Das System-Menü in GNOME ist besser ausgestattet als das in Arch jedoch musste ich bei einem Applet einen kleinen Berechtigungs-Bug beheben.
Im Gegensatz zu vielen anderen Systemen bekommt man unter Gentoo auch den Firefox als Firefox und nicht als Firedove oder Bon Echo: aber auch dafür gibt es ein entsprechendes USE-Flag.
Was die Programaktualität angeht hinkt Gentoo etwas nach und ist etwas hinter Debian Testing, zumindest was das "stable" Gentoo betrifft. Das unstable ist mit Testing vergleichbar, aber so aktuell brauche ich die Pakete gar nicht. Aber man kann auch testing-Pakete in Gentoo ohne weitere Probleme installieren.
Ich habe natürlich auch wieder das gleiche Cursortheme installiert wie unter Arch, was genauso simpel ging und auch einen anderen GDM-Splash (Blue Swirl) welcher noch trivialer einzurichten war. Die GNOME-Integration ist gelungen, das GNOME-Overlay ist schon fast vollständig auf GNOME 2.20.0 aktualisiert und wird sich wohl nach einiger (wohl langer) Testphase in Portage finden.
Hardware-Konfiguration
Zuerst lief Sound gar nicht, da in dem Standardkernel den ich mit den Einstellungen des LiveCD-Kernels gebaut habe keine ALSA-Unterstützung dabei war. Wie ich es von Arch wusste habe ich das Modul ``snd-hda-intel`` verwenden können um die Azalia-Karte verwenden zu können. In den Standardeinstellungen funktionierte Autosensing der Ausgänge Leider nicht, so dass die Lautsprecher auch mit eingesteckten Kopfhörern/Stereoanlage noch an waren. Ließ sich aber mit dem Parameter ``model=hippo`` für die Realtec ALC262 ziemlich gut beheben. Hat nur lange gedauert das herauszufinden.
Ähnlich sah es leider auch mit den ATI-Treibern aus: bei bestimmten Kernel-Einstellungen führen sie zum Freeze - ich habe letztendlich herausgefunden, dass ich die Einstellung von 8 CPUs nicht auf 2 CPUs setzen darf, sonst geht es nicht. Ansonsten habe ich die gröbsten Optimierungen etwa Core 2-Optimierter Code, Preemptiven Kernel + Lock, und den Timer beschleunigt. Viel hat es nicht gebracht aber nun bin ich zumindest was die ATI-Treiber angeht schlauer.
USB-Hotplug funktioniert mit HAL und GNOME ziemlich gut. Allerdings musste ich den Eintrag des CD-ROM -Laufwerkes aus der ``/etc/fstab`` rausnehmen, da ich sonst Fehlermeldungen bekam. Das Einbinden von Massenspeichern wie meinem USB-Stick oder meinem Mediaplayer funktioniert klasse und wenn man die Volumes unmountet, wird extra gefragt, ob man den Trash-Order auf dem Volume leeren will (ansonsten bleibt der drauf - so kann man sogar drei verschiedene Trash-Order haben: XP, Vista, GNOME). Ist eine Kleinigkeit, aber da hat jemand drangedacht.
Probleme
Es ist natürlich nicht so, dass alles bei Gentoo unproblematisch ist, wobei ich zugebe, dass ich mir alles schlimmer vorgestellt habe. Von dem CD-ROM Mount-Problem habe ich schon berichtet. Auch die Umstellung des System auf ein locale und UTF-8 war nicht ohne Probleme. So habe ich es gerne wenn mein System zu mir in Englisch spricht - das Datumsformat sollte aber dennoch deutsch bleiben. Nachdem ich den Fehler gemacht hatte, in ``/etc/env.d/02locale`` die Variable ``GDM_LANG`` zu setzen hat es mit folgenden Inhalt geklappt:
Code: Alles auswählen
LANG="de_DE.UTF-8"
LC_MESSAGES="en_US.UTF-8"
Dabei habe ich immerhin den Unterschied zwischen ``LANG`` und ``LC_ALL`` verstanden, weil das im deutschsprachigen Wiki gut erklärt ist.
Ein weiteres Problem war die Tastatur (auch in Arch hatte ich ein Tastatur-Problem, aber ein anderes) - die Taste mit der Pipe und den Größer/Kleiner-Zeichen ging einfach nicht. Aber nachdem ich in der xorg.conf die Tastatur von ``pc104`` auf ``pc105`` geändert habe und diese Änderung auch von GNOME bemerkt wurde funktioniert sie sehr gut.
Weitere Optimierungen betreffen die zu bauenden Module: ich habe in der Kernelkonfiguration viele Module rausgenommen, weil sie beim booten unnötig geladen wurden. Letztendlich gibt es in der Datei ``/usr/share/genkernel/<arch>/modules_load`` eine Datei die die zu ladenden Module auflistet. Naja, zumindest baut sich der Kernel nun schneller und es ist unwarscheinlich dass ich plötzlich Unterstützung für OHCI bräuchte. Was mir bisher noch nicht ganz klar ist wozu mdev statt udev beim booten startet, da werde ich noch hinter den Sinn steigen müssen.
Interessanterweise löst Kernel 2.6.23-rc9 den ich mal wegen eines Bugs ausprobiert habe, einige udev-Probleme, so dass die ACPI-Module automatisch geladen werden und der ATI-Treiber weiterhin funktioniert. Finde ich sehr praktisch.
Leider habe ich ``pam_keyring`` noch nicht komplett einrichten können - so ist der Ebuild von ``pam_keyring`` in Portage schlicht unbrauchbar, weil das buggy ist. Im entsprechenden Bugreport ist dies schon länger bekannt - die dort von Debian kopierten Patches funktionieren bei mir auch sehr gut (nur dass ich das Passwort doppelt eingeben muss, aber auch dafür ist eine Lösung im Bugzilla vorhanden) nur scheint der Entwickler sich tot zu stellen. Die PAM-Configdateien zu modifizieren ist nicht ganz so trivial, aber die aktuellen Patches dem Ebuild beizulegen ist echt nicht so schwer, insbesondere da schon mehrere (sowohl Debian-, Ubuntu- als auch Gentoo-)User diese Patches ausprobiert haben.
Was funktioniert
GNOME. GNOME 2.18.3 funktioniert Klasse - ohne da an Configdateien schrauben zu müssen (außer der einen für ``startx``, aber die ist Optinal, wenn man GDM verwendet). Die ATI-Treiber funktionieren. Zumindest der größte Teil, denn ``rebuild-revdep``, ein Gentoo-Tool beschwert sich weil einige Binaries der ATI-Treiber 32 bittig sind und ich die benötigten 32-bit Kompatibilitätsbibliotheken nicht installiere. Ansonsten funktionieren sie recht brauchbar und durchaus stabil. Alle Mäuse die ich versucht habe funktionieren. Das Touchpad funktioniert. Die Netzwerkkarte arbeitet sehr stabil. Die WLAN-Karte zwar gar nicht, aber mit dem Madwifi OpenHAL könnte irgendwann Besserung kommen. Meine am meisten Programme funktionieren - sowohl XChat, als auch Claws Mail, Firefox etc. Brennen funktioniert auch absolut problemlos. Ich habe auch nur recht konservative Compiler-Optimierungen eingeschaltet, aber das ist auch ganz gut so, denn bisher ist mir nur ``emerge`` einmal eingefroren.
Das Paketmanagement
Eines vorweg: Ich habe mir eix noch nicht ansehen können, aber nutze sehr oft die Programme des ``gentoolkit``. So wie ich sehe ist ``eix`` nur eine verbesserte Suchfunktion. Die Suchfunktion finde ich aber gar nicht so schlecht, außerdem nutze ich oft gentoo-portage.com.
Das Paketmanagement ist das was mir bisher am wenigsten gefällt. Ich habe über lange Jahre APT benutzt (zusammen mit den verbesserten Dependency-Handling von Aptitude, welches nun auch in APT selbst integriert wird) und war damit zumindest was Binärpakete angeht ziemlich zufrieden. Unter Arch Linux habe ich einige Wochen ``packman`` benutzt, was auch recht nett war - leider bot es keine so Klasse ncurses-Oberfläche wie ``aptitude``, aber ok.
``emerge`` wirkt auf mich dagegen etwas arg minimalistisch. Ja, die Ebuilds sind sehr simpel (obwohl die PKGBUILDS in Arch kürzer sind, na egal, sei's drum), und die Idee mit USE-Flags ist nicht wirklich schlecht, aber außer Installieren von Paketen (und derer Dependencies) kann ``emerge`` nicht wirklich viel. Die Option überflüssige Pakete zu löschen ``--depclean`` ist auch nicht wirklich sicher, denn sie hat mal eben das Paket ``db`` gelöscht, (``libdb4.3`` in Debian-Sprache) und nicht gemekrt, dass viele Programme gegen diese Bibliothek gelinkt waren (warum die das nicht als Dependency haben wundert mich jetzt etwas), so dass ich sie gegen das neue ``db`` Paket (``libdb4.5``) linken musste. Hat nicht wehgetan, da es mit ``revdep-rebuild`` ein brauchbares Programm gibt, dass das automatisch erledigt, aber es ist nicht unbedingt berauschend, wenn so etwas passiert. Es wunder mich sowieso, wo db-4.3 her kam, vermutlich aus dem stage3-Tarball.
Der Portage-Tree ist riesengroß (im Vergleich zu den Cache-Verzeichnissen anderer Systeme) und die Pakete nehmen vergleichsweise viel Festplattenspeicher weg (da die Development-Dateien immer installiert sind). Mit ``emerge --sync`` kann man den Tree über einen Mirror synchronisieren, was angenehm ist, da nur die veränderten Dateien übertragen werden. Einige Mirrors sind auch gut (schnell ist eigentlich alle), andere brauchen aber lange um die Synchronisation zu beginnen. Ein Update des Systems verläuft ziemlich gut, denn ``emerge`` kompiliert alle Pakete und mit ``etc-update`` kann man sich die geänderten Konfigurationsdateien ansehen und verwalten.
Die Verwaltung der Pakete selbst hingegen ist noch ein Buch mit sieben Siegeln. Ich weiß leider immer noch nicht, welche Pakete ich eigentlich installiert habe und welche ich gefahrlos löschen kann. Mit ``emerge --unmerge`` kann ich ein Paket zwar löschen, aber ich weiß eigentlich nie, was das für Folgen haben kann. Schön wäre es, wenn Dependencies die der Ebuild mit sich gezogen hat, auch automatisch zumindest wieder zum Löschen vorschlägt, statt das an ``--depclean`` zu delegieren. Folgende Situation: ich will ``gawk`` gegen ``mawk`` ersetzen. Nun kann ich ``gewk`` unmergen und ``mawk`` emergen, aber unter Debian werde ich gewarnt wenn da etwas schief laufen kann. Bei Gentoo passiert es einfach.
Ich werde wohl noch länger brauchen, um mich mit ``emerge`` anzufreunden. Viele Beklagen die Geschwindigkeit von ``emerge``, aber das ist etwas woran ich Ausnahmsweise eigentlich nichts zu meckern habe. Im Vergleich zur Kompilationszeit fällt das nicht wirklich ins Gewicht.
Community
Ich muss zugeben, dass ich kaum motiviert war irgendwas in der Community zu machen. Das Forum war bei meinen Problemen wenig hilfreich (ich gebe ja auch zu, dass ich keine simplen Probleme hatte) und im Bugtracker gehen meine gefundenen Bugs auch eher langsam vorran. Bisher ist keiner FIXED. Naja.
Aktualität
Dies gilt hier hauptsächlich für das Keyword amd64, also stable. Aber das meiste lässt sich auch auf x86 übertragen.
Manchmal bin ich echt überrascht, wie lange es dauert, bis Pakete nach stable migrieren. Das liegt größtenteils am Mangel der Infrastruktur. GNOME 2.20 war schon einen Monat nachdem Ubuntu es hatte verfügbar, gerade mal zwei Monate nach dem 2.20 Release. Dumm ist auch, dass viele Bugfix-Releases immer noch nicht in stable sind, wie Evince 2.20.2, welches einen großen Druck-Fehler behebt. Ebenso ist IPython in stable in einer antiken Version. Ähnliches gilt für Io, wo der Ebuild seit Jahren nicht entstaubt wurde.
Das ist zwar störend, aber zum Glück recht simpel lösbar indem man in der ``package.keywords`` für bestimmte Pakete ``~amd`` akzeptiert, d.h. die Unstable-Pakete installiert. Das verläuft problemlos, denn sie werden sowieso kompiliert und daher gibt es keine ABI-Mismatches wie bei Debian.
Das die Development-Sachen immer installiert sind hat noch einen weiteren Vorteil: ich kann mir immer die aktuellen Versionen von Io, GNU Smalltalk, Python 3, Ruby 1.9 etc. in $HOME installieren. Gut, könnte ich woanders auch, aber da wärs mir dann um den Plattenplatz zu schade
Portage-Probleme
Bis auf dass ich Portages Dependency-Verwaltung ziemlich blöd finde, hatte ich kaum Probleme. Ich habe von Bekannten gehört, dass das System nach einiger Zeit gegen die Wand fährt, aber bisher habe ich nicht das Gefühl dass es da irgendwo Probleme geben würde. Was manchmal nervt sind die Conflicts die nicht aufgelöst werden können. Ein Beispiel war letztens ``util-linux(-ng)``, welches die Funktionalität von ``setarch`` bot und einen Konflikt mit dem ``setarch`` EBuild hatte. Nach dem Löschen von ``setarch`` war das aber kein Problem mehr. Die Lösungen (und Gründe) der Konflikte kann man sich meist via Suchmaschine finden und problemlos anwenden.
Ausblick
Vielleicht werde ich mir Paludis und pkgcore ansehen - den Konkurrenten von ``emerge``. Möglicherweise bieten sie ja irgendwelche schönen Vorteile.