Review: Gentoo Linux

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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:

Code: Alles auswählen

LANG="de_DE.UTF-8"
LC_MESSAGES="en_US.UTF-8"
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.
Zuletzt geändert von Leonidas am Sonntag 20. Januar 2008, 15:13, insgesamt 2-mal geändert.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
nkoehring
User
Beiträge: 543
Registriert: Mittwoch 7. Februar 2007, 17:37
Wohnort: naehe Halle/Saale
Kontaktdaten:

Dienstag 9. Oktober 2007, 07:51

Hallo...

also das find ich ja mal ne nette Idee. Ich bin uebrigens jahrelanger Gentoo-Nutzer und finde, dass das Paketmanagement der Hauptgrund ist, es zu nutzen ;)

Wichtig ist allerdings, dass du dir mal das Tool "eix" anschaust. Ohne haette ich auch keine Lust.

Code: Alles auswählen

> emerge -av eix
...installation...

> update-eix
Das tolle an "eix" ist, dass es den PortageTree in einer kleinen Datenbank haelt und somit weitaus schneller suchen kann, als "emerge". Wenn du also mal irgendwas suchst, dann schreib sowas wie:

Code: Alles auswählen

eix "^gnome" # re's erlaubt
eix "program" # es geht aber auch ohne
eix -S "beschreibung" # so zB durchsuchst du die Beschreibungen der Pakete
eix -IS "instbeschrei" # und so die Beschreibungen der installierten Pakete
#...
#ansonsten hilft wie immer:
man eix
Vorallem ans Herz legen will ich dir aber den Abschnitt "Eine Portage Einfuehrung" im Gentoo-Handbuch.
Die USE-Flags und Dateien wie /etc/portage/package.use, /etc/portage/package.keywords, /etc/portage/package.mask und /etc/portage/package.unmask spielen eine entscheidende Rolle.

Gruesse
NKoehring
[url=http://www.python-forum.de/post-86552.html]~ Wahnsinn ist auch nur eine andere Form der Intelligenz ~[/url]
hackerkey://v4sw6CYUShw5pr7Uck3ma3/4u7LNw2/3TXGm5l6+GSOarch/i2e6+t2b9GOen7g5RAPa2XsMr2
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Dienstag 9. Oktober 2007, 22:11

nkoehring hat geschrieben:also das find ich ja mal ne nette Idee. Ich bin uebrigens jahrelanger Gentoo-Nutzer und finde, dass das Paketmanagement der Hauptgrund ist, es zu nutzen ;)
Hmm, also ich bin nach einigen Tagen Nutzung immer noch nicht ganz überzeugt. Ich habe aber das Review oben erweitert und werde schauen, dass ich bis zum nächsten Update auch ``eix`` anteste.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
schwedenmann
User
Beiträge: 42
Registriert: Sonntag 21. Oktober 2007, 13:38
Wohnort: Wegberg

Sonntag 21. Oktober 2007, 18:10

Hallo


Bin neu hier im Forum, kompletter Pythonanfänger, aber Linuxnutzer.


Zu genntoo

1. für Anfänger komplett ungeignet

2. Paketmanegement pe emerge ist auch nicht mehr der it, einieg genntoofreaks installieren ja dehalb schon Paludis.

3. Für Produktivsystem nicht geignet, allein der zeitaufwand fürs emergen ist enorm (ich selbst fahre aus Spaß SourceMarge, habe gestern ein komplettes update gefahren von 16:30 bis 00:30 bei rund 128 Dateien, insgesamt 283 auf dem System.


4. Vorteil ziemlich große Auswahl an Paketen, gute Anpaßbarkeit per flags und compileroptioenn an sein System, abr damit erreicht man nur meßbare Performancegewinne, die bewegen sich eher im ms Bereich.


Mein debian-Sid i386 verhält sich nicht langsamer als mein archlinux das auf i686 oder mein SourceMarge das auf XP optimeirt sind, Ausnahme Boot- und shutdownphase.
mfg
schwedenmann
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sonntag 21. Oktober 2007, 22:05

Hallo schwedenmann, willkommen im Forum,

(irgendwie habe ich das Gefühl, das ich dich schon von irgendwoher kenne.. Debianforum?)
schwedenmann hat geschrieben:1. für Anfänger komplett ungeignet
Hmm, ja, gut möglich. Aber wenn man technisch begabt ist, schafft man auch mit Gentoo den Einstieg in Linux. Ich muss zugeben, dass mein Linux-Einstieg auch ziemlich hart war, weil bei mir damals auf meiner Hardware die Installationstools meiner Distribution nicht richtig funktioniert haben, also musste ich mich so durchhacken. War aber zu schaffen, nicht nur dank der damals noch richtig umfangreichen gedruckten Handbücher.

Eine Installation von Gentoo auf x86 ist hingegen ziemlich trivial, man muss im großen und ganzen nur die Befehle im Handbuch abtippen, inzwischen gibt es auch den Installer, der alles selbst macht. Was den Schwierigkeitsgrad des Systems angeht, würde ich sagen, dass es etwa Arch-Niveau hat, vielleicht mit etwas mehr Schrauben zu Konfiguration.

Fassen wir zusammen: viele Themen in Linux sind inzwischen zu simpel geworden :D HAL, GNOME, udev funktionieren sofort überall, das Paketmanagement hat oft alle nötigen Programme im Repository etc. Wobei man zugeben muss, dass es immer noch spannende Themen wie etwa die Konfiguration des initramfs gibt ;)
schwedenmann hat geschrieben:2. Paketmanegement pe emerge ist auch nicht mehr der it, einieg genntoofreaks installieren ja dehalb schon Paludis.
Paludis und Pkgcore wollte ich mir ansehen, aber die sind masked. Habe schon überlegt, so etwas wie Aptitude für Portage zu implementieren, da das Paketmanagement leider nicht so toll ist wie viele sagen (eigentlich kann ich das immer weniger nachvollziehen, von den wenigen Sachen die ich über Portage weiß würde ich vieles anders lösen).
schwedenmann hat geschrieben:3. Für Produktivsystem nicht geignet, allein der zeitaufwand fürs emergen ist enorm (ich selbst fahre aus Spaß SourceMarge, habe gestern ein komplettes update gefahren von 16:30 bis 00:30 bei rund 128 Dateien, insgesamt 283 auf dem System.
Kann ich eigentlich so nicht bestätigen. Natürlich, das kompilieren von X.org, GNOME etc. dauert schon etwas lange, aber seitdem fallen die Updates geradezu minimal aus. Einzig die glibc hat in letzter Zeit lange gedauert. Wobei ich muss auch zugeben, dass ich arch und nicht ~arch fahre. Für ein Produktivsystem ist es aber durchaus geeignet. Lustigerweise funktioniert MP3-Wiedergabe in meinem Gentoo out-of-the-box, was ja in letzter Zeit nicht mehr so selbstverständlich ist.
schwedenmann hat geschrieben:4. Vorteil ziemlich große Auswahl an Paketen, gute Anpaßbarkeit per flags und compileroptioenn an sein System, abr damit erreicht man nur meßbare Performancegewinne, die bewegen sich eher im ms Bereich.
Subjektiv fühlt es sich schneller an, ob das nun an den Optimierungen liegt die mein x86_64-System gegenüber einem auf 686 optimierten Arch hat kann ich dir aber nicht sagen.
Wobei man muss auch die psychologische Sicht betrachten: wenn der User denkt es ist schneller, ist das ja fast so gut, als wäre es tatsächlich schneller. Eine solche Taktik hat beispielsweise der Desktop in neueren Windows-Versionen: man sieht die Icons, kann auf draufklicken, aber bis tatsächlich etwas passiert, dauert es noch etwas. Ubuntu 7.04 lädt auch den GDM bevor noch alles geladen ist, was in 6.06 noch nicht so war.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sonntag 20. Januar 2008, 15:15

Ich habe zu dem Review noch drei weitere Kapitel angehängt. Ich glaube nicht, dass mir zu Gentoo noch irgendetwas schreibenswertes einfällt.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Sonntag 20. Januar 2008, 20:00

Das portage auf den Sondermüll ist kein Geheimnis. Paludis allerdings funktioniert gut, und kann auch Dependencies sauber entfernen, wenn man ein Paket deinstalliert.

Festhalten sollte man auch, dass die Community bei Bugs nicht immer flott arbeitet, und das die QA-Standards im Tree an manchen Ecken sehr, sehr tief liegen. Alles kein Geheimnis.

Allerdings hat Gentoo den unschlagbaren Vorteil, dass neue Software sehr, sehr schnell in den Tree integriert werden kann. Gerade für Standard-Pakete wie setuptools-Archive aus dem Cheeseshop oder autotools-Pakete von kde-look.org sind mit wenigen Zeilen integriert. Der ebuild für html5lib bringt es auf 17 Zeilen, jinja auf 34 (weil die Docs an der falschen Stelle abgelegt werden). Ich habe schon für Suse und Debian bzw. Ubuntu Pakete gebaut, auf keinem der System war das ähnlich komfortabel.

Der Vorteil an gentoo ist auch, dass diese Ebuilds sehr universal sind. Man braucht für alle möglichen Gentoo-Installationen nur einen einzigen Ebuild. Für Binärdistributionen muss man Build-Services bemühen, weil man kaum Systeme mit allen möglichen Versionen auf allen möglichen Architekturen zu Hause stehen hat.

Das lässt es letztendlich auch verschmerzen, dass Bugs mitunter langsam gefixt werden, gerade an entlegeneren Ecken des Trees. Braucht man die Software, kann man sich Bugfix und Ebuild manuell aus dem Tracker heraussuchen, und in das eigene Overlay legen. Das dauert auch nicht länger als ein sync.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Sonntag 20. Januar 2008, 20:24

Hallo!

Ich habe Gentoo recht lange eingesetzt und war ziemlich begeistert davon. Ich empfand es immer als super flexibel und anpassbar. Es lief auf Geräten, an denen mancher Standard-Susianer oder Standard-Debianer verzweifelt wäre.

Aber eine große Schwäche von Gentoo wurde mir einmal zum Verhängnis und bewog mich dazu auf Debian/Ubuntu umzusteigen.

Wenn du ein Gentoo-System nicht ständig pflegst, dann lässt es sich nach ca. einem Jahr schon nicht mehr updaten (auch keine Sicherheitsupdates). Installationsdateien waren schon nach einem halben Jahr nicht mehr beschaffbar -- nur mehr die neuesten Versionen, die für die Updates nicht geeignet waren.

An meine derzeitigen Systeme verbinde ich mich einmal im Monat und fahre ein Update mit ``aptitude update`` und ``aptitude upgrade``. Wenn es keine Probleme/Ausfälle verursacht, dann starte ich die Kisten sogar noch neu. Das dauert ein paar Minuten -- wenn es hoch kommt eine viertel Stunde -- dann sind die Server "up to date".

Bei Gentoo gingen im Monat oft mehrere Stunden dafür drauf. Und ich meine jetzt nicht das Kompilieren, sondern die Fehlersuche und Klärung von Abhängigkeiten, damit das Update fehlerfrei durchläuft. Und wenn man Glück hat und sich nicht wieder irgendeine Abhängigkeit von SSH geändert hat, dann lies sich nach so einem Update der Computer auch per SSH neu starten. Und wenn man Pech hatte -- und das hatte ich -- dann steht so ein Server in Frankfurt in irgendeinem Rechenzentrum, ein paar hundert Kilometer von Wien entfernt.

Vielleicht hat sich das inzwischen geändert. Ich hatte schon lange keine Berührung mehr mit Gentoo. Aber wenn ich wieder mal ein Linux auf einem Computer installieren muss, der sich weigert Debian und Co. anzunehmen, dann werde ich es sicher wieder mit Gentoo probieren. Denn Gentoo läuft überall.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sonntag 20. Januar 2008, 21:13

gerold hat geschrieben:Aber wenn ich wieder mal ein Linux auf einem Computer installieren muss, der sich weigert Debian und Co. anzunehmen, dann werde ich es sicher wieder mit Gentoo probieren. Denn Gentoo läuft überall.
Was für Architekturen wären das? Gentoo unterstützt neun, Debian elf (und ist damit die Distribution mit den meisten unterstützten Architekturen). Für ganz spezifische Anforderungen gibts ja noch NetBSD :)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
nkoehring
User
Beiträge: 543
Registriert: Mittwoch 7. Februar 2007, 17:37
Wohnort: naehe Halle/Saale
Kontaktdaten:

Montag 21. Januar 2008, 09:32

gerold hat geschrieben:[...]
Vielleicht hat sich das inzwischen geändert. Ich hatte schon lange keine Berührung mehr mit Gentoo. Aber wenn ich wieder mal ein Linux auf einem Computer installieren muss, der sich weigert Debian und Co. anzunehmen, dann werde ich es sicher wieder mit Gentoo probieren. Denn Gentoo läuft überall.
Hi gerold. Also das Problem mit den Dependencies gibt es immer noch. Als Server finde ich Gentoo-System schon ziemlich ungeeignet. Es ist toll zum basteln und probieren. Und es ist vielleicht auch toll fuer zuHause, wo man auch mal n bissl Zeit aufwenden kann. Aber ein Produktivsystem? Nein, da sollte man auf bewaehrte Binaerdistributionen setzen. Ubuntu-Server oder Debian sind da okay. Ich persoenlich mag Slackware. Das wird installiert, zusaetzliche Pakete drueber gebuegelt und sobald es laeuft bleibt es wie es ist und gut! Fuer nen Server braucht es bei mir eigentlich keinen Paketmanager :roll:

In diesem Sinne: Never change a running system!

;)
[url=http://www.python-forum.de/post-86552.html]~ Wahnsinn ist auch nur eine andere Form der Intelligenz ~[/url]
hackerkey://v4sw6CYUShw5pr7Uck3ma3/4u7LNw2/3TXGm5l6+GSOarch/i2e6+t2b9GOen7g5RAPa2XsMr2
lunar

Montag 21. Januar 2008, 20:15

gerold hat geschrieben:An meine derzeitigen Systeme verbinde ich mich einmal im Monat und fahre ein Update mit ``aptitude update`` und ``aptitude upgrade``.
In Zeiten, in denen 0-day-exploits auch für Linux-Server zunehmend in Mode kommen, darf man diese Sicherheitsstrategie aber für gewagt halten...
Bei Gentoo gingen im Monat oft mehrere Stunden dafür drauf. Und ich meine jetzt nicht das Kompilieren, sondern die Fehlersuche und Klärung von Abhängigkeiten, damit das Update fehlerfrei durchläuft.
Ich nutze gentoo sicherlich noch nicht lange (vielleicht ein Jahr), aber ich hatte nie wirklich gravierende Probleme mit Abhängigkeiten, außer bei großeren Upgrades (das jetzige KDE-4-Update). Solange man immer brav synct und nach dem Upgrade revdep-rebuild ausführt, hat Gentoo-Linux eigentlich keine Probleme, und das trotz ~x86 in den Keywords. Debian-Unstable hat sich bei mir wesentlich öfter verschluckt als Gentoo Unstable (ja, ich weiß, dass man das nicht unbedingt vergleichen kann ;) ). Ehrlich gesagt, hatte ich sogar unter Suse 9.3 mit den Packman-Quellen größere Abhängigkeitsprobleme als mit Gentoo.
Und wenn man Glück hat und sich nicht wieder irgendeine Abhängigkeit von SSH geändert hat, dann lies sich nach so einem Update der Computer auch per SSH neu starten.
Für Server ist Gentoo imho nur bedingt geeignet. Ich denke nicht, dass es auf einem Produktivsystem sinnvoll ist, Ressourcen für Paketkompilierung abzuziehen, ganz abgesehen davon, dass Sicherheitsupdates bedingt durch die Kompilierung mitunter verzögert eintrudeln, und Gentoo ziemlich miese QA-Standards im Tree hat.

Wenn man Gentoo schon als Server betreiben möchte (z.B. weil man auf gentoo-hardened scharf ist), dann sollte man die Pakete auf einem binpkg-Host bauen, und den Server von dort aktualisieren. Dann hat man aber auch keine Probleme mit Abhängigkeiten, weil revdep-rebuild bzw. reconcilio auf dem Paketbau-System durchlaufen.
Aber wenn ich wieder mal ein Linux auf einem Computer installieren muss, der sich weigert Debian und Co. anzunehmen, dann werde ich es sicher wieder mit Gentoo probieren. Denn Gentoo läuft überall.
@Leondias
Das hat nur bedingt was mit Architekturen zu tun. Exotisches Architekturen sind nicht so sehr ein Problem, wie exotische Hardware auf Standardarchitekturen.

Erst letzte Woche hatten wir das Problem, dass sich Debian nicht auf einem Server installieren lies, weil der Raid-Controller nicht erkannt wurde. Linux-Treiber existieren zwar, nur eben nicht im Standard-Kernel und folglich auch nicht im Debian-Installer.

Unter Gentoo wäre es jetzt kein Problem (zumindest für jemanden, der Erfahrung mit Linux hat), den Raid-Treiber in eine RAM-Disk zu entpacken, von dort gegen den Kernel der Install-CD zu bauen, anschließend die Platten ganz normal zu mounten, und anschließend Kernel und Treiber für das zu installierende System neu zu bauen. Unter Debian wüsste ich jetzt nicht, wie ich externe Treiber während des Installationsprozesses einbinde (v.a. wenn der Treiber gegen den Installer-Kernel gebaut werden muss, um überhaupt auf die Platten zugreifen zu können).
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Montag 21. Januar 2008, 21:07

lunar hat geschrieben:...
Amen!
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
tiax
User
Beiträge: 152
Registriert: Samstag 23. Juli 2005, 17:28
Kontaktdaten:

Montag 21. Januar 2008, 21:54

Unter Gentoo wäre es jetzt kein Problem (zumindest für jemanden, der Erfahrung mit Linux hat), den Raid-Treiber in eine RAM-Disk zu entpacken, von dort gegen den Kernel der Install-CD zu bauen, anschließend die Platten ganz normal zu mounten, und anschließend Kernel und Treiber für das zu installierende System neu zu bauen. Unter Debian wüsste ich jetzt nicht, wie ich externe Treiber während des Installationsprozesses einbinde (v.a. wenn der Treiber gegen den Installer-Kernel gebaut werden muss, um überhaupt auf die Platten zugreifen zu können).
Na wenn wir schon mal dabei sind :) - unter Debian auch nicht. Man kann Debian aus einem laufenden System heraus auf eine andere Partition installieren, mitsamt Kernel seiner Wahl auf der Zielpartition. Man muss ja den debian-installer (obwohl er sonst ganz gut ist), nicht verwenden. Diese Freheit bieten sowohl Debian als auch Ubuntu, ein Stichwort wäre wohl Debootstrap
Ne invoces expellere non possis
[url=xmpp://florian@florianheinle.de]xmpp:florian@florianheinle.de[/url]
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 21. Januar 2008, 22:35

tiax hat geschrieben:Diese Freheit bieten sowohl Debian als auch Ubuntu, ein Stichwort wäre wohl Debootstrap
Ich habe vermutlich mehr Systeme ge"debootstrappt" als ich sie normal installiert hätte :) Für VServer und Systeme ohne Laufwerke ist das sehr nützlich.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Dienstag 22. Januar 2008, 17:39

tiax hat geschrieben:Man kann Debian aus einem laufenden System heraus auf eine andere Partition installieren, mitsamt Kernel seiner Wahl auf der Zielpartition.
Aus einem laufenden System? Wo genau erkennst du in dem beschriebenen Szenario ein laufendes System? Oder allgemeiner: Auf welchen neu erstandenen Server gibt es denn ein laufendes Debian-System?

Oder ermöglicht Debian die Installation über Netzwerk?
Antworten