@spotbot2k ich hab mir auf meiner workstation auch fedora installiert, obwohl ich eigentlich eingefleischter debianist bin...

weil im neuen job waren nur rpm-basierte distris im einsatz (centos), und ich wollte mit der verwaltung von solchen distris vertrauter werden...

bin aber einfach nicht glücklich mit fedora... werd wieder auf debian umsteigen.

@ij
Ich nutze seit Ewigkeiten Testing... auch wenn es bzgl. Sicherheitsupdates nicht optimal ist. Aber du hast Recht... wenn man ein "aktuelles" Debian haben möchte, ist Unstable eigentlich die Distribution der Wahl.

Ich hab mir vor langer Zeit ein sehr aufwändiges und umfangreiches Backup-Script für BTRFS geschrieben, da BTRFS zwar ziemlich genial ist, und Backups mit Snapshots echt gut funktionieren (also Snapshots machen, und diese dann auf eine zweite Platte kopieren). Aber "rekursiv" klappt das nicht mit Hausmitteln.
Und wenn ich schon Subvolumes/Snapshots mit BTRFS nutze, dann will ich das auch "ordentlich" und umfangreich machen. Also jedes Homeverzeichnis ist ein eigenes Subvolume. Die User sollen auch in ihren Homeverzeichnissen Snapshots verwenden können usw...

Mein Backupskript kann genau das. Von Subvolumes im Dateibaum genau dort auch ein Snapshot erstellen und dieses auf das Offsite-Backup-Medium übertragen.

Außerdem prüft es auf dem Offsite-Medium die FS-Struktur ob und welche Subvolumes zu erstellen/löschen/zu übertragen sind.

Und es legt eindeutig benannte Symlinks an.

Außerdem hab ich es in apt so eingehängt, dass bei jedem apt upgrade von den System-Subvolumes (nicht von /home oder bestimmen /var-Verzeichnissen z.b. Mailordner) ein Snapshot gemacht wird. Sollte ein Upgrade also ein kaputtes System hinterlassen (was ja bei Unstable vorkommen soll), kann ich beim Booten durch Angabe des Snapshots "BEFOREUPGRADE" auf der grub CMDL in den letzten Zustand VOR dem Upgrade wieder herstellen und genau dort weiterarbeiten, und den kaputten Snapshot einfach löschen...

Das Skript ist zwar - weil ich schon seit mehreren Jahren Fedora nutze - etwas wenig gewartet... Aber wenn ich wieder auf Debian zurückwechsle bzw. Fedora 34 mit BTRFS nutze, dann werd ich das Skript einmal aufarbeiten... Für Debian-sid ist es genau das richtige!

@spotbot2k

@ij ja das Skript (in Python geschrieben) ist very sophisticated... :)
Alte snapshots kann ich damit auch einfach aufräumen und per Config-File auch vorgeben, wieviele aufgehoben werden sollen.

Leider hab ich mit BTRFS und externen Platten keine so gute Erfahrung gemacht. Da blieben mir oft korrupte Filesysteme übrig... Obwohl BTRFS dagegen eigentlich "immun" sein sollte. Aber es lag dann im Endeffekt an einem kaputten USB-Kabel. Hab mir ein neues zugelegt, und die Probleme waren weg. Dennoch blieb ein ungutes Gefühl zurück, da die ext4-Partitionen trotz kaputtem Kabel reparierbar waren, BTRFS nicht.

Und was mit BTRFS auch nicht funktionierte, waren Quotas. Die verlangsamten das Filesystem so derartig, dass das Filesystem unbenutzbar wurde. Keine Ahnung, ob das mittlerweile gefixt wurde. Bekannt war es. Hab das aber auch schon 6 Jahre nicht mehr getestet

Ich würd dir jetzt gern den Link zu meinem git-Repo nennen. Bin mir aber grad nicht sicher, auf welchem Server ich die aktuelle Version liegen habe, und ich weiß, dass auch in der aktuellen Version ein Bug versteckt ist, den ich mangels Zeit und Dringlichkeit noch nicht gefunden und gefixt habe.

Ich werds nachholen. Ich versprechs. :)

@spotbot2k

@spotbot2k das "bleeding edge"-Fedora hat bei unison eine so derartig veraltete Version im Einsatz, die nichtmal mit Debian old-stable zu verwenden ist, weil Debian eine deutlich neuere Version einsetzt...

Ok... es ist ein Designfehler von unison, dass schon Minor-Versionen nicht mehr untereinander kompatibel sind... aber dennoch...
Mir sind ein paar Pakete in Fedora aufgefallen, die grandios veraltet sind.

Und mit dem Kernel bzw. Netzwerk-Stack habe ich immer wiederkehrende massive Probleme mit Gnome. Ich habe NFS- und Gluster-Filesysteme eingebunden. Und es passiert immer wieder bei Kernel-Updates, dass diese beim Standby hängenbleiben und der Login beim wieder aufklappen des Laptops nicht geht, weil Gnome eingefroren ist. Es hängt an diesen Filesystemen konnte ich schon rausfinden. Und zwei, drei Kernelupdates später funktionierts wieder.

Ich weiß nicht, wie oft ich dieses Phänomen ich in den letzten 4 Jahren schon hatte. 15x 20x?

Und ein Problem, aber das liegt wohl an Gnome, gibts auch noch. Bei der Verbindung mit dem WLAN (vielleicht ist es auch VPN) und auch mit Bluetooth friert Gnome ein. Erst wenn die Verbindung steht oder der Verbindungsversuch mit einem Error beendet wird, lässt sich die Oberfläche wieder bedienen. Sogar die Maus ist eingefroren. Hab das schon mal bei Gnome eingekippt... es passierte aber bislang nix.

Ja ich weiß... Gnome und so... aber ich mag den Desktop. Die Minimalismus-Ansätze nerven manchmal. Besonders beim Dateimanager... Und die mittlerweile nicht nur fehlende sondern auch komplett ausgeschlossene Systray-Einbindung find ich wirklich bescheuert...

Und mit Wayland kann ich auch nicht warm werden. Ich nutze beruflich viel X2Go... und das ist eine Katastrophe mit Wayland. Auch anydesk funktioniert mit Wayland nicht.

Und Fedora muss ich mittlerweile schon fast so oft neu booten, wie annodazumals Win98... kein Scherz. Das ist der Hauptgrund, warum ich wieder zu Debian wechseln möchte. Ich halte es mit Debian so, dass ich solange auf Stable bleibe, bis ich die ersten Pakete aus den Backports benötige. Die werden dann eingebunden. Und irgendwann kommt dann der Punkt, wo ich die ersten Pakete aus Testing benötige, weil die nicht in den Backports sind. Dann wechsle ich zu Testing, bis dieses Stable geworden ist. Und dann gehts von vorne los. Damit fahr ich seit 2007 mit Debian eigentlich ziemlich gut.