CleanPress

Blog

  • Firefox 94 mit neuem OpenGL-Backend für Linux

    Im Verlauf des heutigen Dienstags gibt Mozilla offiziell Firefox 94 und gleichzeitig Firefox-ESR 91.3 frei. Wie üblich liegen die neuen Versionen bereits seit gestern auf den Servern. Linux-Anwender können sich auf mehr Geschwindigkeit beim WebGL-Rendern und weniger Energieverbrauch freuen, denn das OpenGL-API wechselt auch unter X11 von GLX auf dessen modernen Nachfolger EGL, wie Mozilla-Entwickler Martin Stransky in seinem Blog berichtet.

    EGL übernimmt

    Dieses im Vergleich zu GLX relativ neue API, das eine Schnittstelle zwischen OpenGL und dem Fenstersystem darstellt, wurde ursprünglich für Wayland konzipiert, funktioniert aber nun auch unter X11, sofern mindestens Mesa 21 installiert ist. Das neue Backend arbeitet mit Intel und AMD zusammen, Anwender von Nvidias proprietären Treiber müssen sich hingegen noch ein wenig gedulden, da dem Treiber die EGL-Erweiterung fehlt, die mit NVIDIA 495 kommen soll. Bei Mozilla sind in der Hinsicht noch 2 Bugs offen.

    Falls EGL mit Firefox 94 bei euch noch Probleme bereiteten sollte, kann in about:config auf GLX zurückgeschaltet werden. Dazu muss der Schalter gfx.x11-egl.force-disabled von false auf true gesetzt werden. Für die Entwickler bedeutet der Schritt zu EGL eine Erleichterung, da mehr Code mit Wayland und der bereits auf EGL umgestellten Android-App geteilt werden kann, was wiederum zu weniger Bugs führt, wie die Entwickler im Mozilla Gfx Team Blog schreiben.

    Tab Unloading auch für Linux

    Firefox 93 aktivierte erneut das bereits früher einmal getestete Tab Unloading für Windows-Nutzer. Dabei geht es darum, dass Tabs automatisch entladen werden, wenn das System feststellt, dass aufgrund zu vieler offener Tabs oder anderer speicherhungriger Anwendungen der freie Speicher zur Neige geht. Nutzer müssen dann auf den oder die entladenen Tabs klicken, um sie neu zu laden.

    Mit Firefox 94 wird diese Funktionalität nun auch für Linux reaktiviert. Dazu zeigt eine neue Seite unter about:unloads an, wie Firefox die Tabs priorisiert und welcher Tab entladen wird, wenn die Funktion ausgelöst wird und erlaubt auch das manuelle Entladen einzelner Tabs, allerdings nur in der vorgegebenen Reihenfolge.

    Ein von Apple entliehener Energiesparmodus verhilft Firefox-Usern unter macOS beim Abspielen von Vollbild-Videos auf YouTube und Twitch zu längeren Akku-Laufzeiten. Über weitere Neuerungen halten sich die Release Notes noch sehr bedeckt, diese werden im Tagesverlauf für die stabile Version freigegeben.

  • USBImager als Alternative zu Etcher

    USBImager als Alternative zu Etcher

    Es gibt unter Linux viele Wege, um ein Abbild bootfähig auf einen USB-Stick oder eine SD-Card zu legen. Auf der Kommandozeile ist das Werkzeug der Wahl dd, was für disk dump steht und Festplatten, Partitionen oder Dateien Bit für Bit unterhalb der Dateisystemebene ausliest und schreibt. Wer dd nutzt, sollte sicher sein, das richtige Device zu verwenden, denn ist dd einmal gestartet, wird das Ziel gnadenlos ohne Rückfrage überschrieben.

    In den letzten Jahren sind zur Erstellung bootfähiger USB-Stick einige grafische Tools in Mode gekommen. Einige Distributionen bieten eigene Tools an, andere sind unabhängig von Distribution oder Betriebssystem. Für Windows steht seit 10 Jahren Rufus bereit, breiter aufgestellt ist das für Linux, macOS und Windows verfügbare balenaEtcher, kurz Etcher, das Anfängern unter Linux gerne empfohlen wird. Etcher lässt sich sowohl grafisch als auch per CLI bedienen.

    Etcher basiert auf Electron

    Gegenüber dd haben diese Tools den Vorteil, dass sie Fehlbedienungen zu verhindern suchen. Um Datenverlust zu vermeiden, zeigt Etcher Partitionen, die über die übliche Größe von USB-Sticks hinausgehen, als großen Datenträger an. Der entscheidende Nachteil von Etcher ist die Verwendung des Electron-Frameworks und die daraus resultierende Größe der als AppImage ausgelieferten Anwendung von über 90 MByte. Zudem wird seit einiger Zeit während des Schreibens Werbung eingeblendet.

    Minimale Lösung

    Dass das auch besser geht, beweist das seit einem Jahr entwickelte minimalistische grafische Open-Source-Tool USBImager, das ebenfalls für Linux, macOS und Windows sowie für die ARM-Plattform verfügbar ist und als .deb gerade mal 180 KByte auf die Waage bringt. Dabei bietet es sogar mehr Funktionen als Etcher.

    Neben den Binärdateien und dem Quellcode auf GitLab ist USBImager lediglich im AUR von Arch Linux zu finden. Beim Download direkt aus dem Repo ist zwischen Versionen, die nur schreiben und solchen, die auch lesen können zu unterscheiden. Letztere bieten zusätzlich die Möglichkeit, das Ergebnis nach dem Schreibvorgang zu verifizieren sowie das Erstellen von Sicherungen. Der Download als Zip-Archiv anstatt der Binärdatei erlaubt die Verwendung der ausführbaren Datei auch ohne Installation und damit ohne Systemintegration.

    USBImager bei der Arbeit

    Images lesen und Schreiben

    Die GUI ist einfach gehalten und bietet Auswahlfelder für das zu schreibende Abbild, das Device und die Puffergröße. Zudem kann angehakt werden, dass das Ergebnis überprüft wird. Ein weiterer Klick sorgt für eine weitere Kompression. Das Tool versucht durch Ausblenden größerer Partitionen zu verhindern, dass bei falscher Auswahl des Ziels die Systemplatte überschrieben wird. Alle Laufwerke werden beim Start auf der Kommandozeile mit dem Parameter -a angezeigt. Für ein rund 3 GByte großes Abbild inklusive Überprüfung braucht USBImager knapp 4 Minuten.

    Mehr Funktionen als Etcher

    USBImager kann mit den Formaten .img, .bin, .raw und .iso umgehen und kann komprimierte Abbilder wie .zip, .zzz, .tar, .cpio und .pax on-the-fly lesen. Es können über den Schalter Lesen komprimierte Backups roh oder im ZStandard-Format erstellt werden. Die resultierenden Dateien werden auf dem Desktop mit der Endung .dd abgelegt. Wird gleichzeitig komprimiert, lautet die Endung .dd.zst. Zudem können Abbilder über die serielle Schnittstelle an Mikrocontroller geschickt werden. Wie diese und weitere Optionen funktionieren, zeigt ein ausführliches Handbuch (PDF).

  • antiX-21 »Grup Yorum« veröffentlicht

    antiX ist eine kleine Distribution aus dem Umfeld der MEPIS-Community, aus dem auch MX Linux stammt. Auf antiX-19.4 vom April folgt nun antiX-21 mit dem Codenamen »Grup Yorum«, der für eine türkische Band steht, die seit 1985 politisch motivierte Songtexte verwendet.

    antiX-21 basiert auf Debian 11 »Bullseye«, verzichtet aber auf Systemd, verwendet eudev statt udev und bietet SysVinit oder runit als Init-Systeme. Die Distribution wird in 32- und 64-Bit in den Varianten antiX-full, antiX-base, antiX-core und antiX-net angeboten.

    Vier Fenstermanager

    antiX-full und antiX-base werden mit den vier Fenstermanagern IceWM, Fluxbox, JWM und HerbstluftWM ausgeliefert. Die antiX-full-x64-Version bietet Linux 4.9 und 5.10 als Kernel. Die beiden kleineren Varianten werden ohne X-Server ausgeliefert und bieten im Gegensatz zu den beiden größeren Varianten keine Verschlüsselung.

    Große Auswahl an Tools

    Bei antiX-full sind LibreOffice 7.0.4-4 und Firefox-ESR 78.14 vorinstalliert. Bei antiX-base kommt Seamonkey 2.53 zum Einsatz. Für E-Mails steht Claws-Mail 3.17.8 bereit. Hinzu kommt eine große Auswahl an Anwendungen aus allen Sparten, oft mehrere Anwendungen für einen Zweck. Diese kann man entweder im Menü finden oder über die Anwendung App Select direkt anspringen und starten, indem man dort einen Suchbegriff wie Office oder Video eingibt.

    Vorinstalliert sind unter anderem Pakete wie die Dateimanager zzzFM und rox-filer, Conman und gnome-ppp fürs Netzwerk, die Editoren Geany. Leafpad und Midnight Commander sowie Tools zum Remastern und für Snapshots. Hinzu kommen eine Anzahl hauseigener Tools.

    antiX Installer

    Hausgemachter Installer

    Der Installer von antiX ist hausgemacht und erlaubt vor dem Abschluss der Installation die Auswahl der zu startenden Dienste. Der einzige Fehler, der auffiel war, dass die Tastaturbelegung nicht übernommen wurde. Das war aber im Control Centre schnell korrigiert.

    Die Entwickler empfehlen mindestens 256 MByte RAM und zum Installieren eine Mindestfestplattengröße von rund 3 GByte. Nach dem Start belegt das System mit antiX-full knapp unter 150 MByte RAM. Die Installation gelingt auch auf einem USB-Stick mit oder ohne permanente Datenspeicherung.

  • Vom Rest das Beste – Woche 43

    Vom Rest das Beste – Woche 43

    Woche 43 war für mich eine gute Woche, denn nach vier Jahren und einigen Tagen kam das Librem 5 bei mir an. Ich hege keinerlei Groll gegen Purism, ich finde, sie haben eine Herkulesaufgabe bravourös gestemmt. Das es dabei zu Problemen und Verspätungen kommt, war zu erwarten. Bisher kann ich sagen, dass die Build-Qualität hervorragend ist und dem Preis gerecht wird.

    Das mit dem Herkules kann man auch vom Projekt Muen sagen, das nach acht Jahren Entwicklung Version 1.0 erreicht hat. Bei Muen handelt es sich um einen sogenannten Separation Kernel, der für den Einsatz in unternehmenskritischen Umgebungen gedacht ist, die ein hohes Maß an Zuverlässigkeit und Ausfallsicherheit erfordern. Und wo wir schon bei Kerneln sind: Linux 5.15 erscheint vermutlich heute oder aber am kommenden Sonntag.

    Distributionen

    Die Linux-Distributoren haben sich vergangene Woche etwas zurückgehalten. Zu vermelden sind Veröffentlichungen von Nitrux 1.7, das ohne Systemd, aber mit einer eigenen Variante des Plasma-Desktops in Version 5.23 daherkommt sowie von Trisquel 9.0.1 »Etonia«, einer von Ubuntu abgeleiteten Linux-Distribution mit dem Ziel, ausschließlich freie Software auszuliefern. Absolute Linux basiert auch in der neuesten Ausgabe auf Slackware und will als leichtgewichtige Distribution unter anderem ältere 64-Bit-Hardware unterstützen.

    Eine Beta-Version zum Testen hat Elive für Version 3.8.24 freigegeben. NuTyX 21.10.0 wird auf der Basis von Linux from Scratch gebaut und ist weiterhin auch für 32-Bit verfügbar. Yocto 3.4 »Honister« ist ein Projekt der Linux Foundation zum Erstellen von Distributionen für den Embedded-Bereich. Bei Interesse gibt es weiterführende Informationen zu diesem Quasi-Standard. Das Anfang 2020 von FreeBSD zu Void Linux als Grundlage gewechselte Project Trident wird leider eingestellt. Die Entwickler geben in der Ankündigung der Einstellung an, die Ereignisse der letzten beiden Jahre haben die Prioritäten im Leben der Entwickler so verändert, dass es geboten erscheine, das Projekt einzustellen. Die Repositories bleiben bis zum März 2022 online.

    Tools und Anwendungen

    Bei den Tools gab es einige Neuerscheinungen. Darunter sind unter anderem snort 3.1.15, gawk 5.11, mesa 21.2.5, cmake 3.21.4, bind 9.16.22 und samba 4.15.1. Qt erschien als 6.2.1, Calibre als 5.31.1, xmonad erreicht Version 0.17.0. Auf Stefans Weblog entdeckte ich interessante Informationen über Tiling für Plasma Desktops im Projekt Mudeer.

    Lesestoff

    Für viele von uns ist morgen Feiertag, deshalb hier einige zusätzliche Links zu vielleicht interessanten Artikeln. Wie entsteht ein Promo-Video? Wer das schon immer mal wissen wollte, kann dies am Beispiel des PinePhone Pro nachlesen. Besitzer des original PinePhone können bei Marius bloggt nachlesen, wie sie unter Umständen die GPS-Leistung ihres Linux Phones verbessern können.

    Und da wir schon bei den mobilen Begleitern sind, möchte ich euch meine erste Amtshandlung auf dem Librem 5 nicht vorenthalten 🙂

    Aber weiter im Lesestoff. Wer sein Wissen über Debians Paket-Tool APT überprüfen möchte, kann dies anhand dieses gut recherchierten Artikels tun. Kyle Rankin beschreibt in einem neuen Essay, wie Purism Freie Software unterstützt und finanziert. Angela Merkel kommt nicht sonderlich gut weg, wenn es um die Netzpolitik während ihrer Kanzlerschaft geht. War halt alles Neuland.

    In der kommenden Woche erwarten uns unter anderem die Veröffentlichungen von Fedora 35 und Firefox 94. Ich wünsche eine gute Woche und bitte bleibt gesund!

  • Debians Diskussion über »which«

    Debians Diskussion über »which«

    Which way?

    Das Shell-Script which ist ein nicht standardisiertes, externes Werkzeug, das eine ausführbare Datei im gegebenen PATH findet. Es gibt verschiedene Varianten von which in Linux und BSD, die sich bei den verfügbaren Optionen unterscheiden. Ich verwende die bei Debian im Paket debianutils enthaltene Version oft, um zu sehen, ob ein Paket auf einer Installation vorhanden ist. Kurz und schmerzlos sah das bis vor kurzem so aus:

    $ which apt
/usr/bin/apt

    Wer which in den letzten Monaten in Debian Sid genutzt hat, bekam aber zusätzlich eine Warnung zu sehen:

    $ which apt
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
/usr/bin/apt

    Wie es dazu kam und was daraus wurde, zeigt exemplarisch, wie Debian sich selbst reguliert.

    Entzündet hat sich die Diskussion im letzten Jahr an der Option -s, die bei FreeBSD vorhanden ist, bei der Debian-Version jedoch nicht. Entwickler Erik Gustafsson hielt dieses Flag, das die Druckausgabe unterdrückt und den Exit-Status abhängig von der Existenz des abgefragten Programms setzt, für so nützlich, dass er gleich einen Patch mitlieferte.

    Nicht POSIX-konform

    Damit setzte eine Diskussion über den Wert des nicht POSIX-konformen which und ob es in Debian erweitert werden sollte. Im Verlauf der Diskussion wurde Clint Adams, Co-Maintainer der debianutils auf die Diskussion aufmerksam und befand, eigentlich sollte which aus dem essenziellen Paket debianutils entfernt werden, da mit command -v eine POSIX-konforme Alternative bereits vorhanden sei. Ich muss gestehen, ich habe von command -v nie zuvor gehört, und ich denke, ich bin damit nicht alleine.

    Vor einigen Monaten fiel einem Entwickler die oben erwähnte Warnung auf, die mit debianutils 5.0.1 eingeführt worden war und which als deprecated (überholt) bezeichnete. Dies führte zu zahlreichen Anfragen nach einer Rückgängigmachung der Änderung. Einer der Gründe war, dass which als Begriff wesentlich griffiger sei als die Alternativen. Zudem sei es im Muskelgedächtnis vieler Anwender vorhanden. zudem stellte sich heraus, dass eine Reihe von Build-Skripten für Debian-Pakete ebenfalls which verwenden.

    Mehr Schaden als Nutzen

    Adams Position in der Sache wurde schwächer, obwohl sein Argument, dass es zahlreiche Varianten von which gibt und es somit wenig Sinn ergebe, eine bestimmte Version in einem Paket auszuliefern, das als essenziell gekennzeichnet ist und damit auf jedem Debian-System installiert sein muss, eigentlich stichhaltig ist. Die meisten Entwickler waren nicht gegen die Entfernung von which aus den debianutils, es bestand aber keine Einigkeit, wie das geschehen sollte, ohne größere Disruptionen zu erzeugen.

    Das Technische Komitee eingeschaltet

    Da zumindest ein Paket (tensorflow) beim Bau an der eingefügten Warnung scheiterte und keine Einigung über das Vorgehen in Sicht war, schaltete Adrian Bunk das Technische Komitee ein, die Sache zu entscheiden. Seine Hauptforderungen waren, dass which weiterhin von einem essenziellen Paket bereitgestellt werden solle und die Warnung zu entfernen sei.

    This sort of whichcraft is how Debian has managed to keep hundreds of independent-minded developers working toward a common goal for the better part of three decades.

    Jonathan Corbet, Editor at LWN

    Mitte Oktober gab das Komitee nun seine Entscheidung bekannt. Einigkeit bestand darin, dass debianutils weiterhin which bereitstellen muss, zumindest so lange, bis es in ein anderes essenzielles Paket überführt wurde. Eine Mehrheit der Komitee-Mitglieder beschloss zudem, die Warnung zu entfernen. Viele Leser mögen dies für verschwendete Zeit über Nichtigkeiten halten, aber dieses Vorgehen ist ein wichtiger Teil der Art und Weise wie Debian sich selbst reguliert. Paket-Maintainer haben bei Debian viel Macht über die von ihnen betreuten Pakete und manchmal schießt jemand über das Ziel hinaus. Dann gibt es Regularien, das wieder einzufangen, mit denen Debian fast 30 Jahre lang gut gefahren ist.

    Als Quelle für diesen Artikel diente der Artikel Debian’s which hunt auf LWN, der derzeit noch hinter der Paywall steht.

  • Blender Foundation stellt Blender Roadmap 3.x vor

    Blender 3.0 Beta | Bildquelle: Blender

    Blender 2.0 wurde im August 2000 veröffentlicht. Die Anforderungen an die Veröffentlichung von Software haben sich seitdem stark verändert. Um dem Rechnung zu tragen, hat die Blender Foundation in einer neuen Roadmap für Blender 3.x sowohl die Kadenz als auch die Versionierung künftiger Veröffentlichungen angepasst.

    Blender 3.0 im Dezember

    Die Veröffentlichung von Blender 3.0, die ursprünglich für August vorgesehen war, wurde zunächst auf Oktober und zuletzt auf Dezember verschoben. Die vom Vorsitzenden der Blender Foundation, Ton Roosendaal, vorgeschlagene zweite Verschiebung wurde vorgenommen, um persönliche Workshops mit den wichtigsten Mitwirkenden zu ermöglichen, sofern die Reisebeschränkungen für die Pandemie es erlauben.

    LTS, Zyklus und Versionierung

    Bereits im Juni 2020 war mit Blender 2.83 die erste für zwei Jahre unterstützte LTS-Ausgabe der freien 3D-Modelling- und Rendering-Software erschienen, im Juni 2021 folgte mit Blender 2.93 eine weitere. Künftig soll jedes Jahr eine derart unterstützte LTS-Version erschienen. Das Veröffentlichungsmodell soll zudem dahin gehend abgeändert werden, dass alle zwei Jahre eine neue Hauptversion veröffentlicht wird. Auf Blender 3.x im Dezember 2021 soll also Ende 2023 bereits Blender 4.0 folgen. Im Abstand von drei Monaten sollen Point Releases Sicherheits-Patches sowie Fehlerbereinigungen bringen, ohne die Kompatibilität zu gefährden. Von diesen soll eines pro Jahr zur LTS-Version erklärt werden.

    Änderungen beim Core und den Modulen

    Die Roadmap geht des Weiteren auf die zu erwartenden Änderungen beim Core und den einzelnen Modulen ein. Das Kernmodul soll dazu befähigt werden, Code-Standards und technische Praktiken überall im Blender-Code strenger zu verwalten als bisher. Alles, was die Kernfunktionalität von Blender betrifft, wie z.B. ID-Management, Blender-Dateien, DNA-Daten-Design, Python-API, Undo, Dependency Graph, Overrides und APIs im Allgemeinen soll gute Spezifikationen und funktionale Dokumentationen erhalten, damit die Mitwirkenden wissen, wie sie es effizient nutzen können. Änderungen bei den weiteren Modulen, Scripten und Add-ons sind in der Roadmap ausführlich beschrieben.

  • Raspberry Pi Zero 2 W vorgestellt

    Bildquelle: raspberrypi.com

    Die Raspberry Pi Foundation lässt auf die mit rund vier Millionen verkauften Einheiten in sechs Jahren sehr erfolgreichen Platinen Raspberry Pi Zero und Raspberry Pi Zero W jetzt den Raspberry Pi Zero 2 W folgen. War das erste Modell ohne WLAN für 5 und mit für 10 USD zu haben, erhöht sich der Preis beim Nachfolger auf 15 USD.

    Neuer SoC

    Der Raspberry Pi Zero 2 W verwendet denselben Broadcom BCM2710A1 SoC-Chip wie die erste Ausgabe des Raspberry Pi 3, wobei die ARM-Kerne leicht auf 1 GHz heruntergetaktet sind und zusammen mit 512 MByte LPDDR2-SDRAM und weiteren Komponenten in einem eigenen platzsparenden Gehäuse untergebracht sind. Der genaue Leistungszuwachs gegenüber dem ersten Zero variiert je nach Arbeitslast, aber beim Multi-Thread-Sysbench ist er laut der Ankündigung rund fünfmal schneller.

    Die Spezifikation des Raspberry Pi Zero 2 W bietet:

    • Broadcom BCM2710A1, quad-core 64-bit SoC (Arm Cortex-A53 @ 1GHz)
    • 512MB LPDDR2 SDRAM
    • 2.4GHz IEEE 802.11b/g/n wireless LAN, Bluetooth 4.2, BLE
    • 1 × USB 2.0 Interface mit OTG
    • HAT-kompatibles 40 pin I/O Header Layout
    • MicroSD card slot
    • Mini HDMI port
    • Micro USB Power
    • Micro USB 2.0
    • CSI-2 camera connector
    • H.264, MPEG-4 decode (1080p30); H.264 encode (1080p30)
    • OpenGL ES 1.1, 2.0 Grafik

    USB-Netzteil

    Die Dimensionen bleiben mit 65mm x 30mm die gleichen wie beim Vorgänger, sodass viele alte Gehäuse inklusive des offiziellen Gehäuses für den Zero für das neue Modell weiter passen. Zeitgleich hat die Raspberry Pi Foundation ein neues offizielles USB-Netzteil für das neue Modell sowie für den Raspberry Pi 3B und 3B+ vorgestellt. Es verfügt über einen USB-Micro-B-Anschluss, eine leicht reduzierte Spitzenstromstärke von 2,5 A und kostet 8 USD.

    Anwendungsgebiet

    Obwohl der Raspberry Pi Zero 2 W teils die fünffache Leistung seines Vorgängers bietet, ist die Platine nicht für einen performanten Desktop-Einsatz geeignet. Die Beschränkung auf 512 MByte RAM ist hier der limitierende Faktor, hier sollten Anwender weiterhin zum RasPi 4 greifen. Kleinere Projekte, die mit HATs arbeiten, eignen sich jedoch hervorragend für die neue Platine.

    Der Raspberry Pi Zero 2 W kann ab sofort etwa bei BerryBase oder bei Reichelt bestellt werden. Interessenten sollten sich schnell entscheiden, denn wegen der Versorgungskrise bei Halbleitern sind für dieses Jahr nur 200.000 und bis Ende Q2/2022 weitere 250.000 Einheiten zur Auslieferung vorgesehen.

  • X.org Server 21.1.0 stabil freigegeben

    X.org-Server 21.1.0
    Logo von X11 | Lizenz: CC BY-SA 3.0

    Nach X.org Server 1.20 von 2018 ist der jetzt freigegebene X.org Server 21.1.0 die erste stabile Veröffentlichung. Seit Wayland immer mehr in den Vordergrund tritt, sinkt das Interesse an und die Bereitschaft zur Veröffentlichung von X.org. Es erwies sich lange als schwierig, einen Release-Manager für eine neue Veröffentlichung zu finden.

    Unabhängiger Entwickler

    Vor einigen Monaten begann dann der unabhängige litauische Entwickler Povilas Kanapickas, ein Release vorzubereiten und gab Anfang Juni einen Entwicklungs-Snapshot mit veränderter Versionierung als xorg-server 21.0.99.1 frei. Darauf folgte im September ein erster Release Candidate. Ein zweiter RC folgte, der jetzt vorliegende X.org Server 21.1.0 weist lediglich nur noch eine Änderung zu RC2 aus, wie Kanapickas in der Ankündigung schreibt. Sollten durch die weitere Verbreitung der stabilen Version bisher unentdeckte Fehler auftauchen, will Kanapickas diese schnell mit 21.1.1 beheben anstatt im üblichen Intervall von einigen Monaten.

    Ohne XWayland

    X.org Server 21.1.0 ist das erste Release, das ohne XWayland ausgeliefert wird, welches vor einiger Zeit wegen der Verzögerungen bei der Veröffentlichung von X.org ausgegliedert und als separates Paket veröffentlicht wurde. Peter Hutterer, Entwickler von Libinput leitet diese Entwicklung in einem sehr informativen Blogpost vereinfacht her.

    Neues Build-System

    Die neue Version 21.1.0 unterstützt Meson als Build-System jetzt vollständig. Für dieses Release wird das bisher genutzte GNU Build System autotools nochmals mit ausgeliefert, anschließend aber zugunsten von Meson entfernt. Glamor erhält Unterstützung für den Framebuffer Xvfb sowie für XInput 2.4, das Touchpad-Gesten mitbringt. Zudem neu werden variable Bildwiederholraten im Modesetting-Treiber unterstützt. Der DMX DDX-Treiber von X.Org zur Unterstützung von Distributed Multi-Head X wurde entfernt, nachdem der Code bereits seit vielen Jahren nicht mehr richtig funktioniert. Der X-Server meldet zudem nun in mehr Fällen die korrekte DPI-Anzeige, was das Rendering von Client-Anwendungen auf High-DPI-Bildschirmen beeinflussen kann.

  • TrueNAS SCALE 22.02 RC1 »Angelfish« verfügbar

    TrueNAS SCALE 22.02 RC1 »Angelfish« verfügbar

    Nach der Ankündigung im Sommer 2020 und einem Jahr in der Alpha- und Beta-Phase ist der erste Release-Kandidat von TrueNAS SCALE 22.02 erscheinen. TrueNAS SCALE wird von iXsystems entwickelt und basiert auf deren Distribution TrueNAS 12. Es handelt sich bei SCALE um eine auf Debian GNU/Linux 11 basierende Open Source-Virtualisierungsplattform als Hyperkonvergente Infrastruktur (HCI), die mit KVM, ZFS und Containern umgehen kann. Für Letztere kommen Docker und Kubernetes zum Einsatz. Für die Bedienung steht ein Web-Interface bereit.

    TrueNAS SCALE kann kostenfrei auf eigener Hardware genutzt werden, steht aber auch in Kombination mit der Hardware von iXsystems bereit, etwa mit den Serien M und R sowie den Minis. SCALE steht dabei für:

    • Scale-out ZFS
    • Converged Compute and Storage
    • Active Reliability
    • Linux Containers (Kubernetes) & VMs (KVM)
    • Ease of Deployment and Operation

    Getestete Anwendungen

    Anwendungen können auf TrueNAS SCALE-Clustern entweder als KVM-VMs, Docker-Container oder Kubernetes-Pods ausgeführt werden. Es gibt jetzt Dutzende von vorgetesteten und paketierten Anwendungen, darunter Plex, Nextcloud, HomeAssistant und viele mehr. Anwendungskataloge ermöglichen Community-Beiträge wie den umfangreichen und kostenlosen Anwendungskatalog von Truecharts.org.

    Scale Out

    Die Scale-Out-Fähigkeiten erstrecken sich sowohl auf Datei- (SMB-Cluster, Glusterfs) als auch auf Objektspeicher wie S3 mit Minio und zwingen die Benutzer nicht dazu, sich zwischen Datei- und Objektspeicher zu entscheiden. Nach 12 Monaten Entwicklung und Tests mit rund 4.000 Anwendern wird SCALE nun in vielen Anwendungen eingesetzt und verwaltet derzeit etwa 100 PByte. Die RC-Phase ist der Beginn eines breiteren Einsatzes, der mit der Bereitstellung weiterer Updates wachsen wird.

    Die Hardwareanforderungen verlangen 8 GByte RAM, ein 16 GByte SSD Boot-Device sowie zwei gleich große Speichermedien. In den Release Notes sind die Änderungen zu TrueNAS SCALE 22.02 RC1 verzeichnet. Neben TrueNAS Core betreut iXsystems die Distributionen TrueNAS Core und TrueNAS Enterprise.

  • Warum funktionieren nicht alle Fingerabdrucksensoren unter Linux?

    Warum funktionieren nicht alle Fingerabdrucksensoren unter Linux?

    Im Rahmen der Reihe mit Interviews mit deutschsprachigen Entwicklern habe ich Werner Sembach, Entwickler bei Tuxedo Computers ein paar Fragen gestellt. Anlass war meine News zur demnächst verfügbaren Unterstützung für Fingerprint Reader in KDE Plasma 5.24. Ich fragte mich, warum der Sensor an meinem Tuxedo Aura 15 unter Linux noch immer nicht funktioniert. Kollegen berichten ähnliches von anderen Notebooks verschiedener Hersteller. Da ich weiß, dass Werner sich mit dem Thema beschäftigt hat, hier meine Fragen an ihn:

    LN: Als ich vor rund einem Jahr ein TUXEDO Aura 15 Notebook kaufte, war der Treiber für den Fingerabdrucksensor noch in Arbeit. Wie ist denn da der aktuelle Stand?

    WS: Das Aura 15 Gen 1 hat einen ElanTech Match-On-Host Fingerprint Reader. Das Protokoll dazu wurde bereits vor einigen Jahren von Igor Filatov implementiert, aber benutzbar sind nur die breiten Swipe-Style Fingerprint Reader. Das war auch der Grund, warum bis vor kurzem der Reader das Aura 15 Gen 1 bewusst als nicht kompatibel in der libfprint geführt wurde. Inzwischen haben sich die Maintainer aber umentschieden. Problem ist, auch wenn der Reader von der aktuellen Version der libfprint jetzt erkannt wird, benutzbar ist er immer noch nicht.

    LN: Kannst Du bitte ein wenig auf die technischen Hintergründe eingehen, warum es unter Linux bei manchen Geräten so schwierig ist, den Fingerabdrucksensor zur Mitarbeit zu bewegen?

    WS: Ok, ich muss ein wenig ausholen, dann wird meine erste Antwort wahrscheinlich verständlicher. Bei Fingerprint Readern gibt es sogenannte Match-On-Host und Match-On-Device/Match-In-System Modelle. Der Unterschied ist, ob die Bilder, die der Reader macht, vom Betriebssystem (Match-On-Host) oder von der Firmware der Reader selbst (Match-On-Device/Match-In-System) ausgewertet werden. Bei Zweiterem ist der Algorithmus, der eine Aussage trifft, ob 2 Fingerabdrücke gleich sind oder nicht Teil des Firmware-BLOBs der mit dem Reader mitgeliefert wird. Nicht Open Source, aber funktioniert auf allen Betriebssystemen gleich, vorausgesetzt das Protokoll, um mit dem Reader zu sprechen, ist bekannt.

    Bei den Match-On-Host Readern bekommt das Betriebssystem nur Bilder geliefert und muss die Auswertung vollständig selbst übernehmen. Im Falle des Aura 15 Gen 1, das, wie zuvor erwähnt, ein Match-On-Host Typ Reader hat, wird ein rund 4 x 4 mm großer Ausschnitt des Fingers in einer 80 x 80 Pixel großen Auflösung aufgenommen und das bringt uns zum Kern des Problems: Es gibt einfach keinen guten Open Source Fingerprint-Matching Algorithmus.

    Für Linux-Systeme gibt es die Open-Source-Bibliothek libfprint die es Login Screens und Desktop Environments ermöglicht, Fingerprint-Reader anzusteuern. For Match-On-Host Reader benutzt sie im Backend Teile der NIST Biometric Image Software (NBIS), die ursprünglich für amerikanische Polizeibehörden entwickelt wurde, um physische Fingerabdruck-Karteikarten zu digitalisieren und die im Zuge eines Public Money – Public Code Gesetzes als Public Domain als Source Code downloadbar ist. Das letzte Release ist von 2015, war wahrscheinlich da schon leicht veraltet, geht von weitgehend vollständigen Abdrücken aus, die bei Bedarf händisch aufbereitet wurden.

    Kurz, 4 x 4 mm in 80 x 80 Pixel Auflösung sind zu wenig und der Algorithmus versagt mit einer nahezu 100% false negative Rate. Die libfprint Implementierung versucht das noch zu verbessern, indem auch bei diesem „One Touch“ Reader ein Swipe des Fingers verlangt wird: Dann ist der Ausschnitt zwar weiterhin nur 4 mm breit aber hat immerhin die volle Höhe. Aber auch das reicht nicht aus, um ein zuverlässiges Ergebnis zu bekommen. Und dann gibt es noch Fingerprint Reader bei denen einfach das Protokoll nicht in der libfprint implementiert ist. In der Regel, weil es einfach noch nicht bekannt ist und sich noch niemand daran gesetzt hat es herauszufinden.

    LN: Was muss geschehen, damit es im Fall des Aura 15 und weiterer Geräte mit Fingerabdrucksensor vorwärtsgeht?

    WS: Für das Aura 15 Gen1 bräuchte es jemanden, der sich mit Biometrischer Mustererkennung und/oder mit Machine Learning auskennt, um die NBIS Algorithmen zu verbessern oder durch etwas Besseres zu ersetzen. Bisherige Ansätze waren eher auf semi-erfolgreicher Ausprobier-Ebene:

    Die zwei großen Blocker sind diese Issues:

    • https://gitlab.freedesktop.org/libfprint/libfprint/-/issues/271
    • https://gitlab.freedesktop.org/libfprint/libfprint/-/issues/272

    Ruhm und Ehre demjenigen der als erster eine gute Lösung findet 😉. Aber Spaß beiseite, das fprint Project hat gute Arbeit geleistet und aus persönlicher Erfahrung kann ich sagen, das es nette Maintainer hat, die für alle Vorschläge offen sind und vielleicht findet sich ja unter den Lesern hier jemand, der helfen kann. Tuxedo Computers will, um die Nutzbarkeit von verbauten Fingerprint Readern zu gewährleisten, künftig nach Personal und Mitstreitern aus der Community suchen. Vom dort erstellten Open-Source-Code können unter Umständen auch andere Projekte profitieren.

    Danke an Werner Sembach für die ausführliche Darlegung des komplexen Sachverhalts.