Die MZLA Technologies Corporation hat mit Thunderbird 128.7 ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht.
Neuerungen von Thunderbird 128.7
Mit dem Update auf Thunderbird 128.7 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht. Das Update bringt wie immer diverse Fehlerbehebungen und Verbesserungen unter der Haube, welche sich in den Release Notes (engl.) nachlesen lassen. Auch wurden diverse Sicherheitslücken geschlossen.
Es gibt ein fertiges Skript, mit dem bei einer frischen Installation von Kubuntu SNAP, das Softwareverwaltungsprogramm von Canonical, entfernt werden kann. Über SNAP kann viel gesagt werden. Für mich, stellt das eine Lock-In Strategie und unnötiger Überbau dar, aber das müssen alle für sich selbst entscheiden.
Am besten gleich nach der Installation laufen lassen und die Tipps weiter unten auf der Seite zum Thema Flatpak sind auch super nützlich. Erfolgreich mit Kubuntu 24.10 durchgeführt.
UND !! diesen Artikel als Text auf die Platte speichern, denn nachdem Firefox entfernt wurde, gibt es erst mal keinen Browser mehr auf dem System, so dass die Informationen, wie Firefox wieder installiert wird, nur schwerlich zugänglich sind.
SNAP manuell entfernen
Zuerst anzeigen lassen, was alles installiert ist
snap list
Die Ausgabe könnte dann so ausehen
user@notebook:~$ snap list
Name Version Revision Tracking Herausgeber Hinweise
bare 1.0 5 latest/stable canonical✓ base
core20 20220318 1405 latest/stable canonical✓ base
firefox 99.0.1-1 1232 latest/stable/… mozilla✓ -
gnome-3-38-2004 0+git.1f9014a 99 latest/stable/… canonical✓ -
gtk-common-themes 0.1-79-ga83e90c 1534 latest/stable/… canonical✓ -
snapd 2.54.4 15177 latest/stable canonical✓ snapd
Mozilla hat Firefox 135 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.
Für Nutzer in den USA und Kanada wurde mit Firefox 134 ein angepasstes Layout für die Startseite ausgerollt, welches bis zu vier statt drei Content-Empfehlungen pro Zeile erlaubt und die Positionierung von Logo (und Wetter-Widget in Ländern, in denen dieses Feature bereits ausgerollt wird) so anpasst, dass die Suchleiste, Verknüpfungen und Content-Empfehlungen weiter oben erscheinen. Ab Firefox 135 erfolgt eine Ausrollung in allen anderen Ländern, welche Pocket-Empfehlungen unterstützen.
Diese Neuerung wird schrittweise im Laufe der kommenden Wochen für alle Nutzer ausgerollt werden.
Verbesserungen der Übersetzungsfunktion
Firefox besitzt eine Übersetzungsfunktion für Websites, welche im Gegensatz zu Cloud-Übersetzern wie Google Translate lokal arbeitet, die eingegebenen Texte also nicht an einen fremden Server sendet. Mit dem heutigen Tag folgt die Unterstützung von Übersetzungen aus dem Chinesischen, Japanischen sowie Koreanischen. Ebenfalls neu: Übersetzungen ins Russische.
Grundsätzlich ist die Unterstützung neuer Sprachen nicht an Firefox-Versionen gebunden, womit diese Sprachen auch in älteren Firefox-Versionen zur Verfügung stehen. Allerdings gab es in Firefox 135 Anpassungen, welche die Qualität für die Übersetzungen aus den asiatischen Sprachen verbessern.
Außerdem wurden allgemeine Verbesserungen an der Übersetzungsfunktion vorgenommen, von denen auch andere Sprachen profitieren und welche die Wahrscheinlichkeit verringern, dass unter bestimmten Umständen neue Wörter erfunden werden.
Speicherung von Kreditkarten-Daten
Firefox unterstützt die Speicherung von Kreditkarten-Daten, sodass Nutzer diese in Online-Shops nicht jedes Mal manuell eingeben müssen. Bislang war diese Funktion für Nutzer in Deutschland, Österreich, den USA, Kanada, Frankreich, Italien, Spanien, Belgien, Polen sowie dem Vereinigten Königreich aktiviert. Beginnend mit Firefox 135 startet eine weltweite Ausrollung dieses Features.
Diese Neuerung wird schrittweise im Laufe der kommenden Wochen für alle Nutzer ausgerollt werden.
KI-Chatbots
Firefox 135 integriert mehrere KI-Chatbots. Dabei stehen Google Gemini, ChatGPT, HuggingChat, Anthropic Claude sowie Le Chat Mistral zur Verfügung. Die Chatbots können direkt über die Sidebar genutzt werden.
Über das Kontextmenü oder, falls über eine Option im Abschnitt „Firefox Labs“ der Firefox-Einstellungen aktiviert, eine Schaltfläche nach dem Markieren von Text können auch direkt Funktionen zur Zusammenfassung des markierten Inhalts, zur Vereinfachung der Sprache sowie zu einem Abfragen des Inhalts ausgewählt werden.
Neu gegenüber früheren Versionen, in denen dieses Feature über eine versteckte Option bereits vorab getestet werden konnte, ist ein vordefinierter Prompt zum Korrekturlesen. Ebenfalls im Vergleich neu ist ein Kommando, um die Chatbot-Sidebar per Tastatur öffnen und schließen zu können (Strg + Alt + X; macOS: Control + X).
Diese Neuerung wird schrittweise im Laufe der kommenden Wochen für alle Nutzer ausgerollt werden.
Verbesserung der Zurück-Navigation
Es wurden Schutzmechanismen implementiert, die verhindern, dass Websites die Verlaufs-API missbrauchen, indem sie die Verlaufseinträge überladen und damit die Navigation mit den Schaltflächen „Zurück“ und „Vorwärts“ erschweren. Firefox versucht nun, solche Einträge auszulassen.
Kleinere Installationsarchive für Linux
Mozilla hat seine Linux-Pakete von .tar.bz2 auf .tar.xz und damit auf eine LZMA-Kompression umgestellt. Dies resultiert in 25 Prozent kleineren Installationsarchiven sowie einer mehr als doppelt so schnellen Dekompressionszeit.
Sonstige Endnutzer-Neuerungen in Firefox 135
Für Nutzer von Apple macOS und Linux bietet Firefox beim Betätigen des Tastatur-Kommandos zum Beenden des Browsers die zusätzliche Option an, nur den aktuellen Tab zu schließen.
Die sichtbare Datenschutz-Einstellung für „Do not Track“ (DNT) wurde entfernt, da dieser Standard als gescheitert gilt und nicht mehr empfohlen wird. Der indirekte Nachfolger ist die „Global Privacy Control“ (GPC), für welche Firefox bereits eine eigene Einstellung besitzt („Websites anweisen, meine Daten nicht zu verkaufen oder weiterzugeben“).
Der Kontextmenü-Eintrag „Link ohne Website-Tracking kopieren“ wurde in „Saubere Link-Adresse kopieren“ umbenannt. Außerdem werden jetzt weitere Parameter von Facebook-Links entfernt und die Funktion steht auch für ausgeschriebene Links nach Markierung zur Verfügung.
Für Nutzer der neuen Seitenleiste, welche aktuell an einen kleinen Prozentsatz der Nutzer ausgerollt ist (oder manuell über die Option sidebar.revamp in about:config aktiviert werden kann), wurde ein Tastaturkommando implementiert, um diese ein- und auszufahren (Strg + Alt + Z; macOS: Control + Z). Außerdem wurde das Verhalten der Tastaturkommandos zum Ein- und Ausklappen der Sidebars für die Lesezeichen und Chronik im Zusammenspiel mit der neuen Seitenleiste verbessert.
Im Konto-Menü, welches auch Mozilla Monitor, Firefox Relay sowie das Mozilla VPN bewirbt, wird nach Anmeldung in das Mozilla-Konto jetzt zwischen „Meine Dienste“ und „Probieren Sie andere Schutzwerkzeuge von Mozilla aus“ getrennt, sofern der Nutzer auch Anwender von Firefox Relay ist.
Mit accessibility.typeaheadfind.wrappedSoundURL wurde eine neue Option in about:config hinzugefügt, um einen Sound abzuspielen, wenn das Ende einer Suche erreicht wurde.
Auf macOS 15 und höher werden seit Firefox 132 die neuen Auswahlfunktionen des Apple-Betriebssystems für die Bildschirm- und Fensterfreigabe unterstützt. Firefox 135 bringt die Unterstützung auch auf macOS 14.
Auf Linux unterstützt Firefox jetzt sogenanntes Native Messaging zur Kommunikation zwischen WebExtensions und auf dem System installierten Anwendungen auch, wenn Firefox als Snap-Paket installiert ist. Voraussetzung hierfür ist das XDG Desktop Portal in Version 1.19 oder höher (wobei Ubuntu die Unterstützung bereits vorab in Version 22.04 inkludiert hat) sowie die about:config-Option widget.use-xdg-desktop-portal.native-messaging in Firefox mit einem Wert von 1 oder 2.
Das Netzwerkanalyse-Panel der Entwicklerwerkzeuge zeigt jetzt auch Anfragen für data:-URIs sowie lokale Ressourcen, die über das file:-Protokoll eingebunden sind, an.
Mehr Sicherheit für Firefox-Nutzer
Auch in Firefox 135 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 135 daher für alle Nutzer dringend empfohlen.
Firefox erzwingt nun die sogenannte „Certificate Transparency“ und verlangt von Webservern einen ausreichenden Nachweis, dass ihre Zertifikate öffentlich bekannt gegeben wurden, bevor sie als vertrauenswürdig eingestuft werden. Dies betrifft nur Server, welche Zertifikate verwenden, die von einer Zertifizierungsstelle in Mozillas Stammzertifikats-Programm ausgestellt wurden.
Darüber hinaus wird der CRLite-Mechanismus zur Überprüfung des Widerrufs von Zertifikaten eingeführt, wodurch die Leistung dieser Überprüfungen erheblich verbessert wird.
Diese Neuerung wird schrittweise im Laufe der kommenden Wochen für alle Nutzer ausgerollt werden.
Verbesserungen der Webplattform
Verbesserungen der Webplattform lassen sich wie immer in den MDN Web Docs nachlesen.
Gestern war wieder der „Änder-dein-Passwort-Tag“. Früher war das Standard. Wer heute noch in einer Firma arbeitet, die das erzwingt, weiß, dass er eine unfähige IT-Abteilung hat. Aber so ein Tag ist eine gute Gelegenheit, sich zu fragen, ob man Passwörter überhaupt noch braucht.
Warum kein Passwort?
Die Kombination aus Benutzername/E-Mail-Adresse und Passwort ist nach wie vor das Rückgrat der Kontosicherheit im Internet. Dieses Prinzip ist jedoch sehr anfällig. Ist das Passwort zu einfach, kann es schnell geknackt werden. Ist das Passwort zu schwer, kann man es sich schlecht merken. Deshalb verwenden viele Menschen immer dasselbe Passwort. Auch deshalb sind Datenlecks so gefährlich. Die Voraussetzung eines einzigen Sicherheitsfaktors („Wissen“) ermöglicht zudem Phishing-Angriffe.
Passwortmanager sind ein Hilfsmittel, um den Passwort-Zoo überschaubar zu halten. Nur so können individuelle und sichere Passwörter für alle Accounts verwendet werden. Die Sicherheit dieser Passwortmanager hängt jedoch vom sicheren Master-Passwort ab. Außerdem haben Passwortmanager das „alle Eier in einem Korb“-Problem.
Vor einigen Jahren kamen daher Hardware-Schlüssel wie der Yubikey oder der Nitrokey auf. Damit sollten einfachere PINs (Faktor „Wissen“) mit einem externen Sicherheitsschlüssel (Faktor „Besitz“) kombiniert werden. Ich habe hier auch damit gespielt. Sie haben sich nur nie durchgesetzt. Man kann damit ein paar kritische Dienste absichern, aber Reichweite bekommen die nicht. Ich würde daher darauf nicht mehr setzen.
Das einzige verbreitete Hilfsmittel sind zusätzliche Einmalpasswörter auf der Basis von TOTP. Diese werden in der Regel mit einer App auf dem Smartphone generiert und ergänzen den Faktor „Besitz“ um den Faktor „Wissen“, den das Passwort erfordert. Viele Menschen empfinden dies als lästig, weshalb TOTP oft erst dann genutzt wird, wenn Diensteanbieter massiv darauf hinweisen oder es gar erzwingen.
Was sind Passkeys?
Was geblieben ist, ist die FIDO-Allianz als Standardisierungsgremium für Passwortalternativen. Diese hat mit FIDO2 inzwischen einen Standard geschafft, der mit einigen Anpassungen unter dem Marketingbegriff Passkey oder auch passwortloses Anmelden bekannt wurde. Das System wurde benutzerfreundlicher gemacht und anstelle von zusätzlichen Hardwaredongeln wird mit dem Smartphone ein Gerät verwendet, das man sowieso besitzt.
Passkeys basieren auf dem bewährten Prinzip der getrennten Schlüssel. Es gibt einen öffentlichen Schlüssel, der dem Dienstanbieter bekannt ist, und einen geheimen Schlüssel im internen Speicher, der für die Anmeldung benötigt wird. Dies hat mehrere Vorteile gegenüber Passwörtern:
Passkeys sind nie unterkomplex
Passkeys können nicht vergessen werden
Passkeys können nicht einfach durch Phishing abgegriffen werden
Passkeys werden immer individuell für einen Account erstellt.
Passkeys beheben also die schlimmsten Schwächen von Passwörtern. Gleichzeitig machen sie Krücken wie TOTP überflüssig, da der Faktor „Besitz“ – also des vertrauenswürdigen Endgerätes – den Passkeys immanent ist.
Funktionsweise
Das Konzept sah ursprünglich das Smartphone als zentrales Medium zur Generierung und Verwaltung von Passkeys vor. Das war konzeptionell klug gedacht, weil die meisten Menschen ein Smartphone haben und Banking Apps sowie TOTP bereits bei den Menschen verankert hat, dass Smartphones für so etwas geeignet sind.
Smartphones wurden aber vor allem deshalb gewählt, weil sie spezielle Sicherheitschips (z.B. Secure Enclave beim iPhone, Titan M beim Pixel) enthalten und die Betriebssysteme Android und iOS diese sinnvoll nutzen können. Nur so können Passkeys sicher gespeichert werden. Hier ist keine Synchronisation und keine proprietäre Cloud notwendig. Eine Anmeldung an Webseiten mit Passkey-Authentifizierung ist natürlich auch am Desktop möglich, setzt dann aber in diesem Konzept eine Freischaltung am Smartphone voraus. Zur Identifizierung ist entweder eine PIN oder ein biometrischer Abgleich notwendig. Also nichts, was moderne Smartphone-Nutzer nicht ohnehin schon kennen.
Moderne Desktop-Hardware für macOS und Windows kann Passkeys auch auf dem Desktop erzeugen und speichern. Das funktioniert schon Out-of-the-Box. Apple und Google (Android & Chrome) bieten in ihren Softwarelösungen eine cloudbasierte Synchronisation der Passkeys an. Dadurch sind Smartphones und Desktop synchron und es braucht kein Smartphone für die Freigabe auf dem Desktop. Auch Microsoft arbeitet an einer entsprechenden Lösung für Windows Hello. Auch hier ist eine biometrische Freigabe erforderlich. Moderne Hardware ist in der Regel mit Fingerabdruck- oder Gesichtserkennungsverfahren kompatibel und kann dafür genutzt werden. Das schließt andere Browser nicht aus. Firefox bietet ebenfalls Passkey-Unterstützung für Windows und macOS, nutzt dafür aber die entsprechenden Betriebssystemfunktionen (Apple Passwörter / Windows Hello).
Für Linux ist keine Out-of-the-Box-Implementierung integriert. Es sind auch keine Pläne bekannt, die Passwortspeicher entsprechend zu erweitern. Da es keine Linux-Smartphones gibt, ist das auch nicht weiter dramatisch. Nutzer können einfach auf Android ausweichen und darüber Passkeys erzeugen und freigeben. Will man Passkeys ohne Smartphone erzeugen und nutzen, benötigt man zusätzlich einen modernen Passwortmanager wie KeePassXC (ab Version 2.7.7.) und das entsprechende Firefox-Addon. Leider hat Linux auch hier Sicherheitsdefizite, da standardmäßig kein TPM zur Absicherung verwendet wird und biometrische Verfahren nicht sicher gespeichert werden können. Die KeePass-Datenbank sollte daher unbedingt zusätzlich mit einer Schlüsseldatei oder einem Hardwareschlüssel geschützt werden. Auch wenn dies die Vorteile von Passkeys wieder zunichte macht. Linux und Sicherheit ist leider keine einfache Sache mehr.
Ich habe gelesen dass…
Passkeys sind neu und Passwörter alt. Bornierte Alleshasser haben sich natürlich sofort darauf gestürzt. Da war anfangs sehr viel Halb- oder Unwahrheit im Unlauf und hat den Start von Passkeys zumindest in Deutschland massiv beeinträchtigt. Beliebte Angriffspunkte sind die Cloud-Sync-Funktion der großen Hersteller und die Bindung an ein Smartphone. Ersteres, weil die großen Hersteller böse sind und Smartphones gerne von Leuten als unsicher gebrandmarkt werden, die sie technisch nicht verstehen und die intime Kenntnis ihrer herkömmlichen Betriebssysteme mit Sicherheit verwechseln. Inzwischen ebbt die Pauschalkritikwelle aber ab und viele begreifen die Vorteile.
Wer auf solche Kommentare stößt, kann sie getrost ignorieren. Oft entlarven sie sich durch in diesen Kreisen beliebte Verballhornungen (Klaut, M$, Intelligenzphone etc.) selbst. Die Passkey-Synchronisation ist bei allen Anbietern durch zusätzliche Sicherheitsmaßnahmen wie Ende-zu-Ende-Verschlüsselung und die Speicherung auf dem Gerät zusätzliche Sicherheitsmodule wie TPM geschützt. Im direkten Vergleich zu Passwörtern haben Passkeys deutlich mehr Vorteile als Nachteile. Theoretisch überlegene Alternativen wie Yubikey sind leider an der Praxis gescheitert.
Fazit
Die Liste der Dienstanbieter, die Passkeys unterstützen wird stetig länger. Passkeys sind damit über jene Schwelle gekommen, die Hardwareschlüssel wie Yubikeys nie überschreiten konnten. Anstelle also sein Passwort zu ändern, sollte man prüfen, ob der Dienstanbieter nicht schon Passkeys unterstützt und diese anstelle nutzen.
Mozilla hat Version 2.25 seiner VPN-Clients für das Mozilla VPN veröffentlicht. Dieser Artikel beschreibt die Neuerungen vom Mozilla VPN 2.25.
Mit dem Mozilla VPN bietet Mozilla in Zusammenarbeit mit Mullvad sein eigenes Virtual Private Network an und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.
Das Update auf das Mozilla VPN 2.25 bringt keine neuen Funktionen, sondern vor allem Fehlerbehebungen und Verbesserungen unter der Haube. Die Option zum Starten des Mozilla VPNs mit Starten des Gerätes ist auf Desktop-Systemen jetzt standardmäßig aktiv. Das Adjust-SDK zwecks Kampagnenmessung wird nicht länger genutzt. Für Nutzer eines Smartphones oder Tablets von Apple ist iOS 15 die neue Mindestanforderung.
Solo ist ein Website-Builder von Mozilla, der auf Künstliche Intelligenz (KI) und einen maximal einfachen Erstellungsprozess setzt. Nun steht Solo 1.5 bereit und bringt viele Neuerungen.
Im Rahmen der Innovation Week im Dezember 2023 hatte das Mozilla Innovation Studio Solo angekündigt. Dabei handelt es sich um einen sogenannten Website-Builder mit Fokus auf Selbständige, der auf generative Künstliche Intelligenz für einen maximal einfachen Erstellungsprozess setzt.
Seit dem Start hat Mozilla einige Funktionen ergänzt. Jetzt hat Mozilla Solo 1.5 fertiggestellt. Die vollständigen Release Notes:
Exportieren von CSV-Dateien aller Kontaktformulare und Newsletter-Einträge
Neuer Share-Button, um Ihre Website über einen Link oder in sozialen Netzwerken zu teilen
Neuer Abschnitt „Code einbetten“ zum Einbetten von benutzerdefinierten Audio, Video oder anderen Anwendungen
Unterstützung für mobiles Onboarding
Neue Google Safe URL-Erkennung beim Erstellen von Links auf Ihrer Website
Link zu den Abschnitten Textbanner, Bildbanner und Code-Einbettung
Hinzufügen einer Schaltfläche „Ablehnen“ auf dem Cookie-Banner, falls aktiviert
Mobile und Desktop-Vorschau Ihrer Website anzeigen
Weitere allgemeine Fehlerbehebungen und Aktualisierungen
Die Nutzung von Solo ist kostenlos. Geringe Kosten fallen höchstens bei Verwendung einer benutzerdefinierten Domain an. Als Nächstes stehen weitere Optionen zum Bearbeiten und Gestalten, ein Abschnitt für Kundenlogos sowie eine neue Bibliothek zur Verwendung von Icons auf der Website auf der Roadmap.
Zukünftig wird Solo außerdem im Abschnitt „Mehr von Mozilla“ in den Firefox-Einstellungen beworben werden.
Mit dem Programm Ollama könnt ihr Large Language Models (LLMs) wie DeepSeek oder Mistral lokal auf eurem PC oder Laptop installieren und laufen lassen. Dabei nimmt euch Ollama die meiste Arbeit ab.
Installation
Unter https://ollama.com/download könnt ihr Versionen für macOS, Windoof und Linux herunterladen. Unter Archlinux erfolgt die Installation per
sudo pacman -S ollama
Wenn Ollama nicht in eurem Repository vorhanden ist, könnt ihr diesen Befehl verwenden:
curl-fsSL https://ollama.com/install.sh |sh
Nach der Installation kann Ollama per systemd gesteuert werden:
Um den Speicherort für die Modelle festzulegen, könnt ihr die Servicedatei /etc/systemd/system/ollama.service wie folgt anpassen (bei mir soll alles unter dem Pfad /media/SILO/Ollama abgelegt werden)
Sobald Ollama gestartet ist, können die Modelle wie folgt installiert werden:
ollama pull MODELLNAME
Den MODELLNAMEN erhaltet ihr von der Ollama-Homepage https://ollama.com/search. Dort findet ihr das DeepSeek-R1-Modell unter https://ollama.com/library/deepseek-r1. Die Modelle sind jeweils in verschiedenen Varianten verfügbar, z.B. 1.5b, 7b, 14b, 70b. Hierbei handelt es sich um die Parameter, die das Modell verwendet (das b steht für Milliarden). Je kleiner die Zahl, desto “abgespeckter” ist die Version. Je größer die Zahl ist, desto krasser muss eure Hardware sein, damit das Modell nicht Tage benötigt, um zu antworten. Startet am besten mit der kleinsten Zahl, und wenn das gut läuft, dann nehmt die nächst höhere Zahl. Auf einem halbwegs aktuellem Laptop sollten die 7b-Versionen gut laufen.
Ihr installiert das konkrete Modell, indem ihr die Variante per Doppelpunkt an den MODELLNAMEN anhängt. Für DeepSeek-R1 in der Variante 7b lautet der Befehl:
Eine Übersicht eurer installierten Modelle erhaltet ihr mittels
ollama list
NAME ID SIZE MODIFIED
deepseek-r1:7b 0a8c26691023 4.7 GB 2 minutes ago
llama2-uncensored:7b 44040b922233 3.8 GB 53 minutes ago
deepseek-r1:14b ea35dfe18182 9.0 GB 55 minutes ago
huihui_ai/deepseek-r1-abliterated:14b 6b2209ffd758 9.0 GB 57 minutes ago
Um eines dieser Modelle zu starten, gebt ihr ein:
ollama run MODELLNAME
Also zum Beispiel
ollama run deepseek-r1:7b
oder
ollama run huihui_ai/deepseek-r1-abliterated:14b
Der Promt startet, und ihr könnt eure Eingabe machen. Das interessante bei DeepSeek-R1 ist, dass ihr den Reasoning-Prozess verfolgen könnt. Zwischen den tags <think></think> könnt ihr mitlesen, wie das Modell “nachdenkt”.
DeepSeek-R1 denkt nach, und ja, ich habe mich im ersten Prompt vertippt…
Fazit
Ollama macht es mir super einfach, verschiedene Modelle zu installieren und zu nutzen. Und es ist echt interessant, dem “thinking” zuzuschauen.
Generell ist es sowieso immer besser, seine lokale “KI” zu befragen, statt den Datenkraken die Infos einzuwerfen.
Bislang erhält Thunderbird nur ein großes Update pro Jahr. Ab diesem März wird es auf Wunsch Feature-Updates im Monats-Takt geben, wie man es bereits von Firefox kennt.
Bereits vor knapp zwei Jahren hatte ich zum ersten Mal darüber berichtet, dass MZLA plant, einen monatlichen Release-Zyklus für Feature-Updates einzuführen, wie man es auch von Firefox kennt. Nun ist es soweit: Ab März 2025 mit Veröffentlichung von Thunderbird 136 werden die monatlichen Feature-Updates zum Standard.
Doch was bedeutet das genau? Neue Nutzer, welche sich Thunderbird über die Website herunterladen wollen, werden ab dann standardmäßig die Version von Thunderbird erhalten, welche dem neuen Release-Modell folgt. Für bestehende Nutzer ändert sich nichts. Wer derzeit Thunderbird auf dem sogenannten ESR-Kanal nutzt und damit ein Feature-Update pro Jahr und dazwischen lediglich Sicherheits- und Bugfix-Updates erhält, wird weiterhin auf diesem Veröffentlichungskanal bleiben.
Für die Zukunft ist es denkbar, dass über Benachrichtigungen innerhalb von Thunderbird ESR ein Wechsel der Thunderbird-Version beworben wird. Eine automatische Umstellung ist nicht geplant.
Mit Veröffentlichung von Thunderbird 136 wird sich dann auch die Berichterstattung auf diesem Blog ändern. Wie bei Firefox ESR werde ich nicht länger über neue Versionen auf dem ESR-Kanal berichten, sondern stattdessen ausschließlich über Updates auf dem Release-Kanal, der monatliche Feature-Updates bringt. Aber natürlich werde ich auch weiterhin über Sicherheits- und Bugfix-Updates auf dem neuen Release-Kanal berichten.
Die MZLA Technologies Corporation hat mit Thunderbird 128.6.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.
Neuerungen von Thunderbird 128.6.1
Mit Thunderbird 128.6.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht. Die neue Version bringt mehrere Korrekturen für die Versionsreihe 128, welche sich in den Release Notes (engl.) nachlesen lassen.
Dieses Tutorial führt in den RHEL image mode ein und zeigt, wie ein solches Image in einer virtuellen Maschine (VM) installiert werden kann. Es wird ebenfalls gezeigt, wie ein installiertes Image aktualisiert und bei Bedarf zurückgerollt werden kann.
Während diese Einführung in Deutsch gehalten ist, liegen die Dokumentation und weitere verwendete Quellen ausschließlich in englischer Sprache vor.
Das Tutorial richtet sich in erster Linie an Sysadmins, die bereits Erfahrung mit dem Betrieb von RHEL oder einer verwandten Enterprise Linux Distribution haben. Es bietet keine allgemeine Einführung in die Installation und den Betrieb von Red Hat Enterprise Linux.
Zum Inhalt
Die folgende Liste bietet einen Überblick über den Inhalt:
RHEL image modeist eine Technology Preview und (RHEL image mode ist bereits GA; lediglich der in diesem Tutorial verwendete bootc-image-builder ist noch eine Technology Preview) stellt eine neue Methode dar, um RHEL zu konfigurieren, installieren bzw. deployen und zu verwalten.
Durch Nutzung von Container-Tools wird ein Container-Image erstellt, welches neben dem RHEL-Userland auch den RHEL-Kernel, Boot Loader, Firmware und Treiber umfasst. Dieses RHEL-Container-Image (auch RHEL Bootc Image genannt) kann anschließend genutzt werden, um RHEL im Datacenter oder in der Cloud – auf Bare-Metal-Servern, virtuellen Maschinen oder Edge-Geräten zu deployen. Das RHEL-Container-Image kann direkt als Container ausgeführt werden, um die Funktionalität zu testen. Für das Deployment kann das Container-Image in ein Disk-Image für die entsprechende Zielplattform konvertiert werden. Ein installiertes oder als Disk-Image provisioniertes System läuft anschließend nativ auf der Hardware bzw. in der virtuellen Maschine und wird dort nicht als Container ausgeführt.
Konsolidierung von Bereitstellungsprozessen
In vielen Unternehmen kommen heute neben klassischen virtuellen Maschinen auch Linux-Container zum Einsatz. RHEL image mode bietet die Möglichkeit, Bereitstellungsprozesse zu konsolidieren, indem für die Bereitstellung von RHEL-Images die gleichen Werkzeuge genutzt werden, wie für die Bereitstellung von Container-Images für Anwendungen.
Immutable RHEL
Mit Ausnahme von /etc und /var ist das Wurzel-Dateisystem in RHEL image mode immutable (read-only).
Anwendungen und Updates werden durch aktualisierte RHEL-Container-Images verteilt. Ein provisioniertes System lädt dazu das aktualisierte Image auf die lokale Festplatte und startet dieses nach einem Neustart. Im Fehlerfall kann durch einen weiteren Neustart einfach das vorherige Image gestartet werden. So können fehlgeschlagene Updates einfach zurückgerollt werden.
Dies bietet dem Admin die Sicherheit, bei Bedarf zum vorherigen Zustand zurückkehren zu können, ohne dafür auf VM-/Storage-Snapshots oder andere Mechanismen außerhalb des Betriebssystems zurückgreifen zu müssen.
Deklarative Konfiguration des Betriebssystems
RHEL image mode macht es einfach, zu konfigurieren und zu verfolgen, welche Pakete in einem Basis-Image enthalten sind und wann welche Pakete hinzugefügt wurden.
Red Hat veröffentlicht in der Container-Registry registry.redhat.ioRHEL Bootc Base Images, welche die Basis für eigene Images darstellen. Zu jeder Version wird eine Liste der enthaltenen Pakete veröffentlicht. Diese ist über den Red Hat Ecosystem Catalog einsehbar:
Ansicht der Paketliste eines RHEL 9 Bootc Base Image
Hier ist zu beachten, dass obwohl amd64 als Architektur ausgewählt wurde, die Liste Pakete aller verfügbaren Architekturen zeigt. Natürlich sind im Basis-Image nicht 2302 Pakete enthalten. Die Filtermöglichkeiten und die Ergebnisliste zeigen leider unerwartete Ergebnisse. Ich habe dies bereits intern gemeldet und hoffe, dass sich bald jemand der Sache annimmt.
Das in obiger Abbildung gezeigte Image enthält für die amd64-Architektur 441 Pakete. Vergleiche ich dies mit zwei meiner RHEL 9 Installationen, die auf der Minimalinstallation basieren, so umfassen diese 591 bzw. 510 Pakete. Der Vergleich hinkt allerdings, da ich auf den RHEL package mode Installationen bereits weitere Software nachinstalliert habe. Ich bin jedoch erfreut, dass das Basis-Image nicht mehr Pakete als eine Minimalinstallation enthält.
Pakete, die zusätzlich hinzugefügt werden sollen, werden im Containerfile aufgeführt, welches üblicherweise einer Versionskontrolle unterliegt. Änderungen können so jederzeit nachvollzogen werden.
Meine Laborumgebung besteht aus zwei virtuellen Maschinen, welche auf einem Laptop ausgeführt werden. Beide VMs verfügen über 2 vCPU, 8 GB RAM und 40 GB Speicher.
Auf VM 1 werden folgende Tätigkeiten ausgeführt:
Erstellung und Ausführung einer einfachen Container-Registry
Erstellung und Pflege eines oder mehrerer rhel-bootc-Container-Images
Erstellung von Disk-Images
Anhand von VM 2 werden folgende Dinge demonstriert:
Installation von RHEL image mode
Aktualisierung der Installation
Wechsel des verwendeten Images
Rollback
Die in diesem Tutorial verwendeten Containerfiles, Dateien und Skripte habe ich in einem Git-Repository gesammelt. Fühlt euch frei, die dortigen Dateien auf eigene Gefahr für eigene Versuche zu verwenden. Repository-URL: https://github.com/tronde/image-mode-demo
RHEL Bootc Image erstellen
Dieser Abschnitt wurde aus Kapitel 2 der Dokumentation Using image mode for RHEL to build, deploy, and manage operating systems abgeleitet. In ihm wird das RHEL-Container-Image erstellt, welches im nächsten Schritt für das Deployment in einer VM vorbereitet wird. Dieser Abschnitt behandelt folgende Schritte:
Containerfile(5) erstellen
Container-Image mit podman-build(1) erstellen
Container-Image auf dem Build-System testen
Containerfile
Mit dem folgenden Containerfile(5) wird konfiguriert, wie das RHEL Bootc Base Image ‚rhel-bootc:9.5‚ angepasst werden soll:
Die Dienste httpd und sshd werden aktiviert, damit sie nach dem Boot-Vorgang automatisch starten
Die im Containerfile aufgeführten Pakete sind eine persönliche Auswahl, die ich gern auf meinen Systemen habe. Ihr könnt hier natürlich die Pakete eurer Wahl eintragen.
Für dieses Tutorial installiere ich den Dienst httpd. Das von dem Image provisionierte System wird also einen Webserver hosten. Dass ich die index.html-Datei ebenfalls dem Image hinzufüge, soll mir lediglich den späteren Test in diesem Tutorial vereinfachen. Je nach Aufbau, Inhalt und Änderungsrate der auszuliefernden Webseite bzw. Webanwendung ist es nicht sinnvoll, diese in das Image zu integrieren.
Build
Login registry.redhat.io
Bevor das erste Container-Image erstellt werden kann, ist eine Anmeldung an der Container-Registry registry.redhat.io notwendig:
$ podman login registry.redhat.io
Username: alice
Password:
Login Succeeded!
Mit dem folgenden Befehl kann nun ein Image aus obigen Containerfile erstellt werden:
$ time podman build -t localhost/rhel9.5-bootc:test .
…
Successfully tagged localhost/rhel9.5-bootc:test
c958185aa4c578af37b5bca796c7c5e50a270f7b7de38126c31fa6ab97046f41
real 2m52.574s
user 2m31.787s
sys 0m59.680s
$ podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/rhel9.5-bootc test c958185aa4c5 40 seconds ago 1.68 GB
registry.redhat.io/rhel9/rhel-bootc 9.5 7cf5466a7756 2 days ago 1.56 GB
Das Container-Image wird unter dem Namen localhost/rhel9.5-bootc:test im lokalen Dateisystem gespeichert.
Der Build-Vorgang dauerte insgesamt knapp 3 Minuten. Darin ist die Zeit zum Herunterladen des Basis-Image registry.redhat.io/rhel9/rhel-bootc:9.5 enthalten. Ist dieses Image bereits vorhanden, dauert der Build-Vorgang nur knapp über 1 Minute.
Test
Der nun folgende Code-Block zeigt, wie das soeben erstellte Container-Image mit Podman im interaktiven Modus gestartet werden kann. Es wird geprüft, ob die index.html-Datei vorhanden ist und wie viele Pakete das Image enthält.
$ podman run -it --rm --name mybootc localhost/rhel9.5-bootc:test /bin/bash
bash-5.1# ls -l /var/www/html
total 4
-rw-r--r--. 1 root root 342 Jan 11 11:20 index.html
bash-5.1# rpm -qa | wc -l
465
bash-5.1#
Als nächste teste ich, ob die index.html-Datei auch ausgeliefert wird:
$ podman run -d --rm -p 127.0.0.1:8888:80 --name mybootc localhost/rhel9.5-bootc:test
fa9c1f5110cd58c3f28760fb5a5d69cdc4595a5cba2f29ff67f85eaa076204ab
$ curl http://127.0.0.1:8888
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Bootc Demo Page</title>
</head>
<body>
<p>Diese Seite wird von einem Webserver ausgeliefert, der mit RHEL Bootc Image Mode bereitgestellt wurde.</p>
</body>
</html>
Test erfolgreich! Die konfigurierte Webseite wird wie erwartet ausgeliefert. Der Container wird mit podman stop mybootc gestoppt und der Test ist beendet.
Zwischenfazit
Bis hier wurde ein Containerfile erstellt, welches das zu verwendende Basis-Image, die zusätzlich zu installierenden Pakete und die auszuführenden Dienste definiert. Mit Hilfe dieses Containerfiles und Podman wurde anschließend das Container-Image localhost/rhel9.5-bootc:test erzeugt. Mit einem einfachen Test konnte auf dem Build-System verifiziert werden, dass die index.html-Datei wie gewünscht ausgeliefert wird.
Das Image enthält keinerlei Passwörter oder SSH-Schlüssel. Es sind somit bisher keinerlei Geheimnisse enthalten, die mit dem Image verloren gehen könnten.
Verglichen mit einer klassischen RHEL-Minimalinstallation, die als Basis für ein Golden-Image dient, konnte der Vorgang deutlich schneller abgeschlossen werden.
ISO-Image mit dem bootc-image-builder erstellen
Der bootc-image-builder ist eine Container-Variante des RHEL Image Builder. Mit diesem wird in den folgenden Schritten ein ISO-Image aus dem zuvor erstellten Container-Image erzeugt. Mit dem ISO-Image wird anschließend eine Installation in einer VM durchgeführt.
Mit dem bootc-image-builder können auch Disk-Images wie AMI, GCE, QCOW2, RAW und VMDK erzeugt werden. Ich habe mich für ISO entschieden, da dies am vielseitigsten verwendbar ist. Man kann damit VMs unter KVM/Qemu und VMware genauso installieren, wie Bare-Metal-Server.
Benutzer, Passwort und SSH-Schlüssel hinzufügen
Um sich nach der Installation interaktiv am System anmelden zu können, werden dem ISO-Image ein Benutzer mit Passwort und SSH-Schlüssel hinzugefügt. Dafür wird die folgende Datei toml.config genutzt:
$ cat config.toml
[[customizations.user]]
name = "alice"
password = "changeme"
key = "ssh-ed25519 AAAAC3NzaC…cr alice@example.com"
groups = ["wheel"]
Durch Hinzufügen des Benutzers zur Gruppe wheel darf dieser privilegierte Kommandos mittels sudo ausführen.
Das Container-Image in den passenden Benutzerkontext kopieren
Das Image localhost/rhel9.5-bootc:test wurde mit einem rootless-Benutzer erstellt. Der Befehl im folgenden Abschnitt muss jedoch mit root-Rechten ausgeführt werden. Rootful-Podman kann jedoch nicht auf das Image zugreifen, welches wir mit rootless-Podman erstellt haben. Der Vorgang würde fehlschlagen mit der Meldung: Error: localhost/rhel9.5-bootc:test: image not known.
Um dies zu verhindern, gibt es zwei Möglichkeiten. Möglichkeit 1 bietet sich an, wenn man das ISO-Image auf dem gleichen System wie das Container-Image erzeugen möchte. Hierbei wird das Container-Image einfach in den passenden Benutzerkontext kopiert. Die zweite Möglichkeit besteht darin, das Container-Image in eine Container-Registry zu pushen, aus der es dann im nächsten Schritt wieder gepullt werden kann.
Möglichkeit 1
Das Container-Image wird mit folgendem Befehl aus dem Kontext des Benutzers ‚alice‘ in den Kontext des Benutzers ‚root‘ kopiert.
$ podman image scp alice@localhost::rhel9.5-bootc:test
…
$ sudo podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/rhel9.5-bootc test fb6237fff684 21 minutes ago 1.68 GB
Selbstverständlich kann das Container-Image auch in einer Container-Registry gespeichert und im root-Kontext von dort wieder heruntergeladen werden. Für die spätere Aktualisierung eines installierten RHEL image mode Systems ist die Nutzung einer Container-Registry von Vorteil.
How to implement a simple personal/private Linux container image registry for internal use beschreibt die Einrichtung einer einfachen Registry. Ich habe die auszuführenden Schritte in dem Skript create_simple_container_registry.sh zusammengefasst. Die zur Ausführung notwendigen Parameter werden in der Datei registry.vars konfiguriert. Diese Datei ist bereits mit Standardwerten gefüllt, die direkt verwendet werden können. Installiert und konfiguriert wird die Registry mit dem Kommando:
$ sudo bash create_simple_container_registry.sh
Ich trage die IP-Adresse und den Hostnamen meiner VM 1 in die Datei /etc/hosts ein, damit die Namensauflösung funktioniert. Der folgende Code-Block zeigt, wie das Image localhost/rhel9.5-bootc in die Registry gepusht wird.
Die Option --tls-verfiy=false ist notwendig, da ein selbstsigniertes TLS-Zertifikat verwendet wird. Mit dem folgenden Befehl kann überprüft werden, ob sich das Image in der Registry befindet.
Der folgende Code-Block zeigt, wie mit dem bootc-image-builder eine ISO-Datei erzeugt wird, die sich für eine RHEL-Installation in einer Offline-Umgebung eignet. Der Befehl muss mit sudo ausgeführt werden, da erweiterte Benutzerrechte erforderlich sind.
Da das Container-Image des bootc-image-builder noch nicht lokal vorliegt, muss zuerst ein Login bei registry.redhat.io erfolgen. Dies wurde weiter oben bereits für den rootless-Benutzer durchgeführt, muss für den rootful-Benutzer jedoch wiederholt werden, da Logins nicht zwischen verschiedenen Benutzerkontexten geteilt werden.
Achtung: Der folgende Befehl funktioniert nur, wenn das Image localhost/rhel9.5-bootc:test für root verfügbar ist. Dies kann durch eine der Methoden, die im vorherigen Abschnitt beschrieben wurden, sichergestellt werden. Ich habe in diesem konkreten Fall Möglichkeit 1 verwendet.
$ sudo podman login registry.redhat.io
Username: alice
Password:
Login Succeeded!
$ mkdir output
$ time sudo podman run \
> --rm \
> -it \
> --privileged \
> --pull=newer \
> --security-opt label=type:unconfined_t \
> -v /var/lib/containers/storage:/var/lib/containers/storage \
> -v $(pwd)/config.toml:/config.toml \
> -v $(pwd)/output:/output \
> registry.redhat.io/rhel9/bootc-image-builder:latest \
> --type iso \
> --config /config.toml \
> --local \
> localhost/rhel9.5-bootc:test
…
real 22m31.407s
user 0m1.997s
sys 0m2.049s
$ ls -lh output/bootiso/
total 2.4G
-rw-r--r--. 1 root root 2.4G Jan 11 14:26 install.iso
Nun zur Erklärung des Ganzen:
Der Login erfolgt, um das bootc-image-builder-Image herunterladen zu können
Im Projektverzeichnis wird das Verzeichnis output erstellt, welches die ISO-Datei enthalten wird
Nun folgt ein ziemlich langer Aufruf von podman run
Falls in registry.redhat.io eine neuere Version des bootc-image-builder gefunden wird, wird diese heruntergeladen und genutzt
bootc-image-builder muss mit erhöhten Rechten ausgeführt werden, weshalb die Ausführung mittels sudo und die Option --privileged erforderlich sind
Ort der config.toml und Verzeichnis für das ISO werden dem Container als Volume zugänglich gemacht
Mit --type iso wird festgelegt, dass eine ISO-Datei erstellt werden soll
Die Option --local gibt an, dass das lokal existierende Image localhost/rhel9.5-bootc.test verwendet und dies nicht aus einer Registry geholt werden soll
Dass der Vorgang ganze 22 Minuten dauerte, ist den 2 vCPU-Kernen und den 8 GB RAM meiner VM geschuldet. Während der Arbeitsspeicher gerade ausreichend war, dürften weitere CPU-Kerne den Vorgang deutlich beschleunigen.
Das nun erstellte ISO kann zur Installation in VM 2 verwendet werden.
Offline-Installation mit dem RHEL image mode
Das im vorherigen Abschnitt erstellte Disk-Image install.iso wird nun verwendet, um VM 2 zu installieren. Die Installation läuft wie eine normale unbeaufsichtigte Anaconda-Installation ab.
In der Datei toml.config wurde ein Benutzer mit einem SSH-Schlüssel spezifiziert, der nun zum Login in das neue System verwendet werden kann.
$ ssh -o StrictHostKeyChecking=no alice@vm2.example.com
Warning: Permanently added 'vm2.example.com' (ED25519) to the list of known hosts.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 7.1M 1 loop
sr0 11:0 1 2.4G 0 rom
zram0 251:0 0 7.8G 0 disk [SWAP]
vda 252:0 0 30G 0 disk
├─vda1 252:1 0 1G 0 part /boot
├─vda2 252:2 0 1G 0 part [SWAP]
└─vda3 252:3 0 28G 0 part /var
/sysroot/ostree/deploy/default/var
/etc
/sysroot
$ $ mount | grep -E '"/"|var|sysroot|etc'
/dev/vda3 on /sysroot type ext4 (ro,relatime,seclabel)
composefs on / type overlay (ro,relatime,seclabel,lowerdir=/run/ostree/.private/cfsroot-lower::/sysroot/ostree/repo/objects,redirect_dir=on,metacopy=on)
/dev/vda3 on /etc type ext4 (rw,relatime,seclabel)
/dev/vda3 on /sysroot/ostree/deploy/default/var type ext4 (rw,relatime,seclabel)
/dev/vda3 on /var type ext4 (rw,relatime,seclabel)
$ less /usr/lib/systemd/system/bootc-fetch-apply-updates.service
[jkastnin@localhost ~]$ systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
Active: active (running) since Tue 2025-01-14 15:29:07 UTC; 28min ago
Docs: man:httpd.service(8)
Main PID: 829 (httpd)
…
Da ich im Vorfeld keine genaueren Angaben gemacht habe, wurde der Datenträger automatisch partitioniert. Die Installation lässt sich durch Kickstart-Dateien steuern. Dazu wird der Inhalt der Kickstart-Datei in die Datei config.toml eingefügt. Siehe hierzu Kapitel 4.9. Using bootc-image-builder to build ISO images with a Kickstart file in der RHEL-Dokumentation.
Fazit nach der Installation von RHEL image mode
Mit rootless podman wurde ein rhel9.5-bootc:test Image erstellt
Mit dem bootc-image-builder wurde ein ISO-Image erstellt, welchem ein Benutzer mit Passwort und öffentlichem SSH-Schlüssel hinzugefügt wurde und welches sich für die Installation von Offline-Systemen eignet
Das ISO-Image wurde genutzt, um RHEL image mode in einer VM zu installieren
Test von Login und einiger weniger Kommandos
Der konfigurierte Webserver wird ausgeführt und liefert die kleine Beispielwebseite aus
Auf dem Weg hier her wurde erklärt, wie Container-Images mittels podman-image-scp(1) ohne Container-Registry zwischen Benutzerkontexten und Hosts kopiert werden können. Es wurde gezeigt, wie eine einfache Container-Registry betrieben und genutzt werden kann.
Zu den Aufgaben des IT-Betriebs gehört es, Betriebssysteme zu aktualisieren, ihre Konfiguration neuen Anforderungen anzupassen und im Fehlerfall die letzten Änderungen schnell rückgängig machen zu können. Diesen Aufgaben widmen sich die beiden folgenden Abschnitte.
Bootc Image Installation aktualisieren bzw. Konfiguration ändern
Während RHEL package mode Systeme zur Laufzeit mit DNF bzw. YUM aktualisiert werden und mit diesen Werkzeugen Software (de-)installiert wird, ist der Ablauf bei RHEL image mode Systemen anders:
Das RHEL Bootc Image wird aktualisiert
Das aktualisierte Container-Image wird in einer Registry verfügbar gemacht
Das aktualisierte Image wird in den Staging-Bereich des laufenden RHEL image mode Systems geladen
Durch einen Neustart wird das aktualisierte Image geladen
Bei Bedarf, z.B. bei auftretenden Problemen, kann das vorherige Image geladen werden
Aktualisierung des RHEL Bootc Image
Ich möchte die Pakete lsof, strace und tcpdump doch nicht in meiner Standardinstallation haben und sie aus der existierenden Installation entfernen. Deshalb kommentiere die entsprechenden Zeilen aus:
Als Nächstes wird ein neues Image erstellt und in die Registry gepusht. Diesmal verwende ich den Tag 0.0.1, um für den Verlauf dieses Tutorials leichter den Überblick zu behalten:
Das zu verwendende Image aus dem System heraus wechseln
Der nun folgende Schritt wird in dem laufenden RHEL image mode System in VM 2 ausgeführt. In der RHEL-Dokumentation ist dieser Schritt in Abschnitt 8.1. Switching the container image reference beschrieben.
Für diesen Schritt ist eine funktionierende Namensauflösung zwischen VM 1 und VM 2 erforderlich. In der Laborumgebung kann dies mithilfe der Datei /etc/hosts erfolgen. Da in der Registry ein selbstsigniertes Zertifikat verwendet wird und das Kommando bootc keine Option --tls-verify besitzt, muss eine insecure registry in VM 2 konfiguriert werden. Der folgende Codeblock zeigt den Inhalt der Datei, mit der die insecure registry konfiguriert wird:
Da bootc auch nicht über ein Login-Kommando verfügt und keinen Zugriff auf die Login-Informationen von Podman hat, wird in VM 2 ein Pull-Secret für bootc konfiguriert. Dazu wird eine Zeichenkette bestehend aus Benutzername:Passwort in Base-64 kodiert und zusammen mit der Registry-URL in die Datei /etc/ostree/auth.json geschrieben. Der folgende Code-Block zeigt dies mit den Beispielwerten aus diesem Tutorial:
Nach dem Wechsel befindet sich das ab nun zu verwendende Image zunächst im Staging-Bereich des lokalen Systems und wird beim nächsten Neustart aktiviert. Der Befehl bootc status gibt dazu übersichtlich Informationen aus, welches Image gestaged ist und welches aktuell verwendet wird:
~]# bootc status
Current staged image: vm1.example.com:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current booted image: localhost/rhel9.5-bootc:test
Image version: 9.20250109.0 (2025-01-11 12:40:29.172146867 UTC)
Image digest: sha256:eee2c8ea204615a9341f3747a6156c5b7bc208bbcf60f0a5bb28f142f6b0aa54
No rollback image present
Nach einem Neustart wird der Status mit bootc status erneut kontrolliert und wir sehen, dass nun das Image aus der Registry verwendet wird und das vorherige Image für ein Rollback vorgehalten wird:
~]$ sudo bootc status
No staged image present
Current booted image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current rollback image: localhost/rhel9.5-bootc:test
Image version: 9.20250109.0 (2025-01-11 12:40:29.172146867 UTC)
Image digest: sha256:eee2c8ea204615a9341f3747a6156c5b7bc208bbcf60f0a5bb28f142f6b0aa54
Automatische Aktualisierungen und wie man sie deaktivieren kann
Auf RHEL image mode Systemen existiert ein systemd.timer(5), welcher automatische Updates anstößt. Folgender Code-Block zeigt die Timer- und Service-Unit in VM 2:
$ systemctl status --no-pager bootc-fetch-apply-updates.{timer,service}
● bootc-fetch-apply-updates.timer - Apply bootc updates
Loaded: loaded (/usr/lib/systemd/system/bootc-fetch-apply-updates.timer; disabled; preset: disabled)
Active: active (waiting) since Wed 2025-01-15 08:29:37 UTC; 1h 1min ago
Until: Wed 2025-01-15 08:29:37 UTC; 1h 1min ago
Trigger: Wed 2025-01-15 10:28:13 UTC; 57min left
Triggers: ● bootc-fetch-apply-updates.service
Docs: man:bootc(8)
Jan 15 08:29:37 localhost systemd[1]: Started Apply bootc updates.
○ bootc-fetch-apply-updates.service - Apply bootc updates
Loaded: loaded (/usr/lib/systemd/system/bootc-fetch-apply-updates.service; static)
Active: inactive (dead)
TriggeredBy: ● bootc-fetch-apply-updates.timer
Docs: man:bootc(8)
Ein Blick in die Service-Unit verrät, was passiert, wenn diese getriggert wird:
Prüft, ob ein neues Image in der Container-Registry verfügbar ist (Prüfung efolgt auf Digest nicht auf Tag)
Falls ein neues Image verfügbar ist, wird dieses gestaged
Der Host wird automatisch neugestartet, um das neue Image zu laden
Möchte man Aktualisierungen durch andere Verfahren steuern, kann die automatische Aktualisierung wie folgt gestoppt werden:
$ systemctl mask bootc-fetch-apply-updates.timer
Rollback
Angenommen, das System soll auf das zuvor verwendete Conatiner-Image zurückgerollt werden. So kann man sich zuvor mit bootc status einen Überblick verschaffen, welches Image als Rollback-Image eingetragen ist:
Euch fällt evtl. auf, dass zwei Images den gleichen Tag, aber unterschiedliche SHA-256-Prüfsummen haben, und zwei Tags die gleiche Prüfsumme und unterschiedliche Tags. Lasst euch davon bitte nicht irritieren; dies ist nur meiner Spielerei geschuldet.
Bei einem Rollback wird das Image hinter dem Eintrag Current rollback image als Boot-Image verwendet. Ein Rollback wird mit folgendem Kommando ausgeführt:
$ sudo bootc rollback
Next boot: rollback deployment
Nur den Neustart muss man noch selbst durchführen. Nach dem Neustart sieht der Status wie folgt aus:
$ sudo bootc status
[sudo] password for jkastnin:
No staged image present
Current booted image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current rollback image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-15 09:36:38.866194063 UTC)
Image digest: sha256:e68453dd17a45ad9243139b5cbb0565bbd97aa2bcd5a230c41e44d295281f9a7
Anhand der SHA-256-Prüfsumme ist zu erkennen, dass das vorherige rollback image nun den Platz mit dem vorherigen booted image gewechselt hat. Ein weiterer Aufruf von bootc rollback führt zu einem weiteren Image-Wechsel.
Hinweis: Wenn nach einem Update ein Rollback durchgeführt wird und der Systemd-Timer für automatische Updates nicht deaktiviert wurde, führt dieser Timer bei Ablauf zu einem erneuten Update des Systems.
Ende
Hier endet die Einführung in RHEL image mode. Wer dem Tutorial aufmerksam gefolgt ist, sollte an dieser Stelle in der Lage sein:
RHEL Bootc Images zu erstellen
Eine einfache Container-Registry mit Podman zu betreiben
Mit bootc-image-builder Disk-Images zu erstellen
Ein System im RHEL image mode zu installieren
Das installierte System zu aktualisieren
Zu einem anderen Image zu wechseln
Ein Rollback auf das vorherige Image durchzuführen
Wenn euch diese Einführung gefallen hat, freue ich mich, wenn ihr sie mit euren Netzwerken teilt. Nutzt gern die Kommentarfunktion, um mich wissen zu lassen, wie euch diese Einführung gefallen hat.
Falls ihr euch weitere Artikel rund um den RHEL image mode wünscht, teilt mir dies gern ebenfalls über die Kommentarfunktion mit.
Mobilfunk ist eine unverzichtbare Technologie unseres Alltags – und gleichzeitig ein faszinierendes Beispiel für moderne Funksysteme. Während wir bei WLAN als Endnutzer oft sowohl das Endgerät als auch die Basisstation, den sogenannten Access Point, betreiben, ist der Mobilfunk weitaus komplexer und auch fachlich schwieriger zugänglich. Die Mobilfunknetze werden von großen Telekommunikationsunternehmen im lizenzierten Spektrum betrieben, und selbst auf unseren Telefonen bleibt die Interaktion mit dem Mobilfunknetz minimal. Meist reicht es, die SIM-Karte einzulegen, und schon funktioniert alles. Was viele nicht wissen: Auch Betriebssysteme wie Android oder iOS kommunizieren nicht direkt mit dem Mobilfunknetz. Diese Aufgabe übernimmt ein spezieller Chip, der sogenannte Baseband-Prozessor.
Open Source und Mobilfunk: Das Osmocom-Projekt
In der Open-Source-Welt gibt es nur wenige Projekte, die diese Funktechnologie zugänglich machen. Eines herausragendes Beispiel ist das Osmocom-Projekt. Schon ein erster Blick auf die Übersicht zeigt, dass es nicht "die eine" Mobilfunksoftware gibt. Vielmehr müssen viele verschiedene Komponenten ineinandergreifen und wie in einem Orchester zusammenspielen, um ein funktionierendes Netz bereitzustellen.
Sicherheitsforschung im Mobilfunk
Der Blick auf die Sicherheit sollte im Mobilfunk nicht vernachlässigt werden. So mag es überraschen, dass ältere GSM-Mobiltelefone deutlich unsicherer sind, als moderne Geräte, die auf LTE und 5G basieren. Hintergrund sind die verbesserten kryptographischen Verfahren.
Im Risikozone-Podcast haben wir uns in der Episode 65 mit der Mobilfunksicherheit genauer beschäftigt. Wir sprechen mit Adrian Dabrowski und Gabriel Gegenhuber über ihre Forschungsarbeiten und geben gemeinsam Einblick in eine Technologie, die als selbstverständlich wahrgenommen wird, aber in der Arbeitsweise völlig anders herangeht, als wir es aus der IETF-Welt mit TCP/IP & Co. gewöhnt sind.
Zusätzlich stellen Gabriel und Adrian das Open-Source-Projekt MobileAtlas vor. Dieses Projekt, inspiriert vom RIPE Atlas, widmet sich der Vermessung der Mobilfunkqualität und schafft eine interessante Plattform für weitere Analysen und Forschungsarbeiten.
Die 90-minütige Episode ist auf der Podcastseite oder direkt unter diesem Artikel abrufbar.
Unter KDE startet bei mir immer automatisch der Speech-Dispatcher. Meist zusammen mit Firefox. Das ist eigentlich ein super Dienst, der dafür sorgt, dass man sich Texte vorlesen lassen kann.
Allerdings stört dieser Speech-Dispatcher mein Soundsystem, so dass ich hier und da unter Schwerlast Knackser bekomme.
Mit diesem Befehl wird eine Datei speechd.conf mit dem Inhalt DisableAutoSpawn im /home/<USER>/.config/speech-dispatcher/ Verzeichnis des eigenen Benutzers angelegt und das automatische Starten des Speech-Dispatchers unterbunden. (eine Zeile)
Über das gesamte System kann mit root Rechten (sudo) in der Datei
sudo nano /etc/speech-dispatcher/speechd.conf
in der Zeile, in der #DisableAutoSpawn das Gatter # entfernt, so dass dann nur noch DisableAutoSpawn da steht und die Datei abspeichert
Spätestens nach dem nächsten Neustart sollte der Speech Dispatcher beim Einloggen weiterschlafen
Firefox
Firefox könnte den speech-dispatcher dann dennoch aufrufen. Damit das nicht passiert kann die Konfiguration bei Firefox mit about:config eingegeben in der URL Leiste geändert werden. Dann wird aber die Funktion, dass eine Webseite vorgelesen werden kann, nicht mehr funktionieren!
Wenn das OK ist, dann gib in der Suchzeile media.webspeech.synth.enabled ein und klicke doppelt auf das rechts daneben stehende true , um es in ein false zu ändern.
Manuell mit qpwgraph
Falls dann doch immer noch ein Programm den speech-dispatcher starten sollte, dann am besten mit dem Programm qpwgraph die „Kabel“ trennen und die aktuelle Konfiguration speichern und auf Aktiv setzen.
Mozilla hat eine neue Erweiterungs-Schnittstelle vorgestellt, welche Entwickler von Firefox-Erweiterungen nutzen können, um Anwendungsfälle für Maschinelles Lernen und Künstliche Intelligenz lokal auszuführen.
Nutzer einer Nightly-Version von Firefox können ab sofort eine neue experimentelle Erweiterungs-Schnittstelle nutzen. Diese hat Mozilla auf seinem Blog vorgestellt.
Die Schnittstelle erlaubt die Nutzung jedes maschinellen Lernmodells, welches mit Transformers.js kompatibel ist, im Browser auszuführen, ohne dass dabei Anfragen an externe Server gesendet werden. Lediglich das verwendete Modell muss bei der ersten Nutzung heruntergeladen werden, ansonsten geschieht die Arbeit vollständig lokal.
Zwar können Webanwendungen bereits Transformers.js in JavaScript nutzen. Die Ausführung über Mozillas Erweiterungsschnittstelle bietet aber mehrere Vorteile: So wird die Inferenz-Runtime in einem eigenen isolierten Firefox-Prozess ausgeführt, was die Sicherheit und Robustheit verbessert. Die Modell-Dateien werden in einer IndexedDB gespeichert und über verschiedene Ursprünge hinweg gemeinsam genutzt. Außerdem erlauben Firefox-spezifische Leistungsverbesserungen eine verbesserte Performance.
Transformers.js verwendet „Aufgaben“, um Implementierungsdetails für die Ausführung bestimmter Arten von ML-Workloads zu abstrahieren. Für die erste Iteration stellt Firefox die folgenden Aufgaben zur Verfügung:
text-classification – Zuweisung eines Labels oder einer Klasse zu einem gegebenen Text
token-classification – Zuweisung eines Labels zu jedem Token in einem Text
question-answering – Abrufen der Antwort auf eine Frage aus einem gegebenen Text
fill-mask – Maskierung einiger Wörter in einem Satz und Vorhersage, welche Wörter diese Masken ersetzen sollen
summarization – Erstellung einer kürzeren Version eines Dokuments unter Beibehaltung der wichtigen Informationen.
translation – Konvertierung von Text von einer Sprache in eine andere
text2text-generation – Konvertierung einer Textfolge in eine andere Textfolge
text-generation – Erzeugen von neuem Text durch Vorhersage des nächsten Wortes in einer Sequenz
zero-shot-classification – Klassifizierung von Text in Klassen, die während des Trainings nicht gesehen werden
image-to-text – Ausgabe von Text aus einem gegebenen Bild
image-classification – Zuweisung eines Labels oder einer Klasse für ein ganzes Bild
image-segmentation – Unterteilung eines Bildes in Segmente, in denen jedes Pixel einem Objekt zugeordnet ist
zero-shot-image-classification – Klassifizierung von Bildern in Klassen, die beim Training nicht gesehen werden
object-detection – Identifizierung von Objekten bestimmter definierter Klassen in einem Bild
zero-shot-object-detection – Identifizierung von Objekten von Klassen, die beim Training nicht gesehen werden
document-question-answering – Beantwortung von Fragen zu Dokumentenbildern
image-to-image – Umwandlung eines Quellbildes, damit es den Merkmalen eines Zielbildes oder eines Zielbildbereichs entspricht
depth-estimation – Vorhersage der Tiefe von Objekten in einem Bild
feature-extraction – Umwandlung von Rohdaten in numerische Merkmale, die verarbeitet werden können, wobei die Informationen im Originaldatensatz erhalten bleiben
image-feature-extraction – Umwandlung von Rohdaten in numerische Merkmale, die unter Beibehaltung der Informationen im Originalbild verarbeitet werden können
text-to-speech – Umwandlung von Text in Sprache
Für jede Aufgabe hat Mozilla ein Standard-Modell ausgewählt. Der Erweiterungs-Entwickler kann aber auf jedes Modell zurückgreifen, welches auf Hugging Face entweder von Mozilla oder Xenova veröffentlicht worden ist. Derzeit können nur Modelle dieser zwei Organisationen genutzt werden. Dass diese Einschränkung gelockert wird, ist für die Zukunft denkbar.
So einfach könnte beispielsweise Code zur Zusammenfassung von Text mit dem entsprechenden Standard-Modell aussehen:
Im Vergleich mit anderen WebExtension-Schnittstellen gibt es zwei wichtige Unterschiede: Zum einen kann die notwendige Berechtigung erst nach der Installation einer Erweiterung durch den Benutzer erteilt werden. Außerdem werden Änderungen der Schnittstelle in der Zukunt erwartet. Aus diesem Grund nutzt die Schnittstelle den browser.trial-Namespace, statt die Funktionen direkt in browser bereitzustellen. Damit wird die Erwartungshaltung entsprechend gesetzt, dass es sich hierbei um eine Art „Vorschau“ handelt und in Zukunft eher Anpassungen der Erweiterungen notwendig werden, als es bei WebExtensions normalerweise üblich ist.
Die KI-unterstützte Generierung eines Beschreibungstextes für Bilder in PDF-Dateien ist ein in Firefox von Haus aus integriertes Feature, welches unter der Haube aber auf genau die gleiche Weise funktioniert. Mozilla hat diesen Anwendungsfall zusätzlich auch noch in Form einer Erweiterung implementiert, um Entwicklern ein praktisches Beispiel zu geben, welches auch andere relevante Themen wie die Abfrage der Berechtigung behandelt.
Die Umfrage zeigt interessante Ergebnisse zur Nutzung der rollenden Distribution. Ich habe die Aussagekräftigsten für euch herausgesucht.
Vor etwa einem Monat hat ein Moderator der Arch-Linux-Reddit-Community eine Umfrage mit über 35 Fragen veröffentlicht, die verschiedene Aspekte der Interaktion der Benutzer mit der Distribution untersucht. Es wurden 3.923 Antworten gesammelt, und die Ergebnisse wurden nun öffentlich zugänglich gemacht. Sie bieten wertvolle Einblicke in die Art und Weise, wie die Community Arch Linux sieht und nutzt, wobei einige der Ergebnisse besonders interessant sind. Hier ist eine Zusammenfassung der interessantesten Highlights.
Bei der Frage nach der Desktop-Umgebung zeigt sich folgendes Bild:
Mit 37 % führt KDE Plasma gefolgt vom Tiling Compositor Hyprland mit 26 % und GNOME mit nur 11 %. Hinweis: die Legende stimmt nicht. Die ungewohnte Verteilung bei den DEs könnte man darauf zurückführen, dass Arch eher in der Nerd-Ecke Anhänger findet.
Als rolling release Distribution empfiehlt sich Arch nicht als Server-Betriebssystem, was die vorherige Grafik klar zeigt. Nur 1 % sagt, Arch auf einem Server zu verwenden.
Das Verhältnis zwischen der Nutzung der Kommandozeile und von grafischen Anwendungen beträgt 2 zu 1. Auch dieser Wert spricht für den Nerd- bzw. Profi-Charakter dieser Distribution. Bei Distros, die sich eher an Anfänger:innen wenden, dürfte der CLI-Wert erheblich geringer sein.
Beim bevorzugten Webbrowser dominiert Firefox und Derivate das Bild:
Hier hat Firefox mit 75 % klar die Nase vorn, während Chrome mit 5 % noch hinter Brave mit knapp 10 % liegt.
Interessant finde ich das 80:20-Verhältnis beim Display-Server. Nur noch 20 % setzen auf den X-Server.
Und hier das Ergebnis für die bevorzugten CPUs und GPUs:
Beim Hauptprozessor führt AMD leicht vor Intel. Das Rennen um den bevorzugten Grafikprozessor gewinnt AMD mit 42 % dicht gefolgt von Nvidia mit 40 %. Hinweis: auf den ersten Blick erscheint Nvidia als Gewinner, weil die AMD und Intel GPUs in 'integrated' und 'dedicated' aufgeteilt sind.
Erstaunlich finde ich, dass der geführte Installationsprozess (archinstall) immerhin auf 33 % kommt. Dennoch verwendet eine Mehrheit von 55 % das By-the-way Verfahren.
Eine Mehrheit von 66 % hält den Umgang mit Arch-Linux für einfach. Weniger als die Hälfte davon (29 %) halten den Umgang für moderat und nur 5 % für schwierig.
Beim Dateisystem für die Root-Partition setzen 60 % auf ext4 und 35 % auf Btrfs. Die restlichen 5 % verteilen sich auf sechs andere Dateisysteme.
Arch-User scheinen sehr zufrieden mit ihrem System zu sein. In der Fünf-Sterne-Bewertung erreicht Arch-Linux den hohen Durchschnittswert von 4.66.
Die Umfrageergebnisse halten noch mehr Auswertungen und Details bereit.
GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.
Das Invisible Internet Project (I2P) ist ein freies Softwareprojekt mit dem Ziel, ein anonymes bzw. pseudonymes und dezentrales Netzwerk zu schaffen.
Ähnlich wie TOR baut I2P ein Darknet auf, welches parallel zum normalen Internet existiert.
Die Kommunikation bei I2P ist an beiden Enden vollständig verschlüsselt. Jedes Datenpaket durchläuft dabei vier separate Verschlüsselungsschichten. Die verschlüsselten Daten werden über eine Vielzahl von I2P-Routern auf anderen Rechnern geleitet, bevor sie schließlich den Zielrechner erreichen. Dieses Prinzip der anonymen Weiterleitung führt dazu, dass sowohl die Datenrate als auch die Latenz im Vergleich zum normalen Internet reduziert sind. Dieser Geschwindigkeitsverlust ist jedoch der notwendige “Preis” für die deutlich erhöhte Anonymität.
Implementationen
Stand 2025 stehen zwei Implementationen von I2P zur Verfügung:
i2prouter (Java suite, Standard) - benutzerfreundliche und interaktive Web-Benutzeroberfläche, welche viele Funktionen beinhaltet (z.B. E-Mail-Client, Torrent-Client, Webserver).
i2pd (C++, Alternative) - benötigt kein Java und kommt mit weniger Systemressourcen aus, ist dafür aber auch “nur” ein nackter Router.
i2prouter
Die Standardimplementation benötigt ein Java-Runtime-Environmnent, genauer gesagt läuft sie nur mit openjdk, nicht aber mit openjdk/jre
Unter Archlinux erfolgt die Installation per:
yay-S i2p-bin jdk-openjdk
Anschließend kann noch sichergestellt werden, dass die korrekte Java-Version verwendet wird:
archlinux-java statusarchlinux-java set JAVAVERSION
Nach der Installation kann der Router per systemd gestartet werden.
Ist der Service gestartet, steht das Webinterface unter http://127.0.0.1:7657 bereit und führt euch durch die ersten Schritte. Ihr könnt die Standardeinstellungen so belassen und einfach immer auf “Weiter” klicken. Alle Einstellungen können später wieder geändert werden. Habt ihr euch durchgeklickt, begrüßt euch die Startseite eures I2P Routers.
I2P Webinterface
i2pd
Der I2P Daemon (i2pd) ist eine alternative Implementation, die ohne Java auskommt. Bei dieser Variante müssen alle Dienste (E-Mail, Torrent, Webserver) “von Hand” eingerichtet werden. Ich persönlich nutze diese Version auf Servern, um Transitknotenpunkte für das I2P-Netzwerk bereitzustellen.
Die Installation erfolgt unter Archlinux per
sudo pacman -S i2pd
und der Router kann ebenfalls per systemd gesteuert werden
Ist der Service gestartet, steht unter http://127.0.0.1:7070 eine Willkommensseite bereit. Ebenso ist ein Proxy für das Surfen im I2P-Darknet implementiert, der Anfragen über http://127.0.0.1:4444 entgegennimmt (siehe unten).
i2p Webseiten (eepsites)
Ähnlich wie bei TOR können im I2P-Netz hidden services eingerichtet werden. Webseiten heissen in I2P eepsites und haben die Topleveldomain *.i2p.
Um eine solche Seite ansurfen zu können, müssen 2 Aufgaben erfüllt sein:
Wir benötigen einen Browser, der den Proxydienst des I2P-Routers für Webanfragen benutzt. Bei beiden Implementationen (i2prouter und i2pd) lauscht dieser Proxy auf Port http://127.0.0.1:4444. Grundsätzlich empfiehlt es sich, für die Nutzung von I2P einen eigenen Browser zu benutzen. Zumindest solltet ihr ein eigenes Browserprofil für I2P verwenden. Hierbei ist die Firefox-Extension Zero Omega Switch empfehlenswert. Ist diese installiert, kann ihr “Auto-Switch” so eingestellt werden, dass nur Anfragen an *.i2p-URLs an den Proxy weitergereicht werden. So können “normales” Web und I2P Darknet nebeneinander genutzt werden.
Hierfür lege ich mir in den Einstellungen der Extension ein Profil “i2p proxy” an, welches auf Port 4444 verweist…
… unter “Auto switch” wähle ich “Host wildcard” und trage das Pattern *.i2p ein. Dieses zeigt dann auf mein Profil “i2p proxy”.
URLs mit der Endung *.i2p werden an den Proxy weitergeleitet
Wichtig
Damit der Auto-Switch funktioniert, sollte in der Adresszeile des Browsers nach dem *.i2p ein Slash verwendet werden, z.B. http://planet.i2p/.
Wir benötigen die “richtige” Adresse der Webseite. Das I2P-Netz ist dezentral organisiert. Das bedeutet, dass jede Installation ihr eigenes DNS-Adressbuch aufbauen muss. Die meisten *.i2p-Webseiten sind daher nach einer frischen Installation noch gar nicht erreichbar, weil der Router nicht weiss, welche “echte” Adresse sich hinter dem Namen verbirgt. Eine typische I2P-Adresse lautet
Solche Adressen sind jedoch viel zu lang und unpraktisch. Daher wird ein Hashwert aus der Adresse generiert, über den die Seite einfacher aufgerufen werden kann – die sogenannte b32-Adresse. Im obigen Beispiel lautet die entsprechende b32-Hash-Adresse:
Dies ist schon eher handlebar und ähnelt den *.onion-Adressen des TOR-Netzes. Wenn ihr diese Adresse in euren Browser eingebt, könnt ihr die Seite direkt ansurfen. Schöner wäre natürlich, wenn die Seite über eine “menschenlesbare” Adresse erreichbar wäre, z.B. http://notbob.i2p/. Um dies zu erreichen, muss ein lokaler DNS-Eintrag im Adressbuch des eigenen I2P-Routers erfolgen. Hierfür stehen im I2P-Netz so genannte “Helperlinks” zur Verfügung, die das Eintragen vereinfachen. Um die URL notbob.i2p mit der Adresse nytzrhrjjfsutowojvxi7hphesskpqqr65wpistz6wa7cpajhp7a.b32.i2p zu verknüpfen, könnt ihr einfach diesem Link folgen:
Das Router-Adressbuch ist eine automatisch verwaltete Liste, die von eurem I2P-Router gepflegt wird. Hier solltet ihr nichts von Hand ändern. Es gibt Dienste im I2P-Netz, welche “fertige” Adressbucheinträge verteilen. Hat man solche Dienste aboniert, füllt sich das eigene Router Adressbuch mit Adressen und Links, die von den Diensten verteilt werden. Ihr könnt eure Abos unter dem Link http://127.0.0.1:7657/susidns/subscriptions einsehen und erweitern. Folgende Einträge solltet ihr dort ergänzen, um die bekanntesten eesites erreichen zu können:
Wenn ihr auf “Speichern” geklickt habt, könnt ihr sehen, wie sich euer Router Adressbuch nach und nach mit Einträgen füllt. Jetzt solltet ihr z.B. diese eesites erreichen können:
Solltet ihr - woher auch immer - eine neue b32-Adresse erhalten haben, könnt ihr mittels Helper-Link (oder auch “von Hand”) einen neuen Eintrag in eurem lokalen Adressbuch erzeugen. Die Einträge im lokalen Adressbuch stellen euer persönliches Verzeichnis dar und werden nicht an andere I2P-Router weitergegeben.
privates Adressbuch
Das private Adressbuch speichert sensiblere Adressen, die ihr getrennt von eurem lokalen Adressbuch speichern wollt. Es wird genutzt, um hochsensible Ziele oder Dienste zu speichern, die ihr nicht versehentlich teilen möchtet. Einträge im privaten Adressbuch werden weder verteilt noch sind sie von anderen I2P-Komponenten zugänglich.
E-Mail
Unter dem Link http://127.0.0.1:7657/webmail ist der Mail-Client SusiMail erreichbar. In I2P lauten die Standardmailadressen USERNAME@mail.i2p. Ihr könnt euch beliebig viele Mailadressen kostenlos anlegen. Klickt dafür auf “Konto anlegen” oder folgt dem Link http://hq.postman.i2p/?page_id=16. Die Adresse von postman.i2p ist bereits im Router-Adressbuch gespeichert, sofern ihr die oben genannten Dienst abonniert habt.
Torrent
Mit I2Psnark steht euch unter http://127.0.0.1:7657/torrents ein Torrent-Client zur Verfügung. Das Datenverzeichnis liegt standardmäßig unter /opt/i2p/.i2p/i2psnark/. Wenn ihr in dieses Verzeichnis eine Torrentdatei ablegt, wird sie automatisch dem Client hinzugefügt. Natürlich geht das auch über das Webinterface.
Der bekannteste Tracker ist unter https://tracker2.postman.i2p/ erreichbar. Die Seite steht dauerhaft unter “heavy use”, weshalb es sein kann, dass ihr zwei bis drei Anläufe nehmen müsst, um draufzukommen. Dies gilt generell für alle eesites: wenn sie mal nicht erreichbar ist, wartet einfach 60 Sekunden und versucht es erneut. Dabei wird ein neuer Verbindungstunnel aufgebaut, und die Seiten sind dann meist erreichbar.
Ich habe bei mir noch die Bandbreit für die Torrents angepasst. Klickt hierfür auf der Torrentseite unten auf “Konfiguration”. Meine Bandbreite für Uploads habe ich auf 2048, und für Downloads auf 4096 Kbps gestellt.
Das I2P-Netz ist eher langsam, so dass es eine Zeit dauert, bis größere Torrents vollständig sind, aber: steter Tropfen höhlt den Stein.
eigenen Torrent erstellen
Ich habe es nicht geschafft, einen eigenen Torrent über das Webinterface zu erzeugen. Daher habe ich auf mktorrent zurückgegriffen. So konnte ich eine Torrentdatei für mein R-Buch anlegen.
Im Webinterface sehe ich nun, dass der Torrent erfolgreich hinzugefügt wurde.
Sobald ich auf den Startknopf (siehe roter Pfeil) klicke, beginnt die Verteilung an alle Interessierten. Das Webinterface meldet ebenfalls, dass der Torrent gestartet wurde.
Torrent ist gestartet
Über das blaue Ausrufezeichen kann ich mir den Torrent genauer anschauen. Hier finde ich auch den Magnet-Link, den ich verteilen kann. Jeder, der diesen Link seinem I2P-Torrent hinzufügt, kann die Datei herunterladen.
Ebenfalls enthalten ist der Webserver Jetty, mit welchem ihr eure eigene eesite bereitstellen könnt. Am besten eigenen sich hierfür statische Seiten, die z.B. mittels HUGO gebaut wurden.
Legt zunächst eure HTML-Dateien samt Zubehör in den Ordner /opt/i2p/.i2p/eepsite/docroot/.
Im Webinterface findet ihr den Eintrag “Versteckte Dienst verwalten” unter http://127.0.0.1:7657/i2ptunnelmgr. Dort seht ihr unter “I2P Versteckte Services” den Eintrag “I2P webserver”. Klickt darauf, um die grundlegenen Informationen eurer eesite anzugeben. Bei mir sieht das so aus:
Meine eesite
Jetzt muss der Webserver an zwei Stellen aktiviert werden. Geht zunächst nach http://127.0.0.1:7657/config und wählt dort den Reiter “Teilnehmer”.
Reiter “Teilnehmer” (links)
Hier muss der Startknopf gedrückt werden. Optional könnt ihr den Haken setzen, so dass der Server beim Neustart automatisch mitgestartet wird.
Nun läuft der Webserver Jetty, aber der I2P-Tunnel zum Webserver ist noch nicht aktiviert. Klickt hierfür wieder auf http://127.0.0.1:7657/i2ptunnelmgr und dort auf den Start-Knopf.
Tunnel per Startknopf starten
Der Status sollte nun von rot auf grün welchseln.
Ebenfalls wurde ein Helperlink erzeugt, der nun fleissig weiterverteilt werden kann. Bei mir lautet der klassische I2P-DNS-Dreisatz: http://produnis.i2p/ (b32) (Helper)
Speichert mich gerne in euer lokales Adressbuch :-)
Helperlink ins Adressbuch speichern
Ich wünsche euch viel Spaß beim Ausprobieren und Herumexperimentieren. Eine echt coole Seite ist übrigens http://i2puzzle.i2p/ (helper), falls ihr gerne Rätsel löst…
Wahnsinn, wie schnell die Zeit vergeht: Mein Blog Zockertown.de ist tatsächlich 20 Jahre alt geworden! Am Donnerstag, den 13. Januar 2005 um 21:01 Uhr ging der allererste Artikel online. Damals hätte ich nie gedacht, dass ich zwei Jahrzehnte später immer noch hier sitzen würde, um euch an meinen Gedanken, Spielen und Erlebnissen teilhaben zu lassen.
Inzwischen sind 1626 Artikel zusammengekommen – von spontanen Ideen bis zu aufwendigeren Beiträgen. Der letzte offizielle Eintrag stammt übrigens vom Samstag, 23. November 2024 um 11:11 Uhr. Nicht immer habe ich ganz pünktlich zum Geburtstag einen Artikel verfasst, aber alle paar Jahre packt mich dann doch die Nostalgie, und ich schreibe einen kleinen Rückblick.
Viel Spaß, den ich an Spielen und am Schreiben hatte.
Eine Menge Erinnerungen, die in den ganzen Artikeln weiterleben.
Das Gefühl, eine kleine “Online-Heimat” geschaffen zu haben, zu der ich immer wieder gern zurückkehre.
Ich danke allen, die hier vorbeischauen, Kommentare dalassen oder einfach still mitlesen. Auf die nächsten Jahre voller neuer Games, Ideen und Texte – und vor allem auf viele weitere Momente, in denen wir zusammen zocken und darüber schreiben können!
Mit Firefox 134.0.1 behebt Mozilla einen sogenannten Speicher-Leak, der sich zuletzt für einige Nutzer vor allem auf Google-Diensten wie YouTube und Google Docs in Form von Performance-Problemen bemerkbar machte.
Eine mögliche Absturzursache wurde behoben, welche für manche Nutzer nach dem letzten Firefox-Update den Start des Browsers verhindern konnte.
Außerdem wurde ein Problem behoben, welches für Nutzer, die das gleiche Profil mit unterschiedlichen Firefox-Versionen nutzen (was keine offiziell unterstützte Konfiguration ist), verursachen konnte, dass Suchmaschinen und Kontextmenüs nicht mehr korrekt funktionierten.
Wer sein /e/OS-Smartphone auf Android 14 upgraden möchte, sollte darauf achten, ob es sich um ein Community- oder ein Official-Gerät handelt. Im ersten Fall steht Arbeit an.
Verwendet hier jemand Murenas /e/OS-Distribution für Android-Smartphones? Dann gilt es jetzt aufzupassen. Wie die e-Foundation am 9. Januar mitgeteilt hat, wird /e/OS von AOSP 13 auf AOSP 14 aktualisiert. AOSP ist die Abkürzung für das Android Open Source Project, die quelloffene Basis von Googles Android.
Die meisten alternativen Smartphone-Betriebssysteme basieren auf AOSP und modifizieren diese Basis, um den Anwender:innen ein alltagstaugliches Erlebnis Arbeiten auf ihren Android-Gerät zu ermöglichen. /e/OS basiert nicht direkt auf AOSP, sondern bedient sich der Vorarbeit von LineageOS, um möglichst viele Geräte unterstützen zu können. Wer /e/OS bisher nicht kennt, findet hier die wesentlichen Information.
Android-Versionen
Die neueste produktive Android-Version ist Version 15, die am 3. September 2024 erschienen ist
Seit dem 31. Dezember 2024 basiert LineageOS ebenfalls auf AOSP Version 15
Die Derivate hängen immer mindestens eine Version hinterher, so auch /e/OS
Wenn ihr auf das Datum der letzten Version von LineageOS schaut, könnt ihr euch vorstellen, dass diese Geräte mehrheitlich mit älteren Version (14, 13) laufen. Deshalb ist es verständlich, dass /e/OS erst jetzt den Schritt von AOSP 13 auf 14 macht.
Herausforderungen bei Murena, e-Foundation und /e/OS
Drei Namen in der Überschrift? Gaël Duval verwendet verschiedene Namen:
Die Murena Retail SAS sitzt in Paris und kümmert sich um den Vertrieb der Smartphones
Die e-Foundation ist eine gemeinnützige Organisation nach französischem Vereinsgesetz
Die e-Foundation entwickelt die entgoogelte Android-Distro /e/OS
Neben den Geräten und der AOSP-Distribution liefert die e-Foundation auch einen Cloud-Dienst. In dessen Genuss gelangen alle Kunden, die bei Murena ein Telefon kaufen. Bei diesem Cloud-Dienst handelt es sich um eine Implementierung von Nextcloud für alle Murena- aka e-Foundation-Kunden.
Anfang Oktober 2024 gab es bei der Infrastruktur von Murena ein groben Ausfall. Wer sich für die Details interessiert, findet hier den Verlauf. Betroffen waren alle Dienste der Murena-Cloud sowie die /e/OS-Update-Dienste und der Software-Store AppLounge - also fast alles. Zur Begründung schrieb Gael Duval im Forum der e-Foundation:
Der Grund für diesen Ausfall liegt in unserer Speicherinfrastruktur, die in die Jahre gekommen ist, während die Zahl der 1,8k aktiven Nutzer von murena.io in den letzten zwei Jahren stark gewachsen ist. Eine Weiterentwicklung und Konsolidierung der Infrastruktur war geplant, aber letzte Woche verlor unsere aktuelle Infrastruktur einige Speicherknoten und wechselte in einen einen degradierten Modus. Leider hatten wir gestern ein weiteres Problem, das uns dazu zwang die Infrastruktur in den Wartungsmodus zu versetzen, bis sie vollständig wiederhergestellt ist.
Soweit ich das verfolgen konnte, haben manche Anwender:innen Daten in Murenas Cloud (sie nennen es Workspace; es ist Nextcloud) verloren. Ich selbst war nicht davon betroffen, weil ich meine Nextcloud selbst hoste. In den vergangenen 4 Monaten wurden die Dienste nach und nach wieder bereitgestellt. Dennoch gibt es beim Installieren und Aktualisieren von Apps aus dem Google Play Store noch Probleme:
Wir empfehlen, vorerst KEINE Google-Apps auf /e/OS zu aktualisieren. Deaktivieren Sie die automatischen Aktualisierungen in App Lounge, wenn Sie Google-Apps verwenden, und aktualisieren Sie die Apps einzeln. Neu aktualisierte Google-Apps haben eine Signatur-Inkompatibilität, die verhindert, dass sie funktionieren. Das Team arbeitet daran, eine Lösung zu finden. Wir werden Sie auf dem Laufenden halten.
Insbesondere für Einsteiger:innen ist das Angebot verlockend, mit einem entgoogelten Smartphone gleich noch eine Cloud-Lösung (Murena Workspace) mitgeliefert zu bekommen. Am obigen Beispiel seht ihr, was passieren kann, wenn ihr die Kontrolle über eure Daten an andere abgebt. Deshalb gilt: hostet eure Cloud in einer Umgebung, der ihr vertraut und die ihr kontrolliert.
Das 14er-Upgrade
Beim Upgrade auf Android 14 kommt es darauf an, ob ihr ein Community- oder Official-Gerät habt. Fall ihr das nicht wisst, lohnt sich ein Blick auf die Geräteliste. Dort werden die 217 unterstützten Smartphones aufgeführt. In der dritten Spalte (/e/OS-Version) steht entweder 'Official' oder 'Community'. Falls ihr ein Official-Gerät habt, müsst ihr nichts tun. Das Upgrade auf Android 14 wird demnächst automatisch auf dem Gerät (OTA: over the air) installiert. Bei den Community-Geräten müsst ihr selbst Hand anlegen. Murena schreibt dazu:
Wir möchten Sie über ein wichtiges Update für etwa 100 Community-Geräte informieren. Beginnend mit dem /e/OS 2.6.3-Build werden diese Geräte AOSP 14 (U) Unterstützung erhalten. Die Liste der aktualisierten Geräte finden Sie in den /e/OS 2.6.3 (U) Release Notes. In der Zwischenzeit werden wir weiterhin die Geräte mit /e/OS- AOSP 13 (T) durch OTA-Updates für mehrere Monate unterstützen, um Ihnen die Möglichkeit zu geben, manuell auf /e/OS basierend auf AOSP 14 zu aktualisieren.
Was heisst das?
OTA-Updates auf AOSP 13 für diese Geräte werden noch mehrere Monate lang zur Verfügung stehen.
Es wird kein OTA-Upgrade von AOSP 13 auf AOSP 14 zur Verfügung gestellt, sodass die Nutzer manuell auf /e/OS-AOSP 14 aktualisieren oder neu installieren müssen.
Die Nutzer werden keine automatischen Benachrichtigungen über diese Änderung erhalten (wir arbeiten daran, diese Funktion in naher Zukunft hinzuzufügen).
Geräte, für die es kein AOSP 14-Build gibt, behalten die Unterstützung für AOSP 13.
In der Geräteliste findet ihr in der fünften Spalte Installationsanleitungen für jedes unterstützte Smartphone. Wenn euer Gerät sowohl als "Official", als auch als "Community" aufgeführt ist, gilt Folgendes:
Wenn du die offizielle Version hast, dann ist es besser, auf das OTA-Upgrade zu warten
Wenn du eine Community-Version hast, dann aktualisierst du manuell auf AOSP 14
GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.
Die MZLA Technologies Corporation hat mit Thunderbird 128.6 ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht.
Neuerungen von Thunderbird 128.6
Mit dem Update auf Thunderbird 128.6 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht. Das Update bringt wie immer diverse Fehlerbehebungen und Verbesserungen unter der Haube, welche sich in den Release Notes (engl.) nachlesen lassen. Auch wurden diverse Sicherheitslücken geschlossen.
Mozilla hat Firefox 134 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.
Für Nutzer in den USA und Kanada wird schrittweise ein angepasstes Layout für die Startseite ausgerollt, welches bis zu vier statt drei Content-Empfehlungen pro Zeile erlaubt und die Positionierung von Logo und Wetter-Widget so anpasst, dass die Suchleiste, Verknüpfungen und Content-Empfehlungen weiter oben erscheinen.
Firefox View sowie die Sidebar für synchronisierte Tabs zeigen nicht mehr nur maximal 50 Tabs von anderen Geräten an, sondern bis zu 5.000.
Firefox folgt nun stärker der HTML-Spezifikation, was die vorübergehende Benutzeraktivierung betrifft. Durch diese Änderung wird die Blockierung von Popups in Fällen, in denen frühere Firefox-Versionen zu aggressiv waren, weniger streng gehandhabt, wodurch fehlerhafte Blockierungsaufforderungen reduziert werden.
Unter Linux werden jetzt Touchpad-Haltegesten unterstützt. Das bedeutet, dass der kinetische Bildlauf unterbrochen werden kann, indem zwei Finger auf das Touchpad gelegt werden.
Bei Verwendung eines Convertible-Gerätes mit Windows 11 passt Firefox automatisch die Oberflächengröße beim Wechsel zwischen Laptop- und Tablet-Modus an, wenn die Touch-Oberfläche für die Tablet-Nutzung aktiviert ist.
Ein Problem mit der Übersetzungsfunktion wurde behoben, welches verursachen konnte, dass manche Inhalte nicht angezeigt worden sind, wenn die automatische Übersetzung aktiviert ist. Außerdem wurde ein Problem der Übersetzungsfunktion in Zusammenhang mit select-Feldern behoben.
Das Erweiterungs-Menü unterstützt die Anzeige von Warnmeldungen für „Soft Blocks“, also Erweiterungen, welche von Mozilla zum Beispiel aus Gründen der Stabilität aus der Ferne deaktiviert worden sind, aber vom Nutzer wieder aktiviert werden können.
Mit browser.tabs.insertAfterCurrentExceptPinned wird eine neue Option in about:config bereitgestellt, um zu beeinflussen, wo Links, die aus angepinnten Tabs heraus geöffnet werden, angezeigt werden. Standardmäßig öffnen diese am Anfang der Tableiste. Nach Setzen des Schalters auf true öffnen diese am Ende der Tableiste.
Die Leseansicht respektiert jetzt die in den Schriftarten-Einstellungen hinterlegten Schriften für Serif, Sans Serif und Feste Breite.
Die Performance der Quelltext-Ansicht wurde verbessert.
Das Problem auf macOS Sonoma und höher wurde behoben, dass neben dem Öffnen des Emoji-Wählers auch der Buchstabe „e“ in ein Textfeld eingefügt wurde, wenn die Tastenkombination Fn + e gedrückt wurde. Ebenfalls kann der Emoji-Wähler über die Tastenkombination Ctrl + Cmd + Leertaste geöffnet werden. Dabei hatte sich dieser, ebenfalls seit macOS Sonoma, sofort wieder geschlossen. Auch das Problem wurde behoben.
Für den Zugriff auf lokale Adressen ist seit macOS Sequoia eine neue Berechtigung auf Systemebene erforderlich. Die in diesem Fall von Firefox gezeigte Fehlerseite zeigt jetzt einen entsprechenden Hinweis an.
Ebenfalls macOS betrifft eine Änderung bei der Schriftglättung, deren Ergebnis nun mehr dem von Safari entsprechen sollte.
Die Unterstützung für das Debuggen von Erweiterungen wurde verbessert, unter anderem durch ein automatisches Nachladen des Quellcodes der Erweiterung im Debugger, wenn die Erweiterung neu geladen wird.
Das Netzwerk-Panel der Entwicklerwerkzeugezeigt Informationen über Early Hints an, einschließlich einer speziellen Anzeige für den 103 HTTP-Statuscode in der Benutzeroberfläche an.
Mehr Sicherheit für Firefox-Nutzer
Auch in Firefox 134 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 134 daher für alle Nutzer dringend empfohlen.
Die Content-Sandbox unter Windows wurde um eine weitere Stufe auf Level 8 erhöht.
Verbesserungen der Webplattform
Firefox 134 unterstützt den Video-Codec HEVC. Allerdings bisher nur auf Windows und bei Verwendung eines Gerätes mit Unterstützung für diesen Codec.
Die CSS-Eigenschaften align-self und justify-self sowie die CSS-Shortendeigenschaft place-self werden jetzt für absolut positionierte Elemente unterstützt.
WebRTC-Simulcast von gemeinsam genutztem Video mit dem VP8-Codec wird jetzt unterstützt. Von anderen Videoquellen war dies bereits möglich.
Dies war nur eine kleine Auswahl der Verbesserungen der Webplattform. Eine vollständige Auflistung lassen sich in den MDN Web Docs nachlesen.
Feature-Vorschau
SmartBlock-Platzhalter für Instagram- und TikTok-Content
Durch Setzen von extensions.webcompat.smartblockEmbeds.enabled auf true können auf Websites eingebettete Instagram- sowie TikTok-Inhalte durch einen Platzhalter ersetzt werden. Als weitere Voraussetzung muss hierfür der Schutz vor Aktivitätenverfolgung in den Datenschutz-Einstellungen auf die strenge Stufe geschaltet sein. Erst nach einem Klick auf einen Button wird dann der tatsächliche Inhalt dann geladen. In Zukunft soll diese Funktion auch für weitere Einbettungen zur Verfügung stehen.
Entladen von Tabs
Wird über about:config der Schalter browser.tabs.unloadTabInContextMenu per Doppelklick auf true gesetzt, steht im Kontextmenü der Tabs eine neue Option zur Verfügung, um den jeweiligen Tab zu entladen und damit Ressourcen freizugeben.
Diese Distribution möchte mit Geschwindigkeit und Sicherheit punkten. Ich habe sie installiert und für euch kurz getestet.
In letzter Zeit hört man viel von der Distribution CachyOS. Grund genug, um diese Distribution in einer virtuellen Maschine auszuprobieren. Doch bevor ich meine Erfahrungen schildere, stellt sich die Frage, was es mit CachyOS auf sich hat.
CachyOS ist eine Linux-Distribution, die auf Arch Linux basiert. Sie konzentriert sich auf Geschwindigkeits- und Sicherheitsoptimierungen - der Standard-Linux-Kernel ist mit dem BORE-Scheduler (Burst-Oriented Response Enhancer) stark optimiert, während die Desktop-Pakete mit LTO, x86-64-v3 und x86-64-v4, Zen-4-Optimierung, Sicherheitsflags und Leistungsverbesserungen kompiliert sind. Zu den verfügbaren Desktop-Umgebungen und Fenstermanagern gehören KDE, GNOME, Xfce, i3wm, Wayfire, LXQt, OpenBox, Cinnamon, UKUI, LXDE, MATE, Budgie, Qtile, Hyprland und Sway. CachyOS wird sowohl mit grafischen als auch mit Kommandozeilen-Installationsprogrammen ausgeliefert und bietet einen Firefox-basierten Browser (genannt Cachy-Browser) mit einigen Sicherheitsverbesserungen und Leistungsoptimierungen.
Das Team hinter CachyOS besteht aus 12 Personen, die hier vorgestellt werden. CachyOS wird als deutsche Distribution beschrieben, was wohl auf den Gründer Peter Jung zurückzuführen ist.
Die CachyOS Handheld Edition bietet ein GameMode-ähnliches Erlebnis und kommt mit vorinstallierten Gaming-Tools. Es unterstützt offiziell das Rog Ally, Steam Deck OLED und LCD, Legion GO.
Obwohl die Distro mit vielen (fast allen) Desktop-Umgebungen angepriesen wird, heisst es bei der Desktop-Edition:
Erweitern Sie Ihre Möglichkeiten mit KDE Plasma - Surfen Sie im Internet, bleiben Sie mit Freunden und Familie in Verbindung, verwalten Sie Dateien, genießen Sie Multimedia und arbeiten Sie effizient in einer visuell beeindruckenden Umgebung, die sich an Ihre Bedürfnisse anpasst. Erleben Sie die zusätzlichen Vorteile der Verwendung der besten freien und Open-Source-Software mit dem Schwerpunkt auf Sicherheit, Datenschutz und Seelenfrieden.
Ja wie, KDE-Plasma? Was ist mit den anderen Desktop-Umgebungen? Hm, vielleicht gibt es eine Auswahl während des Installationsprozesses (so wie man es von Arch-Linux kennt). Die 2,7 GB grosse ISO-Datei ist schnell heruntergeladen. Ich teste die Installation in GNOME-Boxes unter Manjaro.
Die Installation
Nach dem Start der ISO-Datei in der VM wird man von diesem Bootmenü empfangen:
Als Default ist der erste Menüpunkt ausgewählt, den ich nicht ändere. Danach laufen eine Weile lang die Boot-Meldungen über den Bildschirm. Anschliessend wird KDE-Plasma hochgefahren und man wird von dieser Willkommens-Anwendung begrüsst (die Sprache habe ich dort auf Deutsch umgestellt):
Bisher habe ich nichts zu meckern; alles gut und einfach. Man könnte sich allenfalls fragen, warum KDE-Plasma verwendet wird, obwohl ich doch eine andere Desktop-Umgebung haben möchte. Jetzt wird es spannend; ich starte die eigentliche Installation. Es startet der Installations-Assistent, der auf Calamares beruht:
Beim Partitionieren des Speichermediums ist btrfs als Vorgabe ausgewählt. Zur Wahl stehen weitere Dateisysteme: xfs, etx4, f2fs und zfs. Ich belasse es bei der Vorgabe. Ah, dann kommt sie, die Auswahl der Desktop-Umgebung:
Wahnsinn, es werden sage und schreibe 18 Desktop-Umgebungen angeboten. Eine solche Auswahl habe ich bisher noch in keinem Installationsprogramm gesehen. Selbstverständlich wird eine Vorschau der einzelnen DEs geboten. Ich war kurz davor, Cosmic als DE auszuwählen, habe mich dann aber für GNOME entschieden. Erstens, weil ich GNOME kenne und zweitens, weil Cosmic noch nicht fertig ist.
Im nächsten Schritt kann man Pakete auswählen:
Diese Option erzeugt bei mir ein wenig Stirnrunzeln. Warum werden die Desktops hier erneut angeboten, obwohl ich mich bereits für GNOME entschieden habe? Nun gut, es gibt auch weitere Auswahlen, die nichts mit dem Desktop zu tun haben. Ich ändere nichts an den Voreinstellungen.
Der weitere Verlauf der Installation ist unspektakulär und bietet die gewohnten Abfragen. Während der eigentlichen Installation wird eine Slideshow gezeigt, die über die Besonderheiten von CachyOS informiert: Kernel, Desktop-Umgebungen, CachyOS-Browser, usw. Die Installation dauert ziemlich lange und scheint bei 37 % der zu installierenden Pakete festzustecken. Das mag an der VM liegen; ich warte noch ein paar Minuten ab. Zeit vergeht. Obwohl die Slideshow noch läuft, ändert sich nichts am Fortschritt. Ich breche dann mal ab und versuche es erneut.
Eine halbe Stunde später:
Ich war zu ungeduldig. Bei meinem zweiten Versuch hat die Installation einwandfrei funktioniert. Sie wäre auch beim ersten Versuch gelungen, hätte ich nur lange genug gewartet. Das bringt dem Installationsprozess dennoch einen Kritikpunkt ein: Die Fortschrittsanzeige während der Installation ist nicht granular genug. Da fragt man sich des Öfteren, ob der Prozess jetzt eingefroren ist, oder nicht.
Bewertung: 9 von 10 Punkten
Die Installation ist kinderleicht und von jederfrau und jedermann problemlos zu bewerkstelligen. So macht die Installation eines Arch-basierten Systems Spass. Man wird an die Hand genommen und erhält viele Informationen während des Einrichtungsprozesses. Warum ich einen Punkt abgezogen habe, steht im letzten Absatz.
Der erste Eindruck
Nach dem Neustart begrüsst euch die Willkommens-Anwendung und eine Einführung in den GNOME-Desktop. Ein Blick ins Terminal offenbart das:
Es kommt die Fish-Shell zum Einsatz, die immer mit einer fastfetch-Ausgabe beginnt. Nette Idee; gefällt mir. Doch welche weiteren Anwendungen werden von CachyOS installiert? Ein Blick in das App-Grid zeigt es:
Da gibt es einige Anwendungen, die nicht zum GNOME-Standard gehören, als da wären:
Alacritty - ein Terminal-Emulator
btop++ - ein erweiterter System-Monitor
Btrfs-Assistant - ein Hilfsprogramm zur Verwaltung von btrfs-Partitionen
Cachy Browser - ein gehärteter Firefox-Fork
CachyOS Hello - das Willkommensprogramm
CachyOS Kernel Manager - Verwaltung der installierten Kernels
CachyOS Paket-Installationsprogramm
Meld - ein grafischer Differ
Micro - ein sehr bequemer Terminal-Editor
Vim - ein sehr unbequemer Terminal-Editor :)
Octopi - ein Paketmanager und grafischer Wrapper für pacman
Am Erscheinungsbild der GNOME-Desktop-Umgebung wurde nicht verändert. Allerdings bietet CachyOS ein paar zusätzliche Pakete, die Sinn machen (siehe oben). Eine der wichtigsten Anwendungen ist der Webbrowser. Die meisten Distributionen setzen auf Firefox. CachyOS bietet stattdessen den Fork Cachy Browser an. Das Projekt schreibt dazu:
Unser Standard-Browser, Cachy-Browser, ist ein Fork des bekannten Firefox mit zusätzlichen Sicherheitsfunktionen und optimierter Leistung. Patches des librewolf-Browsers wurden ebenfalls integriert, um das Surfen noch besser zu machen.
Der Browser sieht aus, als wäre er für KDE-Plasma designt worden. uBlock-origin ist installiert und es wird Google als Suchmaschine verwendet. Ich meine, dass der Fork eines Webbrowsers nicht zu den Aufgaben einer Distribution gehört. Mehr möchte ich dazu nicht schreiben.
Bewertung: 9 von 10 Punkten
Die Desktop-Umgebung wurde so belassen, wie sie gedacht ist. Ich nehme an, dass das für die übrigen DEs auch gilt. Das CachyOS-Team hat einige sinnvolle Werkzeuge vorinstalliert. "Batteries included" findet hier nicht statt. Die Nutzer:innen müssen selbst Hand anlegen, um eine vollständige Arbeitsumgebung zu erhalten. Das ist keine Kritik, sondern eine Feststellung. Zum Hauptargument für CachyOS, die Geschwindigkeit, kann ich nichts sagen, da die Performance in einer virtuellen Maschine darüber keine Aussage erlaubt.
Das Paketmanagement
Möchte man eine Arch-basierte Distribution bewerten, gibt es nach meiner Meinung nur zwei wesentliche Punkte: die Installation und das Paketmanagement. Bezüglich der Installation halte ich CachyOS für eine Bereicherung im Distro-Markt (siehe oben). Vom Paketmanagement bin ich enttäuscht. Was ihr hier bekommt, ist eine wilde Zusammenstellung von vier Paketverwaltungen:
pacman - die Original-Paketverwaltung von Arch-Linux
CachyOS Paket-Installationsprogramm
Octopi - erinnert mich an Synaptic für Debian-basierte Systeme
Die Paketverwaltung der Desktop-Umgebung (in diesem Fall: GNOME-Software)
Welcher Vorteil soll sich für die Anwender:innen daraus ergeben? Pacman und die DE-spezifische Paketverwaltung sind gegeben, aber warum brauche ich das CachyOS Paket-Installationsprogramm und Octopi? Das verstehe ich nicht. Als Anwender wüsste ich nicht, worauf ich mich verlassen soll. Welche Verwaltung meldet mir die anstehenden Aktualisierungen? Kommen die vier sich in die Quere? Und was ist mit den Container-Formaten? Soweit ich das beurteilen kann, kümmert sich nur GNOME-Software um Flatpaks.
Bewertung: 4 von 10 Punkten
Wenn es um die Paketverwaltung geht, bedeutet mehr nicht besser. Im Gegenteil bin ich froh, wenn sich nur eine Anwendung um die Bereitstellung, Notifikation, Installation und Abhängigkeitsregelung kümmert.
Fazit
CachyOS möchte mit Geschwindigkeits- und Sicherheitsoptimierungen punkten. Diese wichtigen Argumente konnte ich leider nicht testen, da ich in einer virtuellen Maschine unterwegs war. Tatsächlich punktet diese Distribution mit einem einsteigerfreundlichen Installationsprozess und vielen Desktop-Umgebungen. Die Auswahl an vorinstallierter Software richtet sich eher an Fortgeschrittene als an Einsteiger:innen. Anfänger:innen möchten die Batterien mitgeliefert bekommen. Da soll eine sinnvolle Auswahl an Anwendungen installiert sein. Die Profis schätzen die minimalen Default-Programme, weil sie selbst wissen, welche Büro-Suite usw. sie benutzen möchten.
Für wen eignet sich CachyOS? Wer ein Rolling-Release-Modell bevorzugt und mit möglichen Problemen umzugehen weiss, kann auf eine Arch-basierte Distribution setzen. Falls euch dann auch noch eine kinderleichte Installation und eine leichtgewichtige Vorauswahl an installierten Anwendungen wichtig ist, wird mit CachyOS gut bedient. Das Hauptargument für diese Distro sind jedoch die Optimierungen im Kernel- und Sicherheits-Bereich.
Zum Schluss ein paar ehrliche Worte: Wenn ihr Arch wollt, dann nehmt Arch! Arch-Linux gehört mit zu den performantesten Distributionen, die es gibt. Ich schätze, dass die Leistungsoptimierungen von CachyOS in eurem Leben kaum eine Rolle spielen werden. Die Installation von Arch-Linux ist mittlerweile genauso leicht wie mit einem grafischen Installer, dank des neuen archinstall. Hier findet ihr eine Artikel-Serie, die noch das alte archinstall verwendet.
GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.
Nutzer veralteter Firefox-Versionen müssen damit rechnen, ab März 2025 keine Add-ons und geschützten Inhalte auf Streaming-Plattformen mehr nutzen zu können.
Am 14. März 2025 verliert ein Stammzertifikat seine Gültigkeit, welches zur Verifizierung signierter Inhalte genutzt wird. Aus diesem Grund ist es wichtig, dass der Browser bis dahin in einer Version genutzt wird, welche das neue Stammzertifikat beinhaltet. Wer nach diesem Datum nicht Firefox 128 oder höher respektive Firefox ESR 115.13 oder höher nutzt, muss mit erheblichen Einschränkungen rechnen. Betroffen sind Firefox für Windows, macOS, Linux sowie Android. Lediglich Firefox für iOS ist hiervon nicht betroffen, da Mozilla auf iOS von der Apple-Plattform abhängig ist.
Ab dem 14. März 2025 werden für Nutzer älterer Firefox-Versionen keine Erweiterungen mehr ausgeführt. Dies betrifft nicht nur neu installierte Erweiterungen. Bereits installierte Erweiterungen werden automatisch deaktiviert. Ebenfalls kann es auf Streaming-Plattformen in Folge ausbleibender Updates für das DRM-Modul nach diesem Datum jederzeit dazu kommen, dass keine Wiedergabe mehr möglich ist. Auch andere auf Remote-Updates angewiesene Funktionen können nach diesem Datum eingeschränkt sein.
Gestern wurde Version 25.01 des modalen Editors Helix veröffentlicht. Da die vorherige Version im Juli 2024 veröffentlicht wurde und weil die Entwickler ziemlich fleißig waren, gibt es mit Version 25.01 viele Änderungen, Neuerungen und Verbesserungen.
Die Entwickler haben in einem Artikel die Highlights zusammengefasst. Das wesentlich umfangreichere Changelog lässt sich bei Github abrufen.
Da die Entwickler von Helix relativ selten neue offizielle Versionen veröffentlichen, verwende ich aktuell selbst die Git-Version. Somit konnte ich die diversen Neuerungen usw. bereit schon seit einiger Zeit nutzen. Bei den Funktionen, die ich nutze, konnte ich keine Probleme feststellen.
Wer sich für einen modalen Editor interessiert, aber mit vim / Neovim nicht warm wird, sollte sich Helix zumindest einmal ansehen. Denn Helix funktioniert bewusst in vielen Dingen anders. Ich verweise hierzu einfach mal auf einen Artikel den ich 2023 geschrieben habe.
Helix hat aber auch, verglichen mit beispielsweise Neovim, weiterhin Nachteile. Je nachdem welche Anforderungen der Nutzer hat. So gibt es weiterhin kein Plugin-System. Was mich persönlich aber nicht stört.