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.
