CleanPress

Kategorie: Artikel

  • Linux 2021 – das Jahr im Rückblick

    Linux 2021 – das Jahr im Rückblick

    Das Jahr 2021 ist zu Ende. Es wird in die Geschichte eingehen als das zweite Jahr der ersten Pandemie des 21. Jahrhunderts. Noch ist kein Ende in Sicht und das beste, was wir erhoffen dürfen ist eine endemische Situation. Doch selbst dann bleiben die Folgen noch lange spürbar.

    Linux in der Pandemie

    Die Auswirkungen der anhaltenden Chipkrise und vielerorts zusammengebrochener Lieferketten werden uns noch über Jahre begleiten und haben auch die Nische Linux Hardware fest im Griff. Hersteller wie Pine64 oder Purism haben Probleme, die Komponenten ihrer Linux-Hardware einzukaufen. Purism hat daraufhin kürzlich beschlossen, ihre bis dahin praktizierte »Just-in-time«-Produktion auf eine Lagerhaltung umzustellen, die es erlaubt, solche Lieferengpässe aufzufangen.

    Entwickler isoliert

    Des Weiteren ist die Linux-Szene durch den Wegfall der persönlichen Treffen der Linux-Entwicklergemeinde durch die Pandemie betroffen. Die jährlichen Treffen auf Konferenzen wie FOSDEM, Chemnitzer Linuxtage, DebConf und viele andere erleben 2022 vermutlich zum dritten Mal die Austragung als reine Online-Konferenzen. Darunter leiden die sozialen Kontakte der Entwickler untereinander, die den größten Teil des Jahres online im IRC oder Plattformen wie Matrix, GitHub oder Slack zusammen arbeiten und nur auf den Konferenzen ihre sozialen Kontakte untereinander pflegen und neue knüpfen.

    Geburtstag

    Linux feierte 2021 seinen 30. Geburtstag. Das genaue Datum unterscheidet sich, je nachdem, ob als Geburtstag die Ankündigung oder die erste Veröffentlichung am 17. September angenommen wird. Am 25. August 1991 gab Linus Torvalds jedenfalls im Usenet bekannt, dass er an einem Betriebssystemkern arbeite. Im gleichen Atemzug gab er eine der wohl größten Fehleinschätzungen in der IT-Geschichte ab, vergleichbar mit Bill Gates Aussage, dass niemand jemals mehr als 640 KB Arbeitsspeicher brauchen würde (falls er das je wirklich gesagt hat). Torvalds sagte damals:

    I’m doing a (free) operating system (just a hobby, won’t be big and
    professional like gnu) for 386(486) AT clones.

    Linus Torvalds, 25.8.1991

    Mobiles Linux

    Wir alle wissen, wie sehr er sich damit geirrt hat. Allerdings zu behaupten, Linux wäre im Mobilmarkt angekommen ist wahrscheinlich zu hoch gegriffen, denn dazu sind die vorhandenen Geräte bei Hard- und Software noch zu sehr im Experimentierstadium. Ein beachtenswerter Neuzugang in der Nische in diesem Jahr ist das JingPad A1, ein chinesisches Linux-Tablet, das mit dem dazugehörigen JingOS Apples iPad OS nacheifert. Ich habe das JingPad hier liegen, ebenso wie das Librem 5 und bin bei beiden noch nicht dazu gekommen, sie mir näher anzuschauen. Über das JingPad hat ein Leser dankenswerterweise einen ausführlichen Artikel verfasst.

    Trends 2021

    Für mich sind vorrangig zwei sich ergänzende Trends zu erkennen. Red Hat strebt mit RHEL ein unveränderliches Dateisystem an, dessen Standard-Paketbestand hauptsächlich aus Flatpaks besteht. Zunächst wird dieses neue Mantra vielleicht schon im kommenden Jahr bei Fedora Workstation nach dem Vorbild von Fedora Silverblue umgesetzt. Mit Fedora 35 erschien im Herbst Kinoite als Pendant auf der Basis von KDE Plasma. Es wird spannend zu sehen, welche Nachahmer es für diesen Trend geben wird.

    Ein weiterer Trend aus der gleichen Ecke will Fedora den zwar coolen, aber der weiteren Verbreitung nicht unbedingt förderlichen Nimbus einer Distribution für Entwickler nehmen und mehr auf den generellen Desktop-Markt und sogar auf Gamer abzielen. Und wo wir schon bei Red Hat sind. Aufgrund der Entscheidung, CentOS in der bisherigen Form in Rente zu schicken, hat das Unternehmen zur Entwicklung von mindestens zwei neuen Distributionen beigetragen. die die Nachfolge von CentOS für sich beanspruchen. Es handelt sich dabei um AlmaLinux und Rocky Linux, die beide bereits mehrere Veröffentlichungen hinter sich haben.

    Arch Linux hat im vergangenen Jahr ebenfalls einen Schritt in Richtung mehr Zugänglichkeit getan, mit dem nicht unbedingt zu rechnen war. Das Projekt hat mit einem offiziellen Installer-Script namens archinstall das Aufsetzen der Distribution wesentlich vereinfacht. Der neue Installer, der seit April in den Abbildern von Arch Linux verfügbar ist, arbeitet auf Textbasis und führt den Anwender durch die Installation.

    Gaming

    Gaming unter Linux liegt seit Jahren im Trend und wird dabei maßgeblich von der Firma Valve und deren Steam-Plattform gefördert. Am 15. Juli stellte Valve in diesem Zusammenhang die Handheld-Konsole Steam Deck vor, deren Auslieferung im Februar 2022 anlaufen soll. Was das mit Linux zu tun hat? Nun, als Betriebssystem läuft ein SteamOS, das auf Arch Linux basiert. Das könnte bedeuten, dass für Steam Deck freigegebene Spiele auch auf dem Linux-Desktop laufen. Zumindest ist das meine Einschätzung, die nicht von irgendwelchem Wissen über Gaming getrübt ist. Warten wir es also ab.

    Aufgewertet

    Im Rahmen der Modernisierung der Kernel-Entwicklung sieht ein Anachronismus seinem Ende entgegen: der Pflicht, für Einreichungen zum Kernel einen E-Mail-Client, -Dienst oder -Gateway starten zu müssen. Im Juni stellte Kernel-Entwickler Konstantin Ryabitsev seine Arbeit an einem Bot namens github-pr-to-ml vor, das auf GitHub Pull Requests überwachen und in vollständige Patch-Reihen umwandeln kann. Zudem arbeitet er in diesem Zusammenhang weiter an b4.

    Das GNOME-Projekt hat mit GNOME 40 im März eine tiefgreifende Änderung des Bedienschemas eingeführt. Dabei wurde die Bedienung von einer bisher vertikalen zu einer horizontal ausgerichteten Bedienung geändert und rückt die bisher eher am rechten Rand klebenden Workspaces mittig in den Fokus. Diese Änderung des Bedienschemas ist hauptsächlich der Umsetzung einer besseren Bedienbarkeit auf Touchscreens geschuldet.

    Gleichzeitig wurde auch die Versionierung vereinfacht. GNOME 40 hätte eigentlich 3.40 heißen sollen. Die Vorabversionen heißen künftig beispielsweise 42.alpha, 42.beta und 42.rc. Die Wartungs-Releases von GNOME 42 werden als 42.1, 42.2 usw. veröffentlicht. An dieses wichtige Release knüpft im nächsten Frühjahr GNOME 42 an, das die Integration von GTK 4 größtenteils umsetzt und dazu mit libadwaita den Nachfolger von libhandy einsetzt

    KDE Plasma hat zumindest genauso viel Weiterentwicklung erfahren, allerdings eher als kontinuierliche Verbesserung und ohne große Brüche wie bei GNOME. Derzeit wird der Umstieg auf Qt6 vorbereitet, was aber nach Aussagen der Entwickler nicht als Bruch wahrnehmbar sein wird. Wo es bei Plasma noch hapert, ist Wayland, der Stand von GNOME ist noch nicht erreicht. Fedora 35 prescht hier mit dem KDE-Spin vor, der Wayland standardmäßig nutzt.

    Andere Desktops wie Xfce unterstützen Wayland bisher noch gar nicht. Daran wird sich auch mit dem anstehenden Xfce 4.18 nicht viel ändern, initiale Unterstützung ist jedoch geplant. Längerfristig ist ein Umstieg von Xfwm auf Mutter als Fenstermanager geplant. Hier können Synergien genutzt werden, denn Olivier Fourdan, Schöpfer der Xfce-Desktop-Umgebung und mithin Autor von Xfwm, arbeitet mittlerweile für Red Hat unter anderem an Wayland und Mutter.

    Diskussionsstoff

    Neben Red Hats Entscheidung, CentOS in Rente zu schicken gab es noch andere Themen, die für Aufregung sorgten. Debian diskutierte gleich im Januar über den Umgang mit Non-Free-Firmware. Es ging darum, Abbilder der Distribution mit für aktuelle Hardware benötigter unfreier Firmware für Neueinsteiger besser zugänglich zu machen. Kontrovers diskutiert wurde im März die Rückkehr von Richard M. Stallman in den Vorstand der FSF.

    Im März und April wurde Audacity zum Aufreger. Das Open Source-Tool zur Audiobearbeitung wurde von der Muse Group übernommen. Kurz darauf wurde die Einführung von per Google Analytics erhobener Telemetrie angekündigt, was einen ersten Fork der Software bewirkte. Es gab erhitzte Diskussionen auf verschiedenen Plattformen, woraufhin Muse Group einen Rückzieher machte, um die Pläne zu überarbeiten. Im Juli wurden dann mit einer neuen Datenschutzrichtlinie etwaige noch verbliebene Sympathien verspielt. Hier redete man sich als Reaktion auf den Sturm der Entrüstung mit »unklarer Formulierung« heraus. Wer danach den Glauben an eine wohlmeinende Muse Group verloren hat, kann sich den Fork Tenacity anschauen.

    Im August gab es Aufregung um Beiträge zum Kernel von der University of Minnesota. Studierende hatten für ein Forschungsprojekt vorsätzlich fehlerhafte Patches, die teilweise eine Sicherheitsgefährdung darstellten, an die Kernel-Mailingliste geschickt, um die Sicherheit von FLOSS Projekten und hier im Speziellen die des Kernels zu testen. Selbst Greg Kroah-Hartman, üblicherweise ein Meister der leisen Töne, fand dafür harsche Worte und sperrte alle Einreichungen der @umn.edu-Domain und somit die gesamte University of Minnesota von der Kernel-Entwicklung aus.

    Auch Google trug wieder sein Scherflein zu den Aufregern des Jahres bei. Mit Federated Learning of Cohorts (FLoC) stellte der Suchmaschinen-Riese damit ein Konzept zum verträglichen Tracking der Anwender des Chrome-Browsers zu Werbezwecken vor. In der Folge erklärten viele Unternehmen und Organisationen FLoC zum Sicherheitsrisiko und lehnten die Verwendung ab.

    Im April und Mai schoss der neue Besitzer des IRC-Netzwerks Freenode, Andrew Lee sich und seine Neuerwerbung völlig ins Abseits, womit eins der ältesten IRC-Netzwerke zur Bedeutungslosigkeit verkommt und die meisten Projekte zum neu gegründeten Netzwerk Libera.Chat oder zu OFTC gewechselt sind.

    Im Juli war GitHub an der Reihe. Die Einführung von Copilot, einem Tool für künstliche Intelligenz, das Entwickler mit automatischer Vervollständigung von Code aus dem riesigen GitHub-Fundus unterstützen soll. Die FSF sah sich angesichts drohender Lizenzprobleme zu einem Aufruf zum Erstellen von White Papers veranlasst.

    Was stach heraus?

    Die für mich wichtigste Veröffentlichung einer Distribution im vergangenen Jahres ist eindeutig Fedora 35. Bei Anwendungen stehen mehrere Projekte auf den vorderen Plätzen: die lange aufgeschobene Veröffentlichung von Xorg-Server 21.1 samt der bereits vorher vorgenommenen Ausgliederung von XWayland als eigenständiges Paket stehen der Einführung von PipeWire in ersten Distributionen in nichts nach.

    Hat 2021 Linux nach vorne gebracht? Für mich persönlich kann ich das mit einem klaren Ja beantworten. Für mich war 2021 schon wieder mal das Jahr für Linux auf dem Desktop. Die Meinungen werden da je nach Anwendungsfall natürlich auseinandergehen, aber ich brauche außer Linux nichts für meinen privaten und beruflichen Bedarf. Für 2022 erwarte ich, dass Immutable Linux weiter in den Vordergrund rückt.

    Photo by Paul Carroll on Unsplash

  • Garuda Linux – jung und wild

    Screenshot:ft

    Arch Linux ist abseits des Coolness-Faktors nicht umsonst die Distribution der Wahl für viele fortgeschrittene Anwender. Die Funktionalität des Konzepts drückt sich deshalb auch in vielen Derivaten aus, die das Arch-Konzept pur oder in abgeschwächter Dosierung anbieten.

    Für mich ist EndeavourOS einer der Ableger, deren Entwicklung ich verfolge. Neu hinzugekommen in meiner Beobachtungsliste ist seit einiger Zeit auch Garuda Linux. Das ist eine auf Arch Linux basierende junge Distribution mit Ursprung in Indien, die als direktes Rolling Release ausgelegt ist und sich mit innovativen Ideen und Benutzerfreundlichkeit von der Masse abheben möchte.

    Große Auswahl

    Allein die Auswahl von 12 Desktop-Umgebungen und Window-Managern beeindruckt. Es gibt Abbilder mit KDE Plasma gleich in dreifacher Ausfertigung, Xfce, GNOME, LXQT-Kwin, den Wayland-Compositor Wayfire sowie die Window-Manager Qtile, BSPWM, i3 und Sway. Hinzu kommen Community-Ausgaben mit Cinnamon und MATE. Zusätzlich wird für erfahrene Anwender Garuda Linux Barebones KDE Edition angeboten. Ein entsprechend großes Team vorausgesetzt, ist dies ein imposantes Angebot, das kaum Wünsche offen lässt.

    Als Kernel kommt der Zen Kernel zum Einsatz, auf dem auch der vielleicht einigen hier bekannte Liquorix-Kernel basiert. Damit soll die Hardware bestmöglich angesprochen werden. Installiert wird mit dem Calamares-Framework. Das Standard-Theme hört auf den Namen Sweetified Plasma, das mit Neonfarben daherkommt, was bestimmt nicht jedermanns Sache ist. In den Systemeinstellungen ist aber schnell auf eines der Plasma-Designs umgestellt.

    Das nur für 64-Bit vorliegende Garuda hat relativ hohe Anforderungen an die Hardware, empfohlen werden 40 GByte Speicherplatz und 8 GByte RAM. Bei unter 30 GByte freiem Platz beginnt die Installation erst gar nicht.

    Arch pur bei den Updates

    Garuda zieht Updates ungefiltert aus den Arch-Repositories und bietet als einziges Fremd-Repository Chaotic-AUR an. Es enthält bereits vorerstellte Binär-Pakete. Diese Pakete werden auf der Grundlage der Anweisungen gebaut, die im AUR für das entsprechende Paket zu finden sind.

    Calamares installiert das System in wenigen Schritten und richtet das System mit Btrfs als Dateisystem ein. Als Standard-Browser kommt Firedragon zum Einsatz, eine angepasste Version von Librewolf. Beim ersten Start erblickt man den heutzutage obligatorischen Welcome-Screen, der unter anderem einen Post Installation Wizard bietet, der neben der Auswahl verschiedener Dienste wie Drucker, Samba und anderen, nach Kategorien sortiert, hunderte von Apps zur Installation anbietet. Das können sich gerne andere Distributionen abschauen.

    Snapper für Btrfs-Snapshots

    War in früheren Ausgaben der Distribution Timeshift für die Erstellung der Btrfs-Snapshots zuständig, so sind die Entwickler mittlerweile auf das für diesen Zweck eher geeignete und von openSUSE bekannte Snapper gewechselt. Snapper wird bei der Installation automatisch konfiguriert. Einfluss nimmt der Anwender über das Tool Btrfs Assistant. Die Btrfs-Snapshots sind auch der Grund dafür, warum Garuda mindestens 30 GByte Platz auf der Platte einfordert.

    Einstellungen ohne Ende

    Neben den Plasma-Systemeinstellungen bringt Garuda noch eigene Systemeinstellungen sowie Tools für Systeminfos und andere Diagnosedaten mit. Dabei kann der Anwender relevante Informationen wie den letzten Pacman-Run, Journal-Fehlermeldungen oder eine Systemanalyse gleich per Button für eventuelle Fragen im Forum kopieren. Garuda warnt zudem vor und bietet manchmal auch Hilfe bei einfachen Konfigurationsänderungen an, die bei Arch manchmal notwendig sind.

    Das war nur ein kurzer Überblick über die Plasma-Edition von Garuda. Die Entwickler wollen viel und derzeit sind sie noch dabei, das alles unter einen Hut zu bekommen. Das ändert nichts daran, dass alles funktioniert. Bei den alternativen Paketformaten ist AppImage bevorzugt, Flatpak und Snap sind nicht vorinstalliert.

    Jung und wild

    Garuda ist noch ein wenig chaotisch organisiert, was bestimmt dem jungen Alter der Distribution geschuldet ist. Aber beim derzeit aktuellen Stand ist bereits eine Tendenz zur besseren Integration der vielen Tools zu verzeichnen. Die leichtgewichtigen Abbilder mit Wayfire und Sway sind interessant für Tests mit Wayland. Bei den Fenstermanagern dürften es ruhig weniger sein. Ob Plasma wirklich auch in Varianten für Gamer und zum Pen-Testing sein muss, wage ich zu bezweifeln. Die Integration und automatische Konfiguration von Snapper macht Sinn bei einem System, dass ein Tool namens Chaotic AUR ausliefert.

    Gute Aussichten

    Ich finde Garuda spannend und denke, da ist für die Zukunft noch einiges zu erwarten. Es ist nicht die reine Arch-Lehre, aber das muss es ja auch nicht sein. Die Daseinsberechtigung von Garuda setze ich mindestens so hoch an wie die für Manjaro. Empfehlen würde ich einen Blick auf Garuda denjenigen, die zwar die direkten Updates von Arch bevorzugen, sich aber gleichzeitig ein wenig Absicherung und eine große Zahl nützlicher vorkonfigurierter Tools wünschen. Garuda Linux Barebones KDE Edition ist für die, die sich ihr System selbst aufbauen möchten. Snapper und eine Menge Tools sind auch hier vorkonfiguriert. Bei der Anwendungssoftware ist nicht viel mehr als der Browser an Bord.

  • Erfahrungsbericht: Linux-Tablet JingPad A1

    Tablet mit bekannter Designsprache und GNU/Linux-Ambitionen

    Ein Leserbericht von Franz Kuntke

    Auf der Webseite zum JingPad wird das Tablet mit großen Worten beworben: „JingPad A1 is the World’s First Consumer-level Linux Tablet“. Nachdem im Juni hier bei Linuxnews auf das Crowdfunding für das JingPad A1 aufmerksam gemacht wurde, kommen nun seit etwas über einen Monat die Geräte bei allen (Vor-)Bestellern an – und ich gehöre dazu. Da ich sowohl Linux, als auch mobile Endgeräte toll finde, habe ich das Projekt bereits Anfang des Jahres mit Interesse verfolgt und mir auch einen Platz im Beta-Programm zum JingPad A1 reserviert. Mitte Oktober habe ich dann die JingPad A1 Hardware inkl. Tastatur-Cover erhalten und möchte nun meine Erfahrungen bisher in diesem Bericht teilen – mittlerweile kann man das Gerät nämlich auch regulär im Shop für 699 USD bestellen.

    Solide Hardware

    Im Inneren des Pads steckt der UNISOC Tiger T7510. Laut Datenblatt des JingPad A1 hat diese CPU insgesamt 8 Kerne (4x Cortex-A75 mit 2.0GHz und 4x Cortex-A55 mit 1.8GHz). Der CPU stehen 8GB RAM (LPDDR4) und ein 256GB Flash-Speicher zur Seite. Vom Flash-Speicher sind ca. 184GB auf /home eingehangen und frei nutzbar und 40GB auf /. Die restlichen gut 20GB sind auf 51 weitere Partitionen verteilt, wovon jedoch nur eine Partition mit 10MB aktiv auf /mnt/vendor eingehangen ist. Das aus meiner Sicht Spannendste an dem Tablet ist der 11″ Bildschirm. Dank AMOLED-Technik kommen die Farben subjektiv sehr gut rüber und der Schwarzwert ist exzellent – noch mehr als bei manchen anderen OLED-Geräten fällt es mir bei dem JingPad tatsächlich schwer den „echten“ Rand von dem schwarzen Hintergrund der Systemleiste zu unterscheiden. Weiterhin entsteht das Bild auch recht nah an der spiegelnden Glasoberfläche, was für die Nutzung des (mitgelieferten) Stylus auch praktisch ist.

    Auch LinuxNews macht auf dem Bildschirm Spaß!

    WiFi funkt in den 2.4GHz/5GHz Bändern und auch Bluetooth 5 ist an Board. Weiterhin ist ein 5G-Modem verbaut, das jedoch nicht (mehr) offiziell beworben wird – obwohl es Erfolgsberichte innerhalb der Community gibt. Angeblich werden die 5G-Bänder n41, n78 und n79 unterstützt und sollte die technischen Voraussetzungen auch für die deutschen Netze erfüllen. Mangels 5G-Vertrag konnte ich das leider nicht testen. Dass meine SIM mit LTE-Vertrag (Telekom) dennoch erkannt wird, wird mir mit einem Signal-Indikator bestätigt. An weiterer Peripherie hat das Pad eine Vorder- und Rückkamera mit 8 MP (2448×3264) respektive 16 MP (4608×3456). Die rückwärtige Kamera kann auf zwei LEDs als Blitzlicht zurückgreifen.

    Zwei Mikrofone an den Seiten und zwei Lautsprecher erlauben sowohl die Aufnahme, als auch Wiedergabe von Audio in Stereo. Leider hat das Gerät keine Buchse für 3.5mm Klinke. So muss man entweder den USB-C-Port mit Adaptern bespielen, oder Bluetooth-fähige Kopfhörer nutzen. Die Akkulaufzeit ist auch in Ordnung. Nachdem mit JingOS 1.1 nun das WiFi in Energiesparmodi versetzt wird, wenn das Gerät nicht genutzt wird, hält es realistisch einige Tage mit spontaner Nutzung durch. Die theoretische Idle-Zeit (mit deaktivierten WiFi/Bluetooth) lag mit JingOS 1.0 aber bereits bei ca. 8 Tagen. Das finde ich respektabel und könnte damit genau einen meiner Anwendungsfälle für so ein Multimedia-Brett erfüllen: Einmal pro Woche aufladen, und ansonsten spontan auf dem Sofa damit für paar Minuten surfen oder Videos schauen.

    Mitgeliefertes Zubehör

    Mitgeliefert wird neben dem JingPad A1 ein USB-Netzteil (US-Plug!) und USB-Kabel, sowie ein Cover mit Lederimitat, das durch ein sehr dezent aufgebrachtes JingLing Logo geziert wird und das Tablet sowohl vorn als auch hinten vor Kratzern und Stößen schützt. Da drei Seiten offen sind, könnten jedoch spitze Gegenstände in einer Tasche am Metallrand des Pads kratzen. Das Tablet dockt in dem Cover per starken Magneten an und sitzt sofort an der richtigen Position. Insgesamt fühlt sich das wertig an

    Das mitgelieferte Cover inkl. dezenten JingLing-Logo macht einen guten Eindruck.

    In dem Cover ist über dem Tablet eine magnetische Kerbe, in die man den Stylus einlegen kann, der dann andockt und recht fest sitzt. Das finde ich schön gelöst. Alles zusammen (Cover + Stylus + JingPad A1) bringt 810 Gramm auf die Waage. Das ist vergleichsweise gut für die Art des Covers. Das Tablet selbst wiegt 494g und ist damit etwas schwerer als ein iPad Pro 11″ in 3. Generation von 2021 (466g).

    Optionales Keyboard-Cover

    Optional erhältlich ist das Keyboard-Cover. Dieses Teil ist eine Wucht – vor allem was das Gewicht angeht. An Metall wurde hier nicht wirklich gespart und somit wiegt das Cover allein mit 710g deutlich mehr als das Tablet. Zusammen bringt es das „Tabletop“-Gespann auf 1.2 kg. Das war für mich etwas überraschend und enttäuschend, da manche 13″-Laptops und sogar Convertibles weniger wiegen.

    Da kommt was zusammen – ein Laptopersatz in 11″ dürfte auch etwas leichter sein.

    Auch das Keyboard-Cover dockt das Tablet per starken(!) Magneten an die richtige Position. Das fühlt sich wirklich sehr solide an und man muss schon etwas mehr Druck ausüben, um die Bindung wieder zu lösen. Ein „Kickstand“ lässt sich unter der Tastatur nach hinten herauslösen, wodurch das Tablet gegen nach-hinten-umkippen gesichert ist. Damit lässt sich das Ganze auch wie ein Laptop auf dem Schoß einigermaßen bequem benutzen – mit dem eher wackeligen Surface Go-Cover hatte ich damit beispielsweise immer so meine Probleme.

    Ansonsten ist das Keyboard erwartungsgemäß für ein 11″ Gerät mit recht kleinen, aber immerhin leisen Tasten bestückt. Auch das Touchpad ist klein, der Klick allerdings deutlich zu hören. Insgesamt aber in Ordnung für so ein Gerät. Für den Transport des Stylus hat das Keyboard-Cover leider keine schöne Lösung. Es gibt lediglich auf der Außenseite einen magnetischen Bereich, an den man den Stylus befestigen kann. Folglich kann bei Transport der Stylus abgestreift werden und verloren gehen – hier hätte ich mir eine Integration in das Keyboard-Cover gewünscht.

    Bekannte Designsprache

    Die Hardware des JingPad selbst ist ja noch keine Besonderheit, sondern die Kombination aus Hardware und Betriebssystem. Der Werbeslogan verspricht viel: Ein Tablet mit einem echten Linux („the FIRST Linux Tablet OS“) und das Ganze auf einem „Consumer-level“, sodass man es auch als „daily driver“ nutzen kann. Was bei Nutzung und auch den Mockups und Screenshots direkt auffällt, ist die Designsprache, die starke Verwandtschaft zum Apple-Universum hat. Die meisten Gestaltungselemente erinnern einfach stark an iPadOS. Nur an manchen Stellen sind im System alte Bekannte aus der KDE-Umgebung ersichtlich, z.B. die Terminal-Applikation „Konsole“, oder Sounds bei Lautstärke-Änderung. Da ist es auch nicht verwunderlich, dass die technische Basis für die Oberfläche von KDE Plasma stammen soll.

    Der Startbildschirm und manche Standardapps sind extrem nah am Design von iPadOS

    Ungeachtet der offensichtlichen Kopie von Designelementen finde ich es insgesamt optisch ansprechend und vom grundsätzlichen Bedienkonzept praktisch: Alle Applikationen werden im Vollbild gestartet. Mit einem Wisch von der unteren Bildschirmkante nach oben wird das Programm minimiert und man kommt zur Startseite. Wischt man auf der Startseite nach oben, werden alle minimierten Programme in einer Kacheldarstellung angezeigt. Wischt man mit drei Fingern vertikal, kann man zwischen geöffneten Programmen wechseln. Schließen kann man eine App (1) durch zweimaliges Wischen aus einer Seite in den Bildschirm herein, (2) auf der Kacheldarstellung durch Schieben der App in den oberen Bildschirmrand, oder (3) bei klassischen Programmen wie gewohnt über das Menü („Datei -> Beenden“, o.ä.) bzw. per Tastenkürzel (meist „CTRL“ + „Q“).

    Tatsächlich ein echtes GNU/Linux?!

    Im Unterbau setzt das System auf ein Ubuntu LTS 20.04. Der Kernel ist ein staubiger 4.14er (aktuell 4.14.133). Mittels vorinstallierten Terminal (die KDE-App Konsole) lässt sich auch die gewohnte GNU/Linux-Umgebung nutzen, inkl. Applikations-Management per apt und dpkg. Viele der nützlichen kleinen Shell-Tools laufen, von ssh über git, htop, vim bis hin zu tmux haben bei mir alle Standardtools funktioniert und waren bereits per voreingestellten Repositories erreichbar. Per cargo gitui nachinstallieren? No Problemo! Das fühlt sich insgesamt toll an und war für mich immer ein Ärgernis mit Android-basierten Geräten – und noch viel mehr mit dem Apple-Ökosystem. Auf dem JingPad A1 fühlt man sich somit viel mehr „Herr der Lage“ dank des Zugangs zur Konsole und der vertrauten Linux-Umgebung.

    Konsole + Ubuntu-Basis: Arbeiten in der Shell kann nun auch auf Tablets Spaß machen!

    Blickt man in Richtung grafischer Programme (Stichwort: Multimedia), sieht es allerdings noch nicht ganz so rosig aus. Es gibt nur wenige Programme in dem offiziellen App-Katalog und es bedarf noch manueller Nachjustierung der Skalierung von klassischen GTK- oder QT-Anwendungen, damit Menüs auf eine akzeptable Touchscreen-kompatible Größe gebracht werden. Zu den wenigen Programmen in dem offiziellen „App-Store“ gehören immerhin wichtige Applikationen wir Firefox, Thunderbird, VSCode (und auch Codium!) und Xournal, aber mittlerweile auch einige Multimedia-Applikationen für den Konsum und das Erstellen von audio-/visuellen Erzeugnissen, z.B. Kodi, VLC, OpenShot, Gimp, Krita. Persönlich ist das für mich aber nicht so wichtig, da man die Applikationen auch per apt installieren kann. Neue XDG-Einträge werden direkt auf dem Hauptbildschirm als Icons dargestellt.

    Einige Kateogrin sind dann doch noch leer im offiziellen App-Katalog

    Grafiktreiber und andere Probleme

    Was mich aktuell noch von einer tatsächlichen Empfehlung abhält, ist vor allem die leidige Geschichte mit den Grafiktreibern. Aktuell wird in Software gerendert, was sich z.B. beim Scrollen von Webseiten und hochaufgelösten Videos bemerkbar macht: Wenn sich große Teile des Bildschirminhaltes ändern, ist es einfach nicht so richtig fluffig. Dass es trotz hoher Auflösung nicht extrem schlimm ist, zeigt mir, dass die CPU doch insgesamt recht potent ist und einiges abfedern kann. Aber dennoch ist es kein typisches Tablet-Gefühl, wenn man sich mit Wischen durch das Web bewegt und die Darstellung ruckelt. In dem aktuellen Zustand ist an 3D-Spiele auch überhaupt nicht zu denken.

    Beispielsweise SuperTuxKart ist mit minimalen Details bei 1024×768 Pixel mit ca. 7fps überhaupt nicht spielbar. Ich hatte gehofft, dass das erste größere Update (v1.1 vom 06.11.) dieses Problem lösen würde, dem ist aber leider nicht so. Ob und wann hier nachgebessert werden kann, ist unklar. Mein Eindruck war, dass gerade dieser alte eingesetzte Linux-Kernel die Kompatibilität zu Treibern aus dem Android-Ökosystem ermöglichen soll. Und obwohl bereits Wayland eingesetzt wird und das Gerät über Lagesensoren verfügt, ist die Ansicht auf die Landscape-Variante fixiert. Die Möglichkeit den Bildschirm, im Hochkant-Modus zu nutzen, soll nachgereicht werden.

    Und da sind wir bei dem aktuellen Zustand: Das Betriebssystem ist einfach noch nicht fertig. Die zuletzt kommunizierte Roadmap geht noch bis zum Ende März 2022. Ich denke mit Verzögerungen muss aber wie bei vielen Projekten gerechnet werden. Obwohl zuletzt die Software-Versprechen bisher meist pünktlich eingehalten wurden. Lediglich die Hardware hatte zwischen ursprünglicher Ankündigung und tatsächlicher Lieferung zwei Monate Verzug – aber das muss man ja in der aktuellen Zeit ja fast schon als pünktlich bewerten 😉

    Und dann möchte ich noch einen Punkt nicht unerwähnt lassen: Der zumindest aus meiner westlich geprägten Sicht unorthodoxe Weg der Kommunikation für so ein Projekt. Der Punkt ist hierbei nicht, dass zu wenig kommuniziert wird, sondern dass mehrere Kanäle gleichzeitig bedient werden, – und zwar in alle Richtungen. Es wird fleißig auf Discord, Telegram und im eigenen Discourse-Forum diskutiert und Neuigkeiten geteilt – manche Infos (von Mitarbeitenden!) erreichen die eine Plattform, manche nur eine andere Plattform. Und viel schlimmer: Bisher wurde noch keine zentrale Stelle für Issues gefunden. Im Beta-Programm hieß es, es gibt eine Telegram-Gruppe (warum auch immer) in die man einfach Dinge reinschreiben kann und einen Discord-Server für JingOS.

    Letzterer hat immerhin thematische Kanäle, z.B. für Bugreports. Aber so richtig nachhaltig ist das ganze natürlich auch nicht – zumal man sich erst einloggen muss und dann einen endlosen Nachrichtenfeed durchscrollen müsste, um zu schauen, ob das gefundene Problem bereits bekannt ist. Und gerade für so ein Open-Source-nahes Projekt wirken die gewählten Wege unüblich. Aktuell scheint es aber für Bug-Reporting endlich in Richtung öffentlich zugänglicher GitHub-Issues zu gehen … das sollte dann den organisatorischen Aufwand auf beiden Seiten im Umgang mit Fehlerberichten und Nutzerwünschen reduzieren.

    Fazit & Ausblick: Ein Multimedia-Tablet mit GNU/Linux ist greifbar nah!

    Seit dem gescheiterten Versuch von Jolla,ein Tablet auf den Markt zu bringen in 2015/2016 ist mir keine ernstgemeinte Unternehmung bekannt, ein (kommerzielles) Linux-Tablet für Endverbraucher auf den Markt zu bringen. Die Leute hinter JingLing haben hier ein beachtliches Werk vollbracht. Für einige Anwendungszwecke scheint mir das Tablet bereits jetzt alltagstauglich. Um mit den ganz Großen mitzuspielen und dem Anspruch ein waschechtes Multimedia-Tablet zu sein, fehlt es neben der Grafikbeschleunigung noch an Feinschliff an vielen Ecken und Kanten. Auch unklar ist die Positionierung der Firma und welche Anwendergruppen und Regionen sie langfristig bedienen wollen.

    Die potente Hardware in Kombination mit einer echten GNU/Linux Umgebung sind meiner Ansicht nach allerdings aktuell einzigartig. Ich wünsche der Firma und Community, dass die letzten großen Hürden genommen werden und das Ökosystem wächst. In den nächsten Wochen und Monaten soll ein offizieller Support für Android-Apps Einzug erhalten, neben weiteren kleinen Details wie beispielsweise den Support für den Fingerprint-Reader im Powerbutton. Es bleibt spannend.

    Bei Fragen zum Tablet oder Anmerkungen könnt ihr mich gern per Mail kontaktieren: franz (at) znarfsoft (punkt) de

    Resourcen: jingpad.com | Twitter | Reddit | Discord

  • APT 2.3.12 – Paketmanager wird restriktiver

    Yes, do as I say

    Julian Andres Klode, Entwickler bei Debian und Ubuntu hat gestern APT 2.3.12 freigegeben und damit auf ein in den letzten Tagen viral gegangenes YouTube der Plattform »Linus Tech Tips mit dem provokativen Titel «Linux hates me« reagiert. Es geht darin um eine Wette, in der die beiden Protagonisten Windows 11 für einen Monat durch Linux ersetzen.

    Alle Warnungen in den Wind geschlagen

    Ab Minute 10 versucht einer der Protagonisten, der sich Pop!_OS von System76 ausgesucht hatte, dort Steam zu installieren. Durch einen Fehler in der Paketierung der Distribution erschien eine Warnung, die Installation von Steam sei nicht möglich, da dabei essenzielle Pakete entfernt würden.

    APT schlug vor, um Steam trotzdem zu installieren, müsse die Phrase Yes, do as I say eingetippt werden. Gesagt – getan: Um aus der Perspektive von umsteigewilligen Windows-Usern die Fallstricke von Linux aufzuzeigen, folgt der Protagonist, der auch noch Linus heißt, dem Vorschlag, tippte die Phrase ein und zerstörte wegen der entfernten essenziellen Paketen die Installation.

    Fehler in der Steam-Paketierung

    Dazu ist erstens zu sagen: Die Schuld liegt hier zunächst in der fehlerhaften Paketierung von Steam durch System76. Die Entwickler haben den Fehler schnell behoben, die Produktion des Videos überschnitt sich mit dem Bugfix.

    https://twitter.com/jeremy_soller/status/1453008808314351628

    Reagieren User wirklich so?

    Dass sich Linus über die eindeutige Warnung inklusive der Liste der zu entfernenden Pakete hinwegsetzt und das System schrottet, soll wohl suggerieren, dass sich viele Anwender so verhalten würden. Ob das stimmt, vermag ich nicht zu beurteilen, allerdings wird es für jeden, der es so macht, einen Lerneffekt haben, der ihn entweder zu intensiverem Lesen und Beachten von Warnungen veranlasst oder gleich zu Windows zurückführt. Dass sich Linus dann im Video über den Hard-Reset seines Systems so echauffiert ist natürlich lächerlich, nachdem er dem System die Existenzgrundlage für die Desktop-Umngebung entzogen hat.

    Apt unschuldig?

    Dass APT ein solches Übergehen einer Warnmeldung zulässt, mag jeder beurteilen wie er mag. Ich denke, es gehört zu einem freien Betriebssystem wie Linux mit dazu, dass, wer weiß, was er tut, dies auch tun können muss. Immerhin muss man eine Phrase eintippen und nicht einfach eine Bestätigung anklicken. Wer nicht weiß, was er tut und dennoch fortfährt, ist selbst schuld.

    Obwohl APT hier meiner Meinung nach die wenigste Schuld trifft, haben die Debian-Entwickler reagiert und eine Änderung der Entwickler von Pop!_OS übernommen und die Phrase zum Übergehen der Warnung versteckt. An deren Stelle taucht nun die Meldung This operation is not permitted because it will break the systemauf. Um dennoch auf eigene Verantwortung die Phrase zum Übergehen anzeigen zu lassen, bedarf es einer Anpassung der Konfiguration.

    Wie seht ihr hier die Verantwortung der Beteiligten? Soll APT dem User die Freiheit lassen, sein System zu zerstören? Ist Linus zu doof für Linux?

  • Upgrade: Raspberry Pi OS auf »Bullseye« aktualisieren

    Upgrade: Raspberry Pi OS auf »Bullseye« aktualisieren

    Kürzlich hat die Raspberry Pi Foundation ihr Betriebssystem für den Raspberry Pi aktualisiert. Die neue Version von Raspberry Pi OS wurde von Debian 10 »Buster« auf Debian 11 »Bullseye« angehoben. Es gab aber weitere einschneidende Änderungen wie unter anderem den Schritt von GTK 2 zu GTK 3 und den Umstieg vom Openbox-Window-Manager auf Mutter. Deshalb rät die Foundation von einem Update ab und empfiehlt, mit einem frischen Abbild auf einer SD-Karte neu zu beginnen, nachdem die Bestandsdaten gesichert sind.

    Je nachdem, wie individuell euere RasPi-Installationen sind, ist ein Upgrade allerdings vorzuziehen. Da ich von einigen Kollegen hörte, bei denen das Update nicht reibungslos verlief, habe ich mal die Vorgehensweise zusammengefasst. Dies sind nicht meine eigenen Erfahrungen, ich werde meine RasPis erst im Dezember hochziehen, wenn ich mehr Zeit habe. Aber das hier beschriebene Vorgehen (Quelle am Ende des Artikels) ist technisch korrekt und sollte funktionieren.

    Quellen anpassen und Upgrade anstoßen

    Zunächst sollte ein Abbild der SD-Karte gezogen werden, was mit dem vorinstallierten Tool SD Card Copier problemlos funktioniert. Backups wichtiger Daten habt ihr ja hoffentlich sowieso. Bevor es losgeht, stellt ein Upgrade sicher, dass euer Pi mit der »Buster«-Version auf dem aktuellen Stand ist:

    sudo apt update
sudo apt full-upgrade
sudo rpi-update

    Dann gilt es, die Quellenliste für »Bullseye« anzupassen. Das kann händisch geschehen oder mit zwei sed-Befehlen:

    sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list
sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/raspi.list

    Darauf folgt ein Update der Quellen und die Installation von gcc-8, ohne die die anstehende Aktualisierung nicht durchläuft:

    sudo apt update && sudo apt install libgcc-8-dev gcc-8-base

    Mit dem folgenden

    sudo apt full-upgrade

    wird die Aktualisierung angestoßen. Nachdem das Upgrade durchgelaufen ist, sollte man sicherstellen, dass alle anstehenden Pakete auch installiert wurden. Dazu dient der Befehl 

    sudo apt -f install

    Danach sollte im besten Fall APT anzeigen, dass alle Pakete installiert wurden:

    0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert

    Ist das nicht der Fall, muss ein weiteres Upgrade folgen:

    sudo apt full-upgrade

    Dem kann ein 

    sudo apt autoremove

    folgen, wobei es aber ratsam ist, zu kontrollieren, was für überflüssig erachtet und entfernt werden soll.

    KMS aktivieren

    Wenn mit einem neuen Abbild gestartet wird, wird automatisch Kernel Mode Setting (KMS) aktiviert, bei der Aktualisierung eines vorhandenen Abbilds wie hier beschrieben muss das händisch geschehen. Dazu wird die Datei /boot/config.txt editiert:

    sudo nano /boot/config.txt

    Hier werden zunächst alle Zeilen mit einem # davor auskommentiert, die dtoverlay=vc4-fkms-v3d enthalten. Dann wird unten in der Sektion [all] die Zeile dtoverlay=vc4-kms-v3d hinzugefügt. Beides kann auch wieder mithilfe des Stream Editors sed erledigt werden.

    sudo sed -i 's/dtoverlay=vc4-fkms-v3d/#dtoverlay=vc4-fkms-v3d/g' /boot/config.txt

sudo sed -i 's/[all]/[all]ndtoverlay=vc4-kms-v3d/' /boot/config.txt

    WLAN-Schnittstelle aktivieren

    Damit ist das Upgrade so weit abgeschlossen, dass ein Neustart ohne visuelle Artefakte gelingen sollte. Falls nach dem Reboot eine vorher funktionierende WLAN-Schnittstelle nicht mehr erkannt wird, so liegt das vermutlich an der Verwendung von Conman zum Verwalten der Schnittstelle. Um hier zu einer funktionierenden Verbindung zu kommen, muss man in Menü unter Preferences -> Connman Settings -> Wireless einmal auf Connect klicken.

    Edit: bitte auch https://linuxnews.de/raspberry-pi-os-auf-bullseye-aktualisieren/#comment-11514 beachten.

    WLAN-Applet austauschen

    Das Netzwerk-Applet im Panel wird vermutlich nicht mehr korrekt funktionieren. Um es zu ersetzen, kann man es mit rechter Maustaste anklicken und Remove "Wireless & Wired Network From Panel auswählen. Um ein funktionierendes Applet zu bekommen wird das Panel rechts geklickt und unter Add / Remove Panel Items - > Add der Eintrag Manage Networks ausgewählt.

    Diese Anleitung zum Upgrade auf Raspberry Pi OS »Bullseye« habe ich aus dem Blog Linux Uprising übernommen und leicht erweitert. Dabei habe ich die englischen Menübezeichnungen verwendet, die bei euch vielleicht eingedeutscht sind. Und jetzt viel Erfolg beim Upgrade.

  • WirePlumber: ein Session-Manager für PipeWire

    WirePlumber: ein Session-Manager für PipeWire

    Den meisten Lesern dürfte PipeWire als designierter Nachfolger von PulseAudio und mehr mittlerweile ein Begriff oder bereits in Benutzung sein. Ein Artikel von 2018 in der Zeitschrift LinuxUser beleuchtet die Notwendigkeit für die Entwicklung von PipeWire im Zusammenspiel mit der fortschreitenden Wayland-Integration. Seither ist viel passiert und PipeWire produktiv nutzbar geworden.

    Der Klempner

    Kürzlich erschien nun unter der treffenden Bezeichnung WirePlumber ein externer Session-Manager für PipeWire, der mit Fedora 35 ausgeliefert wurde und der auch bei mir bereits bei Debian Unstable Dienst tun. Ich kam auch gar nicht drum herum, da die bis dahin dafür verwendete Komponente pipewire-media-session entfernt wurde und in der Folge der Sound ausblieb.

    Für den Automotive-Bereich entwickelt

    WirePlumber wird von dem bei Collabora angestellten George Kiagiadakis entwickelt, der seit 2018 auch an PipeWire mitarbeitet. Eines der weiteren Projekte, an denen er im Rahmen seiner Anstellung arbeitet, ist das unter dem Schirm der Linux Foundation agierende Automotive Grade Linux (AGL). Hier fiel ihm auf, dass das zuverlässige Regeln von mehreren Audioströmen mit PulseAudio nicht einfach war. Dabei ging es um simple Dinge wie das Herunterregeln der Lautstärke der Musik, wenn eine Sprachmeldung vom Navi anstand oder das Stoppen des Audiostroms, wenn ein Anruf hereinkommt.

    Logik per Lua-Script

    Für diese Aufgaben versprach PipeWire bessere Ergebnisse. Allerdings stellte Kiagiadakis fest, dass der verwendete, in C geschriebene Session-Manager pipewire-media-session zu unflexibel war, wenn es um schnelle Anpassungen am Code ging. In der Folge entwarf er WirePlumber als modulare externe Anwendung, deren Steuerlogik in der Scriptsprache Lua verfasst ist. Diese Lua-Skripte können leicht modifiziert und erweitert werden, was bedeutet, dass die Benutzer jetzt die Möglichkeit haben, das Verhalten ihres PipeWire-Setups besser an ihre Bedürfnisse anzupassen.

    Raue Ecken

    Noch gibt es allerdings einige raue Ecken, die ausgebügelt werden müssen, bevor WirePlumber ein guter Mitspieler auf dem Desktop wird. Aber die Auslieferung mit Fedora 35 sollte hier für schnellen Fortschritt sorgen. Red Hat-Entwickler Christian Schaller hat Kiagiadakis für das Fedora Magazine zu WirePlumber interviewt, der einige Hintergründe der Entwicklung erläutert. Die Dokumentation von WirePlumber beleuchtet weitere technische Einzelheiten wie die Konfiguration und die einzelnen Module.

    Mit der rasanten Entwicklung von PipeWire und dem neuen Session-Manager WirePlumber sehen wir, wie ich finde, spannenden Zeiten im Bereich Audio/Video entgegen.

    Bild: Photo by Bruce Warrington on Unsplash

  • 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.

  • 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.

  • Warum ist die Entwicklung von Linux-Hardware teuer?

    Warum ist die Entwicklung von Linux-Hardware teuer?

    Es war schon immer etwas teurer, einen besonderen Geschmack zu haben. Diesen Spruch kann man tröstend jedem Käufer von Hardware, die auf Linux zugeschnitten ist, angedeihen lassen, denn für solcherart Geräte ist immer ein kleiner Aufpreis zu entrichten. Das trifft auf Linux-Notebooks, und noch mehr auf Linux-Phones zu. Aber wie kommt der Aufpreis zustande?

    Kleine Stückzahlen

    Ich will versuchen am Beispiel von Tuxedo Computers mit deren Linux-Notebooks und von Purism mit dem Linux-Phone Librem 5 darzulegen, wie diese Preisaufschläge zustande kommen. Ein für jeden einsichtiger Grund, der für beide gleichsam gilt, sind die realisierbaren Stückzahlen. Je mehr man von einem Artikel kauft, desto günstiger wird es meist, das kennt jeder. Von daher sind durch die vergleichsweise kleinen Stückzahlen in der Linux-Nische bereits bei der Beschaffung der nötigen Komponenten im Vergleich mit Lenovo oder Samsung Preisaufschläge gegeben.

    Schwierige Produktionsbedingungen

    Die Suche nach Produzenten für kleine Stückzahlen kann so weit gehen, dass Projekte kaum oder gar nicht realisierbar sind, wie bereits 2014 der KDE-Entwickler Aaron Seigo beim Versuch der Produktion eines Linux-Tablets erfuhr, der für ihn mit einem Schuldenberg endete. Auch Purism hatte Probleme, einen Produzenten für kleine Stückzahlen zu finden, der zudem noch wusste, was Open Source bedeutet. Erst als man einen Insider verpflichten konnte, fand sich ein Produzent für die vermutlich 5.000 – 10.000 bisher produzierten Librem 5 Phones. Konzerne wie Samsung oder Apple bestellen dagegen Millionen Geräte auf einmal.

    Verknappung von Komponenten

    Die Pandemie hat die Situation für kleine Hersteller nochmals drastisch verschärft, sodass etwa Purism derzeit kaum liefern kann, da die Jagd nach bestimmten Komponenten zu bezahlbaren Preisen zu einem weltweiten Abenteuer geworden ist. Auch Tuxedo Computer würde gerne mehr Geräte mit aktuellen AMD-Prozessoren oder dedizierten AMD-Grafikkarten anbieten, leidet aber ebenfalls unter dem verknappten Angebot und den vergleichsweise kleinen Stückzahlen.

    Pine64 vs. Purism

    Das Librem 5 war von Beginn an nicht günstig, beim Crowdfunding waren es noch moderate 599 USD, zum Beginn der Pandemie dann 799 und inzwischen 899 USD mit steigender Tendenz. Wie kommt dieser Preis zustande, wo doch ein nicht wesentlich schlechter ausgestattetes Gerät wie das PinePhone nur 150 – 200 USD kostet? Hersteller Pine64 hat keinen zusätzlichen Entwicklungsaufwand, da die Geräte auf bereits vorhandenen Komponenten beruhen und die Community die Software dazu entwickelt. Im Endeffekt profitiert auch Pine64 von der Entwicklungsarbeit von Purism.

    Purism begann beim Librem 5 ganz von vorne mit dem Entwurf eines Mainboards und der Suche nach Komponenten ohne Blobs anstelle der üblichen integrierten Schaltung, die der Sicherheit und dem Schutz der Privatsphäre nicht dienlich ist. Auf der Basis von GNOME werden zudem ein mobiles Betriebssystem, Apps und Werkzeuge entwickelt und Patches für den Kernel bereitgestellt. Insgesamt ist dies teure Pionierarbeit für die Grundlagen einer hoffentlich nachhaltigen Entwicklung eines Linux-Phones, das gleichzeitig ein kompletter Rechner für die Hosentasche ist.

    Viel Entwicklungsarbeit bei Tuxedo

    Abgesehen davon, dass Tuxedo sich selbst im mittleren bis oberen Marktsegment angesiedelt hat, wird auch hier viel extra Arbeit geleistet. Auch Tuxedo nimmt nicht einfach einen Barebone, steckt ein paar Komponenten rein und klatscht ein Linux-Betriebssystem drauf. In Augsburg werden Entwicklungen wie eigene Treiber, Tuxedo Control Center, Tomte und WebFAI erstellt und gepflegt und die unterstützten Distributionen angepasst. Einige Patches sind bereits im Grafik-Stack des Mainline-Kernels gelandet. Zudem wird ein gut erreichbarer Support geboten. Individuelle Logos auf den Geräten, Tastaturbelegungen wie Dvorak und individuelle Beschriftungen auf der Tastatur sind weitere Pluspunkte eines individualisierbaren Notebooks.

    Der Preis der Freiheit

    Alle diese Kosten der Unternehmen müssen auf die Geräte umgelegt und zudem noch ein Gewinn erzielt werden, wenn die Unternehmen eine Zukunft haben sollen. Wer also diese Geräte als überteuert ansieht, der sollte den Aufpreis als eine Investition in die Zukunft sehen, die uns hoffentlich noch mehr Freiheit bei der Auswahl unserer digitalen Gerätschaften bietet. Denn je größer die Nische wird, desto günstiger kann produziert werden.

  • Firefox soll durch Tab Unloading stabiler werden

    Bildquelle: Mozilla

    Mit dem gestern freigegebenen Firefox 93 versucht Mozilla erneut, dem Problem OOM (out of memory) Herr zu werden. Die entsprechende Funktion namens Tab Unloading wurde bereits mit Firefox 67 eingeführt, aber schnell wieder eingestellt, da keine Balance zwischen der Verringerung des Speicherbedarfs des Browsers und der Verärgerung des Benutzers, weil es eine leichte Verzögerung gibt, wenn der Tab neu geladen wird, gefunden werden konnte, wie ein aktueller Blogeintrag auf Mozilla Hacks zum Thema verrät. Jetzt wurde Tab Unloading für Windows wieder aktiviert, Linux und macOS sollen mit Firefox 94 folgen.

    Algorithmus verfeinert

    Dazu wurde der Algorithmus zur Erkennung von niedrigem Speicherplatz und zur Auswahl von Tabs verfeinert. Unloading soll nur eingreifen, wenn der Browser wegen Speichermangel kurz vor dem Absturz steht. Experimente in den vergangenen Nightlies geben zu der Hoffnung Anlass, dass die Anwender nun von der Funktion profitieren können. Wenn der Arbeitsspeicher des Systems kritisch niedrig ist, beginnt Firefox nun automatisch damit, Tabs zu entladen, um Abstürze zu vermeiden.

    Im Idealfall werden nur Tabs entladen, die vermutlich nicht mehr benötigt werden, und der Benutzer wird schließlich den Browser neu starten oder nicht geladene Tabs schließen, bevor er sie erneut lädt. Dazu wird ermittelt, wann der Benutzer einen Tab zuletzt benutzt hat und dann die am seltensten benutzten Tabs zuerst entladen. Tabs, die Ton abspielen, Bild-im-Bild verwenden, angeheftete Tabs oder Tabs, die WebRTC verwenden, werden stärker gewichtet, sodass es weniger wahrscheinlich ist, dass sie entladen werden. Tabs, die aktuell benutzt werden, sind vom Unloading ausgenommen.

    Neue Übersichtsseite

    Mit Firefox 94 soll unter about:unloads eine neue Seite hinzukommen, die dokumentiert, in welcher Reihenfolge Tabs entladen werden, falls es nötig ist. Zudem kann der Anwender dort Tabs manuell entladen. Die Seite ist derzeit in der Testphase, und kann in einer frühen Form in Firefox 94 Beta ausprobiert werden. Es gibt bereits einige Erweiterungen, mit denen Anwender Tabs entladen können. Die Entwickler gehen davon aus, dass beide Methoden sich nicht stören, da sie das gleiche tabs.discard() API verwenden. Nützlich können die Erweiterungen weiterhin sein, da sie zum Teil andere Metriken oder aggressivere Heuristiken einsetzen, um mehr Speicher zu sparen.

    Firefox crasht bei zu vielen offenen Tabs

    Das Thema tangiert mich persönlich, da ich mit meinem Workflow mit Firefox bisher nicht arbeiten kann. Ich habe üblicherweise am Desktop 300 – 500 Tabs in ~ 10 Browser-Instanzen geöffnet, in denen ich meine aktuelle und die Arbeit der nächsten Monate organisiere und abarbeite.

    Das hat sich über die Jahre als der beste Workflow für mich etabliert, da ich bei der täglichen Arbeit oft über Links stolpere, die für künftige Projekte interessant sind. Die verschiebe ich dann einfach in die entsprechende Browser-Instanz, bis sie benötigt werden. Das erspart oft einiges an Recherche, wenn dann das entsprechende Thema ansteht. Ist das Thema erledigt, wird die Instanz einfach geschlossen.

    Mit Firefox habe ich bereits einmal bei einem der bei dieser Last nicht gerade seltenen Crashes des Browsers fast alle Tabs verloren, obwohl genügend RAM vorhanden war. Seitdem arbeite ich am Desktop-Rechner mit Chrome, der das klaglos schafft. Zudem setze ich Session Buddy ein, um für den Fall der Fälle meine Arbeitsgrundlage nicht zu verlieren. Eine gute Alternative ist Workona, dass es wie Session Buddy auch für Chrome und Firefox gibt. Vielleicht wird Firefox ja nun künftig auch für solche Workloads benutzbarer.