In Wiki von Arch Linux wird empfohlen für Updates des Microcodes entweder amd-ucode oder intel-ucode zu installieren (https://wiki.archlinux.org/title/Microcode). Wenn man eine CPU von AMD nutzt, ist das aber meist nur ein Placebo.

Unter https://gitlab.com/kernel-firmware/linux-firmware/-/blob/main/amd-ucode/README sind die unterstützten Prozessoren genannt. Was überschaubar wenige sind. Und viele davon dürfte man auf einem durchschnittlichen Desktop-System nicht nutzen.

Um zu prüfen, ob man einen unterstützen Prozessor nutzt, kann man folgenden Befehl ausführen und diesen dann mit der README-Datei vergleichen.

1lscpu | awk -F: '$1 ~ /^(Prozessorfamilie|Modell|Stepping)$/ {printf("%s: 0x%.2x\n", $1, $2)}'

Bei dem Rechner mit dem ich gerade diesen Artikel schreibe, erhalte ich folgende Ausgabe.

1Prozessorfamilie: 0x17
2Modell: 0x08
3Stepping: 0x02

Es handelt sich hierbei um einen AMD Ryzen 5 2600X. Also um eine nicht ganz aktuellen aber auch nicht um einen Prozessor aus dem letzten Jahrhundert. Und sie wird nicht unterstützt. Was auch in vielen anderen Fällen zutreffen sollte.

Jetzt kann man, nein sollte man sich fragen, warum AMD (im Gegensatz zu Intel) so wenige CPU mit Microcode-Updates direkt versorgt. Meines Wissens nach liegt es daran, dass AMD davon ausgeht, dass die Hersteller von Motherboards solche Updates zusammen mit BIOS- / UEFI-Updates anbieten. Somit veröffentlicht AMD diese Update nicht direkt in Form von Paketen wie amd-ucode. Was “lustig” ist, da manche Hersteller allgemein höchsten 1 oder 2 BIOS- / UEFI-Updates veröffentlichen. Wenn überhaupt.

Was kann man dagegen machen? Unter Arch würde ich empfehlen amd-ucode zu deinstallieren und dafür https://aur.archlinux.org/packages/amd-zen-ucode-platomav zu installieren. Hierbei handelt es sich um ein, von AMD unabhängiges, Projekt dass die jeweils aktuellen Microcode-Updates diverser Prozessoren in Form eines Pakets anbietet.

Betrifft das nun auch andere Distributionen? Ich bin mir nicht sicher. Entweder machen sich andere Distributionen die Arbeit und bieten von Haus aus ein Paket wie amd-zen-ucode-platomav an. Oder sie bieten ebenfalls keine aktuellen Microcode-Upodates für AMD an.

Vermutlich fragen sich jetzt einige, ob Microcode-Updates überhaupt wichtig sind. Ja, nein, vielleicht. Manche dieser Updates beheben nur Bugs von denen man in seltenen Fällen betroffen ist. Andere Update hingegen beheben Sicherheitslücken. Also im Zweifelsfall sind sie wichtig.

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

Neuerungen von Thunderbird 128.4

Mit dem Update auf Thunderbird 128.4 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht. Das Update bringt eine neue Exportmöglichkeit für die Konteneinstellungen, um diese dann im neuen Thunderbird für Android per QR-Code importieren zu können.

Dazu kommen wie immer diverse Fehlerbehebungen und Verbesserungen unter der Haube, welche sich in den Release Notes (engl.) nachlesen lassen. Auch wurden diverse Sicherheitslücken geschlossen.

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

Mozilla hat Firefox 132 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.

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

Streaming: PlayReady-Unterstützung

Firefox auf Windows unterstützt (zunächst auf ausgewählten Websites) jetzt die verschlüsselte Wiedergabe über Microsoft PlayReady. Dies ebnet den Weg für die 4K-Wiedergabe auf wichtigen Streaming-Plattformen. Weitere Vorteile sind eine verbesserte Akkulaufzeit und Leistung beim Streaming gegenüber der Wiedergabe via Google Widevine.

Diese Neuerung wird schrittweise im Laufe der kommenden Wochen für alle Nutzer ausgerollt werden.

Datenschutz: Blockieren von Drittanbieter-Cookies und Begrenzung der Cookie-Lebenszeit

Bei Aktivierung des strengen Schutzes vor Aktivitätenverfolgung blockiert Firefox jetzt sämtliche Drittanbieter-Cookies.

Die Lebenszeit von jeglichen Cookies, welche eine Lebensdauer definieren, ist ab sofort auf maximal 400 Tage beschränkt.

Datenschutz: „Link ohne Website-Tracking kopieren“ verbessert

Über das Kontextmenü lassen sich Links entweder im Original oder mit entfernten Tracking-Parametern kopieren. Mozilla hat diese Funktion verbessert, so dass einerseits mehr Tracking-Parameter erkannt werden. Zum anderen ist der Kontextmenü-Eintrag jetzt ausgegraut, wenn der Link keine erkannten Tracking-Paramater beinhaltet.

Wem weitere Tracking-Parameter bekannt sind, welche über diese Funktion nicht entfernt werden, kann diese an Mozilla melden.

Tabs auf anderen Geräten schließen

In Firefox lassen sich nicht nur Daten wie Lesezeichen, Chronik und Passwörter synchronsieren, man kann auch die gleichen Tabs öffnen, die auf anderen Geräten bereits geöffnet sind. Dies ist beispielsweise über die Sidebar für synchronisierte Tabs möglich. Über das Kontextmenü der einzelnen synchronisierten Tabs ist es ab sofort möglich, die jeweiligen Tabs auf den anderen Geräten zu schließen. Diese Möglichkeit steht jedoch nur in der neuen Sidebar zur Verfügung, welche in Firefox 132 noch nicht standardmäßig aktiviert ist und über about:config aktiviert werden kann, indem der Schalter sidebar.revamp per Doppelklick auf true geschaltet wird.

Sonstige Endnutzer-Neuerungen von Firefox 132

Auch die Übersetzungsfunktion hat wieder Verbesserungen erhalten. So werden Leerzeichen um Elemente nun korrekt beibehalten und implizite option-Werte (bei Fehlen des value-Attributs) nicht länger übersetzt, weil dies zu unvorhergesehenen Ergebnissen führen könnte. Die Seite about:translations zur freien Textübersetzung hat eine Schaltfläche erhalten, um Quell- und Zielsprache zu tauschen.

Je nachdem, was Websites für Grafiken bereitstellen, konnte es vorkommen, dass Firefox für Lesezeichen ein anderes Icon angezeigt hat als in den Tabs, weil für die Lesezeichen auch andere Bildquellen berücksichtigt wurden. Dies ist nicht länger der Fall und Firefox sollte in den Lesezeichen jetzt immer das erwartete Icon verwenden, welches auch für den Tab verwendet wird.

Auf macOS 15 und höher werden die neuen Auswahlfunktionen des Apple-Betriebssystems für die Bildschirm- und Fensterfreigabe unterstützt. Unterstützung dieser Neuerung auf macOS 14 wird mit einem späteren Update folgen.

Firefox auf macOS wird jetzt automatisch neu gestartet, wenn er vor einem Systemneustart geöffnet war, zum Beispiel nach einer Betriebssystemaktualisierung.

Auf Linux-Systemen mit XWayland und Mesa-Grafiktreiber war die Hardwarebeschleunigung bislang erst ab Verwendung von Mesa 21 oder höher aktiviert. Diese Anforderung wurde auf Mesa 17 oder höher gesenkt.

Das Rendering für die meisten SVG Filter-Primitive kann jetzt durch die Hardware beschleunigt werden, was zu einer verbesserten Performance auf grafiklastigen Websites führen kann.

Die Anzahl der Seiten aus der Chronik in Firefox View sowie in der Chronik-Sidebar war bislang auf maximal 300 begrenzt. Dieses Limit wurde entfernt.

Die Kompression von Zertifikaten wird jetzt unterstützt, was deren Größe reduziert und damit die Geschwindigkeit des TLS-Handshakes verbessert.

Der Minidump-Analysator des Absturzmelders wurde in der Programmiersprache Rust neu implementiert.

Nach einem Update-Fehler konnte es vorkommen, dass Firefox mit einer Fehlermeldung „XULRunner – Error: Platform version is not compatible with minVersion“ nicht mehr startete. In einem solchen Fall hilft eine Neuinstallation von Firefox, worauf der Nutzer bei dieser Meldung aber nicht unbedingt von alleine kommt. Ein entsprechender Hinweis wurde in dieser Fehlermeldung ergänzt.

Für Firefox-Distributionen (von Partnern angepasste Firefox-Versionen) ist es jetzt möglich, ein anderes Theme standardmäßig zu setzen.

Eine neue (standardmäßig deaktivierte) Option wurde implementiert, um HTTP/3 zu deaktivieren, wenn ein Root-Zertifikat eines Drittanbieters gefunden wird. Diese Option wurde explizit für den Fall eingebaut, dass wieder einmal auf Probleme reagiert werden muss, welche durch die Sicherheitssoftware von Avast verursacht wird.

Mehr Sicherheit für Firefox-Nutzer

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

Über unverschlüsseltes http:// geladene Favicons auf Websites, welche über https:// aufgerufen werden, werden ab sofort blockiert, wenn diese nicht ebenfalls über https:// aufrufbar sind.

Verbesserungen der Entwicklerwerkzeuge

Das Debugging von Websites auf anderen über USB angeschlossenen Geräten via about:debugging funktioniert wieder. Außerdem werden über console.log geloggte Nachrichten in Service Workers jetzt wieder in der Konsole ausgegeben.

Verbesserungen der Webplattform

Wide Color Gamut WebGL ist jetzt für Windows und macOS verfügbar. Damit unterstützt Firefox eine reichhaltigere und lebendigere Farbpalette in Videos, Bildern und Spielen.

Die Unterstützung der silent-Option für Webbenachrichtigungen wurde hinzugefügt.

Die Unterstützung von HTTP/2 Push wurde entfernt. Zum einen gab es dadurch Kompatibilitätsprobleme mit verschiedenen Websites, zum anderen unterstützt kein anderer der relevanten Browser dieses Feature.

Die Berechnung der Textausrichtung wurde aktualisiert, um dem neuesten in der HTML-Spezifikation definierten Modell zu folgen, was die Interoperabilität mit anderen Webbrowsern verbessert.

Das Attribut fetchpriority ermöglicht es Webentwicklern, das Laden von Ressourcen zu optimieren, indem sie die relative Priorität von Ressourcen angeben, die vom Browser abgerufen werden sollen.

Dies war nur eine kleine Auswahl der Verbesserungen der Webplattform. Eine vollständige Auflistung lassen sich in den MDN Web Docs nachlesen.

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

Kürzlich habe ich auf Fryboyter diesen Artikel gelesen: Wie sollte man Veröffentlichungen versionieren?

Meine Gedanken zu dem Artikel und dem Thema möchte ich an dieser Stelle mit Fryboyter und euch teilen.

Fryboyter favorisiert nach eigener Darstellung Calendar Versioning (CalVer), da dies seiner Meinung nach aussagekräftiger ist, als z.B. 0.78.1, was sehr stark nach Semantic Versioning (SemVer) aussieht. Meiner Meinung nach kann man dies nicht pauschal sagen, da beide Versionsschemata ihre eigenen Vor- und Nachteile haben. Doch wann sollte man zu welchem Schema greifen?

Calendar Versioning

Die folgende Liste ist eine Übersetzung des englischen Textes, welcher hier zu finden ist. Wenn einer der in dieser Liste genannten Punkte auf ein Projekt zutrifft, scheint CalVer ein geeignetes Schema für die Versionierung zu sein.

• Hat Ihr Projekt einen großen oder ständig wechselnden Umfang?
• Große Systeme und Frameworks, wie Ubuntu und Twisted.
• Amorphe Gruppen von Dienstprogrammen, wie Boltons.
• Ist Ihr Projekt in irgendeiner Weise zeitkritisch? Beeinflussen externe Änderungen neue Projektveröffentlichungen?
• Geschäftliche Anforderungen, wie Ubuntus Fokus auf Unterstützungstermine.
• Sicherheitsupdates, wie certifi’s Notwendigkeit, Zertifikate zu aktualisieren.
• Politische Veränderungen, wie die Handhabung von Zeitzonenänderungen durch die IANA-Datenbank.

Einige Betriebssysteme wie z.B. Ubuntu haben einen festen Veröffentlichungsrythmus und Unterstützungszeitraum. So werden Ubuntu LTS Versionen ohne Zusatzverträge für 5 Jahre unterstützt und mit Aktualisierungen versorgt. Bei Ubuntu 24.04 LTS kann man bereits am Namen erkennen, wie alt dieses Release ist und wie lange es mit Aktualisierungen versorgt wird. Ubuntu veröffentlicht Aktualisierungen für die enthaltenen Pakete in unregelmäßigen Abständen, meist sobald diese verfügbar sind. Aufgrund der vielen enthaltenen Pakete und der Aktualisierungsrichtlinie scheint SemVer (siehe nächster Abschnitt) hier nicht vorteilhaft zu sein.

Bei Debian 12, RHEL 9 oder SLES 15 erkennt man das Datum der Veröffentlichung hingegen nicht. Hier hilft nur ein Blick in die jeweilige Versionshistorie der Projekte, um Informationen über den Zeitpunkt der Veröffentlichung und der jeweiligen Unterstützungszeiträume zu finden.

Semantic Versioning

Auf Grundlage einer Versionsnummer von MAJOR.MINOR.PATCH werden die einzelnen Elemente folgendermaßen erhöht:
1. MAJOR wird erhöht, wenn API-inkompatible Änderungen veröffentlicht werden,
2. MINOR wird erhöht, wenn neue Funktionalitäten, die kompatibel zur bisherigen API sind, veröffentlicht werden, und
3. PATCH wird erhöht, wenn die Änderungen ausschließlich API-kompatible Bugfixes umfassen.

Quelle: https://semver.org/lang/de/

SemVer ist stringent, einfach nachzuvollziehen und bietet für mich als Systemadministrator die folgenden Vorteile.

Wird PATCH erhöht, weiß ich, dass lediglich Fehler behoben wurden, sich am Funktionsumfang einer Anwendung jedoch nichts ändert. Das Einzige, was mir hierbei den Tag vermiesen kann, sind Regressionen. Das Risiko, dass irgendetwas kaputtgeht oder schlimmer wird, ist jedoch gering.

Wird MINOR erhöht, weiß ich, dass die Anwendung neue Funktionalität enthält und ich weiß, dass nun ein genauerer Blick erforderlich ist, um zu entscheiden, ob diese Funktionalität in meiner Umgebung bereitgestellt werden soll bzw. darf. Gegebenenfalls sind vor einer Aktualisierung Anwenderschulungen durchzuführen und interne Prozessbeschreibungen zu aktualisieren, bevor die neue Version zur Nutzung freigegeben werden kann.

Einem an Featureritis erkrankter Nerd mag jede neue Funktion gefallen. Unzureichend geplante Veröffentlichungen neuer Funktionen in Unternehmen können hingegen interessante Folgen haben.

Wird MAJOR erhöht, ist ein Blick in die Release Notes angeraten. Denn man weiß schon mit einem Blick auf die Versionsnummer, dass diese Version Breaking Changes enthält. Dies können sein:

• API-inkompatible Änderungen
• Entfallene bzw. entfernte Funktionalität
• Geänderte Architektur
• Geändertes Format der Konfigurationsdatei(en)
• etc.

Eine solche Aktualisierung kann man in aller Regel nicht ohne sorgfältige Planung installieren. Das Risiko, dass dabei etwas kaputtgeht und Stress und Produktionsausfall folgen ist einfach zu groß.

Aussagekraft

Fryboyter schreibt: „Zumal meiner Meinung nach 2024.10.11 aussagekräftiger als 0.78.1 ist.“

Aber ist es wirklich aussagekräftiger? Wenn ich nur das Datum sehe, weiß ich lediglich, wann die Version veröffentlicht wurde. Welchen Funktionsumfang die Version hat, welche Änderungen es zur vorhergehenden Version es gibt, ob diese Version stabil ist oder ob es die aktuellste Version ist, erkennt man nicht. Bei zwei Daten erkennt man zumindest, welches die aktuellere Version ist.

Sehe ich nur 0.78.1, weiß ich nicht, wann diese Version veröffentlicht wurde. Ich sehe jedoch auf den ersten Blick, dass sich diese Version in einer initialen Entwicklungsphase befindet, der Funktionsumfang nicht abschließend definiert ist und sich jederzeit ändern kann. Kurz gesagt, mit jeder weiteren Erhöhung von MINOR und PATCH ist damit zu rechnen, dass sich das Verhalten und der Funktionsumfang signifikant ändern. Da die einzelnen Elemente bei SemVer ausschließlich erhöht jedoch nie gesenkt werden, kann man bei Vorliegen von zwei Versionsnummern der gleichen Anwendung erkennen, welches die aktuellere ist. Details zu Änderungen gegenüber der Vorgängerversion verrät SemVer zwar auch nicht, doch kann ich den Umfang der Änderungen erkennen. Für mich besitzt SemVer damit in den meisten Fällen die größere Aussagekraft.

Die Frage wann es Zeit für Version 1.0.0 ist, beantwortet SemVer wie folgt:

Wenn die Software schon in der Produktion verwendet wird, sollte sie bereits in Version 1.0.0 vorliegen. Falls eine stable API existiert, auf die sich Nutzer bereits verlassen, sollte es ebenfalls die Version 1.0.0 sein. Auch wenn Kompatibilität zu vorherigen Versionen bereits eine wichtige Rolle spielt, ist Version 1.0.0 angebracht.

Quelle: https://semver.org/lang/de/#woher-wei%C3%9F-ich-wann-es-zeit-ist-version-100-zu-ver%C3%B6ffentlichen

Abschließende Bemerkung

Ich gehöre tendenziell eher zu Team SemVer und denke, dass dies eine höre Aussagekraft als CalVer besitzt.

Grundsätzlich halte ich es für sinnvoll und wichtig, wenn sich Entwickler bzw. Organisationen Gedanken machen, welches Versionsschema am besten zu ihrem Projekt passt.

Wie denkt ihr darüber? Hinterlasst doch gern einen Kommentar mit eurer Meinung oder veröffentlicht einen eigenen Text dazu in eurem Blog.