Hallo Jonas, Listlinge. Ich habe das Thema schon einmal im Rahmen meines Vortrages über Gentoo, beim LiWok ausgeführt. Um Äpfel nicht mit Birnen zu vergleichen, müsste man auch beim Vergleich der Paketzahlen der binären Distributionen untereinander herausfinden, wie viele Source-Pakete diesen zu Grunde liegen. Nur diese ließen einen korrekten Vergleich untereinander zu. Die in der Antwort von Siegfried gezeigten Kombinationen dienen lediglich der Modularisierung zwecks Kombination zur Anpassung an bestimmte User- oder Hardwareanforderungen. Sie sagen also nicht wirklich etwas über die Programmvielfalt aus, unter der der geneigte User wählen kann. (weiter Begründungen dafür ganz unten im Kapitel "Am Anfang war der Quellcode!")
Hier nun ein kleiner Auszug aus meinem Vortrag, absolute Zahlen sind outdated, können aber teilweise über die enthaltenen Links aktualisiert werden. Ähnlich gälte es dann für andere Distributionen herauszufinden... Anzahl der Pakete als Maßstab? Debian nennt auf seiner Website <http://www.debian.org/> die Rekord verdächtige Zahl von 29000 Paketen für seine Distribution. Diese Zahl kann aber nur zum Vergleich der Binär-Distributionen untereinander herangezogen werden und sichert Debian dadurch den ersten Platz in Sachen Paket-Anzahl. Wenn es aber um den Vergleich der Anzahl der Pakete zwischen Binär- und Quell-basierenden Distributionen geht, so darf man hier Äpfel nicht mit Birnen vergleichen. Genauso falsch wäre es, die Anzahl der Ebuilds zum Vergleich heranzuziehen, da es für jede Versionsnummer eines Programms, ein eigenes Ebuild gibt. Oder noch besser, die theoretische Anzahl an Kombinationen der zu erstellenden Pakete, die sich aus der Zahl der Pakete, multipliziert mit der Anzahl der USE-Flags, ergeben würde. Das sind die Möglichkeiten die dem Gentoo-User zur Verfügung stehen, und die dafür sorgen, dass quasi alle Gentoo-Installationen, so individuell wie ihre Nutzer sind (Gentoo is all about choice). Hier zeigt sich, warum es aus Gentoo-Sicht keinen Sinn macht, alle diese möglichen Pakete tatsächlich auch Binär zu erzeugen. Die Datenmenge wäre viel zu Groß, die Vielfalt nicht mehr überschaubar bzw. beherrschbar. Es gäbe zu viele Nachteile, bei vollständiger Beibehaltung dieser Vielfalt und das alles nur um dem User die Kompilierzeit zu ersparen, die in heutiger Zeit immer weniger Gewichtung hat. Hier kommt man als Binär-Distributor unweigerlich an einen Scheideweg, an dem man genötigt ist bestimmte Entscheidungen dem User Abzunehmen, um die Komplexität auf ein beherrschbares Maß zu reduzieren. Deshalb ist so ein Binär-Paket-System grundsätzlich mehr oder minder fremdbestimmt. Für einen objektiven Vergleich der Paketauswahl, müsste man also die Anzahl der *Quellpakete* von Debian, der Anzahl der Pakete (nicht Ebuilds) von Gentoo gegenüberstellen. * * Leider konnte ich selbst keine aktuelle Erhebung bei Debian durchführen, da sich mir der Zugriff auf das Debian Developer's Packages Overview http://qa.debian.org/developer.phpnicht so recht erschloss. Vergleichbare Erhebungen aus dem Jahr 2009 für Debian scheinen mir jedoch relativ verlässlich: *16756* source packages (*32958* binary packages), count input file<http://qa.debian.org/data/ddpo/results/ddpo_packages>bezogen von dieser Site: http://asdfasdf.debian.net/~tar/bugstats/?zack%40debian.org<http://asdfasdf.debian.net/~tar/bugstats/[email protected]> Aktuelle Zahlen von Gentoo belegen findet man hier: http://packages.gentoo.org/categories/ Categories: 154 Packages: *14607* Ebuilds: 27197 * * * * Wie man sieht scheint der Unterschied so groß nicht. Augenscheinlich ist dagegen das durchschnittliche Verhältnis von Binärpaketen zu Quellpaketen von ca. 2:1. (aktuell bei Debian ca. 29000 Binaries /2) * * Wie man daraus ersieht, verfügen beide Distributionen über eine nahezu ebenbürtige Programmauswahl. Allen Erbsenzählern, die nun auf eine eventuelle Differenz zugunsten Debians abzielen möchten, entgegne ich folgende subjektive Behauptung: Mir scheint es auch wichtig, wie einfach und risikolos der User sich all dieser Pakete bedienen kann. Abhängig davon in welchem Release-Zweig sich der User befindet (z.B. *stable *), wird er neu in die Repositories (z. B. testing oder experimental) eingeflossenen Pakete gar nicht wahrnehmen. Schließlich benötigen diese den festgelegten Reifungsprozess, bis sie erstmalig bei *stable* eintrudeln. Möchte der User sie vorher, also aus experimental oder testing nutzen, könnte er sein System gefährden wie bereits Eingangs erwähnt. Noch mehr gilt das für die Verwendung fremder Paketquellen. Bei Gentoo kann man sich dagegen recht unproblematisch aus den unstable oder sogar fremden Quellen (Overlays) bedienen. Probleme sind erfahrungsgemäß eher während der Kompilation, also noch vor der Installation zu erwarten, oder aber beim ausführen dieser wenig getesteten Programme. Das gefährdet jedoch i.d.R nicht das gesamte System, sondern betrifft dann höchstens diese wenig getesteten Programme. Das eröffnet dem User auf einfache und sichere Art, den flexiblen Zugriff auf genau die stabile oder aktuelle Version, die er sich wünscht. Viele dieser Overlays dienen Entwicklern als Spielwiese, zum testen eigener Ebuilds, bevor diese dann in den Portage-Tree aufgenommen werden. Dort finden sich auch viele auf Anwendungsgebiete spezialisierte Overlays, wie z.B. science, VDR, etc. Auch Anhänger des alten KDE-3.5x werden hier fündig, da nach der abgeschlossenen Migration zu KDE-4.x, die alte Version vollständig dorthin ausgelagert wurde. So könnte man problemlos ein brandaktuelles Grundsystem, mit einem alten KDE-3.5.x betreiben. Zur einfachen und übersichtlichen Verwaltung der Overlays, gibt es ein bewährtes Tool Namens Layman. Es wird vom Gentoo-Entwickler Tobias Scherbaum programmiert und gepflegt, den vielleicht Einige durch sein Buch "Gentoo – Die Metadistribution" kennen. Am Anfang war der Quellcode! * * Open-Source-Software wird naturgemäß *zuerst** als Quellcode *veröffentlicht, denn genau das ist es schließlich, was Open-Source ausmacht! Die vor-kompilierten binären Pakete der Distributoren folgen dann Tage, Wochen, oder gar Monate später. Manche weniger populären Pakete schaffen es nie in das Repository mancher Distribution. Das kann sich als Nachteil erweisen, wenn möglichst aktuelle Treiber oder Programme benötigt oder gewünscht werden. Betrachtet man die Quellpakete als Ursprung, so sind diese vollständig und beinhalten einen gewissen Funktionsumfang und Abhängigkeiten. Einige davon sind zur korrekten Funktion zwingend erforderlich, andere sind optional und lassen sich durch zu übergebende Parameter an- oder abwählen. Eine Regel, über die standardmäßig aktivierten oder deaktivierten Features, lässt sich nicht ableiten und wäre daher stets individuell zu prüfen, um davon Kenntnis zu erlangen (siehe auch ./configure –help). Das vergleichbare Binär-Paket könnte dagegen in seiner Funktionalität beschnitten worden sein, indem bestimmte unterstützte Features abgeschaltet wurden. Unterm Strich sind jedoch meist viele Features aktiviert, die häufig gar nicht benötigt werden, dafür jedoch eine Menge an ungenutzten Abhängigkeiten nach sich ziehen. Diese belegen nicht nur ungenutzten Platz, sondern sie müssen auch teilweise mit geladen werden, was den Speicherbedarf und die Ladezeit erhöhen kann. Auch können sie bei ungünstiger Vorkonfiguration zusätzliche Sicherheitslücken aufwerfen. Wenn der Distributor mehrere Hardware-Architekturen unterstützt, so baut er für jede dieser Zielarchitekturen separate Pakete, aus ein- und derselben Quelle, welche dann separiert in verschiedenen Repositories abgelegt werden. Durch die Wahl der Architektur bzw. des architekturspezifischen Installers, merkt der User nichts von alldem, denn er bewegt sich mit seinem Paketmanager nur innerhalb seines architekturspezifischen Verzeichnisses. Aber auch hier kommt es gelegentlich vor, dass sich in den Repositories scheinbar mehrere Variationen eines Paketnamens finden lassen, deren Namensgebung sich nicht immer auf Anhieb erschließt und den User oftmals verunsichert und somit zum Recherchieren nötigt. In Extremfällen weicht dieser Name sogar stark vom Original Quellpaketnamen ab, wodurch er sich dann manchmal nicht mehr so einfach ermitteln lässt. Hinter diesen Variationen verbergen sich meist mit unterschiedlichen Features kompilierte Binärpakete ein- und desselben Quellpaketes, die sich gegenseitig ausschließen oder an bestimmte Voraussetzungen gekoppelt sind. Diese Namensvielfalt geschieht nicht unbedingt aus Willkür des Distributors, sondern ist eher als Versuch anzusehen, unterschiedliche Wünsche auf Anwenderseite zu befriedigen, oder aber durch Modularisierung der Pakete, deren Abhängigkeiten zu reduzieren. So betrachtet müsste man alle diese Mehrfachnennungen ebenfalls abziehen, um auf die vergleichbare Quellpaketauswahl zu schließen. Besten Gruß, Andy.
_______________________________________________ Trolug_trolug.de mailing list [email protected] https://ml01.ispgateway.de/mailman/listinfo/trolug_trolug.de
