Inhaltsverzeichnis
Plasma 6.1 erhält Explicit Sync
Nate Graham berichtet in seiner wöchentlichen Kolumne über die Entwicklung von KDE Plasma unter anderem über den Merge von Explicit Sync. Explicit Sync soll die Probleme mit Wayland und proprietären Nvidia-Treibern lösen, indem es, vereinfacht gesagt, Anwendungen ermöglicht, dem Compositor mitzuteilen, wann Bilder auf dem Bildschirm angezeigt werden sollen, um Latenzzeiten und grafische Störungen zu reduzieren. KDE-Entwickler Xaver Hugl geht in seinem Blog auf die technischen Einzelheiten dieser Lösung ein, die mit Plasma 6.1 am 18. Juni verfügbar sein wird.
Sonst noch…
Des Weiteren wurde in der vergangenen Woche die Software-Sammlung KDE Gear in Version 24.02.2 sowie die KDE Frameworks 6.1.0 veröffentlicht. Die Entwickler bei TUXEDO arbeiten derweil fleißig an der Implementierung von Plasma 6 in TUXEDO OS. Sollte nicht mehr lange dauern.
Debian Paketmanagement APT 2.9 erschienen
In Vorbereitung auf APT 3.0 hat das Debian Team um Andreas Klode APT 2.9 freigegeben. Die neue Version ist seit gestern in Debian Unstable verfügbar. Das Frontend für DPKG erhält mit der neuen Version mehr Übersicht und etwas Farbe. Die Anpassung der UI soll mit APT 3.0 abgeschlossen werden. Farbe und bessere Übersicht
Damit ist APT zwar noch weit von der Übersichtlichkeit von Nala entfernt, aber es ist ein Anfang. Die zu aktualisierenden Pakete werden in einer Kolumne dargestellt und sind besser lesbar als die bisherige Darstellung einer Aneinanderreihung, lediglich durch Leerstellen getrennt. Zudem sind sie durch Einfärbung grün hervorgehoben.
Konkurrenz belebt das Geschäft
Zu entfernende Pakete werden jetzt zuunterst in der Liste angezeigt, womit ein zehn Jahre alter Bugreport geschlossen wird. Auch diese Änderung trägt zur besseren Übersicht bei und führt hoffentlich dazu, dass weniger Anwender sich ihr System durch das Entfernen essenzieller Pakete zerschießen. Ich bin gespannt, was uns APT 3.0 noch an Änderungen der UI bescheren wird. Ich nutze auf verschiedenen Rechnern mal APT, mal Nala und bin immer wieder erstaunt, wie viel besser trotz der im ersten Augenblick aufdringlichen Farben die Inhalte bei Nala zu erfassen sind. APT darf da gerne noch etwas mutiger zu Werke gehen.
Alle weiteren Änderungen stehen im Debian Tracker zum Nachlesen bereit.
paperless-ngx: So wirds endlich papierlos
In den Diskussionen des Bundestages wird (endlich) immer häufiger das Thema Digitalisierung angesprochen. Diese Entwicklung spiegelt auch mein persönliches Bestreben wider, Dokumente und Akten papierlos zu verwalten – ein Unterfangen, welches Mal mehr, mal weniger erfolgreich war. Ein wesentliches Kriterium für mich ist dabei die OCR-Funktion, die es ermöglicht, die digitalisierten Dokumente durchsuchbar zu machen. Aus diesem Grund habe ich mich für die Nutzung von paperless-ngx entschieden. Die Installation der Software über Docker gestaltet sich schnell und unkompliziert. Zudem bietet die Integration von Watchtower in den Docker-Stack die Möglichkeit, Software-Updates automatisch durchzuführen, was den Wartungsaufwand für den Benutzer praktisch eliminiert.
Was ist paperless-ngx eigentlich?
Paperless-ngx selbst ist ein Dokumenten-Management-System – kurz DMS. Die Entwickler beschreiben es auf GitHub wie folgt: “Paperless-ngx ist ein Dokumentenmanagementsystem, das Ihre physischen Dokumente in ein durchsuchbares Online-Archiv umwandelt, damit Sie weniger Papier aufbewahren müssen. Paperless-ngx wurde von paperless-ng abgezweigt, um die großartige Arbeit fortzusetzen und die Verantwortung für die Unterstützung und Weiterentwicklung des Projekts auf ein Team von Personen zu verteilen.”
So läuft die Installation von paperless-ngx
In dieser Variante wird paperless-ngx mittels eines Docker Stacks installiert und verwaltet. Die Konfiguration und Verwaltung von paperless-ngx kann auf zwei Arten erfolgen: traditionell mittels einer docker-compose.yml-Datei oder durch Verwaltungstools wie Portainer.
Der nächste Schritt beinhaltet die Erstellung der benötigten Verzeichnisse. Dies erfolgt durch den Befehl mkdir, wobei in diesem Fall die Ordner im Homeverzeichnis angelegt werden. Um Fehlermeldungen zu vermeiden, müssen die Dateipfade in der Konfiguration an das eigene System anpasst werden.
services:
paperless-ngx:
image: lscr.io/linuxserver/paperless-ngx:latest
container_name: paperless-ngx
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/Berlin
- REDIS_URL= #optional
volumes:
- /home/bjoern/paperless-ngx/config:/config
- /home/bjoern/paperless-ngx/data:/data
ports:
- 8050:8000
restart: unless-stopped
Die initiale Inbetriebnahme des Docker Stacks kann abhängig von der Hardware-Leistung und der Internetgeschwindigkeit einige Zeit in Anspruch nehmen. Nach dem erfolgreichen Start der Container ist der Zugriff auf den Login-Bildschirm über die URL http://ip-adresse-des-hosts:8050/ möglich. Standardmäßig sind die Anmeldedaten als “admin” für Benutzername und Passwort gesetzt. Über den Link http://ip-adresse-des-hosts:8050/admin/ erreicht man die Administrationsoberfläche, welche Optionen zur Änderung von Benutzername und Passwort bietet. Darüber hinaus bietet die Plattform erweiterte Funktionen, einschließlich der “Paperless E-Mail”. Die Integration von IMAP-Konten in das System paperless-ngx ermöglicht es, eingehende Dokumente automatisch direkt im Archiv abzulegen. Diese Funktion ist besonders für Unternehmen und Freiberufler von Vorteil, insbesondere wenn Rechnungen über eine spezielle E-Mail-Adresse empfangen werden.
Wer sich die manuelle Einrichtung nicht zutraut, kann auch auf das automatische Installationsscript zurückgreifen. Mit diesem habe ich in einer Proxmox-VM zum Testen ebenfalls gute Erfahrungen gemacht. Für den Einsatz von paperless-ngx wird lediglich eine funktionierende Docker-Umgebung benötigt.
bash -c "$(curl --location --silent --show-error https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/main/install-paperless-ngx.sh)"
Unabhängig von der gewählten Methode zur Einrichtung von paperless-ngx oder einem anderen Dokumentenmanagementsystem (DMS) ist die Entwicklung einer eigenen Backup-Strategie unerlässlich. Die Sicherung von Daten ist ein kritischer Aspekt, der sicherstellt, dass Informationen auch im Falle eines Systemausfalls oder anderer unvorhergesehener Ereignisse verfügbar bleiben. Eine effektive Backup-Strategie schützt nicht nur vor Datenverlust, sondern erleichtert auch die Wiederherstellung im Worst Case.
Sicherheitslücke im Linux-Kernel
April April, der macht, was er will. Nach dem XZ-Utils-Fiasko taucht nun eine Lücke im Kernel auf, die Angreifern mit unprivilegiertem Zugriff auf das System über eine lokale Rechteausweitung (LPE) Root-Rechte verschaffen kann. Diese wurde bereits am 21. März erstmals gemeldet. Die Lücke wurde als CVE-2023-6546 katalogisiert.
Zwei statt nur einer
Der Angriff funktioniert allerdings nur, wenn sowohl das GSM-Subsystem als auch die Xen-Virtualisierung aktiviert sind. Es existieren bereits mehrere Exploits für verschiedene Kernel und Distributionen. In einer Diskussion auf der Kernel-Liste gehen die Entwickler davon aus, dass die Lücke geschlossen sei. Letztlich scheint es aber um zwei Lücken zu gehen, wie Sicherheitsforscher Kyle Zeng auf Openwall gestern berichtete. Demnach soll eine der beiden Lücken noch ungepatched sein.
Wayland, Nvidia und »explicit sync«
2024 ist das Jahr von Wayland. Die Linux-Gemeinde freut sich darüber, dass nach über 15 Jahren Entwicklung die Ablösung von X11 endlich Fahrt aufnimmt. Wenn da nicht das Lager der Nvidia-User wäre. Vor allem ältere Nvidia-Karten können, je nachdem in welcher Umgebung sie laufen, immer noch Probleme im Zusammenspiel mit Wayland machen. Das äußert sich in Display-Flackern, fallen gelassenen Frames oder Artefakten bis hin zu Freezes und Abstürzen in Games.
Wayland und Nvidia
Das soll nun bald ein Ende haben und eine Technik namens »explicit sync« soll dafür sorgen. Der nötige Code wurde kürzlich in das Wayland-Protokoll integriert und soll am 15. Mai auch in der Beta-Version von Nvidias proprietärem Treiber in Version 555 zu finden sein. Commits für die Integration in Compositoren wie Mutter und KWin sowie in die Kompatibilitätsschicht Xwayland sind in vollem Gange. Mit KDE Plasma 6.1 im Juni 2024 sollte Wayland dann auch mit Nvidias proprietären Treibern problemlos funktionieren.
Um zu verstehen, was hier passiert, muss man verstehen, dass die noch vorhandenen Probleme durch die verwendete Art der Synchronisation beim Rendern von grafischen Elementen im Zusammenspiel von CPU, GPU und der anfordernden Applikation entstehen. KDE-Entwickler Xaver Hugl erklärt die Hintergründe in einem aktuellen Blogpost.
Synchronisation
Vereinfacht ausgedrückt, heißt das: Wenn eine Anwendung das Rendern eines grafischen Inhalts anfordert, schickt die CPU diesen Auftrag an die GPU. Diese rendert aber nicht jeden Auftrag separat, sondern sammelt diese und führt sie zu einem ihr genehmen Zeitpunkt aus. Würde jede Rendering-Anforderung sofort ausgeführt, würden CPU und GPU die meiste Zeit aufeinander warten und somit Zeit verschwenden. Da Rendering-Aufträge aber nicht für sich alleine stehen, sondern beispielsweise mit Befehlen zur Umwandlung in ein anderes Format oder der Rückgabe an die CPU zum Speichern auf die Festplatte verknüpft sind, funktioniert dieser Ablauf nicht ohne Synchronisation.
Imlizit und Explizit
Das bisherige Modell nutzte dazu imlicit sync, was im Gegensatz zu explicit sync ohne Beteiligung der anfordernden Anwendung funktioniert. Das kann unter Wayland zu Problemen führen, da die Anwendung nicht weiß, mit welchen Aufgaben sie synchronisiert, und es kann passieren, dass sie versehentlich und unwissentlich mit GPU-Befehlen synchronisiert, die für Ihre Aufgabe gar nicht relevant sind. Das führt dann wiederum zu den bekannten Problem wie Flackern und Stottern. Beim explicit sync ist die Anwendung beteiligt und weiß, wann das Rendering abgeschlossen ist und welche Aufgaben überhaupt synchronisiert werden sollen.
Komplexes Problem
Es dauerte insgesamt rund vier Jahre und viele Diskussionen, bis der ursprüngliche Merge-Request für Wayland angenommen wurde. Die Komplexität erwuchs aus dem nötigen Zusammenspiel von CPU und GPU, der verwendeten Treiberversion, dem Kernel und dem Compositor. Mit der Implementierung in Xwayland, Mutter, KWin und Mesa sollten die Probleme mit Wayland und Nvidia aber hoffentlich bald der Vergangenheit angehören. Damit wird auch die Akzeptanz von Wayland generell ansteigen.
<< Neuere Einträge | Ältere Einträge >>
This page has been accessed for: Today: 1 / Yesterday: 1 Until now: 368