Von Randy Andy am Do, 12. September 2013 um 14:08 #
mit dem Einbinden von Repositories zum Bezug von nicht Standardmäßig enthaltenen Paketen. Ganz zu schweigen von den Risiken beim Einbinden unausgereifter oder gar fremder Repos, für die Konsistenz der Installation.
Gentoo ist da viel mehr "geradeaus" als es den Anschein haben mag, trotz des anfänglich höheren Aufwandes. Dort heißen die Pakete noch so wie ihr Ursprung (eben die Sourcen) und nicht Distributionsspezifisch immer mal wieder anders. Dann noch zig Namensderivate wegen wegen unterschiedlicher Zusammenstellungen, je nach Bedürfnissen oder Hardware.
Ich finde das Binäre Namensschema deutlich verwirrender als die make-Optionen der sourcen, die in Gentoo zu den USE-Flags abstrahiert sind.
Um also wieder den Bogen zum Artikel zu spannen, würde man unter Gentoo einfach das USE-Flag "css" in der make.conf hinzufügen und durch ein world upate (quasi ein Distributionsupgrade) würde die Unterstützung für das Content Scramble System in alle installieren und dieses Feature unterstützenden Programme einkompiliert werden.
Ach, und mit Repositories braucht man auch nicht herum fummeln und verfügt doch über die gleiche Auswahl wie die Binären über alle ihre Zweige ;-) Der Tree, ist quasi das Standard-Repo von Gentoo, der aber nur die ebuilds enthält, kleine schlanke Text-Dateien mit Anweisungen zum Bau der Pakete aus den Quellen. Da diese jedoch nur auf die Quellen Verweisen, statt diese ober Binaries daraus zu enthalten, entledigt man sich so elegant, der im Artikel erwähnten rechtlichen Problematik.
Gruß, Andy.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Sep 2013 um 14:17.
Von Dirk Weber am Do, 12. September 2013 um 15:51 #
Mag ja sein. Jedoch scheint mir, dass ich dann mein gesamtes System eben nicht mehr aus Binärdateien zusammenstellen kann, sonern alles selber kompilieren muss. Das mag für viele Anwender absolut ok sein, ich bin froh, dass es diese Möglichkeit gibt.
Ich selber und eine Menge anderer Linux-User möchte das aber nicht. Ich will mein Linux benutzen, damit arbeiten. Dazu sind diverse Distris auch sehr gut geeignet, IMHO besser als Gentoo.
Jetzt komme mir bitte niemand mit "DAU", bin ich nicht.
Im übrigen ist es nicht schwer, die Güte eines Repos zu eruieren.
Von Randy Andy am Do, 12. September 2013 um 17:48 #
Ist ja in Ordnung was Du sagst, deshalb ist es ja gut wenn man die Wahl hat, sich die Distro herauszusuchen, die einem am meisten zusagt. Deshalb würde ich auch niemanden als DAU beschimpfen, so etwas liegt mir fern.
"Von Dirk Weber am Do, 12. September 2013 um 15:51 Im übrigen ist es nicht schwer, die Güte eines Repos zu eruieren."
Das würde mich aber nun doch interessieren, wie das verlässlich und reproduzierbar geht?
Von asdfghjkl am Do, 12. September 2013 um 16:48 #
Vertrauenswürdige Quelle: Videolan-Projekt. Eine Zeile Copy & Paste in die Paketquellen. Um Updates kümmert sich danach die Paketverwaltung. Was ist jetzt daran Herumgefrickel oder Gefummel? Gentoo mag elegant sein, aber für die meisten User ist es nicht "straightforward".
Von Randy Andy am Do, 12. September 2013 um 17:40 #
Konkret in diesem Fall Beispielsweise: Ohne über externe Quellen wie diese hier darüber informiert worden zu sein, hätte man das über sein Paketmanagement genau wie erfahren? Dann wäre man doch vermutlich dann auf dem alten Stand stehen geblieben, da einem einfach keine Updates mehr angeboten würden - richtig?
Mit Gentoo wär das so nicht passiert. Bei ähnlichen oder vergleichbaren Aktionen gibt's ca. 30 Tage vorher eine Mitteilung über das Paketmanagement, das das Paket aus dem Tree entfernt oder hart maskiert wird.
Ja, Gentoo ist elegant und für technisch denkende Anwender sehr komfortabel und straightforward, auch wenn es für den Mainstream eher kryptisch und kompliziert wirken mag.
Von asdfghjkl am Fr, 13. September 2013 um 01:03 #
Ja, es ist eleganter, wenn man keine Fremdquellen einbinden muss. Ich habe nichts gegen Gentoo und bin mir sicher, dass Gentoo eine durchdachte Distro ist (in der Theorie finde ich das Gentoo-Konzept auch besser). Dennoch finde ich nicht, dass das Debian Paketmanagement Gefrickel ist. Gentoo muss man verstehen, bei Debian dagegen: Synaptic an, Häkchen bei Paket XY setzen, fertig. Kaputtmachen kann ich auch nichts wenn ich Pakete wieder entferne, da ich über alle Abhängigkeiten informiert werde. Es gibt schon auch Vorteile bei Debian, da sind 3-4 Pakete aus einer Fremdquelle kein großer Umstand. Gentoo und Debian haben vollkommen unterschiedliche Konzepte des Paketmanagements - ich finde beides ist nicht "Gefrickel".
(P.S. Wenn ein Repositorium nicht mehr erreichbar ist, bekomme ich dies ebenfalls über die Paketverwaltung mit, nur eben nicht im Voraus. Dann benötige ich ca. 2 Minuten, um die neue Quelle zu googeln und einzutragen. Elegant ist das nicht, aber eben auch kein großer Aufstand und nur bei einzelnen Ausnahmen nötig.)
Von Randy Andy am Fr, 13. September 2013 um 09:18 #
Ok asdfghjkl,
beides ist gleichermaßen kein Gefrickel, sondern den unterschiedlichen Konzepten geschuldet.
Auch wenn die Bevorzugung für das Eine oder Andere letztlich eine Frage der persönlichen Vorlieben ist, so sehe ich die technischen Vorteile und Möglichkeiten dennoch bei Gentoo. Natürlich macht das Anfangs mehr Arbeit und es funktioniert nichts OOTB. Wer darauf den Focus legt, für den scheint Gentoo eher ungeeignet.
Schließlich beschränken sich die meisten User nach der Installation lediglich auf die weitere Paketauswahl, oder auf die Auswahl und Konfiguration von Diensten und nehmen somit billigend, oder in Unkenntnis der erweiterten Möglichkeiten in Kauf, dass ihr System ansonsten fremdbestimmt wird.
Somit hören sie gerade dort auf, wo sich Linux am stärksten von unfreien BS (Betriebs-System) abhebt, und wo es eigentlich seinen Ursprung und seine größten Stärken hat, nämlich in der individuellen Anpassbarkeit an besondere Bedürfnisse, oder an die verwendete Hardware.
Von .-,.-,-.,-., am Sa, 14. September 2013 um 14:03 #
"Ja, es ist eleganter, wenn man keine Fremdquellen einbinden muss."
Vor allen Dingen ist es sicherer, wenn man nicht querbeet Fremdquellen einbindet, deren Initiatoren man nicht kennt bzw. kennen kann. Von daher ist das debianeigene, gigantische Softwarerepo erst einmal jeder Fremdquelle vorzuziehen. Und genau dies ist auch der große Vorteil von Debian. Das sehe ich genauso.
Von Gentoo User am Fr, 13. September 2013 um 04:53 #
Ich bin selbst Gentoo User und muss dir leider widersprechen!
Wenn man im Tree die gesuchte Software nicht findet, dar man bei Gentoo auch erst mal gucken ob die Software in nem Overlay vorhanden ist und falls ja, dann muss man das Overlay einbinden.
Mal davon abgesehen das viele Pakete in den Overlays veraltet sind oder gar nicht erst funktionieren.
Von Randy Andy am Fr, 13. September 2013 um 09:49 #
Na, Du Nestbeschmutzer
Also erstens braucht man für solche Basics wie Multimedia-Codecs, Firmware, proprietäre Treiber etc. kein Overlay einbinden, da das schon alles im Tree vorhanden ist. Ich hatte das in der Vergangenheit schon mal für einen Vortrag ausgearbeitet, hier ein kleiner Auszug daraus:
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.php nicht 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 bezogen von dieser Site: http://asdfasdf.debian.net/~tar/bugstats/?zack%40debian.org
Aktuelle Zahlen von Gentoo belegen findet man hier: http://packages.gentoo.org/categories/ Categories: 159 Packages: 16838 Ebuilds: 35907
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. 30000 Binaries /2)
Wie man daraus ersieht, verfügen beide Distributionen über eine nahezu ebenbürtige Programmauswahl.
Noch wichtiger als die absoluten Zahlen, scheint es mir auch 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 (insofern klar dass hier vieles noch nicht 100% funktioniert, aber das würdes Du ja in einem Experimental Repository auch nicht erwarten). Dennoch werden die Pakete dann wenigstens nicht am Paketmanagement vorbei installiert und lassen sich somit auch wieder sauber entfernen.
Wenn nun der Nutzer einer binären Distribution ein Paket installiert, welches gegen andere Versionen von Systembibliotheken gelinkt ist, als die seines eigenen, bzw. seines zugrunde liegenden Referenzsystems, dann wird er früher oder später auf Fehler stoßen. So etwas kommt meist dadurch zustande, dass der User Repositories unterschiedlicher Releases einer Distribution beliebig mischt, oder zusätzlich fremde Repositories einbindet.
Auf dem Gentoo-System auf dem das Paket erfolgreich gebaut wurde, sind danach jedoch alle Abhängigkeiten erfüllt. Insofern ist es hier gefahrloser möglich verschiedene Zweige und Quellen zu mischen, ein unschätzbarere Vorteil wie ich finde.
libavcodec-extra non-free-codecs w64codecs bzw. w32codecs
Ich hielt die bisher alle für wichtig. Insbesondere wenn man alte Clips im Real-Format noch abspielen wollte hat man das w32codec oder w64codec Pack immer noch benötigt.
mit dem Einbinden von Repositories zum Bezug von nicht Standardmäßig enthaltenen Paketen.
Ganz zu schweigen von den Risiken beim Einbinden unausgereifter oder gar fremder Repos, für die Konsistenz der Installation.
Gentoo ist da viel mehr "geradeaus" als es den Anschein haben mag, trotz des anfänglich höheren Aufwandes.
Dort heißen die Pakete noch so wie ihr Ursprung (eben die Sourcen) und nicht Distributionsspezifisch immer mal wieder anders.
Dann noch zig Namensderivate wegen wegen unterschiedlicher Zusammenstellungen, je nach Bedürfnissen oder Hardware.
Ich finde das Binäre Namensschema deutlich verwirrender als die make-Optionen der sourcen, die in Gentoo zu den USE-Flags abstrahiert sind.
Um also wieder den Bogen zum Artikel zu spannen, würde man unter Gentoo einfach das USE-Flag "css" in der make.conf hinzufügen und durch ein world upate (quasi ein Distributionsupgrade) würde die Unterstützung für das Content Scramble System in alle installieren und dieses Feature unterstützenden Programme einkompiliert werden.
Ach, und mit Repositories braucht man auch nicht herum fummeln und verfügt doch über die gleiche Auswahl wie die Binären über alle ihre Zweige ;-)
Der Tree, ist quasi das Standard-Repo von Gentoo, der aber nur die ebuilds enthält, kleine schlanke Text-Dateien mit Anweisungen zum Bau der Pakete aus den Quellen.
Da diese jedoch nur auf die Quellen Verweisen, statt diese ober Binaries daraus zu enthalten, entledigt man sich so elegant, der im Artikel erwähnten rechtlichen Problematik.
Gruß, Andy.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Sep 2013 um 14:17.hmmm... wolltest Du jetzt Werbung für Gentoo machen oder was zum Artikel schreiben ?
Beides natürlich
und ich finde das ist mir auch gelungen
Mag ja sein. Jedoch scheint mir, dass ich dann mein gesamtes System eben nicht mehr aus Binärdateien zusammenstellen kann, sonern alles selber kompilieren muss. Das mag für viele Anwender absolut ok sein, ich bin froh, dass es diese Möglichkeit gibt.
Ich selber und eine Menge anderer Linux-User möchte das aber nicht. Ich will mein Linux benutzen, damit arbeiten. Dazu sind diverse Distris auch sehr gut geeignet, IMHO besser als Gentoo.
Jetzt komme mir bitte niemand mit "DAU", bin ich nicht.
Im übrigen ist es nicht schwer, die Güte eines Repos zu eruieren.
Ist ja in Ordnung was Du sagst, deshalb ist es ja gut wenn man die Wahl hat, sich die Distro herauszusuchen, die einem am meisten zusagt.
Deshalb würde ich auch niemanden als DAU beschimpfen, so etwas liegt mir fern.
"Von Dirk Weber am Do, 12. September 2013 um 15:51
Im übrigen ist es nicht schwer, die Güte eines Repos zu eruieren."
Das würde mich aber nun doch interessieren, wie das verlässlich und reproduzierbar geht?
Vertrauenswürdige Quelle: Videolan-Projekt. Eine Zeile Copy & Paste in die Paketquellen. Um Updates kümmert sich danach die Paketverwaltung. Was ist jetzt daran Herumgefrickel oder Gefummel? Gentoo mag elegant sein, aber für die meisten User ist es nicht "straightforward".
Konkret in diesem Fall Beispielsweise:
Ohne über externe Quellen wie diese hier darüber informiert worden zu sein, hätte man das über sein Paketmanagement genau wie erfahren?
Dann wäre man doch vermutlich dann auf dem alten Stand stehen geblieben, da einem einfach keine Updates mehr angeboten würden - richtig?
Mit Gentoo wär das so nicht passiert. Bei ähnlichen oder vergleichbaren Aktionen gibt's ca. 30 Tage vorher eine Mitteilung über das Paketmanagement, das das Paket aus dem Tree entfernt oder hart maskiert wird.
Ja, Gentoo ist elegant und für technisch denkende Anwender sehr komfortabel und straightforward, auch wenn es für den Mainstream eher kryptisch und kompliziert wirken mag.
Ja, es ist eleganter, wenn man keine Fremdquellen einbinden muss. Ich habe nichts gegen Gentoo und bin mir sicher, dass Gentoo eine durchdachte Distro ist (in der Theorie finde ich das Gentoo-Konzept auch besser). Dennoch finde ich nicht, dass das Debian Paketmanagement Gefrickel ist. Gentoo muss man verstehen, bei Debian dagegen: Synaptic an, Häkchen bei Paket XY setzen, fertig. Kaputtmachen kann ich auch nichts wenn ich Pakete wieder entferne, da ich über alle Abhängigkeiten informiert werde. Es gibt schon auch Vorteile bei Debian, da sind 3-4 Pakete aus einer Fremdquelle kein großer Umstand. Gentoo und Debian haben vollkommen unterschiedliche Konzepte des Paketmanagements - ich finde beides ist nicht "Gefrickel".
(P.S. Wenn ein Repositorium nicht mehr erreichbar ist, bekomme ich dies ebenfalls über die Paketverwaltung mit, nur eben nicht im Voraus. Dann benötige ich ca. 2 Minuten, um die neue Quelle zu googeln und einzutragen. Elegant ist das nicht, aber eben auch kein großer Aufstand und nur bei einzelnen Ausnahmen nötig.)
Ok asdfghjkl,
beides ist gleichermaßen kein Gefrickel, sondern den unterschiedlichen Konzepten geschuldet.
Auch wenn die Bevorzugung für das Eine oder Andere letztlich eine Frage der persönlichen Vorlieben ist, so sehe ich die technischen Vorteile und Möglichkeiten dennoch bei Gentoo.
Natürlich macht das Anfangs mehr Arbeit und es funktioniert nichts OOTB. Wer darauf den Focus legt, für den scheint Gentoo eher ungeeignet.
Schließlich beschränken sich die meisten User nach der Installation lediglich auf die weitere Paketauswahl, oder auf die Auswahl und Konfiguration von Diensten und nehmen somit billigend, oder in Unkenntnis der erweiterten Möglichkeiten in Kauf, dass ihr System ansonsten fremdbestimmt wird.
Somit hören sie gerade dort auf, wo sich Linux am stärksten von unfreien BS (Betriebs-System) abhebt, und wo es eigentlich seinen Ursprung und seine größten Stärken hat, nämlich in der individuellen Anpassbarkeit an besondere Bedürfnisse, oder an die verwendete Hardware.
"Ja, es ist eleganter, wenn man keine Fremdquellen einbinden muss."
Vor allen Dingen ist es sicherer, wenn man nicht querbeet Fremdquellen einbindet, deren Initiatoren man nicht kennt bzw. kennen kann.
Von daher ist das debianeigene, gigantische Softwarerepo erst einmal jeder Fremdquelle vorzuziehen. Und genau dies ist auch der große Vorteil von Debian. Das sehe ich genauso.
Ich bin selbst Gentoo User und muss dir leider widersprechen!
Wenn man im Tree die gesuchte Software nicht findet, dar man bei Gentoo auch erst mal gucken ob die Software in nem Overlay vorhanden ist und falls ja, dann muss man das Overlay einbinden.
Mal davon abgesehen das viele Pakete in den Overlays veraltet sind oder gar nicht erst funktionieren.
Mit Pakete ist natürlich das EBuild gemeint
Na, Du Nestbeschmutzer
Also erstens braucht man für solche Basics wie Multimedia-Codecs, Firmware, proprietäre Treiber etc. kein Overlay einbinden, da das schon alles im Tree vorhanden ist. Ich hatte das in der Vergangenheit schon mal für einen Vortrag ausgearbeitet, hier ein kleiner Auszug daraus:
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.php nicht 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 bezogen von dieser Site:
http://asdfasdf.debian.net/~tar/bugstats/?zack%40debian.org
Aktuelle Zahlen von Gentoo belegen findet man hier: http://packages.gentoo.org/categories/
Categories: 159 Packages: 16838 Ebuilds: 35907
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. 30000 Binaries /2)
Wie man daraus ersieht, verfügen beide Distributionen über eine nahezu ebenbürtige Programmauswahl.
Noch wichtiger als die absoluten Zahlen, scheint es mir auch 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 (insofern klar dass hier vieles noch nicht 100% funktioniert, aber das würdes Du ja in einem Experimental Repository auch nicht erwarten).
Dennoch werden die Pakete dann wenigstens nicht am Paketmanagement vorbei installiert und lassen sich somit auch wieder sauber entfernen.
Wenn nun der Nutzer einer binären Distribution ein Paket installiert, welches gegen andere Versionen von Systembibliotheken gelinkt ist, als die seines eigenen, bzw. seines zugrunde liegenden Referenzsystems, dann wird er früher oder später auf Fehler stoßen.
So etwas kommt meist dadurch zustande, dass der User Repositories unterschiedlicher Releases einer Distribution beliebig mischt, oder zusätzlich fremde Repositories einbindet.
Auf dem Gentoo-System auf dem das Paket erfolgreich gebaut wurde, sind danach jedoch alle Abhängigkeiten erfüllt.
Insofern ist es hier gefahrloser möglich verschiedene Zweige und Quellen zu mischen, ein unschätzbarere Vorteil wie ich finde.
Gruß, Andy.
Was ist mit
libavcodec-extra
non-free-codecs
w64codecs bzw. w32codecs
Ich hielt die bisher alle für wichtig. Insbesondere wenn man alte Clips im Real-Format noch abspielen wollte hat man das w32codec oder w64codec Pack immer noch benötigt.