Stirbt GENTOO gerade ?

[artbody]

Stirbt GENTOO gerade ?

Diese Frage stelle ich jetzt mal ganz bewußt hier ins Forum.

GRUND der provokativen Aussage:

[firefly]

[artbody]

Ich habe erst mal ein klares JA gestimmt.

Was ich sehe ist, u.a. dass es Portage an einem Automatismus mangelt,
- welcher neue Packete automatisch mit in unstable einbindet und entsprechende ebuilds erstellt.
- # also u.a. ebuild aus git automatisch erzeugt
- # ebuild aus rpm oder deb packeten automatisch generiert

- welcher Fehler beim Kompilieren vom User automatisch an den entsprechenden Maintainer schickt.(wenn vom user freigeschaltet)
- welcher dem Maintainer die Möglichkeit gibt diese Fehler an die entsprechenden Developer weiter zu leiten.(zwangsweise, weil wenn 1000de Fehlermails im Postfach liegen müsste es auch dem intelligentesten EGODEV einleuchten dass er Mist gebaut hat)

Das derzeitige Bild zeigt eindeutig, dass es an "fachlich versierten Packetbetreuern mangelt" sagen die Einen
ODER genauer auf den Punkt gebracht
Portage derart viel Resourcen an "fachlich versierten Packetbetreuern" benötigt, um der ganzen Flut von Programmen auch nur ansatzweise Herr zu werden.

Resourcenfresser:
Sind aber auch zu langsames Feedback. Hier im Forum tauchen oft Probleme auf, werden gelößt und bis die Lösung dann, irgendwann, in die entsprechenden Packete eingeht, bei Entwicklern und/oder Packetbetreuern umgesetzt wird... vergeht sehr viel Zeit.
In dieser Zeit müssen dann 1000de User alle diese Workarounds ausführen.
Rechnet man mal 1Stunde pro Problem, vom Erscheinen des Fehlers...bis zum finden und lösen des Problemes , pro User , so wären das 1000 Stunden Manpower.
Überflieger sind hier in meinen Augen QT, Python, Perl .... Updates
WIE VIELE STUNDEN PRO USER ?


Als nächsten Punkt hab ich noch das Problem von "Stable Gentoo"
in welchem sich auf einem normalen Rechner, mit der Zeit, bereits ab Erstinstallation (nvidia ..blender, freecad...) soviel ** ~amd ... im package.accept_keywords ansammelt, dass es eigentlich unmöglich ist ein reines Stable Gentoo zu haben.
was dann natürlich wie man an 1000de Threads hier im Forum erkennen kann, immer wieder zu Problemen führt.


Bei soviel Manpower wird es doch langsam Zeit diese sinnvoll zu nutzen anstatt sich als Devoloper und Packetbetreuer ... hinter einer EGO-Mauer der Unzugänglichkeit zu verstecken.
_________________
Never give up
WM : E16 the true enlightenment
achim

[artbody]

[artbody]

Und noch ein Punkt
z.B.
ENLIGHTENMENT Orginalversion flog durch die FEINDLICHE ÜBERNAHME von Entlightenment17, 18, 19, 20 .. jetzt gerade 22 einfach raus
dazu gibt es hier im Forum auch ein paar Threads.
In meinen Augen ist das Entlightenment17...22.. ein völlig anderes Ding als das Orginal Enlightenment 16 (e16) hätte also NIE gemeinsam geslottet werden dürfen, sondern hätte unter eigenem Namen geführt werden müssen
z.B.Enlightenment17 oder wie auch immer

ein emerge -s enlightenment

[mike155]

Ich finde diesen Thread reichlich merkwürdig und ärgerlich!

Ich kann es gut verstehen, dass jemand frustriert ist, weil es im offiziellen Portage Tree keinen aktuellen ebuild für ein Programm gibt. Und es ist auch völlig in Ordnung, hierzu einen Thread auf den Foren zu eröffnen. Meines Erachtens wurden hier auch gute Antworten gepostet:

• Hu hat erklärt, warum es keinen keinen ebuild gibt
  
• Es gab einen Link auf einen Bug-Report mit einem ebuild für eine neuere Version
  
• fedeliallalinea hat sogar einen ebuild für die aktuelle Version von cppzmq entwickelt und gepostet.
  

Was will man mehr? Sind das Zeichen für eine sterbende Distribution? Oder sind das eher Zeichen für eine aktive und hilfsbereite Community?

Gentoo lebt davon, dass Leute die Ärmel hochkrempeln und mitmachen! Diskussionen darüber, ob Gentoo gerade stirbt, helfen nicht weiter.

Also mein Vorschlag: ein oder zwei Nachmittage investieren und lernen, wie man ebuilds schreibt und einen lokalen Overlay installiert. Es kostet etwas Zeit, sich da reinzuarbeiten - aber es ist nicht wirklich schwer. Das vorbildliche Beispiel von fedeliallalinea zeigt, dass es kein Hexenwerk ist.

[artbody]

Ich habe oben nicht behauptet dass die Community nicht hilfsbereit ist.

Ich habe bis jetzt hier im Forum eigentlich immer gute Erfahrungen gemacht.


_________________
Never give up
WM : E16 the true enlightenment
achim

[Max Steel]

Mir fehlt ein "Nein" als Auswahl. So sieht das ganze echt nur nach rumgeflenne eines einzelnen aus.
_________________
mfg
Steel
___________________

Heim-PC: AMD Ryzen 5950X, 64GB RAM, GTX 1080
Laptop: Intel Core i5-4300U, 16GB RAM, Intel Graphic
Arbeit-PC: Intel i5-1145G7, 16GB RAM, Intel Iris Xe Graphic (leider WSL2)

[asturm]

Ein Thread wie ein BILD Artikel.

[misterjack]

Was für ein manipulativer dummer Thread. Wo ist die Option "Nein" zum Abstimmen?

Edith:

[Yamakuzure]

Also da steckt eine Menge "Blödsinn" drin. Ein "Nein" zum Abstimmen fehlt mir auch.

Ich habe das "Blödsinn" in Anführungszeichen gestellt, da so Manches hier ja auch durch mangelnde Erfahrung oder Wissen kommen kann.
Aber da können wir ja helfen.

[forrestfunk81]

Ich würde auch gerne mit einem klaren Nein stimmen! Bitte füge die Option doch noch nachträglich hinzu.

Ich setze Gentoo seit 2005 ein und es wurde von Jahr zu Jahr stabiler. Als ich damals mit ~amd64 startete war eine 64bit Installation wirklich noch experimentell, kein Vergleich zu unstable heute. Alle paar Monate schlägt jetzt mal ein Build fehl. Oft reicht es dann am nächsten Tag zu synchronisieren und die Fehler sind behoben. Wenn nicht muss man halt mal einen Bug Report aufmachen.

Nach fast 14 Jahren unstable habe ich diese Woche meine letzte Installation auf stable umgestellt - einfach weil es mir zuviele Minor- und RC- Updates sind. Von den 1217 installierten Paketen auf meinem Arbeitslaptop sind weniger als 50 unstable (hauptsächlich Browser und Development Sachen). Und ob ich jetzt KDE Plasma 5.14.3 (stable) oder 5.14.4 (unstable) laufen habe ist mir ziemlich egal.

Über die Jahre hinweg hatte ich Gentoo auf knapp 30 Geräten am Laufen - von Raspberries und Router über day2day Arbeits- und Entwicklungslaptop bis zum VServer, welcher wieder LXC Container mit Gentoo Installationen hält. Dementsprechend unterschiedlich sind/waren die Use Cases und Paket Anforderungen. Außer Eclipse, JProfiler und GitKraken hab ich nichts an Portage vorbei installiert.

Im Gegenteil, ich bin sehr positiv überrascht, dass Gentoo im Bereich moderner Software-Entwicklung so breit aufgestellt ist. Von Docker über AWS SDK, Minikube, Helm, Terraform etc ist alles da, was man für die Cloud so braucht. Und das Top aktuell! Die Updates kommen hier meist schneller rein, als bei den Ubuntu Kollegen.

Deshalb an dieser Stelle ein großes Lob und vielen Dank an die Devs und Maintainer <3
_________________
# cd /pub/
# more beer

[Marlo]

[misterjack]

[Yamakuzure]

[ChrisJumper]

artbody, mach dir keinen Kopf!

Im Zweifelsfall musst du dich halt einlesen in die Howtos und deine Lieblingspakete selber mit E-Builds versorgen. Im Zweifel fragst du im Chat nach oder bei bugs.gentoo.org!

Speicher, einige Bereiche sind weg, verloren an andere Distributionen und der Ausbau oder die Weiterentwicklung stockt ein wenig. Aber deswegen ist es noch nicht tot. Im Grunde sind die Kern-Elemente weiterhin sehr gut unterstützt und gepflegt. Ich würde mir da keine Sorgen machen, sicher die ein oder anderen Überflüssigen Pakete aus der Hype-Zeit werden aktuell nicht aktualisiert, aber wenn du erst mal verstanden hast warum das so eine Arbeit ist, diese Pakete zu unterstützt (oder ein Paket), weinst du dem auch keine Träne nach.

Die anderen alternativen sind bedeutend schlechter, wie ich finde und im Grunde kann man mit ein paar Skripts und Overlays das ganze sehr erträglich nutzen. Es ist komplizierter als vor zehn Jahren und bei einigen Paketen scheint es ein wenig turbulent zu sein, doch im Grunde stellt dies kein Problem dar.

Weil die Nutzungsszenarien bei anderen proprietären Betriebssystemen oder Dienstleistungen viel schlimmer sind.

[Marlo]

[gorg86]

Nein Gentoo liegt nicht im sterben...
Es gibt immer wieder Pakete die vernachlässigt werden, aber da gibts auch genug positive Beispiele.
Z.B. war Blender vor einigen Jahren ein ziemlicher Graus, mitlerweile is alles aktuell und die Installation ist auch einfach.
Um den Atom Editor zu installieren, muss man auch nichtmehr durch Hula-Hoops springen.

[doedel]

Diese generelle Anti-Haltung gepaart mit Scheuklappen nimmt man an, wenn man sich zu lange im Dunstkreis von mikrocontroller.net aufhält. Dem Forum hab' ich schon vor Jahren den Rücken gekehrt...
Da kann man rumpissen wie man will und findet immer Rückhalt sowie Gegner - diese "Gesprächskultur" nimmt man dann auch an.

Die Umfrage ist Bildzeitungsniveau. Mir fehlt auch ein eindeutiges nein als Antwort.

... und ich will nicht auf Rechtschreibung herumreiten, das soll ernsthaft konstruktiv sein:
Paket und nicht Packet. Sprich das mal aus: "Pakkett".
_________________
1 ha == 1 Hekto-Ar == 1 Hektar

[Marlo]

[doedel]

Wow, das find' ich cool. Als ich in angesprochenem Mikrocontroller.net Forum noch aktiv war, konnte man einfach nicht posten, wenn man Wiederstand geschrieben hat. Aber vor ein paar Tagen habe ich Wiederstand dort gelesen, vielleicht haben die das wieder abgeschafft.

... Widerstand ...

jetzt sehen beide Varianten, die Richtige und die Falsche, komisch für mich aus... *seltsam*

Jeder macht Fehler, aber manche sind so eindringlich und drücken schon fast im Kopf beim Leser... Ich will damit auch echt niemandem was vorhalten, wie oben schon geschrieben. Packet ist nur sowas, was vielen aufstösst. Das falsch Schreiben degradiert auch niemandem zum Idioten, nur das lernresistent Sein und Anti-Haltung, wenn man drauf aufmerksam gemacht wird.

[ChrisJumper]

Es gibt Probleme mit dem Stabilisieren, aber das durchzieht sich denke ich in allen Bereichen.

Das man einfach einen Stabelize-Request als Bug eröffnen darf, wusste ich auch nicht. Ich dachte die Maintainer haben da eh genug zu tun. Zumal es gefühlt auch immer schwieriger wird weil die Abhängigkeiten oft so verzwickt sind. Wenn ich mich da an openssl 1.1 erinnere, was ja auch schon vor Jahren kam und immer noch Maskiert ist, weil die Bibliothek dieses Projektes umfangreichere Änderungen mit sich bringt bei den Programmen die das einsetzen.

Gibt es da eigentlich einen Blog oder News-Seite zu die sich mit diesen Veränderungen Beschäftigt und das schön zusammen fasst, wahrscheinlich kann man das nur in den Bugzilla-Threads oder Dokumentationen lesen.

Mit git hat sich das alles verändert. Auch hier werden eher dezentrale Repositories verwendet wo man dann etwas ausprobiert statt eine gemeinsame Test-Basis zu habe. Richtige Bugs die einen Stören gehen zurück an git oder das Bugzilla vom Projekt.

Ich selber halte mich damit aber immer zurück weil ich kein Vertrauen in meine Test-Umgebung habe, ich denke immer das ist nicht entsprechend normiert oder zu "Unstable/Mixed" und dann würde ein Beitrag eher zur Verwirrung beitragen.

Packett Boden oder ein Päckchen-Paket ist auch ein fieses Wort! Besonders wenn man oft abwechselnd Englisch und Deutsch schreibt geht es im Eifer des Gefechtes unter.

Edit: Jetzt hatte ich noch was wichtiges Vergessen warum ich aber eigentlich schreibe:
Es hat was ekliges, diese Docker-Images und diese Git-Mentalität, vielleicht kommt es mir nur so vor weil ich bei Lineageos noch nicht durch gestiegen bin und Android selbst ein sehr großes Projekt ist.

Aber mir geht es auf den Keks das diese Installations-Routinen oft wirken wie eine Hand voll Skript die sich alles per Git, oder ganz schlimm per hinein kopierten CURL Shell-Befehl ein Skript laden das Abhängigkeiten auflöst.
Im Fall von Lineageos, ist das sehr bequem, ich denke es ist ähnlich wie diese Docker-Images das man sich nicht mehr darum kümmern muss die Pakete für eine bestimmte Distribution zu machen, sondern man Kopiert sein Set einfach von Maschine A auf Maschine B, hat seine eingebundenen Repositories.

Es mag praktisch sein aber ein ungutes Gefühl wenn ich so etwas einsetze habe ich trotzdem. Wahrscheinlich sind dies aber die gleichen Voraussetzungen die Entwickler haben wollen um eine gleiche Basis zu haben.

Doch irgendwas muss ja falsch gelaufen sein. Vor 10 Jahren hielte ich diese Linux-Paket-Vewaltung, auch wenn sie nicht komplett einheitlich ist. Immer für eine sehr gute Idee. Doch es hat sich nun mal nicht durch gesetzt.
Die ganzen Programmier- und Skript-Sprachen bringen ihre eigene Paketverwaltung mit (Perl, Python, Ruby, Nodejs ist denke ich so etwas ähnliches..). Mir kommt es ein wenig so vor als wurde das Rad X mal neu Erfunden und implementiert aber es gibt kein Einheitliches Tool. Vielleicht ist GIT aber auch das einheitliche Tool, aber dann frage ich mich warum diese Art die Paketverwaltung noch nicht komplett abgelöst hat. Git ist ja auch quasi ein rsync, mit dem Zusatz der Versionsverwaltung. Dennoch wird rsync oft verwendet. Wobei ich oft denke das viele Menschen github Nutzen um Daten zu synchronisieren und Bereit zu stellen.

Es könnte ja so einfach sein wenn alle ein einheitliches Tool verwenden, wie bei der Paketverwaltung von einer Distribution. Gleichzeitig ist die Pflege wohl zu speziell und Aufwendig. Für viele liegt die Antwort auf dies Frage wohl in den Container-Images oder in der Nutzung eben dieser Overlays, statt dem Standard-Mechanismus der Paketverwaltung selbst. Es hat ja durchaus Vorzüge, und Konfigurationsfehler lassen sich vermeiden. Aber es wirkt befremdlich auf mich wenn die gute Praxis um sich zum Beispiel einen Mastodon Server zu installieren, einfach das Docker-Image ist, statt eine detaillierte Beschreibung über den Aufbau und die Dienste.

Im Grunde wird Komplexität immer nur mit einer größeren Box drum herum erschlagen, nur damit man wieder bei dem .exe Paket landet das einfach ein paar Klicks braucht. ;D

Ich sehe ein Muster und stelle mir vor das dies bei Vim/Emacs aber auch bei Systemd so war... doch wenn man sich eine Grafikkarte oder einen WLAN-Treiber anschaut, merkt man sehr schnell das die Komplexität überhand nimmt. Aber auch das war ja schon bei Prozessoren so und zum Beispiel der Intel-ME.

Die gute Alternative sind wohl nur Systeme mit möglichst wenig Speicher, CPU und Akkuleistung. Die voraussetzen möglichst Sparsam mit allem um zu gehen.

[doedel]

Zu Andoid und anderen "Paketen", die als "Paket" verteilt werden...
Andoid habe ich vor zig Jahren auf einem Core2Duo gebaut, das hat hat Tage gedauert, aber mein S2 hatte dann mein Android.

Das ist eine komplette build-Umgebung, die alle libraries beinhaltet. Da kommt ein Compiler mit, bestimmte, gepatchte libraries, viel viel eigener Kram, ...
Da ist es die einzig wartbare Möglichkeit, einen riesen Ordner zu schaffen, in den man entweder per chroot reingeht oder per cd und dann ein build-script ausführt. Ist bei buildroot, openembedded und anderen auch so.

Ich habe mal code für ein Nokia N900 compiliert, da kam die Toolchain in einer fertigen VM. Ich glaube sogar, das war gentoo. Kann man ich aber auch irren. Das finde ich "ein wenig oversized". Dein Beispiel mit dem Mastodon Server kann ich gut nachvollziehen. Das gleiche mit einer VM für einen Compiler. Es mag wartbar sein und bei Nokia vielleicht auch so verwendet werden, mit Vorteilen... Aber hätte man nicht einfach ein Paket vom Compiler schnüren können?

Das ist für mich sehr unsauber im Hinblick auf das laufende Gesamtsystem (ein Server, beim Desktop gibt es sicher ähnliche Sünden...).

Immer wenn mir tools wie Paketmanager einer Scriptsprache oder so begegnen, dann habe ich da auch immer komisches Gefühl dazu. Ich kann nicht genau sagen warum, vielleicht sogar nur die Faulheit ("Schon wieder was neues...").
Git führt metadaten über alle Änderungen und braucht so echt viel Platz. rsync ist da einfacher und in vielen Fällen schon mehr als ausreichend. Persönlich habe ich lieber, wenn in solchen Umgebungen rsync, wget und curl arbeiten, als mit git-repos. Aber das ist echt nur Geschmackssache, begründen kann ich das nicht...

Der einzige für mich "saubere Weg" um sowas Unsauberes zu machen, wie an der Paketverwaltung vorbei ist das nutzen von Ordnern im /home-Ordner oder unter /opt.
Das einzige was da "rausgehen" darf, sind ein paar symlinks.
Gerade habe ich das Beispiel mit dem open-watcom compiler. Dort gibt es ein 350mb dicken Ordner mit compilern für DOS, Windows/ 8086-386 und AXP. Jede Host-Architektur hat einen Unterordner. Ich packe den also nach /opt/ow und füge /opt/ow/bin64l zum Pfad hinzu.
Andere Programme wie eagle oder vmware machen das auch so.

Ebenso aufgebaut, nur für jeweils 1 Host System, sind die arm-toolchains von ARM und anderen Anbietern oder cegcc für Windows CE targets.

Man kann solche "blobs" auch sauber aufziehen, wie man daran sieht. Finde ich...

[forrestfunk81]

Die Programmiersprachen-Paketverwaltungen oder besser Buildsysteme sind halt Entwickler- und Release- Tools. Niemand möchte eine große Anwendung mit vielleicht Hunderten von transitiven Abhängigkeiten ohne diese Tools erstellen. Der Usecase, dass Endanwender ihre Binaries selbst kompilieren, ist bei diesen Buildtools einfach nicht vorgesehen oder out of scope.

Und ja, es ist sehr schade, dass die Integration in Portage so schwierig ist. Ich habe lange Zeit die X Versuche verfolgt, Maven in Portage zu integrieren. Aber das ist der Tatsache geschuldet, dass bei Gentoo alles kompiliert wird. Debian und Co können einfach die Binaries nehmen, die von Maven ausgespuckt werden. Aber bei Source Distros gibt es dann zwei Tools, die sich um die Paketabängigkeiten kümmern wollen. Dass diese Build Tools so einen Edge Use Case nicht berücksichtigen, kann man ihnen denke ich nicht vorwerfen. Denn das wofür sie geschrieben wurden, machen sie ganz gut.

Bei den Docker Installationen bin ich etwas zwiegespalten. Das Prinzip nur noch ein paar Config Files zu haben und die einzuchecken (configuration as code) finde ich super. Man kann einfach zurückrollen oder auf andere Maschinen ausweichen. Man hat ein schön abgeschottetes System, welches sich immer gleich verhält und wenn man den Container weg wirft, bleibt auch nichts auf dem Host zurück.

Allerdings traue ich "dem Internet" nicht und würde keinesfalls irgendwelche Container bestehend aus 10 oder mehr Layern installieren, wo man nicht weiß was da alles mitkommt. Es ist allerdings auch kein Hexenwerk die Dinger selbstzubauen.

Und wer "curl -s http ://unknown.website.com/dubious.sh | bash -s --" ausführt ist selbst schuld
_________________
# cd /pub/
# more beer

[l3u]