Im Rahmen meiner jährlichen Steuererstattung kaufe ich mir meist etwas, was ich normalerweise nicht kaufen würde. Dieses Jahr bin ich etwas früher dran als sonst. Es ist ein Trackball geworden. Ich möchte aber auch meine Maus angeschlossen lassen und immer nur das gewünschte Gerät aktivieren, das ich nutzen will.

Gleich vorweg, diese Lösung funktioniert nur unter Plasma mit KWin und Wayland. Weiterhin werden busctl (systemd) und qdbus6 (qt6-tools).

#!/usr/bin/env bash
set -euo pipefail

QDBUS=$(command -v qdbus6 || command -v qdbus-qt6) || {
    echo "Fehler: qdbus6/qdbus-qt6 nicht gefunden" >&2
    exit 1
}

BUSCTL=$(command -v busctl) || {
    echo "Fehler: busctl nicht gefunden" >&2
    exit 1
}

SERVICE=org.kde.KWin
BASE=/org/kde/KWin/InputDevice
IFACE=org.kde.KWin.InputDevice
PROPS=org.freedesktop.DBus.Properties

# An die tatsächlichen Gerätenamen anpassen.
MAUS='Kingsis Peripherals ZOWIE Gaming mouse'
TRACKBALL='HUGE PLUS HUGE PLUS'

usage() {
    echo "Verwendung: $0 {maus|trackball|beide|toggle}" >&2
    exit 2
}

mode=${1:-toggle}
case "$mode" in
    maus|trackball|beide|toggle) ;;
    *) usage ;;
esac

get_prop() {
    "$QDBUS" "$SERVICE" "$BASE/$1" \
        "$PROPS.Get" "$IFACE" "$2"
}

set_enabled() {
    "$BUSCTL" --user set-property "$SERVICE" "$BASE/$1" \
        "$IFACE" enabled b "$2" || {
        echo "Fehler: $1 konnte nicht auf enabled=$2 gesetzt werden" >&2
        exit 1
    }
}

require() {
    (( $2 > 0 )) || {
        echo "Fehler: $1 nicht gefunden" >&2
        exit 1
    }
}

switch() {
    local state=$1
    shift
    local dev
    for dev in "$@"; do
        set_enabled "$dev" "$state"
    done
}

devlist=$("$QDBUS" "$SERVICE" "$BASE" \
    org.kde.KWin.InputDeviceManager.devicesSysNames) || {
    echo "Fehler: KWin-InputDevice-Schnittstelle nicht erreichbar (Wayland-Session?)" >&2
    exit 1
}
mapfile -t devs <<< "$devlist"

maus=()
trackball=()

for dev in "${devs[@]}"; do
    [[ -n $dev ]] || continue
    name=$(get_prop "$dev" name)
    case "$name" in
        "$MAUS")      maus+=("$dev") ;;
        "$TRACKBALL") trackball+=("$dev") ;;
    esac
done

if [[ "$mode" == toggle ]]; then
    if (( ${#maus[@]} == 0 )); then
        # Keine Maus gefunden: Trackball wählen.
        mode=trackball
    elif [[ "$(get_prop "${maus[0]}" enabled)" == true ]]; then
        if (( ${#trackball[@]} > 0 )); then
            mode=trackball
        else
            # Maus aktiv, aber kein Trackball da: Maus bleibt aktiv.
            mode=maus
        fi
    else
        mode=maus
    fi
fi

case "$mode" in
    maus)
        require "Maus ($MAUS)" "${#maus[@]}"
        switch true  "${maus[@]}"
        switch false "${trackball[@]}"
        if (( ${#trackball[@]} > 0 )); then
            echo "Maus aktiv; Trackball deaktiviert."
        else
            echo "Maus aktiv; kein Trackball gefunden."
        fi ;;

    trackball)
        require "Trackball ($TRACKBALL)" "${#trackball[@]}"
        switch true  "${trackball[@]}"
        switch false "${maus[@]}"
        if (( ${#maus[@]} > 0 )); then
            echo "Trackball aktiv; Maus deaktiviert."
        else
            echo "Trackball aktiv; keine Maus gefunden."
        fi ;;

    beide)
        # Rettungsmodus: aktiviert alles, was gefunden wurde.
        require "Maus oder Trackball" $(( ${#maus[@]} + ${#trackball[@]} ))
        switch true "${maus[@]}" "${trackball[@]}"
        echo "Alle gefundenen Geräte aktiviert." ;;
esac

In Zeile 20 und 21 trägt man die betreffenden Eingabegeräte ein. Dessen Bezeichnung kann man mit folgendem Befehl ermitteln.

q=$(command -v qdbus6 || command -v qdbus-qt6)
for d in $($q org.kde.KWin /org/kde/KWin/InputDevice org.kde.KWin.InputDeviceManager.devicesSysNames); do
  printf '%-8s %-6s %s\n' "$d" \
    "$($q org.kde.KWin /org/kde/KWin/InputDevice/$d org.freedesktop.DBus.Properties.Get org.kde.KWin.InputDevice enabled)" \
    "$($q org.kde.KWin /org/kde/KWin/InputDevice/$d org.freedesktop.DBus.Properties.Get org.kde.KWin.InputDevice name)"
done | sort -V

Das Script bietet nun mehrere Möglichkeiten.

./script.sh maus (schaltet auf die Maus um und deaktiviert den Trackball) ./sript.sh trackball (schaltet auf den Trackball um und deaktiviert die Maus) ./script.sh beide (aktiviert sowohl Trackball als auch die Maus) ./script.sh toggle (schaltet zwischen den jeweiligen Geräten hin und her)

Jedes Jahr erscheinen 1000 neue Linux-Distributionen. Ist das die Voraussetzung für ein Einhorn, oder sind es verschwendete Ressourcen?

Ist euch das auch aufgefallen? Beim täglichen Durchstreifen meines Newsfeeds, sehe ich fast jeden Tag neue Linux-Distributionen. Damit meine ich nicht neue Versionen von bekannten Distros, sondern Ersterscheinungen. Warum ist das so, wer braucht das, wer steckt dahinter?

Um meinen Eindruck zu quantifizieren, habe ich im Internet nach Neuerscheinungen von Distributionen im Jahr 2026 gesucht. Dabei fand ich nur einzelne Berichte, die kein Gesamtbild abgaben. Auch mit einer KI-Suche konnte ich keine befriedigende Liste erstellen. Einen Hinweis findet man bei Distrowatch. Dort gibt es (ganz unten links) eine Warteliste von Distros, die noch nicht in den Bestand aufgenommen wurden:

Diese neuen Distros sind mit einem Datum versehen, so dass man auf die Neuerscheinungen im Jahr hochrechnen kann. Die Liste deckt 5 Tage ab, in denen 16 Distros in die Warteliste aufgenommen wurden. Das ergibt ca. 3 neue Distros pro Tag. Auf ein Jahr gerechnet, sind das mehr als 1000 Neuerscheinungen.

Grundsätzlich ist Vielfalt in der Distro-Welt eine tolle Sache. Jeder soll sich seine Distribution basteln, wie sie ihr gefällt. Dann sei aber die Frage nach der Nachhaltigkeit erlaubt. Was soll die Community mit 1000 Eintagsfliegen anfangen? Wo liegt der Nutzen, wo ist die Nachhaltigkeit? Alle Entwickler:innen, die in der Lage sind, eine eigene Distribution auf die Beine zu stellen, könnten bei den etablierten Projekten mitarbeiten, um deren Qualität und Nachhaltigkeit zu sichern.

Basis-Distributionen

Wenn man über Distributionen schreibt, lohnt sich ein Blick auf den Stammbaum. Obwohl es tausende Distros gibt, stehen 99 % davon auf den Schultern von Giganten, den Basis-Distributionen. Viele davon bestehen seit den Anfängen von GNU/Linux, als da wären (sortiert nach Entstehungsjahr):

• Slackware – 1993
• Debian – 1993
• SUSE – 1994
• Gentoo – 2000
• Arch Linux – 2002
• Fedora Linux – 2003
• NixOS – 2003
• Alpine Linux – 2005
• Void Linux – 2008
• KaOS – 2013
• Solus – 2015

Ohne es geprüft zu haben, behaupte ich, dass die meisten anderen Distributionen auf Debian und Arch Linux aufbauen. Eine interessante Kennziffer wäre die Anzahl an Personen, die bei den Distros mitarbeiten. Mir ist es nicht gelungen, für die oben genannten Projekte verlässliche Zahlen zu finden. Lediglich beim Debian-Projekt werden 1045 stimmberechtigte Entwickler:innen genannt.

Die Neuerscheinungen

Um die Neulinge aus diesem Jahr beurteilen zu können, habe ich mir zufällig drei Distributionen herausgegriffen.

ErgenOS

ErgenOS ist eine unabhängige, auf Arch Linux basierende Distribution, die auf GNOME, Btrfs-Wiederherstellung und einem grafischen Installationsprogramm aufbaut. Sie nutzt die Arch-Repositories und das Rolling-Release-Modell und ergänzt diese um einen eigenen Installationsablauf, Systemstandardwerte und eine Wiederherstellungskonfiguration. Das Projekt hat einen Kontributor.

LumaOS

LumaOS ist eine Wayland-orientierte Linux-Distribution, die auf dem scrollbaren Kachel-Compositor „Niri“ basiert. Geschwindigkeit, Eleganz und eine Ästhetik, die an den Weiten des Weltraums erinnert – zu einem stimmigen Ganzen vereint. Diese Distro basiert auf Ubuntu LTS. Das Projekt hat einen Kontributor.

ReyOS

ReyOS ist eine ruhige, zuverlässige KDE-Plasma-Linux-Distribution auf Arch-Basis: einfach genug, dass auch ein Neuling sie installieren, nutzen und aktualisieren kann, ohne zum Linux-Administrator werden zu müssen, und leistungsstark genug, dass ein erfahrener Nutzer niemals in seiner Freiheit eingeschränkt wird. Das Projekt hat zwei Kontributoren.

Fazit

Diese drei zufällig ausgewählten Neuerscheinungen bestätigen meine These: zwei bauen auf Arch und eine auf Ubuntu (also Debian) auf. Diese Distributionen stammen von Einzelpersonen; es gibt keine Entwickler-Community dahinter. Dem kann man entgegnen, dass Ian Murdock im August 1993 auch alleine mit Debian angefangen hat. Ein weiteres Beispiel ist der Rising Star am Distro-Himmel: CachyOS gibt es erst seit drei Jahren, befindet sich aber seit zwei Jahren unter den Top-Ten der beliebtesten Linux-Distributionen. Das Kernteam von CachyOS besteht aus 13 Personen. 

Was haltet ihr von der Distroschwemme? Sind viele Neuerscheinungen (1000 pro Jahr) ein Segen für den Linux-Markt, weil sich dadurch die Wahrscheinlichkeit für Perlen erhöht? Oder sind das verschwendete Ressourcen, die ihre Ideen und Leistungen besser in die Verbesserung von etablierten Distributionen stecken sollten?

Ich persönlich halte eine Mischung von beidem für den besten Weg. 1000 Eintagsfliegen pro Jahr sind zu viele, aber wenn aus der Nummer 785 ein Einhorn wird, möchte ich das nicht verpassen.

Titelbild: https://commons.wikimedia.org/wiki/Tsunami?uselang=de#/media/File:Tsunami_by_hokusai_19th_century.jpg

Quelle: https://distrowatch.com/

Die MZLA Technologies Corporation hat mit Thunderbird 158.0.1 ein Sicherheits-Update seines Open Source E-Mail-Clients für Windows, Apple macOS und Linux veröffentlicht.

Neuerungen von Thunderbird 158.0.1

Mit Thunderbird 158.0.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht. Die neue Version behebt mehrere Sicherheitsprobleme. Außerdem wurde ein Darstellungsproblem bei Verwendung von Drittanbieter-Themes korrigiert.

Der Beitrag Sicherheits-Update Thunderbird 158.0.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Nach einem Test in einer virtuellen Maschine habe ich den Release Candidate von openSUSE Leap 16.1 auf einem Laptop installiert. Hier mein Bericht.

Ich stand vor der Aufgabe, einen Laptop für die Aufbewahrung in der Schule vorzubereiten - den will ich nämlich nicht dauernd hin- und herschleppen. Bedeutet für mich: Gesicherte Updates, wenig Pflege, Vollverschlüsselung (full disk encryption, FDE). Nach meinen schlechten Erfahrungen mit Debian und debian-basierten Distributionen und da Solus ja wöchentliche Updates erhält (≠︎ wenig Pflege), fiel meine Wahl auf openSUSE Leap. Das Release von 16.1 soll am 03.11. stattfinden, also lohnt es sich jetzt nicht wirklich, 16.0 zu installieren, nur um dann in nicht mal einem Monat ein Upgrade durchzuführen. Folglich "muss" der Release Candidate herhalten. Schauen wir mal, was passiert! 😋

Plan

Folgendes ist als Ziel geplant bzw. soll geprüft werden, ob es geht:

1. openSUSE Leap 16.1 installieren
2. Vollverschlüsselung für NVMe und SSD (/home auf SSD)
3. Entschlüsselung per TPM
4. LXQt mit Wayfire (Wayland) als Oberfläche
5. Apps vornehmlich als Flatpaks, um diese aktuell zu halten. Vor allem für LibreOffice ist das in Hinblick auf Kompatibilität mit OOXML besser.
6. Funktionsfähigkeit des Grafiktablets und Zuordnung zum korrekten Bildschirm
7. Ton muss per HDMI auf einfache Weise ausgegeben werden können

Manches davon scheint trivial, aber der Teufel steckt im Detail.

Ich wähle die Variante ohne immutable Ansatz. Erstens kenne ich mich damit nicht gut aus, zweitens gibt es LXQt nicht als Auswahl als Desktop bei der Installation. D.h. ich müsste dann nach der Installation mit transactional-updates arbeiten usw. und dann kann ich mir auch das immutable sparen - soweit meine aktuelle Einstellung. Dazu brauche ich flatpak-builder, den Flatpak empfiehlt von den Repositories der Distribution zu installieren.

Installation der Distribution

Ich bitte um Entschuldigung für die teilweise schlechten Bilder. Ein paar Optionen gibt es in der VM nicht (bzw. ich weiß nicht, wie man diese provoziert), sodass hier Fotos vom realen Installer auf realer Hardware herhalten müssen.

Die Installation ist soweit recht unspektakulär. Man lädt zuerst die ISO von der Webseite herunter; bei mir das Offline-Image. Das Online-Image hat keine anderen Optionen, soweit ich sehen konnte.

Wir wählen Leap 16.1 und "Standard" aus, akzeptieren die Lizenzbestimmungen.

Dann können wir die einzelnen Aspekte der Installation bearbeiten. Hierbei müssen wir in jedem Schritt wieder auf "Installation" oben klicken, um auf den Überblick zu gelangen. 😑

Tipp: Wählt oben rechts die Sprache und Eingabe-Einstellungen auf Deutsch (bzw. eure Sprache). Leider wird für den Installer Agama nicht das ausgewählt, was man für die Installation selbst bei Sprache einstellt. Andersrum aber schon!... vorausgesetzt man wählt es an... Kurios: Ein mal heißt die Sprache "German", einmal "Deutsch":

Wichtig: Beim Speichermedium auf jeden Fall drauf achten, dass "/" genügend Platz bekommt! Ich musste openSUSE 2x installieren, weil er beim ersten mal <40GB für "/" reserviert hat. 😤 Das ist natürlich viel zu wenig, vor allem da openSUSE Btrfs benutzt, das Snapshots generiert. Für /home auf meiner zweiten Festplatte hat openSUSE Xfs eingerichtet. Da ich mich nicht wirklich mit Dateisystemen auskenne, habe ich das mal so gelassen.

Ich wähle KDE als Desktop-Oberfläche, werde diese aber nachher mit LXQt ersetzen/ergänzen. Da LXQt auch auf Qt aufbaut und ein paar der KDE Frameworks nutzt, ist das für mich eine passende Kombination.

Spannend für mich: Ich kann zwar die TPM-Verschlüsselung anwählen, aber der Warnhinweis sagt mir, dass die fde-tools nicht verfügbar sind. Bedeutet, ich muss mich darum später kümmern, und das trotz Internetverbindung per WLAN! Sehr ärgerlich! Die TPM-Entschlüsselung musste ich folglich abwählen.

Wir haben bei der Authentifizierung die Wahl:

1. Administratorbenutzer (mit und ohne SSH-Schlüssel) erstellen
2. Öffentlichen SSH-Schlüssel (für Root-Benutzer) hinzufügen
3. Root-Benutzer mit Passwort erstellen

Ich wähle einen Administratorbenutzer mit Passwort und deaktiviere die Anmeldung per Root (Standard). Theoretisch kann man sich damit aussperren, wenn die Platte voll läuft, aber mir ist das noch nie passiert.

Hinweis: Verfügbare WLANs kann man über Netzwerk oder "2 more" bei der Angabe der IP-Adresse(n) hinzufügen:

Post-Install

Der erste Schritt nach der Installation sind natürlich die Updates. Da es ein RC ist, gibt es davon doch einige. Wir machen also:

sudo zypper ref
sudo zypper up

zypper ist die Paketverwaltung von openSUSE, die in meinen Augen auch sehr gut ist; "ref" bedeutet "refresh [der Paketlisten]"; "up" bedeutet "upgrade". Wobei ich mir nicht sicher bin, ob "up" nicht auch ein "ref" mit macht... 🤔 Anschließend starte ich das System neu. Das muss man nicht nach jedem Update machen, aber am Anfang halte ich es für sinnvoll. Speziell wenn der Kernel aktualisiert wird, lohnt es sich.

Anschließend benutze ich den grafischen Paketmanager Myrlyn. Dieser löst seit openSUSE 16 den Paket-Manager-Teil von YaST ab und ist mit Qt6 geschrieben - also mit einem aktuellen Software-Stack. Myrlyn wie YaST vorher auch hat einen Reiter "Patterns" bzw. "Schemata". In diesen werden Pakete sortiert aufgelistet bspw. passend für KDE, XFCE aber auch LXQt. Die für LXQt notwendigen bzw. passenden Pakete habe ich mir dort bezogen. Man klickt auf das Kästchen es jeweiligen Pakets, dieses wird zu einem "+" und per Klick auf "Accept" bzw. "Annehmen" werden die Pakete heruntergeladen und installiert. Als Wayland-Compositor habe ich Wayfire gewählt. Es ist recht leichtgewichtig, bietet aber bspw. IPC-Anbindung, sodass Tastaturkürzel und weiteres funktionieren.

Schön finde ich die grafische Darstellung des Prozesses.

Zusätzlich habe ich mir Flatpak mit dem Flathub-Repository eingerichtet. Darüber beziehe ich (aktuellere oder "fehlende") Pakete, aber auch meine Notenverwaltung installiere ich über flatpak-builder, das ich ebenfalls installiert habe. Zu den "Pflicht-Programmen" für mich zählen unter anderem:

1. PDF Arranger (solange Imprint noch nicht verfügbar ist)
2. LibreWolf
3. Chromium (für Schulwebseiten, kein Kommentar...)
4. Xournal++
5. KeePassXC (+ Flatpak-Browser-Fix)
6. (GNOME) Vaults
7. Kile + Texlive

TPM-Entschlüsselung

openSUSE hat die fde-tools in den Repositories. Dieses Werkzeug kommt von ALP und kümmert sich eine vereinfachte Ent-/Versiegelung von TPM. Wenn ich das richtig vestehe: Damit soll man also bspw. die Passwörter zur Verschlüsselung im TPM versiegeln können. Dadurch muss man diese nicht mehr eintragen. Die Sicherheit ist insofern weiter gewährleistet, dass nur die Kombination aus Platte + TPM die Passwörter hergibt. Sie liegen also nicht "frei rum".

Die Seite auf Github beschreibt das Vorgehen zum Glück gut, wenn auch auf Englisch.

Hinweis: Alle Befehle müssen als root oder über sudo ausgeführt werden. Ich spare mir das in den Listings.

Zunächst prüfen wir, ob ein TPM vorhanden und erreichbar ist.

fdectl tpm-present

Über

fdectl tpm-disable
fdectl tpm-enable

können wir das TPM (de-)aktivieren. Und über

fdectl tpm-wipe

können wir eingetragene Schlüssel löschen.

Anmerkungen:

1. Jetzt wird es etwas "experimentell", weil ich mir nicht sicher bin, ob ich alles richtig verstanden habe. Wichtig ist: Die folgenden Maßnahmen haben nichts "kaputt" gemacht, aber die Entschlüsselung per TPM hat bei mir nicht vollständig funktioniert.
2. Da die Entschlüsselung der Swap-Partition über TPM nicht funktionieren wollte, habe ich versucht, die Swap-Partition zu deaktivieren und durch ein Swapfile zu ersetzen. Und das obwohl beim Einfügen der Schlüssel (siehe unten) die entsprechende Partition immer mit gelistet wurde. Leider hat auch das nicht funktioniert.

Zunächst tragen wir alle Geräte ein, für die ein Schlüssel im TPM hinterlegt werden soll. Das geschieht in der Datei /etc/sysconfig/fde-tools . Dort gibt es einen Eintrag namens 

# Specify the devices to be managed by fdectl
# NOTE: Those devices must use the same recovery password.
FDE_DEVS=""

Welche Devices tragen wir da ein? Quasi alle, die ein cr_... unter sich haben. Per lsblk kann man sich alle Blockdevices aka Platten, Partitionen,... anzeigen lassen. Bei mir sieht das so aus:

$ lsblk
sda           8:0    0 465,8G  0 disk  
└─sda1        8:1    0 465,8G  0 part  
  └─cr_home 254:2    0 465,7G  0 crypt /home
nvme0n1     259:0    0 238,5G  0 disk  
├─nvme0n1p1 259:1    0   512M  0 part  /boot/efi
├─nvme0n1p2 259:2    0   236G  0 part  
│ └─cr_root 254:0    0   236G  0 crypt /var
│                                      (...)
└─nvme0n1p3 259:3    0     2G  0 part  
  └─cr_swap 254:1    0     2G  0 crypt 

Ich brauche also nvme0n1p2 und sda1, jeweils mit einem /dev/ vornedran. nvme0n1p3 ist die Swap-Partition, mit der es nicht geklappt hat, egal, ob sie da gelistet war oder nicht.

# Specify the devices to be managed by fdectl
# NOTE: Those devices must use the same recovery password.
FDE_DEVS="/dev/nvme0n1p2 /dev/sda1"

Anschließend reicht ein

$ fdectl regenerate-key

Das läuft dann durch, wobei der Output mir zu lang war, um ihn hier abzulichten. Schließlich werden Grub, / und /home per TPM ohne Eingabe des Passworts entschlüsselt.

Anmerkung: openSUSE ist die einzige mir bisher begegnete Distribution, die standardmäßig bei FDE auch den Grub mit verschlüsselt.

Grafiktablet-Test

Zusammenfassung: Anschließen. Geht.

... Leider nicht die Zuordnung des Stifts zum entsprechenden Display. Das lässt sich über Wayfire aber zum Glück beheben! Und zwar garnicht so kompliziert, wie ich mir das vorgestellt habe. Die Schritte:

Schritt 1: Identifizieren des korrekten Bildschirms

via:

wlr-randr

oder alternativ das grafische Programm WDisplays. Bei mir ist das HDMI-A-1.

Schritt 2: Herausfinden des Namens des Stifts

Dies schauen wir mittels libinput nach, für das ich zuerst das Paket "libinput-tools" installieren musste.

sudo libinput list-devices | grep "Device"

An der Stelle heißt es suchen... Wir brauchen wirklich nur diesen "Namen" inklusive Leerzeichen etc.. Bei mir: "Wacom One Pen Display 13 Pen".

Schritt 3: Eintragen in Wayfire

Leider gibt es keine (mir bekannte) GUI dafür. Das heißt wir müssen die wayfire.ini bearbeiten, die für LXQt hier liegt: ~/.config/lxqt/wayland/lxqt-wayfire.ini . Immerhin brauchen wir dafür keine Root-Rechte, sodass das hier reicht:

nano ~/.config/lxqt/wayland/lxqt-wayfire.ini

Dort tragen wir folgenden Code ein:

[input-device:DEVICE NAME]
output = OUTPUT

Für mich also:

[input-device:Wacom One Pen Display 13 Pen]
output = HDMI-A-1

Anschließend musste ich den Wacom-Bildschirm ein mal aus- und einschalten und dann ging es - schwierig, hier ein Beweisbild dafür zu zeigen. Glaubt es mir einfach. 😅

Hinweis: Das geht nur so lange gut, wie derselbe HDMI-Anschluss genutzt wird. Zumindest war das bei mir so. Denn ein anderer HDMI-Anschluss bekommt einen anderen Namen.

HDMI- + Ton-Test

Zu meiner Überraschung: Anschließen -> geht. 👍️

Fazit

Ein Check der Liste zeigt:

1. openSUSE Leap 16.1 installieren ✅
2. Vollverschlüsselung für NVMe und SSD (/home auf SSD) ✅
3. Entschlüsselung per TPM ❌
4. LXQt mit Wayfire (Wayland) als Oberfläche ✅
5. Apps vornehmlich als Flatpaks, um diese aktuell zu halten. Vor allem für LibreOffice ist das in Hinblick auf Kompatibilität mit OOXML besser. ✅
6. Funktionsfähigkeit des Grafiktablets und Zuordnung zum korrekten Bildschirm ✅
7. Ton muss per HDMI auf einfache Weise ausgegeben werden können ✅

Probleme, die ich noch bemerkt habe:

• nm-tray existiert nach Start zwei mal - beide reagieren aber nicht auf Linksklick, sodass ich keine WLANs oder VPNs auswählen kann. Hier musste ich mit "env QT_QPA_PLATFORM=xcb nm-tray" einen Umweg gehen.
• Qt-Flatpaks übernehmen nicht das global gesetzte Theme.

openSUSE Leap 16.1 bleibt bei mir auf jeden Fall auf der Platte. Es läuft stabil und macht das, was ich von ihm will. Die Vollverschlüsselung und gute Performanz erfreuen mich. LXQt in Version 2.4 ist gut gereift, ist und bleibt aber ein System, das man anpassen wollen muss. Aber soweit ich das Projekt verstehe, ist das auch so gewollt. 👍️

Quellen

1. https://get.opensuse.org/leap/16.1/
2. https://github.com/openSUSE/fde-tools
3. https://github.com/shundhammer/myrlyn 
4. https://flathub.org/de/setup/openSUSE 
5. https://en.opensuse.org/SDB:Partitioning#Creating_a_btrfs_swapfile
6. https://codeberg.org/sockenklaus/keepassxc-flatpak-browser-fix 

Mozilla hat mit Firefox 158.0.1 ein Korrektur- und Sicherheits-Update veröffentlicht. Dieser Artikel beschreibt die Änderungen des neuesten Updates.

Download Mozilla Firefox 158.0.1

Mit dem Update auf Firefox 158.0.1 behebt Mozilla mehrere Sicherheitslücken. Zwei davon stuft Mozilla als hohes Risiko ein.

Außerdem reagiert Mozilla auf die Kompromittierung privater Schlüssel von acht Zwischenzertifikaten der Zertifizierungsstelle eMudhra. Mozilla hatte die betroffenen Zertifikate bereits am 17. Oktober über seine zentrale Zertifikatssperrliste OneCRL gesperrt. Innerhalb von weniger als drei Stunden nach Eingang der Meldung war die Verteilung für Firefox-Nutzer mit Standardeinstellungen abgeschlossen. Dafür war weder ein Firefox-Update noch ein Neustart des Browsers notwendig. Firefox 158.0.1 enthält die aktualisierte Sperrliste zusätzlich direkt und schützt damit auch Nutzer, bei denen die Verteilung über die sogenannten Remote Settings beispielsweise durch Unternehmensrichtlinien deaktiviert oder aufgrund der Netzwerkumgebung nicht möglich ist.

Darüber hinaus behebt Firefox 158.0.1 ein Problem, durch welches Websites beim Markieren von Text unerwartet an den Seitenanfang springen konnten.

Unter Windows konnte Firefox beim Drucken oder Speichern einer Seite als PDF abstürzen, wenn gleichzeitig ein Screenreader oder eine andere assistive Technologie ausgeführt wurde.

Unter Linux wurden Fenster bei Verwendung mehrerer Bildschirme unter Umständen auf dem falschen Bildschirm geöffnet.

Eine weitere Korrektur betrifft das in Firefox integrierte VPN, welches sich für manche Nutzer nicht aktivieren ließ.

Unter macOS konnten Dateien, die aus anderen Anwendungen in Firefox gezogen wurden, nicht auf der Website abgelegt werden.

Bei bestimmten Bildern im JPEG XL-Format wurden halbtransparente Bereiche zu dunkel dargestellt.

Eine Verbesserung der Barrierefreiheit betrifft die klassische Lesezeichen-Sidebar. Screenreader erkannten deren Lesezeichen-Baumstruktur unter Umständen nicht korrekt.

Außerdem wurde ein Problem in der JavaScript-Engine behoben, durch welches das wiederholte dynamische Importieren von Modulen zu einem stetig wachsenden Speicherverbrauch führen konnte.

Weitere Korrekturen betreffen mögliche Abstürze beim Programmstart. Dazu zählt ein Problem beim Laden interner JavaScript-Module, welches unter anderem die Drittanbieter-Lösung „PWAs for Firefox“ betraf. Unter Windows wurden außerdem Schutzmaßnahmen gegen Startabstürze implementiert, die durch unterschiedliche Versionen interner Programmdateien nach einem fehlgeschlagenen Update entstehen konnten. Eine weitere potenzielle Absturzursache in Zusammenhang mit Service Workern wurde ebenfalls behoben.

Der Beitrag Mozilla veröffentlicht Sicherheits-Update Firefox 158.0.1 erschien zuerst auf soeren-hentzschel.at.

Mozilla hat Version 2.40 seiner VPN-Clients für das Mozilla VPN veröffentlicht.

Mit dem Mozilla VPN bietet Mozilla in Zusammenarbeit mit Mullvad sein eigenes Virtual Private Network an und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.

Jetzt Mozilla VPN nutzen

Die Neuerungen vom Mozilla VPN 2.40

Das Update auf das Mozilla VPN 2.40 bringt keine großen Neuerungen, sondern fokussiert sich auf Fehlerbehebungen und Verbesserungen unter der Haube.

Der Beitrag Mozilla VPN 2.40 veröffentlicht erschien zuerst auf soeren-hentzschel.at.