Suche Gentoo ähnliches BS
-
KasF schrieb:
Ich verschaffe mir mal gerade nen Überblick über Arch, wobei Fedora auch nen recht sympatischen Eindruck macht.
Wenn Du eine Distro mit möglichst viel Bottom-Up-Setup möchtest, ist Fedora keine gute Wahl, das ist schon sehr stark auf 0815-Gnome-Setups zugeschnitten. Ich persönlich mag auch einfach rpm-basierte Distros sehr ungerne, aber das ist natürlich Geschmackssache.
-
nman schrieb:
Ich persönlich mag auch einfach rpm-basierte Distros sehr ungerne, aber das ist natürlich Geschmackssache.
Wieso, wenn ich fragen darf ?
-
Arch scheint recht nett zu sein. Vielleicht teste ich es mal demnächst in ner VM. Hast du nochn anderen Tipp ?
-
KasF schrieb:
Wieso, wenn ich fragen darf ?
http://en.wikipedia.org/wiki/Dependency_hell
Ist zwar mittlerweile wesentlich besser als früher, aber apt und Konsorten sind immer noch besser.
Fedora ist außerdem in letzter Zeit erstaunlich instabil. Die sind zwar aktuell einer der großen Innovationstreiber in der Desktop-GNU/Linux-Welt, aber man merkt dem Projekt auch an, dass es die defacto Beta für RHEL ist.
-
KasF schrieb:
Arch scheint recht nett zu sein. Vielleicht teste ich es mal demnächst in ner VM. Hast du nochn anderen Tipp ?
Lade Dir einfach mal ein paar der bekannteren Distros herunter und probiere die in der VM aus.
Ich bin auch riesiger Grml-Fan, habe allerdings nur wenig Erfahrungen mit deren HD-Installation. Wobei die sehr kompetente Entwickler haben und seit Jahren die mit Abstand beste Live-Distro machen.
-
Die use-flags bringen doch eh nicht viel.
Du verplemerst doch viel mehr Zeit an der ganzen Gentoocompiliererei, als daß du durch die paar use-flags reinholen kannst.
Das ist ineffizient.
Außerdem kostet es so mehr Strom, weil dein Rechner ständig unter Volllast am compilieren ist.Nimm einfach Ubuntu und such dir das passende, was du noch so brauchst, einfach dazu.
Ich mach das auch so und habe wieder viel mehr Zeit für andere, wichtige Dinge.
-
nman schrieb:
KasF schrieb:
Wieso, wenn ich fragen darf ?
Das sieht mir sehr sehr stark nach FUD aus und sollte dort in der Wikipedia dringend geändert werden. Die im Textverweis geschilderten Probleme haben absolut gar nichts mit RPM zu tun:
On the Linux Annoyances mailing list, John Andersen suggested the following method for dealing with what is commonly known as RPM Hell:
You try to install XYZ package but it has a prerequisite for abc.lib.so.7.
You take a swig of beer.
You Google around a bit and find that abc.lib.so.7 is supplied by package abc-2.19-45.rpm.
You hunt around for that RPM on the Web (since a quick ls abc* | less on the distribution CD didn't turn up anything) and you find it on a Bulgarian web site and download it.
You try to install it, and it requires lib-hij.so.2.
You take a swig of beer.
You Google around a bit and find that lib-hij.so.2 is supplied by package efg-5.10-54.rpm.
You hunt around for that RPM on the Web (those dang CDs again) and you find it on an Australian web site and download it.
You try to install it, and it requires lib-klm.so.1.
You take a swig of beer.
"Hmm", you think to yourself, "maybe I'll just download and compile the source code".
No good, the configure script will just die on you, with unresolved externals and more prerequisites.
Das bedeutet nur, dass die Abhängigkeiten nicht verfügbar sind. Das kann ein .deb Paket, ein pkg.tar.gz (Arch Linux) oder ein build in einer Source-basierten Distribution genauso wenig einfach aus dem Ärmel zaubern. Auch Windows kann das nicht. Drittanbieter sollten sich an die LSB halten, zumindest um zu sehen, was in einer Linux Distribution generell verfügbar sein sollte. Die Pflicht- APIs der LSB sollten in jeder Distribution verfügbar sein. Ich weiß nicht, wie das bei Gentoo ist, aber Arch Linux hält (oder hielt, ich bin da nicht mehr auf dem neuesten Stand) absolut nichts von der LSB. Da wirst du wesentlich mehr Probleme haben, als mit RPM-basierten Distributionen. Mal abgesehen davon, dass RPM das in der LSB standardisierte Paketformat ist
Trotzdem wäre Arch Linux noch ein Bottom-Up System, das dir gefallen könnte. Auch Slackware könnte man ausprobieren. Debian bietet eine Minimalinstallation an, genauso wie viele andere Distributionen. Bei openSUSE kannst du bei der Installation von DVD beliebige Pakete auswählen, die du installieren willst, kannst also so minimal installieren, wie du Lust hast, oder gleich die Pakete, die du bei Gentoo nachträglich installieren würdest zur Installation hinzufügen.
-
Du hast den Wikipedia-Eintrag wohl missverstanden. Rpm konnte früher Dependencies nicht selbst auflösen. Überhaupt nicht.
Dass nicht-RPM-basierte Distros häufig nicht vollständig LSB-konform sind, ist übrigens kein Wunder, da die LSB vorschreibt, dass Pakete per RPM installiert werden können sollen.
Ist aber völlig uninteressant, schau Dir doch mal genauer an, was in der LSB standardisiert ist. Größtenteils sehr wenig aussagekräftiges bzw. interessantes Zeug. Deine Ausführungen dazu, dass man sich auf LSB-standardisierte APIs verlassen soll, sind übrigens nicht sehr hilfreich. Die LSB kann konzeptbedingt nicht alle Libraries abdecken, die man als Entwickler verwendet und brauchen kann.
-
Der harte Arbeiter schrieb:
Die use-flags bringen doch eh nicht viel.
Du verplemerst doch viel mehr Zeit an der ganzen Gentoocompiliererei, als daß du durch die paar use-flags reinholen kannst.
Achtung, Useflags != CFLAGS.
Useflags sind durchaus eine sehr praktische Sache, die ich bei nicht sourcebasierten Distros regelmäßig vermisse.
-
nman schrieb:
Du hast den Wikipedia-Eintrag wohl missverstanden. Rpm konnte früher Dependencies nicht selbst auflösen. Überhaupt nicht.
dpkg kann das auch nicht. Auch heute nicht. Das Auflösen von Abhängigkeiten ist bei diesen beiden Systemen nicht die Aufgabe des Paketverwalters, sondern eines Frontends. Das mit dpkg häufig verwendete apt gibt es auch für rpm, und smart, yum, urpmi und zypper sind qualitativ und funktional mehr als nur ebenbürtig. Zypper war für mich sogar einer der Hauptgründe, warum ich von Arch Linux auf SuSE gewechselt bin.
nman schrieb:
Dass nicht-RPM-basierte Distros häufig nicht vollständig LSB-konform sind, ist übrigens kein Wunder, da die LSB vorschreibt, dass Pakete per RPM installiert werden können sollen.
Die LSB hat aus Rücksicht auf Debian nur eine Untermenge von RPM spezifiziert, so dass RPM Pakete zusammen mit Debian-Paketen verwendet werden können (zum Beispiel mit Alien). Debian ist also nicht weniger LSB-konform als Red Hat oder SuSE. Es gibt natürlich Unterschiede in der Unterstützung, aber das dürfte eher am kommerziellen Interesse der Entwickler Novell/SuSE GmbH bzw Red Hat liegen, die Drittanbieter anlocken und es ihnen deswegen möglichst einfach machen wollen.
nman schrieb:
Ist aber völlig uninteressant, schau Dir doch mal genauer an, was in der LSB standardisiert ist. Größtenteils sehr wenig aussagekräftiges bzw. interessantes Zeug. Deine Ausführungen dazu, dass man sich auf LSB-standardisierte APIs verlassen soll, sind übrigens nicht sehr hilfreich. Die LSB kann konzeptbedingt nicht alle Libraries abdecken, die man als Entwickler verwendet und brauchen kann.
Die LSB hat durchaus seine Schwächen, ist aber auch eine ABI-Spezifikation. Der API-Teil funktioniert recht gut und auch der ABI- Teil "meistens". Keine Spezifikation kann Konzeptbedingt alle Bibliotheken abdecken. Das gilt für LSB genauso wie für Windows oder Mac OSX. Zur Not muss man eben statisch linken, oder die Bibliotheken mitliefern. Die in dem Artikel erläuterten Probleme sind eher auf die mangelhaften Paketierungsfähigkeiten der Entwickler des Beispielpaketes XYZ zurück zu führen. Stell dir mal eine Anwendung für Windows vor, die die Qt-Bibliotheken benötigt, diese aber nicht mitliefert oder anbietet und auch sonst keinen Hinweis darauf bietet. Wer ist dann Schuld?
-
Franklin Ulano Doosevelt schrieb:
dpkg kann das auch nicht.
Nur dass es apt schon seit Ewigkeiten gibt. Seit wann verwendet RedHat nochmal yum? Noch keine fünf Jahre. Das machte dist-upgrades von SuSE früher zu einer äußerst unangenehmen Angelegenheit. Bei RedHat war es auch verdammt unschön. Hast Du je up2date verwendet? Das Ding war völlig kaputt.
Debian ist also nicht weniger LSB-konform als Red Hat oder SuSE. Es gibt natürlich Unterschiede in der Unterstützung, aber das dürfte eher am kommerziellen Interesse der Entwickler Novell/SuSE GmbH bzw Red Hat liegen, die Drittanbieter anlocken und es ihnen deswegen möglichst einfach machen wollen.
Und daran, dass die Zertifizierung und die automatisierten LSB-Compliance-Tests völliger Schwachsinn sind und Distro-Maintainer Ressourcen kostet - und zwar nicht zu knapp. Ulrich Drepper, der Maintainer der Glibc, hat dazu irgendwann mal ein paar recht interessante Sachen geschrieben.
Stell dir mal eine Anwendung für Windows vor, die die Qt-Bibliotheken benötigt, diese aber nicht mitliefert oder anbietet und auch sonst keinen Hinweis darauf bietet. Wer ist dann Schuld?
Es ist ja nicht so, dass diese Abhängigkeiten nicht angegeben worden wären, sonst hätte sich rpm ja nie über fehlende Pakete beschwert. Es war schlichtweg nicht sinnvoll möglich, zusätzliche Repos sinnvoll zu verwenden, schon allein aufgrund der Beschränkungen von rpm.
Die LSB hatte ein paar gute Ideen und hat einige gute Sachen hervorgebracht, aber sie als Indikator für die Qualität einer GNU/Linux-Distro heranzuziehen ist einfach keine gute Idee.
-
nman schrieb:
Franklin Ulano Doosevelt schrieb:
dpkg kann das auch nicht.
Nur dass es apt schon seit Ewigkeiten gibt. Seit wann verwendet RedHat nochmal yum? Noch keine fünf Jahre. Das machte dist-upgrades von SuSE früher zu einer äußerst unangenehmen Angelegenheit. Bei RedHat war es auch verdammt unschön. Hast Du je up2date verwendet? Das Ding war völlig kaputt.
Schon richtig. Das ist aber eine Schwäche der Distribution, nicht eine Schwäche von RPM. Außerdem wird hier ja heute nach einer neuen Distribution gesucht, nicht vor ein paar Jahren. Auch der Wikipedia-Artikel ist falsch, da er die RPM-Hell noch in der Gegenwart beschreibt und zudem das Problem RPM zuschiebt und nicht den Frontends.
nman schrieb:
Debian ist also nicht weniger LSB-konform als Red Hat oder SuSE. Es gibt natürlich Unterschiede in der Unterstützung, aber das dürfte eher am kommerziellen Interesse der Entwickler Novell/SuSE GmbH bzw Red Hat liegen, die Drittanbieter anlocken und es ihnen deswegen möglichst einfach machen wollen.
Und daran, dass die Zertifizierung und die automatisierten LSB-Compliance-Tests völliger Schwachsinn sind und Distro-Maintainer Ressourcen kostet - und zwar nicht zu knapp. Ulrich Drepper, der Maintainer der Glibc, hat dazu irgendwann mal ein paar recht interessante Sachen geschrieben.
Sie sind kein völliger Schwachsinn, man darf sich nur nicht voll und ganz drauf verlassen. Die LSB ist einfach momentan der einzige Konsens zwischen fast allen Linux-Distributionen. Woran soll man sich denn sonst orientieren, wenn man Software für "Linux" entwickeln will und nicht für "Distribution x"? Ob eine Distribution nun offiziell zertifiziert ist, oder einfach nur LSB als Feature anbietet, ist mir auch ziemlich egal. Aber eine Distribution, die sich offen davon distanziert ist für mich keine passable Linux Distribution, weil ich dann zu sehr auf die von der Distribution selbst angebotenen Pakete abhängig bin.
nman schrieb:
Stell dir mal eine Anwendung für Windows vor, die die Qt-Bibliotheken benötigt, diese aber nicht mitliefert oder anbietet und auch sonst keinen Hinweis darauf bietet. Wer ist dann Schuld?
Es ist ja nicht so, dass diese Abhängigkeiten nicht angegeben worden wären, sonst hätte sich rpm ja nie über fehlende Pakete beschwert. Es war schlichtweg nicht sinnvoll möglich, zusätzliche Repos sinnvoll zu verwenden, schon allein aufgrund der Beschränkungen von rpm.
Welche Beschränkungen von RPM? Oder meinst du wieder die Beschränkungen der Frontends? Wie gesagt, subjektiv ist Zypper für mich im Moment das beste Frontend zu einem Paketmanager das es gibt und es besitzt derzeit leider nur ein RPM-Backend. Was mir insbesondere daran gefällt ist die Auflösung von Abhängigkeiten (SAT/libsatsolver) und die Verwendung mehrerer, sogar inkompatibler, Repositories (Dank Prioritäten und einer "Paket-Anbieter-Bindung"). Genau das sind die Schwächen von alten RPM-Frontends gewesen. Heute noch der RPM-Welt ein Mangel an hochwertigen Frontends oder gar ein Mangel im Design von RPM selbst vorzuwerfen ist absolut absurd. Man hört immer wieder, dass jemand RPM basierte Distributionen niemals anrühren würde, weil es früher keine guten Frontends gab. Das ist doch Blödsinn. Heute gibt es sie, also ist RPM definitiv kein Grund mehr die Finger von einer Distribution zu lassen. Vor Allem nicht für die Nutzer, denn die bekommen von dem Backend absolut überhaupt nichts mit.
Ich kritisiere ja auch nicht den von Wikipedia verlinkten Artikel an, sondern dass die Wikipedia selbst den Artikel auf RPM anstatt dem Frontend bezieht und außerdem die Information über die Frontends nicht mehr aktuell ist. Das sollte in der Wikipedia, wie es auch bei Mac OS getan wurde auch erwähnt werden, denn auf genau solche Fehlinformationen basieren viele Missverständnisse in der Linux-Welt, wenn es um RPM geht. Zum einen die Verwechslung von RPM mit dem Frontend (meistens wird RPM mit APT verglichen), zum Anderen veraltete (aber damals durchaus richtige) Informationen bezüglich der verfügbaren Frontends für RPM.
nman schrieb:
Die LSB hatte ein paar gute Ideen und hat einige gute Sachen hervorgebracht, aber sie als Indikator für die Qualität einer GNU/Linux-Distro heranzuziehen ist einfach keine gute Idee.
Natürlich nicht. Aber eine gute Unterstützung der LSB ist schon ein guter Indikator dafür, wie gut Pakete von Drittanbietern bei dir funktionieren werden. Denn Drittanbieter wollen auch nicht für jede kleine Distribution alle paar Monate (bei Arch Linux können es auch gut ein paar Minuten sein dank Rolling Release) neue Pakete bauen.
LSB-Kompatibilität oder zumindest dessen Anstreben ist kein Qualitätsindikator, aber durchaus ein Feature.
-
Franklin Ulano Doosevelt schrieb:
Das ist aber eine Schwäche der Distribution, nicht eine Schwäche von RPM.
Das habe ich auch nicht behauptet. Dennoch war das ein Problem der größeren rpm-basierten Distros, siehe oben.
Heutzutage mag ich die großen rpm-basierten Distros aus anderen Gründen nicht. Dass es sich dabei um persönliche Vorlieben handelt, habe ich durchaus nicht verschwiegen.
Auch der Wikipedia-Artikel ist falsch, da er die RPM-Hell noch in der Gegenwart beschreibt und zudem das Problem RPM zuschiebt und nicht den Frontends.
Wo liest Du denn das heraus? Gleich in der Einleitung steht folgendes: "This was mainly attributable to old Linux package managers. Current package managers have largely solved this problem by automatically resolving and downloading dependencies."
Sie sind kein völliger Schwachsinn, man darf sich nur nicht voll und ganz drauf verlassen.
Mehr noch: Man muss wohl teils aktiv um Probleme der Tests herumarbeiten.
Die LSB ist einfach momentan der einzige Konsens zwischen fast allen Linux-Distributionen. Woran soll man sich denn sonst orientieren, wenn man Software für "Linux" entwickeln will und nicht für "Distribution x"?
Das Argument, dass man dank LSB "einfach für Linux entwickeln kann" und das ohne nicht ging, hört man von LSB-Verfechtern oft. Tatsache ist, dass das realistischerweise immer noch nicht so einfach ist. Das, was heutzutage Anbietern kommerzieller GNU/Linux-Software leichter gemacht wird, ist größtenteils freedesktop.org uä. zu verdanken.
Wenn ich kommerzielle Software verwenden möchte, die für RHEL zertifiziert ist, stehen meine Chancen, sie mit Debian oder OpenSuSE in einer Produktivumgebung vernünftig laufen lassen zu können, meistens immer noch eher schlecht.
Aber eine Distribution, die sich offen davon distanziert ist für mich keine passable Linux Distribution, weil ich dann zu sehr auf die von der Distribution selbst angebotenen Pakete abhängig bin.
Was wäre denn ein Beispiel für so eine Distro? Ganz nebenbei, abhängig vom Distributor bist Du bis zu einem gewissen Grad immer. Ubuntu hat seine PPAs, die machen viel wieder wett, aber ansonsten siehts erstaunlich düster aus da draußen.
Welche Beschränkungen von RPM? Oder meinst du wieder die Beschränkungen der Frontends?
Beides. Aber die Frontend-Beschränkungen überwogen damals natürlich. Erinnere mich nur ungern daran zurück, wie furchtbar früher alternative Repos außerhalb der Debian-Welt waren.
Wie gesagt, subjektiv ist Zypper für mich im Moment das beste Frontend zu einem Paketmanager das es gibt und es besitzt derzeit leider nur ein RPM-Backend. Was mir insbesondere daran gefällt ist die Auflösung von Abhängigkeiten (SAT/libsatsolver) und die Verwendung mehrerer, sogar inkompatibler, Repositories (Dank Prioritäten und einer "Paket-Anbieter-Bindung").
Die MiniSat-basierende Dependency-Auflösung ist eine nette Sache. Aber hat Dir das praktisch schonmal irgendwas gebracht, was Du bei Debian oä. nicht hattest? Die Prioritäten und Paket-Anbieter-Bindung ist doch auch nichts anderes als Debians Apt-Pinning, oder?
Man hört immer wieder, dass jemand RPM basierte Distributionen niemals anrühren würde, weil es früher keine guten Frontends gab. Das ist doch Blödsinn.
Vergiss nicht, dass viele User, die derartige Aussagen tätigen, immer wieder versucht haben, rpm-basierte Distros zu verwenden und sich immer wieder daran die Finger verbrannt haben. Einige von uns haben schon so viele Versprechen, dass jetzt endlich alles toll wird, hinter sich, dass sie aktuellere Versionen dieser Distros einfach nicht mehr in Betracht ziehen würden. Zumindest nicht für private Maschinen. Warum auch? Was haben andere Distros, was Debian oder Ubuntu nicht haben?
(Und nein, RHEL und SLES und Co. zähle ich nicht dazu, Server werden ohnehin vollständig per Configuration Management System verwaltet. Da ist die Wahl der Distro weniger spannend, weil man jederzeit für Spezialfälle die passendste Distro auswählen kann.)Zum einen die Verwechslung von RPM mit dem Frontend (meistens wird RPM mit APT verglichen), […]
Warum wundert Dich das? Apt hatte eben jahrelang keinerlei ernstzunehmende Pendants. Als User interessiert mich primär, was ich mit einer Distro machen kann oder eben auch nicht. Und wenn die rpm-basierten Distros Mist waren, dann wurde das eben (fälschlicherweise) angekreidet. (Die vielen unterschiedlichen Frontends ("smart, yum, urpmi und zypper") helfen natürlich auch nicht unbedingt dabei, den schlechten Ruf von RPM zu verbessern, wenn man in der Debian-basierenden Welt einfach überall Apt verwenden kann.)
Technisch hast Du natürlich Recht, aber interessiert das da draußen irgendjemanden? Nein. Genausowenig, wie sich die Leute dafür interessieren, dass sie nicht Linux sondern GNU/Linux verwenden oder dass nicht ihr OpenSuSE sondern ihr KDE 4 instabil ist.
Natürlich nicht. Aber eine gute Unterstützung der LSB ist schon ein guter Indikator dafür, wie gut Pakete von Drittanbietern bei dir funktionieren werden. Denn Drittanbieter wollen auch nicht für jede kleine Distribution alle paar Monate (bei Arch Linux können es auch gut ein paar Minuten sein dank Rolling Release) neue Pakete bauen.
Ich habe jahrelang Gentoo verwendet und hatte da durchaus einiges an proprietärer Software laufen, die nicht in Gentoo paketiert war. Schwierigkeiten mit nicht funktionierender Software hatte ich nie.
-
Ach ja, Mittlerweile sind wir schon ziemlich weit Offtopic. Falls Du weiterdiskutieren möchtest, gib Bescheid, ich kann den Thread absplitten. Werde mich nur die nächsten zwei, drei Tage wohl nicht beteiligen.
-
Sooo, nun habe ich seit zwei Tagen Arch drauf und bin voll zufrieden. Gentoo hat sich leider verabschiedet.
Dennoch lebt noch ein bissl portage/emerge in pacman weiter, zudem hat Arch echt sehr gute Dokumentationen und bis jetzt lief alles reibungslos und super flott