Ja, und dann … sind in den Abhängigkeiten 10.000 andere AUR-Pakete definiert, weil definitiv libterroregoshooter-0.3.so benötigt wird, die von der Distro ausgelieferte aber schon in der Version 0.5 vorhanden ist. Siehe vala-010 und andere Kuriositäten.
Das ist in meinen Augen halt der Nachteil des Linux-Paketmanagement-Systems (habe auch grade einen audacious-Installationskrampf unter CentOS hinter mir), von daher hielte ich es auch nicht verkehrt, wenn sich die Entwickler nicht alles bedienen. Muß man halt zum Spielen sein Ubuntu im Dualboot hochfahren
Von anyoneirgendwer am Do, 26. Juli 2012 um 21:17 #
Das stört mich als Gentoouser nicht im geringsten, weil ich das auch einfach nicht erwarten kann. Ich bin sicher, dass ich Steam auch unter Gentoo problemlos zum laufen kriege, wenn auch vielleicht mit etwas Aufwand.
Aber da ich weiss dass Gentoo niemals Mainstream wird ist mir auch völlig klar, dass man diese Distribution nicht supporten wird.
Aber eben nicht in dieser Form. Unter Gentoo kommt z.B. noch das dazu, was ich liebevoll "Optimierungswahn" nenne. Auch wenn schon seit Jahren im Gentoo-Forum davor gewarnt wird allzu exotische Compiler-Optimierungsoptionen zu verwenden, hält das die Anwender nicht davon ab sie trotzdem einzusetzen. Die Konsequenz sind Fehler, die man nur sehr schwer nachvollziehen kann. Dazu kommen bei RR-Distributionen noch solche Nettigkeiten, wie sich ständig ändernde Bibliotheksversionen bis hinzu kompletten API/ABI-Brüchen.
Soll ein Entwickler einem Benutzer z.B. mitteilen, dass er die Funktionsfähigkeit seines Programms nur für den Stand 27.07.2012 der RR-Distribution garantiert, was danach kommt, liegt aber außerhalb seines Einflussbereiches? Da ist es doch einfacher zu sagen "Benutzt die Version X der Distribution Y, welche mehrere Jahre unterstützt wird und ich garantiere auch für die Funktion meines Programms in diesem Zeitraum".
Aber wenn die Spiele und/oder Steam als Binärprogramme ausgeliefert werden, dann kann der Nutzer da ja nichts optimieren. Außerdem gibt es z.B. bei Gentoo bei den ebuilds schon lange die Möglichkeit, die im System (make.conf) konfigurierten cflags mit denen im ebuild zu überschreiben. So kann der package-maintainer sicherstellen, das bei den entsprechenden Anwendungen/Libs auch wirklich die passenden cflags verwendet werden. Wenn ein Nutzer diese vorgaben ignorieren möchte, gibt es bei diesen ebuilds auch das use-flag "custom-cflags". Aber das ist ja dann auf seinen ausdrücklichen Wunsch hin, da muss er mit Problemen rechnen. Und wenn es zu viele Probleme mit alternativen cflags gibt, kann der package-maintainer dieses use-flag auch einfach gar nicht erst verwenden.
Ich stimme dem zu, dass es für einen Hersteller einfacher ist, wenn er nur eine Distribution unterstützt. Aber ich sehe hier keine so großen Probleme wie du, wenn auch gänzlich andere Distributionen (binäre, source-basierte, ...) unterstützt werden. Ebenso scheint es mir dass du irgendwie Angst davor hast, wenn dir als Nutzer zu viele Optionen und Möglichkeiten zur Verfügung stehen. Denn sonst hättest du nicht auf die Problematik mit den Compiler-Optimierungen hingewiesen. Ich bin mir sicher dass sich die meisten Gentoo-Nutzer bewusst sind, das es durch das sehr flexible System (Portage) auch zu vielen Problemen kommen kann.
Ich verwende Gentoo seit nun etwa 8-9 Jahre, und setze es immer noch sehr gerne ein. Im Moment gibt mir Portage z.B. einen Hinweis, dass die aktuell installierte Chrome-Version (21.0.1180.55_beta148257, wird Binär ausgeliefert) noch eine ältere "libudev" verwendet, obwohl ich schon eine neuere udev-Version installiert habe. Aber Portage (ab v2.2) bietet ja die Möglichkeit, die ältere Bibliothek so lange zu behalten, wie eine Anwendung sie benötigt. Erst sobald ich eine Chrome-Version Installiere, die die neuere lib verwendet, und kein anderes Programm diese Lib mehr benötigt, löscht Portage sie automatisch. Aber so lange kann ich Chrome immer noch wie gewohnt weiterverwenden, obwohl ich schon längst eine neuere udev-Version Installiert habe.
Ja, und dann … sind in den Abhängigkeiten 10.000 andere AUR-Pakete definiert, weil definitiv libterroregoshooter-0.3.so benötigt wird, die von der Distro ausgelieferte aber schon in der Version 0.5 vorhanden ist. Siehe vala-010 und andere Kuriositäten.
Das ist in meinen Augen halt der Nachteil des Linux-Paketmanagement-Systems (habe auch grade einen audacious-Installationskrampf unter CentOS hinter mir), von daher hielte ich es auch nicht verkehrt, wenn sich die Entwickler nicht alles bedienen. Muß man halt zum Spielen sein Ubuntu im Dualboot hochfahren
Das stört mich als Gentoouser nicht im geringsten, weil ich das auch einfach nicht erwarten kann. Ich bin sicher, dass ich Steam auch unter Gentoo problemlos zum laufen kriege, wenn auch vielleicht mit etwas Aufwand.
Aber da ich weiss dass Gentoo niemals Mainstream wird ist mir auch völlig klar, dass man diese Distribution nicht supporten wird.
Und? Die Abhaengigkeiten hast du unter Ubuntu auch. Gute Spiele sind nun mal gross and MB. Whats the problem?
Dazu kommen bei RR-Distributionen noch solche Nettigkeiten, wie sich ständig ändernde Bibliotheksversionen bis hinzu kompletten API/ABI-Brüchen.
Soll ein Entwickler einem Benutzer z.B. mitteilen, dass er die Funktionsfähigkeit seines Programms nur für den Stand 27.07.2012 der RR-Distribution garantiert, was danach kommt, liegt aber außerhalb seines Einflussbereiches? Da ist es doch einfacher zu sagen "Benutzt die Version X der Distribution Y, welche mehrere Jahre unterstützt wird und ich garantiere auch für die Funktion meines Programms in diesem Zeitraum".
Aber wenn die Spiele und/oder Steam als Binärprogramme ausgeliefert werden, dann kann der Nutzer da ja nichts optimieren. Außerdem gibt es z.B. bei Gentoo bei den ebuilds schon lange die Möglichkeit, die im System (make.conf) konfigurierten cflags mit denen im ebuild zu überschreiben. So kann der package-maintainer sicherstellen, das bei den entsprechenden Anwendungen/Libs auch wirklich die passenden cflags verwendet werden. Wenn ein Nutzer diese vorgaben ignorieren möchte, gibt es bei diesen ebuilds auch das use-flag "custom-cflags". Aber das ist ja dann auf seinen ausdrücklichen Wunsch hin, da muss er mit Problemen rechnen. Und wenn es zu viele Probleme mit alternativen cflags gibt, kann der package-maintainer dieses use-flag auch einfach gar nicht erst verwenden.
Ich stimme dem zu, dass es für einen Hersteller einfacher ist, wenn er nur eine Distribution unterstützt. Aber ich sehe hier keine so großen Probleme wie du, wenn auch gänzlich andere Distributionen (binäre, source-basierte, ...) unterstützt werden. Ebenso scheint es mir dass du irgendwie Angst davor hast, wenn dir als Nutzer zu viele Optionen und Möglichkeiten zur Verfügung stehen. Denn sonst hättest du nicht auf die Problematik mit den Compiler-Optimierungen hingewiesen. Ich bin mir sicher dass sich die meisten Gentoo-Nutzer bewusst sind, das es durch das sehr flexible System (Portage) auch zu vielen Problemen kommen kann.
Ich verwende Gentoo seit nun etwa 8-9 Jahre, und setze es immer noch sehr gerne ein. Im Moment gibt mir Portage z.B. einen Hinweis, dass die aktuell installierte Chrome-Version (21.0.1180.55_beta148257, wird Binär ausgeliefert) noch eine ältere "libudev" verwendet, obwohl ich schon eine neuere udev-Version installiert habe. Aber Portage (ab v2.2) bietet ja die Möglichkeit, die ältere Bibliothek so lange zu behalten, wie eine Anwendung sie benötigt. Erst sobald ich eine Chrome-Version Installiere, die die neuere lib verwendet, und kein anderes Programm diese Lib mehr benötigt, löscht Portage sie automatisch. Aber so lange kann ich Chrome immer noch wie gewohnt weiterverwenden, obwohl ich schon längst eine neuere udev-Version Installiert habe.