Manche Pakete sind in den Repos. nicht vorhanden oder entsprechen ein älteren Stand (auch bei Distributionen die normalerweise das neueste von neusten anbieten). Manchmal fehl etwas was man gern hätte und in dem Fall kann eine eigene Erweiterung eingebaut werden. Damit gibt es reichlich Möglichkeit selbst zu kompilieren. Eigene Programme oder Programme an den man mitarbeitet werden natürlich immer wieder kompiliert.
Nur im Notfall. Und das heißt bei mir: Nur wenn kein offizielles Debianpaket (d.h. in Debian-Repos oder direkt auf der jeweiligen Entwicklerseite) vorhanden ist. Gelegentlich habe ich auch schon einzelne Pakete von Ubuntu installiert, aber nur wenn es keine weiterführenden Abhängigkeiten gibt.
Früher, also im letzten Jahrtausend habe ich vor Allem den Kernel compiliert (SuSE). Heute (Debian) bin ich mit der Software in den Repos zufrieden und spare mir den Aufwand.
Jupp, dafür muss man aber auch immer dran bleiben. Hatte Arch auch mal eine zeit lang, war mir aber zuviel frickelei. Bin dann wieder zurück zu Debian stable
Jupp, dafür muss man aber auch immer dran bleiben. Hatte Arch auch mal eine zeit lang, war mir aber zuviel frickelei. Bin dann wieder zurück zu Debian stable
Hier kompiliet man ohnehin fast ausschließlich aus den Quellen und dadurch, dass der Bau lokal auf dem jeweiligen Rechner geschieht und daher nur gegen die dort vorhandenen Libraries gebaut wird, ist das ganze die Abhängigkeiten betreffend deutlich unkritischer. Nach erfolgreichem Bauen, sind diese Abhängigkeiten zwangsläufig erfüllt.
Hier ist keine Synchronität zum Build-System des Distributors erforderlich, die eben genau diese im Artikel erwähnten Probleme mit sich bringt und dessen Backporting erforderlich macht, wenn man nicht selber bauen möchte.
Warum so viele eben nicht selber Kompilieren möchten, wissen sie ja sellbst am besten. Das es aber auch einfacher und Komfortabler geht beweist Gentoo. Hier läuft dieser Vorgang weithestgehend automatisiert und daher sehr komfortabel ab, trotzdem hat man wesentlich einfacher die Kontrolle über sämtliche Optionen des Paket-Bauens und dazu noch Update-Persistent.
Das und vieles mehr, machen Gentoo zu einer der flexibelsten Distributionen im Linux-Universum.
Das und vieles mehr, machen Gentoo zu einer der flexibelsten Distributionen im Linux-Universum. ;-)
Das mag sein, aber ich meine Gentoo-Zeiten sind schon lange vorbei. Ich hatte irgendwann keine Lust mehr darauf, den Rechner nicht mehr benutzen zu können, nur weil für ein größeres Programm ein Sicherheitsupdate reinkam und der Rechner stundenlang mit Kompilieren beschäftigt war.
Ich finde erher das Gegenteil ist der Fall! Da in den letzten Jahren die Rechenleistung derart gestiegen ist, spielt die benötigte Zeit des Kompilierens eine stetig kleiner werdende Rolle.
Dagegen spielt die nach wie vor vorhandene Wahlfreiheit/Entscheidungsfreiheit in Zeiten von unpopulären Entscheidungen eine immer größere Rolle, zumindest für mich. Ich sag jetzt aber nicht Jehova.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Feb 2015 um 16:49.
Genau, das stimmt grundsätzlich erst mal. Allerdings gibt es genügend Quellcode der durch Threading nicht profitiert (worauf der Vorposter sicher anspielen möchte).
Das kann Portage aber mit den richtigen Einstellung aber hervorragend kompensieren, indem es dann einfach mehr von anderen Pakete parallel baut, solange bis z.B. eine bestimmte Anzahl oder ein bestimmter Load erreicht sind. Wenn man das gut auf seine Maschine hin abgestimmt hat, dann bleibt der Desktop immer noch schön responsive, trotz hoher Auslastung beim Kompilieren.
Kannst du mir mal erklären, wieso du den Rechner während des Kompilierens nicht benutzen kannst? Das läuft mit nice im Hintergrund. Du kannst nebenher weiterarbeiten wie gewohnt und wenn es fertig ist, dann ist es fertig.
Ja, Gentoo ist im Prinzip eine tolle Sache. Ich hatte es mal auf dem Laptop und war zufrieden, bis ich an einem Workshop nmap und ein paar weitere Tools brauchte. Nach vier Stunden war endlich fertig kompiliert und der Workshop auch vorbei. Danach bin ich wieder zurück zu Debian.
Das gleiche mit dem PC, zufrieden und stabil mit Gentoo unterwegs, aber jedes grössere Update von KDE oder so führe dazu, dass ich den Rechner über Nacht kompilieren lassen musste.
Ist schon viele Jahre her, aber ich setze seither lieber rpm oder deb Pakete.
Beim aufsetzten von Gentoo hab ich allerdings sehr viel über Linux gelernt.
Das gleiche mit dem PC, zufrieden und stabil mit Gentoo unterwegs, aber jedes grössere Update von KDE oder so führe dazu, dass ich den Rechner über Nacht kompilieren lassen musste.
Eben. Und nicht jeder hat Lust den Rechner die ganze Nacht durchlaufen zu lassen, nur um ein paar Sicherheits -oder Bugfix-Updates zu installieren.
Also ich weis jetzt nicht ob du mit "aktuell" High End meinst, aber ich z.b. habe einen FX-6300. Ne ganze Nacht brauchst du fürs aktualisieren nicht, da musst du wirklich schon sehr lange Zeit jegliches Update verweigert haben das du ne ganze Nacht aktualisieren müsstest, bei mir könnte ich in der Zeit mein ganzes System neu bauen.
Die meisten Pakete bauen auf allen Kernen, ein paar wenige, aber in der Regel auch sehr kleine bauen nur auf einer. Die einzigen Packete die unangenehm lange bauen sind Chromium (1h) und Libreoffice (2h), wobei du die als Binärdateien auch runterladen kannst.
Bei den meisten Pakete dauert .configure länger als das eigentliche Bauen. Bei mir wird /var/tmp/portage aber auch in den RAM gemountet (16G)ich weis nicht wie sie sich das letztendlich auf die Dauer auswirkt, weil ich Gentoo nie ohne Betreibe, ich denke aber das es auf einer aktuellen i5/i7 CPU oder nem Xeon ned langsamer ist =D
Auf nem aktuellen System geht das ganze auch neben der normalen Nutzung, hatte noch nie das Problem dass das System unresponsiv war nur weil grad im Hintergrund kompiliert wurde
Auch bei quellbasierenden Distros ist man von dem Build-System und von Backports abhängig. Das ist inhärent in Software, falls Software X von Bibliothek A, die wiederum von Bibliothek B, usw. abhängig ist.
Vielleicht ist bei quellbasierenden Distros dies ein wenig abgemildert, weil die Software nur API kompatibel sein muss und nicht ABI kompatibel.
Die Ausnahme ist vielleicht wenn man alle Bibliotheken statisch Einbindet. Deswegen ist auch, z.B. der Chromium Code über ein Gigabyte groß.
"Auch bei quellbasierenden Distros ist man von dem Build-System und von Backports abhängig." Bei Gentoo ist ja bereits ein funktionsfähiges Build-System inklusive passender Toolchain lokal vorhanden. Auch ist man nicht von Backports abhängig, schließlich kann man hier einfach die neuere Version eines Paketes, das z.B. den dringend benötigten Bug-Fix oder das neue Feature enthält hier einfach gegen die lokal vorhandenen Libraries neu bauen, statt lange auf einen Backport warten zu müssen.
Sollte diese neuere Paketversion auch zwingend eine neuere Library als Abhängigkeit verlangen, dann wird diese eben gleich mitinstalliert. Die darauf hin lokal gebrochenen Abhängigkeiten zu anderen Paketen, die noch von der alten vorher installierten Library abhingen, werden durch Neubau gegen die nun Neue Version wiederhergestellt. Anschließend ist das System wieder in einem konsistenten Zustand.
Von daher ist das Problem mehr als nur deutlich abgemildert und genau hierein liegt auch die größere Unabhängigkeit ganz allgemein, wenn man lokal aus den Qellen kompiliert. Lästig ist's halt nur, wenn man sich um den ganzen Abhängigkeitsbaum selber kümmern muss. Doch bei Gentoo erledigt das ja Portage für die User.
Lass mal das Beispiel mit dem statischen linken weg, das geht natürlich immer, hat aber nichts mit unserer Problematik zu tun und bringt die bereits von Dir erwähnten Nachteile mit sich.
Du hast das gleiche Problem wenn z.B. der Bug-Fix nur in einer neueren Version der Bibliothek vom Entwickler bereitgestellt wurde, diese aber mit einer deiner älteren Anwendung nicht mehr kompatibel ist. Dann musst du auch auf einen Backport warten.
Ich hatte das Problem des öfteren mit Ruby Anwendungen, wo ich die Gems kompilieren musste. Deswegen gibt es den Bundler, der die Gems isolieren kann und mehrere gleiche Gems mit unterschiedlichen Versionen nebeneinander installiert haben kann. Oder in Haskel für die Gitit Wiki Software.
Backport heißt ja nur dass man den Bug oder Feature in eine älteren Version einbaut, weil die Anwender noch nicht auf die neuste Version updaten können oder wollen. Ob die Anwendung nun vom Anwender selber kompiliert wird oder nicht, hat damit erst mal nichts zu tun.
Wenn du selbst kompilierst musst du einfach nicht auf die Package-Maintainer warten. Oder du bist nicht auf den Entwickler angewiesen dir ein Paket bereitzustellen. Ich hatte öfters die Situation, dass nur ein DEB Paket bereitstand und nur für Ubuntu.
"Du hast das gleiche Problem wenn z.B. der Bug-Fix nur in einer neueren Version der Bibliothek vom Entwickler bereitgestellt wurde, diese aber mit einer deiner älteren Anwendung nicht mehr kompatibel ist. Dann musst du auch auf einen Backport warten." Steht die Anwendung schon in einer neueren Version zur Verfügung, installiere ich einfach diese, da sie in der Quelle ja als erstes verfügbar wird und ich nicht warten muss, bis es davon ein binary Paket gibt (unter Gentoo dann höchsens auf ein ebuild, dass kann man aber auch selbst machen).
"Ich hatte das Problem des öfteren mit Ruby Anwendungen, wo ich die Gems kompilieren musste. Deswegen gibt es den Bundler, der die Gems isolieren kann und mehrere gleiche Gems mit unterschiedlichen Versionen nebeneinander installiert haben kann. Oder in Haskel für die Gitit Wiki Software." Für das parallele installieren von unterschiedlichen Versionen des gleichen Pakets/Library stehen in Gentoo sog. Slots zur Verfügung. Das beste daran ist, dass diese bereits von den Paketmantainern definiert werden, um genau dieses Problem bereits für den Anwender zu lösen! Kann man bei besonderen Wünschen natürlich auch selbst definieren.
"Wenn du selbst kompilierst musst du einfach nicht auf die Package-Maintainer warten. Oder du bist nicht auf den Entwickler angewiesen dir ein Paket bereitzustellen. Ich hatte öfters die Situation, dass nur ein DEB Paket bereitstand und nur für Ubuntu." Wie gesagt, bei Open Source wird ja als estes der Quellcode zur Verfügung gestellt, aber zur Not kann Gentoo kann auch deb und rpm Pakete verarbeiten, will man aber eher nicht, weil man sich damit der erweiterten Möglichkeiten zur Einflußnahme (Stichwort USE-Flags) beraubt.
Meine Software compiliere ich meist aus beruflichen Gründen selbst. Bei der Systempflege compiliere ich aber nur, wenn es gar nicht anders geht und ich etwas dringend brauche.
Manchmal, wenn kein passendes Paket vorhanden ist compiliere ich selbst.
Nicht selten hat es aber auch Gründe, dass es keines gibt. So passt die Toolchain oder eine Bibliothek nicht richtig, irgendwas fehlt oder liegt in der falschen Version vor. Das ganze zu recht zu biegen ist dann aufwändiger, als es eigentlich wert ist.
Ich selber nutze jetzt seit fast 3 Jahren nur noch Arch auf meinem privaten Rechner und habe auch diverse Pakete aus dem AUR installiert.
Manch einer wird meine Frage vielleicht als etwas merkwürdig oder blöd empfinden ;), aber kann man das überhaupt als "selbst kompiliert" bezeichnen, wenn ich mir gelegentlich Software (auch von git) aus dem AUR mittels yaourt installiere?
Oder wie kann man "selbst kompilieren" am besten umschreiben? Ist dabei eine "Hilfe" (bzgl. des Komforts) wie sie yaourt bietet mit einbegriffen?
Aus meiner Sicht schon, aber ich bin letztlich nur ein Endanwender mit erweiterten Linux- und allgemeinen IT-Kenntnissen und habe mit Programmieren und Entwickeln von Software nichts zu tun.
Von Dümmer geht immer am So, 22. Februar 2015 um 17:44 #
Ganz deiner Meinung, ich lass sogar meine Computerspiele vom Nachbarn durchspielen, das spart nämlich auch Strom und Zeit, wenn ich die nicht spielen muss.
das ärgert mich, für das schach programm Scid , 2 verschiede versionen: scid for pc, auch, gibt es nicht fertige deb pakete 64 bit von ubuntu oder debian, und statisch.
Compiliere selten, z.B. wenn kein Binärpaket vorhanden ist oder spezielle Anforderungen bestehen.
siehe Betreff - ansonsten wird alles durch JIT abgedeckt
Manche Pakete sind in den Repos. nicht vorhanden oder entsprechen ein älteren Stand (auch bei Distributionen die normalerweise das neueste von neusten anbieten). Manchmal fehl etwas was man gern hätte und in dem Fall kann eine eigene Erweiterung eingebaut werden. Damit gibt es reichlich Möglichkeit selbst zu kompilieren. Eigene Programme oder Programme an den man mitarbeitet werden natürlich immer wieder kompiliert.
ich viel auf ARM unterwegs bin.
Nur im Notfall. Und das heißt bei mir: Nur wenn kein offizielles Debianpaket (d.h. in Debian-Repos oder direkt auf der jeweiligen Entwicklerseite) vorhanden ist. Gelegentlich habe ich auch schon einzelne Pakete von Ubuntu installiert, aber nur wenn es keine weiterführenden Abhängigkeiten gibt.
Red Hat hat dafür die Software Collections:
https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/1/html/1.2_Release_Notes/chap-RHSCL.html#sect-RHSCL-About
das macht komplilieren auch häufig überflüssig.
Der Jupp
Früher, also im letzten Jahrtausend habe ich vor Allem den Kernel compiliert (SuSE). Heute (Debian) bin ich mit der Software in den Repos zufrieden und spare mir den Aufwand.
Schultze
Archlinux ist meist immer aktuell. Eher selten lege ich bei Programmen aus dem AUR schon mal Hand an..
Jupp, dafür muss man aber auch immer dran bleiben. Hatte Arch auch mal eine zeit lang, war mir aber zuviel frickelei. Bin dann wieder zurück zu Debian stable
Jupp, dafür muss man aber auch immer dran bleiben. Hatte Arch auch mal eine zeit lang, war mir aber zuviel frickelei. Bin dann wieder zurück zu Debian stable
Hier kompiliet man ohnehin fast ausschließlich aus den Quellen und dadurch, dass der Bau lokal auf dem jeweiligen Rechner geschieht und daher nur gegen die dort vorhandenen Libraries gebaut wird, ist das ganze die Abhängigkeiten betreffend deutlich unkritischer.
Nach erfolgreichem Bauen, sind diese Abhängigkeiten zwangsläufig erfüllt.
Hier ist keine Synchronität zum Build-System des Distributors erforderlich, die eben genau diese im Artikel erwähnten Probleme mit sich bringt und dessen Backporting erforderlich macht, wenn man nicht selber bauen möchte.
Warum so viele eben nicht selber Kompilieren möchten, wissen sie ja sellbst am besten.
Das es aber auch einfacher und Komfortabler geht beweist Gentoo. Hier läuft dieser Vorgang weithestgehend automatisiert und daher sehr komfortabel ab, trotzdem hat man wesentlich einfacher die Kontrolle über sämtliche Optionen des Paket-Bauens und dazu noch Update-Persistent.
Das und vieles mehr, machen Gentoo zu einer der flexibelsten Distributionen im Linux-Universum.
Ich finde erher das Gegenteil ist der Fall!
Da in den letzten Jahren die Rechenleistung derart gestiegen ist, spielt die benötigte Zeit des Kompilierens eine stetig kleiner werdende Rolle.
Dagegen spielt die nach wie vor vorhandene Wahlfreiheit/Entscheidungsfreiheit in Zeiten von unpopulären Entscheidungen eine immer größere Rolle, zumindest für mich.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Feb 2015 um 16:49.Ich sag jetzt aber nicht Jehova.
Die Softwaregröße wächst doch auch mit, mal abgesehen das die Kompilierorgien kaum linear auf die Threads verteilen kannst.
Verstehe ich jetzt nicht, kompilieren ist einer der Tasks der sehr gut mit den Anzahl Kernen skaliert.
Genau, das stimmt grundsätzlich erst mal.
Allerdings gibt es genügend Quellcode der durch Threading nicht profitiert (worauf der Vorposter sicher anspielen möchte).
Das kann Portage aber mit den richtigen Einstellung aber hervorragend kompensieren, indem es dann einfach mehr von anderen Pakete parallel baut, solange bis z.B. eine bestimmte Anzahl oder ein bestimmter Load erreicht sind.
Wenn man das gut auf seine Maschine hin abgestimmt hat, dann bleibt der Desktop immer noch schön responsive, trotz hoher Auslastung beim Kompilieren.
Kannst du mir mal erklären, wieso du den Rechner während des Kompilierens nicht benutzen kannst? Das läuft mit nice im Hintergrund. Du kannst nebenher weiterarbeiten wie gewohnt und wenn es fertig ist, dann ist es fertig.
Ja, Gentoo ist im Prinzip eine tolle Sache. Ich hatte es mal auf dem Laptop und war zufrieden, bis ich an einem Workshop nmap und ein paar weitere Tools brauchte. Nach vier Stunden war endlich fertig kompiliert und der Workshop auch vorbei. Danach bin ich wieder zurück zu Debian.
Das gleiche mit dem PC, zufrieden und stabil mit Gentoo unterwegs, aber jedes grössere Update von KDE oder so führe dazu, dass ich den Rechner über Nacht kompilieren lassen musste.
Ist schon viele Jahre her, aber ich setze seither lieber rpm oder deb Pakete.
Beim aufsetzten von Gentoo hab ich allerdings sehr viel über Linux gelernt.
Richtig.
Allerdings habe ich meine Erfahrungen mit Gentoo vor 10 Jahren oder so gemacht. Hat jemand Erfahrungswerte mit einer aktuellen CPU?
Also ich weis jetzt nicht ob du mit "aktuell" High End meinst, aber ich z.b. habe einen FX-6300. Ne ganze Nacht brauchst du fürs aktualisieren nicht, da musst du wirklich schon sehr lange Zeit jegliches Update verweigert haben das du ne ganze Nacht aktualisieren müsstest, bei mir könnte ich in der Zeit mein ganzes System neu bauen.
Die meisten Pakete bauen auf allen Kernen, ein paar wenige, aber in der Regel auch sehr kleine bauen nur auf einer. Die einzigen Packete die unangenehm lange bauen sind Chromium (1h) und Libreoffice (2h), wobei du die als Binärdateien auch runterladen kannst.
Bei den meisten Pakete dauert .configure länger als das eigentliche Bauen. Bei mir wird /var/tmp/portage aber auch in den RAM gemountet (16G)ich weis nicht wie sie sich das letztendlich auf die Dauer auswirkt, weil ich Gentoo nie ohne Betreibe, ich denke aber das es auf einer aktuellen i5/i7 CPU oder nem Xeon ned langsamer ist =D
Auf nem aktuellen System geht das ganze auch neben der normalen Nutzung, hatte noch nie das Problem dass das System unresponsiv war nur weil grad im Hintergrund kompiliert wurde
Auch bei quellbasierenden Distros ist man von dem Build-System und von Backports abhängig. Das ist inhärent in Software, falls Software X von Bibliothek A, die wiederum von Bibliothek B, usw. abhängig ist.
Vielleicht ist bei quellbasierenden Distros dies ein wenig abgemildert, weil die Software nur API kompatibel sein muss und nicht ABI kompatibel.
Die Ausnahme ist vielleicht wenn man alle Bibliotheken statisch Einbindet. Deswegen ist auch, z.B. der Chromium Code über ein Gigabyte groß.
"Auch bei quellbasierenden Distros ist man von dem Build-System und von Backports abhängig."
Bei Gentoo ist ja bereits ein funktionsfähiges Build-System inklusive passender Toolchain lokal vorhanden.
Auch ist man nicht von Backports abhängig, schließlich kann man hier einfach die neuere Version eines Paketes, das z.B. den dringend benötigten Bug-Fix oder das neue Feature enthält hier einfach gegen die lokal vorhandenen Libraries neu bauen, statt lange auf einen Backport warten zu müssen.
Sollte diese neuere Paketversion auch zwingend eine neuere Library als Abhängigkeit verlangen, dann wird diese eben gleich mitinstalliert. Die darauf hin lokal gebrochenen Abhängigkeiten zu anderen Paketen, die noch von der alten vorher installierten Library abhingen, werden durch Neubau gegen die nun Neue Version wiederhergestellt. Anschließend ist das System wieder in einem konsistenten Zustand.
Von daher ist das Problem mehr als nur deutlich abgemildert und genau hierein liegt auch die größere Unabhängigkeit ganz allgemein, wenn man lokal aus den Qellen kompiliert.
Lästig ist's halt nur, wenn man sich um den ganzen Abhängigkeitsbaum selber kümmern muss.
Doch bei Gentoo erledigt das ja Portage für die User.
Lass mal das Beispiel mit dem statischen linken weg, das geht natürlich immer, hat aber nichts mit unserer Problematik zu tun und bringt die bereits von Dir erwähnten Nachteile mit sich.
Du hast das gleiche Problem wenn z.B. der Bug-Fix nur in einer neueren Version der Bibliothek vom Entwickler bereitgestellt wurde, diese aber mit einer deiner älteren Anwendung nicht mehr kompatibel ist. Dann musst du auch auf einen Backport warten.
Ich hatte das Problem des öfteren mit Ruby Anwendungen, wo ich die Gems kompilieren musste. Deswegen gibt es den Bundler, der die Gems isolieren kann und mehrere gleiche Gems mit unterschiedlichen Versionen nebeneinander installiert haben kann. Oder in Haskel für die Gitit Wiki Software.
Backport heißt ja nur dass man den Bug oder Feature in eine älteren Version einbaut, weil die Anwender noch nicht auf die neuste Version updaten können oder wollen. Ob die Anwendung nun vom Anwender selber kompiliert wird oder nicht, hat damit erst mal nichts zu tun.
Wenn du selbst kompilierst musst du einfach nicht auf die Package-Maintainer warten. Oder du bist nicht auf den Entwickler angewiesen dir ein Paket bereitzustellen. Ich hatte öfters die Situation, dass nur ein DEB Paket bereitstand und nur für Ubuntu.
"Du hast das gleiche Problem wenn z.B. der Bug-Fix nur in einer neueren Version der Bibliothek vom Entwickler bereitgestellt wurde, diese aber mit einer deiner älteren Anwendung nicht mehr kompatibel ist. Dann musst du auch auf einen Backport warten."
Steht die Anwendung schon in einer neueren Version zur Verfügung, installiere ich einfach diese, da sie in der Quelle ja als erstes verfügbar wird und ich nicht warten muss, bis es davon ein binary Paket gibt (unter Gentoo dann höchsens auf ein ebuild, dass kann man aber auch selbst machen).
"Ich hatte das Problem des öfteren mit Ruby Anwendungen, wo ich die Gems kompilieren musste. Deswegen gibt es den Bundler, der die Gems isolieren kann und mehrere gleiche Gems mit unterschiedlichen Versionen nebeneinander installiert haben kann. Oder in Haskel für die Gitit Wiki Software."
Für das parallele installieren von unterschiedlichen Versionen des gleichen Pakets/Library stehen in Gentoo sog. Slots zur Verfügung. Das beste daran ist, dass diese bereits von den Paketmantainern definiert werden, um genau dieses Problem bereits für den Anwender zu lösen! Kann man bei besonderen Wünschen natürlich auch selbst definieren.
"Wenn du selbst kompilierst musst du einfach nicht auf die Package-Maintainer warten. Oder du bist nicht auf den Entwickler angewiesen dir ein Paket bereitzustellen. Ich hatte öfters die Situation, dass nur ein DEB Paket bereitstand und nur für Ubuntu."
Wie gesagt, bei Open Source wird ja als estes der Quellcode zur Verfügung gestellt, aber zur Not kann Gentoo kann auch deb und rpm Pakete verarbeiten, will man aber eher nicht, weil man sich damit der erweiterten Möglichkeiten zur Einflußnahme (Stichwort USE-Flags) beraubt.
Quellenbasierende Distributionen wie Gentoo finde ich ähnlich verachtenswert wie SUVs.
Richtig, Energieverschwendung.
Dazu kommt, dass es die Meme-Distri von 4chan ist und das sagt schon alles.
Meine Software compiliere ich meist aus beruflichen Gründen selbst.
Bei der Systempflege compiliere ich aber nur, wenn es gar nicht anders geht und ich etwas dringend brauche.
Manchmal, wenn kein passendes Paket vorhanden ist compiliere ich selbst.
Nicht selten hat es aber auch Gründe, dass es keines gibt. So passt die Toolchain oder eine Bibliothek nicht richtig, irgendwas fehlt oder liegt in der falschen Version vor. Das ganze zu recht zu biegen ist dann aufwändiger, als es eigentlich wert ist.
kompilierst du noch oder lebst du schon
Ich selber nutze jetzt seit fast 3 Jahren nur noch Arch auf meinem privaten Rechner und habe auch diverse Pakete aus dem AUR installiert.
Manch einer wird meine Frage vielleicht als etwas merkwürdig oder blöd empfinden ;), aber kann man das überhaupt als "selbst kompiliert" bezeichnen, wenn ich mir gelegentlich Software (auch von git) aus dem AUR mittels yaourt installiere?
Oder wie kann man "selbst kompilieren" am besten umschreiben? Ist dabei eine "Hilfe" (bzgl. des Komforts) wie sie yaourt bietet mit einbegriffen?
Aus meiner Sicht schon, aber ich bin letztlich nur ein Endanwender mit erweiterten Linux- und allgemeinen IT-Kenntnissen und habe mit Programmieren und Entwickeln von Software nichts zu tun.
Hallo,
ich lass alles beim Nachbarn kompilieren. So spart man Strom und hat jemanden der für einen die Arbeit macht.:-)
Ganz deiner Meinung, ich lass sogar meine Computerspiele vom Nachbarn durchspielen, das spart nämlich auch Strom und Zeit, wenn ich die nicht spielen muss.
das ärgert mich, für das schach programm Scid , 2 verschiede versionen: scid for pc, auch, gibt es nicht fertige deb pakete 64 bit von ubuntu oder debian, und statisch.
... compilen oft und gerne (wobei das nicht heißt, dass keine Binärpakete zur Verfügung stehen).