RSS ist ein ebenso altes wie wichtiges Protokoll, um unabhängig von Algorithmen und irgendwelchen Interessen Dritter Inhalten zu folgen und Nachrichten zu konsumieren. Ausgerechnet in diesem so wichtigen Bereich ist Linux viel schlechter aufgestellt als macOS oder Windows.

Das finde ich ebenso bedauerlich wie verwunderlich. Normalerweise ist Linux bei so alten „Power-Lösungen“ immer ganz gut aufgestellt, aber hier überzeugt man vor allem durch Leerstellen. Feedsynchronisation ist bei der Vielzahl an Endgeräten heute nahezu unumgänglich, wenn man sich nicht jedes gelesene Feed merken möchte und angesichts der verbreiteten Unart, Feeds zu kürzen, braucht es eine gute Browser-Integration oder zumindest Weiterleitung an einen Browser.

Zur Bedeutung von RSS hatte ich mich hier bereits ausgelassen. Lange Zeit hatte ich mittels FreshRSS meine Feeds zwischen meinen Geräten abgeglichen. Dafür gibt es aber unter Linux kaum passende Clients. Den Abgesang auf FeedReader hatte ich vor bald 2 Jahren geschrieben. Schweren Herzens hatte ich mich von der Feed-Synchronisation verabschiedet und mit lokalen Feeds gearbeitet. Fazit: Es geht, aber es geht nicht gut.

Umso mehr habe ich mich gefreut als Rajdeep Singha FeedReader geforkt hat und seitdem unter dem neuen Namen „Communique“ erste Modernisierungsmaßnahmen vorgenommen hat.

Das Programm ist eigentlich für elementary OS bzw. die Pantheon Shell entwickelt, aber sieht erfahrungsgemäß auch unter GNOME und anderen Gtk-basierten Desktopumgebungen gut aus.

Es steht momentan als Flatpak zur Verfügung und ist zusätzlich unter openSUSE auch über den OBS zu finden. Einige nervige Bugs sind behoben, die GUI moderat und absolut sinnvoll überarbeitet und die Synchronisation läuft ohne Probleme.

Hoffentlich sehen wir da noch die ein oder andere neue Funktion, aber bereits im jetzigen Zustand ist es ein massiver Fortschritt zu z. B. Liferea oder Akregator.

Für mich eines der größten Highlights im Oktober. Nebenbei nutze ich die Gelegenheit, um beim Re-Umstieg von Lokal auf FreshRSS die Abonnements auszumisten und nur noch das hinzuzufügen, was ich auch wirklich lesen möchte.

Der Artikel FeedReader lebt weiter als Communique erschien zuerst auf [Mer]Curius

Mit Ubuntu 21.10 »Impish Indri« hat Canonical das letzte Release vor der nächsten LTS-Version 22.04 fertiggestellt. Die wichtigsten Neuerungen lassen sich in zwei Punkten zusammenfassen: Ubuntu hat den Sprung auf Gnome 40 vollzogen (wenn auch nicht auf die aktuelle Version 41), und Firefox steht standardmäßig als Snap-Paket zur Verfügung. Das neue Installationsprogramm, an dem Canonical zur Zeit arbeitet, war noch nicht so weit gediehen, dass es für Version 21.10 zum Einsatz kommen konnte.

Firefox und Snap

Leser meines Blogs wissen, dass ich kein ausgesprochener Fan der neuen Paketformate Snap und Flatpak bin. Ich verstehe natürlich den Nutzen distributions- und versionsunabhängiger Pakete, bin aber der Meinung, dass die Nachteile aufgrund des riesigen Overheads überwiegen. Unter Ubuntu 21.10 sind außer diversen Basispaketen nur der Paketmanager snap-store (das ist Canonicals Variante zu Gnome Software) sowie Firefox installiert:

snap list

Name               Version             Revision  Tracking         Herausgeber  Hinweise
bare               1.0                 5         latest/stable    canonical✓   base
core               16-2.51.7           11743     latest/stable    canonical✓   core
core20             20210928            1169      latest/stable    canonical✓   base
firefox            93.0-1              631       latest/stable/…  mozilla✓     -
gnome-3-38-2004    0+git.6ba6040       76        latest/stable/…  canonical✓   -
gtk-common-themes  0.1-59-g7bca6ae     1519      latest/stable/…  canonical✓   -
snap-store         3.38.0-66-gbd5b8f7  557       latest/stable/…  canonical✓   -

Der Platzbedarf für diese Pakete beträgt 674 MByte:

ls -lh /var/lib/snapd/snaps/

insgesamt 674M
-rw------- 1 root root 4.0K Oct 10 09:58 bare_5.snap
-rw------- 1 root root 100M Oct 10 09:58 core_11743.snap
-rw------- 1 root root  62M Oct 10 09:57 core20_1169.snap
-rw------- 1 root root 151M Oct 10 09:57 firefox_631.snap
-rw------- 1 root root 243M Oct 10 09:58 gnome-3-38-2004_76.snap
-rw------- 1 root root  66M Oct 10 09:58 gtk-common-themes_1519.snap
-rw------- 1 root root  55M Oct 10 09:58 snap-store_557.snap

Der Vorteil des Firefox-Snap-Pakets besteht darin, dass Canonical dieses Paket in Zukunft für sämtliche Versionen von Ubuntu warten kann. Ein nicht unerheblicher Nachteil besteht darin, dass der erste Start von Firefox Snap-bedingt spürbar langsamer als bisher erfolgt. (Ab dem zweiten Start ist der Unterschied kaum mehr wahrnehmbar.)

Das nächste Ärgernis ist die Verwaltung der Gnome Shell Extensions: Obwohl chrome-gnome-shell in Ubuntu standardmäßig installiert ist und ich auch die Firefox-Erweiterung Gnome Shell-Integration beim ersten Besuch von https://extensions.gnome.org/ installiert habe, kann Firefox die Extensions nicht verwalten. Meine Vermutung ist, dass das Paket chrome-gnome-shell im Ubuntu-Dateisystem für Firefox unzugänglich ist, weil dieser — Snap sei dank — ja quasi in seinem eigenen Betriebssystem läuft.

Ich bin der Sache nicht auf den Grund gegangen, weil es eine bequeme Alternative gibt: Ich habe Google Chrome installiert. Das Programm gibt es von Google als »richtiges« Paket samt eigener Paketquelle. (Es gibt in den offiziellen Ubuntu-Paketquellen übrigens noch immer ein DEB-Paket für Firefox. Dieses Paket soll aber in Version 22.04 verschwinden.)

Insgesamt stellt sich die Frage, ob Canonical mit der Snap-Entscheidung Firefox unter Ubuntu nicht endgültig den Todesstoß versetzt. Ein wenig gewinnt man in den letzten Jahren den Eindruck, Firefox entwickelt sich zu einem Programm für Idealisten.

Gnome 40

Über Gnome 40 habe ich schon genug geschrieben. Den aus meiner Sicht größte Mangel — das horizontale Dock — hat Canonical mit dem vorinstallierten Ubuntu Dock behoben. Dabei handelt es sich um eine Variante zu Dash to Dock (siehe auch Gnome 40 mit einem vertikalen Dock). Über das merkwürdige Aussehen des Papierkorb-Icons, das im Dock angezeigt wird, kann man streiten, aber davon abgesehen funktionieren sowohl Gnome 40 als auch das Dock wunderbar.

In den Systemeinstellungen kann zwischen einem hellen und einem dunklen Erscheinungsbild ausgewählt werden. Hier können Sie auch die Icon-Größe im Dock sowie dessen Position einstellen.

Versionen

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel     5.13   Gnome          40   bash       5.1   Apache     2.4
glibc      2.34   Firefox        93   docker   20.10   CUPS       2.3
X-Server   1.20   Gimp         2.10   gcc       11.2   MySQL      8.0
Wayland    1.19   LibreOffice   7.2   Java        11   OpenSSH    8.4
Mesa       21.2   Thunderbird    91   PHP        8.0   qemu/KVM   6.0
Systemd     248                       Python     3.9   Postfix    3.5
NetworkMan 1.32                                        Samba     4.13
GRUB       2.04 

Als Default-Java-Version gilt 11. Zur Auswahl stehen aber auch Java 16, 17 und sogar schon eine erste Testversion von Java 18. Der Umstieg auf PHP 8.0 ist willkommen; schade ist, dass Python 3.10 den Sprung in Ubuntu 21.10 nicht geschafft hat. (Zugegebenermaßen ist das Release gerade einmal vor 10 Tagen.)

Anmerkung

Für diesen Test habe ich Ubuntu 21.10 ausschließlich in einer virtuellen Maschine getestet. Grundsätzlich hat dabei alles wunschgemäß funktioniert. Einzig das Zusammenspiel mit Wayland hat Probleme verursacht (fallweise schwarzer Bildschirm, in Firefox kein Bild etc.). Ein neuerlicher Login mit X statt Wayland war die Lösung. Ob an den Problemen Wayland oder mein Virtualisierungssystem (KVM/QEMU) Schuld war, kann ich nicht sagen. Ähnliche Probleme hatte ich aber auch schon mit anderen Distributionen. Die Lösung hießt immer X.

Ich habe vor, mein Arbeits-Notebook nächste Woche auf Version 21.10 zu aktualisieren. Falls sich dabei neue Erkenntnisse ergeben (das ist anzunehmen), werde ich diesen Artikel noch einmal aktualisieren. Insbesondere möchte ich testen, wie gut Wayland mit den proprietären NVIDIA-Treibern harmoniert. (Die aktuelle Version der NVIDIA-Treiber ist erstmalig Wayland-kompatibel, aber zumindest laut Fedora-Berichten ist die Sache noch nicht richtig stabil.)

Fazit

Ich habe in den letzten Jahren Ubuntu als Standarddistribution auf meinem wichtigsten Arbeitsrechner verwendet (einem Lenovo-Notebook). Ja, ich habe mehr Rechner und noch viel mehr virtuelle Maschinen, auf denen ein buntes Sammelsurium von Distributionen läuft. Aber grundsätzlich hat sich Ubuntu in den letzten Jahren für mich gut bewährt; es läuft stabil, ich hatte selten ernsthafte Probleme (auch nicht mit Versionen außerhalb des LTS-Zyklus), selbst Microsoft Teams läuft (das brauche ich gelegentlich beruflich) und bin eigentlich zufrieden mit dem, was ich habe. Ganz pragmatisch: Es hat durchaus Vorteile, mit dem Linux-Mainstream mitzuschwimmen.

Bei Snap endet meine Liebe zu Ubuntu aber. Bisher war mein Ansatz, Snap samt allen dort mitgelieferten Paketen einfach zu deinstallieren. Noch ist das möglich: Ich kann Firefox durch ein APT-Paket oder gleich durch Google Chrome ersetzen, und statt dem snap-store verwende ich sowieso apt. Sollte ein Snap-freier Betrieb von Ubuntu irgendwann nicht mehr möglich sein, dann wird es mir sicher gelingen, mich mit einer anderen Linux-Distribution anzufreunden :-)

Quellen / Links / Andere Tests

• Download
• Release Notes
• DistroWatch
• derstandard.at
• heise.de 1
• heise.de 2
• omgubuntu.co.uk
• What’s new im Ubuntu Blog

Verschlüsselung schützt zwar Daten, schränkt aber naturgemäß die Datenverfügbarkeit ein und damit auch die Möglichkeiten zur Wiederherstellung von Daten von defekten Speichermedien oder fehlerhaften Betriebssystemen. Deshalb sind Backups sehr wichtig.

Ist ein unverschlüsseltes System unwiederbringlich defekt, bootet man entweder von einer Live-CD oder baut das Speichermedium aus, um an die Daten zu kommen. Schwieriger wird es, wenn es irgendwelchen Gründen der LUKS Header defekt ist oder das Speichermedium selbst Probleme hat. Datenrettung bei verschlüsselten Systemen ist keine schöne Sache. Deshalb sind Backups hier noch wichtiger als sie es sonst schon sind.

Allerdings gefährden unverschlüsselte Backups wiederum die Sicherheit. Es macht keinen Sinn, ein Betriebssystem komplett zu verschlüsseln, wenn in der Schreibtischschublade eine unverschlüsselte externe Festplatte mit allen Daten liegt. Die Lösung ist hier relativ einfach: Man verschlüsselt auch die externen Speichermedien.

Schwieriger ist das bei Sicherungen auf einem NAS. Die Geräte laufen meist im 24/7-Betrieb oder zumindest dauerhaft in einem festgelegten Nutzungszeitraum. Während der Laufzeit sind die Backup-Volumes naturgemäß entschlüsselt. Die meisten Anwender lassen das NAS-Betriebssystem verschlüsselte Volumes auch gleich beim Start entschlüsseln, da eine zusätzliche Passworteingabe bei entfernten Systemen extrem unpraktisch ist.

Bei den immer beliebteren Backups in der Cloud ist eine clientseitige Verschlüsselung auf dem Gerät des Nutzers während des Backup-Vorgangs sowieso Pflicht, weil man ansonsten alle seine Daten dem Cloud-Betreiber ausliefert.

Man kann hier mit LUKS-Containern oder Verschlüsselungslösungen für die Cloud arbeiten und dann Daten per rsync sichern oder gleich eine integrierte Softwarelösung nutzen.

Vorteile von Déjà Dup

Eine solche integrierte Lösung bietet die GNOME-Software Déjà Dup. Dabei handelt es sich um Frontend für Duplicity, das eine ziemlich ausgereifte Backup-Lösung ist. Ich hatte um Déjà Dup immer einen Bogen gemacht, weil es als GNOME-Programm ziemlich viele Abhängigkeiten in dessen Ökosystem mit sich zieht. Seit meinem vollständigen Wechsel auf die Pantheon Shell ist das kein Problem mehr, weil Déjà Dup sich sehr gut in Gtk-basierte Desktopumgebungen integriert.

Déjà Dup ist eine langjährig etablierte Software und bei allen Linux-Distributionen in den Paketquellen enthalten. Die Version ist dabei zweitrangig, da in den letzten Jahren keine substanzielle Entwicklung jenseits von kleinen Modifikationen und Fehlerbehebungen erfolgte.

Natürlich kann man Duplicity genau wie andere CLI-Lösungen auch ohne grafische Oberfläche nutzen. Ich habe zwar kein Problemen mit der Kommandozeile, aber schätze gute und einfach zu bedienende grafische Oberflächen. Ich möchte nicht für jedes Backup, jeden Mount-Vorgang und jede kleine Wartungsaufgabe einen Befehl eingeben. Die Kommandozeile ist bei mir Anwendungen vorbehalten, deren Vielfalt sich nur schlecht in grafische Umgebungen packen lässt und wo ich mehr Kontrolle benötige. Beispielsweise bei der Paketverwaltung unter openSUSE.

Déjà Dup bietet einige Alleinstellungsmerkmale gegenüber anderen Backup-Lösungen für Linux. Es bietet – wie bereits geschrieben – eine übersichtliche grafische Oberfläche, beherrscht die Verschlüsselung der Backups, kann über GVFS problemlos Netzwerkfreigaben als Backupziele auswählen und lässt sich einfach als automatisieren.

Automatische verschlüsselte Backups mit Déjà Dup

Die Einrichtung ist dank der einfachen Einrichtungsroutine schnell erledigt. Beim Programmstart klickt man einfach auf die Schaltfläche zur Erstellung einer ersten Sicherung.

Anschließend werden die zu sichernden Ordner und die ausgeschlossenen Ordner festgelegt. Standardmäßig schlägt Déjà Dup das Homeverzeichnis des Anwenders zur Sicherung vor und exkludiert Download-Verzeichnis und Papierkorb. Danach legt man das Sicherungsziel fest. Entweder ein Ordner (der auch auf einem externen Speichermedium liegen kann) oder auf einer Netzfreigabe. Abschließend fragt das Programm noch, ob man die Sicherung mit einem Passwort schützen möchte. Hierdurch aktiviert man die clientseitige Verschlüsselung.

• 

• 

Danach beginnt die erste Sicherung. Je nach Menge der zu sichernden Daten, Qualität des heimischen Netzwerks und Geschwindigkeit des NAS, kann dieser Vorgang eine Weile dauern.

Ohne Verschlüsselung legt Déjà Dup bzw. Duplicity die Datensicherung in Form vieler tar.gz Archive an, mit aktivierter Verschlüsselung werden diese Archive mit GnuPG verschlüsselt.

Ist die erste Sicherung erfolgreich durchgelaufen zeigt Déjà Dup die Option zur automatischen Sicherung an.

Sobald man die entsprechende Option aktiviert, startet das Programm mit einem festgelegten Sicherungsintervall. Optionen um die Häufigkeit zu regulieren fehlen allerdings. Eine automatische Sicherung macht natürlich nur Sinn, wenn das Backupziel permanent verfügbar ist.

Déjà Dup sichert die Daten inkrementell, das bedeutet die Sicherung enthalten nur die geänderten Daten. In regelmäßigen Abständen oder bei großer zeitlicher Distanz zwischen zwei Sicherungen führt das Programm automatisch eine Vollsicherung durch.

Eine Wiederherstellung der Dateien ist über den Reiter „Wiederherstellen“ möglich. Über das Dropdown-Menü „Datum“ lassen sich die einzelnen Sicherungen selektieren und einzelne Dateien oder ganze Ordner auf einen beliebigen Stand zurücksetzen.

Nachteile von Déjà Dup

Das führt auch direkt zu den Nachteilen von Déjà Dup. Die Sicherung erfolgt in Archiven und mit Verschlüsselung, die sich ohne entsprechende Software nicht lesen lässt. Es benötigt zwar nicht zwingend Déjà Dup zur Wiederherstellung von Backups, aber zwingend Duplicity und das gibt es nur für Linux. Die so erzeugten Backups lassen sich also nicht unter Windows oder macOS lesen oder wiederherstellen.

Weiterhin lassen sich keine Backup-Profile erstellen. Man kann also mittels Déjà Dup dasselbe System nicht auf ein NAS und zusätzlich noch auf Festplatten sichern. Ich nutze Dèjà Dup deshalb nur für das NAS, weil hier Automatisierung und Verschlüsselung ihre Stärken ausspielen und sichere die Daten zusätzlich noch auf externe Festplatten mittels (G)rsync. Die Sicherung der Daten übernimmt hier eine herkömmliche LUKS-Verschlüsselung.

Zusammengefasst

Déjà Dup bietet eine sehr gute Oberfläche für ein mächtiges Backup-Tool, mit dem sich niedrigschwellig Datensicherungen automatisieren lassen. Beides sind für Backups wichtige Aspekte, weil nur Automatisierung und ein leichter Zugang dafür sorgen, dass Anwender auch wirklich Backups machen und diese regelmäßig durchführen.

Die einfach gehaltene Oberfläche bringt ein paar Nachteile mit sich, aber Déjà Dup ist trotzdem die beste grafische Backuplösung für den Linux-Desktop.

Der Artikel Verschlüsselte Backups mit Déjà Dup und Duplicity erschien zuerst auf [Mer]Curius

Wenn man unter KDE Plasma beispielsweise ein Widget auf den Desktop abgelegt hat, konnte man den Desktop so sperren, dass man die Widgets zum Beispiel so lange nicht mehr verschieben konnte bis man die Sperre aufgehoben hat.

Diese Funktion wurde meines Wissens (warum auch immer) aus der grafischen Oberfläche entfernt. Nun ist es mir in letzter Zeit öfters passiert, dass ich auf ein Icon in der Schnellstartleiste zu lange geklickt haben und dabei den Mauszeiger bewegt hat. Was dazu geführt hat, dass das beispielsweise das Icon über das ich den Browser auf den Desktop verschoben wurde. Was mich nervt.

Die Sperrfunktion gibt es aber intern weiterhin. Hierfür einfach folgendes im Terminal ausführen.

qdbus org.kde.plasmashell /PlasmaShell evaluateScript "lockCorona(true)"

Zum Entsperren dann einfach den gleichen Befehl ausführen und das true auf false ändern. Damit man nicht jedes mal die Sperre manuell aktivieren muss, kann man den Befehl beispielsweise in die Autostart-Funktion eintragen die man über die Systemeinstellung von KDE Plasma bearbeiten kann.

Die MZLA Technologies Corporation hat mit Thunderbird 91.2 ein planmäßige Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.2

Mit dem Update auf Thunderbird 91.2 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 diverse Fehlerbehebungen der Versionsreihe 91, welche sich in den Release Notes (engl.) nachlesen lassen.

Der Beitrag Thunderbird 91.2 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mozilla hat Firefox 93 für Windows, Apple macOS und Linux veröffentlicht. Nach einem kleineren Update auf Firefox 92 vor vier Wochen beinhaltet Firefox 93 dafür umso mehr spannende Neuerungen. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Unterstützung für neues Bildformat AVIF

AVIF steht für AV1 Image File Format und ist ein Bildformat, welches auf dem lizenzfreien Video-Codec AV1 basiert. Ähnlich wie AV1 bei Videos verspricht auch AVIF bei Bildern bei gleichbleibender Qualität deutlich geringere Dateigrößen als konkurrierende Formate wie JPG oder WebP. Für den Website-Besucher bedeutet dies in erster Linie schnellere Ladezeiten auf Websites, welche das neue Bildformat nutzen.

XFA PDF-Formulare können ausgefüllt werden

Seit Firefox 81 ist es mit dem in Firefox integrierten PDF-Betrachter nicht nur möglich, PDF-Dateien anzusehen, sondern auch PDF-Formulare auszufüllen – zumindest sofern es sich um AcroForm-Formulare handelt. Firefox 93 unterstützt auch den XFA-Standard für PDF-Formulare.

Automatisches Entladen inaktiver Tabs bei Ressourcen-Knappheit

Firefox auf Windows kann in Situationen, in denen der zur Verfügung stehende Arbeitsspeicher knapp wird, jetzt automatisch Tabs entladen und auf diese Weise RAM freigeben. Dabei berücksichtigt Firefox verschiedene Faktoren wie den Zeitpunkt der letzten Nutzung, den RAM-Verbrauch des jeweiligen Tabs oder eine aktive Medienwiedergabe, so dass nach Möglichkeit keine Tabs entladen werden, welche vom Nutzer gerade verwendet werden.

Durch das Entladen inaktiver Tabs kann die Wahrscheinlichkeit für sogeannte Out-of-Memory-Abstürze reduziert werden. Bei dieser Art von Absturz handelt es sich um eine der häufigsten Arten von Firefox-Abstürzen.

Ein Wechsel zu einem entladenen Tab lädt diesen automatisch neu. Gegebenfalls eingegebene Formulardaten und die Scroll-Position werden wie bei der Sitzungswiederherstellung nach einem Firefox-Neustart automatisch wiederhergestellt. Dieses Feature wird in einem späteren Update auch für macOS und Linux zur Verfügung stehen.

Privatsphäre: SmartBlock 3.0

Der mit Firefox 87 eingeführte SmartBlock-Mechanismus, welcher in privaten Fenstern sowie in allen Fenstern für jene Nutzer aktiviert ist, welche den strengen Schutz vor Aktivitätenverfolgung aktiviert haben, verbindet Privatsphäre mit Web-Kompatibilität. Dabei ersetzt Firefox die Scripts bekannter Tracking-Dienste durch eine Art Ersatz-Script, welches sicherstellt, dass die Website-Kompatibilität nicht beeinträchtigt wird, während die eigentliche Funktionalität außer Kraft gesetzt wird. So können beispielsweise seitens Website Funktionen aufgerufen werden, welche Google Analytics voraussetzen, ohne dass diese tatsächlich ausgeführt werden und ohne dass es, anders als ohne SmartBlock, Script-Fehler gibt, weil Google Analytics von Firefox blockiert wird.

Nach Smartblock 2.0 in Firefox 90 bringt Mozilla mit SmartBlock 3.0 in Firefox 93 eine erneut verbesserte Version dieses Mechanismus. So wurde die Unterstützung von Google Analytics verbessert und Unterstützung für Optimizely, Criteo, Amazon TAM sowie diverse Werbe-Scripts von Google hinzugefügt.

Privatsphäre: Verbesserter Referrer-Schutz

Beim sogenannten Referrer handelt es sich um die Information, welche Seite der Benutzer besuchte, bevor er auf der aktuellen Seite landete. Aus Privatsphäre-Gründen wurde dieser bereits in Firefox 87 gekürzt. Wurde hier zuvor die komplette URL inklusive möglicher Parameter übermittelt, welche sensible Informationen beinhalten konnten, besteht der Referrer seit dem standardmäßig nur noch aus der Domain. In Firefox 93 folgt eine weitere Verbesserung für Nutzer, welche den strengen Schutz vor Aktivitätenverfolgung aktiviert haben, sowie in privaten Fenstern.

Websites konnten das standardmäßige Referrer-Verhalten außer Kraft und den Privatsphäre-Schutz von Firefox somit effektiv deaktivieren. Eine Website, welche mit Trackern zusammenarbeitet und eine freizügigere Referrer-Politik wählt, würde also immer noch ein Privatsphäre-Problem darstellen. Firefox 93 ignoriert in den beschriebenen Konfigurationen weniger restriktive Referrer-Richtlinien für seitenübergreifende Anfragen, womit der Referrer immer gekürzt wird, unabhängig von den Einstellungen der Website.

Sicherheit: Firefox schützt vor unsicheren Downloads

Downloads, welche bei einer HTTPS-Verbindung der Website nur unverschlüsselt über HTTP übertragen werden, werden von Firefox ab sofort standardmäßig blockiert. Gleiches gilt für Downloads in Sandboxed iFrames, welche nicht das allow-downloads-Attribut besitzen. Bei entsprechenden Download-Versuchen erhält der Nutzer eine Warnung und kann den Download dann entweder verwerfen oder die Warnung ignorieren und den Download erlauben.

(Bildquelle)

Sicherheit: 3DES-Verschlüsselung wird nicht länger unterstützt

Der Verschlüsselungsalgorithmus 3DES war lange populär, gilt allerdings nicht mehr als sicher. Darum wird dieser von Firefox standardmäßig nicht mehr unterstützt. Aus Kompatibilitätsgründen kann dieser durch die Aktivierung der veralteten TLS-Versionen 1.0 und 1.1 implizit wieder mit aktiviert werden.

Sicherheit: Geschlossene Sicherheitslücken

Auch in Firefox 93 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 93 daher für alle Nutzer dringend empfohlen.

Weniger RAM-Verbrauch der Entwicklerwerkzeuge

Mozilla arbeitet bereits seit mehreren Jahren unter dem Projektnamen an einer sogenannten Website-Isolation für Firefox, welche zwischen Firefox 94 und Firefox 96 für alle Nutzer ausgerollt werden soll. Diese verbessert nicht nur die Sicherheit, sondern bringt auf dem Weg dahin auch Verbesserungen im Umgang mit dem RAM. So konnte nicht mehr freigegebener Arbeitsspeicher der Entwicklerwerkzeuge in Firefox 93 signifikant verbessert werden – insbesonders lange Debugging-Sessions können fast 50 Prozent weniger Speicherleaks aufweisen. Weitere große Verbesserungen sind in Firefox 94 zu erwarten: Im gemessenen Szenario sind die Speicher-Leaks der Entwicklerwerkzeuge von Firefox 94 im Vergleich zu Firefox 92 ganze 85 Prozent weniger.

WebRender nicht mehr abschaltbar, Entfernung von Legacy-Backends

Der Grafik-Renderer WebRender ist bereits seit Firefox 91 standardmäßig für alle Firefox-Nutzer aktiviert, entweder mit Hardware-Unterstützung oder in Form von Software-WebRender. Mit Firefox 93 gibt es nicht länger eine Option zur Abschaltung von WebRender und die Entfernung der Legacy-Backends hat begonnen. Dies macht Firefox nicht nur um viele Tausend Zeilen Code leichter, auch ermöglicht dies weitere Performance-Optimierungen in der Zukunft, welche nicht möglich waren, solange die alten Grafik-Backends unterstützt werden mussten.

Nutzer, welche graphische Probleme in Zusammenhang mit Hardware-WebRender haben, können statt einer Deaktivierung Software-WebRender aktivieren, indem über about:config der Schalter gfx.webrender.software auf true geschaltet und Firefox neu gestartet wird.

Kompaktere Lesezeichen-Menüs für Nutzer des kompakten Modus

Mit Firefox 89 führte Mozilla mit Proton ein neues Design für seinen Browser ein. Dieses brachte auch eine größere Darstellung der Lesezeichen-Menüs, was nicht bei jedem Nutzer gut ankam. Ab Firefox 93 respektiert Mozilla an dieser Stelle die Option des kompakten Modus: Nutzer, welche diesen aktiviert haben, haben jetzt auch wieder Platz sparendere Lesezeichen-Menüs.

Verbesserungen der Webplattform

Natürlich unterstützt Firefox auch mit diesem Update wieder weitere Webstandards. So unterstützt Firefox 93 auch Eingabefelder vom Typ <input type=“datetime-local“>. Eine Übersicht über alle Verbesserungen der Webplattform gibt es wie immer in den MDN web docs.

Sonstige Neuerungen von Firefox 93

Die Liste gespeicherter Zugangsdaten unter about:logins zeigt in der linken Spalte jetzt Monats-Überschriftungen bei Sortierung nach letzter Änderung oder letzter Verwendung an.

Wird im Kontextmenü eines Chronik-Eintrags die Funktion „Gesamte Website vergessen“ genutzt, bittet Firefox jetzt zunächst um eine Bestätigung, statt diese Aktion direkt auszuführen.

Das Download-Panel hat optische Detail-Verbesserungen erhalten.

Nutzer von macOS, welche Firefox direkt von der DMG-Datei starten, werden bei der ersten Ausführung aufgefordert, die Installation abzuschließen, um Sitzungsverluste zu vermeiden.

Blinkende Cursor respektieren jetzt den entsprechenden Registry-Eintrag von Windows respektive GTK-Einstellung unter Linux, um nach einer festgelegten Zeit mit dem Blinken aufzuhören und keine CPU-Leistung zu verschwenden. Verbessert wurde auch die CPU-Auslastung bei Verwendung der Suchfunktion bei großen Dokumenten.

Verbesserungen gab es auch wieder bei der Barrierefreiheit, speziell bei der Zusammenarbeit mit dem Screenreader VoiceOver, ebenso mit dem Screenreader Orca, welcher nach dem Start von Firefox nicht länger erst den Wechsel zu einer anderen Anwendung erfordert, um mit Firefox zusammenzuarbeiten.

Natürlich kamen auch in Firefox 93 Fehlerbehebungen und sonstige Verbesserungen unter der Haube dazu.

Der Beitrag Großes Update: Mozilla veröffentlicht Firefox 93 erschien zuerst auf soeren-hentzschel.at.

Am 16. Oktober 2021 findet zum zweiten Mal ein reiner Online-LinuxDay AT statt.

Noch immer hat uns die Covid-Pandemie im Griff und so findet auch dieser LinuxDay wieder online statt.

Dennoch hat sich die Linux User Group Vorarlberg wieder tüchtig ins Zeug gelegt und ein abwechslungsreiches Programm mit 12 Vorträgen zusammengestellt. Informationen für Besucherinnen und Besucher stellt die LUG unter „Was wie wo – 2021“ bereit.

Ich freue mich, wenn wir uns im virtuellen Raum treffen und einen schönen LinuxDay verbringen. Hoffentlich können wir uns im nächsten Jahr wieder vor Ort treffen und ein schönes Wochenende in Dornbirn verbringen.

Viele sprechen und schreiben immer von „der“ Linux Community, aber wenn man näher hinsieht, zerfällt die Community eigentlich in zwei bzw. drei gänzlich unterschiedliche Hauptgruppen. Das sollte man berücksichtigen, wenn man über Akzeptanz und Entwicklung nachdenkt.

Das Kernproblem beim Verfassen eines solchen Artikels ist der eklatante Mangel an belastbaren Zahlen. Das liegt zum einen an Datenschutz-/Privacy-Vorbehalten, aber vermutlich wollen manche Projekte die Wahrheit gar nicht so genau wissen. Irgendjemand wird sicher in den Kommentaren sinngemäß schreiben, dass das in seinem Umfeld natürlich ganz anders sei. Aber Binnenwahrnehmungen haben selten etwas mit den realen Verhältnissen zu tun. Die AfD skandiert ja auch bei 10 % noch Wir sind das Volk, weil ihre Anhänger in ihren Blasen die Mehrheit stellen.

Einen genaueren Blick auf die Community zu nehmen ist aber sinnvoll, um interne Diskussionsprozesse besser gewichten zu können und manche Entwicklungen zu verstehen. Simplifiziert geht es um die Frage: Warum ist Ubuntu mit GNOME (und demnächst Snaps) so erfolgreich, wenn die Mehrheit der Kommentatoren in Foren und Blogs diese Konstruktion ablehnt.

Das Thema Mehrheiten, Minderheiten und die Abläufe von Diskussionsprozessen interessiert mich schon länger, weil in meiner Wahrnehmung Teile der Community das Potenzial haben, in etwas abzurutschen, was momentan gerne als „toxisches Umfeld“ beschrieben wird.

Das wiederum halte ich für fatal, weil es eine kritische Größe gibt, ab der eine Community in die Bedeutungslosigkeit abrutscht (oder dieser nie entwächst) und dann immer weniger Berücksichtigung durch Dritte gibt. BSD wäre hier ein Beispiel. Linux ist als Baustein für den Schutz der Privatsphäre oder des Datenschutzes im individuellen IT-Bereich für die „digitale Selbstverteidigung“ zu wichtig, um diese Tendenzen bedeutungslos zu finden.

Gruppe 1: Linux im Mainstream

Die erste große Gruppe sind die Masse der Anwender von Linux als Desktopsystem. Dazu hatte ich mich hier schon mal geäußert. Die Masse der Linux-Anwender verteilt sich auf ein paar wenige Distributionen und nutzt primär Software einer Handvoll Projekte.

Die große Mehrheit der Linux-Anwender nutzt Ubuntu, eines der offiziellen Derivate (Kubuntu, Xubuntu, Lubuntu usw.) oder einen der inoffiziellen Abkömmlinge (Linux Mint, elementary OS, Pop!_OS usw.). Es gibt dazu keine belastbaren Zahlen, aber Hinweise. Dazu gehören die von Canonical publizierten 25 Millionen aber auch die Größe der Communitys, die Rezeption in den Medien und die Unterstützung durch Anbieter proprietärer Programme. Ergänzend kann man sich die Ergebnisse der Steam Hardware Survey ansehen, die man aber nicht überbewerten darf, weil Gaming nur ein Segment des Linux-Desktops ist und aktuelle Treiber hier eine überproportional große Rolle spielen. Insgesamt ergibt sich ein ziemlich stimmiges Bild.

Über die internen Verteilungen möchte ich nicht ausführlich mutmaßen, aber durchaus denkbar, dass Linux Mint hier bereits vor der Stammdistribution Ubuntu liegt. Da die meisten der offiziellen und inoffiziellen Derivate direkt auf die Ubuntu LTS aufsetzen, kann man konstatieren, dass die große Mehrheit der Anwender eine LTS-Distribution nutzt. Entsprechend sind viele (proprietäre) Drittanbieter-Programme vor allem für Ubuntu LTS getestet.

Den Desktopzahlen bin ich bereits mal auf den Grund gegangen. Es gibt viel Auswahl, aber letztlich nutzt eine große Gruppe GNOME, direkt gefolgt von KDE Plasma. Danach kommen dann die kleineren Desktopumgebungen mit Marktanteilen im einstelligen oder niedrigen zweistelligen Bereich.

Installationen von Programmen nehmen diese Anwendergruppen über die von der Distribution vorgegebenen Wege vor. Das bedeutet grafische Oberflächen für Paketinstallationen und App Stores. Auf der Kommandozeile werden lediglich Dreizeiler aus dem Internet per C&P eingefügt, um ggf. PPAs für neuere Versionen einzufügen. Ob das Programm als DEB, Snap, Flatpak oder AppImage kommt, ist dieser Anwendergruppe egal – so lange es funktioniert.

Diese Community-Gruppe sollte man nicht als DAUs abstempeln oder als anspruchslose Nutzer. Mir fallen spontan gleich einige Entwickler und Systemadministratoren ein, deren Arbeitsgeräte ziemlich langweilige Ubuntu 20.04 Systeme ohne größere Anpassungen sind. Man arbeitet schließlich mit dem System und nicht am System.

Diese Gruppe ist zudem extrem wichtig, weil sie die Masse der Anwender stellt und verhindert, dass Linux am Desktop auf das Bedeutungsniveau von BSD absackt. Dank dieser Gruppe gibt es für Linux inzwischen selbstverständlich Clientprogramme für wichtige Dienste wie Zoom oder Teams. Das sah vor 15 Jahren noch ganz anders aus und ist eine Folge der Popularität von Ubuntu und der damit einhergehenden Standardisierung dessen, was gemeinhin als „Linux-Desktop“ begriffen wird.

Die Gruppe nimmt aber naturgemäß kaum Teil an irgendwelchen Diskussionen zur Weiterentwicklung von Linux. Normale macOS-Nutzer kommentieren schließlich auch nicht die Apple-Entwicklungen in irgendwelchen Foren. Die Gruppe fällt eher als träge Masse auf, die bei langanhaltenden Fehlentwicklungen oder durch gruppendynamische Prozesse von Distribution A zu Distribution B wandert. Diese Gruppe ist aber ziemlich tolerant gegenüber neuen Entwicklungen. Das kann man z. B. am Prozess GNOME 2 zu Unity zu GNOME Shell bei Ubuntu sehen, die meistens ausweislich der Zahlen einfach mit vollzogen wurde.

Gruppe 2: Lautstarke Minderheiten

Weit abgeschlagen hinter der „Ubuntu-Familie“ kommen andere Distributionen. Hier haben wir aber noch viel weniger Zahlen. Für openSUSE Tumbleweed wurden 2016 mal 60.000 aktive Installationen bekannt gegeben, vermutlich sind das inzwischen ein paar mehr, aber es wird hier keine Millionen-Sprünge gegeben haben. Ich mag openSUSE, aber so viel Ehrlichkeit und Reflexionsvermögen sollte man als Kommentator haben. Fedora hat zwar 2019 Anstalten unternommen seine Benutzer zu zählen, aber Ergebnisse gibt es bisher nicht, die Verbreitung kann ich schwer schätzen, weil es hier erhebliche regionale Unterschiede zwischen Europa und den USA geben kann. Debian mag für das Gesamt-Ökosystem eine tragende Rolle spielen und im Server-Segment wichtig sein, Desktop-Installationen machen nach den Popcon-Zahlen nur eine Minderheit aus. Bei den Nicht-stabilen Distributionen spielt bestenfalls Manjaro und Arch eine nennenswerte Rolle, wie man auch der Steam Survey entnehmen kann.

Natürlich kann man nicht alle Distributionen über einen Kamm scheren, aber gemessen an der „Ubuntu-Familie“ haben sie alle eher kleine Benutzerzahlen. Man kann nämlich getrost bezweifeln, dass diese Distributionen auf die Millionen-Basis kommen, die Ubuntu für sich veranschlagt. Ansonsten würden beispielsweise die wenigen Mirror-Server andauernd in die Knie gehen. Alles andere läuft sowieso unter „ferner liefen“.

Viele Anwender dieser Distributionen benutzen diese mit GNOME oder KDE Plasma und damit einem ähnlichen Aufbau, wie dem „Ubuntu-Mainstream“. Man kann also auch mit den oben genannten Distributionen faktisch zu Gruppe 1 gehören. Allerdings gehen exotische Distributionen eben oft mit exotischen Desktopumgebungen und exotischen Gesamt-Setups einher. Anwender schwören hier oft auf die Anpassbarkeit von Xfce, MATE oder irgendwelchen Openbox-Konstruktionen. Gerne auf demonstrativ veralteter Hardware, um die Genügsamkeit von Linux unter Beweis zu stellen und unter Verweigerung moderner „Trends“ wie Cloud oder Smartphone.

Hier bildet sich dann der Kern dessen, was ich als Gruppe 2 betrachte. Diese Gruppe hat sich mit dem System Linux wie es aktuell ist, sehr gut eingerichtet und benötigt keine Veränderung. Sie sieht keine Probleme und hat deshalb keinen Bedarf an wirklicher Entwicklung jenseits kosmetischer Pflege. Teile der Gruppe bekämpfen jedwede Veränderung geradezu aggressiv, weil sie es als Angriff auf ihr liebgewonnenes System wahrnehmen.

Das liegt auch daran, dass die Gruppe glaubt die Wahrheit gepachtet zu haben. Sie verwendet deshalb zur Begründung ihrer Positionen gerne die „Unix-Philosophie“ oder das „KISS-Prinzip“, um missliebige Entwicklungen zu diskreditieren.

In den Foren und Kommentarspalten machen diese Anwender aber einen überproportional großen Anteil aus. Auch in den Communitys der oben genannten Distributionen. Zum Problem wird das, wenn subjektive Äußerungen sich nicht mehr in Deckung mit Fakten bringen lassen. Stabile LTS-Distributionen verteufeln diese „Supporter“ bei jeder Gelegenheit (Beispiel hier) oder Snaps und Flatpaks werden mit Argumenten an der Schwelle von Unkenntnis zu Fake News bekämpft (Beispiele in den Kommentaren hier). Die überproportionale Präsenz in Foren und Kommentarspalten verleitet Gruppe 2 oft dazu zu glauben, sie wären „die Community“ oder von besonderer Relevanz für die Community.

Gruppe 3: Dort wo wie Entwicklung passiert (Red Hat)

Gruppe 2 hält sich zwar für sehr wichtig (sieht man daran, dass in den verlinkten Kommentaren von „Akzeptanz in der Community“ die Rede ist, wo eher die eigene Blase gemeint wird) ist es aber eigentlich nicht. Das wird wieder einige furchtbar aufregen, aber wer hier kommentiert, soll bitte gleich die letzte Innovation listen, die diese Gruppe hervorgebracht hat. Die Wünsche von exotischen Nutzern mit hochgradig individuell konfigurierten Linux-Setups sind einfach zu irrelevant im Hinblick auf die Marktanteile.

Die Entwicklung passiert bei Red Hat und hier vor allem im Testballon Fedora. Eine Zusammenfassung konnte man jüngst hier lesen. Ein wenig steuern noch SUSE und Canonical bei. Konkrete Projekte als Beispiele wären der usr-merge samt daraus hervorgehenden Möglichkeiten, alles rund um systemd, Pulseaudio, Pipewire, Desktop-Entwicklung im GNOME-Umfeld, Gedanken über Distributionen der Zukunft, Flatpaks und schließlich noch kpatch, um eine für Server relevante Funktion zu nennen. Diese Liste ließe sich endlos fortsetzen.

Diese Gruppe wird zwar regelmäßig von Gruppe 2 angepöbelt (kann man bei jedem Aufschlag von Lennart Poettering erleben) aber arbeitet trotzdem weiter an Linux. Ab einer gewissen Reife landen diese Entwicklungsergebnisse über Ubuntu dann bei der Masse der Anwender. Gruppe 2 zieht irgendwann mal nach oder nicht, kann man dann in internen Abstimmungsprozessen bei z. B. Debian nachverfolgen.

Zusammengefasst

Wichtig ist, was Gruppe 3 macht und wie Gruppe 1 darauf reagiert. Die zweite Gruppe führt zwar ihre lautstarken Binnendiskurse, geriert sich als Semi-Profis, wird aber von allen ernst zu nehmenden Entwicklern inzwischen ganz offenkundig ignoriert.

Noch arbeiten alle Gruppen letztlich mit dem gleichen Linux-System, aber je schneller die Entwicklung voranschreitet und je mehr sich Gruppe 2 dem verweigert, desto eher kann hier eine wirkliche Spaltung eintreten. Die Frage, ob die Lieblingsprojekte von Gruppe 2 den Sprung auf aktuelle Technologien wie Wayland schaffen, ist noch nicht beantwortet. Die sukzessive Verbreitung von Flatpaks oder Snaps bei Mainstream-Distributionen und Drittanbieter-Software wird hartnäckige Verweigerer zudem weiter isolieren.

Die Frage ist allerdings, wie sehr Gruppe 2 mit ihrer Ablehnung, undifferenzierter Ablehnung und partiellem Hass die Community so sehr vergiftet, das Linux insgesamt Schaden nimmt. Öffentliche Diskussionsprozesse über Veränderungen sind gegenwärtig bereits fast unmöglich, weil Akteure von Gruppe 2 jede konstruktive Diskussion sabotieren.

In diesem Sinne sollte jeder mal darüber nachdenken, wo er sich positioniert, welcher Gruppe er sich zuordnet, mit welchen Argumenten er sich beschäftigt und ob er vielleicht Nischenmeinungen reproduziert.

Der Artikel Spannungsfelder in der Linux Community erschien zuerst auf [Mer]Curius

Ich habe mir im April 2020 einen Dell G7 17 – 7700 zugelegt. Nach nunmehr einem halben Jahr möchte ich hier meine Erfahrungen mit diesem Laptop darstellen.

Anforderungen

Als Erstes möchte ich kurz auf meine Anforderungen eingehen. Diese waren:

• Linux-Kompatibilität. Das Ding soll einfach laufen. Ich habe wenig Lust bei der Installation viel rum zu friemeln. Ich will Ubuntu installieren und gut.
• Brauchbare Akkulaufzeit. Mir ist wichtig, wenn ich mal auf Reisen bin, auch im Zug ein paar Stunden arbeiten zu können. Ich brauche keinen Laptop, der einen ganzen Arbeitstag ohne Stromanschluss durchhält. Die meiste Zeit residiert mein Laptop eh auf meinem Schreibtisch.
• Eine gute Tastatur. Wenn man schon mal mit dem Laptop direkt auf dem Schoß arbeiten muss arbeitet, dann soll die Tastatur auch angenehm zu schreiben sein. Ich persönlich mag Tastaturen mit kurzem Hub.
• Ordentlich Speicher. Da ich beruflich viel mit React und Webpack arbeite, und dabei viele Browser Fenster offen habe, benötige ich einiges an Arbeitsspeicher. 16 GB sind eigentlich das absolute Minimum, besser sind wahrscheinlich 32 GB.
• Große Festplatte. Ähnliches gilt für die Festplatte, am Ende sollte es wahrscheinlich ein Terabyte sein, damit man mit virtuellen Maschinen und ein paar Videos nicht gleich den ganzen Platz verbraucht.
• 17 Zoll Display. Ich persönlich mag 17 Zoll (ca. 43 cm) Laptops. Sie ersetzen auf dem Schreibtisch einen zweiten Monitor und wenn man sie auch mal auf dem Schoß hat, machen sie einem Nacken und Schultern nicht so sehr kaputt, wie kleinere Modelle.
• Ordentliche Verarbeitung. Eine gewisse Wertigkeit sollte der Laptop schon haben. Ich brauche kein Modell aus Vollaluminium, aber wie eine Brotdose auf dem Schulhof sollte er auch nicht so wirken.

Mit dem oben genannten Anforderungen bin ich dann erst mal auf die Suche gegangen. Die vielen günstigen Geräte, die es in der 17 Zoll Klasse gibt, schieden schon einmal aus, da Tastatur und Gehäuse meistens eine unterirdische Qualität haben.

Leider waren auch die Geräte von auf Linux spezialisierten Anbietern nichts für mich. Deren 17 Zoll Laptops sind meistens White-Label Spiele-Laptops, die sehr schwer, sehr dick, sehr teuer sind und recht billig aussehen.

Um eines klarzustellen: Ich bin großer Fan von auf Linux spezialisierten Anbietern. Einen Desktop-PC würde ich jederzeit von solch einem Anbieter kaufen. Leider bestehen Laptops nicht wie Desktop-PCs aus Standard Bauteilen, und deswegen, ist es für Nischen-Anbieter sehr schwierig eigene Laptops zu entwickeln.

Nach einiger Recherche kam ich zu der Überlegung, einen Spiele-Laptop zu kaufen, der nicht auf absolut maximale Leistung ausgelegt ist, sondern eher für Gelegenheitsspieler gedacht ist. Spiele-Laptops haben in der Regel ordentliche Hardware verbaut und besitzen eine brauchbare Tastatur, weil Spieler ja dauernd in die Tasten hacken müssen.

Ich habe mich dann für den Dell G7 17 – 7700 entschieden, weil er eine etwas erhöhtes Display hat, von dem ich mir beim Arbeiten auf dem Schoß einen kleinen Ergonomie-Vorteil versprach.

Technische Daten

Prozessor	Intel Core i7-10750H 6 x 2.6 – 5 GHz (Intel Comet Lake)
Grafikkarte	NVIDIA GeForce RTX 2060 Mobile – 6144 MB, GDDR6
Arbeitsspeicher	16384 MB, DDR4-2933
Display	17.30 Zoll 16:9, 1920 x 1080 Pixel 127 PPI, 9ms, entspiegelt, 144 Hz
Massenspeicher	1TB SSD
Anschlüsse	3 USB 3.0 / 3.1 Gen1, 1 Thunderbolt, 1 HDMI, 1 DisplayPort, Audio Anschlüsse: 3.5mm, Card Reader: SD
Netzwerk	Killer E2500 Gigabit Ethernet Controller (10/100/1000/2500/5000MBit/s), 802.11 a/b/g/n/ac/ax (a/b/g/n = Wi-Fi 4/ac = Wi-Fi 5/ax = Wi-Fi 6), Bluetooth 5.0
Abmessungen	Höhe x Breite x Tiefe (in mm): 20.7 x 398 x 290
Akku	97 Wh Lithium-Ion, 6-cell
Kamera	Webcam: HD 720p
Sonstiges	Lautsprecher: Stereo, Tastatur: Chiclet, Tastatur-Beleuchtung: ja
Gewicht	3.29 kg

Installation

Nach ca. 7 Tagen war der Laptop bei mir zu Hause angekommen. Als Erstes habe ich dann mit einem Live-Stick die Ubuntu-Tauglichkeit getestet. Nach ein paar Minuten ohne Probleme, bin ich dann zur Installation übergegangen. Ich habe Windows runtergeschmissen und Ubuntu 20.04 installiert.

Ich habe die Voreinstellungen des Ubuntu-Installers einfach übernommen. Brav wie ich bin, habe ich auch die Festplattenverschlüsselung angestellt.

Nach kurzer Zeit war die Installation fix und fertig. Der G7 und war somit einsatzbereit und konnte auch schon gut verwendet werden.

Am BIOS habe ich übrigens nichts geändert, sondern die Werkseinstellungen gelassen wie sie sind.

Nacharbeiten

Wo viel Licht ist, da ist auch Schatten. Zwar konnte man mit dem G7 nach der Ubuntu-Installation direkt loslegen und arbeiten. Aber nichtsdestotrotz gab es ein paar Kleinigkeiten, die es zu optimieren galt.

Der vom Ubuntu-Installer standardmäßig installierte Nvidia-Treiber funktionierte mit meinem Multi-Monitor Setup nicht. Ich habe meinem Arbeitsplatz neben dem Laptop Monitor noch zwei weitere Monitore die ich einmal per USB und einmal per HDMI anspreche. Mit dem proprietären Nvidia-Treiber hat es schlicht nicht funktioniert, mehr als einen Monitor anzusprechen.

Da Spielen für mich keine Priorität hat, habe ich mich nach anderen Lösungen umgeschaut. Meine erste Idee war es auf den quelloffenen Nouveau-Treiber zu setzen. Und zu meinem Glück funktionierte diese auch direkt. Sein Vorteil ist, dass er sich wesentlich besser in die Ubuntu-/Gnome-Settings einfügt.

Die schlechtere Performance bei grafiklastigen Anwendungen spielt für mich keine große Rolle

Neben den Problemen mit der Grafikkarte hakte nur der Fingerprint-Reader. Um den habe ich mich aber nicht weiter gekümmert.

Bildschirm

Der Full HD Bildschirm ist sehr hell und man kann damit problemlos auch in der Sonne arbeiten. Die maximale Auflösung liegt bei 1920 x 1080.

Batterielaufzeit

Mit der Batterielaufzeit bin ich durchaus zufrieden. Für eine Bahnreise reicht es allemal. Ich muss meinen Laptop nicht den ganzen Tag nutzen können, ohne ihn laden. 5 bis 6 Stunden sind bei normaler Benutzung allemal drin.

Tastatur & Touchpad

Tastatur und Touchpad sind die heimlichen Highlights des G7. Der Tastenhub ist sehr gering, was ich persönlich mag, und funktioniert butterweich.

Das große Touchpad ist aus Glas und lässt sich sehr angenehm nutzen. Anders als bei billigen Laptops gleitet man sehr leicht über die Oberfläche. Die Multitouch Unterstützung mit Ubuntu ist zumindest für meine ansprechen Ansprüche ausreichen.

Fazit

Abschließend muss ich sagen, dass ich mit dem G7 sehr zufrieden bin. Es war für mich ein echter Glücksgriff. Das Gerät ist leistungsfähig genug, sieht gut aus und hat eine sehr gute Ergonomie.

Firewalls sind entgegen der landläufigen Meinung auch für Linux sinnvoll. Die meisten Distributionen setzen entweder auf Firewalld oder ufw. Auf Letzteres soll hier ein wenig eingegangen werden.

ufw als Kürzel für uncomplicated firewall ist ein relativ leicht zu konfigurierendes Frontend für iptables. Während Firewalld vor allem bei Red Hat, Fedora und openSUSE verbreitet ist, setzen Ubuntu und die offiziellen und inoffiziellen Derivate meist auf ufw. Beide Lösungen erfüllen ihren Zweck und reichen für Privatanwender aus.

Wichtig ist überhaupt eine Firewall zu nutzen. Die meisten Linux-Nutzer glauben immer noch dem alten Mythos, sie bräuchten keine Firewall, doch das war einmal. Linux-Desktopinstallationen sind nicht mehr minimalistisch und bewegen sich auch nicht mehr nur innerhalb des Heimnetzes.

Eine Firewall kann dann Sinn machen, wenn man ein mobiles Gerät besitzt und sich in fremde Netze einwählt. Nennt sich Notebook und dürfte bei den meisten Anwendern der Standardfall sein. Man verweist immer gerne auf Windows mit seinen vermeintlich vielen offenen Ports und Diensten, die man nicht braucht, aber auch bei Linux laufen viele Dienste, die außerhalb des Heimnetzes nicht gebraucht werden: CUPS, Avahi, KDE Connect, ggf. ein Samba-Share. Die Liste ließe sich sicher noch erweitern. Das ist jetzt grundsätzlich kein Problem, aber es schadet auch nicht, diese Ports bei unbekannten Netzwerken zu blockieren. Wer weiß schon, welche Sicherheitslücke demnächst in CUPS oder sshfs gefunden wird.

Den aktuellen Status von ufw kann man mit folgender Abfrage prüfen:

$ sudo ufw status

Die Ausgabe ist dann je nach Zustand Status: Inaktiv oder Status: Aktiv.

Mit folgendem Befehlen aktiviert bzw. deaktiviert man ufw.

$ sudo ufw enable
$ sudo ufw disable

ufw kennt drei Modi für Verbindungen: allow, deny reject. Der Unterschied zwischen letzteren beiden besteht darin, dass bei reject der Absender des Netzwerkpakets eine Nachricht über die Ablehnung bekommt. Der Vollständigkeit halber sei darauf hingewiesen, dass eine solche Reaktion manche Experten aus Sicherheitsgründen für nicht klug halten.

Normalerweise ist die Standardkonfiguration von ufw wenn weitere Einstellungen fehlen, eingehende Verbindungen zu blockieren und ausgehende Verbindungen zu erlauben. Die aktuelle Konfiguration kann mit dem verbose Befehl abgefragt werden. Die Ausgabe sollte wie folgt aussehen:

$ sudo ufw status verbose
Status: Aktiv
Protokollierung: on (low)
Voreinstellung: deny (eingehend), allow (abgehend), disabled (gesendet)
Neue Profile: skip

Sollten eingehende Verbindungen nicht per default blockiert werden kann dies mit folgendem Befehl nachgeholt werden:

$ sudo ufw default deny

Mit einem anschließenden Reload von ufw werden die Regeln aktiviert:

$ sudo ufw reload

Eine Konfiguration kann auf Basis von Services oder Application-Profilen erfolgen. Zusätzlich kann man einzelne Ports konfigurieren. Ein Service wie z. B. SSH lässt sich mit folgendem Befehl freigeben:

$ sudo ufw allow ssh

Besonders praktisch sind die mitgelieferten Profile. Diese werden direkt bei der Installation von Programmen mitgeliefert. Verfügbare Profile lassen sich mit folgendem Befehl finden:

$ sudo ufw app list

Normalerweise sollte mindestens ein Profil für CUPS vorhanden sein. Den Inhalt eines solchen Profils kann man sich ebenfalls anschauen:

$ sudo ufw app info CUPS
Profil: CUPS
Titel: Common UNIX Printing System server
Beschreibung: CUPS is a printing system with support for IPP, samba, lpd,
and other protocols.

Port:
  631

Anders als Firewalld kennt ufw keine Zonen, weshalb sich Verbindungen auch nicht klassifizieren und diese Klassifizierungen unterschiedlichen Netzwerken zugewiesen werden können. Das erleichtert zwar die Konfiguration, erlaubt aber nicht die Differenzierung zwischen privaten (vertrauenswürdigen) Netzwerken und öffentlichen Netzen.

Der Mehrwert von ufw für private Nutzer ist deshalb überschaubar. Bei einem ordentlich gepflegten Linux gibt es keine unnötigen offenen Ports. Wohl aber offene Ports, die man nicht in jedem Netzwerk benötigt. Firewalld bietet hier die Möglichkeit mit Zonen automatisiert zu differenzieren, ufw kennt nur zulässige Dienste oder Apps – egal in welchem Netz.

Der Artikel Firewall ufw für Linux konfigurieren erschien zuerst auf [Mer]Curius

Die MZLA Technologies Corporation hat mit Thunderbird 91.1.2 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.1.2

Mit Thunderbird 91.1.2 hat die MZLA Technologies Corporation ein weiteres Update außer der Reihe veröffentlicht, welches diverse Korrekturen für die Versionsreihe 91 beinhaltet. Eine Übersicht über die in Thunderbird 91.1.2 behobenen Fehler gibt es in den Release Notes (engl.).

Der Beitrag Thunderbird 91.1.2 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Ein kurzer Tipp fürs Interface Monitoring mit Icinga oder Nagios unter Debian.

Nach einem Update auf Debian Bullseye kann es vorkommen, dass einige Check Plugins fehlschlagen. So geschehen mit check_interfaces.

Das Plugin bringt nur noch folgende Ausgabe:

Plugin-Ausgabe
/usr/lib/nagios/plugins/check_interfaces: error while loading shared libraries: libnetsnmp.so.30: cannot open shared object file: No such file or directory

Zunächst kann man natürlich versuchen, die nötigen Dateien auf anderen Systemen zu suchen oder das Paket libsnmp40 zu installieren, leider bringt dies unnötige Arbeit, bzw. keine Abhilfe.

Die Lösung ist ein einfaches neu builden des Plugins:

apt-get update
apt-get -y install git build-essential libsnmp-dev

wget https://github.com/NETWAYS/check_interfaces/archive/refs/tags/v1.4.tar.gz

tar xvf v1.4.tar.gz

cd check_interfaces-1.4/

./configure --libexecdir=/usr/lib/nagios/plugins

make
make install

Der Zielpfad kann natürlich je nach Check Plugin Verzeichnis angepasst werden. Nach dem erneuten Builden unter Debian Bullseye sollte das Plugin wieder ohne Probleme funktionieren.

Kali Linux 2021.3

Neues Quartal neues Kali Linux.

TLS 1.x

Mit Version 2021.3 wurden unter anderem alte Brötchen wieder aufgewärmt. So ist TLS 1.0 und TLS 1.1 unter OpenSSL wieder aktiv. Hintergrund sind mögliche Tests mit alten Systemen, welche noch mit den alten Standards laufen. Mit dem Befehl kali-tweaks lassen sich die Einstellungen allerdings jederzeit anpassen.

Virtuelle Maschinen

Virtuelle Maschinen haben eine bessere Unterstützung erhalten. So sollte nun ein Copy & Paste zwischen Host und virtuellem Zielsystem funktionieren. Unter Windows wurde mit dem Hyper-V Enhanced Session Mode die Möglichkeit für USB Sticks als lokale Ressource geschaffen.

Auch diese Funktion lässt sich über den Befehl kali-tweaks einrichten.

Smartwatches und Android 11 ohne TWRP

Neben der ersten Smartwatch TicHunter-Pro können Android 11 Smartphones nun via Magisk bespielt werden. Bisher war dies nur über das TWRP möglich. Das Projekt befindet sich allerdings noch am Anfang und ist mit Vorsicht zu genießen.

ARM

Kali für ARM hat neue Build Scripts erhalten, diese unterstützen nun auch RaspberryPi Zero.

Die aktualisierten Scripts erstellen ein neues Snakeoil Zertifikat. Als neue Standard Shell wird ZSH integriert. Dies lässt sich über das bereits bekannte kali-tweaks anpassen. Ebenfalls werden kalipi-config und kalipi-tft-config vorinstalliert.

Pinebook Freunde dürfen sich außerdem über einen neuen Kernel und einen hübscheren Bootscreen freuen.

Doku ist alles

Die neue Kali Tools Seite soll nicht unerwähnt bleiben. Sie bietet eine moderne und praktische Übersicht aller vorhandener Software.

BlackArch hat so eine Übersicht schon etwas länger und in der Vergangenheit ebenfalls ein neues Release veröffentlicht.

---

BlackArch 2021.09

Nachdem Kali Linux vorgelegt hatte, zieht BlackArch mit einer neuen Version nach.

Das auf Arch Linux basierende System bringt nach eigener Aussage nun 2700 Tools mit.

Welche Werkzeuge euch genau zur Verfügung stehen, könnt ihr dieser Tool-Liste entnehmen.

BlackArch 2021.09 läuft mit dem Kernel 5.13.10. Neben einem neuen Textinstaller gab es die üblichen Updates.

---

---

Übersicht 09/2021

 

Name	Version	Tools	Besonderes	Basis	GUI
Autopsy	4.18	???	The Sleuth Kit	Windows
BackBox	7.0	100+	AWS	Ubuntu	Xfce
BlackArch	2021.09	1750+	ArchLinux	ArchLinux	Multi
CAINE	11	100+	WinUFO	Ubuntu	Mate
DracOS	3.0		veraltet	LFS	DWM
DEFT Zero	2018.2		offline	Lubuntu 14.04	Lxde
Kali Linux	2021.03	300+	Plattformen	Debian Testing	Multi
Kali AppStore		40+		Android
LionSec	5.0		veraltet	Ubuntu
Matriux	v3 RC1		offline	Debian	Gnome
NST	34	???	Server integriert	Fedora
NetSecL OS	6.0		veraltet	OpenSuse	Lxde
Paladin	7.0			Ubuntu
Parrot OS	4.11.2	700+	Cloud fähig	Debian Buster	MATE/KDE
Pentoo	2018.0 RC7.1		veraltet	Gentoo	Xfce
Ronin			veraltet	Lubuntu	Lxde
Sans SIFT	3.0		veraltet	Ubuntu

Beim Durchwühlen des Internets bin ich auf eine Perle gestoßen, die ich hier festhalten möchte. In „Bash Script to Parse and Analyze Nginx Access Logs“ stellt Ruan Bekker ein kurzes Bash-Skript vor, welches die NGINX Access Logs analysiert, um einen Bericht mit folgenden Sektionen auszugeben:

• Top 10 Request IPs (aus dem aktuellen Access Log)
• Top Request Methods (aus dem aktuellen Access Log)
• Top 10 Request Pages (aus dem aktuellen Access Log)
• Top 10 Request Pages (aus dem aktuellen und Gzipten Logs)
• Top 10 HTTP 404 Page Responses (aus dem aktuellen und Gzipten Logs)

Ich selbst nutze aktuell den Fork von Marc Brunet, welchen ich meinen My-IT-Scripts hinzugefügt habe:

#!/bin/bash

# URL: https://github.com/Tronde/My-IT-Scripts/blob/master/bash/analyze_nginx_access_logs.sh

# variables
LOGFILE="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log"
LOGFILE_GZ="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log.*"
RESPONSE_CODE="200"

# functions
filters(){
grep -w $RESPONSE_CODE \
| grep -v "\/rss\/" \
| grep -v robots.txt \
| grep -v "\.css" \
| grep -v "\.jss*" \
| grep -v "\.png" \
| grep -v "\.ico"
}

filters_404(){
grep -w "404"
}

request_ips(){
awk '{print $1}'
}

request_method(){
awk '{print $6}' \
| cut -d'"' -f2
}

request_pages(){
awk '{print $7}'
}

wordcount(){
sort \
| uniq -c
}

sort_desc(){
sort -rn
}

return_kv(){
awk '{print $1, $2}'
}

request_pages(){
awk '{print $7}'
}

return_top_ten(){
head -10
}

## actions
get_request_ips(){
echo ""
echo "Top 10 Request IP's:"
echo "===================="

cat $LOGFILE \
| filters \
| request_ips \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

get_request_methods(){
echo "Top Request Methods:"
echo "===================="
cat $LOGFILE \
| filters \
| request_method \
| wordcount \
| return_kv
echo ""
}

get_request_pages_404(){
echo "Top 10: 404 Page Responses:"
echo "==========================="
zgrep '-' $LOGFILE $LOGFILE_GZ\
| filters_404 \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}


get_request_pages(){
echo "Top 10 Request Pages:"
echo "====================="
cat $LOGFILE \
| filters \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

get_request_pages_all(){
echo "Top 10 Request Pages from All Logs:"
echo "==================================="
zgrep '-' --no-filename $LOGFILE $LOGFILE_GZ \
| filters \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

# executing
get_request_ips
get_request_methods
get_request_pages
get_request_pages_all
get_request_pages_404

Selbstverständlich erhalte ich damit keine genauen Statistiken, da meine Logs nach einem Monat automatisch gelöscht werden. Für einen kurzen Rückblick und der Erstellung eines monatlichen Berichts scheint das kleine Skript jedoch gut geeignet zu sein. Ich probiere es gerade aus, um zu sehen, wie gut es mir auf Dauer gefällt.

Auf Basis des ersten Skripts habe ich ein zweites geschrieben, mit dessen Hilfe ich die Requests für einen spezifischen Beitrag abfragen kann (Quelle):

#!/bin/bash

# variables
LOGFILE="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log"
LOGFILE_GZ="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log.*"
RESPONSE_CODE="200"
ARG1=$1

# functions
filters(){
grep -w $RESPONSE_CODE \
| grep -v "\/rss\/" \
| grep -v robots.txt \
| grep -v "\.css" \
| grep -v "\.jss*" \
| grep -v "\.png" \
| grep -v "\.ico"
}

request_ips(){
awk '{print $1}'
}

request_page(){
awk '{print $7}' \
| grep -w $ARG1
}

wordcount(){
sort \
| uniq -c
}

return_kv(){
awk '{print $1, $2}'
}

get_request_page(){
echo "Page requests in current log:"
echo "====================="
cat $LOGFILE \
| filters \
| request_page \
| wordcount \
| return_kv
echo ""
}

get_request_page_all(){
echo "Page requests in all logs (last month):"
echo "==================================="
zgrep '-' --no-filename $LOGFILE $LOGFILE_GZ \
| filters \
| request_page \
| wordcount \
| return_kv
echo ""
}

# execute
get_request_page
get_request_page_all

Der folgende Code-Block zeigt ein Beispiel, wie das Skript angewendet wird. Dabei wird der Permalink als Argument übergeben:

:~/bin$ sh get_page_requests_from_nginx_access_logs.sh kommentar-linux-container-spreu-und-weizen
Page requests in current log:
=====================
262 /wordpress/kommentar-linux-container-spreu-und-weizen/
6 /wordpress/kommentar-linux-container-spreu-und-weizen/feed/

Page requests in all logs (last month):
===================================
5124 /wordpress/kommentar-linux-container-spreu-und-weizen/
49 /wordpress/kommentar-linux-container-spreu-und-weizen/feed/
2 /wordpress/wp-json/oembed/1.0/embed?url=https://www.my-it-brain.de/wordpress/kommentar-linux-container-spreu-und-weizen/

Noch nicht schön, aber zweckmäßig.

Was haltet ihr davon? Falls ihr beim Drübergucken zufällig noch einen Fehler in den Skripten entdeckt, freue ich mich, wenn ihr mir einen Kommentar hinterlasst.

Christian Schaller hat in seinem Blog sich sehr ausführlich zur vergangenen und künftigen Entwicklung von Fedora Workstation (also der Desktop-Variante der Distribution) geäußert.

Den Artikel „Fedora Workstation: Our Vision for Linux Desktop“ möchte ich allen interessierten Linux-Nutzerns empfehlen. Neben einem Resümee der Ausgangssituation und getroffenen Entscheidungen kann man bereits einen Ausblick auf das werden, was konzeptionell angedacht wird. Besonders interessant ist die Schilderung, wie komplex die Entwicklung einer klassischen Distribution mit normaler Paketverwaltung ist und dass dieses Konzept eigentlich keine sinnvolle Variante für schnelle Entwicklungszyklen ist. Wenn es überhaupt eine langfristige Zukunft jenseits Status quo-orientierter Distributionen hat.

Die Zielrichtung von Fedora Workstation ist immer noch ein Szenario, das sich momentan in der Silverblue-Edition testen lässt. Das bedeutet eine gänzlich neue Art Linux-Distribution. Das Betriebssystem wird read-only eingebunden, Anwendungen primär über Flatpaks installiert und weiterführende Ansprüche werden mit Toolbox anvisiert. Dabei handelt es sich letztlich um Container mit Systemwerkzeugen.

Weitere Themen sind dann noch Wayland, Pipewire und LVFS. Ebenfalls sehr interessante Baustellen und für viele Community-Lieblinge wie MATE oder Xfce ein riesiges Problem, weil die Manpower für solche Entwicklungsleistungen eigentlich zu knapp ist.

An dem Artikel sieht man wieder sehr deutlich, wie wichtige Red Hat bzw. Fedora für Linux ist. Nahezu alle wichtigen Zukunftsthemen werden dort bearbeitet, viele wichtige Projekte gestartet und entwickelt. Diese sickern dann nach und nach in die anderen Distributionen.

Interessierte Anwender sollten sich außerdem Silverblue mal ansehen. Momentan halte ich Silverblue noch nicht für komplett alltagstauglich und die Fedora-Entwickler teilen diese Meinung scheinbar. Die Fortschritte sind aber immens und ich persönlich denke, dass diese Variante einer Linux-Distribution bereits in den nächsten Jahren das normale Desktop-Linux für Endanwender werden kann.

OpenSUSE experimentiert schließlich mit einem ähnlichen Konzept, das aber einen vollständig anderen technischen Ansatz hat und Ubuntu könnte Snaps weiter aufbohren und auf eine ähnliche Strategie schwenken. Sofern man an der Eigenentwicklung festhält und sich nicht letztlich doch wieder dem Linux-Mainstream beugt.

Der Artikel Lesetipp: Vision für Fedora Workstation erschien zuerst auf [Mer]Curius

Der systemd-Entwickler schreckt mal wieder die Linux-Gemeinde auf. Nicht ganz unerwartet befasst er sich mit der Ar,t wie die meisten Linux-Distributionen Daten verschlüsseln und Integrität gewährleisten. Ein notwendiger Weckruf für die oft bräsige Community.

Poettering befasst sich bereits seit längerem mit der Datensicherheit, LUKS und TPM. Der aktuelle Blogpost von ihm kommt daher nicht gänzlich unerwartet. Eine kurze Zusammenfassung und Bewertung kann man auch bei Golem lesen.

Einleitend befasst er sich mit dem aktuellen Status quo. Hier ist er sogar in vielen Fällen zu optimistisch, denn die Situation ist oft noch viel schlimmer.

Die meisten Distributionen verschlüsseln standardmäßig gar nicht und drängen diese Möglichkeit ihren Nutzern auch nur dezent auf. Linux ist hier schon länger deutlich unsicherer als die meisten anderen Betriebssysteme – abgesehen nur von der Windows-Home-Edition. Linux-Distributionen verschlüsseln Daten mittels einer LUKS/Cryptsetup-Lösung, die frühere verbreitete eCryptFS-Methode ist kaum noch verbreitet. Basale TPM-Unterstützung ist zwar vorhanden, wird aber kaum genutzt, obwohl (wegen entsprechender Microsoft-Vorgaben) alle halbwegs neuen Geräte einen TPM-Chip aufweisen.

Ein weiterer Baustein in der Validierungskette ist Secureboot. Hier ist Poettering wieder mal viel zu optimistisch, wenn er schreibt, dass die meisten Distributionen hierüber absichern. Insbesondere die vielen Kleinprojekte, aber auch so beliebte Distributionen wie Arch Linux oder Manjaro bieten kein Secureboot an bzw. zumindest nicht als Standard. Im besten Fall nutzt eine Distribution Secureboot und validiert via Shim Bootloader und Kernel. Eine lückenlose Valididerungskette inklusive Initrd und Betriebssystem erfolgt bei keiner Distribution. Dazu hatte ich mich hier auch schon mal geäußert. Das nicht verifizierte Initrd wird entpackt und fragt nach einem Passwort, um das LUKS-Volume zu entschlüsseln. Ab jetzt sind die Daten verfügbar. Der Benutzerlogin ist dann nur noch Kosmetik und wird von vielen LUKS-Nutzern bei Einzelnutzung auch per Autologin übersprungen.

Die aktuelle Vorgehensweise hat gleich mehrere offene Flanken. Vor allem schützt sie nicht, wenn die Festplatte physisch gestohlen oder komplett kopiert wird. Der Angreifer hat danach alle Zeit der Welt, um sich mit der Verschlüsselung und ihrer Umgehung zu beschäftigen. Ein weiteres Szenario ist die unbeobachtete Kompromittierung des Systems, genant Evil Maid Angriff.

Poettering kommt deshalb auch zu dem harten Schluss, dass alle anderen Betriebssysteme – ChromeOS, Android, Windows und macOS – die Daten der Anwender besser schützen.

Zur Abhilfe schlägt Poettering einige Punkte vor. Initrd müsste beim Start authentifiziert werden, ebenso das System unter /usr (was einen vollständigen usr-merge voraussetzt – Hallo Debian) und die Verschlüsselung des Benutzerverzeichnisses sollte an das Nutzerpasswort gebunden werden und nicht an das System. Besser wären noch Lösungen ohne Passwörter, wie beispielsweise FIDO2. Hier enteilt Microsoft Windows mit Hello Linux sowieso hoffnungslos.

Die Lösungsvorschläge basieren natürlich viel auf Entwicklungen in systemd (z. B. system-cryptenroll, systemd-home), aber auch auf Kryptofunktionen im Kernel wie dm-Verify und dm-Integrity. Ingesamt setzt Poettering auf eine viel stärkere Einbeziehung der sowieso verfügbaren TPM-Technik in die Sicherheitskonzepte der Distributionen. In diesem Zusammenhang wendet er sich auch massiv gegen nicht faktengestützte Vorurteile gegenüber TPM.

Diese Ideen sind natürlich weit entfernt davon, produktiv einsetzbar zu sein. Vermutlich werden sie am ehesten bei Fedora umgesetzt und dann sukzessive bei weiteren Distributionen.

Leider werden viele schon alleine deshalb dagegen arbeiten, weil die Ideen von Poettering kommen und systemd bei vielen nicht faktengestützte Vorurteile hervorrufen. Zudem haben viele Linux-Nutzer sich bequem in der Vergangenheit eingerichtet und leugnen die Herausforderungen der Gegenwart (von der Zukunft ganz zu schweigen).

Der Artikel Lennart Poettering hinterfragt Linux Verschlüsselung erschien zuerst auf [Mer]Curius

Mozilla hat mit Firefox 92.0.1 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht.

Download Mozilla Firefox 92.0.1

Mit dem Update auf Firefox 92.0.1 behebt Mozilla ein Problem, welches unter bestimmten Umständen verursachen konnte, dass die Suchleiste keinen Schließen-Button anzeigte. Außerdem wurde ein Problem behoben, welches für manche Linux-Nutzer verursachte, dass bei der Wiedergabe von Medien kein Ton zu hören war. Darüber hinaus wurde das Suchmaschinen-Logo von DuckDuckGo aktualisiert und diverse Anpassungen in Vorbereitung auf ein bevorstehendes Experiment für Nutzer in den USA wurden integriert.

Der Beitrag Mozilla veröffentlicht Firefox 92.0.1 erschien zuerst auf soeren-hentzschel.at.

Von Linux gibt es drölfzig Distributionen. Das wird gerne kritisiert, weil dadurch massiv Ressourcen gebunden werden. Befürworter verteidigen immer die Vielfalt als Stärke von Linux. Das gilt aber auch nur wenn man die Vielfalt auch wirklich zulässt und nutzt.

Aktuell gibt es nur Pseudo-Vielfalt unter den Distributionen, denn im Grunde genommen sind sie sich alle sehr ähnlich. Es gibt Distributionen mit rollenden Veröffentlichungsmodellen und stabile Distributionen mit festgelegten Releasezyklen und Supportzeiträumen. Bei Letzteren muss man noch die kleine Gruppe der Distributionen mit LTS/Enterprise-Support separieren.

Alle Distributionen funktionieren sehr ähnlich. Meistens bieten sie alle verfügbaren Desktopumgebungen an, die zunehmend lieblos integriert werden, weil die hohe Schlagzahl bei zurückgehenden Ressourcen keine liebevolle Integration mehr zulässt. Die allermeisten Distributionen verwenden systemd, udev, PolKit, eine X11/Wayland-Kombination, kompilieren mit GCC usw. usf.

Es gibt nur ein paar wenige exotische Distributionen mit Grundlagen, die sich deutlich von allen anderen unterscheiden. Spontan fallen mir da vielleicht Gentoo, Void, Slackware und vielleicht Devuan ein. Gemessen an der Gesamtzahl fallen diese kaum ins Gewicht.

Wo ist der Unterschied zwischen Linux Mint und Ubuntu oder zwischen Ubuntu und Debian? Wo ist der Unterschied zwischen Mageia und Fedora, zwischen openSUSE und Mageia? Wo trennt sich Manjaro von Arch Linux und was sind die Vorteile gegenüber openSUSE Tumbleweed? Man muss schon ganz weit heran zoomen, um hier noch die große Vielfalt zu erkennen, die angeblich der Vorteil von Linux ist.

Wenn also Distributionen wie Fedora mit Silverblue an der Distribution der Zukunft bauen, openSUSE mit MicroOS experimentiert, Ubuntu demnächst mehr Snaps ausrollen und elementary OS ein kuratiertes Flatpak-Ökosystem aufbauen, ist das eine Chance. Eine Chance auf wirkliche Vielfalt.

Es wird schließlich noch genug Distributionen geben, die andere Wege einschlagen. Die an konventionellen Veröffentlichungen festhalten, Flatpaks oder Snaps nicht standardmäßig verteilen oder sogar komplett aussperren.

Meiner Meinung nach könnte das noch viel weiter gehen. Anstatt 6 Desktops stiefmütterlich zu unterstützen, sollte man sich auch hier lieber auf einige wenige konzentrieren und hier auch guten Support bieten. So wie Fedora dies mit GNOME macht oder KDE neon mit Plasma. Andere Distributionen können hier ja andere Entscheidungen treffen.

Wenn nicht mehr alle Distributionen alles bieten, muss vielleicht der ein oder andere seine Distribution wechseln. Das Ökosystem gewinnt aber insgesamt hinzu. An wirklicher Vielfalt, an Wahlmöglichkeiten und an Qualität.

Momentan ist die vermeintliche Vielfalt nur ein Argument jener, die jede Kritik am Distributionsdschungel wegwischen wollen. Kaum entsteht wirkliche Vielfalt, wie bei Canonicals Entscheidung, künftig stärker auf Snaps zu setzen, kommt ein lautes Wehklagen, ob des vermeintlichen Verrats am Linux-Einheitsbrei und der Drohung, dass man dann selbst woanders hin abwandern möchte (gerne versteckt als „dann werden viele User gehen“).

Super, dann geht doch. Das ist überhaupt nicht negativ gemeint, denn genau dafür hat Linux doch die Vielfalt. Es muss nicht jede Distribution zu jedem Anwender oder Anwendungsfall passen. Gefällt einem eine Distribution nicht, sucht man sich eine andere. Vielfalt bedeutet nicht, hundert austauschbare Distributionen zu haben.

Der Artikel Kommentar: Viele Distributionen nutzen nur bei wirklicher Vielfalt etwas erschien zuerst auf [Mer]Curius

Bei Etherpad handelt es sich um einen Editor für kollaboratives Schreiben, welcher selbst gehostet werden kann. Soll Etherpad unter Ubuntu gehostet werden, muss im ersten Schritt Node.js installiert werden:

apt install -y libssl-dev
curl -sL https://deb.nodesource.com/setup_14.x | bash -
apt install -y nodejs

Anschließend wird ein Nutzer für Etherpad angelegt und in diesen gewechselt werden und dort der Quellcode für Etherpad heruntergeladen und initial einmal gestartet und dann mittels Strg + C wieder beendet:

adduser --disabled-login --gecos "" etherpad
su - etherpad
git clone --branch master https://github.com/ether/etherpad-lite.git
cd etherpad-lite
npm install sqlite3
src/bin/run.sh

Nun werden einige Konfigurationen vorgenommen. Im Groben werden die Datenbank, die Authentifikation, Vorbereitungen für den Reverse Proxy, die Nutzer und die maximale Länge von einzufügendem Inhalt und das Log konfiguriert:

nano etherpad-lite/settings.json

Die Änderungen sind in ihrer Reihenfolge in der Konfigurationsdatei angegeben:

...

"dbType": "sqlite",
"dbSettings": {
  "filename": "var/sqlite.db"
},

...

"requireAuthentication": true,

...

"trustProxy": true,

...

"users": {
"admin": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": true
},
"user": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": false
}
},

...

"socketIo": {
/*
 * Maximum permitted client message size (in bytes). All messages from
 * clients that are larger than this will be rejected. Large values make it
 * possible to paste large amounts of text, and plugins may require a larger
 * value to work properly, but increasing the value increases susceptibility
 * to denial of service attacks (malicious clients can exhaust memory).
 */
"maxHttpBufferSize": 1048576
},

...

"logconfig" :
{ "appenders": [
    { "type": "console"
    //, "category": "access"// only logs pad access
    }

  , { "type": "file"
  , "filename": "etherpad.log"
  , "maxLogSize": 1024000
  , "backups": 3 // how many log files there're gonna be at max
    }

...

Anschließend wird der Kontext des Nutzers etherpad verlassen und eine neue Service-Unit für systemd angelegt:

exit
nano /etc/systemd/system/etherpad.service

Diese wird mit folgendem Inhalt befüllt:

[Unit]
Description=Etherpad
After=syslog.target
After=network.target

[Service]
Type=simple
User=etherpad
Group=etherpad
Environment="NODE_ENV=production"
ExecStart=/home/etherpad/etherpad-lite/src/bin/run.sh
Restart=always

[Install]
WantedBy=multi-user.target

Nachdem die Datei angelegt wurde, kann der Service aktiviert und gestartet werden:

systemctl enable etherpad
systemctl start etherpad

Lokal ist der Service nun per HTTP unter dem Port 9001 erreichbar. Damit der Service auch von außen erreichbar ist, kann Nginx als Reverse Proxy konfiguriert werden. Dazu muss die entsprechende Konfiguration hinterlegt werden:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
    ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

    server_name example.org;

    client_max_body_size 512m;

    location / {

        # Set proxy headers
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # These are important to support WebSockets
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        # Make sure to set your Etherpad port number
        proxy_pass http://localhost:9001;
    }
}

Damit steht Etherpad auch von außen unter der entsprechenden Domain zur Verfügung und kann benutzt werden.

Ubuntu stellt demnächst Firefox auf Snap um. In der Community kochen mal wieder die Gemüter hoch. Anstelle mich immer zu wiederholen, fasse ich hier mal alle relevanten Punkte zusammen. Das Ziel ist ein möglichst sachlicher Überblick

Es gibt unterschiedliche Arten wie Betriebssysteme Software organisieren. Windows und macOS haben lange auf separate Installationsroutinen für einzelne Programme gesetzt, die auf ein Betriebssystem mit eigener Updateroutine installiert werden. Heute drängen beide mehr oder minder erfolgreich auf die Adaption des App Store-Prinzips auch für den Desktop.

Die verschiedenen Linux-Distributionen haben stattdessen aus unterschiedlichen Gründen eine zentrale Paketverwaltung für die Installation und Aktualisierung des gesamten Systems, letztlich vom Kernel bis zum Taschenrechner, entwickelt. Dabei gab und gibt es unterschiedliche Spielarten, aber das System funktioniert bei fast allen Distributionen gleich.

Das hat nichts mit Open Source vs. proprietäre Software zu tun, was man schon daran sehen kann, dass die verschiedenen BSD-Varianten noch mal ganz andere Modelle aufgezogen haben.

Ganz zentral ist, dass es kein entweder/oder gibt. Die Entwickler von Flatpak respektive Snap haben nie die Absicht geäußert, klassische Paketverwaltungen gänzlich zu ersetzen und selbst wenn eine Distribution komplett bei klassischen Paketverwaltungen bleiben möchte, kommt man vermutlich zukünftig zumindest bei manchen proprietären Programmen nicht um die Nutzung von Flatpak bzw. Snap umhin.

Die Sinnhaftigkeit von zwei neuen Lösungen, also Flatpak und Snap, kann man infrage stellen. Es wird hier keine Analyse der Unterschiede der einzelnen beiden Lösungen geben und auch keine Prognose abgegeben, ob beide dauerhaft überleben, oder nur eines von beiden sich durchsetzt. Neben Flatpak und Snap gibt es mit AppImages und Container-Ansätzen weitere Lösungen, die hier nicht berücksichtigt werden.

Paketverwaltung

Kennzeichen der klassischen Paketverwaltung:

• Die Paketverwaltung dient zur zentralen Installation und Aktualisierung aller Bestandteile des gesamten Systems.
• Der Bezug erfolgt heute i. d. R. über zentrale Repositorien und erfordert eine Internetverbindung.
• Programme werden nach Möglichkeit in ihre Bestandteile zerlegt und z. B. Bibliotheken oder Sprachdateien separiert. Eine Abhängigkeitsauflösung erfolgt durch die Paketverwaltung und sorgt dafür, dass alle notwendigen Bestandteile installiert werden.
• Rechte werden über Benutzer- und Gruppenrechte, sowie Dateisystemberechtigungen gesteuert.

Vorteile der klassischen Paketverwaltung:

• Programme benötigen keine separaten Updateroutinen.
• Eine Distribution ist eine aufeinander abgestimmte Gesamtkomposition, in der idealerweise alles perfekt harmoniert und getestet ist.
• Die Distributoren können Programme zielgenau patchen und gezielt bestimmte Versionen nutzen.
• Durch die Aufspaltung der Programme und Abhängigkeiten können einzelne Bibliotheken von vielen Programmen genutzt werden. Idealerweise ist keine Bibliothek doppelt installiert.

Nachteile der klassischen Paketverwaltung:

• Das System führt zu einem Duopol aus Rolling Release Distributionen (alles vom Kernel bis zum Taschenrechner wird fortlaufend aktualisiert) und stabilen Distributionen (nur Sicherheitsupdates und Fehlerbehebungen für alles vom Kernel bis zum Taschenrechner).
• Je älter die Basis, desto schwieriger bis ganz unmöglich ist die Aktualisierung einzelner Bestandteile, weil Abhängigkeiten auf gemeinsam genutzte Bestandteile irgendwann nicht mehr erfüllt werden können.
• Aufgrund der komplexen Abhängigkeitsauflösung ist es nicht komfortabel Pakete herunterladen und offline zu installieren.
• Jedes Programm muss für jede Distribution neu paketiert werden. Das bedeutet angesichts der aktuellen Anzahl an Distributionen, dass die Arbeit bis zu 100 Mal wiederholt wird.
• Entwickler müssen hoffen, dass ihr Programm von jeder wichtigen Distribution paketiert und damit den Endanwendern zur Verfügung gestellt wird.
• Entwickler haben Schwierigkeiten zu testen und Fehler zu reproduzieren, weil sie keinen Einfluss darauf haben, welche Bibliotheken und welchen Versionen vorliegen.
• Paketverwaltung sind sehr mächtige Systeme und lassen sich nur ungenügend mit einfachen App-Store-ähnlichen Oberflächen administrieren.

Neue Formate Flatpak / Snap

Kennzeichen der neuen Formate Flatpak / Snap:

• Dient konzeptionell nur dazu Programme und nicht das gesamte System zu verwalten.
• Nur Snap: Der Bezug erfolgt über ein zentrales Repositorium unter der Kontrolle von Canonical.
• Nur Flatpak: Distributoren können eigene Repositorien betreiben, faktisch gibt es mit Flathub eine übergreifende zentrale Bezugsplattform.
• Rechteverwaltung mittels einer Sandbox-Lösung mit spezielle Zugriffsrechten (AppArmor bei Snap; Portals bei Flatpak)
• Programme im Flatpak / Snap-Format bringen viele Bibliotheken bereits mit, nur wenige gemeinsam genutzte Bestandteile und keine ausdifferenzierte Abhängigkeitsverwaltung.

Vorteile der neuen Formate Flatpak / Snap:

• Flatpaks / Snaps können unabhängig von der Betriebssystem-Basis aktualisiert werden.
• Ein Snap oder Flatpak muss nur 1 Mal erstellt werden und kann anschließend unter allen Distributionen genutzt werden.
• Flatpaks / Snaps bringen die Bibliotheken in exakt den Versionen mit, für die sie getestet wurden.
• Flatpaks / Snaps ermöglichen es unterschiedliche Versionen von Programmen gleichzeitig zu installieren.
• Es gibt eine moderne Zugriffssteuerung, um Programmen ggf. den Zugriff auf das Dateisystem, die Kamera, das Mikrofont etc. pp. zu beschränken.
• Flatpak / Snap ermöglicht in Kombination mit anderen Lösungen gänzlich neue Typen von Distributionen wie z. B. Fedora Silverblue oder openSUSE MicroOS.

Nachteile der neuen Formate Flatpak / Snap:

• Bei Sicherheitsupdates für einzelne Bibliotheken müssen alle Flatpaks / Snaps aktualisiert werden, die diese enthalten. Es besteht das Risiko, dass dies nicht konsequent erfolgt.
• Die Verantwortung für die Prüfung der eingereichten Flatpaks / Snaps liegt bei Flathub respektive Snapcraft.io. Es bestehen Zweifel an der Qualität dieser Prüfung.
• Ein höherer Speicherplatzverbrauch, da letztlich dieselbe Bibliothek (ggf. in unterschiedlichen Versionen) mehrfach installiert wird. Das System ist weniger effizient in dieser Richtung.
• Kinderkrankheiten: Beide Formate sind immer noch nicht ausgereift. Es gab und gibt verschiedentlich Probleme mit Performance und der Steuerung der neuen Zugriffsrechte.

Der Artikel Flatpak / Snap vs. Paketverwaltung – Alles was dazu gesagt werden muss erschien zuerst auf [Mer]Curius

Die MZLA Technologies Corporation hat mit Thunderbird 91.1.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.1.1

Thunderbird 91.1.1 ist ein Fehlerbehebungs-Update außer der Reihe, welches noch einmal eine ganze Reihe von Fehlern der Versionsreihe 91 behebt, ehe ab dieser Woche die Updates von Thunderbird 78 auf Thunderbird 91 aktiviert werden – zunächst nur für Nutzer in den USA. Eine Übersicht über die in Thunderbird 91.1.1 behobenen Fehler gibt es in den Release Notes (engl.).

Der Beitrag Thunderbird 91.1.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

In verwende seit einiger Zeit elementary OS im Consumer-Einsatz. Die Erfahrungen sind ziemlich positiv. Nun teste ich den weitestgehenden Umstieg auf Flatpaks.

In meinem Umfeld sind in den letzten Jahren einige Leute auf Linux umgestiegen. Ich empfehle das nicht aktiv, aber wenn der Wunsch von außen an mich herangetragen wird und eine Prüfung der Bedarfe Linux als mögliche Alternative ergibt, helfe ich gerne beim Umstieg. Ehrlicherweise allerdings auch langfristig als Ansprechpartner für Administration und Probleme. Das ist nur noch privat und semi-privat für ein KMU. Beruflich geht es für mich schon seit einiger Zeit in eine andere Richtung und weg von IT-„Management“.

Vor einiger Zeit habe ich damit begonnen, für diese Zwecke elementary OS auszutesten. Momentan betreue ich dadurch leider eine ziemlich krude Mischung aus Kubuntus und Systemen mit Pantheon Shell. Elementary OS 5 hatte leider einige nervige Bugs, weshalb ich längere Zeit auf Fedora setzte.

Die Pantheon Shell und die zugehörigen Programme plus Ergänzungen aus dem GNOME Ökosystem sind meiner Meinung nach ideal für Anwender, die keine Lust haben sich groß mit dem System zu befassen. Die Funktionsweise ist intuitiv und die Programme nicht überfrachtet mit Optionen. Die Anwender sind damit ziemlich zufrieden und ich bekomme sehr selten Probleme mit. Die Kubuntus machen mir da viel mehr Scherereien, nicht wegen Fehlern, sondern weil die Anwender es immer wieder hinbekommen, Plasma zu verunstalten und mit der Reorganisation der Elemente dann überfordert sind, weil die KDE-UX nicht intuitiv ist.

Die Integration von Pantheon in Fedora ist aber nur mittelmäßig und hat hier und da immer wieder für Probleme gesorgt. Trotz der Schwächen von elementary OS 6 habe ich daher angefangen, die Systeme sukzessive umzustellen.

Die elementary-Entwickler haben den Wechsel auf ein Flatpak-basiertes System eingeleitet. Das neue Appcenter kann zwar Aktualisierungen für APT durchführen, aber bietet Installationen von neuen Programmen nur über das Flatpak-Repo an. Ich stehe den neuen Formaten grundsätzlich offen gegenüber, obwohl ich persönlich bei meinem eigenen System noch eine klassische RR-Paketverwaltungssystem fahre.

Das Flatpak-Repo von elementary OS ist noch recht schmal bestückt, aber man kann Flathub unproblematisch systemweit einrichten und danach die dort enthaltenen Programme via Appcenter (oder Terminal) installieren.

Das habe ich auf einem „Testsystem“ jetzt mal konsequent verfolgt. Die klassische Paketverwaltung organisiert nun wirklich nur noch das Basissystem und die Desktopoberfläche. Alle Programme kommen konsequent aus dem elementary Flatpak-Repo oder von Flathub. Das ist der übliche Consumer-Mischmasch aus Firefox, Evolution, LibreOffice, Spotify, Anydesk usw. usf.

Der Vorteil ist ziemlich offensichtlich. Die Version von Kernel, X11, Mesa oder glibc ist hier völlig egal, die Hardware wird schon seit Kernel 5.4 perfekt unterstützt. Das Basissystem kommt nun direkt aus Ubuntu main plus die separat von elementary gepflegten Bestandteile. Das trägt notfalls bis ins Jahr 2025. Hier gibt es keine Überraschungen oder Updates, die Administration erforderlich machen. Durch den konsequenten Einsatz von Flatpaks entgeht man aber den ungepflegten Paketen in universe und bekommt hier immer die aktuelle stabile Version ausgeliefert.

Die Installation und die Updates laufen ziemlich problemlos und durch die Ähnlichkeit zu den mobilen Appstores ist das Verfahren auch sehr niedrigschwellig und bedurfte keiner weiteren Erklärung.

Ich bin gespannt wie sich das System so im Alltagsbetrieb schlägt, ob Probleme auftreten und wenn ja welche.

Der Artikel Experiment: elementary OS 6 mit Flatpaks erschien zuerst auf [Mer]Curius

In diesem Beitrag beschreibe ich exemplarisch, wie ein In-Place-Upgrade von RHEL 7 auf RHEL 8 durchgeführt werden kann. Dabei beschreibe ich zuerst, was ein In-Place-Upgrade ist und in welchen Fällen es sinnvoll sein kann, bevor ich im Hauptteil anhand einer Test-VM die Durchführung demonstriere.

Was ist ein In-Place-Upgrade?

Als In-Place-Upgrade wird der Vorgang bezeichnet, bei dem ein Betriebssystem auf ein neues Major-Release aktualisiert wird, ohne das System dabei neuinstallieren zu müssen. Statt dessen werden alle zum Betriebssystem gehörenden Dateien gegen die entsprechende Version des neuen Release ausgetauscht.

Nutzer von Debian und Ubuntu kennen dieses Verfahren unter dem Begriff Distributions-Upgrade.

• https://wiki.ubuntuusers.de/Upgrade/
• https://www.debian.org/releases/bullseye/i386/release-notes/ch-upgrading.de.html

In-Place-Upgrade vs. Neuinstallation

Grundsätzlich bevorzuge ich die Neuinstallation eines Systems. Da man sich üblicherweise mit Backups und Deployment-Skripten darauf vorbereitet hat, einen Dienst bzw. eine Anwendung nach einem Verlust des laufenden Systems wiederherstellen zu können, kann man sich dies auch zu Nutze machen und den Dienst bzw. die Anwendung auf einem frisch installierten System wiederherzustellen. Auf diese Weise werden keine Altlasten über mehrere Betriebssystemversionen mitgeschleppt.

Gleichzeitig kann man die Downtime verkürzen, indem das neue System parallel zum alten aufgebaut wird und man nach dem Abschluss aller Arbeiten und Tests umschaltet. Das Altsystem kann im Nachgang in Ruhe abgebaut werden.

Es gibt jedoch auch Gründe, die für ein In-Place-Upgrade sprechen. Verfügt man nur über einen einzigen Host und kann kein Parallelsystem aufbauen, kann ein In-Place-Upgrade die Lösung sein.

Evtl. verfügt man selbst zwar über ausreichend Berechtigungen, um das vorhandene System zu aktualisieren, für die Provisionierung neuer Systeme ist man jedoch auf die Unterstützung weiterer Stellen angewiesen. Die Abhängigkeitskette lässt sich hier zum Teil deutlich reduzieren.

Dabei muss stets bedacht werden, dass bei einem In-Place-Upgrade auch ein katastrophaler Fehler eintreten kann, welcher zum Verlust des Systems führt. Es ist daher dringend angeraten, eine Datensicherung zu haben, aus welcher das System wiederhergestellt werden kann. Besitzt man ein Backup, auf das man sich verlassen kann, kann es auch schon losgehen.

Das Upgrade von RHEL 7 auf RHEL 8

Laut Kapitel 1 der unter [0] verlinkten Dokumentation stellt das In-Place-Upgrade den von Red Hat unterstützten und empfohlenen Weg dar, um auf das nächste Major-Release zu aktualisieren. Dabei kann man stets nur von der letzten Verfügbaren RHEL 7 Version auf das jeweils letzte gerade RHEL 8 Release (z.B. 8.4) aktualisieren. Details hierzu können im Artikel unter [1] nachgelesen werden.

Die folgenden Abschnitte können die Dokumentation unter [0] nicht ersetzen. Sie sollen lediglich einen kompakten Überblick über den Prozess geben.

Limitierungen

Zum Zeitpunkt der Artikelerstellung , kann das In-Place-Upgrade nicht auf Systemen mit verschlüsselten Dateisystemen durchgeführt werden.

Netzwerkspeicher, wie z.B. iSCSI oder NAS, werden nicht unterstützt und müssen während des Upgrades ausgehängt werden. Die dazugehörigen Dienste, wie z.B. autofs müssen vorübergehend deaktiviert werden.

Weitere bekannte Probleme sind Kapitel 8 in [0] zu entnehmen.

Vorbereitung

Bevor man mit dem Upgrade beginnen kann, sind folgende Voraussetzungen zu schaffen:

• Das System erfüllt die minimalen Systemvoraussetzungen für RHEL 8 (siehe [2]).
• Zugriff auf Repos mit aktuellen Paketen für RHEL 7.9 und RHEL 8.4.
• Korrekte Registrierung des Systems am Red Hat Content Delivery Network (CDN) oder den Red Hat Satellite Server mittels Red Hat Subscription Manager (RHSM).

Wichtig: Ich empfehle ausdrücklich, vor Beginn der Arbeiten ein aktuelles Backup bzw. einen Snapshot zu erstellen, um auf den Ausgangszustand vor der Upgrade-Prozedur zurückkehren zu können.

Kapitel 2 in [0] bietet eine ausführliche Schritt-für-Schritt-Anleitung zur Vorbereitung des Upgrades. Der folgende Codeblock bietet eine kompakte Übersicht der einzelnen Schritte. Als Zielsystem dient eine aktuelle RHEL 7.9 Minimal-Installation.

[tronde@rhel7-t1 ~]$ # Überprüfung, ob eine RHEL-Subskription abonniert wurde
[tronde@rhel7-t1 ~]$ sudo subscription-manager list --installed
[sudo] password for tronde: 
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+
Product Name:   Red Hat Enterprise Linux Server
Product ID:     69
Version:        7.9
Arch:           x86_64
Status:         Subscribed
Status Details: 
Starts:         06.10.2020
Ends:           06.10.2021

[tronde@rhel7-t1 ~]$ # Aktivierung des RHEL 7 Basis- und Extras-Repo
[tronde@rhel7-t1 ~]$ sudo subscription-manager repos --enable rhel-7-server-rpms
Repository 'rhel-7-server-rpms' is enabled for this system.
[tronde@rhel7-t1 ~]$ sudo subscription-manager repos --enable rhel-7-server-extras-rpms
Repository 'rhel-7-server-extras-rpms' is enabled for this system.

[tronde@rhel7-t1 ~]$ # Ist locale auf en_US.UTF-8 gesetzt?
[tronde@rhel7-t1 ~]$ cat /etc/locale.conf
LANG="en_US.UTF-8"

[tronde@rhel7-t1 ~]$ sudo yum install leapp leapp-repository
# Ausgabe gekürtzt
Transaction Summary
================================================================================
Install  2 Packages (+24 Dependent packages)

Total download size: 5.3 M
Installed size: 19 M
Is this ok [y/d/N]: y
# Ausgabe gekürtzt

Pre-Upgrade-Bericht erstellen

Bevor das eigentliche Upgrade durchgeführt wird, führe ich auf meinem Testsystem das Kommando leapp preupgrade aus. Dieses sammelt Informationen über das System, um die Upgradefähigkeit zu bewerten und erstellt einen detaillierten Bericht, welcher im Pfad /var/log/leapp/leapp-report.txt abgelegt wird.

[tronde@rhel7-t1 ~]$ sudo leapp preupgrade
# Ausgabe gekürzt
============================================================
                           ERRORS                           
============================================================

2021-08-31 06:33:26.035495 [ERROR] Actor: repository_mapping
Message: Data file /etc/leapp/files/repomap.csv is invalid or could not be retrieved.
Summary:
    Details: Could not fetch repomap.csv from https://cert.cloud.redhat.com/api/pes/repomap.csv (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.
2021-08-31 06:35:22.415297 [ERROR] Actor: restricted_pcis_scanner
Message: Data file /etc/leapp/files/unsupported_driver_names.json is invalid or could not be retrieved.
Summary:
    Details: Could not fetch unsupported_driver_names.json from https://cert.cloud.redhat.com/api/pes/unsupported_driver_names.json (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.
2021-08-31 06:35:47.800140 [ERROR] Actor: pes_events_scanner
Message: Data file /etc/leapp/files/pes-events.json is invalid or could not be retrieved.
Summary:
    Details: Could not fetch pes-events.json from https://cert.cloud.redhat.com/api/pes/pes-events.json (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.

============================================================
                       END OF ERRORS                        
============================================================


Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile
[tronde@rhel7-t1 ~]$

Dem obigen Codeblock ist zu entnehmen, dass der Pre-Upgrade-Check Fehler festgestellt hat, die behoben werden müssen, bevor ein In-Place-Upgrade durchgeführt werden kann. Dankenswerter Weise ist sowohl in der Ausgabe auf STDOUT als auch in /var/log/leapp/leapp-report.txt der Knowledge-Base-Artikel [3] verlinkt, welcher die Lösung parat hält.

Ist dieser Fehler behoben, lässt man leapp preupgrade ein weiteres Mal laufen und prüft die Ausgabe erneut. Auf meinem Testsystem erhalte ich nun folgende Ausgabe:

[root@rhel7-t1 ~]# leapp preupgrade
# Ausgabe gekürzt
============================================================
                     UPGRADE INHIBITED                      
============================================================

Upgrade has been inhibited due to the following problems:
    1. Inhibitor: Missing required answers in the answer file
Consult the pre-upgrade report for details and possible remediation.

============================================================
                     UPGRADE INHIBITED                      
============================================================


Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

Diesmal weist die Ausgabe darauf hin, dass ein Upgrade durch fehlende Antworten in /var/log/leapp/answerfile verhindert wird. Die genannte Datei kann mit einem Editor geöffnet und entsprechend bearbeitet werden:

[remove_pam_pkcs11_module_check]
# Title:              None
# Reason:             Confirmation
# =================== remove_pam_pkcs11_module_check.confirm ==================
# Label:              Disable pam_pkcs11 module in PAM configuration? If no, the upgrade process will be interrupted.
# Description:        PAM module pam_pkcs11 is no longer available in RHEL-8 since it was replaced by SSSD.
# Type:               bool
# Default:            None
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
confirm = True

Die Datei enthält direkt eine Erklärung, warum das erwähnte Modul zu entfernen ist und wie dies zu geschehen hat.

Anschließend empfiehlt sich ein Blick in den Bericht unter /var/log/leapp/leapp-report.txt, um zu prüfen, ob einem Upgrade evtl. weitere Gründe entgegen stehen. Auf die Ausgabe des Berichts in diesem Artikel wird aus Platzgründen verzichtet. Da der Inhalt auf jedem System unterschiedlich ausfallen kann, ist sein Nutzen an dieser Stelle ohnehin stark begrenzt.

Durchführung des In-Place-Upgrade

An dieser Stelle wird es ernst. Man sollte sich noch einmal vergewissern, dass man einen Snapshot bzw. ein geeignetes Backup des Systems hat. Dann wird das Upgrade mit folgendem Befehl gestartet:

# leapp upgrade
# Ausgabe gekürzt
============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

Dieser Vorgang kann mehrere Minuten dauern. Leapp lädt notwendige Daten herunter und bereitet die RPM-Transaktionen für das Upgrade vor. Dabei wird erneut geprüft, ob Gründe vorliegen, die ein Upgrade verhindern können. Sollte dies der Fall sein, bricht leapp den Vorgang ab und erzeugt einen neuen Bericht.

Ist das Upgrade erfolgreich durchgelaufen, muss das System manuell neugestartet werden. Das System startet anschließend in eine RAM-Disk und aktualisiert alle Pakete des Systems. Anschließend wird automatisch ein Neustart ausgeführt. Dieser Vorgang lässt sich am besten an einer (virtuellen) Konsole beobachten.

Nachdem das Upgrade abgeschlossen ist, kann man sich wieder am System anmelden und mit folgenden Kommandos prüfen, ob das System den gewünschten Status hat (vgl. Kapitel 5 in [0]):

[root@rhel7-t1 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.4 (Ootpa)

[root@rhel7-t1 ~]# uname -r
4.18.0-305.12.1.el8_4.x86_64

[root@rhel7-t1 ~]# subscription-manager list --installed
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+
Product Name:   Red Hat Enterprise Linux for x86_64
Product ID:     479
Version:        8.4
Arch:           x86_64
Status:         Subscribed
Status Details: 
Starts:         06.10.2020
Ends:           06.10.2021

[root@rhel7-t1 ~]# subscription-manager release
Release: 8.4

Hier sieht alles gut aus.

Post-Upgrade-Tasks

Kapitel 6 in [0] beschreibt detailliert, welche Aufgaben nach einem erfolgreichen In-Place-Upgrade noch auszuführen sind, um ein möglichst sauberes System zu erhalten.

Auf meinem Testsystem sind einige RHEL 7 Pakete zurückgeblieben, welche ich mit folgendem Kommando entferne:

# dnf remove `rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort`
Updating Subscription Management repositories.
Dependencies resolved.
===============================================================================
 Package              Arch       Version                     Repository   Size
===============================================================================
Removing:
 doxygen              x86_64     1:1.8.5-4.el7               @System      15 M
 kernel               x86_64     3.10.0-1160.31.1.el7        @System      64 M
 kernel               x86_64     3.10.0-1160.36.2.el7        @System      64 M
 leapp                noarch     0.12.1-1.el7_9              @System      93 k
 leapp-repository     noarch     0.14.0-4.el7_9              @System     1.7 M
 python2-leapp        noarch     0.12.1-1.el7_9              @System     618 k
 ustr                 x86_64     1.0.4-16.el7                @System     279 k

Transaction Summary
===============================================================================
Remove  7 Packages

Freed space: 146 M
Is this ok [y/N]:

# cd /lib/modules && ls -d *.el7*
3.10.0-1160.25.1.el7.x86_64  3.10.0-1160.36.2.el7.x86_64
3.10.0-1160.31.1.el7.x86_64

# /bin/kernel-install remove 3.10.0-1160.36.2.el7.x86_64 /lib/modules/3.10.0-1160.36.2.el7.x86_64/vmlinuz
# /bin/kernel-install remove 3.10.0-1160.25.1.el7.x86_64 /lib/modules/3.10.0-1160.25.1.el7.x86_64/vmlinuz
# /bin/kernel-install remove 3.10.0-1160.31.1.el7.x86_64 /lib/modules/3.10.0-1160.31.1.el7.x86_64/vmlinuz

Damit ist es geschafft. Das System wurde erfolgreich auf RHEL 8 aktualisiert.

Fazit

Dieser Artikel stellt das RHEL-In-Place-Upgrade vor und nennt kurz einige Gründe, wann dies gegenüber einer Neuinstallation Vorteile bietet. Anschließend wurde das Upgrade an einem Testsystem demonstriert mit dem Ziel, einen Überblick über den Upgrade-Prozess zu geben.

Für In-Place-Upgrades von Produktionssystemen ist ein Blick in die Hersteller-Dokumentation, Backups und sorgfältige Planung unerlässlich.

Das für diesen Artikel verwendete Testsystem besteht lediglich aus einer Minimal-Installation ohne Anwendungen von Dritten. Ob ein In-Place-Upgrade auch mit installierten Anwendungen Dritter funktioniert, hängt vom Einzelfall ab und ist sorgfältig zu prüfen und zu testen.

Erste Versuche mit Web- und Anwendungsservern aus unserer Umgebung konnten mit positivem Ergebnis abgeschlossen worden.

Es gibt Anwendungsfälle, wo ein In-Place-Upgrade vorteilhaft ist. Ich persönlich bevorzuge, wenn möglich und vom Aufwand vertretbar, jedoch die Neuinstallation inkl. Migration der Daten auf einem neuen System. So kann sichergestellt werden, dass keine unentdeckten Altlasten mitgeschleppt werden.

[0] Upgrading from RHEL 7 to RHEL 8. Instructions for an in-place upgrade from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. Red Hat Enterprise Linux 8. Red Hat Customer Content Services.

[1] Supported in-place upgrade paths for Red Hat Enterprise Linux (Login required)

[2] Red Hat Enterprise Linux technology capabilities and limits

[3] Data required by the Leapp utility for an in-place upgrade from RHEL 7 to RHEL 8 (Login required)

Die Welt war schön und einfach, als Steve Ballmer 2001 Open Source noch zu einem Krebsgeschwür erklärte. Hier die freie Open Source Community, dort die Hersteller proprietärer Systeme. Heute ist die Welt unübersichtlicher geworden und nicht Konzerne wie Microsoft sind das größte Problem, sondern Firmen wie Google.

Bleiben wir beim Bild des Krebsgeschwürs. Balmer meinte in jenem denkwürdigen Interview, dass die freie Lizenz alles anstecken würde, was es berührt, daher der Vergleich mit Krebs. Heute würde ich Google als eben jenen Krebs bezeichnen, denn es befällt alles was es berührt und zerstört es.

Die grundlegende Frage ist letztlich, was ist Open Source und was ist freie Software. Man kann es rein rechtlich und nüchtern per Definition betrachten. In der Auseinandersetzung um die Luca-App hat das auch eine größere Öffentlichkeit erreicht. Open Source ist sachlich betrachtet erst mal nur offener Quellcode, den man einsehen kann. Die Lizenz kann trotzdem proprietär sein. Freie Software ist hingegen offener Quellcode und eine freie Lizenz. Zur besseren Unterscheidung gibt es den Begriff FOSS: Free and Open Source Software. Seltener auch als FLOSS, also Free/Libre Open Source Software bezeichnet.

Kurzum: Alles was unter einer freien Lizenz steht und den Quelltext frei zur Verfügung steht, ist Open Source Software. Bleibt man nahe an dieser Definition, ist es nur ein rechtlicher Vorgang, ob eine freie Lizenz gewählt wird und es kann unmöglich ein Urteil darüber getroffen werden, ob irgendetwas „Open Source“ schadet. Abgesehen von einer Verletzung der Lizenz natürlich. Hier könnte man den Artikel nun beenden.

Das greift aber zu kurz. Open Source steht auch für eine Gemeinschaft und ein Konzept. Ganz wesentlich hat dies in der öffentlichen Wahrnehmung die Entwicklergemeinschaft um den Linux-Kernel geprägt. Eine Gemeinschaft aus Individuen erschafft gemeinsam eine lauffähige Software, die dann frei verfügbar ist. Potenziell kann jeder dazu beitragen und die Software besser machen.

Dieses Konzept und diese Idee hat sich im Laufe der Zeit einen guten Ruf erarbeitet. Freie Software gilt erst mal als etwas Positives und Entwickler, die dazu beitragen, bekommen dasselbe Sozialprestige wie bei anderen Ehrenämtern auch. Dasselbe gilt für Firmen im Open Source-Umfeld.

Und hier kommt Google ins Spiel: Was ist, wenn eine Firma sich dieses Images bedient, den Gedanken bis zur Unkenntlichkeit aushöhlt und die Community mit überlegenen finanziellen Ressourcen ruhig stellt. Gleichzeitig unterwandert sie das Ökosystem bis zur Dysfunktionalität. Denn genau das tut Google.

Als Vergleich lohnt sich ein Blick auf Microsoft und Apple. Insbesondere der Konzern aus Redmond hat ja in den letzten Jahren eine umfassende Open Source Strategie aufgebaut. Die meisten dürften sich z. B. an die Übernahme von GitHub oder die Offenlegung von .NET erinnern. Inzwischen kann man sogar Linux als Subsystem installieren. Trotzdem würde sich kein Microsoft-Manager hinstellen und beispielsweise bei der Ankündigung von Windows 11 irgendwo von einem „freien System, das die Welt besser macht“, sprechen.

Das Gleiche gilt für Apple. Dabei sind seine Betriebssysteme tief im Kern Open Source. Das betrifft nicht nur Darwin, sondern auch viele andere Bestandteile und großzügige Übernahmen aus dem BSD-Universum. Ein Gutteil von macOS (und iOS) steht unter freien Lizenzen. Trotzdem stellt sich kein Apple-Manager hin und behauptet, Apple wäre eine tolle Open Source Company. Da wirft man lieber mit tausend anderen Superlativen um sich.

Anders ist das bei Google. Als Beispiel kann die Darstellung der Geschichte von Android dienen. Mithin das wichtigste Produkt von Google neben der Suchmaschine:

2007

Steve Jobs stellt das erste iPhone vor. Im gleichen Jahr gründet Google gemeinsam mit 33 Partnern aus der Mobilfunkbranche, darunter Samsung, HTC und T-Mobile, die »Open Handset Alliance«. Die Mission: mit Android ein offenes Betriebssystem zu schaffen, das jeder Hersteller und Entwickler kostenlos verwenden und anpassen kann.

Geschichte von Android, abgerufen am 17.09.2021

Das ist ein tolles Beispiel, weil es die Mechanismen von Googles Darstellung zeigt. Ein weiteres Beispiel ist die Open Source Landingpage von Google. Man schafft etwas freies, offenes, kostenloses, mit vielen Partnern und macht die Welt ein bisschen besser. Auch du als Programmierer oder Kunde willst Teil davon sein.

Den Lesern dieses Blogs brauche ich vermutlich nicht erzählen, was für ein Quatsch das ist. Die Open Handset Alliance existiert nur auf dem Papier, faktisch entwickelt Google Android alleine. Die Hersteller werden z. B. mit lukrativen Knebelverträgen verpflichtet, Android mit dem proprietären Google-Ökosystem auszuliefern. Die Kunden in der westlichen Welt wollen Android nur in der Google-Variante. Huawei musste das gerade schmerzlich erfahren.

Und hier nähern wir uns dem Kern des Problems an. Google macht viel mit Open Source, aber die Basis des Geschäftsmodells ist die Bündelung mit proprietären Google-Diensten. Alles was Google am Ende an den Verbraucher bringt, ist letztlich eine Kombination aus Open Source und proprietären Bestandteilen. Weder bei Android noch bei Chrome oder dem neuen Projekt Fuchsia gibt es eine Kooperation mit der Community. Google entwickelt und schmeißt den Quellcode der Community vor die Füße. Das unterscheidet sich nahezu gar nicht von der Art, wie Apple Darwin veröffentlicht. Die Community kann dann schauen, was sie damit macht. Bei Android hat die famose Custom ROM-Szene ein lauffähiges freies Android entworfen, auf Basis des Chrome-Quellcodes sind viele Browser entstanden und mal sehen, was Fuchsia so bringt. Bei ChromeOS hat man erst die Gemeinschaft entdeckt, als man merkte, dass man mit reinen WebApps nicht weiter kommt. Die maschinelle Übersetzung auf Googles Seite ist verblüffend ehrlich:

Linux ist eine Funktion, mit der Sie Software auf Ihrem Chromebook entwickeln können.

Chromebook Hilfe, abgerufen am 17.09.2021

Dass ChromeOS ein angepasstes Linux ist und ohne die Community nicht denkbar wäre wird mit keinem Wort auf der gesamten Seite erwähnt.

Gleichzeitig gerät die Gemeinschaft in eine massive Abhängigkeit von Google. Ich glaube, dass die Existenz von Android ein Grund ist, warum lange kein freies Linux-Smartphone entwickelt wurde und die Projekte noch immer in den Kinderschuhen stecken. Es gab ja bereits ein „Linux-Betriebssystem für Smartphones“. Ganz offenkundig ist es mit Chrome. Die Existenz von Chromium hat viele Projekte dazu gebracht, auf den Google-Vorarbeiten aufzusetzen. Qt hat gar sein eigenes WebKit eingestampft und ist auf Chromium gewechselt. Doch was passiert, wenn Google Chrome morgen aufgibt oder mit Fuchsia sich von den Linux-Wurzeln löst?

Die FOSS-Community wird gleichzeitig mit Projekten wie GSoC ruhig gestellt. Nachwachsende Generationen von Programmierern werden gleich mit einer positiven Einstellung zu Google herangezogen (bei Journalisten macht Google das übrigens genau so) und die OSS-Projekte sind viel zu knapp an Ressourcen, um sich den Avancen von Google zu widersetzen.

Sind Firmen wie Microsoft oder Apple besser? Nein, aber sie sind ehrlicher. Sie behaupten nicht, freie Software zu entwickeln und wenn sie es machen, stellen sie es nicht so extrem ins Schaufenster. Es sind proprietäre Firmen und es gibt mit der FOSS-Gemeinschaft etablierte Verfahren der Koexistenz. Wenn Apple Darwin morgen einstampft, ist das für den Fortbestand von FOSS unkritisch, mit Abstrichen würde das auch für den fiktiven Fall gelten, dass Microsoft GitHub abschaltet.

Wenn Google morgen jedwedes Engagement für FOSS einstellt, dürfte das anders aussehen. Und die Abhängigkeit wird jedes Jahr größer.

Und bei dieser Betrachtung haben wir noch nicht mal in den Blick genommen, dass die FOSS-Gemeinschaft mit einer Firma ins Bett steigt, deren Geschäftsmodell die vielleicht größte Bedrohung für die Privatsphäre und den Datenschutz der Menschen in der westlichen Welt (neben den Aktivitäten staatlicher Stellen) darstellt.

Von „Don’t be evil“ hat Google sich ja wohlweislich vor einiger Zeit verabschiedet.

Der Artikel Warum Google für FOSS gefährlich ist erschien zuerst auf [Mer]Curius

Firefox wird in den meisten Ländern der Welt mit Google als Standard-Suchmaschine ausgeliefert. Aktuell testet Mozilla, wie sich eine Änderung der Standard-Suchmaschine auf Microsoft Bing auf die Nutzung von Firefox auswirkt.

Die meisten Browser werden bereits mit mehreren Suchmaschinen ausgeliefert. Auch hat der Nutzer jederzeit die Möglichkeit, weitere Suchmaschinen zu installieren. Das Thema Standard-Suchmaschine, sprich welche Suchmaschine genutzt wird, wenn der Nutzer keine Änderung vornimmt, ist von besonderer Bedeutung. Denn daran hängt üblicherweise zu einem großen Teil auch die Finanzierung des Browsers. Im Falle von Firefox beispielsweise hat die Vergütung für die Standard-Suchmaschine 88 Prozent von Mozillas Gesamt-Umsatz im Jahr 2019 ausgemacht.

Siehe auch: Mozillas Einnahmen, Ausgaben und Vermögen von 2005 bis heute

Fast schon traditionell wird Firefox mit Google als Standard-Suchmaschine ausgeliefert – zumindest in den meisten Ländern. Nur zwischen 2014 und 2017 fiel die Wahl auf Yahoo. Der aktuelle Vertrag zwischen Mozilla und Google soll im August 2020 um weitere drei Jahre verlängert worden sein.

Doch was bringt die Zukunft? Wie viel ist es Google über das Jahr 2023 hinaus noch wert, Standard-Suchmaschine in Firefox zu sein? Zumal Mozilla kontinuierlich weitere Datenschutz-Verbesserungen in Firefox ausliefert und Google mit Chrome ebenfalls einen Browser anbietet, der mittlerweile eine unglaublich hohe Dominanz besitzt, Tendenz weiter steigend. Es erscheint also nur logisch, dass sich Mozilla mit einem möglichen Zukunfts-Szenario beschäftigt, welches ohne Google stattfindet.

So findet seit diesem Monat ein Experiment statt, in dessen Rahmen die Standard-Suchmachine für einen Prozent der Desktop-Nutzer von Firefox auf Microsoft Bing verändert wird. Dieser Test, der Erkenntnisse darüber liefern soll, inwieweit eine Änderung der Standard-Suchmaschine Einfluss auf die Nutzung von Firefox hat, wird vermutlich bis Ende Januar 2022 laufen.

Der Beitrag Mozilla testet Microsoft Bing als Standard-Suchmaschine in Firefox erschien zuerst auf soeren-hentzschel.at.