HOSTBLOGGER.de

Der Frage schließe ich mich mal an.

Na weil er einen distro flamewar vom zaun brechen möchte, ist doch wohl klar

Gentoo ist eine fast-pacing rolling release distro. Der Stable tree macht server admins glücklich und der unstable tree ist sehr gepflegt und bestens geeignet für desktops.
Dazu hat gentoo mit den overlays in verbindung mit eix ein sehr mächtiges und elegantes user-repository system. Ähnlich dem AUR von Archlinux. Mit dem PPA Gekrepel von Debian/Ubuntu möchte ich es nicht vergleichen. Dazu gibt es ausgereiften Binary-Support für größere Infrastrukturen.

Debian hingegen wartet alle 3 bis 4 Jahre mit einem neuen Major-Release auf, dessen Pakete wirklich schon steinalt sind zum jeweiligen Zeitpunkt. (Gefrickel vorprogrammiert)
Debians wunderbarer Paketmanager names apt startet/restartet Dienste automatisch beim install/upgrade. Wirklich eine super sache auf servern. Braucht jeder!1!!

Zudem tendieren Debian Paketverwalter upstream total zu verbiegen, natürlich nur im Sinne des "Users". Wieviele Sicherheitslöcher hatte Debian aufgrund ihrer eigenen Drecks-Patches? Mir fällt da irgendwas mit ssh ein, liegt nur wenige Jahre zurück ...

Die Gentoo ISOs will (und braucht) man nicht.

ich habe gentoo vor vielen Jahren mehrfach ausprobiert. Meine Erfahrungen damals:
- man musste dauernd irgendwas neu kompilieren, ccache etc. belegten ordentlich Platz und machten Probleme
- die USE-Flags waren grausam (irgendwann war ich für meine Bedürfnisse bei ca. 120)
- ein guter Teil der sinnvollen Pakete waren maskiert und sogar die semi-offiziellen Seiten riefen dazu auf, das zu ignorieren
- wenn man in USE-Flag neu hinzufügte (global) sorgte dies gerne mal für 'ne Rekompilierorgie, USE-Flag pro Paket ging nur, wenn man's explizit jedesmal angab (oder z.B. für "mp3" an nem halben dutzend Stellen in ner Zentral-Konfig selber angab)
- Doku wurde oft nicht mitgeliefert, wegen irgendwelchen (zirkulären?) Abhängigkeiten
- Bei Deinstallieren von Paketen wurde auf Abhängigkeiten zu anderen Paketen nicht geachtet.

Ist das heute besser?

Zugegeben: ganz am Anfang, als gentoo das erste mal gehypt wurde, fand ich Linux From Scratch einfacher zu installieren. Das hatte sich bei den weiteren Versuchen gebessert Aber gerade die USE-Flags und die nicht (wirklich) beachteten Abhängigkeiten haben mich dann doch jedesmal zu Debian (je nach Rechner stable oder testing) zurückkehren lassen.

s/Ubuntu/Gentoo/ -.-

keine Frage, wenn man genug Maschinen rumstehen hat, dass man eine oder zwei nur für's "dauerkompilieren" abstellen kann ist das schön. Ebenso, wenn (fast) alle Rechner im Verbund dieselben USE-Flags verwenden.

Aber was macht eine Person, die nur ein, zwei Serverchen hat? Sich auf den Build des Hosters zu verlassen ist ja fast so wie gleich Binärpakete von $beliebigeanderedistro einsetzen.

Früher war bei OpenOffice (zumindest auf meinen Kisten) das Problem, dass der RAM nicht ausreichte, alles auf einmal zu kompilieren, und dadurch die Platte mit "temp"-Zeugs vollief... Beides heute weniger Problema

Bei einem Projekt haben wir uns entschieden von Debian Stable auf Gentoo zu wechseln.
Der entscheidende Punkt war in dem Fall die Aktualität:
Die von uns benötigte Software war in Debian Stable unbrauchbar: total veraltet und verbugt. Selbst in Testing sind die Pakete noch veraltet. Wir hätten die Software und einige Bibliotheken selber neu bauen und aktuell halten müssen.
Wir haben uns dann für Gentoo entschieden. Inzwischen haben wir auch für einige andere Software kleine Patches, die man bei Gentoo einfach in den Build-Prozess integrieren kann.
Aus einem Rechner wurden 7 virtuelle Server, wovon einer der Buildserver ist, der den anderen die binären Pakete bereitstellt. Den Portage-Tree und die Binären-Pakete werden vom Buildserver per nfs in den Clients eingebunden. Für die Verwaltung haben wir eine Hand voll Bash-Skripte geschrieben.

Bei einem anderen Projekt bin ich gezwungen Debian zu verwenden. Da bin ich ehrlich gesagt ziemlich am Fluchen - vielleicht einfach, weil ich mich noch nicht gut genug mit Debian auskenne. Bei dem Projekt handelt es sich um einen "On-Demand-Druckdienst". Für die Aufbereitung der Druckdaten wurden einige Skripte und Tools für die Aufbereitung der Druckdaten geschrieben. Dabei sind wir schon auf viele Bugs in Cairo,Poppler,GTK+ und CUPS gestoßen.
Die meisten Bugs haben wir gemeinsam mit Upstream gefixed. In Debian Stable haben es diese nicht mehr geschafft. Also haben wir da auf Debian Testing umgestellt. Leider haben es da bisher nicht alle Fixes reingeschafft. Also dürfen wir ein paar Pakete (z.B. gtk, cairo) selber bauen und bereitstellen. Leider hab ich bisher noch kein Automatismus gefunden, der mir die Pakete neu baut, wenn Debian neue Pakete bereitstellt.
Bei einem Update muss man immer aufpassen, ob ein betroffenes Paket aktualisiert wurde und das man sich nicht aus versehen das original Paket von Debian installiert.
Desweiteren dürfen wir die cups-filter selber neu Paketieren, weil Debian ghostscript zum Rendern nimmt. Das führt bei unsren Vorlagen, die wir bekommen, aber häufig zu Problemen. Wir müssen deshalb dem cups-filter-Paket bei bringen poppler zu verwenden. Da gilt das selbe Probleme wie oben: Passt man nicht auf und installiert ein Update aus den Debian-Quellen macht auf einmal das Drucken Probleme.

Die Häufigkeit an Updates von gentoo ggü. Debian Stable mag zwar minimal höher sein, aber das compilieren und installieren dauert bei Serversoftware in der Regel nicht sonderlich viel länger als bei Debian. Auf dem Desktop kann das aber schon ein bisschen anders aussehen.
Ich compiliere z.B. meine Software auf der Workstation und installiere auf meinem Laptop die Binaries.

Die Init-Skripte von Gentoo sind jedoch in der Regel deutlich besser als die von Debian. Zum Beispiel Bind: Gentoo führt vor dem start ein named-checkconf und gibt die Fehlermeldung aus. Debian sagt einfach nur: failed.

Auch die Verwaltung und Installation von Software finde ich bei Gentoo deutlich angenehmer. Die Ausgaben nach einem Emerge sagen einem, was man ggf. noch tun muss. Wir stellen das immer so ein, dass wir zum Schluss eine Zusammenfassung per Mail zugeschickt bekommen.
Bei Debian kämpf ich häufig damit, dass bei vielen Updates/Installationen dpkg zwischen drin Fragen stellt. Da kann man den Installations-Prozess also nicht einfach mal alleine Laufen lassen, da Garantiert am Anfang irgend ein Paket ein Frage hat und damit der ganze Prozess hängt. Klar, die Fragerei kann man deaktivieren. Aber dann muss man wissen, welche Dienste man am Schluss von Hand noch nachkonfigurieren muss. Ich weiß nur noch nicht, woher man das Wissen soll.

Desweiteren wird bei Debian viel Debianspezifisches verwendet: z.B. die Skripte um apache oder exim zu konfigurieren. Bei exim kann man diese Tools zum Glück relativ einfach durch ein eigenes Dummy-Paket ersetzen. Aber für mich ist das einfach gefrickel... Ich arbeite in der Regel mit der Doku von Upstream. Bei Debian fällt man da nicht selten auf die Schnauze, weil einem irgendwas Debianspezifisches in die quere kommt.

Mir gefällt insgesamt die (Rolling Release) Philosophie besser: lieber immer wieder kleine Änderungen an einzelnen Diensten, als bei einem dist-upgrade ein Haufen Dienste auf einmal testen und ggf. neu konfigurieren müssen.
Bei Debian hab ich manchmal das Gefühl, dass man lieber einen Bug nicht fixt, als dass man ggf. von irgendjemand den Workaround kaputt macht.

Bei mir steht Debian leider häufig im Weg bei meiner Arbeit, was für mich sehr frustrierend ist. Bei Maschinen, bei denen ich jedoch kaum von den Vorstellungen der Debian Maintainer abweiche (z.B. dem Desktop meiner Mutter), da ist Debian ganz nett. So bald man aber vom Debian-Weg abweichen will, werden einem nur Steine in den Weg gelegt. Gentoo lässt mir deutlich mehr Freiheit.

Im Prinzip muss aber jeder für sich selber entscheiden, was ihm lieber ist.

Was nimmt man da so? Eine Art Netinstaller?

Je tiefer ich mich in Debian einarbeite, desto frickeliger finde ich es.
Wenn man dann in der ML zu Bugfixes so etwas ließt: "Das Problem tritt in folgender Zeile auf [...] Wir haben keine Ahnung was die macht. Wenn die Zeile gelöscht wird, funktioniert das Programm und der Fehler tritt nicht mehr auf. Diese Lösung haben wir jetzt im VCS eingecheckt."
Da stehen einem die Haare zu Berge.
Ich möchte Debian nicht bashen, dass ist dank des Umfang des Repositories die Distribution meiner zweiten Wahl.
Aber es gibt eindeutig noch viel Verbesserungspotential in den debianspezifischen Software. So bald das neue Testing aufgemacht wird, werde ich ein paar Vorschläge einreichen.

Pah, es geht nichts über einen ordentlichen Mix aus bashism, sed, grep, nano, gedit und Python (;

gegen das "debian installiert sich über eigene Pakete"-Problem sollte apt-pinning helfen. Einfach ein eigenes Repository aufsetzen (geht primitiv oder extrem komplex, ersteres reicht) und dieses via Pinning auf Wert 1001 setzen. Schon sind Pakete des Privat-Repos "wichtiger" als die Debian-eigenen, man kann aber bei Bedarf immer noch die Debain-Pakete installieren. Bei euch sollte sich so ein Repo ja ohnehin lohnen, da genug Server.

Gerade bei so einem wichtigen Server wie einem On-Demand-Druckdienst würde ich aber lieber Debain stable plus evtl. selbstkompiliertes nehmen. Da will man keine häufigen Updates, die (potentiell) Bugs haben und alles zerschießen. Lieber uralte Grundlage mit nur(!) Sicherheitsupdates.

Das Verhalten dpkg sollte einstellbar sein (z.B. kann man die häufigste Nachfrage, die nach modifizierten Configdateien, über ein --force-confold (oder -confnew und/oder -confdef) abschalten). Allerdings finde ich die Situation, nach einem (nächtlichen?) Update erstmal einige Stunden "unkonfiguriert" zu arbeiten auch nicht grade glücklich...

"Im Prinzip muss aber jeder für sich selber entscheiden, was ihm lieber ist. "

Zu emacs fällt mir nur des ein:

Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn
ich nach einem Fahrrad frage und einen pangalaktischen
Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll.

-- Frank Klemm, de.comp.os.unix.discussion

Auf die Gefahr hin, dass ich mich nun zum Deppen machen, frage ich trotzdem.

Was spricht denn dagegen von [1] ein ISO Image zu ziehen und damit zu installieren? Warum den Umweg über z.B. die sysresccd?


[1] http://www.gentoo.org/main/en/where.xml

so genau kenne ich mich mit pinning auch wieder nicht aus - habe das bisher nur in seltenen Ausnahmefällen gebraucht.
Allerdings - woher soll debian wissen, dass es eine neue Upstream-release von einem Programm in deinem Privat-Repo gibt? Sofern das Programm aber nicht (wirklich) sicherheits- aber dafür produktionsrelevant ist muss ja auch nicht 10 Sekunden nach Updates im Upstream die neue Version installiert sein. Natürlich ist das immer eine Abwägung...