Ranayna schrieb:
hat Canonical sich fuer mich disqualifiziert, weil sie ein paar Sachen gemacht haben, die sie direkt von Microsoft kopiert zu haben scheinen.
Ich sage auch gerne, dass Canonical für mich das Microsoft der Linux-Distributoren ist.
Ranayna schrieb:
Entweder wird es wieder Manjaro, Fedora, oder OpenSUSE Tumbleweed. Ein (Semi) Rolling-Release mit nativem KDE Plasma.
Zu Manjaro hatte ich schon geschrieben, SUSE war schon 2008 bei meinen ersten Versuchen mit Linux durchgefallen *) und auch als ich mich vor ca. 2 Jahren informiert habe, habe ich nichts gelesen, das meine Meinung geändert hätte, sondern sie wurde eher bestätigt (ohne das genauer definieren zu können: es geht mir einfach irgendwie gegen den "Strich"), aber da dort momentan sowieso einiges im Umbruch ist, wäre es jetzt sowieso nicht sehr empfehlenswert.
Von den dreien macht Fedora (nachdem was ich darüber lese) noch den besten Eindruck auf mich (Hauptsache Redhat macht damit ich auch plötzlich etwas in der Art, wie mit CentOS), vielleicht aber eher ein für Spiele optimiertes Derivat?
Aber groß festlegen muss man sich sowieso nicht: Alle nutzen den gleichen Linux-Kernel und funktionieren unter der Haube ziemlich gleich, so dass man, wenn man erst mal "drin" ist, rel. problemlos wechseln kann. - Insbesondere wenn man beim gleiche Paketmanager bleibt, kann man das meiste einfach übernehmen.
*) Ich bin dann aber bei Windows XP geblieben, allerdings auf x64 umgestiegen: Bis 2015, ab dann LinuxMint 17.1-18.3: das aber bis 2020 - es war
sehr angenehm, nicht mehr alle 6 Monate eine neue Version (mit oft gravierenden Änderungen) zu bekommen: Deshalb habe ich mich dann ausschließlich nach Rolling Releases umgesehen - diesen "Komfort" wollte ich nicht mehr missen
Ranayna schrieb:
An meiner Praemisse so wenig wie moeglich mit der CLI machen zu muessen werde ich festhalten, dementsprechend ist mir eine grafische Paketverwaltung wichtig. Deswegen ist Endeavour eher raus, auch wenn man die da auch nachinstallieren kann.
Sei besser offen für - äh - altes (Terminal gab es ja zuerst
): Das eine schließt das andere nicht aus (für jedes das passende Werkzeug) und auch wenn man im Terminal zuerst etwas mehr Zeit investieren muss, spart man die bei anschließend vielfach wieder ein.
Z. B. hatte ich mir nach der Installation notiert, was ich rausgeschmissen und nachinstalliert habe und wenn ich mal eine Neuinstallation mache, brauche ich nur das ausführen:
Bash:
# Ausmisten und benötigtes installieren (Hinweise unten beachten):
sudo rm -v /boot/*-fallback.img /etc/environment /etc/issue;sudo ln -s /usr/local/bin /root/
sudo pacman -Rscn intel-ucode memtest86+ linux-headers scrot artix-branding qt ecryptfs-utils cups ghostscript liblouis epiphany leafpad ristretto parole vi xfwm4-themes xfce4-artwork xcursor-premium
sudo pacman -Syu --needed base-devel artools-base hdparm gsmartcontrol espeak-ng neofetch expac wget pv qemu-desktop falkon xcursor-vanilla-dmz gparted ddcutil trizen mate-utils x{view,read}er gnome-{disk-utility,system-monitor} hunspell{,-de,-en_us} audacity xed gimp simple{-scan,screenrecorder} xsane vice
sudo pacman -S --asdeps bash-completion mesa-vdpau libva-mesa-driver vulkan-radeon xarchiver
trizen --noedit -Sa mugshot menulibre gnome-icon-theme upd72020x-fw
# + aus Arch-Quellen:
sudo pacman -S compsize drawing duperemove exfatprogs fdupes fsarchiver fs rmlint sigil uasm wmctrl xaos gnome-icon-theme-extras
# ==================
sudo pacman -Qdtq|sudo pacman -Rscn -;sudo pacman -Sc
sync;sudo fstrim -va # bei SSDs
Was für ein
irrsinniger Aufwand wäre es, das alles einzeln im GUI zu (de)installieren?
Außerdem: Würdest du all das aus dem Kopf auf die Reihe bekommen? - Aufschreiben müsste man es also sowieso…
Abgesehen davor bekommt man im Terminal mehr Informationen und ausführliche Meldungen: Wenn im GUI was nicht funktioniert (z. B. eine Anwendung startet nicht), starte ich sie im Terminal, um herauszufinden was das Problem ist.
Beschränkst du dich auf GUI, kannst du nur sagen "geht nicht", versuchst du es im Terminal, kannst du die Fehlermeldung posten: Wann kann man dir wohl besser helfen? - Und was ist schneller: Wahlloses im dunkeln stocheren (versuch mal dies, versuch mal das, …), oder eine gezielte Hilfe direkt auf den Punkt?
Beelzebot schrieb:
Interessanter Ansatz. Ich hab das gesplitet zwischen Hauptsystem und Home.
System und Home gehören m. E. auf eigene Partitionen, wie ich es auch im Garuda-Thread für Calamares und LMDE gezeigt habe:
Klick
Beelzebot schrieb:
Das Hauptsystem wird bei jedem Update durch Snapper gesichert. Die Snapshots werden direkt in Grub eingebunden und sind bootbar, falls was ist. Diese zusätzlich nochmal zu speichern ist mir too much.
Was ist daran zu viel? Hast du dir das nicht in meinem Video angesehen: Ein Klick aufs Skript (den Doppelklick habe ich schon lange deaktiviert) + Passworteingabe und dann kurz warten bis es durchgelaufen ist.
Snapshots nutze ich schon deshalb nicht, weil Platzverschwendung und mit hops sind, falls man sich die Partition zerschießt. - Das sind
keine Sicherungen, sondern man sollte sie bestenfalls als eine Art erweiterter Undo-Funktion sehen.
Davon abgesehen macht dieser @-Kram es unübersichtlich und provoziert Fehler, weil man "von innen" nichts davon sieht, es bei der Wiederherstellung "von außen" aber berücksichtigen muss, damit man sich das System nicht zerschießt.
Alleine die Möglichkeit, dass man mit Grub einen älteren Snapshot direkt booten kann, hätte was, aber die Nachteile sind mir zu groß.
Ich nutze btrfs wegen der Komprimierung (zstd:2, weil es bei btrfs genauso gut wie die Standardstufe 3 komprimiert, aber fast 50% weniger CPU-Zeit braucht) auf der Systempartition, aber als normales Dateisystem:
Code:
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=fb01a4fd-8f22-4481-aa43-bb6af7762cd9 / btrfs noatime,compress=zstd:2 0 0
UUID=db0bf1df-6c20-4890-b3a3-6d31f3e52e11 /home xfs noatime 0 0
memory /tmp tmpfs nosuid,size=90% 0 0
memory /tmph tmpfs huge=always,size=90% 0 0
Auf der Home habe ich xfs, weil es sich als sehr schnell und nahezu unkaputtbar erwiesen hat.
/tmph nutze ich für große Dateien (z. B. Videoschnitt oder ISOs), weil es durch "huge=always" dabei deutlich schneller als die normale RAM-Disk ist. Für viele kleine Dateien, z. B. der Systempartition, ist es dagegen
vollkommen unbrauchbar, da es quasi mit 4M Clustergröße arbeitet und dadurch einen gewaltigen "Verschnitt" hat.
Eine Swap habe ich nicht. Stattdessen nutze ich eine zRAM-Swap per /etc/rc.local:
Code:
modprobe zram && echo lz4 > /sys/block/zram0/comp_algorithm && echo $(($(grep 'MemTotal:' /proc/meminfo|awk '{print $2}')*1/1))K > /sys/block/zram0/disksize && mkswap -qU clear /dev/zram0 && swapon -p100 /dev/zram0
