andy_m4 schrieb:
Und dann gibts natürlich auch noch den Fortschritt um des Fortschritts willen, wo zwar etwas anders gemacht wird und von mir aus punktuell sogar besser aber man letztlich nur alte Probleme gegen Neue tauscht.
Ich bastle auch ständig an meinen Systemen: Einerseits bin ich in solchen Sachen etwas perfektionistisch und will es bestmöglich haben, andererseits aber auch, weil ich so auf neue Ideen und Ansatzpunkte komme, die dann zu wirklichen Verbesserungen führen. - Besonders durch meinen Vater habe ich gelernt vieles zu hinterfragen und anders zu sehen, da er oft Probleme mit für mich schon lange Selbstverständliches hatte: Statt "das ist eben so", überlege ich jetzt eher "muss das wirklich so sein".
Z. B. den Doppelklick: Wie oft wird der nicht angenommen, weil die Maus währenddessen leicht verrutscht (besonders bei meinem Vater)? - Also wozu überhaupt einen Doppelklick? In Menüs, Schnellstart, Links im Browser und vor allen bei Handys und Tablets wird alles mit einem Klick/Tipp gestartet/geöffnet, wieso muss also auf dem PC-Desktop da unbedingt ein Doppelklick dazu nötig sein?
Nachdem ich das bei Linux und Windows abgeschaltet habe, kann ich *) damit viel flüssiger arbeiten. - Bei Solus hat das übrigens auch jemand erkannt, da es inzwischen standardmäßig keinen Doppelklick mehr nutzt.
*) nach erstaunlich kurzer Eingewöhnung, da ich es ja von Handy, Tablet, Menüs, Browser, usw. schon lange gewohnt war
Wie? Ich denke Stillstand ist Rückschritt? :-)
Ein weiser Mann hat mal gesagt: "Wobei es auch Dinge gibt die ausentwickelt sind und wo zumindest kaum noch was hinzu kommt." ;-)
Ein Init-System sollte nur ein Init-System sein: Praktisch die Tür zum OS.
Eine Tür öffne ich vorzugsweise mit einem einfachen, seit Jahrhunderten bewährten Türdrücker und nicht mit einem verschnörkelten, mit haufenweise unnützen Firlefanz behängten und kaum noch handhabbaren Mode-Accessoire.
Klar, Otto Normalo bekommt davon nichts mit, Hauptsache das BS bootet, aber wenn ich z. B. das regelmäßige trimmen nicht mehr per "mv /etc/cron.weekly/fstrim /etc/cron.daily" von wöchentlich auf täglich ändern kann, sondern sogar Google brauche, um herauszufinden, ob überhaupt noch getrimmt wird und das dann aufwändig in einer tief im System versteckten Textdatei ändern muss, hört es für mich auf. - Das war bei LinuxMint 18.3->19.
Übrigens: Als ich mich mit Solus beschäftigt habe, wollte ich das auf die für LM 19 ermittelte Art ändern, aber da musste ich erst wieder suchen, da die Textdatei an anderer Stelle versteckt war: Das ich also noch nicht mal einheitlich!
Ich bin ja immer kein Freund von diesen abgeleiteten Distributionen. Wenn, dann nehme ich lieber das Original. Als im Falle von Artix halt Arch Linux. Und insbesondere in Deinem Fall, wo Du ja viel lernen möchtest, wäre Arch Linux doch eigentlich besser. Weil die sind ziemlich gut dokumentiert.
Arch nutzt systemd.
Außerdem komme ich mit der Text-Modus-Installation noch nicht klar, weshalb ich höchstens ein anderes Arch-Derivat nutzen könnte. Die habe ich mit auch angesehen, allen voran natürlich Manjaro, da es standardmäßig schon Xfce nutzt und deren Webseite auch einen sehr professionellen Eindruck macht, aber neben dem, dass es mir viel zu zugemüllt ist, ist es mir unter der Haube zu sehe vermurkst: So bootet es nur mit dem eigenen Grub (womit "update-grub" bei mehreren parallelen Installationen sehr viel länger als bei allen anderen Distributionen braucht): Bootet man es mit dem Grub einer anderen Distribution (sogar wenn das auch ein Arch-Derivat ist!), gibt es eine Kernel-Panik. Pamac hängt sich ständig auf, wenn man mehreres in einem Rutsch installieren will, dann gibt es oft nach dem booten für ca. 2 Min. 100% CPU-Last auf einem Kern, usw. - Manjaro würde ich nicht mal nutzen wollen, wenn ich dafür bezahlt würde.
Ich habe übrigens extra ein reines (älteres) AMD-System und benötige keine proprietären Treiber: Mir werden auch bei Manjaro nicht mal welche angeboten.
Ich kenne jetzt Artix-Linux nicht. Gut möglich, das es da ähnlich ist (und man auch weite Teile der Arch Doku übernehmen kann) und das der ausschlaggebende Punkt für Dich war, das es besser darin ist alternative Init-Systeme zu unterstützen.
Artix nutzt erst seit kurzer Zeit die Arch-Qellen nur noch optional: Ich benötige sie aber, da es in den Artix-Quellen z. B. weder Opera noch Sigil gibt. Die Arch-Qellen zu nutzen ist kein Problem: Wie shinXdxd oben geschrieben hat, ist das bei Artix sauber umgesetzt. Auch das AUR lässt sich weit überwiegend unter Artix nutzen und aufs Arch-Wiki greife ich oft zurück: Bis eben auf systemd lässt sich das uneingeschränkt übernehmen. - Die systemd-Kommandos in klar verständliche Befehlszeilen zu enträtseln sehe ich als Herausforderung. ;-)
Ich hatte vor übrigens, ein Arch-Xfce parallel zu installieren, um gegentesten zu können, ob Fehler auch schon dort auftreten, so dass ich die besser direkt im Arch-Forum melde **), aber auf meinem PC hing es sich beim initialisieren der GUI immer auf. Auch noch nach mehreren Aktualisierungen, also habe ich es geblkdiscardet: Das sehe ich mir später nochmal an, wenn ich Artix besser kenne.
Das betraf nur mein PC: Die selbst Installation (auf ext. SSD) bootete auf dem noch etwas älteren AMD-PC bei meiner Mutter problemlos ins GUI und auf beiden PCs ließ es sich in KVM auch problemlos bis ins GUI booten.
**) z. B. als sich vor einigen Monaten ntfs nicht mehr per fstrim trimmen ließ und ich auch nach zwei Wochen noch nichts dazu im Internet finden konnte:
https://forum.archlinux.de/d/33838-fstrim-funktioniert-nicht-mehr-mit-ntfs
Im Idealfall fummelt man ja auch nicht einfach an irgendwelchen Einstellungen rum und guckt was passiert, sondern liest die Doku und weiß dann auch welche Änderung welches Ergebnis bringt. Aber ich verstehe, was Du meinst. :-)
Erst kommt natürlich die Doku, dann meine Optimierungen, da ich mir nicht vorschreiben lassen will, wie ich etwas zu handhaben habe: Ich denke lieber selbst.
Wie dem auch sei: Danke für den umfangreichen Einblick in Deine persönliche Artix-Welt.
Keine Ursache. Ich schreibe das hier nicht nur für dich, sondern nicht zuletzt auch, um später noch darauf zurückgreifen zu können.
