Inhaltsverzeichnis
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.
Firefox Nightly 126 übersetzt selektierte Textstellen
Seit Firefox 118 bietet der Mozilla-Browser ein Alleinstellungsmerkmal, das die Bedeutung des Browsers im Open-Source-Umfeld erneut unterstreicht. Die Rede ist von Firefox Translations, einer Übersetzungsfunktion, bei der im Gegensatz zu anderen Übersetzern keine Daten an einen fremden Server gesendet werden. Die Übersetzung findet vielmehr auf dem eigenen Rechner statt. Bisher konnte jedoch nur ganze Webseiten übersetzt werden.
Stetig verbessert
Über die letzten Monate wurden weitere Sprachen hinzugefügt und an der Robustheit der Übersetzungsfunktion gearbeitet, um die Leistung in Zukunft an die Angebote der Konkurrenz anpassen zu können. Das ist noch ein weiter Weg, der gerade wieder ein wenig kürzer wird. Denn was bisher oft schmerzlich vermisst wurde, ist die Übersetzung einzelner markierter Textstellen. Das soll künftig das Arbeiten mit Übersetzungen in Firefox im Gegensatz zum Übersetzen einer gesamten Webseite beschleunigen.
Nativ integriert
Was bisher nur als Add-on verfügbar war, kann derzeit in Firefox Nightly 126 als native Funktionalität getestet werden. Allerdings ist die Funktion bisher nicht standardmäßig aktiv, was sich aber schnell ändern lässt. Dazu wird about:config geöffnet und in der Suche der String browser.translations.select.enable eingegeben. Darin wird der Wert dann von false auf true gesetzt.
Im Kontextmenü wird damit die Option Translate Selection to Deutsch freigeschaltet. Daraufhin öffnet sich oben rechts ein Fenster, in dem eigentlich die Übersetzung stehen sollte. Das funktioniert bei mir mit der Nightly-Version 126.0a1 (2024-04-04) derzeit nicht, das Fenster bleibt leer.
Die neue Funktion wird frühestens mit Firefox 126 am 14. Mai ausgeliefert.
Kodi 21 »Omega« freigegeben
Das Open-Source-Media-Center Kodi hat bereits einen langen Weg hinter sich. Die Software startete im Jahr 2002 als XBMC und wurde 2015 mit Version 14 in Kodi umbenannt. Gerade wurde nach drei Beta-Versionen die stabile Version von Kodi 21 »Omega« veröffentlicht.
FFmpeg 6.0
Die Entwickler haben sich Zeit gelassen mit Kodi 21. In den drei Beta-Versionen seit Oktober 2023 sollte sichergestellt werden, dass die Einführung von FFmpeg 6.0 als eine der wichtigen Komponenten von Kodi keine Regressionen hervorbringt. Verbesserungen wurden für HiDPI-Displays besonders für Anwender von macOS erreicht. Ebenfalls neu für macOS und iOS ist die Einführung von Spracherkennung, die es Benutzern erlaubt, mit Kodi über Sprachbefehle zu interagieren. Seit Jahren in der Entwicklung war native Fensterdarstellung unter macOS, die jetzt bereit zum Einsatz ist. Somit konnten letzte Reste der bisher verwendeten SDL-Bibliothek entfernt werden.
webOS als neue Plattform
Eine neue Plattform kann Kodi jetzt nativ ausführen. Die Portierung auf LG webOS Smart TVs wurde durch Reeinginiering großer Teile der webOS-Medien-Pipelines erreicht. Verbesserungen für Linux lassen sich aus der Ankündigung nicht herauslesen. Lediglich die Einstellung des offiziellen PPA für Ubuntu findet Erwähnung. Ein aktuelles Flatpak als Ersatz steht auf Flathub bereit.
Im Download-Bereich der Webseite steht Kodi 21 »Omega« für Linux, macOS, Android, iOS, Raspberry Pi, webOS, tvOS und Windows bereit.
<< Neuere Einträge | Ältere Einträge >>
This page has been accessed for: Today: 1 / Yesterday: 1 Until now: 300