Orientierungsvektor zum Tod. Jemand mag das vielleicht nicht, aber Sie können für längere Zeit leugnen, dass das Gras grün ist und dass es nicht aufhören wird, grün zu sein.
Gleichzeitig wollen die Führungskräfte der Gentoo-Distribution nicht verstehen, was passiert, und angesichts dessen werden keine Schritte unternommen, um die Distribution zu transformieren. Und es ist schade!
Zunächst wäre es sinnvoll, den Grund für die Popularität der Gentoo-Distribution (2005-2010) und den weiteren Rückgang der Popularität und den unvermeidlichen Tod der Distribution in den nächsten 10 Jahren zu verstehen.
Der Grund für die Popularität in den Jahren 2005-2010 war:
1. Binärdistributionen versorgten den Benutzer trotz ihrer Anzahl nicht mit aktuellen Versionen von Softwarepaketen im stabilen Zweig. Die Test- und instabilen Zweige versorgten den Benutzer nicht mit stabiler Arbeit, wodurch die Workstation regelmäßig in einen funktionsunfähigen Zustand versetzt wurde. Darüber hinaus hat die Debian-Distribution ihre Position überarbeitet und die Versionen der Pakete stabilisiert, an denen der Benutzer arbeiten konnte (dh das Entwicklungsstudio und den Desktop-Kontext). Und er wurde populär. Genau aus diesem Grund.
2. Die Gentoo-Distribution hat eine innovative USE-Flag-Technologie implementiert, die in anderen Distributionen nicht vollständig implementiert ist. Es ist teilweise in NixOS implementiert. Diese Technologie ermöglichte es dem Benutzer, die Funktionsschnittstelle des Betriebssystems zu ändern.
Das Gentoo-Management glaubt immer noch, dass der Grund für seine Popularität die Ideologie war, "Software aus der Quelle zu erstellen". Es ist nicht so. Der Endbenutzer benötigt Flexibilität in Bezug auf eine funktionale Schnittstelle. Und nur. Bei dieser Gelegenheit kann der Benutzer sogar warten, bis die Pakete aus den Quellen erstellt wurden.
Die mangelnde Entwicklung der Gentoo-Distribution hat zur Entstehung von Distributionen geführt, die versuchen, dem Benutzer diese Flexibilität zu bieten. In verschiedenen Kontexten sogar die unglaublichsten. Ein eklatantes Beispiel ist die Entstehung der NixOS-Distribution, die versucht, Benutzern die folgenden Funktionen zur Verfügung zu stellen:
- die Fähigkeit, mehrere Softwareversionen zu verwenden
- die Fähigkeit, den Zustand zu beheben
- deklarative Betriebssystemkonfiguration
- die Möglichkeit, die Funktionsschnittstelle des Betriebssystems zu ändern (analog zu USE-Flags)
Jeder dieser Punkte ist in dieser Verteilung implementiert. Gleichzeitig führte die Festlegung auf 1, 2 Punkte zu zahlreichen Schwierigkeiten bei der Verwendung dieser Verteilung. Punkt 3 ist überkompliziert und tendenziell weiter überkompliziert und hat bereits dazu geführt, dass diese
Verteilung ihre Universalität verloren hat. Das einfachste Beispiel: Versuchen Sie, von
einem NixOS-Installationsimage auf eine andere Distribution zu chrooten.
Daher hat Gentoo eine innovative USE-Flag-Schnittstelle bereitgestellt, mit der Sie die Funktionsschnittstelle des Betriebssystems ändern können. Der Hauptnachteil der Implementierung ist die Erstellungszeit von der Quelle. Frage: Ist die Assembly von der Quelle die einzige
möglich bei der Implementierung der Möglichkeit, die funktionale Schnittstelle zu ändern? Meine Antwort ist nein. Diese Funktion kann ohne Verwendung der Assembly aus der Quelle implementiert werden. Es gibt sicherlich Probleme auf dem Weg. Aber um sie zu lösen (und es ist letztendlich möglich, sie zu lösen, hat die NixOS-Distribution dies auf praktischer Ebene gezeigt), liegt sie ausschließlich in der Ebene der Transformation der Ideologie der Führungskräfte der Gentoo-Distribution.
Viele Male im Internet (und nicht nur) haben Benutzer das Problem der binären Caches von Paketen angesprochen. Die Antwort ist immer dieselbe: Dies ist nicht möglich, da jede Workstation über einen Prozessor mit einem eigenen Satz von CFLAGS verfügt und ein Paket, das mit einem kompiliert wird
Das CFLAGS-Set funktioniert nicht unbedingt auf einer anderen Workstation mit einem anderen CFLAGS-Set. Aus diesem Grund ist es technisch unmöglich, einen Binärpaket-Cache zu implementieren, der auf anderen Workstations auch innerhalb derselben Architektur (z. B.
AMD64) funktioniert . Diese Aussage ist wahr, aber es gibt Lösungen:
- mit GENERIC CFLAGS
- Segmentierung von binären Caches durch CFLAGS
Sowohl der erste als auch der zweite Punkt können implementiert werden. Die Führungskräfte der Gentoo-Distribution haben keine Lust. Was erwartet die Gentoo-Distribution, wenn sie Binärpaket-Caches hat? Er ist zum Scheitern verurteilt. Für den Erfolg.
Mein Traum ist es, dass das Managementteam von Gentoo seine Ideologie überdenkt und eine strategische Entscheidung über die Richtung dieser wunderbaren Distribution trifft und in der Welt der Distributionen wirklich innovativ wird.
PS: Gentoo sabotiert seit über 10 Jahren die Entstehung eines zentralisierten Binärpaket-Cache. Lesen Sie bei Interesse die Kommentare ausführlich durch.