Mozilla hat Firefox Translations 1.3 veröffentlicht. Dabei handelt es sich um eine Übersetzungsfunktion für Websites, welche im Gegensatz zu Übersetzern wie Google Translate vollständig ohne Online-Komponente auskommt. Highlights der neuen Version sind die Text-Auswahl-Übersetzung sowie Unterstützung von Firefox für Android.

Was ist Firefox Translations?

Im Rahmen des von der Europäischen Union geförderten Bergamot-Projekts hatte Mozilla gemeinsam mit der University of Edinburgh (Schottland), der University of Tartu (Estland), der University of Sheffield (England) sowie der Charles University (Tschechien) zusammengearbeitet, um eine vollständig clientseitige Funktion zur maschinellen Übersetzung von Websites für den Browser zu entwickeln. Das bedeutet, dass die Übersetzung vollständig im Browser geschieht und keine zu übersetzenden Inhalte an einen Datenriesen wie Google oder Microsoft übermittelt werden müssen.

Download Firefox Translations

Die Neuerungen von Firefox Translations 1.3

Nach dem großen Update auf Firefox Translations 1.2.0 im November 2022 hat Mozilla nun Firefox Translations 1.3 veröffentlicht. Die exakte Versionsnummer lautet Firefox Translations 1.3.2.

Text markieren und übersetzen

Nachdem die Kernkompetenz von Firefox Translations die Übersetzung vollständiger Websites ist und es seit Version 1.2 außerdem ein freies Textfeld zur Übersetzung von beliebigem Text gibt, bringt Firefox Translations 1.3 zusätzlich die Möglichkeit, eine Textstelle auf einer Website zu markieren und diese per Kontextmenü-Eintrag übersetzen zu lassen. Die Übersetzung erscheint anschließend im Übersetzungs-Popup.

 

Verbesserungen des Übersetzungs-Popups

Eben jenes Übersetzungs-Popup, welches auch für die freie Textübersetzung genutzt wird, hat mehrere Verbesserungen erhalten.

So wird das Eingabefeld nach Klick auf das Erweiterungs-Symbol direkt fokussiert, so dass man sofort mit der Eingabe starten kann.

Die Sprache des eingegebenen Textes kann Firefox Translations jetzt automatisch erkennen.

Außerdem merkt sich die Erweiterung den eingegebenen Text nach dem Schließen des Übersetzungs-Popups für 60 Sekunden. Bislang wurde das Eingabefeld mit dem Schließen direkt geleert, was besonders ärgerlich war, wenn man dieses versehentlich geschlossen hat.

Insgesamt kommt das Übersetzungs-Popup nun etwas Platz sparender daher und bei Verwendung eines dunklen Firefox-Themes ist dieses jetzt auch Schwarz und nicht länger Weiß.

Firefox Translations für Android

Firefox Translations 1.3 ist die erste Version, welche auch Firefox für Android unterstützt. Da Firefox für Android noch keine generelle Erweiterungs-Unterstützung besitzt (eine solche ist für dieses Jahr geplant) muss derzeit Firefox Nightly oder Firefox Beta mit einer benutzerdefinierteren Erweiterungs-Sammlung genutzt werden, um Firefox Translations auf Android nutzen zu können. Firefox Translations für Android unterstützt sowohl die Übersetzung vollständiger Websites als auch von freiem Text.

Ausblick: Firefox Translations wird natives Firefox-Feature

Wie bereits vergangenen Monat berichtet, wird Firefox Translations ein natives Firefox-Feature werden und langfristig nicht länger die Installation einer Erweiterung erfordern. Bis es soweit ist, wird es aber noch eine Weile dauern. Wer eine Nightly-Funktion von Firefox nutzt und über about:config den Schalter browser.translations.enable per Doppelklick auf true setzt, sieht sogar bereits erste Spuren der bereits begonnenen Arbeit, wenn about:translations in die Adressleiste eingegeben wird. Dabei handelt es sich aber weder funktional noch optisch auch nur annähernd um ein fertiges Produkt, auch wenn zumindest die freie Textübersetzung auf diese Weise bereits genutzt werden kann.

Neben einer nativen Integration in Firefox ist mit einer neuen Oberfläche, der Unterstützung für ältere Hardware sowie für weitere Sprachen zu rechnen.

Der Beitrag Firefox Translations 1.3 bringt Text-Auswahl-Übersetzung und Android-Unterstützung erschien zuerst auf soeren-hentzschel.at.

Fr, 24. Februar 2023, Lioh Möller

Vermutlich hat es jeder von uns bereits einmal gehört:

Aus betrieblicher Sicht ist es sinnvoll, nur noch ...

Es folgt dann meist etwas wie: Windows einzusetzen, über Teams zu telefonieren oder ähnliches. Grundsätzlich handelt es sich dabei in den meisten Fällen, um einen Weg patriarchische Strukturen zu erhalten und den Willen einzelner, ohne den Einbezug aller Beteiligten durchzusetzen. Leider entspricht diese Annahme in den seltensten Fällen der Realität, denn unsere Welt ist vielfältig und die Bedürfnisse sind unterschiedlich.

Freie Software hingegen wird in der Regel im Konsens entwickelt. Das heisst zunächst werden alle Bedürfnisse abgeholt und dann gemeinsam eine demokratische Entscheidung gefällt, bei der jeder Teilnehmer ein gleichwertiges Stimmrecht hat. So zumindest in einer idealen Welt. Tatsächlich herrscht in vielen Projekten eine Meritokratie, bei der Menschen, die mehr leisten, ein höheres Votum erhalten. Auch hier besteht die Gefahr, dass Minderheiten übergangen werden und sich eine sogenannte Oligarchie bildet.

Beispiele aus der jüngsten Vergangenheit wäre die Entscheidung von Canonical, in Zukunft die als Flavors bezeichneten Derivate der Distribution, standardmässig ohne Flatpak auszuliefern. Der Prozess, welcher dazu geführt hat, ist nicht transparent einsehbar und die Entscheidung wurde hinter verschlossenen Türen ohne Einbezug der Community getroffen. Ein Vorgehen, das Canonical selbst bei anderen immer wieder kritisiert hat und welches beispielsweise Mark Shuttleworth im Zusammenhang mit der Mir Entwicklung verleitet hat, von einer Open Source Tea Party zu sprechen. (Einen Ausrutscher, für den er sich später entschuldigt hat)

Die Entscheidung, Flatpak standardmässig nicht mehr auszuliefern, führt zwangsläufig dazu, dass Betroffene selbst Lösungen entwickeln. In diesem konkreten Beispiel würde ein Anwender bei Bedarf Flatpak manuell über den Paketmanager installieren und das Flathub Repository selbstständig aktivieren. Nun kann man sagen, dass dies ja unproblematisch sei. Ein nachhaltigerer Ansatz wäre jedoch, Flatpak standardmässig zu installieren, das Flathub Repository vorzukonfigurieren, aber zu deaktivieren. Nutzer hätten dann die Möglichkeit, über einen einfachen Schalter in der Softwareverwaltung das Repository bei Bedarf zu aktivieren (Opt-in). Technisch wäre dies bereits heute mit der aktuellen GNOME Softwareverwaltung möglich.

Vorbildlich hingegen lösen Projekte wie Debian GNU/Linux solche Entscheidungsfindungsprozesse. Sofern nicht ohne weiteres ein Konsens gefunden werden kann, besteht die Möglichkeit einen als General Resolution bezeichneten Prozess zu starten. Dabei können zunächst von der Community verschiedene Vorschläge zur Lösung eingebracht werden, über die daraufhin abgestimmt werden kann. Deutlich wurde dies beispielsweise bei der Frage, ob unfreie Firmware mit der Distribution ausgeliefert werden soll.

Argumente, dass sich dieses Vorgehen nicht auf das Geschäftsumfeld adaptieren liesse, sind letztlich Ausreden und führen dazu, dass einige wenige, meist ältere weisse Männer, Entscheidungen treffen, die für eine bunte Kundschaft oder Belegschaft gültig sein sollen. Auch Behauptungen, dass demokratische Prozesse die Innovation unterbinden würden, verkehren sich unter genauerer Betrachtung schnell ins Gegenteil. Ein Beispiel für einen positiven Einbezug der Community im Geschäftsumfeld wäre Nextcloud, eine Software, die so vielfältig ist wie ihre Anwender.

Bildquelle: https://www.flickr.com/photos/foobarbaz/141522112/ - Mark Shuttleworth am Linuxtag 2006 in Wiesbaden.

---

GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

Fr, 24. Februar 2023, Ralf Hersel

So manch einer fragt sich, ob ein getaktetes, ein LTS (long term support) oder ein Rolling-Release Modell die beste Wahl für die eigenen Bedürfnisse ist. Was ich damit meine, zeige ich am Beispiel dieser Distributionen:

• Fedora fährt ein getaktetes Release-Modell: alle 6 Monate gibt es eine neue Version.
• Ubuntu ist auch getaktet: jeden Frühling und Herbst erscheint eine neue Version.
• Ubuntu publiziert ausserdem allen 2 Jahre eine LTS-Version.
• Arch-Linux ist ein Rolling-Release: die aktuellen Pakete treffen kontinuierlich ein.
• Manjaro verfolgt den Semi- oder kuratierten Rolling-Release Ansatz: Pakete werden in kontinuierlichen Stufen ausgerollt.

Bei den getakteten oder LTS-Varianten bedeutet das für die Anwenderin eine Neuinstallation nach einer bestimmten Zeit; bei getakteten nach ca. 6 bis 18 Monaten, bei LTS-Releases nach ca. 2 Jahren. Verwendet man eine Rolling-Release-Distribution, muss man theoretisch niemals neu installieren. Um das "theoretische" geht es in diesem Artikel.

Wer eine Rolling-Distro installiert hat, fragt sich vielleicht, wie lange das Ding schon läuft. Um das herauszufinden, gibt es drölfzig verschiedene Kommandos. Das Einfachste ist dieses:

stat -c %w /
2022-05-04 04:14:44.000000000 +0200

Mein Notebook läuft demnach nicht einmal ein Jahr lang rollend. Auf diesem System habe ich keine Probleme. Manjaro/GNOME läuft darauf bestens. Etwas anders sieht es auf meinem HP-Desktop aus:

stat -c %w /
2021-05-08 15:08:45.000000000 +0200

Der läuft ziemlich genau 1 Jahr länger auf Manjaro, also seit 2 Jahren. Zwei Jahre sollten für ein Rolling-Release kein Problem sein. Im Grossen und Ganzen ist es das auch nicht. Erst seit dem GNOME 43.3 Update kann sich die Desktop-Umgebung auf meinem HP nicht mehr daran erinnern, dass ich das dunkle Erscheinungsbild eingestellt habe. Nach jedem Log-in wird das standardmässige helle Theme angezeigt. Trotz Recherche in diversen Foren und Befragung unserer HELP-Gruppe habe ich noch keine Lösung gefunden. Doch bin ich zuversichtlich; bisher hat die Kraft der Community noch jedes Problem gelöst. In der Zwischenzeit behebe ich das Beibehalten des Dark-Modus mit einem Autostart-Shell-Skript:

gsettings set org.gnome.desktop.interface color-scheme prefer-dark

Spannend wird es, wenn man länger als die üblichen Zweijahres-Zyklen der LTS-Releases unterwegs ist. Da ich diese Laufzeit-Erfahrung noch nicht habe, kann ich nur spekulieren, bzw. die Zeichen, die ich sehe, extrapolieren. Wer an einer Rolling-Distro nicht herumschraubt, wird vermutliche viele Jahre ohne Probleme damit arbeiten können. Doch das Schrauben liegt den meisten Linuxern im Blut. Bei mir ist es sozusagen "berufsbedingt". Für die Artikel bei GNU/Linux.ch muss ich oft Anwendungen installieren, um sie testen und darüber schreiben zu können. Nicht immer mache ich das in einer virtuellen Maschine. Ausserdem optimiere ich gerne meinen GNOME-Desktop mit Erweiterungen, auf dem Weg zur perfekten Umgebung.

Beim GNOME-Desktop kann man sich mit Vanille zufriedengeben, oder den Kampf gegen die Minimalisierung aufnehmen. Ich schätze, dass viele den zweiten Weg wählen. Und dieser Weg hat einen Namen: Extensions. Dummerweise ist die Welt der Erweiterungen ein Minenfeld. Sehr ähnliche Erweiterungen drehen an sehr ähnlichen Parametern in den GNOME-Settings. Da ist es kein Wunder, wenn die Erweiterungen die Desktop-Umgebung zur Konfusion bringen.

Meine Vermutung ist, dass man jede Rolling-Distribution nach einer gewissen Zeit "kaputtgefrickelt" hat. Dann ist eine Neuinstallation fällig. Die Formel dafür hat zwei Variablen: Zeit und Frickel-Energie. Je länger, desto kaputt. Je mehr Gefrickel, desto kaputt.

Mich würde die Erfahrung der Langzeit-Roller zu diesem Thema interessieren. Wie lange konntet ihre eure Rolling-Distro am Leben erhalten? Wie sah euer Frickel-Faktor aus? Schreibt es gerne in die Kommentare.

---

GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

Fr, 24. Februar 2023, Fabian Schaar

Hinweis: Das ist ein Meinungsartikel.

"Immutable" Distributionen sind in letzter Zeit in aller Munde. Alle reden über openSUSE ALP, Fedora Silverblue und Konsorten, oder haben zumindest davon mitbekommen. Ich wusste lange Zeit nicht, was ich von dieser Entwicklung halten sollte. Ein System, was "unberührbar" ist, klang für mich eher nach "unkontrollierbar" als nach "unkaputtbar".

Mittlerweile kann ich besser nachvollziehen, warum unveränderliche Distributionsmodelle und Distributionen einen derartigen Aufschwung erlebt haben. Das Konzept ist für mich umso spannender geworden, je länger ich mich damit beschäftigt habe. Besonders wichtig war vermutlich auch, das Ganze selbst einmal unvoreingenommen auszuprobieren. Ohne die Ganze Zeit an etwaige Nachteile zu denken.

Heute habe ich Fedora Silverblue auf meinem Hauptrechner installiert: All-in sozusagen. Interessanter Weise bin ich wirklich überrascht, sehr positiv. Ursprünglich hatte ich bedenken, dass das Zusammenspiel aus Flatpaks und System-Layering zu speicherintensiv werden könnte. Ich habe mir schon durchgerechnet, wie groß so ein System wohl werden könnte, aber rückblickend wäre das vielleicht gar nicht nötig gewesen.

Der Bedarf an Plattenplatz beläuft sich auf etwa 15 GB, und das bei knapp über 50 installierten Flatpaks. Die Bedenken, die ich ursprünglich hatte, waren nicht gerechtfertigt und haben meine Vorstellungen, nicht nur von Silverblue, aber auch vom Gesamtkonzept "Immutable" getrübt.

Dieser ursprüngliche Pessimismus hat sich, sobald ich das System einmal tatsächlich auf der richtig echten Platte hatte, ziemlich schnell in eine gewisse Euphorie gewandelt. Sicher, Silverblue hat noch ein paar Ecken und Kanten, um ein Einlesen in die Dokumentation kommt man auf keinen Fall drum herum und auch eine gewisse Aufbruchstimmung kann nicht schaden. Aber: Alles in Allem bin ich doch ziemlich angetan.

Ich hätte nicht gedacht, dass mich ein Konzept, dem ich bis vor ein paar Wochen oder Tagen noch eher skeptisch gegenüberstand derartig überzeugen könnte. Ja, Silverblue macht manches anders, manches muss man umlernen und auch ich habe noch ein paar Wünschlein. Aber: Alles in allem ist Silverblue schwer in Ordnung, zumindest meinem ersten Eindruck zu Folge.

Die Systemeinrichtung selbst fällt dabei erstaunlich unkompliziert aus, wobei man sich vielleicht darauf einstellen sollte, was man von der Distribution erwartet. Die Installation verläuft eigentlich ziemlich genau wie eine reguläre Fedora-Installation. Danach muss man sich mit Flatpaks an stelle der klassischen RPMs versorgen.

Fedora liefert nur einen kleine Satz an vorinstallierten Anwendungen aus, dazu gibt es noch Firefox als RPM. Über die Fedora-Flatpaks lassen sich dann weitere Anwendungen installieren. Eine größere Auswahl kann man sich über das Flathub-Repository verschaffen; stand jetzt scheint das auch noch ein Muss zu sein. Die Fedora-Flatpaks sind in der Auswahl dann doch relativ begrenzt. Nichtsdestotrotz zeigt sich hier, dass Fedora und de facto auch Red Hat massiv auf diese Containertechnologie setzen.

Nach der Einrichtung wirkt Silverblue wie ein gut integriertes und vor allem robustes Fedora-System. Dabei wird die typische Aktualität des Software-Stacks gewahrt, aber mit dem Rollback-Konzept kombiniert. Theoretisch kann mit Silverblue eigentlich wenig schief gehen, wenn es denn einmal läuft oder auch nur lief. Ein Rollback und fertig, so einfach soll das gehen. Ich selbst habe diese Funktion noch nicht gebrauchen müssen.

Als Desktop-Anwender komme ich tatsächlich besser mit Flatpak aus, als ich mir das selbst hätte vorstellen können. Die Auswahl ist, gerade mit dem Flathub, mehr als ausreichend groß. Das Plattenplatz-Problem scheint zumindest momentan alles andere als ein Problem zu sein.

Im Zuge der Flatpak-Installationen habe ich wesentlich mehr mit GNOME Software als der Kommandozeile gearbeitet. Davon mag man halten, was man will. Flatpak ist jedenfalls nicht unbedingt für die unkomplizierte Namensgebung der einzelnen Pakete bekannt.

Auch die Kritikpunkte, die mir bisher aufgefallen sind, halten sich eher in Grenzen: Einerseits sind die Fedora-Flatpaks zu limitiert, als das man auf das Flathub verzichten könnte. Dieses kann aber während der Ersteinrichtung in Version 37 aber noch nicht einfach hinzugefügt werden. Für Version f38 soll sich das aber ändern, zumindest für die reguläre Workstation-Ausgabe.

Das Konzept der Fedora-Flatpaks finde ich trotzdem löblich. Fedora kann so eine gewisse Kontrolle über die eigene Anwendungsverwaltung behalten, steht aber einer etwaigen Vereinfachung der Paketverwaltungen auf das Flatpak-Format nicht im Wege.

Schade finde ich, dass sich die Flathub-Anwendungen nicht nach Lizenzen filtern lassen, weder auf flathub.org, noch über GNOME Software. Dahingehend würde ich mir, der Softwarefreiheit zu Liebe, einige Verbesserungen wünschen.

Über die Performance-Probleme von GNOME Software selbst kann ich einigermaßen hinwegsehen. So weit ich weiß, arbeiten die GNOME-Entwickler gerade daran. Ganz nebenbei scheint mir das einfache Konzept der GNOME-Arbeitsumgebung nur zu gut in das von Silverblue zu passen. Beide Projekte scheinen sich angenehm zu ergänzen.

Der größte Verbesserungsbedarf besteht in meinen Augen bei der Integration von Drittanbieterquellen, insbesondere RPM Fusion. Ich vermute stark, dass ein Großteil der Anwender um die Installation von Multimedia-Codecs nicht herumkommen wird, ich bin da keine Ausnahme.

Während die Installation von RPM Fusion an sich, und auch die der Codecs ohne Probleme funktioniert hat, bemerken selbst die Maintainer im entsprechenden HowTo-Abschnitt auf rpmfusion.org, dass die Integration momentan noch nicht ideal ist, gerade, was den Wechsel zwischen den Fedora-Hauptversionen angeht.

Ich hoffe, dass es in Zukunft noch weitere Fortschritte in dieser Richtung geben wird. Im Moment ist die Situation nicht unfassbar schrecklich, und doch merkt man, dass Silverblue nicht primär darauf ausgelegt ist, mit (Drittanbieter-)RPMs umzugehen. Vermutlich wäre ein erster sinnvoller Schritt eine Erweiterung der offiziellen Fedora-Dokumentation um derartige Problemstellungen.

Was die bestehende Dokumentation angeht, werden neue Nutzerinnen und Nutzer gut in das Konzept eingeführt. Man muss halt lesen wollen, aber ich glaube, dafür ist die Distribution interessant genug. Die wichtigen Grundfunktionen sind gut und übersichtlich dokumentiert, die Grundkonzepte werden vergleichsweise anschaulich dargelegt. Schade ist, dass diese Dokumentation im Moment noch ausreichende Englischkenntnisse voraussetzt.

Abschließend möchte ich festhalten: Fedora Silverblue hat mich sehr positiv überrascht. Die Einrichtung und Nutzung des Systems wirken zwischen den mittlerweile oftmals gesehen Konzepten der Distributionslandschaft frisch und modern. Wer sich einmal darauf einlässt, scheint mit Silverblue ein modernes und gleichzeitig robustes System zu erhalten.

Ich persönlich bin mittlerweile umso gespannter, wie sich das Projekt weiterentwickelt. Mittlerweile aber nicht mehr, weil ich Angst habe um die bisherigen Errungenschaften der GNU/Linux-Welt, sondern weil ich hoffe, dass sich Silverblue dort verbessern kann, wo es sinnvoll und manchmal auch nötig ist.

Fedora-Projektseite: https://getfedora.org/

Fedora-Silverblue-Projektseite: https://silverblue.fedoraproject.org/

Bild: "Fedora (clothing)" von David Ring, Europeana Fashion; Creative Commons CC0 1.0 Universal Public Domain Dedication, verteilt über Wikimedia Commons.

---

GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

Do, 23. Februar 2023, Ralf Hersel

Wie Canonical auf dem Ubuntu-Discourse-Kanal vorgestern mitteilte, hat man sich zusammen mit den Ubuntu-Flavors entschieden, zukünftig das Paketformat Flatpak nicht mehr standardmässig zu unterstützen. Die Begründung für diesen Schritt ist lang und nachvollziehbar. Ich möchte diese herausdestillieren und anschliessend meine Meinung zu dieser Entscheidung mitteilen.

Da die Begründung lang und salbungsvoll ist, gebe ich hier die Essenz wieder:

Die Ubuntu-Flavours werden als Ökosystem von Linux-Variationen bezeichnet, die Auswahl und Vielfalt fördern. Sie bauen auf einem gemeinsamen Kern auf, bei dem sofort klar ist, dass man Ubuntu verwendet, und bieten darüber hinaus ihre eigenen Feinheiten.

Ein solcher grundlegender Aspekt einer jeden Linux-Distribution ist die Paketierung. Die grossen Distributionen haben alle ihre eigenen Entscheidungen getroffen, um Konsistenz in ihrem Ökosystem zu gewährleisten. Ubuntu baut auf einer Grundlage von Deb-Paketen auf und glaubt an die Vorteile von Snaps. Das Ziel ist es, eine sichere und einfache Benutzererfahrung zu bieten und die Wartung von Paketen zu vereinfachen.

In einer idealen Welt gibt es für die Benutzer nur eine einzige Möglichkeit, Software zu installieren. Dabei kann man erwarten, dass dieser Mechanismus von der Gemeinschaft unterstützt wird und die meiste Aufmerksamkeit erhält, wenn es um die Lösung von Problemen in Softwarepaketen geht. Wenn eine neue Paketierungstechnologie standardmässig bereitgestellt wird, wird erwartet, dass die Distribution die Community unterstützt und sich an der Entwicklung beteiligt, um Probleme zu lösen. Dies führt zu einer Fragmentierung, anstatt sich auf die Verbesserung der für die Distribution ausgewählten Technologien zu konzentrieren.

Ubuntu und seine Varianten betrachten Debs und Snaps als ihren Standard. Die Benutzer haben die freie Wahl, ihre Software aus anderen Quellen zu beziehen, einschliesslich Flatpak. Eine Möglichkeit, diese Alternativen zu installieren, ist und wird auch weiterhin zur Verfügung stehen.

Das Flatpak-Format sowie die Pakete zur Integration von Flatpak in das jeweilige Software-Center werden in der nächsten, im April 2023 erscheinenden Version, Lunar Lobster, nicht mehr standardmässig installiert. Nutzer, die bisher Flatpak verwendet haben, sind vom Upgrade nicht betroffen. Diejenigen, die noch nicht mit Flatpak gearbeitet haben, werden Software aus den Ubuntu-Repositories und dem Snap Store 11 erhalten.

Meine Meinung

Ich halte die vorgebrachten Argumente für gut und richtig. In den alten Zeiten haben wir GNU/Linux-Distributionen dafür gelobt, dass sie die Repository-basierte Softwarebereitstellung hatten, lange bevor andere Betriebssystem-Hersteller auf diese Idee kamen. Zwar gab und gibt es die nativen Paketformate, die zu einem Distributions-Stamm gehören (deb, rpm, usw.); man hatte jedoch nur eine Paketquelle für die Distro seiner Wahl zur Verfügung. Das war die ideale Welt, die Canonical weiter oben beschreibt.

Mit dem Aufkommen der Container-Formate (Flatpak, Snap, AppImage) sollte primär eine Herausforderung für Entwickler:innen gelöst werden, nämlich die Plattform-übergreifende Erzeugung von Paketen. Dieses Ziel hätte erreicht werden können, wenn man sich auf ein Format geeinigt und die nativen Formate damit abgelöst hätte.

Bisher wurde eher das Gegenteil erreicht. Es gibt immer noch die "alten" Formate und drei der neuen. Somit werden immer noch DEBs, RPMs, Arch-Pakete, sowie Flatpaks, AppImages und Snaps gebaut. Der Turmbau von Babel schreitet voran. Hoffentlich befinden wir uns in einer Konsolidierungsphase, an deren Ende ein Paketformat herauskommen wird. Ich schätze die Situation so ein, dass Flatpak sich als Standardformat durchsetzen wird.

Aus der Sicht von Anwenderinnen und Anwendern hat sich auch nichts verbessert. Während man bisher einen Paketmanager hatte, der die gesamte Softwarepalette in einem Format anbot (z.B.: Apt für DEB-Pakete), findet der User heute eine Vielzahl von Formaten im Paketmanager der Distribution. Hier ein Beispiel aus Pamac, dem grafischen Paketmanager von Manjaro:

Dort seht ihr Inkscape als Arch-Paket, Flatpak und aus dem AUR (Arch User Repository). Hätte ich Snap eingeschaltet, würdet ihr auch dieses sehen. Für die Endanwenderin ist diese Situation nicht optimal. Welches Paket soll man installieren? Die meisten Anwender sind mit dieser Entscheidung überfordert. Für Fortgeschrittene muss das kein Nachteil sein, weil nicht alle Pakete gleich gut funktionieren. Ich führe eine Liste von Anwendungen, in der ich notiere, welches Paketformat am besten läuft (ja, Paket ist nicht gleich Paket).

Auch dieses Beispiel zeigt, dass die Entscheidung von Canonical und den Ubuntu-Flavours richtig ist. Die Anwenderin möchte für eine Applikation gerne ein Paket angeboten bekommen, statt vier verschiedene. Ein gut gepflegtes Software-Repository, welches von der Distribution optimal unterstützt wird, ist besser als vier schlecht gepflegte.

Somit haben die Ubuntus alles richtig gemacht, bis auf einen entscheidenden Fehler. Sie hätten das Snap-Format in die Wüste schicken und stattdessen Flatpak zum Standard erklären sollen. Warum? Weil sich die Mehrheit der Entwickler-Community bereits für das Flatpak-Format entschieden hat und die Mehrheit der Distributionen dieses Format bevorzugen. Ausserdem möchte niemand ein proprietäres Backend haben. Die Entscheidung von Canonical führt zum Gegenteil des Wünschenswerten. Statt das Paket-Babel einzufrieden, wird nun die Paket-Spaltung zementiert.

Auf lange Zeit werden wir ein unnötiges Nebeneinander von Snaps und Flatpak sehen. AppImages spielen keine grosse Rolle und die nativen Formate werden langfristig verschwinden. Meiner Meinung nach hat sich Canonical erneut für die Spaltung der Community entschieden. Hätte Mark Shuttleworth seine Snaps aufgegeben und sich für Flatpaks entschieden, hätte die Freie Software Welt einen grossen Schritt vorwärtsgemacht.

Quelle: https://discourse.ubuntu.com/t/ubuntu-flavor-packaging-defaults/34061?u=d0od

---

GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

Unter dem Namen MDN Plus bietet Mozilla eine Premium-Version seiner Entwickler-Dokumentation MDN Web Docs an. Mit filterbaren Update-Tabellen und Werbefreiheit gibt es zwei neue Vorteile für Abonnenten.

Mozilla ist vor allem für seine kostenlosen Produkte wie den Browser Firefox bekannt. Um den Nutzern zusätzliche Mehrwerte zu bieten, aber auch um die finanzielle Abhängigkeit von Suchmaschinen-Anbietern zu reduzieren, setzt Mozilla vermehrt auch auf kostenpflichtige Premium-Angebote wie das Mozilla VPN, Firefox Relay Premium – oder MDN Plus.

Das bietet MDN Plus bereits

Dies sei gleich zu Beginn klargestellt: Die zahlreichen Artikel der MDN Web Docs werden natürlich auch in Zukunft kostenlos bleiben. MDN Plus bietet zusätzliche Funktionen für Nutzer, die so außerdem den Betrieb sowie die Weiterentwicklung (auch der kostenfreien Version) der MDN Web Docs unterstützen können. Außerdem erwägt Mozilla, einen Teil der Einnahmen in Open Source-Projekte zu investieren, welche zu den MDN Web Docs beitragen.

Im Vorstellungs-Artikel von MDN Plus habe ich bereits ausführlicher die Vorteile vorgestellt, welche zum Start von MDN Plus verfügbar waren. Dazu gehört die Möglichkeit, Artikel zu einer persönlichen Sammlung hinzufügen und Notizen dazu hinterlassen zu können, sowie die Speicherung von Artikeln, um diese auch ohne aktive Internetverbindung lesen zu können.

Jetzt MDN Plus abonnieren

NEU: Updates ersetzen Benachrichtigungen, Basis-Feature kostenlos für alle

Ein Feature von MDN Plus war die Möglichkeit, Artikeln folgen zu können, um in der Folge über Änderungen an diesen Artikeln benachrichtigt zu werden, zum Beispiel wenn ein Artikel mit neuen Informationen zur Browser-Unterstützung aktualisiert wird. Dieses Feature wurde in seiner bisherigen Form entfernt und durch Updates ersetzt.

Dabei handelt es sich um eine tabellarische Auflistung von Dokumentations-Änderungen in Zusammenhang mit Browser-Updates. Dies schließt nicht nur Firefox, sondern auch andere Browser wie Chrome, Edge und Safari ein. Jeder Eintrag beinhaltet die entsprechende Kompatibilitätstabelle, die mit nur einem Klick angezeigt werden kann, sowie einen Link auf den entsprechenden Artikel.

Das neue Updates-Feature steht allen Nutzern kostenlos zur Verfügung. Nutzer von MDN Plus können die Ergebnisse nach Browser und Kategorie wie HTML, JavaScript oder CSS filtern. Auch eine Einschränkung auf gespeicherte Artikel ist möglich und ein Filterfeld erlaubt die Suche nach beliebigen Begriffen. Außerdem können Nutzer von MDN Plus die Sortier-Reihenfolge anpassen. Darüber hinaus können Nutzer von MDN Plus direkt aus dieser Tabelle heraus Artikel in einer persönlichen Sammlung speichern.

NEU: Keine Werbeanzeigen für Abonnenten

Seit vergangener Woche gibt es in der Seitenleiste der MDN Web Docs bezahlte Werbeanzeigen. Dabei handelt es sich erst einmal um ein Experiment, welches zunächst für einen Zeitraum von sechs Wochen angelegt ist.

Datenschutz steht für Mozilla dabei an erster Stelle. Die Werbeanzeigen sind Kontext-basiert und haben einen klaren Themen-Bezug zu den MDN Web Docs. Dabei gibt es keine Tracking-Pixel oder dergleichen. Die Anzeigen selbst werden nicht einmal über eine andere Domain, sondern direkt über developer.mozilla.org geladen. Interessierte Werbepartner können über diese Seite mit Mozilla in Kontakt treten.

Nutzer von MDN Plus können die Werbeanzeigen abschalten.

Der Beitrag MDN Plus: Update-Tabellen und Werbefreiheit als neue Features erschien zuerst auf soeren-hentzschel.at.

Mi, 22. Februar 2023, Fabian Schaar

Die Distribution NeptuneOS hat die Beta-Version 7.9 veröffentlicht. Diese basiert auf dem Testing-Zweig von Debian und hat somit die KDE Plasma-Beta für die Version 5.27 sowie die Linux-Version 6.1.8 im Gepäck.

Einen besonderen Wert legen die Entwickler dabei traditionell auf die Integration des KDE Plasma-Desktops sowie verschiedener Multimedia-Anwendungen. Besonders wichtig ist die Out-of-the-Box-Erfahrung.

Erstmals liefert die Distribution auch eine Wayland-Sitzung aus. Neben dem nativen Debian-Paketformat aktiviert Neptune nun auch das Flathub-Repositorium für eine erweiterte Einbindung des Flatpak-Containerformats.

NeptuneOS in einer älteren Version: Die Entwickler konzentrieren sich unter anderem auf eine gute Multimedia-Erfahrung.

Die Distribution kann von der Projektseite heruntergeladen werden. Dort finden sich auch weitere Informationen zur neuen Test-Veröffentlichung.

Quelle: https://neptuneos.com/de/news-reader/neptune-7-9-beta-1-bereit-zum-testen.html

Bildquelle: https://neptuneos.com/de/screenshots.html

---

GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel diskutierst, sei es in unseren Chat-Gruppen oder über die Kommentarfunktion. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

Di, 21. Februar 2023, Lioh Möller

Das openSUSE Projekt hat die Verfügbarkeit einer Beta der kommenden Leap Version 15.5 bekannt gegeben. Dabei handelt es sich um einen Point-Release der seit 2018 veröffentlichten 15.x Serie, welche eine Binärkompatibilität zu der kommerziellen Enterprise Distribution SLE 15 (SUSE Linux Enterprise) bietet.

Parallel dazu arbeitet das Team aktuell unter dem Namen Adaptable Linux Platform (ALP) an einer Umgestaltung der Distribution, mit dem Ziel ein sogenanntes Immutable-System anzubieten, ähnlich wie es bei Fedora Silverblue bereits seit Längerem der Fall ist.

Die nun vorliegende Beta-Version enthält unter anderem einen aktualisierten Mesa-Stack, sowie eine vereinfachte Möglichkeit zur Installation von H.264 Codecs. Als Kernel kommt, wie es auch bei der aktuellen stabilen Version der Fall ist, weiterhin Version 5.14 zum Einsatz.

KDE Plasma hingegen soll in openSUSE 15.5 in der aktuellen Version 5.27 LTS enthalten sein.

Die Architekturen x86_64, AArch64, PowerPC, sowie s390x sollen unterstützt werden.

Die Veröffentlichung des Release Candidates ist für April geplant und die stabile Version soll am 7. Juni folgen.

Quelle: https://news.opensuse.org/2023/02/21/leap-reaches-beta-phase/
Download https://get.opensuse.org/testing

---

GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel diskutierst, sei es in unseren Chat-Gruppen oder über die Kommentarfunktion. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

Di, 21. Februar 2023, Ralf Hersel

Die GNU/Linux-Distribution Solus OS ist bekannt für ihre Eigenständigkeit (built from scratch) und als Erfinderin des Budgie-Desktops. Auch wir haben mehrere Male über die Distro berichtet. Seit Mitte Januar ist die Webseite, der Dev Tracker und das Forum des Projektes nicht mehr erreichbar. Wer die Geschichte von Solus OS über die letzten Jahre verfolgt hat, kann sich an Ikey Doherty erinnern, der das Projekt im September 2015 gestartet hat, und es im November 2018 unter mysteriösen Umständen verliess.

Das stürzte die Distribution in eine Krise, die von Josh Strobl einige Zeit später aufgefangen wurde. Er führte das Projekt wieder in geordnete Bahnen. Doch auch Josh wandte sich nach sechs Jahren intensiver Arbeit von Solus ab, und verliess es im Januar 2022.

Zu den aktuellen Ausfällen schreibt Beatrice Meyers (Technical Lead des Solus Projektes) auf Twitter:

Wie viele bereits bemerkt haben, sind die Solus-Server ausgefallen. Ich habe bestätigt, dass die Daten intakt sind. Dies scheint ein libvirt dnsmasq Problem zu sein. Ich werde mich heute Nachmittag mit den IT-Leuten auf der Arbeit beraten, um zu sehen, ob wir das Problem nicht lösen können. Ich danke für eure Geduld.

Zum Glück haben diese technischen Probleme keine Auswirkungen auf die Server der Solus OS-Paket-Repositories. Damit gibt es keine Unterbrechung im Software-Update-Prozess der Distribution. Leider scheint Beatrice aufgrund gesundheitlicher Probleme, die Server bis heute nicht wiederbeleben zu können. GNU/Linux.ch wünscht ihr gute Besserung.

Solus ist eine etablierte GNU/Linux-Distribution, die nicht von einer einzelnen Person (Beatrice) abhängen darf. Als eigenständige, von Grund auf neu entwickelte Distro, hat Solus eine Daseinsberechtigung, insbesondere, weil das Projekt neben der Distribution auch den Budgie-Desktop entwickelt hat.

Ich wünsche dem Projekt alles Gute. Es wäre sehr schade, wenn Solus OS wegen fehlender Unterstützung sterben würde.

Quellen:

• https://en.wikipedia.org/wiki/Solus_(operating_system)
• https://distrowatch.com/table.php?distribution=solus
• https://twitter.com/SolusProject/status/1616025519501312007

---

GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel diskutierst, sei es in unseren Chat-Gruppen oder über die Kommentarfunktion. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

In diesem dritten Teil meiner Serie über RHEL System Roles nutze ich die Rolle timesync, um die NTP-Pool-Zone de.pool.ntp.org für meine Hosts zu konfigurieren.

Ich möchte mit diesem Artikel zeigen, wie einfach die Nutzung der RHEL System Roles ist, um eine Gruppe von RHEL-Servern zu konfigurieren. Dabei muss ich mich nicht um Details wie die Frage kümmern, ob auf meinen Zielhosts ntpd oder chronyd für die Zeitsynchronisierung genutzt wird. Diese Aufgabe löst die Ansible-Rolle für mich.

Bevor ich fortfahre, habe ich eine Warnung: Diese Rolle ersetzt die Konfiguration auf den Zielsystemen. Alle zuvor dort getroffenen Einstellungen werden verloren gehen.

Man muss sich also entscheiden, ob man die Zeitsynchronisation komplett über diese Rolle steuern möchte oder gar nicht.

Voraussetzungen

Auf dem Ansible-Controller müssen die Pakete ansible-core und rhel-system-roles installiert sein.

Das Playbook

Ich möchte mehrere NTP-Server konfigurieren. Für diesen Anwendungsfall liefert die Rolle timesync bereits ein Beispiel mit, welches ich mittels Copy-Paste-and-Modify in mein Playbook übernehme.

[root@ansible-ctrl ]# cp /usr/share/doc/rhel-system-roles/timesync/example-multiple-ntp-servers-playbook.yml ansible/use_de_ntp_servers.yml

Das Playbook sieht nach der Anpassung wie folgt aus:

- hosts: all
  vars:
    timesync_ntp_servers:
      - hostname: 0.de.pool.ntp.org
        iburst: yes
      - hostname: 1.de.pool.ntp.org
        iburst: yes
      - hostname: 2.de.pool.ntp.org
        iburst: yes
      - hostname: 3.de.pool.ntp.org
        iburst: yes
  roles:
    - rhel-system-roles.timesync

Testlauf in Labor-Umgebung

Um zu sehen, wie die Datei /etc/chrony.conf vor und nach dem Playbook-Lauf aussieht, lasse ich das Playbook zuerst mit den Optionen -C (aktiviert Check-Mode) und -D (zeigt die Änderungen an) laufen. So kann ich vorab prüfen, welche Änderungen vorgenommen werden, bevor es ernst wird. Die Ausgabe ist über 500 Zeilen lang. Ich habe sie auf Gist gepostet und hier eingebunden. Wer sich für die Ausgabe nicht interessiert, kann direkt zur Zusammenfassung springen.

Anschließend habe ich das Playbook ohne die Optionen -C und -D ausgeführt und meine Hosts wie gewünscht konfiguriert.

Zusammenfassung

Mit der RHEL System Role timesync kann die Zeitsynchronisation verschiedener RHEL-Releases schnell und einfach konfiguriert werden, ohne Kenntnis über die konkrete Implementierung auf den Zielsystemen zu besitzen.

Gleichzeitig kann ein Blick in die Struktur der Rolle und den Inhalt der dazugehörigen Dateien Aufschluss darüber geben, wie Ansible-Rollen für mehrere RHEL-Major-Releases erstellt werden können. Man kann dies für die Erstellung eigener Rollen mit ein wenig Transferleistung wiederverwenden.

Weiterführende Quellen und Links

1. Red Hat Enterprise Linux (RHEL) System Roles {en}
2. Ansible Documentation: Role Directory Structure {en}
3. Red Hat Software and Download Center {en}
4. Die Vorteile einer Red Hat Subskription
5. RHEL System Roles: selinux
6. RHEL System Roles: sshd
7. RHEL System Roles: firewall