>>78621
Arsch mit i3

>>77984
Das ist korrekt. Debian mit Gnome kriegt bei Felix auch nur 4/10 Punkten, aber alle Alternativen kriegen noch weniger.

Felix benutzt unironisch Debian mit Gnome. Es ist sehr gut.

>>78250
Bist nur mett, weil du dich täglich von deinem Betriebssystem in den Arsch penetrieren lässt und es nicht ertragen kannst, dass es auch Betriebssysteme gibt, die die anale Jungfräulichkeit erhalten.

>>77989
Doch

Irgendjemand sollte eine kommerzielle Linux-Version anbieten für Leute die zu blöd zu frickeln sind und blöd genug für kostenlose Software zu zahlen. Gibt sicherlich Schnittmengen.

>>77829
Nun, man nimmt das Beste was da ist. Leider ist alles andere noch weniger brauchbar. Ist halt so.

Wenn du qualitative Weichware willst, hast du keine andere Wahl. Kannst ja dein eigenes System zusammentippeln oder auf grafische Benutzeroberflächen komplett verzichten, dann hast du weitestgehend funktionstüchtige Weichware. Ansonsten einfach damit leben, wie wir es alle so tun!

>>77780
Sie meinen Jauchegrube aus Backdoors, ungepatchten Sicherheitslücken und stetig wachsender,rektaler Penetration gleichender Nutzergängelung? Danke, aber nein.

Ein Softwarenhaus aus Redmond stellt die nötigen Lösungen seit mindestens drei Jahrzehnten her.

>>77714
>Ist auch alles ganz nett, ausser die Pakete, die nach einem Update mal wieder nicht kompilieren wollen.
Selten der Fall, solange man experimentellen Systemkonfigurationen fernbleibt. Ist halt der Vorteil, wenn die ganze Distro so aufgesetzt ist und das QA-Team an den Paketen arbeitet, anstatt irgendwelcher Nutzerfrickeley. Updateschwemme hält sich bei Stable auch im Rahmen. Für einige sehr schlimme Pakete gibt es Binärversionen; die haben aber natürlich weniger Konfigurationsbreite, weil man die volle Kontrolle halt nur per Quellcode hat.

>>77661
Gut, mit Arch hast du dank AUR auch einen Sumpf von Programmen, die der Paketmanager selbst kompiliert. Ist auch alles ganz nett, ausser die Pakete, die nach einem Update mal wieder nicht kompilieren wollen. Aber eigentlich ist das Hauptargument gegen jeden Furz selbst kompilieren einfach die CPU-Zeit. Das dauert mir einfach zu lange und wenn man dann jede Woche wieder n Updates hat, weil mal wieder wer die Sicherheitspatches verkackt hat, dann verbringt der Rechner praktisch die Hälfte seiner Uptime mit Kompilieren inklusive de m damit verbundenen hohen Stromverbrauch - in Zeiten von Ukrainekrieg und Gasknappheit eher weniger geil, wir müssen schliesslich sparen!

>>77667
Wie in >>69031 erwähnt, ist das einzige, was Felix von Hand patchieren musste, GTK3 für den Feuerfuchs. Da braucht man folgenden Patch (muss eventuell für neuere Versionen minimal angepasst werden) und muss entweder die Abhängigkeit aus dem Ebuild schmeißen oder mit package.provided tricksen.

>>77619
>So, das macht D-Bus im Großen und Ganzen.
Korrekt. Allerdings ging es mir mehr darum, welches Problem dadurch gelöst wird. Und da bin ich eben der Meinung, dass D-Bus überhaupt keine Probleme löst, sondern nur neue schafft.

>Die Alternative zu D-Bus ist, dass die Anwendungen einfach die Interprozess-Primitive des Betriebsystems benutzen
Exakt. Unix hat bereits Domänensockets und bringt damit alles mit, was man braucht. Einfach JSON über einen Domänensocket und fertig. Wozu diesen ganzen OOP-Müll mit XML-Interfacespezifikationen?

Das einzige, was man wirklich bräuchte, wäre eine Standardisierung. Dort hätte D-Bus eventuell trotz der beschissenen Implementierung einen Mehrwert liefern können. Aber genau hire liefert D-Bus nicht. Beispiel: Ich hatte mal das Vergnügen, unter Linux den Bildschirmschoner/Lock-Screen/Standby-Modus zu steuern, also verhindern, dass er aktiviert wird oder ihn gezielt aktivieren. Geht leider nur per D-Bus. Das Problem ist aber, dass die Bildschirmschoner-Spezifikation von D-Bus so schlecht ist, dass jede Schreibtischumgebung (Gnome, KDE etc.) ihren eigenen Standard unter einer abweichenden Adresse implementiert, sodass man unterm Strich doch wieder vier verschiedene Implementierungen braucht. Man hat also nicht nur nichts gewonnen gegenüber handgedengelten Lösungen, sondern man hat auch noch diesen ganzen D-Bus-Ranz an der Backe.

Felix verwendet den Fensterverwalter i3. Eine der schönen Sachen bei i3 ist, dass man ihn einfach per i3-msg auf der Kommandozeile steuern kann. Z.B. i3-msg exit, um die aktuelle Sitzung zu beenden, oder i3-msg restart, um den Fensterverwalter neuzustarten nach Update oder Konfigurationsänderung. Intern sendet der einfach JSON (iirc) über einen Domänensocket. Und deshalb funktioniert es einfach. Immer. 100% zuverlässig. Hatte damit noch nie ein Problem. Wenn i3 D-Bus verwenden würde, dann würde es die Hälfte der Zeit nicht richtig funktionieren. Dann würde es irgendwo komische Hänger geben, Befehle kämen nicht an oder ein Prozess würde nicht starten, weil irgendeine Lib die falsche Version hat. Wenn man mehrere Sitzungen auf verschiedenen TTYs hat, dann gibt es bei D-Bus auch immer irgendwelche komischen Bugs. Mit i3 hat man niemals solche Probleme, einfach nur, weil es kein D-Bus verwendet. Leider sind systemd, Pulseaudio, GTK und Co. alle mit D-Bus infiziert.

>>77650
Oke, wenn das tatsächlich so weitgehend und einfach via USE-Flags geht (also von Haus aus sehr einfach rausreißbar ist), sollte sich dieser Felix mal Gentoo näher anschauen.

>>77657
emerge dietchan ist jetzt nicht sonderlich aufwändiger als pacman -S dietchan. Die Abneigung gegenüber Selbstkompilierung klang da schon eher, als ginge man davon aus, dass man da Hand anlegen müsse.

>>77650
>Gentoo
War Gentoo nicht das Konzept "Ich kompiliere alles selbst"? Damit bestätigst du ja nur, was ein Anderer hier bereits sagte, dass er jedes Paket selbst kompilieren musste, weil bei seiner Distro standardmässig alles mit ALLEM(TM) kompiliert wird?

>>77619
>Die Alternative zu D-Bus ist, dass die Anwendungen einfach die Interprozess-Primitive des Betriebsystems benutzen oder gar nichts benutzt, d.h. die Funktionalität rausreißt. Also Selbstkompilieren und einen Haufen Patches vorhalten. -_-
Oder einfach Gentoo. Felix muste genau ein (1) Paket patchen.