staging.inyokaproject.org

2026 Woche 19

10. Mai 2026

Neue Feature-Updates von Firefox erscheinen üblicherweise alle vier Wochen. Mindestens ein Korrektur-Update pro Firefox-Version ist fest eingeplant. Ab Firefox 151 werden Korrektur-Updates im Abstand von jeweils einer Woche erscheinen.

Zwischen zwei Funktions-Updates von Firefox liegen in der Regel exakt vier Wochen. Dass es dazwischen mindestens ein Update geben wird, um kleinere Probleme zu beheben, ist fest eingeplant. Dieses erscheint normalerweise nach zwei Wochen. Bei Bedarf kann es auch schon früher sein, ebenso wie zusätzliche Updates möglich sind.

Beginnend mit Firefox 151 wird Mozilla in jeder Woche, in der kein neues Feature-Update erscheint, ein Update veröffentlichen, um Probleme aus der Welt zu schaffen. Mozilla nennt hier den Desktop sowie Android, wobei Android bereits in der Vergangenheit häufiger Updates als die Desktop-Version erhalten hat.

Eine offizielle Begründung liegt zu diesem Zeitpunkt noch keine vor. Aber neben der Tatsache, dass diese Umstellung es ermöglicht, Probleme schneller zu lösen, ergibt der Schritt vor allem auch vor dem Hintergrund Sinn, dass durch die aktuellen KI-Fortschritte Sicherheitslücken in einem wesentlich höheren Tempo gefunden werden können – und das zukünftig eben auch von Angreifern. Darüber hinaus hat Google vor kurzem angekündigt, ab September 2026 seinen Zyklus von Feature-Updates für Chrome von vier auf zwei Wochen zu verkürzen. Diesen Schritt geht Mozilla bisher zwar nicht, erhöht damit aber ab sofort zumindest das Tempo für Fehlerkorrekturen.

Der Beitrag Firefox: Korrektur-Updates künftig im Wochen-Takt erschien zuerst auf soeren-hentzschel.at.

9. Mai 2026

Alleine im April 2026 hat Mozilla 423 Sicherheitslücken in Firefox geschlossen. Dies war vor allem mit Hilfe von Künstlicher Intelligenz (KI) möglich. Zum Vergleich: In der Vergangenheit bewegte man sich meist zwischen 20 und 30 Sicherheitslücken pro Monat.

Bereits im März habe ich darüber berichtet, wie Mozilla seinen Browser in Zusamenarbeit mit Anthropic durch KI-Einsatz sicherer gemacht hat. Damals konnten durch Nutzung von Anthropics KI-Modell Claude Opus 22 bis dahin unentdeckte Sicherheitslücken (sowie über 90 weitere Bugs ohne Sicherheits-Relevanz) gefunden werden, die in Firefox 148 behoben worden sind.

Bei einem einmaligen KI-Einsatz blieb es nicht. Stattdessen hat Mozilla seine Sicherheitsabläufe angepasst, um KI stärker in die Sicherung von Firefox zu integrieren. Außerdem ist Mozilla eines von wenigen Unternehmen, welches bereits Zugriff auf eine Vorschau-Version von Anthropics neuem KI-Modell Claude Mythos erhalten hat.

Mit dessen Hilfe wurde alleine in Firefox 150 eine bemerkenswerte Anzahl von 271 Sicherheitslücken geschlossen. Weitere KI-unterstützte Sicherheits-Korrekturen erfolgten in Firefox 149.0.2, Firefox 150.0.1 sowie Firefox 150.0.2. Durch den Einsatz weiterer Modelle, anderer interner Methoden sowie externer Berichte kommt Mozilla auf eine Gesamtzahl von 423 Sicherheitslücken, die nur im April 2026 behoben worden sind. In der Vergangenheit waren es häufig zwischen 20 und 30 geschlossene Sicherheitslücken pro Monat.

Geschlossene Sicherheitslücken in Firefox

Natürlich ersetzt der Einsatz von KI nicht, dass sämtliche gefundenen Probleme priorisiert und Korrekturen entwickelt, überprüft und getestet sowie die ganze Sicherheits-Pipeline aufgebaut und skaliert werden müssen. Über 100 Menschen haben dazu beigetragen, diesen Erfolg für die Sicherheit von Firefox möglich zu machen.

Der Beitrag Dank KI: Mozilla schließt 423 Sicherheitslücken in Firefox – nur im April 2026 erschien zuerst auf soeren-hentzschel.at.

8. Mai 2026

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

Neuerungen von Thunderbird 150.0.2

Mit Thunderbird 150.0.2 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit aktuelle Sicherheitslücken der verwendeten Mozilla-Plattform.

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

In diesem Teil geht es darum wie Starkoch NixOS wirklich zum Sternekoch wird. Wie man die Integration anderer Köche vorbereitet und wie die Speisekarte gesichert wird.



Flakes gegen den "Snowflake-Effekt"

Sicher erinnert ihr euch noch an den brillanten Starkoch Nixos aus dem letzten Teil. Eigentlich kann er mehr als zufrieden sein. Die Restaurantküche läuft seit dem Paradigmenwechsel (funktional und deklarativ), also mit der Speisekarte als einziger Quelle der Wahrheit, wie geölt. Trotzdem fehlt das letzte Bisschen Kontinuität, Beständigkeit und 100‑%ige Reproduzierbarkeit. Trotz unveränderter Karte schmecken die Speisen nicht immer ganz genau gleich. Mit dem Traum vom Sternekoch wird es so natürlich nichts.

Dabei steht doch in dem numerisch verschlüsseltem Rezept (dem Hash) ganz genau: "Nimm 500ml frische Milch und 200g Weizenmehl" - damit ist doch alles beschrieben, oder? Irgendwann fällt der Groschen. Starkoch Nixos greift zur Tastatur und legt eine zusätzliche Datei zur Speisekarte an. In diese schreibt er: „Nimm 500ml frische Bio-Milch der Molkerei Demet und 200g Weizenmehl Typ 1050 von der Müller-Mühle“. Alles klar?!

Wenn du momentan nach der Festsetzung der Konfiguration sudo nixos-rebuild switch tippst, holt sich dein Rechner die jetzt gerade aktuellen Pakete. Wenn du denselben Befehl auf einem anderen Rechner mit der gleichen Konfiguration ausführst, aber mit zwei Tagen Abstand, gibt es eventuell schon neuere, unterschiedliche Versionen von z. B. Firefox oder dem Kernel. Das Ergebnis: Deine Konfiguration ist zwar identisch, aber das Ergebnis (die installierte Software) ist es nicht. Das hält das Versprechen von Nix, „exakt gleich“, nicht zu 100 %.

Und genau das ist die bahnbrechende Weiterentwicklung von NixOS: Die normalen Update-Channels werden ergänzt und ersetzt durch Flakes. Und by the way: Nixos ist jetzt endlich Sternekoch.

Zwei Schneeflocken

  • Die flake.nix (Die Einkaufsliste): Hier schreibst du z. B. rein (in der Regel nur ein einziges Mal, danach muss die flake.nix nie wieder angetastet werden), woher Nix die Programme holen soll (stable, unstable etc.).
  • Die flake.lock (Das Frische-Siegel): Sobald du dein System einmal gebaut hast, schreibt Nix hier den exakten "Fingerabdruck" jedes Programms rein. Das ist übrigens wieder so eine Datei, die wir als User nie antasten (dürfen).

Das Ergebnis: Ab jetzt schaut Nix in das Siegel (flake.lock) und weiß: „Aha, ich darf exakt nur diese Bausteine nehmen." Und so richtig cool wird das, wenn du deine Konfiguration mit deinen anderen Geräten über Git bzw. Codeberg synchronisierst (kommt in Teil 3).

Technisch bedeutet das: Ohne Flakes ist NixOS ein (mindestens) sehr gutes Linux, weil es die "Dependency-Hell" durch den Nix-Store ausschaltet. Mit Flakes wird es zu einer überragenden Zeitmaschine, die du verlustfrei vor- und zurückspulen kannst. Die Schneeflocke kann ruhig schmelzen, wir können sie jederzeit nachbauen – und zwar jetzt wirklich Bit-genau.

Erfahrung schlägt Erkenntnis

Bevor wir hier als Trockenübung weiter machen, biete ich an, dass du an diesem Punkt meine Systemdateien übernimmst, damit wir schauen können, wo die Flakes auf fruchtbaren Boden fallen.

Das sind Lernmaterialien! Klar, es ist gleichzeitig auch eine Basis und bietet ein erstes schönes Fundament für das eigene System. Aber ich habe extra sehr intensiv in den Dateien kommentiert, damit vorrangig das Lernen erleichtert wird.

Und noch ein Hinweis:

Ich liebe nun mal die schlichte Eleganz und Usability von GNOME. Wenn du jetzt meine Konfigurationsdateien übernimmst, dann wird dadurch dein System zwangsläufig auf GNOME umgestellt werden. Du bekommst initial: GNOME mit Erweiterungen zu einem Manjaro-EndeavourOS-Style-Mix, das Terminal mit Fish und Starship, Firefox, Thunderbird, LibreOffice-Fresh und zwei eingebaute Skripte (beschreibe ich noch); den Rest habe ich auskommentiert.

Du hast einen anderen Lieblingsdesktop? Kein Problem – das sind deine Ressourcen:

  • Bei der Installation hattest du schon deinen Liebling gewählt und somit wurde dieser vom Installationsprogramm in der korrekten Syntax deiner configuration.nix hinzugefügt. Kopiere diesen Block einfach in die heruntergeladene configuration.nix, welche ja dann in ~/Downloads liegt, sofern du dem Angebot gefolgt bist. Gleichzeitig löschst du in meinem Original den Gnome-Block und alle Komfortfunktionen von Gnome. Achtung: Auch in meiner home.nix sind Gnome-Erweiterungen etc. Diese Blöcke ebenfalls komplett entfernen (zähle die Klammern mit! Schnell bleibt mal eine zu viel stehen oder es wird eine zu viel gelöscht – passiert!).
  • Die Nix-Dokumentation ist richtig gut. (Früher muss das mal anders gewesen sein, im Netz liest man viel Gegenteiliges.) Erste Anlaufstation ist eigentlich immer das Wiki und spezielle Befehle findet man mit einem Klick über Search Options. (In den Links hatte ich 'Xfce' als Beispiel gewählt.)

So kannst du meine Systemdateien einspielen und anpassen

1. Download

Ohne über eine der Dateien (home.nix) bisher gesprochen zu haben, bitte alle drei herunterladen:

2. Anpassung

Vor dem Editieren möchte ich dich aus didaktischen Gründen dazu motivieren die Dateien komplett zu lesen. Du wirst sehen, dass du den Syntax sehr gut verstehst (die Skripte dabei zunächst gerne überlesen). Schließlich möchte man ja wissen, was man dem System deklarativ als Bauanleitung übergibt.

In der flake.nix folgenden Block anpassen. Hier 2 × deinen Hostnamen (wenn nicht geändert, ist es "nixos") eintragen. Und 1x deinen Benutzernamen. Beides ist im Terminal ersichtlich. Dort steht vor dem Eingabeprompt benutzername@hostname.

 # Gemeinsame Konfiguration für alle Systeme
    common-modules = [
      ./configuration.nix
      home-manager.nixosModules.home-manager
      {
        home-manager.useGlobalPkgs = true;
        home-manager.useUserPackages = true;
        home-manager.backupFileExtension = "backup";
        home-manager.users.DEIN-USERNAME = import ./home.nix;     # <==
      }
    ];
  in {
    nixosConfigurations = {

      # --- Konfiguration für den Erstrechner ---
      DEIN-HOSTNAME = nixpkgs.lib.nixosSystem {     # <==
        system = "x86_64-linux";
        modules = common-modules ++ [
          ./hardware-configuration.nix
          { networking.hostName = "DEIN-HOSTNAME"; }     # <==
        ];
      };

In der home.nix im gezeigten Block 3 × den Benutzernamen deines Systems und 1 × die E-Mail-Adresse (diejenige, welche du für Codeberg benutzt oder später benutzen möchtest) editieren.

home.username      = "DEIN-USERNAME";        # <==
home.homeDirectory = "/home/DEIN-USERNAME";  # <==

programs.git = {
  enable = true;
  settings = {
    user.email = "deine@email.de";           # <==
    user.name  = "DEIN-USERNAME";            # <==
  };
};

In den Block der configuration.nix deinen Echtnamen angeben (hattest du auch bei der Installation angegeben) und 1 × den Benutzernamen deines Systems einbauen.

users.users.DEIN-USERNAME = {    # <==
  isNormalUser = true;
  description  = "Dein Name";   # <==
  extraGroups  = [ "networkmanager" "wheel" ];
  shell        = pkgs.fish;
};

3. Konfiguration einspielen

Die Dateien liegen wahrscheinlich noch in ~/Downloads:

sudo cp ~/Downloads/configuration.nix /etc/nixos/
sudo cp ~/Downloads/home.nix /etc/nixos/
sudo cp ~/Downloads/flake.nix /etc/nixos/

4. Git einrichten

Git wird zwingend benötigt damit NixOS Flakes verwenden kann. Du brauchst zunächst kein Codeberg-Konto.

Hier, mitten in die Befehle rein, muss ich noch etwas zu git ergänzen, was für das Verständnis wichtig ist.

Git ist ein Versionsverwaltungssystem. Es wurde von Linus Torvalds (dem Erfinder von Linux) entwickelt, weil er ein Werkzeug brauchte, um die Zusammenarbeit von tausenden Programmierern am Linux-Kernel zu koordinieren.

  • Die Zeitmaschine: Git merkt sich jede kleinste Änderung an einer Datei. Wenn du Mist baust, kannst du mit einem Befehl (sudo nixos-rebuild switch --rollback) zu dem Moment, zu der Version zurückkehrenn, als noch alles funktionierte.
  • Der Team-Player: Mehrere Leute können gleichzeitig an derselben Datei arbeiten. Git führt diese Änderungen später intelligent zusammen.

Und identische Anforderungen stellt NixOS ja auch, um die Idee mit den "Flakes" umzusetzen: Versionierbarkeit (flake.lock) und Multi-Hosts (flake.nix). Daher ist git und NixOS das perfekte 'Match'.
Welche Versionen deiner Konfiguration git bekannt sind, zeigt dir dann später nix-env --list-generations --profile /nix/var/nix/profiles/system.

4.1 Git temporär installieren

nix-shell -p git

In der neuen configuration.nix die du dann einspielst, ist git schon enthalten und bleibt dadurch dauerhaft im System.

4.2 Git minimal konfigurieren

sudo git config --global user.name "DEIN-USERNAME"
sudo git config --global user.email "deine@email.de"

4.3 Repository initialisieren

Hier stellen wir git unsere vier "Nixen" vor:

cd /etc/nixos
sudo git init
sudo git add configuration.nix home.nix flake.nix hardware-configuration.nix
sudo git commit -m "initiales Setup"

Das ist zunächst nur ein lokales Repository – nichts wird ins Internet hochgeladen. Es dient nur dazu, dass Flakes die Dateien "sehen" können.

5. System bauen

5.1 Flakes aktivieren

Einmal System bauen:

sudo nixos-rebuild test

Schritt 5.1 ist nötig, weil nix.settings.experimental-features = [ "nix-command" "flakes" ] erst durch diesen Rebuild aktiviert wird. Ohne diesen Schritt kennt NixOS den --flake-Parameter noch nicht und Schritt 5.2 schlägt sofort fehl.

5.2 System mit Flakes bauen

# Paketversionen aktualisieren und neu bauen

sudo nix flake update

sudo nixos-rebuild switch --flake /etc/nixos#DEIN-HOSTNAME

Die Befehle unter 5.2 sind ab jetzt deine neuen Update-Befehle und ersetzt den schon bekannten (unter 5.1)! Das # ist hier übrigens ausnahmsweise echter Teil des Befehls und weist auf den zu verwendenden Host.

Der Zusatz --flake /etc/nixos#DEIN-HOSTNAME sorgt ab jetzt dafür, dass die Informationen aus der flake.nix bzw. der flake.lock für den nun Bit-genauen Bau deines Systems (DEIN-HOSTNAME) herangezogen werden.

Beim ersten Mal wird dabei auch die flake.lock automatisch angelegt. Dieser Schritt dauert etwas, da alle Programme heruntergeladen und installiert werden.

Konfiguration sichern

Selbstverständlich kannst du die vier Dateien auch konventionell sichern. Zum Beispiel auf einer mobilen Festplatte. Dabei würdest du aber die „Zeitmaschine“ aushebeln! Wir nutzen daher einen "Git-Hub", ich empfehle Codeberg.org.

Wenn Git deine „Zeitmaschine“ ist, dann ist Codeberg das sichere Archiv, in dem du deine Zeitreisen und Rezepte aufbewahrst.
Um es kurz zu machen: Codeberg ist eine Plattform, auf der du deine NixOS-Konfigurationen speichern und mit anderen Hosts teilen kannst. Es ist quasi deine Cloud für git. Ausschließlich nur mit einem solchen "Git-Hub" kann git kommunizieren.

Also, sofern noch nicht geschehen, richte dir jetzt einen Account bei Codeberg ein und dort ein neues Repo mit dem Namen "NixOS".

Im letzten Teil beschreibe ich dann, wie du damit deine Konfiguration auf andere Rechner nicht nur spiegelst, sondern auch synchronisiert. Aber egal, ob dich der eigene Rechner wegen Defekt oder Diebstahl verlässt oder ob du weitere Maschinen mit dieser Konfiguration betreiben möchtest: Neu aufsetzen, Bit-genau-gleich: 30 Minuten!

1. Codeberg als Remote einrichten

cd /etc/nixos  # Vorab ins Verzeichnis zu wechseln wird gerne vergessen!
sudo git remote add origin https://codeberg.org/DEIN-USERNAME/NixOS.git
sudo git push -u origin master

2. Nach jeder Änderung sichern

Sei akkurat und sichere nach jeder Änderung deine Konfiguration:

cd /etc/nixos
sudo git add .
sudo git commit -m "kurze Beschreibung der Änderung"
sudo git push origin master

Home, sweet home.nix

Unser frisch gebackener Sternekoch Nixos möchte sich fortan nicht mehr selbst die Hände schmutzig machen und bereitet daher die Einstellung weiterer Köche vor. Die wollen aber jeweils unbedingt ihren eigenen Satz Kochmesser nutzen … schneller Switch auf die Systemebene:

Vielleicht nutzen deinen Rechner ja zusätzlich auch unterschiedliche Familienmitglieder? Oder du richtest einen zusätzlichen Gastzugang ein. Genau an diesem Punkt stößt man mit der Konfiguration ausschließlich über die configuration.nix an eine Grenze. Ebenso bei einem Set-up mit mehreren Rechnern (kommt in Teil 3) ist man damit limitiert. Und da kommt die home.nix ins Spiel.

Die configuration.nix stößt den Systembau- und die Systemverwaltung an. Die neue home.nix macht dasselbe für die Benutzerumgebung – sie aktiviert das dafür zuständige NixOS-Modul, den Home-Manager.

Bei NixOS hat jeder User die Möglichkeit, einen Teil der Konfiguration zu individualisieren – über seine eigene home.nix. Vielleicht hast du beim Editieren der configuration.nix und der home.nix schon bemerkt, dass z. B. die Benutzerprogramme alle in die home.nix gewandert sind. Und das macht ja auch absolut Sinn. Was schert andere Nutzer meine Fotosoftware, wenn es nicht auch deren Hobby ist? Vielleicht wollen auch nicht alle User die gleichen GNOME‑Erweiterungen. Und der riesige Vorteil ist eben, dass die Updates viel schneller durchlaufen, da jeder User nur seine Programme in den Nix-Store eingelagert bekommt.

In der Zusammenschau wird NixOS also durch vier Dateien in /etc/nixos/ gesteuert. Die Quelle der Wahrheit hat nun diese sehr logisch abgegrenzten Kapitel:

Datei Zuständig für
flake.nix Schaltzentrale: Paketversionen, Hostnamen, Multi-Host-Setup
configuration.nix System, Dienste, systemweite Programme (identisch auf allen Rechnern)
home.nix Benutzerprogramme, Theme, Desktop-Einstellungen
hardware-configuration.nix Gerätespezifisch, automatisch generiert

Die ersten drei Dateien sind ja zum Editieren vorgesehen und sind vom Syntax her identisch, gleich aufgebaut und gleich zu bedienen. Es sind immer normale Textdateien, was super zur Linux-Philosophie passt. Und mittlerweile sind mir diese Dateien schon so ans Herz gewachsen, dass ich sie "Nixen" nenne. :)

Ich werde das Multi-User-Setup (jeder User pflegt seine eigene home.nix) erst nach den drei Teilen dieser Setup Reihe beschreiben, das ist dann gleich der erste Folgebeitrag.

„Aber ich bin alleine auf meinem System und habe nur den einen Rechner. Mir reicht meine configuration.nix ..." Ja, geht – aber: Es gibt viele technische Gründe für die "Gewaltenteilung" im System, mich persönlich überzeugt aber ein eher philosophischer Grund am meisten: Semantische Klarheit: configuration.nix beschreibt, was das System ist, home.nix beschreibt, was Du bist. Das ist keine technische Notwendigkeit, sondern eine gedankliche Ordnung, die sich auszahlt, sobald die Konfiguration dann doch mal wächst. Technische Gegenüberstellung:

nur configuration.nix mit home.nix
Funktioniert ✅ ✅
Übersichtlichkeit nimmt ab bleibt hoch
Rebuild-Geschwindigkeit langsamer schneller
Portabilität mein PC only überall
Mehrbenutzer-fähig nicht wirklich elegant
Unabhängige Rollbacks ❌ ✅

Der Zugewinn ist also auch klar technisch begründet.

Belohnung

Wenn du bis hierhin durchgehalten hast, möchte ich dich mit einem Skript belohnen (es ist direkt in die home.nix geschrieben, also schon aktiv).

update-push     # Skript 1

Du hast etwas an der Konfiguration geändert, z. B. die home.nix um ein neues Programm ergänzt, dann wäre jetzt sudo nixos-rebuild switch --flake /etc/nixos#DEIN-HOSTNAME fällig und danach noch das ganze oben beschriebene Prozedere zur Sicherung auf Codeberg. All das nimmt dir ab jetzt das Skript ab. Nach Eingabe von update-push (ohne sudo) musst du dich nur noch identifizieren.

Vorschläge zur Weiterarbeit

(1) Schau dir die home.nix und die configuration.nix an und vergleiche die Elemente hinsichtlich System und Du (siehe oben). Lies die Dateien in der für dich noch fremden Sprache und nutze als "Wörterbuch" Search Options, sowie das Wiki.

(2) Konfiguriere dir dein System nach deinem Wunsch, indem du (so wie in Teil 1 beschrieben) nun z. B. weitere Programme durch Ergänzen der home.nix hinzufügst. Meine z. T. auskommentierten und für dich evtl. nutzlosen Programme kannst du dann auch gleich durch Löschen der entsprechenden Zeilen entfernen. Etwas aufpassen musst du in der configuration.nix bei den Gnome-Programmen: Auskommentieren heißt hier „Ich darf bleiben“.
Danach immer update-push!

(3) Wieder der Tipp: Solltest du schon wild experimentieren oder Fragen haben: einfach Terminal-Ausgaben oder Fragen z. B. in claude.ai (Empfehlung, da Claude auch .nix-Dateien lesen kann!).

Artikel der NixOS-Reihe


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.

7. Mai 2026

Mozilla hat Firefox 150.0.2 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion. Außerdem wurden zahlreiche Sicherheitslücken geschlossen.

Download Mozilla Firefox 150.0.2

Mit Firefox 150.0.2 behebt Mozilla zahlreiche Sicherheitslücken. Alleine aus Gründen der Sicherheit ist ein Update daher für alle Nutzer empfohlen.

Die Backup-Funktion von Firefox konnte unter bestimmten Umständen fehlschlagen.

Die Kennzeichnung der Funktion „Geteilte Ansicht” als „Neu” im Kontextmenü von Tabs war nach erstmaliger Benutzung des Features nicht verschwunden.

Das gleichzeitige Neuladen mehrerer Tabs funktionierte nicht mehr.

Probleme beim Hervorheben in PDF-Dateien sowie ein mögliches Problem beim Update von Firefox auf macOS wurde behoben.

Auch in Zusammenhang mit dem KI-Feature Smart Window wurden noch einmal Verbesserungen vorgenommen.

Die kryptographische Chiffre ECDHE-ECDSA-AES128-SHA wurde deaktiviert.

Darüber hinaus wurden mehrere Webkompatibilitäts-Probleme, potenzielle Absturzursachen und kleinere Design-Probleme korrigiert.

Der Beitrag Mozilla veröffentlicht Sicherheits-Update Firefox 150.0.2 erschien zuerst auf soeren-hentzschel.at.

Mit einer modernen Oberfläche und der Unterstützung aller relevanten Paketformate, empfiehlt sich Shelly als grafischer Paketmanager für Arch-Linux und dessen Derivate.



Wer sich für Arch Linux entscheidet, hat es bei der Installation mit dem kontinuierlich weiterentwickelten Installationsprogramm Archinstall 4.0 sehr einfach. Der TUI-Installer wurde vom veralteten Curses auf Textual umgeschrieben, wodurch sich die Installation vereinfacht und auch für ambitionierte Einsteiger:innen geeignet ist.

Damit wird die Arch-Installation für fast alle machbar. Andere Arch-basierte Distributionen (EndeavourOS, CachyOS, Manjaro)  machen einem das Leben mit grafischen Installationsprogrammen noch einfacher. Der nächste Knackpunkt nach der Installation ist die Paketverwaltung. Bei einem reinen Arch erhält man Pacman für die Paketverwaltung auf der Kommandozeile. Je nach gewählter Desktop-Umgebung sind grafische Werkzeuge, wie z. B. GNOME-Software oder Octopi dabei, die mehr oder weniger das Spektrum der gewünschten Paketformate abdecken.

Als Alternative bietet sich die moderne und umfassende Paketverwaltung Shelly an. Das Programm ist kürzlich in der Version 2.2 erschienen, die einen Umbau des grafischen Erscheinungsbilds mit sich bringt. Ich habe bereits vor einem Monat einen Artikel über Shelly geschrieben. Dort findet ihr die Basics, während es mir jetzt um die Neuerungen geht.

Die grösste Neuerung in der Version 2.2 ist die umfassende Überarbeitung der Benutzeroberfläche, die die Bedienung der Anwendung vereinfachen soll. Weg sind die Seitenleiste und die Systemübersichtsbereiche am unteren Rand. Shelly besteht nun aus einem übersichtlichen Fenster mit Registerkarten, in dem ihr eure Pakete einfach installieren, aktualisieren und verwalten könnt.

Die neue Benutzeroberfläche erleichtert zudem die Konfiguration von Shelly durch die Einführung eines Einrichtungsassistenten für die Erstinbetriebnahme, über den man die Unterstützung für das AUR-Repo (Arch User Repository), Flatpak und AppImage sowie die Taskleisten-Icon-Unterstützung aktivieren kann.

Ab dieser Version zeigt Shelly die Anzahl der verfügbaren Updates nun dynamisch in der neuen Benutzeroberfläche an und geht mit abweichenden Git-Historien bei AUR-Paketen um, indem es einen neuen Klon versucht, wenn der Befehl „git pull“ fehlschlägt. Die Anwendung geht jetzt auch eleganter mit Installationsfehlern um und behebt das Problem mit geteilten AUR-Paketen.

Seit Shelly 2.1 bietet der grafische Paketmanager ausserdem Unterstützung für Flatpak-Installationen, animierte und konfigurierbare Fortschrittsbalken in CLI-Befehlen, Unterstützung für XDG-Pfade, eine neue Option in der Paketsuche zum Beenden des Prozesses sowie die Verwaltung von Datei-Expandern.

Zudem wurden verschiedene Verbesserungen bei der Handhabung von AppImage und Flatpak vorgenommen, zusammen mit zahlreichen Fehlerbehebungen, um die Paketverwaltung auf deine Arch-Linux-Distribution zuverlässiger zu machen. Weitere Details zu den Änderungen findet ihr auf der GitHub-Seite des Projekts.

Die Installation von Shelly 2.2 ist meh. Wer CachyOS verwendet, kann sich die Anwendung aus den Cachy-Repos mit sudo pacman -S shelly ziehen. Alle anderen sind auf das AUR-Paket angewiesen. Also entweder yay -S shelly oder paru -S shelly.

Titelbild: https://pixabay.com/photos/shells-sand-beach-seashells-shore-792912/ (bearbeitet)

Quellen:

https://www.heise.de/news/I-install-Arch-BTW-mit-dem-neuen-archinstall-4-0-11241611.html

https://github.com/archlinux/archinstall/releases/tag/4.0

https://github.com/Seafoam-Labs/Shelly-ALPM/releases

https://shellyalpm.com/index.html

https://9to5linux.com/shelly-2-2-arch-linux-gui-package-manager-released-with-major-ui-revamp


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.