Die nun vorliegende Version 5.25 der KDE Plasma Desktopumgebung stellt einen Meilenstein in der Entwicklung dar. Das Augenmerk lag dabei vorwiegend auf der Verbesserung des Benutzererlebnisses.
So wurde beispielsweise die Übersichtsseite erneuert und neben den aktuell geöffneten Fenstern, werden nun auch virtuelle Arbeitsflächen angezeigt. Ein direktes Ablegen von Fenstern auf Arbeitsflächen ist ebenfalls möglich.
Durch die Integration von krunner können direkt aus der Übersicht weitere Applikationen gestartet werden. Wie bereits zuvor, lässt sich die Übersicht durch eine 4-Finger-Pinch Geste öffnen. Neu ist allerdings auch eine Gestensteuerung auf Touchscreens möglich. So lassen sich beispielsweise mittels 3-Finger-Swipe Geste auf dem Touchpad die virtuellen Arbeitsflächen umschalten.
Auf einem Touchscreen lassen sich die Gesten über eine Wischbewegung von den Bildschirmrändern initiieren. Damit eignet sich die Desktopumgebung ideal für eine Nutzung auf Geräten mit abnehmbaren Touchscreen oder Touchpads. Dabei wird der Moduswechsel automatisch erkannt und der Touchmodus lässt sich bei Bedarf aktivieren.
Die Akzentfarbe lässt sich ähnlich wie bei GNOME bereits seit längerem anpassen, doch KDE Plasma wäre nicht KDE Plasma, wenn es nicht noch weitere Einstellmöglichkeiten bieten würde. So kann die Akzentfarbe so gewählt werden, dass sie sich automatisch an das aktuelle Hintergrundbild anpasst.
Sogenannte Floating Panels ermöglichen ein schwebendes Panel-Layout, bei dem die Taskleiste automatisch am Bildschirmrand platziert wird, sobald ein Fenster maximiert dargestellt wird.
Darüber hinaus wurde die Darstellung der verfügbaren Anwendungen in Discover verbessert und der Anmeldemanager gibt visuelles Feedback, sofern ein Passwort falsch eingetippt wurde.
Die KWin Scripts Einstellungen wurden überarbeitet und erlauben eine einfachere Verwaltung von Windowmanager-Scripten.
Das KDE-Projekt hat sich nicht nur bei der Verbesserung der Software sehr viel Mühe gegeben, auch die Release-Ankündigung ist eindrücklich. Viele der neuen Funktionen werden in Videos gezeigt und in Hinweisboxen werden die Möglichkeiten zur Einstellung der jeweiligen Optionen genannt.
Die MZLA Technologies Corporation hat heute bekannt gegeben, die bekannte Android-App K-9 Mail zu übernehmen. Aus dieser wird Thunderbird für Android entstehen.
Wie bereits vor wenigen Wochen berichtet, wird es den beliebten E-Mail-Client Thunderbird in Zukunft auch für Android geben. Grundlage hierfür wird mit K-9 Mail die wohl bekannteste Open Source Mail-App für Android werden, wie die Mozilla-Tochter MZLA Technologies Corporation heute bekannt gegeben hat.
Bevor es jedoch einen offiziellen Thunderbird für Android geben wird, wird zunächst einiges an Arbeit in K-9 Mail fließen. Christian Ketterer, Projektleiter von K-9 Mail, arbeitet bereits in Vollzeit für MZLA. Das Thunderbird-Projekt wird sowohl Geld als auch Entwicklungszeit in die Weiterentwicklung von K-9 Mail stecken. Das Ziel ist es, K-9 Mail sowohl funktional als auch optisch in Einklang mit Thunderbird zu bringen, ehe dann K-9 Mail offiziell zu Thunderbird für Android werden wird. Wer die Entwicklung der Android-App unterstützen möchte, kann dies ab sofort auf Mozillas neuer Spenden-Seite für K-9 Mail machen.
Zu den geplanten neuen Thunderbird-Features für K-9 Mail gehören unter anderem eine automatische Konfiguration neuer E-Mail-Accounts, eine verbesserte Ordner-Verwaltung sowie Nachrichten-Filter. Im Sommer 2023 soll es eine Integration mit dem Firefox-Konto geben, um Thunderbird-Accounts mit denen von K-9 synchronisieren zu können.
Konkrete Pläne für einen potentiellen Thunderbird für iOS gibt es noch keine, das Team evaluiert nach eigenen Angaben diese Möglichkeit aktuell aber.
Nur drei Wochen nach der Veröffentlichung von Alpine Linux 3.16 konnten die Entwickler von postmarketOS eine neue, darauf basierende Version bereitstellen.
Der aktuelle Release richtet sich vornehmlich an Entwickler und Enthusiasten und es werden mit dem SHIFT 6mq und dem Samsung Galaxy S III zwei weitere Geräte unterstützt, wodurch sich die Anzahl der unterstützten Devices auf 27 erhöht.
Dank eines nun zur Verfügung stehenden Scripts ist eine Aktualisierung einer Vorgängerversion mit Sxmo, Phosh oder Plasma Mobile möglich. Aktuell muss der Vorgang über die CLI gestartet werden und das entsprechende Paket muss zunächst installiert werden:
In Zukunft soll dies auch mittels Hook über die grafischen Paketverwaltungsutilitys GNOME Software und KDE Discover ermöglicht werden. Mit der Version v22.06 wurden auch die folgenden verfügbaren grafischen Oberflächen aktualisiert:
Sxmo 1.9.0 unterstützt Geräteprofile und bringt eine verbesserte Bluetooth-Unterstützung mit. Als Audio-Backend kommt standardmässig Pipewire zum Einsatz. Das Incall-Menü und die Audio-Verwaltung wurden verbessert, ebenso wie superd, welches zur Überwachung von Benutzerdiensten verwendet wird.
Phosh 0.17.0 enthält kleinere Verbesserungen gegenüber der Version 0.15.0, welche seit v21.12 SP2 im Stable-Zweig der Distribution enthalten ist. Die GNOME-Basis wurde auf Version 42 aktualisiert, und eine Vielzahl der enthaltenen GTK-Anwendungen wurden auf GTK4 und libadwaita portiert. Um das Fehlen einer standardmässig installierten Kalenderanwendung auszugleichen, wird aktuell karlender ausgeliefert.
Eine detaillierte Übersicht der in Plasma Mobile Gear 22.04 enthaltenen Verbesserungen, gegenüber der Version Plasma Mobile Gear 21.12, welche mit postmarketOS v21.12 ausgeliefert wurde, ist auf der Homepage des Projektes zu finden.
PinePhone-Benutzer können mittels fwupd ihr Modem jetzt auf die alternative Firmware von Biktor auf v22.06 aktualisieren. Der bisher enthaltene DHCP Server, welcher bei einer Verbindung eines Telefons mit einem PC über USB, automatisch eine IP-Adresse zuweisen kann, um einen Zugriff via SSH zu ermöglichen, wurde auf unudhcpd umgestellt.
Wer Red Hat Enterprise Linux (RHEL) betreiben möchte, benötigte dazu eine sogenannte Subskription, im Folgenden RHEL-Sub genannt. Die Kosten für eine RHEL-Sub ergeben sich aus der Art der RHEL-Sub und dem damit verbundenen Service-Level. Der schon etwas ältere Artikel Support-Subskriptionen von SUSE und Red Hat gibt hierzu einen kleinen Einblick.
Da RHEL-Klone wie AlmaLinux und Rocky Linux kostenlos verfügbar sind, kommt schnell die Frage auf: „Warum soll ich für RHEL soviel Geld bezahlen, wenn ich quasi das gleiche OS unter anderem Namen kostenlos nutzen kann?“
Um bei der Beantwortung dieser Frage zu helfen, stelle ich in diesem Artikel einige potenzielle Mehrwerte vor, die man mit dem Erwerb einer RHEL-Sub erhält.
Aus Gründen der Transparenz weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community und System-Administrator diverser RHEL-Server bin. Dieser Text gibt ausschließlich meine persönlichen Ansichten und nicht die von Red Hat oder die meines Arbeitgebers wieder. Zwar können diese in einzelnen Punkten übereinstimmen, müssen es aber nicht.
Kostenlose RHEL-Subs
Nicht alle RHEL-Subs kosten Geld. Es gibt auch zwei Subskriptionen, mit denen sich RHEL und bestimmten Rahmenbedingungen kostenlos betreiben lässt.
Die Subskription muss jedes Jahr verlängert werden. Die Verlängerung ist ebenfalls kostenlos.
Die Subskription beinhaltet keinen kommerziellen Support. Man hat lediglich Zugriff auf die Wissensdatenbank und die Customer Portal Community. Die SaaS-Dienste Red Hat Insights und Image Builder können auch mit dieser Subskription genutzt werden.
Red Hat Developer Subscription for Teams
Im Unterschied zur oben vorgestellten individuellen Subskription dürfen Systeme mit der RHEL-Sub-for-Teams nicht in Produktion betrieben werden. Sie dient ausschließlich der Entwicklung, dem Test und der Qualitätssicherung. Dafür dürfen mit dieser Sub eine sehr große Anzahl RHEL-Systeme provisioniert werden.
Ich bin mir nicht sicher, ob ich eine genaue Zahl nennen darf. Darum glaubt mir bitte, wenn ich euch sage: „Es sind wirklich eine Menge Berechtigungen für physische und virtuelle Systeme enthalten.“
Diese Subskription erhaltet ihr nur über euer Red Hat Account Management. Falls ihr dieses (noch) nicht kennt, wendet euch im Zweifel an die Firma, wo ihr eure RHEL-Subs kauft.
Mich selbst hat es einige Mühen gekostet, an diese Sub zu kommen. Laut Aussage meines Account-Managers war ich der erste Kunde in Deutschland, der diese Sub kannte und haben wollte. Dank der Red Hat Accelerators und meines Account-Managers, der nicht aufgegeben hat, hat es schlussendlich geklappt. Falls ihr Probleme habt, diese Sub zu bekommen, schreibt mich einfach an. Vielleicht habe ich noch einen Tipp für euch.
Für den Support, Zugriff auf Red Hat Insights und Image Builder gelten die gleichen Bedingungen wie für die RHEL Developer Subscription for Individuals.
Support
Support meint an dieser Stelle nicht die Hilfe und Unterstützung, die man auf Mailinglisten, in Foren oder Chats erhalten kann. Gemeint ist ausschließlich der kommerzielle Support der Firma Red Hat, welchen man per Telefon, E-Mail oder das Customer Portal erreichen kann.
Über den Support hat man Kontakt zu den Menschen, die sich vermutlich am besten mit dem Produkt auskennen. Hier sitzen Menschen, die dafür bezahlt werden, uns Kunden bestmöglich zu unterstützen. Dabei mag es von Fall zu Fall Schwankungen in der Reaktionszeit und/oder der Qualität geben.
Mir persönlich hat der Support schon in etlichen Fragestellungen und bei einigen hartnäckigen Problemen weiterhelfen können. Dabei waren so schöne Dinge wie Kernel Panic bei Zugriff auf eine eingehängte DFS-Ressource, deren Shares in einer HNAS-Speicher-Infrastruktur liegen. Ich glaube, sowas haben die wenigsten Menschen bei sich daheim im Keller stehen. Und die Chance, bei diesem Problem Hilfe in einem Forum oder Chat zu finden, dürfte dementsprechend gering sein. Der Support stellte in diesem Fall Kontakt zu einem Engineer her, der über eine hervorragende Kenntnis der beteiligten Protokolle und Protokollversionen verfügte und beim Debugging unterstützte. Am Ende erhielten wir einen angepassten Kernel, der das Problem löste und den wir nutzen konnten, bis das Problem auch Upstream und im regulären RHEL-Kernel gefixt wurde.
Nicht zuletzt ist kommerzieller Support ein guter Verbündeter, wenn man selbst nicht weiterweiß und sich Druck aufbaut. Nach dem Motto: „Wenn selbst der Hersteller nicht weiter weiß, woher soll ich dann wissen, warum es nicht geht?“ Es ist nie schön, wenn es soweit kommt. Noch hässlicher wird es, wenn man dann nicht auf jemand anderen zeigen kann.
Red Hat Insights
Zu Red Hat Insights (engl.) habe ich in der Vergangenheit bereits eine eigene Serie geschrieben, auf die ich an dieser Stelle verweise:
Dieser Dienst steht auch mit den kostenlosen Developer-Subs zur Verfügung. Vorausgesetzt, die Nutzung ist unter geltendem Recht möglich, stellt dieser Dienst einen echten Mehrwert dar. Ein vergleichbarer Dienst existiert für AlmaLinux und Rocky Linux nicht.
Image Builder (SaaS)
In größeren Umgebungen (IHMO >2 Systeme) werden Server meist nicht mehr individuell installiert, sondern von sogenannten Images oder Templates provisioniert. Diese sind initial zu erstellen und fortlaufend zu pflegen.
Image Builder ist ein SaaS-Dienst in Red Hat Insights, welcher bei der Erstellung solcher Templates unterstützt. Dabei können Images direkt für die Cloud Anbieter Amazon Web Services, Google Cloud Platform, Microsoft Azure, VMware vSphere, KVM/QEMU (.qcow2) und Bare Metal erstellt werden.
Es handelt sich dabei um einen noch recht jungen Dienst, der einige Einschränkungen hat. So ist das einzige derzeit unterstützte Dateisystem für Images XFS. Ein RFE, um Ext4 als unterstütztes Dateisystem hinzuzufügen, ist gestellt.
Auch lassen sich aktuell über diesen Dienst noch keine User oder SSH-Public-Keys in die Images integrieren. Für diese Funktionalität habe ich ebenfalls bereits RFEs geschrieben.
Ich bin gespannt, wie Red Hat diesen Dienst weiterentwickelt. In meinen Augen hat er das Potenzial, zu einem nützlichen Werkzeug zu reifen.
Diesen Dienst kann man ebenfalls mit den kostenlosen Developer-Subs nutzen, während ein vergleichbarer Dienst meines Wissens für AlmaLinux und Rocky Linux nicht existiert.
Fazit
Ob die genannten Mehrwerte tatsächlich zum Tragen kommen, muss jeder für sich und seine Organisation selbst beurteilen. Sie sollten jedoch vor einer Entscheidung in die Überlegungen mit einbezogen werden.
Die Nutzung von Red Hat Insights ist in unserem Rechtsraum schwierig, bis nahezu unmöglich. Dort wo der Dienst genutzt werden kann, stellt er ein gutes Werkzeug dar, welches dem Admin die tägliche Arbeit erleichtert.
Ich werde ein kleines Heimlabor aus RHEL-Servern aufbauen und diese in Red Hat Insights integrieren. Vielleicht gewinne ich dadurch Erkenntnisse, die sich auch auf den Betrieb im Rechenzentrum übertragen lassen.
Der Image Builder ist als SaaS in seiner jetzigen Form nur von geringem Nutzen für mich. Ich hoffe, dass meine RFEs akzeptiert und umgesetzt werden, um diesen Service und dessen Nutzen weiter auszubauen.
Die FIDO-Allianz (Fast Identify Online) ist vor nunmehr 10 Jahren angetreten, um uns endlich von Passwörtern zu erlösen und eine neue sichere Authentifzierungsmethode zu schaffen. Der große Durchbruch blieb leider bisher aus. Das könnte sich aber hoffentlich in den nächsten Jahren ändern.
Die von der FIDO-Allianz entwickelten Standards kennen sicher viele Anwender, die sich mit Sicherheit ein bisschen mehr beschäftigt haben. U2F als Standard für die Zwei-Faktor-Authentifizierung und etwas weniger bekannt UAF als Netzwerkprotokoll. Zusammengefasst in den FIDO-Standard, der als in Zusammenarbeit von FIDO-Allianz und W3C vor einigen Jahren als kommende Authentifizierungslösung für Internetdienste angekündigt wurde.
Die meisten Anwender werden FIDO praktisch mit Security-Keys wie YubiKey oder NitroKey verbinden. Ich bin selbst Besitzer eines YubiKey und arbeite gerne damit, aber eine wirklich umfangreiche Verbreitung hat der noch nicht gefunden. Ein paar Webseiten bieten das an, aber bei der Mehrheit darf man schon froh sein, wenn es Zwei-Faktor-Authentifizierung per TOTP und App auf dem Smartphone gibt. Selbst Linux bietet erst seit Kurzem die Möglichkeit damit LUKS-Container abzusichern. Damit ist Linux leider nicht alleine, denn Google hat FIDO nie richtig in Android implementiert, sondern nur in den proprietären Google-Bestandteilen. Anwender von Aftermarket-Lösungen schauen damit in die Röhre.
Manche hoffnungsvollen Projekte siechen dann vor sich hin und werden irgendwann eingestellt. Nicht so FIDO. Die großen Anbieter haben damit immer weiter experimentiert und es sukzessive in ihre Betriebssysteme integriert. Denn die Ablösung von Passwörtern als primäre Authentifizierungsmethode ist ein drängendes Problem und FIDO die naheliegendste Lösung.
Einen neuen umfassenden Anlauf kündigen Microsoft, Apple und Google am Welt-Passwort-Tag an. Damit sind die Entwicklerfirmen aller wichtigen Betriebssysteme – Windows, Android, ChromeOS, iOS, macOS – an Bord. Noch ist die Umsetzung nicht ganz klar, denn die aktuellen Methoden sind noch viel zu umständlich für die breite Masse der Anwender. Irgendwie müssen die FIDO-Zugangsdaten (oft als „Passkey“ bezeichnet) also zwischen den Geräten ausgetauscht werden. Für die reaktionären Alles-Hasser natürlich eine Steilvorlage, um wieder alles Mögliche zu unterstellen. Aber dennoch ist klar, dass es eine Weiterentwicklung des Standards braucht, der leichtere Bedienbarkeit mit einem hohen Sicherheitsniveau verbindet. Dazu ist der Bericht von Andreas Proschofsky in DerStandard aus dem Pressegespräch mit dem Google-Verantwortlichen sehr interessant zu lesen.
Das ist alles nicht nur Zukunftsmusik. Vor wenigen Tagen kündigte Apple die nächste Version seiner Betriebssysteme an, die eine entsprechende Funktion beinhaltet. Ich vermute, dies wird vorerst auf das Apple-Universum beschränkt sein, weil Microsoft und Google noch nicht so weit sind, aber der Weg ist vorgezeichnet. Hoffentlich bekommt Linux da dann ebenfalls noch einen Fuß in die Tür.
Wer Podcasts gerne zum späteren Anhören oder zu Archivierungszwecken herunterladen möchte, kann dies beispielsweise mit gPodder tun. Automatisieren lässt sich dies mit dem Kommandozeilen-Programm castget.
Zur Installation aus den Quellen müssen zunächst die entsprechenden Build-Abhängigkeiten installiert werden. Auf einem Debian GNU/Linux System in der Version 11 (Bullseye) erfolgt dies mit folgendem Befehl:
Nach dem Herunterladen des aktuellen Quellcodes von der Projekthomepage, kann das Archiv entpackt werden und der Compiliervorgang im Verzeichnis des entpackten Archivs gestartet werden.
./configure
make
sudo make install
Die Konfiguration erfolgt in der Datei ~/.castgetrc und sie hat folgenden Aufbau:
Das angegebene Spool-Verzeichnis muss vorab erstellt werden. Die Konfigurationsdatei kann mehrere Einträge dieser Art enthalten. Globale Einstellungen lassen sich wie folgt setzen:
[*]
id3contenttype=Podcast
Der Download lässt sich daraufhin mit folgendem Befehl starten:
castget -vrp
Als Parameter können die Namen der in der Konfigurationsdatei in eckigen Klammern angegebenen Podcasts angegeben werden, um nur einzelne Podcasts herunterzuladen oder zu aktualisieren.
Die Angabe von -r stellt sicher, dass ein bereits zuvor begonnener Download fortgesetzt wird. -v (verbose) und -p (progress-bar) dienen lediglich der optischen Darstellung und sind bei einer Verwendung beispielsweise über einen cronjob nicht notwendig.
Mit dem Update auf Firefox 101.0.1 behebt Mozilla ein Problem in Zusammenhang mit der in Firefox 100.0.1 eingeführten verbesserten Prozess-Isolation, welches für einen kleinen Teil der Windows-Nutzer verursachen konnte, dass Firefox nicht mehr funktioniert hat.
Ebenfalls Windows betrifft eine potentielle Absturzursache beim Beenden von Firefox, welche mit dem Update aus der Welt geschafft worden ist.
Auf macOS wurde ein Problem behoben, welches verursachte, dass Firefox den Inhalt der Zwischenablage vergessen hat, wenn Firefox beendet worden ist.
Speziell Linux-Nutzer waren von einem Problem mit dem Bild-im-Bild-Modus für Videos betroffen, wo das Kontextmenü nicht mehr funktionierte.
Behoben wurde außerdem ein Absturz auf Systemen mit Overlay-Scrollbalken bei Verwendung von Firefox in einer Sprache, in der von rechts nach links geschrieben wird, der auftrat, wenn der Info-Dialog einer Website aufgerufen worden ist.
Außerdem gab es noch eine Kompatibilitäts-Anpassung für Microsoft Teams.
LUKS ist ein tolles, sicheres und variantenreiches Werkzeug für Verschlüsselung unter Linux. Lediglich für verschlüsselte Container war bisher einiges an Handarbeit notwendig. Abhilfe schafft hier luckyLuks
Ein sehr mächtiges Werkzeug für diesen Bereich ist zuluCrypt, das durch seine vielfältigen Optionen und zahlreichen möglichen Backends aber auch manchen Einsteiger überfordern kann.
Für diese Lücke gibt es nun luckyLUKS. Eine relativ simple Qt-Oberfläche mit der sich verschlüsselte Container erzeugen und benutzen lassen. Neben LUKS unterstützt luckyLUKS auch TrueCrypt- und VeraCrypt-Container. Das ist sehr praktisch, da VeraCrypt (TrueCrypt sollte man wirklich nicht mehr nutzen!) bei keiner Distribution in den Paketquellen enthalten und die Installation deshalb immer ein bisschen nervig ist. Die Unterstützung für TrueCrypt bzw. VeraCrypt ist keine Eigenentwicklung, sondern basiert auf dem bewährten tc-play.
luckyLUKS ist bei Ubuntu 22.04 „Jammy Jellyfish“ in den Paketquellen enthalten und auch bei Debian Testing. In anderen Distributionen ist es noch nicht gelandet, diese müssen mit dem auf GitHub zu findenden Python-Download vorliebnehmen.
$ sudo apt install luckyluks
Die Erzeugung neuer Container erfolgt im Reiter Create New Container. Bei der Erstellung kann der Anwender im Abschnitt „Advanced“ zusätzlich wählen, ob er LUKS oder TrueCrypt im Hintergrund nutzen möchte. Ebenso kann das Dateisystem gewählt werden. Zur Wahl stehen ext2/4 oder NTFS. Hierbei ist zu beachten, dass alle verwendeten Betriebssysteme das Dateisystem unterstützen müssen. Arbeitet man nur mit Linux-Systemen ist ext4 eine gute Wahl. Soll der Container auch für Windows-Anwender nutzbar sein, wäre NTFS vermutlich klüger.
Anstelle eines Passworts kann auch eine Schlüsseldatei genutzt werden. Diese Methode bietet sich vor allem an, wenn man den Container in der Cloud ablegt (die Schlüsseldatei natürlich nicht!) und hier ein wenig mehr Sicherheit als bei normalen Passwörtern haben will. Wenn Container und Schlüsseldatei auf dem gleichen System verbleiben, erzeugt dieses Vorgehen kaum Mehrwert.
Die eigentliche Erstellung eines Containers ist dann recht einfach gehalten. Notwendig ist nur ein Dateiname und eine definierte Größe. Die Schlüsseldatei kann man leer lassen und das Passwort wird erst im nächsten Schritt festgelegt. Die UX der Oberfläche ist hier nicht ganz intuitiv.
Nach der Betätigung des Buttons Create fragt luckyLUKS das Kennwort ab. Hier gilt wie immer zu beachten, dass die Qualität des Kennworts über die Sicherheit der verschlüsselten Daten entscheidet.
Die verschlüsselten Container können über den Reiter Unlock Container eingebunden werden. Der Container wird als Laufwerk unter /media/<benutzer>/ eingehängt und kann dort wie ein normales Laufwerk verwendet werden.
Ein paar kleinere Bugs gibt es noch und die Oberfläche ist nicht ganz selbsterklärend, aber luckyLUKS schließt eine Lücke im Umgang mit LUKS- bzw. TrueCrypt-Containern unter Linux.
Ein Befehl zum Sortieren fehlt im KDE Texteditor Kate. Das ist insofern ungeschickt, weil so eine Funktion einfach integriert doch oft weiter hilft. Allerdings kann diese Funktion auf einem Linux System recht einfach durchgeführt werden, indem das Kommandozeilen Programm „sort“ benutzt wird. Dazu muss lediglich die Tastenkombination Strg+AltGr+\ oder im Menü „Extras – Filtern durch Befehl (Strg+\)“ aufgerufen werden.
Markiert man vorher einen Bereich, z.B. mehrere Zeilen mit einer Nummerierung, dann werden nur diese Zeilen dem aufgerufenen Programm übergeben.
So werden Zeilen dann einfach mit Strg+\ und der Eingabe „sort“ in die richtige Reihenfolge gebracht. WENN denn die Zahlen am Anfang für sich alleine stehen
Sort hat einige Parameter und vermutlich wird meist der Parameter „-V“ natural sort of (version) numbers within text“ gesucht, da dieser Parameter das so sortiert, wie wir das meist manuell machen würden.
sort -V
sort
1 2 3 20 30
1 2 20 3 30
Mit „sort -V“ werden zum Beispiel auch Nummer 1, Nummer 2, Nummer 3, Nummer 30 ordentlich sortiert.
Wer noch mehr Sortier-Parameter von sort erfahren möchte, gibt einfach „man sort“ auf der Kommandozeile ein.
Viel Spaß beim Sortieren.
PS: Kate gibt es übrigens auch als Windows und als Mac Version hier zum Runterladen
Ein Befehl zum Sortieren fehlt im KDE Texteditor Kate. Das ist insofern ungeschickt, weil so eine Funktion einfach integriert doch oft weiter hilft. Allerdings kann diese Funktion auf einem Linux System recht einfach durchgeführt werden, indem das Kommandozeilen Programm “sort” benutzt wird. Dazu muss lediglich die Tastenkombination Strg+AltGr+\ oder im Menü “Extras - Filtern durch Befehl (Strg+\)” aufgerufen werden.
Markiert man vorher einen Bereich, z.B. mehrere Zeilen mit einer Nummerierung, dann werden nur diese Zeilen dem aufgerufenen Programm übergeben.
So werden Zeilen dann einfach mit Strg+\ und der Eingabe “sort” in die richtige Reihenfolge gebracht. WENN denn die Zahlen am Anfang für sich alleine stehen
Sort hat einige Parameter und vermutlich wird meist der Parameter “-V” natural sort of (version) numbers within text” gesucht, da dieser Parameter das so sortiert, wie wir das meist manuell machen würden.
sort -V
sort
1 2 3 20 30
1 2 20 3 30
Mit “sort -V” werden zum Beispiel auch Nummer1, Nummer2, Nummer3, Nummer30 ordentlich sortiert.
Wer noch mehr Sortier-Parameter von sort erfahren möchte, gibt einfach “man sort” auf der Kommandozeile ein.
Viel Spaß beim Sortieren.
PS: Kate gibt es übrigens auch als Windows und als Mac Version hier zum Runterladen
Vor Kurzem veröffentliche Red Hat mit Red Hat Enterprise Linux 9 die nächste Hauptversion der wichtigsten Linux-Distribution. Erstaunlich finde ich die geringe Resonanz. Das passt in einen längeren Trend der Entkopplung von „gefühlter“ und „realer“ Bedeutung von Distributionen.
Red Hat Enterprise Linux ist meiner Ansicht nach die wichtigste Linux-Distribution überhaupt. Die Gründe dafür sind leicht erklärt. Red Hat war vor der Übernahme durch IBM die erfolgreichste und finanzstärkste Firma im direkten Linux-Umfeld und daran hat sich seitdem nichts geändert. Alle wichtigen Weiterentwicklungen entstammen dem Red Hat-Umfeld oder werden dort ganz massiv vorangetrieben: Systemd, PulseAudio, PipeWire, Wayland, GNOME, Flatpak, Podman, Etablierung von SELinux im Linux-Bereich, viel Weiterentwicklung im Container-Segment. Bestimmt habe ich hier noch ganz viel vergessen.
Neben diesen eher harten Fakten spielt die Verbreitung noch eine wichtige Rolle. Wie immer gibt es keine harten Zahlen und Fakten im Linux-Segment und daher kann jeder nur mit seinen eigenen Beobachtungen arbeiten. Ich habe in meinem Arbeitsleben bisher beobachten können, dass auf dem Desktop der IT-Mitarbeiter alles mögliche läuft – Windows, macOS und wenn Linux dann alles von Ubuntu über Manjaro bis zu Fedora – aber im Serverbereich zwei Anbieter führen: Red Hat und SUSE. Wenn ein kostenloses System genutzt wird, dann meist ein freier Klon von RHEL. Das mag natürlich an den Branchen liegen, in denen ich bisher gearbeitet habe, aber die Umsatzzahlen der Unternehmen müssen ja irgendwelche Grundlagen haben.
Ich wunderte mich deshalb in den vergangenen Wochen, wie ruhig es rund um den Release von RHEL 9 blieb. Schaut man sich die einschlägigen IT-Portale an, dann gibt es kaum Resonanz. Weder in Form von Artikeln noch bei den Kommentaren unter den wenigen vorhandenen Meldungen. Die neue Version ist nun sicherlich auch nicht gerade vollgepackt mit Änderungen, aber wo gibt es aktuell bei Linux schon umstürzende Entwicklungen?
Abgesehen von den beiden Blogartikeln sind das größtenteils Berichte auf dem Niveau von „Agentur-Meldungen“ und in wenigen Minuten geschrieben. Das ist kein Vergleich mit dem Release einer Debian-Version (der Vergleich mit Ubuntu hinkt, weil das auch auf dem Desktop eine herausragende Bedeutung hat). Das finde ich beachtlich, da in meiner persönlichen Wahrnehmung – und das hat wirklich nichts damit zu tun, wie ich persönlich Debian finde – Debian seine primäre Bedeutung als Basis für verschiedene andere Distributionen und Enterprise-Produkte wie beispielsweise Proxmox hat. Ein Debian-Release ist eigentlich erst dann interessant, wenn es in diese Produkte einfließt.
Was steckt dahinter? Entkoppelt sich die online präsente Linux-Community zunehmend von dem, was manche abfällig „Enterpise-Linux“ nennen oder ist das Zufall?
In diesem Artikel möchte ich einen Blick auf die Linux Distributionen AlmaLinux und Rocky Linux werfen und sie ihrem Upstream-Projekt Red Hat Enterprise Linux (RHEL) gegenüber stellen. Dabei interessieren mich insbesondere die folgenden Punkte:
Wer betreibt das Projekt bzw. steht hinter dem Projekt?
Wie finanziert sich das Projekt? Gibt es ein funktionierendes Geschäftsmodell?
Welchen Eindruck hinterlässt die Dokumentation?
Wie lange wird ein Major-Release unterstützt?
Wie viele Tage liegen zwischen einem RHEL-Release und den Releases der beiden Projekte?
Wie handhaben die Projekte Sicherheits-Updates?
Aus Gründen der Transparenz weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community und System-Administrator diverser RHEL-Server bin. Dieser Text gibt ausschließlich meine persönlichen Ansichten und nicht die von Red Hat oder die meines Arbeitgebers wieder. Zwar können diese in einzelnen Punkten übereinstimmen, müssen es aber nicht.
Was haben beide Projekte gemeinsam?
Sowohl AlmaLinux als auch Rocky Linux sind nach eigener Aussage:
Produktionsreife Betriebssysteme
Binärkompatibel zu RHEL
Werden aus den RHEL-Quelltexten übersetzt
Für den Nutzer kostenlos
Bieten 10 Jahre Unterstützung für ein Major-Release
Auch Red Hat bietet 10 Jahre Support auf seine RHEL-Major-Releases (Login erforderlich), an die sich eine Extended Life Phase anschließen kann. Selbstverständlich ist auch RHEL nach eigener Aussage reif für den produktiven Einsatz. Im Unterschied zu AlmaLinux und Rocky Linux kann RHEL jedoch nur zusammen mit einer kostenpflichtigen Subskription sinnvoll betrieben werden. Je nach Größe der Umgebung und Anzahl RHEL-Instanzen können hier beträchtliche Kosten anfallen.
Wer steht hinter den Distributionen?
Bei AlmaLinux handelt es sich um ein Community-Projekt, welches von der Firma CloudLinux Inc. gestartet wurde, welche das Projekt auch mit 1 Mio. USD pro Jahr unterstützt. Entwickelt und gesteuert wird das Projekt durch die Community, zu deren Unterstützung die gemeinnützige AlmaLinux OS Foundation gegründet wurde.
Neben der jährlichen Zuwendung von CloudLinux finanziert sich das Projekt durch diverse Sponsoren.
Die Firma CloudLinux Inc. verfügt selbst über mehr als 10 Jahre Erfahrung in der Pflege eines RHEL-Klons sowie den Betrieb der dazu notwendigen Infrastruktur. Nach eigener Aussage möchte CloudLinux Inc. durch die Unterstützung des Projekts den eigenen Bekanntheitsgrad steigern und hofft auf neue Kunden für das kommerzielle CloudLinux OS und KernelCare.
RHEL wird von der Firma Red Hat entwickelt, welches eines der weltweit erfolgreichsten Open Source Unternehmen ist. Haupteinnahmequelle des Unternehmens ist der Vertrieb von Subskriptionen für RHEL und weitere Produkte aus dem Portfolio. Eine Subskription berechtigt zum Bezug von Software-Aktualisierungen und umfasst kommerziellen Support.
Rocky Linux ist ein Community-Projekt, welches vom CentOS-Mitbegründer Gregory Kurtzer gegründet wurde. Das Projekt verfolgt die gleichen Ziele wie das ursprüngliche CentOS, welches zugunsten von CentOS Stream aufgegeben wurde.
Wie oben bereits beschrieben haben alle Distributionen ein Unterstützungszeitraum von 10 Jahren. Das heißt, dass ein Major-Release wie AlmaLinux/RHEL/Rocky Linux 8 für einen Zeitraum von 10 Jahren Aktualisierungen in Form von Bug-/Security-Fixes und ausgewählter Verbesserungen erhält. AlmaLinux und Rocky Linux profitieren hier von der Vorarbeit, welche Red Hat für RHEL geleistet hat.
Hilfe für individuelle Probleme, Sorgen, Nöte und Anträge erhält man bei AlmaLinux und Rocky Linux in Foren, Chats und auf Mailinglisten. Darüber hinaus kann man kommerziellen Support für AlmaLinux bei TuxCare einkaufen. Rocky Linux listet CIQ und OpenLogic by Perforce als Support-Anbieter. Red Hat unterhält mit der Red Hat Customer Portal Community ebenfalls einen Bereich mit Disussions-Forum. Darüber hinaus bietet Red Hat im Rahmen seiner Subskriptionen Support direkt vom Hersteller.
Für alle drei Distributionen gibt es also sowohl freie/kostenlose Support-Angebote, als auch kommerzielle Support-Verträge, entweder direkt vom Hersteller oder durch Drittanbieter.
Ob man kommerziellen Support benötigt oder der Community-Support ausreicht, hängt von verschiedenen Faktoren wie z.B. den eigenen Fähigkeiten und nicht zuletzt von der eigenen Risikofreudigkeit ab. Ich persönlich habe die Erfahrung gemacht, dass in Enterprise- bzw. Provider-Umgebungen Probleme auftreten können, die im Hobbykeller, im Verein oder im SoHo ausbleiben und völlig unbekannt sind. In diesen Fällen darf man sich nicht wundern, wenn sich in den Community-Foren niemand findet, der helfen kann. Hier kann ein kommerzieller Support vorteilhaft sein, der auf diese Umgebungen ausgerichtet ist und über mehr Erfahrung in diesem Bereich verfügt.
Ich persönlich bin mit dem Red Hat Support für RHEL zufrieden. Er hat mir schon einige Male bei Problemen und Fragestellungen geholfen, wo ich im Forum vermutlich ohne Antwort geblieben wäre. Die Support-Qualität bei AlmaLinux und Rocky Linux kann ich mangels Erfahrung nicht beurteilen.
Softwareunterstützung
Alle drei betrachteten Distributionen sind zueinander binärkompatibel. Das bedeutet, dass Anwendungen, die unter RHEL ausgeführt werden können, in aller Regel auch unter AlmaLinux und Rocky Linux ausgeführt werden können und umgekehrt.
Software-Hersteller führen in ihren Systemvoraussetzungen häufig unterstützte Betriebssysteme auf. Hier finden sich manchmal nur die kommerziellen Enterprise-Betriebssysteme wie RHEL oder SuSE Linux Enterprise Server (SLES). In solch einem Fall kann es passieren, dass der Software-Hersteller den Support ablehnt, wenn man seine Anwendung auf einem RHEL-Klon ausführt statt auf dem Original. Evtl. verlangt der Hersteller auch nur, dass das Problem unter einem offiziell unterstützten Betriebssystem nachgestellt wird. Dieser Punkte sollte bei der Auswahl einer Distribution mit bedacht werden.
Dokumentation
Red Hat bietet für RHEL eine ausführliche Produkt-Dokumentation und eine umfassende Wissensdatenbank. Zwar ist auch hier nicht alles perfekt, doch hat man dies auch schon deutlich schlechter gesehen. Um die Dokumentation kontinuierlich zu verbessern, bietet Red Hat allen Kunden und Nutzern die Möglichkeit, Dokumentations-Feedback direkt in der Dokumentation zu geben. Aus eigener Erfahrung kann ich berichten, dass gefundene Fehler meist innerhalb weniger Tage behoben werden.
Bei AlmaLinux habe in hinsichtlich Dokumentation auf den ersten Blick nur ein Wiki gefunden, welches auf mich hinsichtlich Gliederung und Umfang einen enttäuschenden Eindruck macht.
Rocky Linux hat ebenfalls ein Wiki und einen gesonderten Bereich für Dokumentation. Auch hier lässt mich die Gliederung etwas verstört und hilflos zurück. Zwar finden sich auf den ersten Blick mehr Anleitungen als bei AlmaLinux, an die RHEL-Dokumentation reicht sie jedoch keinesfalls heran.
Die schwache bis mangelhafte Dokumentation bei AlmaLinux bzw. Rocky Linux mag nicht so sehr ins Gewicht fallen, da man in vielen Fällen einfach die RHEL-Doku zurate ziehen kann. Auch hier profitieren die beiden Projekte wieder von der Vorarbeit des Originals.
Release-Zyklen
Seit RHEL 8 hat sich Red Hat feste Release-Zyklen auferlegt, welche alle 6 Monate ein Minor- bzw. Point-Release und alle 3 Jahre ein Major-Release vorsehen. Da AlmaLinux und Rocky Linux als Downstream-Projekte aus den RHEL-Quelltexten gebaut werden, erscheinen deren Releases stets nach der Veröffentlichung eines RHEL-Release. Die folgende Tabelle gibt einen kleinen Überblick, wann welche Distribution ein Minor-Release veröffentlicht hat.
Bisher folgen die Releases von AlmaLinux und Rocky Linux in der Regel wenige Tage auf das RHEL-Release. Beim Major-Release 9 hing RockyLinux ca. 1,5 Monate hinterher.
Bereitstellung von Sicherheits-Updates
Alle drei Projekte stellen Produkt-Errata im Internet bereit:
Dabei werden Errata in Bugfix-, Enhancement- und Security-Advisory unterschieden.
Während Bugs und fehlende Funktionalität störend und ärgerlich sein können, stellt die schnelle Verfügbarkeit von Sicherheits-Updates einen kritischen Faktor dar, um Sicherheitslücken zeitnah schließen zu können. Nach Aussage von AlmaLinux werden Errata bei AlmaLinux und Rocky Linux mit einem Geschäftstag Verzögerung in Bezug auf das RHEL-Errata-Release veröffentlicht. Ob beide Projekte dies durchhalten können, werde ich in der Zukunft stichprobenartig kontrollieren.
Mein Open-Source-Projekt Ansible: Patch-Management für Red Hat Systeme nutzt die Red Hat Security Advisories, um sogenannte Patch-Sets zu definieren, welche zu bestimmten Stichtagen installiert werden. Es ist darauf angewiesen, dass Errata-Informationen als Meta-Informationen in den Paket-Repositorien verfügbar sind. Bei CentOS fehlten diese, sodass mein Patch-Management für CentOS nicht nutzbar ist.
Daher bin ich sehr erfreut, dass AlmaLinux und Rocky Linux diese Meta-Informationen ebenfalls in ihren Repositorien bereitstellen. Prinzipiell sollte mein Patch-Management auch mit diesen beiden Distributionen funktionieren. Ein Test steht jedoch noch aus.
Zusammenfassung
Mit AlmaLinux und Rocky Linux gibt es zwei von einer Gemeinschaft entwickelte binärkompatible RHEL-Klone, welche von unterschiedlichen Unternehmen unterstützt und gesponsort werden. Erste Unternehmen bieten kommerziellen Support für diese Distributionen an.
Mir fällt positiv auf, dass beide Projekte in ihren Repos Errata-Informationen wie z.B. ALSA oder RLSA bereitstellen. Dies erleichtert die gezielte Installation von sicherheitsrelevanten Aktualisierungen. Hier bieten beide Projekte mehr, als es CentOS in der Vergangenheit tat.
Die Dokumentation scheint bei beiden Projekten keine große Rolle zu spielen. Ich empfinde sie als unübersichtlich und lückenhaft. Hier kann man jedoch vermutlich auf die Dokumentation des Originals (RHEL) zurückgreifen, welche sich mit sehr geringer Transferleistung auch für AlmaLinux und Rocky Linux nutzen lässt.
Auf den ersten Blick scheint es sich sowohl bei AlmaLinux als auch bei Rocky Linux um zwei solide Distributionen für alle jene zu handeln, die sich RHEL nicht leisten können oder wollen.
Abseits der bevorstehenden Veröffentlichung von Thunderbird 102 plant die MZLA Technologies Corporation bereits darüber hinaus. Für das kommende Jahr steht ein neues Design an. Außerdem befindet sich mit Thunderbird Mobile erstmals eine Smartphone-App für Android in Entwicklung.
Die MZLA Technologies Corporation hat kürzlich ihren Finanzbericht für das Jahr 2021 veröffentlicht. Wie dieser zeigt, steht das Thunderbird-Projekt finanziell auf gesunden Beinen und befindet sich weiter im Wachstum.
In den nächsten Wochen wird MZLA seinen neuen E-Mail-Client Thunderbird 102 veröffentlichen. Dieser wird wieder einige interessante Neuerungen beinhalten, darunter ein neues Adressbuch, was von Thunderbird-Nutzern bereits seit Jahren gewünscht wird. Alle wichtigen Neuerungen von Thunderbird 102 werden selbstverständlich auch hier auf diesem Blog wieder vorgestellt werden, sobald die neue Version zum Download zur Verfügung steht.
Die Planungen gehen natürlich längst viel weiter. So wurde mittlerweile angekündigt, dass Thunderbird 114, welcher im Jahr 2023 erscheinen wird, eine komplett überarbeitete Benutzeroberfläche haben wird, welche auf den internen Projektnamen „Supernova“ hört. Erste Anzeichen dafür werden bereits in Thunderbird 102 sichtbar sein, wie teilweise neue (und bunte) Icons sowie eine Seitenleiste, deren Farben übrigens vom Nutzer frei wählbar sind. Dies ist allerdings erst der Anfang.
Die aber wohl mit der größten Spannung erwartete Ankündigung betrifft die Expansion von Thunderbird auf das Smartphone. Mit Thunderbird Mobile wird es erstmals eine Thunderbird-App für Android geben. Der mobile Thunderbird, der sich schon seit einiger Zeit in Entwicklung befindet, wird natürlich, wie schon Thunderbird für Windows, macOS und Linux, kostenlos und Open Source sein. Bereits in zwei Wochen sollen erste offizielle Informationen zu Thunderbird Mobile folgen.
Im Rahmen des von der Europäischen Union geförderten Bergamot Projects arbeitet Mozilla daran, eine Übersetzungsfunktion für den Browser zu entwickeln – und das vollständig ohne Online-Komponente wie Google Translate. Kurz nach Veröffentlichung einer neuen Version mit vielen Neuerungen steht diese jetzt auch für die Installation in finalen Firefox-Versionen zur Verfügung.
Vor wenigen Tagen berichtete ich über eine neue Version von Firefox Translations zur maschinellen Offline-Übersetzung von Websites mit vielen Neuerungen. Diese konnte nur in Nightly-Versionen sowie in der Developer Edition von Firefox genutzt werden, weil zwei Konfiguration-Anpassungen notwendig waren, welche in finalen Firefox-Versionen nicht möglich sind.
Nun hat das Team Firefox Translations auf addons.mozilla.org zur Installation bereitgestellt. Ein wesentlicher Vorteil: Es müssen keine Schalter in about:config mehr verändert werden, dementsprechend funktioniert die Erweiterung auch in finalen Firefox-Versionen. Außerdem erhält der Anwender durch die Bereitstellung auf addons.mozilla.org auf Wunsch automatisch Updates auf neue Versionen.
Achtung: Laut Erweiterungs-Website ist Firefox Translations kompatibel mit Firefox 79 und höher. Dies ist jedoch nicht der Fall. Selbst Firefox ESR 91 ist zu alt. Damit Firefox Translations genutzt werden kann, muss also tatsächlich eine aktuelle Firefox-Version genutzt werden, die nicht Firefox ESR ist. In weniger als einem Monat macht aber auch Firefox ESR den Sprung zu Firefox 102, womit die Erweiterung dann auch in Firefox ESR funktionieren wird.
Hinweis für Nutzer, welche Firefox Translations zuvor über GitHub installiert hatten: Die alte Version sollte deinstalliert und die Änderungen in about:config wieder rückgängig gemacht werden. Konkret heißt das, dass xpinstall.signatures.required wieder auf true und extensions.experiments.enabled wieder auf false zu setzen sind.
Neben Slackware -current auf meinem Haupt-PC nutze ich auf meinem Laptop Fedora Vauxite. Dabei handelt es sich um eine Variante von Fedora Silverblue mit Xfce als Desktopumgebung. Da bisher keine eigenständigen Installationsmedien zur Verfügung stehen, kann wahlweise Silverblue oder Kinoite als Basis gewählt werden.
Im Folgenden beschreibe ich die Einrichtung und die Anpassungen, welche ich vorgenommen habe.
Ich habe mich für Kinoite entschieden und nach der Basisinstallation mit folgenden Befehlen einen rebase auf Vauxite durchgeführt:
Nach einem Neustart mittels systemctl reboot begrüsste mich lightdm, allerdings mit dem Standard GTK-Greeter, welcher auf meinem hochauflösenden Display winzig klein dargestellt wird. Nach dem Login und dem ersten Start von Xfce fand ich trotz der miniaturhaften Oberfläche unter Erscheinungsbild / Einstellungen die Möglichkeit der 2x Skalierung des Desktops. Unter Fensterverwaltung / Stil konnte ich passend dazu die Fensterdekoration Default-xhdpi wählen. Im Bereich Maus und Touchpad habe ich im Geräte Pull-Down-Menü mein Touchpad gewählt und die Mausradrichtung umgedreht. Unter dem Reiter Touchpad konnte ich darüber hinaus den Punkt Mausklicks per Touchpad ermöglichen wählen.
Statt der bei Xfce üblichen zwei Panels habe ich mich für ein Panel am unteren Bildschirmrand entschieden und dieses nach meinen persönlichen Vorlieben hin angepasst. Dabei ist mir aufgefallen, dass Vauxite das mittlerweile übliche Whisker Menü standardmässig nicht mit ausliefert. Da ich darüber hinaus einige weitere Anwendungen benötige, habe ich diese kurzerhand mithilfe folgenden Kommandos nachinstalliert, nachdem ich das RPM Fusion Repository aktiviert habe:
Nach einem beherzten sudo rpm-ostree ex apply-live standen die Änderungen bereits zur Verfügung und ich konnte das klassische Startmenü durch das Whisker Menü ersetzen.
Nach dem Aufruf von VLC ist mir aufgefallen, dass dieses weiterhin ohne Skalierung dargestellt wird. Zur Lösung habe ich folgende Datei erstellt:
sudo vim /etc/profile.d/qt-style.sh
if [ "$DESKTOP_SESSION" = "xfce" ] || [ "$XDG_SESSION_DESKTOP" == "xfce" ]; then
# QT apps to use GTK styling
export QT_STYLE_OVERRIDE=adwaita
# QT apps HIDPI scaling
export QT_SCALE_FACTOR=2
fi
Für GIMP hingegen musste ich ein eigenes Theme erstellen.
Das Fedora Projekt hat sich vor einiger Zeit entschieden, nano als Standard-Editor einzusetzen. Da ich vim Userin bin, habe ich darüber hinaus eine weitere Profil-Konfigurationsdatei erstellt:
sudo vi /etc/profile.d/zz-default-editor.sh
export EDITOR=vim
Umgebungsvariablen des Nutzers werden bei einem Aufruf von sudo standardmässig nicht mit übergeben. Um dies zu erreichen, habe ich mithilfe von sudo visudo folgende Parameter zur sudo-Konfiguration hinzugefügt:
Defaults rootpw
Defaults env_keep += "EDITOR"
Der erste Wert stellt sicher, dass bei einem Aufruf von sudo nicht das Benutzerpasswort, sondern das Root-Passwort abgefragt wird. Dies hatte ich bereits während der Installation von Kinoite aktiviert (Silverblue bietet diese Option nicht). Andernfalls kann man in einer Root-Shell das passwd Kommando ausführen und ein entsprechendes abweichendes Passwort setzen.
Hinweis: bei grafischen Passwortanforderungen mittels PolicyKit muss dennoch das User-Passwort angegeben werden.
Der zweite Parameter stellt sicher, dass die Umgebungsvariable EDITOR auch bei sudo Aufrufen berücksichtigt wird.
Nach dem Abmelden von der grafischen Oberfläche, um zu testen, ob alle Einstellungen aktiviert werden, stellte ich erstaunt fest, dass lightdm nun den slick-greeter verwendet. Letzerer skaliert auch auf HiDPI-Displays gut und wurde als Abhängigkeit des grafischen Administrationswerkzeuges lightdm-settings mitinstalliert.
In der lightdm Konfigurationsdatei habe ich dennoch den slick-greeter fest hinterlegt, da der Displaymanager andernfalls beim ersten Start versucht einen passenden Greeter unter den verfügbaren zu wählen:
sudo vim /etc/lightdm/lightdm.conf
[Seat:*]
...
greeter-session=slick-greeter
...
Damit die Schrift auch in einer tty gut lesbar ist, habe ich die Datei /etc/vconsole.conf wie folgt angepasst:
sudo vi /etc/vconsole.conf
KEYMAP="ch"
FONT="latarcyrheb-sun32"
Einige Zusatzpakete habe ich über Flatpak aus dem Flathub Repository installiert, nachdem ich dies wie folgt aktiviert habe. Für Flatpaks entscheide ich mich aktuell dann, wenn ich weiss, dass die Pakete dort regelmässig aktualisiert und im besten Falle direkt von den Entwicklern gepflegt werden.
Darüber hinaus habe ich keine wesentlichen Anpassungen ausgeführt. Lediglich im Xfce4-Terminal habe ich die Option zur Verwendung der Systemschriftart gesetzt und im Dateimanager Thunar sowie in den Schreibtischeinstellungen habe ich Single-Klick zum Öffnen von Ordnern aktiviert. Um GNOME-Keyring automatisch bei der Anmeldung zu entsperren, habe ich die ausführliche Anleitung im Arch Linux Wiki zurate gezogen.
Zusammenfassend würde ich selbst meinen Desktop als minimalistisch bezeichnen. Ich verzichte gerne auf grafischen Schnick-Schnack, da dieser mich eher irritiert, als dass ich Gefallen daran finde. Da kommt mir die Xfce-Desktopumgebung sehr entgegen, zumal ich diese schon nutze, seitdem es sie gibt. Als darunterliegende Technologie verwende ich gerne Bleeding-Edge Software und ich interessiere mich sehr für neue Ansätze, wie sie bei Fedora Silverblue und dessen Derivaten zum Einsatz kommen.
Ich würde mich freuen, wenn euch diese Zusammenfassung animiert, dieses oder ein ähnliches Setup einmal auszuprobieren und eure persönlichen Erfahrungen damit zu teilen.
Die MZLA Technologies Corporation hat mit Thunderbird 91.10 ein planmäßige Update für seinen Open Source E-Mail-Client veröffentlicht.
Neuerungen von Thunderbird 91.10
Mit dem Update auf Thunderbird 91.10 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit aktuelle Sicherheitslücken. Darüber hinaus bringt das Update kleinere Design-Korrekturen.
Mozilla hat Firefox 101 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.
Firefox 98 brachte diverse Änderungen des Download-Verhaltens. Eine davon war, dass Downloads nun umgehend stattfinden, ohne den Nutzer noch einmal explizit um Bestätigung zu bitten. Ein häufiger gehörtes Nutzer-Feedback war es, dass einige Nutzer weiterhin gefragt werden wollen. Zwar kann dies weiterhin erreicht werden, indem Firefox für möglichst viele Dateitypen entsprechend konfiguriert wird, doch ist dies verhältnismäßig umständlich. Mozilla reagiert auf dieses Feedback mit einer neuen Einstellung in den Einstellungen, welche automatisch für alle noch nicht konfigurierten Dateitypen gilt.
Immer alten Drucken-Dialog öffnen
Mit Firefox 86 hatte Mozilla die native Drucken-Oberfläche des jeweiligen Betriebssystems standardmäßig durch eine plattformübergreifend konsistente Oberfläche ersetzt. Über einen Link im Drucken-Dialog konnte die bisherige Oberfläche jederzeit geöffnet werden. Außerdem gab es mit print.tab_modal.enabled eine Option in about:config, um immer die alte Oberfläche zu öffnen. Diese Option wurde gemeinsam mit altem Code, der damit verknüpft war, in Firefox 97 entfernt.
Auch hier hat Mozilla auf das Feedback seiner Nutzer gehört und mit print.prefer_system_dialog eine neue Option für about:config eingeführt, welche das gleiche Ergebnis hat, nämlich immer den alten Drucken-Dialog zu öffnen, ohne den obsoleten Code wieder einzuführen.
Bild-im-Bild-Verbesserungen
Nach der Unterstützung von Untertiteln im Bild-im-Bild-Modus (PIP) für Videos in Firefox 100 wurde das PIP-Fenster in Firefox 101 um eine Schaltfläche zum Stummschalten der Videos erweitert. Werden mehrere Videos in diesem Modus gestartet, werden diese außerdem nicht länger standardmäßig aufeinander positioniert.
Verbesserungen der Entwicklerwerkzeuge
Mehrere Verbesserungen hat das Inspektor-Werkzeug bekommen. Soll zu einem HTML-Element eine Klasse hinzugefügt werden, gibt es bei Verwendung des Eingabefelds hinter der .cls-Schaltfläche jetzt eine Autovervollständigung, welche alle bereits auf der Seite bestehenden Klassen-Namen vorschlägt. Jeder Vorschlag findet umgehend nach Auswahl mittels Pfeiltasten Anwendung, so dass schnell verschiedene CSS-Klassen getestet werden können.
Bei CSS-Eigenschaften, welche Größen verändern, können diese nun mittels Klicken und Ziehen verkleinert respektive vergrößert werden. Wer die Funktion nicht haben möchte, kann diese in den Einstellungen der Entwicklerwerkzeuge deaktivieren.
Die Performance der Webkonsole wurde verbessert.
Verbesserungen der Web- und Erweiterungsplattform
Bei der Verwendung einer Konferenz-Anwendung kann der Benutzer nun alle vorhandenen Mikrophone nutzen und jederzeit zwischen diesen wechseln, sofern die entsprechende Anwendung diese Möglichkeit aktiviert.
Firefox 101 unterstützt den prefers-contrast Media Query, über welchen Websites die Information erhalten können, ob Nutzer einen schwächeren oder stärkeren Kontrast bevorzugen, um die Darstellung gegebenenfalls entsprechend anpassen zu können.
Darüber hinaus wurde das WebDriver BiDi-Protokoll aktiviert, um es externen Werkzeugen wie Selenium zu erlauben, dieses für Automatisierung mittels Firefox zu nutzen.
Außerdem unterstützt Firefox 101 die neuen Viewport-Längeneinheiten svh, lvh, dvh, svw, lvw, dvw, svmax, lvmax, dvmax, svmin, lvmin und dvmin, was vor allem in Zusammenhang mit den dynamischen Toolbars moderner Smartphone-Browser relevant ist.
Weitere Verbesserungen der Webplattform sowie einige Änderungen für Erweiterungs-Entwickler, welche vor allem in Zusammenhang mit dem kommenden Manifest v3 (MV3) relevant sind, darunter eine neue Scripting-API, lassen sich in den MDN Web Docs nachlesen.
Geschlossene Sicherheitslücken
Auch in Firefox 101 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 101 daher für alle Nutzer dringend empfohlen.
Im heutigen Artikel möchte ich euch kurz ein Werkzeug vorstellen, das immer dann sinnvoll ist, wenn mehrere Dateien auf einmal nach einem bestimmten Muster umbenannt werden sollen.
Das Werkzeug heißt rename (man prename) und kann unter Debian/Ubuntu als solches aus den Repositories bezogen werden. Bei anderen Distributionen muss man darauf achten, dass man die Perl-Variante nimmt (teils auch als prename bekannt) und nicht auf die util-linux-Variante zurückgreift, die zwar simple Ersetzungen beherrscht, aber kein Regex/Perl-Expression beherrscht und nur den ersten Treffer im Dateinamen ersetzt.
Das Kommando ist relativ einfach aufgebaut:
rename OPTIONS perlexpr [ files ]
Die wichtigste Option, das möchte ich vorab schon sagen, ist -n, da hiermit ein "Trockenlauf" durchgeführt und somit überprüft werden kann, ob das Muster auch passt.
Darüber hinaus halte ich -v für die zweitwichtigste Option, da man im "scharfen" Lauf dann überwachen kann, was konkret umbenannt wurde.
Das Muster selber wird als Perl-Expression übergeben, die in vielen Fallen an die Syntax vom Kommandozeilenwerkzeug sed für die Ersetzung von Text erinnert.
Das Kommando kann dann zum Beispiel so eingesetzt werden:
rename 's/TEst/Test/g' *.txt
Hier sollen alle Stellen mit "TEst" in den Dateinamen, die auf .txt enden, durch "Test" ersetzt werden. Mit einem klassischen mv ließe sich das nicht ohne weiteres umsetzen, da dieses Werkzeug nicht kontextbezogen ersetzen/umbenennen kann.
Natürlich können auch komplexere (Regex)-Muster umgesetzt werden: soll z. B. die Dateiendung aller Dateien, die auf ".htm" enden, in ".html" umbenannt werden, geht das mit folgendem Kommando:
rename 's/\.htm$/\.html/' .htm
Weitere Beispiele und Bedienungshinweise können aus dem Ubuntuusers-Wiki bezogen werden.
Meiner Erfahrung nach spart das Werkzeug besonders viel Zeit bei Umbennungsaufgaben und ersetzt somit ggfs. eigene Skripte mit find-mv-Konstruktionen.
NixOS ist eine Linux-Distribution auf Basis des Nix-Paketmanagers. Die Distribution basiert auf dem Ansatz deklarativer Systemkonfiguration, um reproduzierbare und zuverlässige Systemkonfiguration und in Folge reibungslose Systemaktualisierungen zu erlauben. Nun gibt der Release Manager Janne Hess die Verfügbarkeit der Version 22.05 bekannt.
Die Besonderheit dieser Version ist, dass erstmalig bei dieser Distribution ein grafisches Installationswerkzeug zum Einsatz kommt. Wie man dem Bild unschwer erkennen kann, handelt es sich dabei um Calamares. Kernstück von NixOS ist der Paketmanager Nix, der in der Version 2.8 vorliegt. Damit liegt die Hürde für den Einstieg in das besondere Konzept (reproduzierbar, deklarativ, zuverlässig) von NixOS ein gutes Stück tiefer, sodass die eine oder der andere vielleicht eine Proberunde damit drehen möchte. Dafür verweise ich auch auf unsere Artikelserie zu NixOS vom Dezember 2021:
Bei AlmaLinux handelt es sich um einen Clone der kommerziellen Red Hat Enterprise Linux (RHEL) Distribution. Das als Stiftung aufgestellte Projekt entfernt dabei in erster Linie das Branding und Vorkommnisse der Bezeichnung Red Hat in Paketnamen und anderen Komponenten. Bei Wechseln der Major-Release Version, wie es von 8 auf 9 der Fall ist, fällt dabei erwartungsgemäss etwas mehr Arbeit an, da neue Pakete und weiter Bestandteile zur Upstream-Distribution hinzugefügt wurden.
Dennoch ist es dem Projekt gelungen, in kürzester Zeit eine erste Veröffentlichung auf Basis von RHEL 9 bereitzustellen.
Damit ist AlmaLinux erneut führend, gegenüber Projekten wie Rocky Linux oder semi-kommerziellen Clones wie Oracle Linux.
Aktuell werden die folgenden Architekturen unterstützt:
Zur Darstellung von Medieninhalten werden oftmals Codecs benötigt, welche aus lizenzrechtlichen Gründen nicht direkt mit vielen Linux-Distributionen ausgeliefert werden.
Dies betrifft nicht nur die Wiedergabe von Medien in darauf ausgelegten Applikationen, sondern beispielsweise auch die Integration in Webbrowser. Dort wird zumeist der Codec H.264 verwendet, welcher in Firefox aktuell über ffmpeg eingebunden wird.
Zur Installation wird zunächst das RPM Fusion Repository integriert:
Änderungen mittels rpm-ostree werden dabei erst beim nächsten Neustart des Systems aktiviert. Alternativ kann der folgende experimentelle Parameter genutzt werden, welcher bei Paketinstallationen in der Regel gut funktioniert, sofern allerdings overlays entfernt wurden, ist dennoch ein Neustart notwendig:
sudo rpm-ostree ex apply-live
Daraufhin kann ffmpeg installiert werden:
rpm-ostree install ffmpeg
Nach einem erneuten Ausführen von sudo rpm-ostree ex apply-live oder einem Neustart, sollte eine Wiedergabe von H.264 codierten Videos im Webbrowser Firefox bereits möglich sein. Prüfen lässt sich dies beispielsweise durch das Abspielen eines Trailers auf der unter Filmfans beliebten Seite IMDB.
Ein Grossteil der Multimedia-Applikationen setzt allerdings auf gstreamer als Backend. Dazu zählt beispielsweise der unter KDE Plasma beliebte Dragon Player oder auch GNOME Videos (totem). Die dafür benötigten Codecs lassen sich wie folgt installieren:
Vor zwei Wochen habe ich das menübasierte Installationsprogramm von Arch Linux vorgestellt, mit dem die Installation von Arch Linux auf für Anfänger möglich ist. Gestern wurde archinstall 2.5.0 mit einer Fülle neuer Funktionen veröffentlicht, darunter FIDO2 (HSM)-Unterstützung für systemd-boot beim Entriegeln der Festplattenverschlüsselung mit einem Master-Passwort als Backup während der Registrierung. Mit Archinstall können Benutzer nun FIDO2-Geräte als Entsperrmechanismus für eine Partition verwenden.
Das Hauptmenü von Archinstall wurde in dieser Version um eine neue Datenträger-Vorschau, eine neue Datenträger-Layout-Vorschau sowie eine Benutzer-Vorschau des Hauptmenüs erweitert. Ausserdem wurden in der Version 2.5.0 verschiedene Menütypen hinzugefügt, um die verschiedenen Rückgabearten der Menüauswahl besser handhaben zu können, sowie allgemeine Verbesserungen der Festplattenlayout-Ansicht.
Archinstall 2.5.0 verbessert auch die Benutzerverwaltung und implementiert eine neue Benutzerstruktur in --config, fügt Fernladen zu --config, --disk-layout und --creds hinzu, fügt einen retry=True-Aufruf zur Funktion Partition.format() hinzu, um die Formatierung im Falle einer Kernel-Verzögerung zu wiederholen, und fügt Unterstützung für die Codierung von pathlib.Path-Objekten zum archinstall.general.JSON-Encoder hinzu.
Neben anderen Änderungen führt archinstall 2.5.0 die Tastenkombination Strg+C zum Löschen der aktuellen Option ein, installiert automatisch das network-manager-applet, wenn ein Desktop-Profil und NetworkManager ausgewählt werden, und fügt neue Übersetzungen hinzu, darunter brasilianisches Portugiesisch, Tschechisch, Italienisch, Polnisch, Portugiesisch, Russisch, Spanisch, Türkisch und Urdu.
Archinstall 2.5.0 bringt auch viele Fehlerkorrekturen mit sich. Weitere Informationen finden ihr in den Release Notes auf der GitHub-Seite des Projekts, von der man auch den Sourcecode-Tarball zum Kompilieren herunterladen kann. Die neue archinstall-Version ist jetzt in den stabilen Software-Repositories von Arch Linux verfügbar.
Im Rahmen des von der Europäischen Union geförderten Bergamot Projects arbeitet Mozilla daran, eine Übersetzungsfunktion für den Browser zu entwickeln – und das vollständig ohne Online-Komponente wie Google Translate. Nachdem es lange ruhig schien, kann jetzt eine von Grund auf neu entwickelte Version getestet werden.
Bergamot Project: Website-Übersetzung im Browser
Bereits im Oktober 2019 berichtete ich über das Bergamot Project. Zur Erinnerung:
Hintergrund des Ganzen ist das von der Europäischen Union geförderte Bergamot Project, in dessen Rahmen Mozilla mit der University of Tartu (Estland), der University of Sheffield (England), der University of Edinburgh (Schottland) und der Charles University (Tschechien) kollaboriert, um eine vollständig clientseitige Funktion zur maschinellen Übersetzung von Websites für den Browser zu entwickeln.
Die clientseitige Durchführung der Übersetzung soll einerseits der Privatsphäre dienen, da kein Datenriese wie Google involviert ist, andererseits aber auch die Verbreitung von Sprachtechnologie in Europa fördern, und zwar in Bereichen, welche Vertraulichkeit erfordern und wo es dementsprechend keine Option ist, die Übersetzung in der Cloud durchzuführen.
Das Bergamot Project ist mit drei Millionen Euro durch die Europäische Union gefördert und auf drei Jahre ausgelegt. Damit das Projekt auch über die drei Jahre hinaus einen langfristigen Effekt hat, wird die Übersetzungsfunktion in Firefox integriert und alle Technologien, welche im Rahmen des Bergamot Projects entstehen, als Open Source veröffentlicht.
Was im letzten Jahr geschah
Ziemlich genau ein Jahr ist es her, dass ich über eine direkte Integration der damaligen Browser-Erweiterung in die Nightly-Version von Firefox berichtete. Im Juli 2021 folgte noch ein nennenswertes Update, seit dem ist es ruhig um das Projekt geworden.
Die Implementierung in der Nightly-Version war schon eine ganze Weile auf Grund von Änderungen der Mozilla-Plattform nicht mehr funktionsfähig, im März wurde die Integration in der Nightly-Version von Firefox dann entfernt. Im Hintergrund erfolgte zu dem Zeitpunkt längst eine komplette Neuentwicklung der Browser-Erweiterung.
Die Neuerungen von Firefox Translations 1.1.2
Verbesserte Performance
Eine der wichtigsten Verbesserungen gegenüber Firefox Translations 0.4.3 ist die Performance. Sowohl WebAssembly-Verbesserungen auf Seiten der Firefox-Plattform als auch die neue Architektur der Erweiterung sollten ihren Teil dazu beitragen, dass die Erweiterung gut performt, ohne die Leistung von Firefox zu sehr zu beeinträchtigen.
Unterstützung für weitere Sprachen
Unterstützte Firefox Translations bisher Übersetzungen aus dem Spanischen sowie aus dem Estnischen ins Englische und umgekehrt, sowie vom Englischen ins Deutsche (bisher allerdings nicht umgekehrt, in der neuen Version jedoch schon), stehen jetzt auch die Sprachen Bokmål (Norwegen), Bulgarisch, Italienisch und Portugiesisch zur Verfügung. Außerdem, mit einem Beta-Zusatz versehen, um deutlich zu machen, dass deren Übersetzungs-Qualität noch nicht an die anderen heranreicht: Isländisch, Nynorsk (Norwegen), Persisch sowie Russisch.
Unterstützung für Apple Silicon
Firefox Translations lief bereits plattformübergreifend auf Windows, Apple macOS und Linux – außer es wurde ein neuer Mac (November 2020 oder später) mit sogenanntem Apple Silicon Chip, also einem M1-Prozessor, verwendet. Die neue Version von Firefox Translations unterstützt auch Apples neue Prozesser-Architektur.
Zusätzliche Features
Firefox Translations unterstützt gegenüber der Vorjahres-Version zusätzliche Features. Dies schließt die Übersetzung von Formularen, die Hervorhebung von möglichen Übersetzungsfehlern durch eine rote Schlangenlinie sowie die Möglichkeit ein, Seiten beim Surfen in einem Tab automatisch zu übersetzen, ohne dass jedes Mal manuell der Übersetzungs-Prozess gestartet werden muss. Ein intergrierter Umfragen-Button bittet die Nutzer außerdem um Feedback zur Übersetzungs-Funktion.
Außerdem kann jetzt auch auf Seiten, auf denen keine übersetzbare Seite erkannt wird und die Übersetzungsleiste dementsprechend nicht automatisch eingeblendet wird, diese per Klick auf ein entsprechende Symbol in der Adressleiste aktiviert werden, wo dann manuell die Original-Sprache auszuwählen ist.
Installation von Firefox Translations
Update 2. Juni 2022: Firefox Translations kann ab sofort über addons.mozilla.org für Nutzer einer aktuellen Firefox-Version installiert werden. Firefox ESR 91 wird auf Grund seines Alters nicht unterstützt.
Ubuntu ist die am weitesten verbreitete Linux-Distribution. Das gilt für die offiziellen Varianten, aber umso mehr, wenn man sich vergegenwärtigt, dass der Ubuntu-Unterbau die Basis für Distributionen wie Linux Mint, Pop!_OS oder elementary OS bildet. Wie ist es eigentlich um die Sicherheit bei Ubuntu bestellt?
Achtung: Wer keine Kritik an Debian verträgt oder jeden Vergleich von Debian mit irgendetwas anderem als Sakrileg empfindet, bitte hier gleich aufhören zu lesen.
Einordnung
Diese Frage bzw. dieser Vorwurf erreicht mich immer wieder, da ich einerseits die Situation bei Debian sehr kritisch beurteilt habe, aber andererseits immer mal wieder erzähle, dass ich Ubuntu nutze. (Kleiner Hinweis übrigens an die Alles-Hasser in den Kommentarspalten: Ich bin kein „Ubuntu-Fanboy“, wenn ich „Fan“ irgendeiner Distribution bin, dann sicher von openSUSE. Aber um das herauszufinden, müsste man ja tatsächlich diesen Blog lesen…). Zurück zu Debian vs. Ubuntu: Tatsächlich messe ich hier mit zweierlei Maß!
Der Grund dafür ist leicht zu erklären. Wenn mich irgendetwas besonders abstößt oder auch einfach nur provoziert, dann Selbstgerechtigkeit. Debian wird von seinen Anhängern immer besondere Sicherheit zugeschrieben (siehe z. B. der eigene Abschnitt bei Wikipedia) und unter jedem Debian-Artikel taucht irgendeiner auf, der sagt, dass man genau wegen der Stabilität und Sicherheit Debian verwenden muss. Im Gegensatz dazu weiß jeder, dass Ubuntu abseits von main Probleme mit der Qualität hat. Niemand in der Ubuntu Community würde das Gegenteil behaupten und der potenziell faulige Zustand der dortigen Software wird Neulingen bei jeder Gelegenheit erzählt. Ein Artikel über die Probleme bei Ubuntu universe ist also eigentlich völlig überflüssig, weil ich darüber schreiben würde, was sowieso jeder weiß (bzw. habe ich auch schon).
Kurzum: Wer eine sichere Distribution sucht, greift sowieso nicht zu Ubuntu, sondern zu RHEL oder einem freien Klon oder Fedora, wenn man es aktueller mag. Alternativ gibt es noch openSUSE Leap bzw. SUSE Linux Enterpise bei Bedarf für einen offiziellen Supportvertrag. Hier ist dann meiner Meinung nach auch schon Ende bei den Linux-Distributionen, die ich bezüglich Sicherheit besonders empfehlen würde, wenn man von Spezialdistributionen wie Qubes etc. absieht.
Wie groß ist das Problem der eigenen Installation
Die spannende Frage ist aber, wie groß das Problem bei Ubuntu wirklich ist und ob ein normaler Desktop-Nutzer wirklich eine besonders sichere Distribution benötigt. Dazu muss man ein wenig tiefer in das jeweilige System schauen. Im konkreten Fall gehe ich von Kubuntu-Installationen aus, wie ich sie normalerweise aufsetze. Den Sicherheitsstatus kann mit folgendem Befehl abfragen.
$ ubuntu-security-status
Das Ergebnis hängt dann vom jeweiligen Setup aber und kann z. B. wie folgt aussehen:
2004 packages installed, of which:
1159 receive package updates with LTS until 4/2027
3 packages are from third parties
2 packages are no longer available for download
Packages from third parties are not provided by the official Ubuntu
archive, for example packages from Personal Package Archives in
Launchpad.
For more information on the packages, run 'ubuntu-security-status
--thirdparty'.
Packages that are not available for download may be left over from a
previous release of Ubuntu, may have been installed directly from a
.deb file, or are from a source which has been disabled.
For more information on the packages, run 'ubuntu-security-status
--unavailable'.
This machine is not attached to an Ubuntu Advantage subscription.
See https://ubuntu.com/advantage
Das bedeutet, 1159 Pakete entstammen main und erhalten Sicherheitsupdates von Canonical. Das ist das, was ich als Betriebssystem-Basis bezeichne. 840 Pakete kommen aus multiverse oder universe und haben keinen garantierten Sicherheitsstatus.
Was das genau ist, kann sehr einsteigerfreundlich bei Muon (oder Synaptic bei GTK-Oberfläche) eingesehen werden.
Kein offizieller Support – Katastrophe?
Alle Pakete mit dem blauen Kreis haben offiziellen Supportstatus. Pakete ohne entsprechendes Symbol eben nicht. Auf einem Kubuntu-System wird der überwiegende Teil davon zum KDE-Softwarestack gehören. Das ist aus mehreren Gründen nicht kritisch:
Die Kubuntu-Entwicker pflegen die Software und bringen Updates raus. Sie reichen auch Updates von KDE weiter (bei der letzten LTS wurde z. B. KDE Plasma von der Releaseversion 5.18.4 auf 5.18.8 angehoben). Um den Vergleich mit Debian wieder zu bemühen: Dort passiert das nicht und wer den KDE-Stack nach dem zumindest halben Weggang von Norbert Preining pflegt, kann ich nicht sagen. Trotzdem behauptet Debian, dass sie KDE Software umfänglich unterstützen, während Ubuntu das hier nicht tut. So viel zum Ehrlichmachen, was ich oben angesprochen habe.
Unabhängig von dem Aspekt sind Sicherheitslücken bei KDE eher selten. Das liegt nicht zuletzt an der Art, wie freie Software aufgebaut ist. Dazu kann man einfach mal das Packprogramm Ark nehmen. Sicherheitslücken treten eher selten in der Oberfläche auf, sondern betreffen meist die Kompressionsprogramme. Ark hat keinen offiziellen Sicherheitsstatus, zip, unzip, bzip etc. schon. Das kann man auf viele andere Bereiche übertragen. Akonadi hat selten Sicherheitslücken, die PostgreSQL-Datenbank im Hintergrund dagegen häufiger.
Nicht alles in universe ist zudem gleichermaßen problematisch, sondern sehr abhängig davon, wo sich Freiwillige engagieren. VirtualBox in Ubuntu bekommt z. B. sehr regelmäßig Updates durch zwei Debian-Maintainer. Ironie am Rande: In Debian ist VirtualBox rausgeflogen, weil dort keine Updates verteilt werden dürfen, die Versionsnummern anheben, selbst wenn es wirklich nur Wartungsupdates sind, wie bei VirtualBox.
Problematische Bereiche
Also gibt es keine Probleme? Leider doch:
Der komplette Multimedia-Stack hat keinen offiziellen Supportstatus und der Zustand der Codecs ist bekanntermaßen schlecht. Das ist kein exklusives Linux-Problem, sondern der Multimedia-Bereich bei z. B. Android leider auch immer wieder ein Grund für viele Sicherheitsupdates. Die Trennung in bad, ugly & Co bei GStreamer ist auf jeden Fall kein Entwicklerspaß, sondern ernst gemeint. Ich weiß nicht, wie andere Distributionen damit umgehen. OpenSUSE hat sich des Problems formell mit Packman entledigt, Red Hat / Fedora mit EPEL. Wie Debian glaubt hier Sicherheit garantieren zu können weiß ich nicht. Besonders fatal finde ich, diese Anleitungen für Einsteiger, bei denen alle Codecs installiert werden, die es gibt, anstelle nur der wirklich genutzten Formate. Hier ist für die Sicherheit weniger einfach mehr. Egal bei welcher Distribution.
Ein weiteres Problem ist der fehlende Support von Qt5. Besonders bei Qt5Webengine ist das fatal, weil Programme wie KMail oder RSS Guard diese nutzen, um HTML-Ansichten auszugeben. Das ist ein heftiges Manko (und dass Debian da nicht besser ist, hilft leider nicht) und als Anwender kann man sich da nur behelfen, indem man HTML in Programmen wie KMail standardmäßig deaktiviert lässt.
In manchen Bereichen ist man zudem sehr zurückhaltend. Das betrifft jetzt nicht Updates und Sicherheitslücken aber Prioritätensetzung. Die Funktion systemd-cryptenroll hat Canonical z. B. für Ubuntu 22.04 faktisch deaktiviert, weshalb keine TPM oder FIDO2-Unterstützung für LUKS-Entsperrung vorgesehen ist. Bei openSUSE hat man das hingegen für 15.4 implementiert.
Abschließend sei der Vollständigkeit halber zudem noch auf die offizielle CVE-Liste von Ubuntu verwiesen, die leidlich versierten Anwendern zumindest einen Blick in den Abgrund ermöglicht. Hier kann man gut nachprüfen, wie der aktuelle Zustand von Paketen ist, die man vielleicht im Verdacht hat. Anlässlich meiner jüngsten Empfehlung das Akonadi-Backend von MariaDB auf PostgreSQL umzustellen, sei hier mal exemplarisch auf die Liste von MariaDB in 22.04 „Jammy Jellyfish“ verwiesen.
Zusammengefasst
Ubuntu ist keine perfekte Distribution, wenn man einen Fokus auf Sicherheit legt. Das hat aber auch nie jemand behauptet. Als normaler Anwender kann man trotzdem sehr gut damit arbeiten, weil die Gefahr wirklich schwerwiegender Sicherheitslücken überschaubar ist. Notwendige Updates betreffen sehr oft die „Systembasis“ und neuralgische Bereiche wie den Internetbrowser. Hier bekommt man bei Ubuntu zuverlässig Updates. Das gilt aber natürlich ebenso für Debian.
Wie groß das Problem ist, hängt ganz wesentlich von der eigenen Installation und dem genutzten Derivat ab. Anwender der Hauptdistribution mit GNOME Shell dürften vermutlich noch weniger nicht-unterstützte Pakete haben als ich mit der hier gezeigten Kubuntu-Instanz. Es kann aber auch sicherlich deutlich schlimmer sein, wenn man noch viel mehr aus Universe bezieht.
Ich persönlich schätze die Ehrlichkeit hinter der Trennung in main und universe. Deshalb gebe ich Ubuntu den Vorzug vor Debian. Für wirklich hohe Sicherheitsansprüche würde ich aber sowieso keine der beiden Distributionen nutzen.
Datensparsamkeit und Schutz der digitalen Privatsphäre ist das eine Thema, Anonymität ein völlig anderes. Leider wird beides viel zu oft vermengt. Anonymität ist nicht immer notwendig und wenn, dann nur mit strenger Disziplin und den entsprechenden Werkzeugen zu erreichen. Eines dieser Werkzeuge bietet Whonix.
Umfeld von Whonix
Anonymität ist im Internet immer noch gleichzusetzen mit Tor (trotz aller Probleme). Doch obwohl sich Tor beispielsweise einfach über die Paketquellen der meisten Linux-Distributionen installieren lässt, ist es nicht einfach damit getan, seinen Datenverkehr über ein paar Tor-Knoten zu leiten. Denn erstens erfolgt Identifizierung heute über mehr Faktoren als nur die IP-Adresse und zweitens würde man bei so einem Vorgehen auch identifizierbaren Traffic mitschicken und sich damit selbst kompromittieren.
Deshalb gibt es zwei besonders bekannte Lösungen, um anonym zu surfen. Den Tor Browser und Tails. Der Tor Browser ist ein niedrigschwelliges Angebot, das einfach unter jedem Betriebssystem installiert werden kann. Dabei handelt es sich um eine modifizierte Firefox-Version, die darauf ausgelegt ist, in der Masse unterzugehen und natürlich den Datenverkehr über das Tor-Netzwerk leitet. Für den Einstieg und „kleinere“ Anonymitätsbedarfe völlig ausreichend.
Die Arbeit auf dem eigenen Desktop hat aber auch Nachteile. Downloads können manipuliert sein oder der ein oder andere Link aus Versehen doch im falschen Browser geöffnet werden. Für diese Zwecke gibt es Tails, das nur als Live-System funktioniert und somit immer eine saubere Arbeitsumgebung startet. Die Funktionsweise bedingt natürlich einen abwechselnden Betrieb zum eigenen System und die eigene Hardware sollte mit GNOME Shell flüssig laufen, denn Tails versucht im Linux-Umfeld möglichst wenig aufzufallen. Ein zufälliger Beobachter im Café soll eben nicht sehen, dass man gerade mit Tails arbeitet. Tails ist unpraktisch und will auch genau das sein.
Whonix
An diesem Punkt kommt Whonix ins Spiel. Die Entwickler haben den Anspruch ein „wasserdichtes Betriebssystem für die Privatsphäre“ zu schaffen und durchaus prominente Fürsprecher. Anders als Tails setzt man auf Virtualisierung, weshalb sich Whonix in das eigene Arbeitsumfeld einfügt, aber im Gegensatz zum Tor Browser dennoch hinreichend separiert.
Dieses Ziel erreichen die Entwickler mit Virtualisierung. Whonix gibt es für VirtualBox (Windows, macOS, Linux) und für das erste Setup ist dies auch der einfachste Weg. Linux-Anwender können aber auch eine Virtualisierung über KVM vornehmen und besonders sicherheitsbewusste Anwender können zu Qubes greifen.
Whonix verwenden
Die Installation und Einrichtung funktioniert für VirtualBox über den Download von OVA-Images. Diese können über die Schaltfläche Importieren in VirtualBox importiert werden. Dabei werden zwei virtuelle Maschinen angelegt:
Whonix Gateway
Whonix Workstation
Beide Maschinen müssen gestartet werden. Whonix Gateway ist dafür zuständig, die Verbindung zum Tor-Netzwerk aufzubauen. Ansonsten macht man als Anwender nichts in dieser Maschine. In der Workstation darf gearbeitet werden. Diese Workstation kann nur über den Gateway nach außen kommunizieren. Die Idee dahinter ist, dass selbst bei einer Kompromittierung der Workstation Informationen wie die öffentliche IP-Adresse nicht offen gelegt werden kann.
Beide Maschinen müssen über den Befehl upgrade-nonroot aktualisiert werden, um Sicherheits- und Funktionsupdates zu erhalten. Als Desktop kommt das ressourcensparsame Xfce zum Einsatz. Eine kleine Softwareauswahl ist bereits vorinstalliert. Insbesondere der zentrale Tor Browser in einer speziellen Ausfertigung.
Vor- und Nachteile
Whonix soll in einer virtuellen Umgebung laufen. Dadurch kann der Anwender das System anpassen und konfigurieren und startet anders als bei Tails nicht jedes mal mit einem blanken System. Das ist Vor- und Nachteil zugleich, weil es eben auch Spielräume zur Kompromittierung lässt. Zudem müssen Gateway und Workstation aktuell gehalten werden, weshalb eine gewisse Systempflege notwendig ist.
Der Betrieb von zwei virtuellen Maschinen zusätzlich zum Host-System erfordert zudem eine hinreichend potente Hardware.
