Andere "Linuxe": Void, NixOS, Alpine,... Erfahrungen/Meinungen

[BBig]

Moin zusammen,
mein neuer PC ist unterwegs und ich mag nach Jahren
(bis jetzt lief Antergos (https://distrowatch.com/table.php?distribution=antergos) mit dann Packetquellen auf "pure" Arch)
neu installieren.

Ich bin schon lange mit Linux unterwegs und eine Weisheit, die ich im Laufe der Jahre erlangt habe, ist, dass egal welche Distro, es ist doch Linux.

Alle haben einen Kernel - LTS und / oder mainline,
alle haben Audio - manche schon Pipewire,
alle haben eine Init - viele haben systemd,
alle haben xorg - viele probieren sich "schon" an wayland,
alle bekommt man installiert, wenn man partionieren kann, entscheidet sich, ob ext4 oder ein anders Filesystem
und man bootet meistens in den Bootloader Grub.
Userland and Userland-Apps sind mehr oder weniger installiert - mal mehr kde, mal mehr gtk,
dann benutzt man den Paketmanager (mit oder ohne GUI), um ein seine präerfierten Apps zu kommen.
... was sich sagen mag:
- Alle benutzen "under the hood" doch eigentlich das selbe.

Klar, mache haben mehr vorkonfiguriert, haben beispielsweise den Desktop schon gericed,
aber im Endeffekt, passt man die selben *.confg-Files an, installiert die passende Firmware.
Was man an Software braucht, installiert man nach. Schmeißt das raus, was man nicht mag.

Nach Jahren mit Arch-Linux kann ich sagen: "Ich mag Arch, eben weil es rolling ist."
Neuste Software war mal wichtig für mich, gerade bei neuster Hardware sollte man schauen, dass der Kernel nicht zu alt ist.
Aber nach Jahren weiß ich auch, dass das ach so tolle AUR für mich nicht wichtig ist.
Weil es gerade auch - für mich - die größe Fehlerquelle war.

So steht für mich als Auswahl an Distros eigentlich nur eins fest: Rolling!


Wenn ich mir die Distros so anschaue, dann stechen ein paar hervor:

- Voidlinux (https://voidlinux.org/): Eigenbau, kein Abkömmling.
- NixOS (https://nixos.org/): deklarative Systemkonfiguration.
(- Alpine (https://www.alpinelinux.org/): dann eher doch nicht, weil Musl & BusyBox, aber sexy fast!)
(.. oder doch bei "Arch" (https://archlinux.org/) bleiben: vll ohne systemd? - Artixlinux (https://artixlinux.org/); gericed & Calamares-Installer? - EndeavourOS (https://endeavouros.com/))

- XXX - "Welche habe ich nicht auf dem Schirm?"

===

Für welche Distro habt ihr euch entschieden? Und warum?
Vor allem, habt ihr Erfahrungen mit "anderen Linuxen" - läuft bei euch Void, NixOS, Alpine oder was ganz anderes?
Seid ihr vll Slackies (http://www.slackware.com/)? Tuned ihr gerne eure Flags und gentooed (https://www.gentoo.org/) euch einen?

Bin gespannt, Bbig

[Rooter]

Ich bin bei Linux Mint xfce weil ich einen simplen, stabilen Ersatz für Win7 wollte. :)

Dir hilft sicher der
https://pbs.twimg.com/media/FJPbLP_WQAAC4SG?format=jpg&name=4096x4096
MfG
Rooter

[raumfahrer]

Habe seit einigen Jahren Void (mit glibc) im Einsatz, aktuelles System ist eine Installation von Herbst 2018. Gründe von damals muss ich mir jetzt aus den Fingern saugen. Wollte Rolling, bin Bastelkind aber keine Lust auf _alles_ kompilieren und wollte um die ganze Systemd-Diskussion rum mal die praktisch einzige ernsthafte Alternative ausprobieren.

Thema Musl: Hat Void auch "eine" Variante, habe ich ursprünglich auch mal ausprobiert, bin aber relativ schnell in Grenzen gerannt. Was Spiele angeht bist du da praktisch auf opensource eingeschränkt.

Die Musl-Variante an sich ist dann auch ein Fluch und manchmal Segen von Void, unabhängig, ob du sie fährst oder nicht. Hier und da werden Pakete (bzw. deren Updates) zurückgehalten, bis sie mit Musl kompilierbar sind. Das hat teilweise den positiven Effekt, dass manches verbuggte Zeug direkt übersprungen wird.

xbps als Paketmanager ist ziemlich flott, per xbps-src kann man sich relativ einfach eigene Pakete erstellen und lokal pflegen/installieren. runit als init/service management ist schon was anderes als Systemd, bei weitem nicht so mächtig. Ist aber auch gewissermaßen der Punkt.

Was Updates angeht würde ich Void tendenziell eher zu den langsameren Rolling zählen. Insbesondere bei den großen Sachen, zum einen weil es ein Ziel der Distribution ist ("Void focuses on stability, rather than on being bleeding-edge"), zum anderen, weil Musl+arm scheinbar nicht immer schmerzfrei ist.

Ich mache eigentlich täglich ein Update, die offiziellen Kanäle verfolge ich nur sehr peripher. Bislang hatte ich vlt. eine Handvoll, eher weniger, Probleme, die auf gröbere Void-eigene Änderungen zurückgegangen sind.

Kann mich grad ehrlich an keinen Moment erinnern, wo ich dachte "Void stinkt, das wär woanders viel besser, wär es nicht so nervig würd ich was anderes installieren".

PS: amdgpu + mesa only, keine Ahnung wie es mit Nvidia wäre.

[Shink]

Thema Musl: Hat Void auch "eine" Variante, habe ich ursprünglich auch mal ausprobiert, bin aber relativ schnell in Grenzen gerannt. Was Spiele angeht bist du da praktisch auf opensource eingeschränkt.

So ein musl-System mit Steam über Flatpak klingt doch ganz nett. Wine sollte auch gehen.
Welche closedsource Linuxspiele meinst du denn?
Nvidia würde ich ohnehin nicht wirklich empfehlen unter Linux.

Zum Thema "nicht am Schirm": Clear Linux vielleicht. Ist halt auch Kategorie "ohne Flatpak kommt man nicht weit".

[raumfahrer]

So ein musl-System mit Steam über Flatpak klingt doch ganz nett. Wine sollte auch gehen.
Welche closedsource Linuxspiele meinst du denn?
Nvidia würde ich ohnehin nicht wirklich empfehlen unter Linux.

Das war alles so im Zeitraum 2016-2018, Sandbox&Co waren für mich da noch kein Thema. Kann gut sein, dass es mittlerweile praktikabel ist.

[lumines]

Ehrlich gesagt bin ich nicht so der Freund von Rolling Releases. Wenn man es mag, spricht natürlich wenig dagegen. Man sollte dann aber auch einmal die Distributionen mit kurzen Release Zyklen genauer unter die Lupe nehmen, z.B. die nicht-LTS-Versionen von Ubuntu oder Fedora. Man bekommt eine etwas stabilere Basis (im Sinne von weniger ändernd) als bei einem Rolling Release, hat aber den Vorteil, dass man zu genauen Zeitpunkten ein neues Release bekommt und switchen kann.

Im Fall von Fedora ist ein "Release" aber auch gar nicht so extrem scharf definiert. In Fedora werden je Release auch schon ganz gerne einmal Major-Updates von einigen Paketen veröffentlicht. Nur größere fundamentale Änderungen werden auf ein neues Release verschoben.

Musl-basierte Distributionen sind für den Desktop wahrscheinlich wirklich nur in Kombination mit Flatpak sinnvoll. Wobei man sich dann natürlich fragen könnte, ob man nicht besser direkt eine glibc-basierte Distribution genommen hätte. Für Server-Anwendungen sind das aber ganz nette Distributionen, wenn die Software kompatibel ist, die man einsetzen will.

[Shink]

Flatpak wäre halt für "die ein, zwei Anwendungen, die anders nicht gehen".
Ubuntu ist auch abseits der LTS-Versionen ein Stück weit davon entfernt, aktuell zu sein. Generell gefällt mir die Richtung, in die Ubuntu geht, nicht so gut in den letzten Jahren: Klar ist das bequem, den Browser nach Snap zu verschieben aber gerade da nerven Overhead und Startzeiten. Für aktuelle Treiber braucht man ein inoffizielles RPM, was beim Umstieg auf ein Beta-Release dann natürlich unauflösbare Abhängigkeiten haben kann.

Fedora ist tatsächlich super aktuell und manchmal frag ich mich, warum die Releases machen. Da kommen neue Major-Versionen von Kernels, Anwendungen - wenn ich das richtig mitbekomme, sind die nicht einmal immer stable.

[lumines]

Fedora ist einerseits das Testbett für neue Technologien, aber parallel eben trotzdem eine Distribution, die einen gewissen Stabilitätsanspruch für den alltäglichen Betrieb hat. Amazon bauen z.B. aus Fedora mittlerweile ihr Amazon Linux und nicht mehr aus dem Quellcode von RHEL.

openSUSE Tumbleweed geht ja in eine ähnliche Richtung. Zwar kein Rolling Release, aber trotzdem sehr aktuell.

Sollte man jedenfalls nicht unterschätzen, wenn man bisher nur Rolling-Release-Distributionen oder LTS auf dem Radar hatte. Das sind die beiden Extreme, aber dazwischen gibt es auch sehr viel.

[Dino-Fossil]

Für mich war der Grund auf rolling release zu gehen ein neuer (AMD) Laptop vor zwei Jahren, da ich nur so zeitnah eine gute Unterstützung der Hardware bekam. Aber sobald man damit leben kann, dass Software und die Unterstützung der Hardware eventuell ein paar Monate hinterher hängen, kommt man auch ohne RR gut hin, ja.

[BBig]

Ich bin bei Linux Mint xfce weil ich einen simplen, stabilen Ersatz für Win7 wollte. :)

Dir hilft sicher der
https://pbs.twimg.com/media/FJPbLP_WQAAC4SG?format=jpg&name=4096x4096
MfG
Rooter

Der Spoiler geht bei mir nicht; bleibt leer.
Aber "Der c't–Linux-Netzplan: So finden Sie die passende Distribution" (https://www.heise.de/ratgeber/Der-c-t-Linux-Netzplan-So-finden-Sie-die-passende-Distribution-6330180.html) kenne ich.


Die Standard-Linuxe haben viele auf dem Radar; spricht ja auch nichts gegen.
Auf meinem Laptop läuft Xubuntu (https://xubuntu.org) LTS.

Der Laptop ist aber alt - Thinkpad T460 - und eher Backup und Reisemaschine.
Da braucht nichts super-aktuell sein.

Habe seit einigen Jahren Void (mit glibc) im Einsatz, aktuelles System ist eine Installation von Herbst 2018. Gründe von damals muss ich mir jetzt aus den Fingern saugen. Wollte Rolling, bin Bastelkind aber keine Lust auf _alles_ kompilieren und wollte um die ganze Systemd-Diskussion rum mal die praktisch einzige ernsthafte Alternative ausprobieren.

Thema Musl: Hat Void auch "eine" Variante, habe ich ursprünglich auch mal ausprobiert, bin aber relativ schnell in Grenzen gerannt. Was Spiele angeht bist du da praktisch auf opensource eingeschränkt.

Die Musl-Variante an sich ist dann auch ein Fluch und manchmal Segen von Void, unabhängig, ob du sie fährst oder nicht. Hier und da werden Pakete (bzw. deren Updates) zurückgehalten, bis sie mit Musl kompilierbar sind. Das hat teilweise den positiven Effekt, dass manches verbuggte Zeug direkt übersprungen wird.

xbps als Paketmanager ist ziemlich flott, per xbps-src kann man sich relativ einfach eigene Pakete erstellen und lokal pflegen/installieren. runit als init/service management ist schon was anderes als Systemd, bei weitem nicht so mächtig. Ist aber auch gewissermaßen der Punkt.

Was Updates angeht würde ich Void tendenziell eher zu den langsameren Rolling zählen. Insbesondere bei den großen Sachen, zum einen weil es ein Ziel der Distribution ist ("Void focuses on stability, rather than on being bleeding-edge"), zum anderen, weil Musl+arm scheinbar nicht immer schmerzfrei ist.

Ich mache eigentlich täglich ein Update, die offiziellen Kanäle verfolge ich nur sehr peripher. Bislang hatte ich vlt. eine Handvoll, eher weniger, Probleme, die auf gröbere Void-eigene Änderungen zurückgegangen sind.

Kann mich grad ehrlich an keinen Moment erinnern, wo ich dachte "Void stinkt, das wär woanders viel besser, wär es nicht so nervig würd ich was anderes installieren".

PS: amdgpu + mesa only, keine Ahnung wie es mit Nvidia wäre.

Hört sich super an; mein neuer PC ist mit 5600G (APU Cezanne).

Zur Zeit ist Void auch meine #1; einfach mal ein anderes Rolling als Arch.
Opensuse Tumbleweed (https://www.opensuse.org/) wäre auch eine Überlegung; steht bei mir aber nicht hoch im Kurs,
weiß noch nicht mal warum... :redface:

So ein musl-System mit Steam über Flatpak klingt doch ganz nett. Wine sollte auch gehen.
Welche closedsource Linuxspiele meinst du denn?
Nvidia würde ich ohnehin nicht wirklich empfehlen unter Linux.

Zum Thema "nicht am Schirm": Clear Linux vielleicht. Ist halt auch Kategorie "ohne Flatpak kommt man nicht weit".

Ich bin kein Fan von Flatpak oder Snaps; ich weiß, dass da die Entwickling hingeht.
Aber meine "älteren" Erfahrungen waren nicht gut.

Ich mag auch nicht "viele Libs und Co" doppelt und dreifach auf dem Rechner haben.
Wenn es ums Thema Sicherheit & Updates geht, traue ich auch meiner Distro & Repo mehr als den "Stores und Hubs". Wahrscheinlich auch ein Vorurteil.

Clear Linux (https://clearlinux.org/) habe ich schon ein paar Mal bei Phoronix (https://www.phoronix.com/) gelesen: Ich weiß, dass das eine auf Performance getrimmt Distro von Intel ist, mehr aber auch nicht. Kenne auch keinen, der mit Clear Linux unterwegs ist.
Sollte man sich die anschauen?

Ehrlich gesagt bin ich nicht so der Freund von Rolling Releases. Wenn man es mag, spricht natürlich wenig dagegen. Man sollte dann aber auch einmal die Distributionen mit kurzen Release Zyklen genauer unter die Lupe nehmen, z.B. die nicht-LTS-Versionen von Ubuntu oder Fedora. Man bekommt eine etwas stabilere Basis (im Sinne von weniger ändernd) als bei einem Rolling Release, hat aber den Vorteil, dass man zu genauen Zeitpunkten ein neues Release bekommt und switchen kann.

Im Fall von Fedora ist ein "Release" aber auch gar nicht so extrem scharf definiert. In Fedora werden je Release auch schon ganz gerne einmal Major-Updates von einigen Paketen veröffentlicht. Nur größere fundamentale Änderungen werden auf ein neues Release verschoben.

Musl-basierte Distributionen sind für den Desktop wahrscheinlich wirklich nur in Kombination mit Flatpak sinnvoll. Wobei man sich dann natürlich fragen könnte, ob man nicht besser direkt eine glibc-basierte Distribution genommen hätte. Für Server-Anwendungen sind das aber ganz nette Distributionen, wenn die Software kompatibel ist, die man einsetzen will.

Wie viele habe ich /home ausgelagert; nicht nur andere Partition, sondern gleich andere SSD. Spricht also nichts gegen "ab und zu" neu zu installieren; oder willst du mir sagen, dass nun apt-get dist-upgrade funktioniert? ;D
Denn sonst installiert man ja alle Nase lang neu; Interims Releases sind wie lange supported? 1 Jahr bei Canonical? ... ne, da hat doch keiner Bock drauf.

Jetzt bin ich aber gespannt, was läuft den bei dir, lumines? Kann nicht glauben, dass bei dir ein Interims Release läuft...

Flatpak wäre halt für "die ein, zwei Anwendungen, die anders nicht gehen".
Ubuntu ist auch abseits der LTS-Versionen ein Stück weit davon entfernt, aktuell zu sein. Generell gefällt mir die Richtung, in die Ubuntu geht, nicht so gut in den letzten Jahren: Klar ist das bequem, den Browser nach Snap zu verschieben aber gerade da nerven Overhead und Startzeiten. Für aktuelle Treiber braucht man ein inoffizielles RPM, was beim Umstieg auf ein Beta-Release dann natürlich unauflösbare Abhängigkeiten haben kann.

Fedora ist tatsächlich super aktuell und manchmal frag ich mich, warum die Releases machen. Da kommen neue Major-Versionen von Kernels, Anwendungen - wenn ich das richtig mitbekomme, sind die nicht einmal immer stable.
Fedora ist einerseits das Testbett für neue Technologien, aber parallel eben trotzdem eine Distribution, die einen gewissen Stabilitätsanspruch für den alltäglichen Betrieb hat. Amazon bauen z.B. aus Fedora mittlerweile ihr Amazon Linux und nicht mehr aus dem Quellcode von RHEL.

openSUSE Tumbleweed geht ja in eine ähnliche Richtung. Zwar kein Rolling Release, aber trotzdem sehr aktuell.

Sollte man jedenfalls nicht unterschätzen, wenn man bisher nur Rolling-Release-Distributionen oder LTS auf dem Radar hatte. Das sind die beiden Extreme, aber dazwischen gibt es auch sehr viel.

Fedora ist für mich ein rotes Tuch; eingeordnet unter "Redhat ist aufgekauft von IBM"; Gnome-centric, non-rolling, Big Business gibt nichts auf seine Community. Ergo Schmuddelkind! :tongue:

Irgendwie hat mich Fedora nie interessiert, es gibt so viele gute Distros, dass Fedora für mich nie in Frage kam.

[Berniyh]

Nach Jahren mit Arch-Linux kann ich sagen: "Ich mag Arch, eben weil es rolling ist."
Neuste Software war mal wichtig für mich, gerade bei neuster Hardware sollte man schauen, dass der Kernel nicht zu alt ist.
Aber nach Jahren weiß ich auch, dass das ach so tolle AUR für mich nicht wichtig ist.
Weil es gerade auch - für mich - die größe Fehlerquelle war.
Ich finde nicht, dass AUR das Merkmal ist mit dem sich Arch von anderen Distributionen abhebt.
So außerordentlich ist das nämlich auch gar nicht. Bei jeder Distribution kann man externe Paketquellen nutzen, teilweise sogar wesentlich einfacher als mit den AUR.
Bei Fedora oder Suse fügst du einfach rpm Fusion als Quelle hinzu und bekommst so die wesentlichsten Zusatzpakete ebenfalls. Meistens sogar besser gewartet als die im AUR.
Auch für Debian oder Ubuntu gibt es natürlich externe Quellen, wenn du z.B. die neuste KDE oder Gnome Version auf einem Ubuntu LTS Release haben willst.
Man könnte Arch zuschreiben, dass es etwas einfacher als bei deb und rpm ist selbst-kompilierte Pakete zu integrieren, allerdings finde ich persönlich das hoch gelobte pkgbuild Design wirklich furchtbar. Das ist eigentlich eine Einladung Dinge zu verpfuschen und falsch zu machen.
Da ist auch Gentoo schon deutlich weiter im Design der ebuilds. (zugegeben ist der Vergleich etwas unfair, denn bei Gentoo ist das ja die Grundlage der Distribution)

Aus meiner Sicht gibt es eher 2 andere Dinge, die für Arch sprechen:
1. Wie von dir schon angesprochen: rolling release
ich hab über die Jahre immer wieder PCs anderer betreut, die unter Linux laufen sollten (aus Sicherheitsaspekten), aber auch "benutzbar" sein sollten. Sowas wie Gentoo kommt also eher nicht in Frage.
Eingesetzt habe ich da Opensuse, Ubuntu und Fedora. Besonders bei Ubuntu und Fedora waren aber die Release Upgrades immer richtig furchtbar, irgendwas ging eigentlich immer schief und man durfte hinterher Fehler ausbügeln.
Bei Fedora das ganze sogar dann alle 1.5 Jahre, bzw. ich habe es dann meistens jährlich gemacht. Es wird gerne behauptet, dass das der stabilere Ansatz ist, das kann ich aus meiner Erfahrung heraus allerdings nicht nachvollziehen. Arch hingegen läuft auf meinem Gaming PC jetzt seit einigen Jahren und macht sich da richtig gut. Probleme gab es hier so gut wie gar nicht und wenn, dann waren es kleinere Probleme. Dinge wie "PC startet gar nicht" kamen z.B. gar nicht vor. Bei Ubuntu oder Fedora hingegen ist das gerne mal nach einem Update passiert, dann inkl. längerer Telefonsessions, abgefilmten Bildschirmen und so Späßen.
Ich werde daher die Systeme nach und nach testweise durch Arch ersetzen, in der Hoffnung, dass es reibungsfreier läuft.
2. Dokumentation. Ich hab es hier glaube ich schon mehrfach erwähnt, das Arch Wiki ist aktuell eine der besten Quellen für Nutzerinformationen im Linuxbereich. Natürlich haben auch andere Distributionen solche Seiten, aber auf z.B. ubuntuusers.de oder gentoo-wiki.com (gibt es zum Glück nicht mehr) bin ich doch arg oft auf sehr veraltete oder gar falsche oder gefährliche Informationen gestoßen. Deutlich mehr als im Arch Wiki.
Nun wird gerne gesagt, dass Arch eine etwas "schwierigere" Distribution sei, das kann ich allerdings vor dem Gesichtspunkt nicht ganz nachvollziehen, denn in meinen Augen ist eine gute Dokumentation viel mehr wert als 1-2 hübsche Programme zum Rumklicken, welche dann aber typischerweise auch sehr begrenzte Möglichkeiten haben.
- Voidlinux (https://voidlinux.org/): Eigenbau, kein Abkömmling.
Als Nutzer einer Eigenbaudistribution (Exherbo) muss ich dich da warnen. Du musst dir hier schon im Klaren sein, dass das Risiko ist irgendwo in Probleme zu laufen, schon deutlich größer ist als bei einer etwas größeren Distribution wie z.B. Arch Linux.
Schlicht und einfach, weil tendenziell weniger Leute dran mitarbeiten und auch weil es weniger Leute nutzen. Es funktioniert hauptsächlich dann gut, wenn man die richtigen Paradigmen anwendet. Bei uns (also Exherbo) ist das z.B. möglichst wenig Patches anzubringen. d.h. man verwendet die Software größtenteils so wie sie von den Entwicklern released wird (von kritischen Bugfixes oder Sicherheitsupdates natürlich mal abgesehen).
Wenn man hingegen, so wie z.B. Gentoo, alles fröhlich hin und her patched was nicht bei 3 auf dem Baum ist, dann wird das zu einem regelrechten Minenfeld.
Prinzipiell ist Void Linux aber jetzt auch nicht die kleinste Distribution.
Wenn es dir also darum geht zu experimentieren, dann kannst das ggf. schon mal ausprobieren.
(.. oder doch bei "Arch" (https://archlinux.org/) bleiben: vll ohne systemd? - Artixlinux (https://artixlinux.org/); gericed & Calamares-Installer? - EndeavourOS (https://endeavouros.com/))
Davon würde ich dringend abraten. Ich kann auch den ganzen Hate gegen systemd nicht wirklich nachvollziehen. Die Diskussionen damals waren teilweise wirklich absurd. Das hatte schon Züge wie man sie jetzt vor einiger Zeit auch bei den Corona Leugnern/Impfgegnern gesehen hat. d.h. es werden Dinge aus dem Zusammenhang gerissen, einfach irgendwelche Behauptungen aufgestellt. Das meiste wurde zigmal debunked, aber derartiges wurde natürlich auch ignoriert. z.B. hält sich hartnäckig die Behauptung, dass systemd alles in eine Binary packen würde, was aber einfach nur Quark ist. Das init von systemd ist (auf meinem System) gerade mal 87kB groß. Zum Vergleich: das simple GNU cp Programm hat 108 kB.
Im Endeffekt ging es bei dem ganzen Hate eigentlich auch gar nicht so wirklich um technische Gründe, die wurden eher vorgeschoben (und entsprechend hanebüchen waren oft auch die Argumente), sondern um die persönliche Abneigung dieser Menschen gegen Lennart Poettering. Das hatte vor allem mit dem Start von Pulseaudio zu tun, der alles andere als rund verlief, es gab so einiges an gravierenden Bugs. Auch der Start von systemd war etwas holprig und man hatte anfangs schon hier und da das Gefühl, dass mehr Wert auf noch ein Feature als Bugfixing gelegt wurde.
Vor allem aus diesem Hate heraus haben sich dann Distributionen wie Devuan gegründet und das ist auch einer der Gründe, weshalb man das mit Vorsicht genießen sollte. Ein neues Projekt aus so einer negativen Stimmung heraus zu gründen bewirkt meistens weder eine halbwegs brauchbare Struktur, noch einen brauchbaren Plan für die Zukunft.
Meistens holt man sich mit solchen Forks, die irgendwelchen altbackenen Strukturen nachträumen, auch signifikante Risiken ins Boot. Ein Beispiel hierfür ist das Trinity Projekt, welches ein Fork von KDE 3.5 ist.
Da hatte ein KDE Entwickler sich mal kurz die Zeit genommen zu prüfen, ob eine Reihe von Sicherheitsproblemen aus späteren KDE Releases auch auf Trinity zutrifft, und tatsächlich war das der Fall. Davon wurde aber quasi nichts gefixt, auch nicht, nachdem er die Trinity Entwickler darauf hinwies. Es fehlt einfach an Personal für so große Projekte.

Das ist auch der wichtigste Punkt, weshalb ich von einem System ohne systemd abraten würde. systemd hat sich, weil die große Mehrheit der Entwickler hier eben die Vorteile sieht, unter Linux einfach als Standard durchgesetzt.
(Und hat übrigens auch die Standardisierung der Linux Desktops voran getrieben, einer der wesentlichen Gründe, weshalb es heute viel unkritischer ist sowas wie Steam auf irgendeiner Distribution laufen zu lassen, als nur z.B. auf Ubuntu. Das war früher nämlich auch ein Minenfeld …)
Immer, wenn du dich vom Standard wegbewegst, dann steigt das Risiko für Probleme signifikant an. Also z.B. wenn du Windows Spiele unter Linux spielen willst, statt unter Windows. Nicht, dass Windows frei von Fehlern wäre (ist es nicht …), aber es sind halt trotzdem Situationen die bei der Entwicklung nicht berücksichtigt und getestet wurden.
Und ebenso ist es eben auch, wenn du heute eine Linux Distribution ohne systemd nutzt. Entwickelt werden die Distributionen und Desktopumgebungen für die Schnittstellen von systemd. Ohne systemd brauchst du ggf. eine Reimplementierung dieser Schnittstellen (wie z.B. eudev), was aber nicht zwingend gut getestet sein muss. Und ggf. fehlen sogar Features die Programme erwarten.
Da ich zudem alle wesentlichen init Systeme im Linuxbereich der letzten 20 Jahre (also SysVInit, OpenRC, Upstart und systemd) genutzt habe kann ich dir zudem auch mit sehr hoher Sicherheit sagen, dass du durch einen Wechsel zurück zu SysVInit oder hin zu OpenRC keinen Gewinn haben wirst. systemd ist sicher nicht perfekt und ich stimme auch nicht mit jeder der Entscheidungen die da getroffen wurden überein, aber die Alternativen sind einfach nicht besser.
Wenn ich insbesondere an die Zeit mit SysVInit zurück denke, dann bin ich wirklich froh, dass wir diese dunkle Zeit hinter uns gelassen haben. Was hab ich mich damals mit irgendwelchen Shell Skripten rumgequält, das war wirklich zum Kotzen teilweise.
Im Horror erinnere ich mich heute noch daran, dass ich einen Dienst hatte, der sich – mit exakt den gleichen Parametern als exakt der User – in der normalen Shell starten lies, aber in dem init Skript dann gecrasht ist. Ich habe es da tatsächlich aufgegeben, weil ich es nicht gelöst bekommen habe.
systemd hat die Units hingegen auf die wesentlichen Informationen reduziert und den ganzen Schnickschnack (der eh in praktisch jedem Skript sehr ähnlich war) aus der Deklaration der Aufgabe weggelassen. Das war und ist eine ungemeine Erleichterung darin eine Unit zu schreiben.
Das soll nicht bedeuten, dass systemd keine Probleme machen kann. Ich hatte z.B. ein massives Problem mein systemd damals ordentlich eingerichtet zu bekommen. Hintergrund ist, dass ich für /home 2 Festplatten verwende die jeweils per cryptsetup unlocked werden müssen und dann zusammen ein btrfs Dateisystem ergeben. Nun erstellt systemd aber automatisch units und führt diese auch automatisch aus. Das führte dann in dem Fall dazu, dass das mount des btrfs fehlschlug, weil halt ggf. eine der unlock-units nicht schnell genug war und btrfs standardmäßig nicht degraded mounted.
Aber gut, in so einem Fall maskiert man diese Units halt, schreibt sich schnell selbst welche und damit funktioniert es dann wunderbar. Seit grob 10 Jahren ohne Probleme.
Generell sind es gerade die Verbesserungen, die die Gegner von Lennart Poettering gerne mal übersehen. Ich meine … ich finde den Typen auch echt nicht sympatisch, aber man muss schon ziemlich blind sein um zu behaupten, dass Pulseaudio nicht signifikante Fortschritte im Linux Audio Bereich gebracht hat. An der Stelle war und ist Linux sogar Windows voraus. Endlich gibt es mal vernünftige Unterstützung für Bluetooth Audio. Man kann einfach und schnell Ausgabegeräte wechseln, on-the-fly! Und man kann ggf. auch Programme unterschiedlichen Ausgabegeräten zuweisen. Natürlich ist auch Pulseaudio nicht perfekt, daher wird jetzt ja pipewire entwickelt, aber dennoch war Pulseaudio ein Schritt in die richtige Richtung und eben so verhält es sich eben auch mit systemd. Sollte sich eine Gruppe von Entwicklern also mal entscheiden einen Nachfolger für systemd zu entwickeln, dann bin ich mir ziemlich sicher, dass es sich in vielen Aspekten nahe daran orientieren wird, so wie es pipewire mit Pulseaudio macht.
Für welche Distro habt ihr euch entschieden? Und warum?
Zu Arch habe ich ja schon einiges geschrieben.
Meine andere Distribution ist Exherbo, was ein etwas ähnliches System wie Gentoo ist, allerdings mit anderen Paradigmen.
Das wird insbesondere klar, wenn ich mal noch auf den nächsten Punkt eingehe:
Tuned ihr gerne eure Flags und gentooed (https://www.gentoo.org/) euch einen?
Gentoo habe ich über mehrere Jahre auf meinem Desktopsystem genutzt, bevor ich bei Exherbo eingestiegen bin.
Die USE flags von Gentoo werden gerne hochgelobt, aber ehrlich gesagt sind die meisten USE flags ziemlich useless.
Gentoo hat hier das Paradigma alles optional zu machen, wenn es irgendwie geht. Notfalls auch mit Patches (und davon ehrlich gesagt nicht gerade wenige).
Das ist auch einer der Gründe, weshalb Gentoo überdurchschnittlich viele distributionsspezifische Bugs hat, einerseits, weil die Patches gerne selbst noch Probleme reinbringen, andererseits, weil in Programmen Features deaktiviert werden, bei denen die Entwickler nicht davon ausgehen, dass jemand so bescheuert sein könnte diese Features zu deaktivieren.
(Der andere Grund sind verpfuschte CFLAGS, welche manche User anwenden, von denen Gentoo aber immerhin in der Doku explizit abrät.)
Letztendlich gibt es nur 2 Gründe, weshalb USE flags (oder "options", wie sie bei Exherbo heißen) sinnvoll sind:
1. man spart sich 1 oder mehrere Pakete als Abhängigkeiten
2. man spart Ressourcen (i.e. Speicherplatz)

Man muss sich aber hier wirklich die Frage stellen wie sinnvoll das denn ist. Wenn man sich nicht gerade mit einem embedded System beschäftigt, dann spielen HDD/SDD und RAM Verbrauch heutzutage keine so große Rolle mehr, die entsprechenden Speichermedien sind relativ günstig.
Ich hatte gerade so einen Fall letzte Woche mit QtWebengine. Das will in Version 6 als Abhängigkeit cups. Nun habe ich schon seit > 10 Jahren keine Drucker mehr, weil ich einfach keinen brauche (bzw. der nächste Copy Shop auch nur 10min entfernt ist). Also hab ich das auch in etwa so lange nicht mehr installiert. Nun hat QtWebengine sogar eine compile option um printing zu deaktivieren und ich habe damit experimentiert um zu sehen, ob ich es ohne cups hinbekommen kann.
Funktioniert aber nicht, die Option ist im Grunde nur Deko. (Liegt hauptsächlich daran, dass QtWebengine ein grauenvoll verschachtelte Library ist mit chromium im Huckepack und damit auch mit ineinander verschachtelten Build Systemen)
Im Ende habe ich damit eigentlich nur ca. 1-1.5h meiner Zeit sowie ca. 5-6h CPU Zeit komplett verschwendet (QtWebengine 6 braucht auf einem 5950X ca. 1h compile time.).
Mein komplettes /usr (ohne /usr/src, wo hauptsächlich Kernel Sources liegen) "wiegt" gerade mal 14G. Das ist jetzt kein sonderlich großer Anteil den 1T der / SSD. Und ob man jetzt sich jetzt 3-4 python Pakete oder sonstige Abhängigkeiten spart, nur weil man hier oder da eine USE flag deaktiviert … macht eigentlich keinen großen Unterschied. Beim RAM ist es ähnlich. Ob ich jetzt cups (hier ca. 700 MB) auch noch installiere wird jetzt den Braten auch nicht fett machen.

Zu was also das System mit den USE flags führt ist, dass man irgendwelche Features gerade nicht aktiviert, gerne auch mal versehentlich, weil man einfach nicht wusste, dass das wirklich sinnvoll ist, und sich dann darüber ärget, dass irgendetwas nicht so funktioniert wie es sollte. Und ja, das ist mir schon häufiger passiert (auch mit Exherbo).
Bei Gentoo kommt noch dazu, dass die Beschreibungen der USE flags typischerweise global gesetzt werden. Das ist aber ein ziemlich schlechtes System. Als Beispiel nimm z.B. die USE flag "X".
Da steht dann als Beschreibung (ohne es nachgeschaut zu haben) wahrscheinlich sowas drin wie "Support for the X Window System", was aber halt mindestens ungenau, manchmal sogar falsch ist.
Tatsächlich macht die USE flag bei unterschiedlichen Paketen auch ganz unterschiedliche Dinge. Mal fügt es einfach eine GUI hinzu (die aber ggf. auch unter Wayland funktionieren würde), mal nutzt es wirklich xorg libraries. Mal baut es eine Library genau für solche Zwecke und an anderen Stellen fügt es evtl. irgendwelchen Support für irgendwelche X Protokolle hinzu. Ähnliche Probleme gibt es bei anderen USE flags auch.
Bei Exherbo habe ich mich daher immer sehr stark dafür eingesetzt, dass die Beschreibungen möglichst häufig lokal in den Paketen definiert werden, d.h. dann spezifisch für dieses Paket sind.

Wie auch immer, ich sehe aus diesen Gründen das USE flag System von Gentoo (und auch das OPTION System von Exherbo) nicht wirklich als großen Vorteil, sondern teilweise sogar eher als Nachteil an. In jedem Fall würde ich nicht empfehlen aus dem Grund eine Dsitribution zu nutzen.
Und generell würde ich an der Stelle weder Gentoo noch Exherbo empfehlen.
Ich habe das damals angefangen, weil ich einfach eine Art Basteldrang entwickelt habe und dafür ist das auch ok. Mittlerweile kenn ich das ganze System so in- und auswendig, dass es für mich recht wenig Mühe ist das noch weiter zu nutzen. Wenn ich aber dieses Wissen nicht hätte und mich jetzt entscheiden müsste, dann würde ich da sicher nicht einsteigen, man kann seine Zeit wirklich sinnvoller investieren.

Edit: sorry für den Mega Drop hier …

[Berniyh]

Flatpak wäre halt für "die ein, zwei Anwendungen, die anders nicht gehen".
Ubuntu ist auch abseits der LTS-Versionen ein Stück weit davon entfernt, aktuell zu sein. Generell gefällt mir die Richtung, in die Ubuntu geht, nicht so gut in den letzten Jahren: Klar ist das bequem, den Browser nach Snap zu verschieben aber gerade da nerven Overhead und Startzeiten. Für aktuelle Treiber braucht man ein inoffizielles RPM, was beim Umstieg auf ein Beta-Release dann natürlich unauflösbare Abhängigkeiten haben kann.
Snap ist vor allem auch als Paketverwaltung unglaublich laaaaaaaaahm.
Ich wurde vor kurzem gezwungen das zu nutzen, weil ich auf meinem Smartphone /e/ OS in einer neueren Version installieren musste und das mit dem Installer, der halt per snap ausgeliefert wird, halt doch etwas schneller geht als mit adb.
Es ist schon schockierend, aber die Installation von /e/ OS ging wesentlich schneller als die Installation und (spätere) Deinstallation des Installers mit snap. Das war wirklich ein Armutszeugnis …

Fedora ist tatsächlich super aktuell und manchmal frag ich mich, warum die Releases machen. Da kommen neue Major-Versionen von Kernels, Anwendungen - wenn ich das richtig mitbekomme, sind die nicht einmal immer stable.
Mit Fedora habe ich aber wesentlich häufiger die Erfahrung gemacht, dass verbuggte Pakete beim Nutzer ankommen, als z.B. mit Arch. Obwohl ja Arch auch relativ aktuell ist.
Generell sind meine Erfahrungen mit Fedora in den letzten ca. 5 Jahren auch echt nicht sonderlich positiv. Ich bin wirklich froh, wenn ich das wieder losgeworden bin … (hoffentlich bald)

[Shink]

Okay, dann hau ich einmal meine persönlichen Erfahrungen raus.
Mein Vorgehen ist: Ich habe einen PC und irgendwas, was nicht so einfach funktioniert, also installiere ich ein paar Distros und schau, wie kompliziert es ist, das laufen zu lassen.

ThinkPad E595 mit Ubuntu 22.10. Damit läuft z.B. mein Farblaser out-of-box perfekt. Ansonsten kann Ubuntu Dinge wie "Kernel-Update ohne Reboot" oder DRM out-of-box.
Für binäre Treiber und Anwendungen ist man mit Ubuntu meist auf der sicheren Seite. Da Microsoft Intune zur Zeit nur Ubuntu unterstützt, nehme ich an, in der Firma werde ich auch über kurz oder lang von Windows auf Ubuntu wechseln.
Ansonsten... mag ich es nicht mehr halb so gerne wie vor 10 Jahren noch, als es mein primäres System würde. Hauptgrund ist sicher Snap.

Alter HP-Schinken mit AMD E350 und 4GB Ram: Lubuntu LTS. Nach Enttäuschung über die Performance hab ich Snapd runtergeschmissen, was perfekt funktioniert hat. Ubuntu wie früher. Ich bin sogar von LTS 20.04 auf 22.04 gekommen ohne dass Ubuntu Snap nachinstalliert hätte. Das Laptop ist allemal schnell genug für Stardew Valley, Diablo 2 über Wine oder 0ad.

"Gaming-System": Soundkarte, Grafikkarte, Gamepad. Für Diablo Resurrected und andere AAA-Games habe ich mit Fedora am wenigsten Probleme. Grafiktreiber, Wine, Kernel und GCC sind immer up-to-date und mit rpmfusion hat man viel Software zur Auswahl.
Redhat ist eine Firma, die Linux zu Geld macht aber ich würde nicht behaupten, die geben nichts zurück. Welche Softwarefirma macht schon mehr an Kernel als Redhat?

Und schließlich hab ich noch dieses Steamdeck mit SteamOS auf Arch-Basis. Für mich ein gutes Zeichen, dass Arch für diesen Einsatzzweck eine gute Wahl wird/bleibt.

[Berniyh]

Welche Softwarefirma macht schon mehr an Kernel als Redhat?
Typischerweise Intel, Google, AMD und Linaro. Je nach Version auch gerne mal noch Meta (Facebook).
Wobei AMD ein bisschen runter- und Red Hat ein bisschen hochrutscht, wenn man nicht nach lines changed geht, sondern Anzahl der Commits.
Für beide Varianten gibt es Argumente.

[Shink]

Ich bin so unglaublich altmodisch, dass ich mich weigere, Intel und AMD als Softwarefirma zu sehen.

[Ganon]

Auch wenn es nur zum Teil zum Thema passt:

Ich persönlich benutze Arch+Flatpak auch mit ein paar selbstgebauten Flatpaks, die ein Großteil des AUR ersetzen. Flatpak selbst ist in der Runtime soweit "Rolling-Release" solange es in den Bibliotheken der Runtime keine ABI-Breaks gibt. Weil dann werden sie eingefroren. Anwendungen selbst sind Rolling-Release. Ansonsten kommt jedes Jahr eine neue Runtime raus. Die hat dann mehr oder weniger Bibliotheken direkt enthalten, ggf. auch mehr oder weniger unterstützte CPU Architekturen, etc. pp.

Flatpak hat hier mehrere Gründe. Zum Einen brauche ich mein Host-System nicht mehr mit einer Tonne Bibliotheken zumüllen (GTK2, Qt5 & 6, lib32-*, ...) nur um ein Programm benutzen zu können, zum Anderen haben die Teils mit Spyware versehenen Spiele von Steam und auch Steam selbst kein Zugriff auf mein Host-System.

Das Argument, dass man einige Bibliotheken dann vielleicht mehrfach installiert hat, stimmt sicherlich, auf der anderen Seite patched z.B. GIMP in ihrem Flatpak bestimmte GTK2-Bugs die speziell mit ihrer Anwendung auftreten. Diese Patches fehlen natürlich ggf. wenn man einfach nur das Vanilla GTK2 installiert hat. Auch können Programme entsprechende Bibliotheken in speziellen Konfigurationen ausliefern, anstatt auf "One-Size-Fits-All" setzen zu müssen. Auch sind etwaige Sicherheitslücken in den Programmteilen nur lokal für das eine Programm und dann auch noch in einer Sandbox. Ein weiterer Vorteil ist, wenn mal ein Update einer Anwendung bei einem aus irgend einem Grund nicht funktioniert, kann man das ganz einfach zurückrollen und das Problem melden. Man steht erst mal nicht vor einem Scherbenhaufen.

Natürlich hat das Sandbox-System auch Nachteile, klar. z.B. die meisten Nutzer erwarten schlicht, dass eine Anwendung überall hin Zugriff hat und das gilt bei Flatpak nicht immer.

[Gast]

Flatpak hat hier mehrere Gründe. Zum Einen brauche ich mein Host-System nicht mehr mit einer Tonne Bibliotheken zumüllen (GTK2, Qt5 & 6, lib32-*, ...) nur um ein Programm benutzen zu können, zum Anderen haben die Teils mit Spyware versehenen Spiele von Steam und auch Steam selbst kein Zugriff auf mein Host-System.


Das sind berechtigte und sinnvolle Einsatzgebiete.

Ich habe gestern Fedora (KDE) installiert und dann auch per Flatpak Steam. Leider findet Steam wie auch andere Flatpaks keine Internetverbindung bzw. Netzwerkverbindung.
Ich habe noch keine Zeit gefunden für tiefere Recherche. Scheint aber allgemein nicht so eine ungewöhnlicher Fehler zu sein.
Hat jemand einen Tip?


Ich hatte vorher Manjaro drauf, weil das meist so gelobt wird.
Ich nutze seit 20 Jahren gelegentlich Linux. Und ich muss sagen, dass Manjaro die schlechte Distribution ist, die mir jemals untegekommen ist. Ich kann diesen Hype nicht verstehen. Warum ist Manjaro so schlecht und sollte man die Finger davon lassen: Manjaro verzört Sicherheitsupates um mehrere Tage. Das wird mit Systemstabilität begründet. Jo.... wenn O-Days darunter sind (z.B. im Brower), ist man tagelang angreifbar. So ein mieses Updateverhalten ist mir sonst bei keiner anderen bzw. seriösen Distribution aufgefallen.
Wenn Arch, dann bitte ein richtiges Arch bzw. Ableger, der nicht solchen Sicherheitswahnsinn betreibt.

[BBig]

...

Edit: sorry für den Mega Drop hier …

Holy Moly, Berniyh!
Du brauchst dich nicht entschuldigen für den "Drop", sondern ein Danke von mir!

Ich bezeichne mich als "langjähriger Linux-Noob"; Insides wie sowas hier, bekommt man nicht häufig mit.

~ ~ ~

- Das was du über Arch schreibst spiegelt genau meine Erfahrung wieder.
Das "stabile" Rolling macht Arch toll.
Und jeder Linux-User, der englisch kann, sollte, egal welche Distro er benutzt, als erstes in das Arch-Wiki schauen, wenn er Probleme oder Fragen hat.

Das AUR ist schon toll, nur sollte Leuten klar sein, was sie da installieren. Nicht ein Paket von Arch, sondern ein Arch-Paket von einem andern User!
Wenn man aber nicht blind alles mögliche installiert, ein wenig auf "Votes & Popularity" schaut, dann passt das schon.

In den 6 oder 8 Jahren bei denen nun bei mir Antergos -> dann auf Arch lief, musste ich vll 1x (oder 2x) chrooten. Und das auch nur, weil ich Mist gebaut hatte. :tongue:

Sonst sind mir nur Probleme mit den Keys (Einzeiler im Terminal) oder Lib-Changes bzw. "Versions-Unstimmigkeiten" im Gedächtnis geblieben, die dann aber in den News angesprochen werden. Und eben das AUR.

Vom Gefühl her hat M$ da mehr Probleme mit ihren buggy / zurückgezogenen KBs, die dann auch mal was löschen (Desktop und Userdaten!) oder einfach mal Hardware nicht mehr funktioniert, obwohl der Treiber installiert ist, :freak:

~ ~ ~

- "Kleine Distros" würde ich mit meinem Linux-Wissen auch nicht nehmen, aber Voidlinux ist schon lange dabei und ist mir in letzter Zeit häufig vorgekommen. Vom Gefühl her sind sie nicht klein. Kann natürlich täuschen.

Ich habe in die Paket-DB geschaut, da ist alles drin, was ich haben mag. Sogar mein Drucker-Treiber ist drin, sodass ich mich nicht darum selber kümmern müsste.

~ ~ ~

- systemd ist "schwierig". Auf der einen Seite glaube ich, dass Lennart Poettering dicke was auf dem Kasten hat; PulseAudio z.B. ist super und hat den Linux-Desktop weit nach vorne gebracht.
Ich kenne Zeiten vor systemd, und ja, systemd hat vieles einfacher gemacht.

Auf der anderen Seite, ist systemd genau das geworden, wovor viele / einige gewarnt haben. Eine Krake, die immer weiter wächst und nun so tief im System ist, dass es immer schwerer wird, Teile davon zu ersetzen.

Ich glaube, das "Do one thing and do it good." wirklich wert hat.
Wenn man sich anschaut, wie Software-Entwicklung gerade in FOSS voranschreitet, dann sieht man, dass es Vorteile hat, wenn man einzelne Dinge gegen dann - eventuell - bessere austauschen kann.
Freiheit und Flexibilität "leidet" unter systemd.

Wer möchte sich denn an das Mamut-Projekt setzten und einen Austausch für systemd schreiben? Wenn systemd nur eine Init wäre, dann wäre es ja gut. Aber schau dir mal an, was mittlerweile davon alles abhängt und wo systemd seine Fingern überall drin hat.

Als Linux-Noob finde ich das nicht gut, denke aber auch, dass ich zu wenig Kenne habe, das wirklich zu beurteilen. Dementsprechend sehe ich systemd weder als gut oder schlecht an, sondern nehme es so wie es ist.
Und ich glaube ich stimme dir zu, dass es zur Zeit keine Alternative gibt, nur wie gesagt, so wie systemd aufgebaut & ausgebaut ist, wird es auch immer schwerer eine Alternative zu entwickeln.

~ ~ ~

Zu Gentoo habe ich ein besonderes Verhältnis.
Ca. 2001 ( ja, dass ist lange her) habe ich im Keller eines Studiwohnheims Tage mit einem Freund verbracht, um es auf meinen Rechner zu bekommen.
Gerne erinnere ich mich daran zurück, aber es war mehr mein Freund ( ein wirklicher Nerd ), der Spaß daran hatte. Seit der Zeit hat mich Linux nie losgelassen.
Und ja, wir haben Gentoo damals auf meinem Intel Coppermine mit 1000 MHz zum laufen gebracht. :D

Ein paar Jahre später habe ich dann versucht Gentoo alleine auf meinen Rechner zu bringen, und ja, die Flags machen einen wahnsinnig, ;D

Gentoo würde ich auch nicht auf meinen PC aufspielen, da würde ich noch eher non-rolling Fedora nehmen.

Okay, dann hau ich einmal meine persönlichen Erfahrungen raus.
Mein Vorgehen ist: Ich habe einen PC und irgendwas, was nicht so einfach funktioniert, also installiere ich ein paar Distros und schau, wie kompliziert es ist, das laufen zu lassen.

ThinkPad E595 mit Ubuntu 22.10. Damit läuft z.B. mein Farblaser out-of-box perfekt. Ansonsten kann Ubuntu Dinge wie "Kernel-Update ohne Reboot" oder DRM out-of-box.
Für binäre Treiber und Anwendungen ist man mit Ubuntu meist auf der sicheren Seite. Da Microsoft Intune zur Zeit nur Ubuntu unterstützt, nehme ich an, in der Firma werde ich auch über kurz oder lang von Windows auf Ubuntu wechseln.
Ansonsten... mag ich es nicht mehr halb so gerne wie vor 10 Jahren noch, als es mein primäres System würde. Hauptgrund ist sicher Snap.

Alter HP-Schinken mit AMD E350 und 4GB Ram: Lubuntu LTS. Nach Enttäuschung über die Performance hab ich Snapd runtergeschmissen, was perfekt funktioniert hat. Ubuntu wie früher. Ich bin sogar von LTS 20.04 auf 22.04 gekommen ohne dass Ubuntu Snap nachinstalliert hätte. Das Laptop ist allemal schnell genug für Stardew Valley, Diablo 2 über Wine oder 0ad.

"Gaming-System": Soundkarte, Grafikkarte, Gamepad. Für Diablo Resurrected und andere AAA-Games habe ich mit Fedora am wenigsten Probleme. Grafiktreiber, Wine, Kernel und GCC sind immer up-to-date und mit rpmfusion hat man viel Software zur Auswahl.
Redhat ist eine Firma, die Linux zu Geld macht aber ich würde nicht behaupten, die geben nichts zurück. Welche Softwarefirma macht schon mehr an Kernel als Redhat?

Und schließlich hab ich noch dieses Steamdeck mit SteamOS auf Arch-Basis. Für mich ein gutes Zeichen, dass Arch für diesen Einsatzzweck eine gute Wahl wird/bleibt.

Du hast für dich für non-rolling Distros entschieden.

Unter Ubuntu scheinen ja die Distro-Upgrades besser zu funktionieren.
Unter Fedora auch schon probiert?

Das Steamdeck habe ich mir schon ein paar mal angeschaut,
die Hardware ist sexy, aber ich game einfach nicht mehr.

Auch wenn es nur zum Teil zum Thema passt:

Ich persönlich benutze Arch+Flatpak auch mit ein paar selbstgebauten Flatpaks, die ein Großteil des AUR ersetzen. Flatpak selbst ist in der Runtime soweit "Rolling-Release" solange es in den Bibliotheken der Runtime keine ABI-Breaks gibt. Weil dann werden sie eingefroren. Anwendungen selbst sind Rolling-Release. Ansonsten kommt jedes Jahr eine neue Runtime raus. Die hat dann mehr oder weniger Bibliotheken direkt enthalten, ggf. auch mehr oder weniger unterstützte CPU Architekturen, etc. pp.

Flatpak hat hier mehrere Gründe. Zum Einen brauche ich mein Host-System nicht mehr mit einer Tonne Bibliotheken zumüllen (GTK2, Qt5 & 6, lib32-*, ...) nur um ein Programm benutzen zu können, zum Anderen haben die Teils mit Spyware versehenen Spiele von Steam und auch Steam selbst kein Zugriff auf mein Host-System.

Das Argument, dass man einige Bibliotheken dann vielleicht mehrfach installiert hat, stimmt sicherlich, auf der anderen Seite patched z.B. GIMP in ihrem Flatpak bestimmte GTK2-Bugs die speziell mit ihrer Anwendung auftreten. Diese Patches fehlen natürlich ggf. wenn man einfach nur das Vanilla GTK2 installiert hat. Auch können Programme entsprechende Bibliotheken in speziellen Konfigurationen ausliefern, anstatt auf "One-Size-Fits-All" setzen zu müssen. Auch sind etwaige Sicherheitslücken in den Programmteilen nur lokal für das eine Programm und dann auch noch in einer Sandbox. Ein weiterer Vorteil ist, wenn mal ein Update einer Anwendung bei einem aus irgend einem Grund nicht funktioniert, kann man das ganz einfach zurückrollen und das Problem melden. Man steht erst mal nicht vor einem Scherbenhaufen.

Natürlich hat das Sandbox-System auch Nachteile, klar. z.B. die meisten Nutzer erwarten schlicht, dass eine Anwendung überall hin Zugriff hat und das gilt bei Flatpak nicht immer.

Arch & Flatpak, wow interessant.
Gerade wo dir doch das AUR zur Verfügung steht.

Was sagst du denn zu meiner Aussage: "Wenn es ums Thema Sicherheit & Updates geht, traue ich auch meiner Distro & Repo mehr als den "Stores und Hubs". Wahrscheinlich auch ein Vorurteil." - Bullshit oder ein Thema? Oder eher geringe Auswirkung, da gesandboxed?

Wie ist den die Performance von den "Universal Linux Packaging Formats"?
Merkt man, ob man gimp als snap oder flatpak startet?
Ich gehe mal davon aus, das es UI Probleme nicht mehr gibt.

[Ganon]

Arch & Flatpak, wow interessant.
Gerade wo dir doch das AUR zur Verfügung steht.

Flatpak ist aber einfacher und stabiler (im Sinne von Update-Stabilität) als das AUR. Auch muss ich mein Host-System nicht mit Build-Dependencies zumüllen bzw. mit chroots rumhantieren.

Was sagst du denn zu meiner Aussage: "Wenn es ums Thema Sicherheit & Updates geht, traue ich auch meiner Distro & Repo mehr als den "Stores und Hubs". Wahrscheinlich auch ein Vorurteil." - Bullshit oder ein Thema? Oder eher geringe Auswirkung, da gesandboxed?

Fast alle "Manifests" (~PKGBUILDS) liegen auf https://github.com/flathub/. Die kannst du dir selbst anschauen. Die Pakete baut auch nicht der Paketersteller manuell (anders als bei Arch), sondern ein Buildbot. Auch diesen kannst du einsehen: https://buildbot.flathub.org/ Pakete sind auch kein schlichter Datei-Download sondern über OSTree versionisiert (d.h. auch nachvollziehbar).

Du kannst via Github Issues & Pull-Requests sogar ganz einfach direkt mitwirken :) Als Paketersteller kann man sogar das Projekt so konfigurieren, dass die Programme + Abhängigkeiten automatisch aktualisiert und verteilt werden. Es gibt dafür einen Bot.

Aus dem Bauch heraus: Flathub ist sogar noch wesentlich transparenter als ArchLinux. Aber Arch arbeitet daran auf einen Buildbot umzustellen, ähnlich wie Flatpak.

Wie ist den die Performance von den "Universal Linux Packaging Formats"?
Merkt man, ob man gimp als snap oder flatpak startet?
Ich gehe mal davon aus, das es UI Probleme nicht mehr gibt.

Von Snap hab ich keine Ahnung. Ubuntukackscheiß interessiert mich nicht :D Ansonsten merke ich von der Performance her keinen Unterschied. Was in der Theorie langsamer sein könnte, wäre der allererste Start einer Flatpak Anwendung, da erst die grundlegende Runtime geladen werden muss. Aber auf meinem Notebook startet so gut wie alles in <1 Sekunde. Mal von LibreOffice und Electron-Anwendungen abgesehen.

Wenn du aber natürlich dein System natürlich hochgradig modden willst, dann wird das mit Flatpak schwieriger. Flatpak ist halt mehr ein System im System. Wie schon gesagt, das hat Vor- und Nachteile. Das Ganze erinnert stark an dem wie man Android-Anwendungen entwickelt.

Ich will persönlich auch gar nicht gegen die ArchLinux Pakete wettern oder so. Ich habe nichts gegen die ArchLinux Pakete und ich denke man sollte diese auch schlicht weiter erstellen. Alternativen sind wichtig. Für mich persönlich überwiegen aber gerade die Vorteile der Flatpaks, darum gehe ich gerade diesen Weg. Ich begrüße aber durchaus die Möglichkeit das alles wieder zu verwerfen und zu ArchLinux Paketen für die entsprechenden Anwendungen zurückzukehren.

[Shink]

Du hast für dich für non-rolling Distros entschieden.

Unter Ubuntu scheinen ja die Distro-Upgrades besser zu funktionieren.
Unter Fedora auch schon probiert?
Ich hatte ehrlich noch nie Probleme bei Distro-Upgrades, eher im Gegenteil.

[Berniyh]

Ich hatte ehrlich noch nie Probleme bei Distro-Upgrades, eher im Gegenteil.
Realistisch betrachtet funktioniert es ja auch bei der Mehrheit der Systeme, sonst wäre ja wirklich die Kacke am Dampfen.

Ich persönlich habe nicht so gute Erfahrungen gemacht und schreibe das durchaus auch Pech zu, aber mit Rolling Release entfällt es halt trotzdem.

[Berniyh]

Auf der anderen Seite, ist systemd genau das geworden, wovor viele / einige gewarnt haben. Eine Krake, die immer weiter wächst und nun so tief im System ist, dass es immer schwerer wird, Teile davon zu ersetzen.

Wer möchte sich denn an das Mamut-Projekt setzten und einen Austausch für systemd schreiben? Wenn systemd nur eine Init wäre, dann wäre es ja gut. Aber schau dir mal an, was mittlerweile davon alles abhängt und wo systemd seine Fingern überall drin hat.
Ne, das stimmt so nicht.
Was stimmt, ist dass alles in einem Paket ausgeliefert wird, aber die Funktionen sind fast alle separat voneinander und fast alles ist optional.
e.g. journal, network, resolve, coredump, oom-killer, loginctl etc. Nichts davon musst du nutzen und z.B. network und resolve werden bei vielen Distributionen auch nicht genutzt (sondern NetworkManager).
Ich glaube das einzige, was bei Nutzung von systemd nicht optional ist ist der udev Teil, aber das ist verschmerzbar, denke ich.
Die anderen Teile werden gerne genutzt, weil sie einfach gut funktionieren und nützlich sind, wie eben loginctl. Wenn man hier eine Alternative haben will, dann kann man aber die Schnittstellen einfach separat implementieren, die sind ja dokumentiert.
Und das wurde mit eudev ja auch gemacht.
Mein Punkt war ja auch nicht, dass es nicht geht, sondern dass die meisten eben die systemd Variante offensichtlich besser finden und darum das nutzen. eudev braucht es eben nur für die, die systemd verweigern und das ist eine kleine Minderheit. Entsprechend schlechter ist es dann eben getestet.
Aber das kann man ja schlecht systemd vorwerfen, finde ich.

Ich persönlich nutze von systemd auch die resolve, journal, network und timesync Tools. Da gibt es zwar auch andere Tools, aber z.B. Network Manager ist für meinen Fall (stationärer PC mit LAN Anbindung) schlicht Overkill und openntp (habe ich früher für timesync verwenden) hat bei mir nicht so zuverlässig funktioniert wie jetzt systemd. Mit openntp hatte ich ständig Drifts in der Zeit und musste manuell einen Komplettreset forcieren.
Die Tools von systemd sind halt einfach und funktional, ich arbeite gerne damit, aber wer will kann sich auch heute noch mit rsyslog, openntp, dhcpcd etc. rumschlagen, rein von der Unterstützung her ist das kein Thema.
Ich glaube, das "Do one thing and do it good." wirklich wert hat.
Siehst du, das war immer eines der wesentlichen Argumente der systemd Gegner und es war eines der Argumente an denen man erkennen konnte, dass sie teilweise einfach Null Ahnung haben wovon sie reden.
Wie schon erwähnt ist systemd nicht eine Binary in der alles drin steckt, sondern es ist eine Sammlung von Tools, von denen eben jedes einen Zweck erfüllt und – meiner Erfahrung nach – meistens auch recht gut. Man könnte also behaupten, dass sie das Kriterium erfüllen.
journald und journalctl haben z.B. genau eine Aufgabe, nämlich logs aufzuzeichen bzw. auszulesen. Und diese Aufgabe erfüllen sie – meiner Meinung nach – deutlich besser als z.B. die alte Variante mit den Textdateien.
Sowas wie z.B.
journalctl -b -1 -k --priority=3
(Alle Kernel Meldungen (=dmesg) mit Priorität 3 und höher (d.h. Fehler) der vorherigen Uptime.)
Oder recht simpel nach einzelnen Programmen filtern:
journalctl -b 0 -t plasmashell
Zeigt alle Meldungen von plasmashell an.
Ich kann mir anzeigen lassen welche Boots es in den Logs gibt und wann die anfangen:
journalctl --list-boots
uvm.
All das hat das journal massiv vereinfacht. Wer will kann es ja auch parallel zu klassischen Textlogs nutzen (warum auch immer man das wollen sollte …).

Auf der anderen Seite muss man aber auch fragen: Was war denn diese eine Sache, die SysVInit gut konnte?
Mir fällt da ehrlich gesagt nichts ein, ich fand dieses System schon immer, seit ich es genutzt habe (ca. 1999/2000) grauenvoll.
OpenRC kann man zumindest zugute halten, dass es ebenfalls deklarative Configs unterstützen soll, wenngleich ich selbst diese nie verwendet habe. Dennoch wäre das schon ein signifikanter Vorteil gegenüber SysVInit.
Ansonsten sehe ich als einzigen Vorteil von OpenRC, dass man es auch auf anderen Kernel (z.B. BSD-artig oder HURD) nutzen kann, aber da mich das persönlich nicht sonderlich interessiert …

[Benutzername]

Typischerweise Intel, Google, AMD und Linaro. Je nach Version auch gerne mal noch Meta (Facebook).
Wobei AMD ein bisschen runter- und Red Hat ein bisschen hochrutscht, wenn man nicht nach lines changed geht, sondern Anzahl der Commits.
Für beide Varianten gibt es Argumente.

Microsoft nicht vergessen. Auch ein großer Beiträger mittlerweile. Amazon trägt auch viel bei. Sitzen auch zusammen mit Alphabet und Meta und Co in den Gremien.Wobei die großen Techkonzerne in den Gremien finde ich nicht so gut. Die wollen halt Konkurrenz rausmobben und andere Konzerndinge tun statt einfach gute TEchnik zu entwickeln.

---------

Ich bin so unglaublich altmodisch, dass ich mich weigere, Intel und AMD als Softwarefirma zu sehen.

Verständlich, aber die machen auch viel Software tatsächlich.

[Ganon]

Microsoft nicht vergessen. Auch ein großer Beiträger mittlerweile

Das stimmt nicht. Microsoft war nur einmal kurz ein Top-Contributor als sie ihren ganzen Hyper-V Kram in den Kern commited haben. Ansonsten sind ihre Beiträge am Linux-Kernel eher zu vernachlässigen und schon gar nicht regelmäßig.

https://www.linaro.org/blog/linaro-developers-top-5-12-kernel-release/
https://www.linaro.org/blog/linaro-developers-make-an-impact-in-linux-kernel-5-13-release/
https://www.linaro.org/blog/linaro-contributions-to-the-5-18-linux-kernel-release/
https://www.linaro.org/blog/linaro-in-top-five-for-most-active-contributors-to-the-6-0-linux-kernel-release/

[Berniyh]

Microsoft nicht vergessen. Auch ein großer Beiträger mittlerweile. Amazon trägt auch viel bei. Sitzen auch zusammen mit Alphabet und Meta und Co in den Gremien.Wobei die großen Techkonzerne in den Gremien finde ich nicht so gut. Die wollen halt Konkurrenz rausmobben und andere Konzerndinge tun statt einfach gute TEchnik zu entwickeln.
Nö, hab ich nicht vergessen. Ich hab mir die Stats der letzten 10 Kernels angeschaut und da taucht Microsoft nur hin und wieder mal in den Top 10 auf nicht sonderlich weit oben. Amazon weiß ich gerade nicht mehr, aber eher seltener als Microsoft.

Eher hätte ich noch andere Konzerne erwähnen können. Samsung z.B. hatte glaube ich in der einen oder anderen Version recht viele Beiträge.

Wie auch immer. Intel und AMD sind halt echt bei fast jeder Kernel Version in den Top 3. AMD hat ja auch mit amdgpu mit Abstand den größten Treiber im Kernel.

[BBig]

Ne, das stimmt so nicht.
Was stimmt, ist dass alles in einem Paket ausgeliefert wird, aber die Funktionen sind fast alle separat voneinander und fast alles ist optional.
e.g. journal, network, resolve, coredump, oom-killer, loginctl etc. Nichts davon musst du nutzen und z.B. network und resolve werden bei vielen Distributionen auch nicht genutzt (sondern NetworkManager).
Ich glaube das einzige, was bei Nutzung von systemd nicht optional ist ist der udev Teil, aber das ist verschmerzbar, denke ich.
Die anderen Teile werden gerne genutzt, weil sie einfach gut funktionieren und nützlich sind, wie eben loginctl. Wenn man hier eine Alternative haben will, dann kann man aber die Schnittstellen einfach separat implementieren, die sind ja dokumentiert.
Und das wurde mit eudev ja auch gemacht.
Mein Punkt war ja auch nicht, dass es nicht geht, sondern dass die meisten eben die systemd Variante offensichtlich besser finden und darum das nutzen. eudev braucht es eben nur für die, die systemd verweigern und das ist eine kleine Minderheit. Entsprechend schlechter ist es dann eben getestet.
Aber das kann man ja schlecht systemd vorwerfen, finde ich.

Ich persönlich nutze von systemd auch die resolve, journal, network und timesync Tools. Da gibt es zwar auch andere Tools, aber z.B. Network Manager ist für meinen Fall (stationärer PC mit LAN Anbindung) schlicht Overkill und openntp (habe ich früher für timesync verwenden) hat bei mir nicht so zuverlässig funktioniert wie jetzt systemd. Mit openntp hatte ich ständig Drifts in der Zeit und musste manuell einen Komplettreset forcieren.
Die Tools von systemd sind halt einfach und funktional, ich arbeite gerne damit, aber wer will kann sich auch heute noch mit rsyslog, openntp, dhcpcd etc. rumschlagen, rein von der Unterstützung her ist das kein Thema.

Ok, dass wusste ich nicht. Ich benutzte was da ist, und um ehrlich zu sein, davor hatte ich Upstart und runit, kann mich nicht an Probleme erinnern.
Allerdings beschränken sich meine Erfahrungen hauptsächlich mit Services starten oder enablen.

Kenne nur die Argumentation "der Gegenseite", und wenn man dann noch von den vielen "Addons" ließt, dann verstärkt sich das Gefühl.

Siehst du, das war immer eines der wesentlichen Argumente der systemd Gegner und es war eines der Argumente an denen man erkennen konnte, dass sie teilweise einfach Null Ahnung haben wovon sie reden.
Wie schon erwähnt ist systemd nicht eine Binary in der alles drin steckt, sondern es ist eine Sammlung von Tools, von denen eben jedes einen Zweck erfüllt und – meiner Erfahrung nach – meistens auch recht gut. Man könnte also behaupten, dass sie das Kriterium erfüllen.
journald und journalctl haben z.B. genau eine Aufgabe, nämlich logs aufzuzeichen bzw. auszulesen. Und diese Aufgabe erfüllen sie – meiner Meinung nach – deutlich besser als z.B. die alte Variante mit den Textdateien.
Sowas wie z.B.
journalctl -b -1 -k --priority=3
(Alle Kernel Meldungen (=dmesg) mit Priorität 3 und höher (d.h. Fehler) der vorherigen Uptime.)
Oder recht simpel nach einzelnen Programmen filtern:
journalctl -b 0 -t plasmashell
Zeigt alle Meldungen von plasmashell an.
Ich kann mir anzeigen lassen welche Boots es in den Logs gibt und wann die anfangen:
journalctl --list-boots
uvm.
All das hat das journal massiv vereinfacht. Wer will kann es ja auch parallel zu klassischen Textlogs nutzen (warum auch immer man das wollen sollte …).

Auf der anderen Seite muss man aber auch fragen: Was war denn diese eine Sache, die SysVInit gut konnte?
Mir fällt da ehrlich gesagt nichts ein, ich fand dieses System schon immer, seit ich es genutzt habe (ca. 1999/2000) grauenvoll.
OpenRC kann man zumindest zugute halten, dass es ebenfalls deklarative Configs unterstützen soll, wenngleich ich selbst diese nie verwendet habe. Dennoch wäre das schon ein signifikanter Vorteil gegenüber SysVInit.
Ansonsten sehe ich als einzigen Vorteil von OpenRC, dass man es auch auf anderen Kernel (z.B. BSD-artig oder HURD) nutzen kann, aber da mich das persönlich nicht sonderlich interessiert …

Glaube ich dir, aber eine Sache verstehe ich dann grundsätzlich nicht.
Wahrscheinlich gibt es dazu auch einen guten Grund, aber warum die logs im binary format ablegen?

Text-Dateien kann ich super bearbeiten / sortieren / greppen ... was auch immer.
Will ich auf einen log von systemd zugreifen, muss ich systemd laufen haben und dass dann pipen ...
Einige erzählen dann was von Platz sparen, was für mich wenig Sinn ergibt. Text-Dateien lassen sich super komprimieren und Platz haben wir heute auch mehr als früher.

~~~

Wenn ich mal die Distros von den paar Meldung im Forum zusammenfasse:

3x Arch (zähle mich noch dazu)
1x Mint (xfce)
1x Void (glibc)
1x Ubuntu
1x Fedora

Hätte ich was raten sollen, hätte ich gedacht, dass mindestens 1x OpenSuse vorkommt und insgesamt mehr Ubuntu & Derivate.
Haben ja auch nicht viele geantwortet; auf so was Allgemeines hat ja auch nicht jeder Block drauf.

[Berniyh]

Ok, dass wusste ich nicht. Ich benutzte was da ist, und um ehrlich zu sein, davor hatte ich Upstart und runit, kann mich nicht an Probleme erinnern.
Allerdings beschränken sich meine Erfahrungen hauptsächlich mit Services starten oder enablen.
Services starten oder zum Runlevel hinzufügen ging auch mit SysVInit, das war jetzt nicht das Problem.
Die Probleme fingen hauptsächlich dann an, als die Computerwelt dynamischer wurden, d.h. Devices per Hotplug dazu kommen.
In den 00er Jahren sind da für Linux erste Lösungen gekommen und keine hat so wirklich toll funktioniert. (HAL, coldplug und was weiß ich noch alles)
Insbesondere, wenn "auf Zuruf" ein Service gestartet werden sollte.
Gerade sowas wie Bluetooth. Wenn du das aktivierst oder einen Dongle anschließt, dann willst du, dass das auch funktioniert und zwar ohne, dass du erst den Bluetooth Service startest.
Umgekehrt willst du aber evtl. auch nicht, dass es permanent läuft und genau solche Dinge hat systemd deutlich verbessert.
Auch Upstart hat sich genau solcher Dinge angenommen, eben indem es nicht mehr Zustands-basiert war, sondern Event-basiert.
Glaube ich dir, aber eine Sache verstehe ich dann grundsätzlich nicht.
Wahrscheinlich gibt es dazu auch einen guten Grund, aber warum die logs im binary format ablegen?

Text-Dateien kann ich super bearbeiten / sortieren / greppen ... was auch immer.
Will ich auf einen log von systemd zugreifen, muss ich systemd laufen haben und dass dann pipen ...
Einige erzählen dann was von Platz sparen, was für mich wenig Sinn ergibt. Text-Dateien lassen sich super komprimieren und Platz haben wir heute auch mehr als früher.
Platz sparen glaube ich eher nicht. Hab da jetzt keine Vergleiche gemacht, aber komprimierte Logs waren schon seit Jahrzehnten Standard.
Übrigens sind komprimierte Textdateien genau genommen auch Binärdateien.

Textdateien haben letztendlich einen Vorteil: die Daten sind – mittels Texteditor – für Menschen gut lesbar. (Wenn das Textformat darin passt.)
Das war es aber auch, ansonsten haben Textdateien eigentlich nur Vorteile.

Als Wissenschaftler muss ich recht häufig mit Textdateien arbeiten, weil Ergebnisse oder Messungen typischerweise in so einem Format abgelegt sind und daher kann ich dir sagen, dass das erste, was du damit machst ist, die Textdatei zu parsen und in ein Format importieren, mit dem du da vernünftig arbeiten kannst. Also z.B. Filtern oder irgendwelche Funktionen anwenden, Plotten oder was auch immer.
Die Nutzung von Textdateien ist da aber immer aus der Not heraus geboten, da es einfach keine allgemein verwendbaren Formate gibt, die sich anbieten und durchgesetzt hätten.¹
Dafür hast du aber gewissen Nachteile, denn die Notwendigkeit des Parsens birgt auch immer das Risiko, dass du Fehler beim Importieren machst, sei es, weil im "Text" irgendwo ein Formatfehler ist oder du das Textformat leicht falsch interpretierst. Dazu kommt, dass du beim Textformat auch gewisse Beschränkungen hast, z.B. die Präzision von Zahlen. (Und ja, das ist mir auch schon auf die Füße gefallen …)

Bei den Logdateien ist es letztendlich genauso. Logs sind letztendlich erstmal eine Datenbank von Informationen über den vergangenen Systemzustand. Das kann man in Textform packen, allerdings ist Textform einfach eine sehr schlechte Datenbank. Ok zum Lesen, aber schlecht um damit später noch irgendetwas anzufangen.
Alleine, wenn du Einträge zwischen Datum X und Y haben willst, dann musst du erst alles parsen (mit dem Risiko auf Fehler), in ein verarbeitbares Format bringen und dann durchsuchen. Warum also nicht gleich in einem besseren Format abspeichern?
Daraus sich wieder eine Textform ausgeben zu lassen ist wesentlich trivialer als der umgekehrte Weg.
Ob man für diese Journal Datenbank nun ein eigenes Format definieren musste oder evtl. auch irgendeine Form von SQL o.ä. hätte nehmen können ist natürlich wieder eine Frage, aber damit kenne ich mich mit den Formaten nicht gut genug aus.

Die Nutzung eines echten Datenbankformats hat dann auch noch den Vorteil, dass man Dinge implementieren kann, die bei Textdateien nicht, oder nur recht umständlich, möglich sind. Wie z.B. die Integrität der Datenbank und ihrer Einträge sicherzustellen, um zum Beispiel gegen Manipulation zu schützen.

Und eben, dass es viel einfacher ist gezielt Informationen herauszufiltern.
Ich kann dir hier nur nahelegen, lieber mal 5min Zeit zu investieren wie man journalctl nutzt statt grep darauf anzuwenden. Die Treffsicherheit wird sich dazu erhöhen. Ein paar Beispiele sind auch in der Manpage von journalctl angegeben.
Mit einer vernünftigen Shell wie zsh hat man zudem den Vorteil der mächtigen completion, welche die Parameterfindung auch immens vereinfacht.²

Es gibt noch ein paar weitere Dinge, welche journalctl massiv verbessert hat.
Eins ist z.B., dass nun auch die user-logs im journal landen. Früher würde das alles nach .xsession-errors und ggf. auch noch ein paar andere Logdateien geworfen und es war ein heilloses Durcheinander. Da irgendwelche relevanten Informationen zu finden war furchtbar. Speziell die .xsession-errors war immer vollgemüllt mit allerlei uninteressantem Quark und das zu greppen war echt grauenvoll.
Heutzutage loggen fast alle Programme ins journal und man kann die gleichen guten Tools auch hier anwenden.
In die System Logs zu schreiben wäre evtl. auch früher schon möglich gewesen, allerdings hätte ich als normaler Nutzer (ohne Admin Rechte) keine Möglichkeit gehabt auf meine Logs zuzugreifen und genau diese Schnittstelle hat journalctl geschaffen, mittels journalctl --user.
Auch das wäre mittels Textdateien nicht unmöglich, aber nur umständlicher umzusetzen und ganz sicher nicht ohne ein Tool dazwischen, das die Logs einliest und nur den Teil an den Nutzer ausgibt, auf welchen er auch zugreifen darf.

Und als weiteren Vorteil bietet sich durch das Journal jetzt auch besser die Möglichkeit für die Desktopumgebungen das besser in ihre Tools einzubinden.
bzw. überhaupt bessere Tools dafür zu schreiben. Siehe z.B. kjournald:
https://invent.kde.org/system/kjournald

Ist noch arg unausgereift (die UI ist etwas naja …), aber es zeigt, in welche Richtung es gehen könnte und mit etwas Polishing wird das evtl. ein richtig gutes Tool.
Jedenfalls wird es zukünftig solche Tools geben. Für KDE, aber auch andere DEs. Schlicht, weil die programmatische Abfrage von Informationen mit journald einfacher geworden ist als bei den früheren Textdateien.

Und wer unbedingt weiter grep verwenden will, der jagt das halt durch ne Pipe. So what?

¹ Das stimmt so nicht ganz, es gibt z.B. HDF5, aber das wird nur sporadisch verwendet und ist auch nicht ganz leicht in der Handhabung.

²zu zsh, siehe z.B. das hier:
https://www.youtube.com/watch?v=eLEo4OQ-cuQ

[BBig]

Meine neue Hardware ist da und macht nur Probleme.
Bis ich mal raus hatte, dass einer der beiden RAM-Riegel tot war, ;D

(Plus Mindfactory hat das Case in seiner orginalen Umverpackung geschickt, und die Post hat damit Fussball gespielt. Mindfactory ist wirklich preiswert, aber der Support ist zum brechen.)

===

...
Und wer unbedingt weiter grep verwenden will, der jagt das halt durch ne Pipe. So what?
...
Klar glaube ich, dass man sich dabei was gedacht hat, aber was macht man denn, wenn man ein System hat, was sich nicht booten lässt? Dann brauche ich eine Distro, die systemd hat, sonst kann man die Logs nicht lesen, oder?

===

Meine neue Hardware bootet, ich habe mir dann doch mal ein paar andere Distros auch auf Grund von lumines - auch nicht-rolling - angeschaut.

Ich war wirklich lange mit Openbox unterwegs und mag die Einfachheit / Usability. Wahrscheinlich auch, weil ich es super gut kenne.

Auf meinem alten Laptop lief sehr lange CrunchBang (https://distrowatch.com/table.php?distribution=CrunchBang) der Quasi-Nachfolger:
- BunsenLabs (https://www.bunsenlabs.org/)
Die hatten gerade ein neues Release auf Debian 11: Beryllium - Released on December 19th, 2022 (https://www.bunsenlabs.org/installation.html)

Wer Debian stable, dark theming & Openbox mag, macht hier nichts falsch.
Weihnachten und Neujahr habe ich Zeit, dann landet es auf mein Laptop, für den Desktop mag ich dann doch Rolling.

~

Beim Desktop bleibe ich bei Arch, ich habe mir Endeavouros (https://endeavouros.com/) angeschaut. Das default theming ist nicht meins, das wäre aber kein Problem.
Nur, wenn mir das Theming sowieso nicht zusagt, kann ich auch Arch installieren.
Und wenn schon ein neuer Desktop nach all den Jahren, dann wird es wahrscheinlich KDE.

Hat jemand KDE mit Bismuth (https://github.com/Bismuth-Forge/bismuth) laufen?
Funktioniert das gut?

Wünsche euch ein frohes Fest.

[Ganon]

Dann brauche ich eine Distro, die systemd hat, sonst kann man die Logs nicht lesen, oder?

Ja. Es hindert dich aber auch keiner daran neben journald noch irgend ein syslogd dazu zu hängen, der das dann in normale Textdateien schreibt. Journald erlaubt die Weiterleitung an einen anderen Logging-Dienst. Es ist halt nur nicht Standardeinstellung (unter ArchLinux).

Aber ich sag mal so... wenn mein ArchLinux-System kaputt geht, dann werde ich vermutlich nicht Alpine nehmen um es zu debuggen. Da nehme ich auch einfach wieder ArchLinux. Von daher halte ich das Problem eher für ein Scheinproblem.

[Berniyh]

Klar glaube ich, dass man sich dabei was gedacht hat, aber was macht man denn, wenn man ein System hat, was sich nicht booten lässt? Dann brauche ich eine Distro, die systemd hat, sonst kann man die Logs nicht lesen, oder?
Das stimmt, wobei ich da jetzt nicht so das Problem sehe. Gibt ja genügend Distributionen, die systemd mitbringen. Es muss ja auch nicht unbedingt die gleiche sein, das Format ist überall das gleiche.
Prinzipiell könnte man auch einen standalone Reader dafür erstellen, das Format ist ja offen und dokumentiert.
Wüsste aber nicht, dass das jemand umgesetzt hat.
Hat jemand KDE mit Bismuth (https://github.com/Bismuth-Forge/bismuth) laufen?
Funktioniert das gut?
Ne, tatsächlich nicht.

Es gab aber vor kurzem einen Blogpost zu dem Thema tiling in kwin:
https://notmart.org/blog/2022/10/kwin-and-tiling/

Die Verbesserungen sollen in Plasma 5.27 drin sein, genauso wie die Verbesserungen bzgl. multi screen, die wirklich mehr als überfällig waren.
https://notmart.org/blog/2022/12/multi-screen/
Evtl. genügt dir kwin mit den Verbesserungen ja auch so, ansonsten kannst ja Bismuth zusätzlich noch ausprobieren.

Edit: übrigens bekomme ich die Krise, wenn ich sehe, wie er das Fenster am Fensterrand vergrößert. Das ist so ein hakeliges Interface und so dermaßen Windows …
Es gibt in KDE die Funktion das gleiche zu erreichen, in dem man Mod+Rechte Maustaste nutzt, wobei Mod hier die Meta/Windows oder Alt Taste sein kann, je nach Einstellung.
Das ist soooooooooo viel besser in der Bedienung, da man nicht pixelgenau irgendwas treffen kann, sondern halt nur im richtigen Quadranten des Fensters sein muss.
Mod+Linke Maustauste verschiebt entsprechend, auch sehr praktisch.
Das sind mit die wesentlichsten Funktionen, die ich unter Windows regelmäßig vermisse …
Wünsche euch ein frohes Fest.
Danke, ebenso. :)

[raffa]

Auf dem Laptop Vanilla Arch, auf dem Desktop seit 2 Monaten EndeavourOS -

is halt Arch, easy installiert vom Live-Iso und gut vorkonfiguriert. Biste halt ruck-zuck "fertig" und die Themes, naja, die können weg :)

Ich benutze KDE Plasma (wayland), ohne Zusätze wie Bismuth

Bin recht zufrieden

[Berniyh]

Ich habe Bismuth mal für einen Tag ausprobiert, mit kwin 5.26.
Hat recht gut funktioniert, hatte keine Probleme. Bevorzugt habe ich das "Stacked" Layout, d.h. ein größeres Fenster und die restlichen werden rechts übereinander gestapelt.
Für Leute mit einem einzelnen großen Bildschirm ist das glaube ich ganz nett.
Für mich als Nutzer von zwei eher kleinen 24" Bildschirmen ist die klassische Variante aber glaube ich besser. Man muss halt bedenken, dass man mit einem Tiling Compositor seine Fenster nicht mehr frei verschieben kann, sondern sie immer auf einem der vorgefertigten Plätze landen. Die kann man natürlich in der Größe anpassen, dennoch ist es glaube ich aus dem Grund eher nicht so mein Ding.

Ich denke mit der nächsten Plasma Version könnte es eher etwas für mich werden, da man hier dann besser zwischen Tiling und freier Fensterplatzierung wechseln kann.

[Masterp]

Nutzt hier jemand Zorin ? https://zorin.com/