Gentoo veröffentlicht Binärversion

 (gentoo.org)
2 Punkte von GN⁺ 2023-12-31 | 1 Kommentare | Auf WhatsApp teilen
  • Gentoo bleibt eine quellbasierte Distribution, bietet aber für langsamere Hardware und eine einfachere Installation nun offizielle Binärpakete zum Download und zur direkten Installation an
  • Der Umfang unterscheidet sich je nach Architektur; für amd64 und arm64 stehen über 20 GB an Paketen sowie täglich aktualisierte Gentoo-stable-Pakete bereit
  • Neue Stage-Installationen enthalten bereits die Konfiguration für Binär-Repositories; bei bestehenden Installationen kann sie durch Hinzufügen einer Konfigurationsdatei unter /etc/portage/binrepos.conf/ genutzt werden
  • Offizielle Pakete liegen im signierbaren GPKG-Format vor; bei fehlgeschlagener Verifikation wird die Installation verweigert, in der Standardeinstellung können aus Kompatibilitätsgründen aber auch unsignierte XPAK-Pakete erlaubt sein
  • Wer USE-Flag-Kombinationen nutzt, die von den Profil-Defaults abweichen, kann Binärpakete nicht ohne Weiteres unverändert verwenden und muss die benötigten Teile mit lokalen Builds kombinieren

Gentoo bietet offizielle Binärpakete an

  • Gentoo stellt die von Portage schon lange unterstützte Funktion für Binärpakete nun als offiziellen Download und zur direkten Installation bereit
  • Ziel ist es, die Arbeitszeit auf langsamer Hardware zu reduzieren und Installation sowie Updates insgesamt komfortabler zu machen
  • Gentoo bleibt wie bisher eine quellbasierte Distribution; Source-Builds und Binärpakete können gemeinsam genutzt werden

Umfang nach Architektur

  • Die meisten Architekturen sind auf das Kernsystem und wöchentliche Updates beschränkt
  • amd64 und arm64 erhalten ein größeres Paketset
    • Auf den Mirrors liegen mehr als 20 GB an Paketen
    • Enthalten sind unter anderem LibreOffice, KDE Plasma, Gnome und Docker
    • Gentoo-stable-Pakete werden täglich aktualisiert

Einrichtung je nach Installationsumgebung

  • Um Binärpakete in einer bestehenden Gentoo-Installation zu verwenden, muss unter /etc/portage/binrepos.conf/ eine Konfigurationsdatei erstellt werden
  • Neue Stage-basierte Installationen enthalten bereits /etc/portage/binrepos.conf/gentoobinhost.conf
    • Bei Bedarf kann src-uri auf die entsprechende Verzeichnis-URI eines lokalen Mirrors geändert werden
    • Ein Beispiel für ein Update ist emerge -uDNavg @world

Build-Kriterien für amd64 und arm64

  • Binärpakete unter amd64/binpackages/17.1/x86-64 werden mit folgender Einstellung kompiliert
    • CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe"
    • Sie funktionieren auf allen amd64-/x86-64-Maschinen
  • Die USE-Flag-Einstellungen und Versionen der amd64-Pakete entsprechen den Stable-Paketprofilen
    • amd64/17.1/nomultilib
    • amd64/17.1/desktop/plasma/systemd
    • amd64/17.1/desktop/gnome/systemd
  • Pakete unter arm64/binpackages/17.0/arm64 werden mit folgender Einstellung kompiliert
    • CFLAGS="-O2 -pipe"
    • Sie funktionieren auf allen arm64-/AArch64-Maschinen
  • Auch die USE-Flag-Einstellungen und Versionen der arm64-Pakete richten sich nach den Stable-Paketprofilen
    • arm64/17.0
    • arm64/17.0/desktop/plasma/systemd
    • arm64/17.0/desktop/gnome/systemd
  • Wer CPU-spezifische Optimierungen benötigt, muss wie bisher selbst kompilieren

Andere Architekturen und Stage-Integration

  • Das Hosting von Binärpaketen für andere Architekturen und ABIs ist mit den Stage-Builds verknüpft
  • Für nahezu alle Stages wird Binärpaket-Hosting angeboten, das nur den Inhalt und die Konfiguration der jeweiligen Stage enthält
  • Dieser Umfang umfasst den Compiler gcc oder clang sowie die vollständige Build-Toolchain
  • Derzeit gibt es keine Pläne, diesen Umfang weiter auszubauen

Signaturen und Verifikation

  • Offizielle Binärpakete werden mit denselben Schlüsseln wie die Stages kryptografisch signiert
  • Portage unterstützt zwei Binärpaketformate
    • XPAK: das ältere Format, das keine Signaturen unterstützt
    • GPKG: das neue Format, das kryptografische Signaturen unterstützt
  • Offizielle Gentoo-Binärpakete liegen alle im GPKG-Format vor
    • Bei GPKG-Paketen wird die Signatur verifiziert
    • Schlägt die Verifikation fehl, wird die Installation verweigert
  • In der Standardeinstellung können aus Kompatibilitätsgründen mit älteren Binärpaketen auch unsignierte XPAK-Pakete installiert werden
  • Um verifizierte Signaturen zu erzwingen, muss in make.conf FEATURES="binpkg-request-signature" gesetzt werden
    • In diesem Fall können nur GPKG-Pakete verwendet werden

Signaturfehler und selbst erstellte Pakete

  • Wenn ein Fehler erscheint, dass die Signatur nicht verifiziert werden kann, kann das Gentoo Trust Tool getuto als root ausgeführt werden
    • Ein Beispielbefehl ist getuto
    • Es richtet den für Portage benötigten Gentoo-Release-Engineering-Keyring ein
  • Wenn in make.conf FEATURES="binpkg-request-signature" aktiviert ist, wird getuto vor dem Herunterladen von Binärpaketen automatisch aufgerufen
    • Das dient dazu, Schlüssel-Updates und Widerrufe abzurufen
  • Selbst erstellte Binärpakete können von Portage abgelehnt werden
    • Das ist eine Nebenwirkung von FEATURES="binpkg-request-signature"
    • Für eigene Pakete muss ein Signaturschlüssel eingerichtet werden, und der Anker unter /etc/portage/gnupg muss diesem Schlüssel vertrauen

Mirrors, Profile und Einschränkungen durch USE-Flags

  • Wenn Downloads langsam sind, wird empfohlen, statt der University of Oregon einen lokalen Mirror zu verwenden
    • Dazu genügt es, die URI in /etc/portage/binrepos.conf anzupassen
    • Dank der kryptografischen Signaturen ist die Nutzung eines lokalen Mirrors sicher
  • Wer USE-Flag-Kombinationen nutzt, die von den Profil-Defaults abweichen, kann die entsprechenden Binärpakete nicht verwenden
    • Portage kann Binärpakete und lokal kompilierte Pakete gemeinsam nutzen
    • Gentoo zielt nicht auf eine vollständig rein binäre Installation ab
  • Die Pakete können auch auf merged-usr-Systemen verwendet werden
    • Bei Problemen sollten diese als Bug gemeldet werden
  • Mit anderen älteren oder neueren Profilen können sie nicht gemeinsam verwendet werden
    • Das ist der Grund, warum der src-uri-Pfad eine Profilversion wie 17.1 enthält
    • Wenn eine neue Profilversion erscheint, wird ein separates neues Paketverzeichnis bereitgestellt

~amd64 und Problemmeldungen

  • Für ~amd64-Binärpakete gibt es derzeit noch keine Pläne
    • Ihre Bereitstellung würde viele Rebuilds erfordern
    • Selbst bei einer Bereitstellung wäre aus technischen Gründen eine separate URI nötig
  • Wenn Testing-Pakete benötigt werden, wird empfohlen, möglichst bei stable zu bleiben und sie lokal über package.accept_keywords hinzuzufügen
    • Viele Binärpakete können weiterhin genutzt werden
    • Die übrigen müssen selbst kompiliert werden
  • Bei Problemen mit Portage oder bestimmten Paketen kann man in IRC, Foren oder Mailinglisten um Rat fragen oder einen Bug einreichen
  • Die Unterstützung für Binärpakete wurde eine Zeit lang getestet, doch mit mehr Nutzern können Edge Cases auftreten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-31
Meinungen auf Hacker News

  • Um es vorwegzunehmen: Ich bin ein eingefleischter Gentoo-Fan.
    Der Reiz von Gentoo liegt nicht darin, alles aus dem Source zu kompilieren, sondern in der Freiheit, dank hervorragender Dokumentation und minimaler Hürden auf fast beliebiger Hardware genau das zu installieren, was man möchte.
    Wenn man auf einem Laptop von 2008 Enlightenment + OpenRC + NetworkManager nutzen will, installiert man Gentoo; und wenn man ZFS auf dem Root-Dateisystem eines smarten Kühlschranks verwenden will, geht das mit Gentoo ebenfalls.
    Auch ein unverändertes Gnome + SystemD auf einem neuen Laptop ist möglich.
    Die Entscheidung, Binärpakete anzubieten, gibt den Nutzern mehr Auswahlmöglichkeiten und steht im Gegensatz dazu, wie andere Distributionen die Wahlfreiheit reduziert haben.
    Debian bezeichnet sich zwar als „universelles Betriebssystem“, hat aber die Unterstützung für 32-Bit-x86 eingestellt; alternative init-Systeme lassen sich zwar installieren, sind aber ziemlich umständlich.
    Gentoo dagegen lässt einen zwischen mehr als 17 stage-3-Tarballs und 35 eselect-Profilen wählen.
    Persönlich genieße ich es, alles aus dem Source zu kompilieren, und die Flexibilität dahinter; auf aktueller Hardware ist das überhaupt keine Qual.
    Wer nicht einverstanden ist, kann einfach die neuen Binärpakete installieren.
    Gentoos Verkaufsargument war nie Portage, sondern immer Flexibilität und Community.

    • Die Formulierung, Debian habe die Unterstützung für 32-Bit-x86 eingestellt, ist nicht korrekt.
      Näher an der Wahrheit ist, dass man bei einem Meeting des Release-Teams zu dem Schluss kam, dass in einer nicht näher bestimmten Zukunft sehr wahrscheinlich Installer- und Kernel-Unterstützung für 32-Bit-x86 wegfallen könnten.
      Derzeit werden beide weiterhin angeboten und vollständig unterstützt.
      Insbesondere kann man weiterhin 32-Bit/64-Bit-Multiarch verwenden, sodass auch 32-Bit-x86-Software lauffähig ist.
    • Es ist etwas unfair zu behaupten, andere Distributionen würden aktiv die Wahlfreiheit abschaffen.
      Alle würden gern alles unterstützen, aber am Ende sind die Ressourcen begrenzt, die man als Distribution verwalten kann, wenn man Sicherheit und Wartung gewährleisten will.
      Auf manches muss man zwangsläufig verzichten.
      Auf jeder Linux-Distribution kann man installieren, was man möchte, aber der Bereich, den man wirklich als unterstützt bezeichnen kann, ist immer durch die Zahl der Maintainer begrenzt.
    • Man kann durchaus sagen, dass Debian genauso viele Architekturen unterstützt wie Gentoo.
      https://buildd.debian.org/status/package.php?p=base-files&su...
      Ich weiß das, weil ich viele der weniger bekannten Debian-Architekturen selbst mit regelmäßigen Installations-Snapshots betreue.
      https://cdimage.debian.org/cdimage/ports/snapshots/
      Debian hat außerdem Hurd-Ports sowohl für i386 als auch für amd64.
    • Heutzutage hat man das Gefühl, dass Arch einen Teil der Gentoo-Nutzerschaft übernommen hat.
    • Ich konnte Gentoo nicht installieren; besonders beim Installieren des grub2-Bootloaders für BIOS oder UEFI bin ich steckengeblieben.
      Ich habe auch kein musl- oder clang-Profil verwendet.
      Da das mein erster Eindruck war, werde ich Gentoo oder einen davon abgeleiteten Fork nicht in Betracht ziehen, solange kein Installer angeboten wird.
      Demnächst will ich Solus OS / Solus Linux ausprobieren; der Paketmanager machte einen guten ersten Eindruck und behauptet, reproduzierbar zu sein, wenn auch nicht auf die Art von nix oder guix.

  • Der große Reiz von Gentoo ist für mich persönlich Portage.
    Es bietet mehr als nur eine einfache Build-Umgebung und Abhängigkeitsverwaltung.
    Ebuilds, also Gentoo-Pakete, werden von hervorragenden Tools und Eclasses unterstützt, die viele Sonderfälle beim Build abdecken.
    Ein Ebuild zu entwickeln fühlt sich wie ein echtes Softwareprojekt an und ist gut für Leute, die mit Paketen experimentieren wollen, die nicht im offiziellen Repository sind.
    Passenderweise habe ich gerade ein Tool veröffentlicht, das unprivilegierte chroots zum Testen von ebuilds verwaltet.
    Diese Änderung wird Gentoo für viele Menschen zugänglicher machen, aber für mich passt sie wohl nicht.
    Meine Build-Einstellungen, etwa CFLAGS, werden nie zu den offiziellen Binaries passen, daher werde ich sie am Ende nicht nutzen.

    • Ich stimme zu, was das Anpassen von Paket-Flags und Features angeht.
      Als ich Gentoo in Produktivumgebungen eingesetzt habe, wurde das Entfernen von Funktionen und Integrationen mit Software, die ich nicht nutzte, zu einem wichtigen Teil der Sicherheitslage.
      Allerdings hatte ich immer einen dedizierten Build-Host, der die Binaries erzeugte, und Gentoos Binary-Unterstützung war nicht besonders gut.
      Im Grunde bestand sie nur darin, die kompilierten Artefakte ohne Signatur per HTTP oder NFS bereitzustellen.
      Dass das neue Paketformat kryptografische Verifikation enthält, freut mich wirklich.
      Selbst für eine rein interne Bereitstellung hätte es diese Funktion von Anfang an geben sollen.
    • Für leistungsschwache Geräte ist das wirklich eine gute Nachricht.
      Nützlich ist es, wenn man kein eigenes binrepo aufsetzen möchte – erst recht nicht, wenn Cross-Compilation ins Spiel kommt –, aber trotzdem die vorhandene Portage-Konfiguration und eigene ebuilds wiederverwenden will.
    • Wenn du ein Tool veröffentlicht hast, das unprivilegierte chroots zum Testen von ebuilds verwaltet, solltest du dir ansehen, wie ChromeOS das macht.
      ChromeOS verwendet bazel, um ebuilds in einem temporären chroot auszuführen.
      https://chromium.googlesource.com/chromiumos/bazel/+/refs/he...
      Dadurch lässt sich garantieren, dass keine nicht deklarierten Abhängigkeiten verwendet werden.
    • Meine CFLAGS werden ebenfalls nicht passen.
      Trotzdem bin ich versucht, ein Skript zu schreiben, das für plasma-bezogene Pakete die Nutzung gemeinsamer Binaries erzwingt.
      Dinge, bei denen Geschwindigkeit wichtig ist, würde ich selbst bauen; wenn ich die GUI-Pakete als Binaries bekomme, könnte das enorm viel Build-Zeit sparen.
      Der Nachteil scheint mir auch nicht besonders groß zu sein.
    • Es wäre schön, wenn du dieses Tool teilen könntest.
      Für mein Sandbox-Projekt habe ich wirklich händeringend nach so etwas gesucht.

  • Was auch immer man vom Konzept Gentoo hält: Mit 17 etwas über Software-Packaging, verteiltes Kompilieren, die Details von Compile-Time-Optimierung und Optimierung des Linux-Kernels zu lernen, hat wirklich Spaß gemacht.
    Soweit ich mich erinnere, war auch die Community-Dokumentation ziemlich gut.
    Ein paar der Patches, die ich eingereicht habe, könnten irgendwo in manchen Releases noch immer enthalten sein.
    Erst als ich sah, dass eine Slackware-Maschine genauso schnell lief wie eine Gentoo-Maschine, wurde mir klar, dass all die Anpassungen und Optimierungen und die neueste Software den Aufwand nicht wert waren.
    Bei bestimmten Apps, etwa Render-Farmen oder Kryptowährungs-Minern, können Custom-Kompilierung und Tuning zwar helfen, aber Spiele lieferten auf jeder Distribution dieselben FPS.

    • Die Bedeutung CPU-spezifischer Optimierung ist im Lauf der Jahre mal größer, mal kleiner geworden.
      Früher enthielt ein Build für den kleinsten gemeinsamen Nenner nicht einmal MMX oder SSE, und bei manchen CPU-gebundenen Algorithmen konnte das einen großen Unterschied machen.
      Es war aber auch immer möglich, CPU-Features zur Laufzeit zu erkennen und die optimale Version auszuführen; die Auswahl von Features zur Compile-Zeit war also nicht der einzige Weg.
      Später, mit dem AMD Opteron, landeten alle auf einer neuen Baseline.
      Für amd64 zu kompilieren bedeutete wieder, eine bestimmte CPU zu adressieren, und damals gab es noch keine neueren Instruktionen.
      Heute gibt es bei AMD64 mehrere Stufen[1], was bei bestimmten Aufgaben wie SIMD wichtig werden kann.
      Ein gewöhnlicheres Beispiel, auf das man öfter stößt: Das in v2 hinzugefügte popcnt ist für Dinge wie Bitsets für sich genommen gut, aber bei der Gesamtperformance von Programmen konnte ich in meinen Projekten zwischen v1 und v3 kaum einen Unterschied messen.
      Bei Spielen waren sie vermutlich ohnehin nur als Binärdateien verfügbar und entweder bereits für den kleinsten gemeinsamen Nenner kompiliert oder nutzten Feature-Auswahl zur Laufzeit.
      Außerdem waren die meisten davon ohnehin GPU-limitiert.
      [1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level...

  • Vor ein paar Jahren habe ich, warum auch immer, Stunden und Tage an Computerzeit und eigener Zeit damit verschwendet, ein Gentoo-System zu kompilieren und feinzujustieren.
    Dabei wollte ich es am nächsten Tag sowieso formatieren, um die neu eingetroffene Ubuntu-CD zu installieren.

    • Nur weil man etwas getan hat und es jetzt nicht mehr tut, heißt das nicht, dass es falsch war, es getan zu haben.
      Leute, die früher ihren Kernel selbst kompiliert haben und es heute nicht mehr tun, sind zum Teil gerade deshalb heute fähig, weil sie so etwas zumindest eine Zeit lang gemacht haben.
      Erst nachdem man es ausprobiert hat, ist es vernünftig, es heute nicht mehr zu tun.
      Es ist nicht richtig zu sagen: „Wenn ich klüger gewesen wäre, hätte ich damit keine Zeit verschwendet“, oder dass neue Beobachter es so auffassen.
    • Mir ging es genauso, aber ich habe dabei wirklich viel gelernt.
      Am Ende war ich erschöpft und bin zu Arch gewechselt; dort bekam ich fast dasselbe, ohne ständig gegen kaputte Pakete kämpfen zu müssen.
      Das Wissen, das ich beim Umgang mit zufällig auftretenden Low-Level-Problemen gewonnen habe, nutze ich aber bis heute.
    • Bei mir war es genauso.
      Trotzdem habe ich viel gelernt.
      Heutzutage fühlt sich Linux wie meine Superkraft an.
      OS, VM, Container, Nix-Shell und WSL2 sind alle Linux.
      Egal in welcher Kommandozeile ich lande — bis zu einem gewissen Grad auch BSD eingeschlossen — fühle ich mich wohl und kann Probleme lösen.
      Ich möchte glauben, dass die schöne Zeit mit Gentoo mich dorthin geführt hat.
    • Der größte Reiz von Gentoo waren immer die USE-Flags.
      Unter CentOS musste man selbst für den Kommandozeilen-Player mpg123 eine vollständige X-Installation mitziehen, während man in Gentoo die X-Integration von mpg123 abschalten konnte.
      Die Flags waren der Bonus obendrauf.
    • Ich war auch einmal davon besessen, mein Betriebssystem zu customizen.
      Heute installiere ich Debian, richte nur ein paar Programme ein, die ich täglich nutze, und bin fertig.
      Auf einer anderen Maschine kann ich meine Konfiguration in unter 20 Minuten wiederherstellen.

  • Anfang der 2000er habe ich lange Gentoo genutzt, und fast alles, was ich über Linux-Maschinen im Allgemeinen weiß, habe ich aus dieser Erfahrung gelernt.
    Interessant an den USE-Flags war, dass man überhaupt erst erfuhr, dass ein Paket eine bestimmte Integration mit einer anderen Bibliothek oder einem anderen Paket hat.
    Als mir klar wurde, dass sich das SQLite3-Binary nicht gleich verhält, wenn es ohne readline-Unterstützung gelinkt ist, verstand ich, was readline insgesamt ist.
    Dasselbe wiederholte sich mit unzähligen Bibliotheken, die auf anderen Linux-Systemen scheinbar immer einfach dabei waren.
    Es war ein wirklich wertvolles Lernwerkzeug, das mir zum richtigen Zeitpunkt in meinem Leben begegnet ist.

  • Fühlt sich etwas seltsam an
    Viele Kommentare sagen, sie hätten Gentoo ausprobiert oder früher benutzt
    Aber ich nutze es immer noch als Daily Driver und hauptsächlich auf Servern
    Ich frage mich, was bei mir anders ist, dass Gentoo für mich das Beste ist
    Und ich habe nicht vor, binäre Pakete zu aktivieren

    • Du bist nicht allein
      Ich lasse Gentoo auf allen Geräten laufen, darunter GPD Win 4, ein Pixelbook mit coreboot, NAS, VPS usw.
      Ich denke, die Gründe sind diese
      1. Die beste Dokumentation, die ich bisher gesehen habe
      2. Unbegrenzte Anpassungsmöglichkeiten, sodass man das System so minimal oder maximal machen kann, wie man will
      3. Portage-Overlays sind meiner Ansicht nach immer besser als AUR
      4. Man kann das init-System selbst wählen
        Wenn man SystemD will, kann man es nutzen; wenn man OpenRC will, nimmt man einfach das
      5. Die Stärke einer guten Community mit klar definierten Werten ist schwer zu unterschätzen
        Bei Gentoo fühle ich mich sicher und wohl
        Weil ich weiß, dass Gentoo die Freiheit, die mir bei Linux am wichtigsten ist, immer respektieren wird
        Gentoo ist wie ein Abenteuerbuch, bei dem man selbst entscheidet
        Wenn man SystemD + Gnome + PulseAudio + binäre Pakete nutzen will, geht das; wenn man OpenRC + Hyprland + Pipewire + NetworkManager statt netifrc nutzen will, geht das ebenfalls
        Gentoo ist keine Distribution, bei der man alles kompiliert, sondern eine Distribution, bei der man alles auswählt
        Diese Ankündigung ist für mich irrelevant, gibt den Nutzern aber mehr Auswahlmöglichkeiten
    • Wenn NixOS nicht aufgetaucht wäre, würde ich immer noch Gentoo benutzen
      Gentoo ist auch gut, aber als NixOS-Systemadministrator lebt es sich viel einfacher als als Gentoo-Systemadministrator
    • Dann frage ich mich, warum Gentoo für dich das Beste ist
      Ich will deine Antwort nicht widerlegen, ich bin wirklich neugierig
      In meinem Fall passte Gentoo nicht, weil ich keine privaten Server betreibe und bei der Arbeit Cloud-Server nutze
      Vermutlich Ubuntu-basiert oder nach AWS-Art, aber Kernel kompiliere ich dort nicht
      Auf dem Desktop habe ich Gentoo vor über zehn Jahren ausprobiert, nachdem ein Freund mich überzeugt hatte: „Es wird schneller sein, weil es für deine Hardware kompiliert wird“
      Ich habe viel Zeit damit verschwendet, es zu installieren und zum Laufen zu bringen, aber bei keiner meiner Aufgaben war es merklich schneller als normales Ubuntu, und die Konfiguration dauerte nur länger
      Also habe ich es aufgegeben
      Auch das oft gehörte „Beim Einrichten von Gentoo habe ich wirklich viel gelernt“ stimmte bei mir nicht
      Wie die meisten Leute folgte ich Rezepten, setzte Flags, die ich nicht verstand, und änderte Konfigurationsdateien; vorsichtig gesagt habe ich nichts gelernt
      Ich habe nur Prozeduren abgearbeitet
      Natürlich war das nur meine Erfahrung
    • Vielleicht wegen erwachsener Beharrlichkeit
      Genau weiß ich es nicht, aber ich benutze es auch schon seit 20 Jahren
    • Ich frage mich, ob es auch Maschinen gibt, die einfach zuverlässig laufen
      Ich meine keine Daily Driver oder Server, an denen man jede Woche arbeitet, sondern Geräte, die vor langer Zeit eingerichtet wurden und seitdem weiterlaufen
      Also Systeme, bei denen man sich nur ein paar Mal im Jahr einloggt
      Ich habe Gentoo aufgegeben, als ich mein erstes „Produktiv“-System gebaut habe
      Leute begannen es zu nutzen, und es war in dem Sinne „fertig“, dass es keinen Grund mehr gab, sich täglich oder wöchentlich einzuloggen
      Sicherheitsupdates wollte ich weiterhin, und ganz selten brauchte ich wegen neuer Funktionen ein neues Paket, aber im Grunde wollte ich ein stabiles System
      Für diesen Zweck war Gentoo schrecklich ungeeignet
      Sogar auf meinem privaten Desktop habe ich wöchentlich aktualisiert, und fast jedes Mal gab es emerge-Build-Fehler; bei einem System, das man monatelang nicht aktualisiert, wäre es wohl noch schlimmer
      Deshalb bin ich zu Debian gewechselt, und das war gut
      Besonders unattended upgrades waren gut, und am Ende habe ich alle Maschinen auf Debian umgezogen
      Wenn du Gentoo nutzt, frage ich mich, ob du auch Maschinen hast, die du nicht wöchentlich anfasst, wie oft du aktualisierst und wie oft manuelles Eingreifen nötig ist, um Updates abzuschließen

  • Zu wenig und 15 Jahre zu spät
    Einer der Gründe, warum ich vor über 15 Jahren von Gentoo zu FreeBSD gewechselt bin, war, dass man bei Gentoo alles kompilieren musste, während FreeBSD binäre Pakete bereitstellte
    Heute mag das nicht mehr so wichtig sein, aber in Zeiten von einem CPU-Kern und 1 GB RAM war das ein Gamechanger

    • Leider stimmt das vollkommen
      Ich habe Gentoo lange benutzt, bin dann für einige Jahre zu macOS gewechselt und habe dort Gentoo Prefix genutzt, was Homebrew deutlich überlegen war
      Vor fast 10 Jahren habe ich einen Patch hinzugefügt, damit upstream llvm unter Gentoo Prefix auf macOS läuft [1]
      Bei einer GSoC-Reunion habe ich schließlich jemanden getroffen, der mir Maintainer-Rechte geben wollte, aber es wurde nie zu Ende gebracht
      Er hatte mich schon gewarnt, dass diese Arbeit kompliziert werden würde
      Ich sagte immer wieder, dass auch Prefix Binärdateien braucht
      Ich frage mich, wie es gewesen wäre, wenn Gentoo Prefix auf dem Mac Pakete so einfach hätte installieren können wie Homebrew
      Traurig, aber Gentoo ist ein gutes Beispiel dafür, dass selbst ein technisch überlegenes Open-Source-Projekt, wenn es grundlegende Endnutzerfreundlichkeit ignoriert und keine gute Governance hat, gegenüber minderwertigen Lösungen nicht überleben kann
      Ich denke, dass opensolaris/illumos aus ähnlichen Gründen faktisch am Lebenserhaltungssystem hängt
      Die Verantwortlichen kamen nicht über ihren Elitismus hinaus und konnten nicht die Entscheidung treffen, dass Community-Beteiligung etwas Einfacheres braucht als 100 Schichten unverständlicher Makefile-/Shell-Spaghetti zum Bauen des Kernels
      [1] https://github.com/fishman/timebomb-gentoo-osx-overlay/tree/...
    • Ist es wirklich zu spät?
      Gentoo war selbst innerhalb der ohnehin schon nischigen Linux-Community immer eine Nische, aber es scheint trotzdem fröhlich weiterzulaufen
      Was ist denn das Problem?

  • Wenn ich daran denke, wie viel Stromkosten und Treibhausgase wohl dadurch entstanden sind, dass immer wieder unnötig dieselbe Software kompiliert wurde, läuft es mir kalt den Rücken herunter

    • Das dürfte wahrscheinlich um einige Größenordnungen weniger sein als die Energieverschwendung und die Treibhausgase, die dadurch entstehen, dass auf Milliarden von Geräten mit Webzugang immer wieder unnötig dieselbe JavaScript-Software kompiliert wird
    • Verglichen mit dem durchschnittlichen Stromverbrauch von Aktivitäten wie Gaming ist es vermutlich keine nennenswerte Menge
    • Wahrscheinlich ist es gar nicht so viel
      Gentoo war im Vergleich zu Red Hat oder Ubuntu ja auch nicht besonders weit verbreitet
      Außerdem ist der CPU-Stromverbrauch, wenn der Computer ohnehin eingeschaltet war, verglichen mit rotierenden HDDs, Monitoren usw. eher ein Rundungsfehler
    • Als Hobby betrachtet ist es weit vom Schlimmsten entfernt
      Manche Leute spielen 12 Stunden am Tag auf Gaming-PCs im Kilowattbereich, fahren Autos auf der Rennstrecke oder schippern mit spritfressenden Booten herum
    • Es ist sehr wahrscheinlich nur ein winziger Bruchteil von 1 % des Stroms, den Microsoft verbraucht, um rund um die Uhr persönliche Daten von Windows-10-Nutzern zu sammeln

  • Was Gentoo großartig macht, ist, dass es von Grund auf so entworfen wurde, dass man kleine Anpassungen, die man auf dem eigenen System haben möchte, leicht hinzufügen und pflegen kann
    Alle anderen Distributionen, die ich ausprobiert habe — alle großen Distributionen und mehrere kleinere — funktionieren im Auslieferungszustand tendenziell besser, aber sobald man den vorgegebenen Pfad verlässt, wird es extrem schmerzhaft
    Ein gut abgestimmtes Gentoo-System läuft einfach™
    Egal, was „läuft“ für einen persönlich bedeutet
    Das kann ein Namenskonflikt bei python 2to3 sein, der entsteht, wenn Arch beschließt, Upstream zu überschreiben, oder ein Latenzproblem im Systemkern, weil SystemD im Kernel-Modus zu viele unnötige Dinge tut
    Trotz der verschiedenen Schwächen bin ich ein sehr zufriedener Gentoo-Nutzer
    Upstream-Binärpakete sind nur eine weitere Erweiterung dieser Freiheit
    Es gab bereits Binärversionen einiger wichtiger Projekte, oder man konnte sich einen eigenen Build-Server bauen, aber wenn mehr Binärpakete leicht nutzbar werden, können viel mehr Leute von den Vorteilen profitieren, ohne den enormen Zeitaufwand, jedes kleine Ding selbst zu bauen
    Wenn man für ein bestimmtes Paket mehr Flexibilität braucht, etwa Patches oder USE-Flags, ist das weiterhin möglich und auch leicht zu pflegen
    Das ist ein großer Gewinn

  • Eine Zeit lang gab es bei Gentoo wirklich eine passende Phase, in der alles ziemlich reibungslos lief
    Es gab weder zu viele noch zu wenige USE-Flags, und es war die Zeit, in der man OpenOffice neu kompilierte, wenn es im Wohnheimzimmer in kalten Winternächten zu kalt war

    • HN ist wohl der einzige Ort, an dem man ohne Ironie auf irgendeinen Zustand von Gentoo als „lief einfach wie geschmiert“ zurückblicken kann
      Das ist liebevoll gemeint