Vor ein paar Jahren hatte ich mich mit einer Videosequenz herumgespielt, um einen gefällten Baum virtuell wieder auferstehen zu lassen. Das Ausgangsmaterial war qualitativ mäßig, aber der Einzeiler machte, was er sollte: Der Baum stand wieder.
ML-gestütztes Video Upscaling wollte ich immer mal wieder ausprobieren. Ein erster Anlauf mit Real-ESRGAN in Ubuntu 22.04/WSL war unbefriedigend, die Performance war mau:
Die AMD Ryzen iGPU wird von ROCm nicht unterstützt.
Das Modell lief nur auf einem CPU-Kern.
Den neuen Anlauf gestaltete ich auf Basis von Ubuntu 24.04/WSL bzw. nativ mit Fedora 43. Die Performance war in beiden Fällen deutlich besser, obwohl die iGPU weiterhin keine Nutzung fand. Dafür skalierte nun das Modell über alle CPU-Kerne. Allerdings stehen hinter der Aussage „deutlich besser“ immer noch ca. 12 Sekunden pro Frame.
Baum sagt adieu – nach dem Upscaling mit Real-ESRGANUnd da ist er wieder, mein Freund der Baum – nach dem Upscaling mit Real-ESRGAN
Was ziehe ich aktuell daraus:
Mein persönlicher Proof-of-Concept ✅
Um so weit zu kommen, musste ich die eine oder andere Library patchen um sie mit aktuelleren Python-Versionen zum Laufen zu bekommen (insbesondere basicsr) ✅
Die erzielte Video-Qualität ist auch bei wirklich schlechtem Ausgangsmaterial gut. Das zeigte der obige PoC, aber auch andere Videoschnipsel, die ich hier nicht posten kann ✅
ML auf CPU-Kernen macht keinen Spaß, schon gar nicht bei vielen Hundert oder Tausend Frames. Eine letzte Möglichkeit, die iGPU doch noch zum Mitmachen zu überreden, wäre die Inferenz via Vulkan zu beschleunigen. Aber auch da reden wir vielleicht von Faktor 2 bis 5 an Verbesserung gegenüber der reinen CPU – zu langsam um ein ernsthaftes Projekt zu wagen.
Ich bin nicht der große Freund von Teams, bin aber durch verschiedene Aktivitäten mit verschiedenen Teams-Konten konfrontiert. Da ich zuhause aber lieber Linux (aktuell Fedora) verwende, steht mir am Desktop die native Teams-App nicht zur Verfügung.
Für Teams gibt es aber seit einiger Zeit die Progressive Web App, kurz PWA, von Microsoft, welche aktuell in Firefox und Chromium-basierten Web Browsern als „Desktop-Applikation“ installiert werden können. So weit wenig Neues.
Die PWA unterstützt Stand heute immer nur ein Teams-Konto. Um somit mehrere Teams-Konten zu bespielen, kann man sich einem Trick behelfen und in Chromium sogenannte Profile erstellen:
Profil-Auswahl in Chromium
In jedem Profil können nun eigene PWA installiert werden, in meinem Fall jeweils einmal Teams. Ist das erfolgt, sind die PWA im Applikations-Launcher verfügbar und können separat gestartet werden:
Zwei separate Teams-Instanzen in jeweils einer PWA
Ähnlich lässt sich das auch in Firefox lösen, aber Teams bevorzugt leider Edge und lebt ganz gut mit Chromium.
Eine meiner eher partiell schlauen Entscheidungen war annodazumal ein Netgear Readynas Ultra 2, aka RDNU2120, zu beschaffen. Gedacht war es als NAS mit zusätzlicher Backup- und Media-Streaming-Aufgabe, also genau, was es (damals) konnte. Die Nutzungsrealität sah anders aus:
In der damaligen Wohnung gab es keinen Platz, wo das kleine Kastl nicht irgendwie störte (optisch, akustisch).
Der familiäre Media-Streaming-Konsum damals wie heute überschaubar geblieben ist.
24/7 laufen lassen nur Strom verbraucht hätte, da außer Leerlauf kaum Betrieb zu erwarten war.
Außer den gelegentlichen Systemupdates wurden in unregelmäßigen Abständen Backups von unseren Endgeräten gezogen.
Bis es immer öfter im Schrank blieb.
Dabei ist es ein für damalige Verhältnisse potentes Gerät für viele Aufgaben, die im Heimbereich anfallen:
Intel Atom Single Core Prozessor mit 1,8 GHz Taktfrequenz
1 GB DDR3-RAM
2x 1 Gb Ethernet
3x USB
2x 3,5″ HDD-Schnellwechselschächte
Und mit dem vorinstallierten Readynas-OS ein Debian-Abwandlung als Betriebsystem
Vor kurzem habe ich es wieder aus dem Schrank geholt, wegen Backups ziehen warat’s und außerdem suche ich ein Poster aus einer Posterpräsentation aus dem Jahr 2009, das ich nirgends mehr finden kann.
Long story short: Das Poster konnte ich (noch) nicht finden und beim Einbinden des Readynas wurde es holprig.
Nach dem erfolgreichen Boot-Prozess und Abholens einer TCP/IP-Adresse beim DHCP-Servers zeigte sich mangels Unterstützung einer aktuellen TLS-Version ein Drama in mehreren Akten. Der in Nautilus/Files integrierte Samba/CIFS-Client war not amused die Shares einzubinden, mein Webbrowser wollte nicht mit dem Admin-Panel kommunizieren. Bei letzterem verständlich, TLS 1.0 ist seit einiger Zeit abgekündigt und das aus gutem Grund.
Nicht unterstützte TLS-Version verhindert Zugriff auf das Admin-Panel
Workaround Admin-Panel
In Firefox kann unter
about:config
in die Innereien des Browsers eingegriffen werden. Unter anderem kann hier1 auch die minimale TLS-Version vorgegeben werden. Dafür gibt man in der Suchmaske folgendes ein:
security.tls.version.min
Per Default ist hier 3 als Wert eingetragen, was TLS-Version 1.2 oder höher entspricht. Im Fall von diesem Readynas musste ich TLS-Version 1.0 freischalten:
Wert in about:config
TLS-Version
3
TLS-Version 1.2 oder höher
2
TLS-Version 1.1 oder höher
1
TLS-Version 1.0 oder höher
Zulässige Werte und deren Bedeutung für security.tls.version.min
Es ist keine gute Idee, dauerhaft auf eine nicht mehr unterstützte und vor allem unsichere TLS-Implementierung zurückzugreifen.
Mit dieser Anpassung gelang der Zugriff auf das Admin-Panel wieder.
Workaround Nautilus/Files
Ursache war hier, dass sich das Readynas nur auf SMB-Version 1.0 versteht, aber die Welt von Version 2 oder höher mittlerweile ausgeht.
[Quick Fix #1] WebDAV aktivieren
Im Admin-Panel aktivierte ich zusätzlich den Zugriff auf die Shares via WebDAV, womit der Zugriff in Nautilus/Files wieder funktionierte. Damit konnte ich wieder durch die Verzeichnisse navigieren.
[Quick Fix #2] Mount via Terminal
Mit den cifs-utils kann ein Share direkt im Terminal eingebunden werden:
~$ sudo mount -t cifs -o user=username,vers=1.0 //192.168.x.y/xyz /mnt/rn
Wie geht es weiter?
Die beiden Workarounds sind natürlich keine Dauerlösung. TLS wurde aus gutem Grund verbessert und WebDAV ist als Protokoll sicher ok um die wichtigsten Daten vom Readynas zu sichern, aber aus meiner Sicht ist es nicht das Protokoll für das dauerhafte Bewegen großer Datenmengen. Die Limitierung auf SMB-Version 1.0 kann mit entsprechendem Scripting bzw. Automount umgangen werden, somit ist dieser Punkt entschärft.
Readynas-OS ist EOL und für mein deutlich älteres Readynas gibt es seit vielen Monden keine Updates mehr, d.h., die Hoffnung auf eine offiziell aktualisierte TLS-Version ist nicht gegeben. Beim Blick in das Gerät zeigte sich aber ein sehr guter Zustand, zum Wegwerfen zu schade. Folgende Ansätze stehen zur Diskussion:
Ein älterer PC steht seit ein paar Wochen herum und dient als kurzweilige Spielwiese für verschiedene Linux-Distributionen, u.a. Debian Buster, AV Linux (aka MX Linux Respin) oder jetzt gerade eben Fedora SOAS (Sugar on a Stick).
Praktischerweise reicht ein USB-Stick als Träger für die jeweilige Live-Session und als Installationsmedium. Und damit ich es nicht vergesse: dd unterstützt eine Fortschrittsanzeige, wenn ich eine Live-ISO wieder auf den USB-Stick spielen möchte…
Wieder einmal etwas aus der Kategorie „brauch ich ganz selten“: Log Files werden, seit systemd bei vielen Linux-Distributionen Einzug gehalten hat, durch das Service systemd-journald zentral verwaltet. Mit der Zeit werden gewinnen die Log Files an Größe, das lässt sich aber ganz einfach managen.
Die Log Files werden je nach Konfiguration persistent unter /var/log/journal/MACHINE-ID/ oder in-memory unter /run/log/journal/MACHINE-ID/ abgelegt. Im zweiten Fall löst der Reboot die Speicherfrage, im ersten darf/muss man selbst Hand anlegen.
--disk-usage gibt Auskunft über den verbrauchten Speicherplatz der aktiven und archivierten Log Files.
--rotate wandelt aktive Log Files in archivierte um.
--vacuum-time=4months entfernt alle Log-Einträge, die älter als vier Monate sind. Das geht auch Wochen (4weeks), Stunden (4h), Minuten (4m) und Sekunden (4s)…
--vacuum-size=256M entfernt alle älteren Log-Einträge, bis die Log Files 256Mb haben (K, M, G, T sind die möglichen Größeneinheiten).
--vacuum-time und --vacuum-size können auch gemeinsam in einem Aufruf verwendet werden, auch in Kombination mit --rotate (seit systemd 240): journalctl --rotate --vacuum-time=4months --vacuum-size=256M
![[work-in-progress] Netgear Readynas ins Leben zurück holen](https://www.achtzigzehn.net/blog/wp-content/uploads/2024/07/Bildschirmfoto-vom-2024-07-15-14-33-56.png)