Mozilla hat Version 2.26 seiner VPN-Clients für das Mozilla VPN veröffentlicht.
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.
Halten Rolling-Releases länger als LTS-Releases? Dieser Artikel stellt Thesen auf, liefert aber keine Antworten.
Meine Lebenserfahrung mit Betriebssystemen kann man in vier Zeitalter einteilen:
DOS
Windows
Ubuntu
Rolling Distributionen
An die alten Zeiten mit DOS und Windows kann ich mich kaum noch erinnern, und darum soll es nicht gehen. Abgesehen von ersten Linux-Erfahrungen mit SuSE Linux 5.2 aus dem Jahre 1998 (das hiess damals noch so; heute: openSUSE), begann mein richtiger Einstieg in die Linux-Welt mit Ubuntu 6.10 (Edgy Eft) im Jahr 2006.
In den ersten Jahren habe ich jedes Ubuntu-Release installiert. Das war eine spannende Zeit, die von interessanten halbjährlichen Neuerungen geprägt war. In jedem April und Oktober habe ich mich wie ein Kind auf die Verbesserungen und Neuigkeiten im halbjährigen Ubuntu-Release gefreut; das war fast wie Weihnachten.
An diesen Feierlichkeiten habe ich ca. 10 Jahre lang teilgenommen. So ab 2015 wurde mir die Neuinstallation bzw. das Upgraden zu viel, weshalb ich auf den LTS-Pfad eingeschwenkt bin. Ab dann wurde nur noch alle zwei Jahre die Long-Term-Version neu installiert. Nachdem Canonical (die Firma hinter Ubuntu) ab den 2020er Jahren sich mit Eigenentwicklungen immer mehr von der Community entfernt hatte, begann bei mir die Zeit des Distro-Hoppings.
Letztlich bin ich bei der kuratiert-rollenden Distribution Manjaro gelandet. Während all dieser Jahre bin ich dem Gnome-Desktop treu geblieben, obwohl er bei Ubuntu auch einmal anders hiess (Unity). Ob das der Weisheit letzter Schluss war, wage ich zu bezweifeln. Nicht, weil ich Probleme mit Manjaro habe, sondern weil sich die Weltkugel der Linux-Distribution kontinuierlich weiterdreht. Wer weiss, was da noch kommt.
Genug des Vorgeplänkels; nun komme ich zum Thema.
Wie gesagt, wer sich auf ein LTS-Release-Modell verlässt, hat (theoretisch) zwei Jahre lang Ruhe und kann ein stabiles System geniessen: Nicht frickeln, sondern arbeiten ist hier die Devise. Die Release-Zeiten bei LTS-Modellen fallen unterschiedlich lang aus, aber da möchte ich jetzt keine Haarspalterei betreiben. Vorhin habe ich "theoretisch" geschrieben, weil man dennoch in hoher Kadenz mit Updates bespielt wird. Dabei handelt es sich in erster Linie um Sicherheitsupdates, was notwendig und gut ist. Je nachdem, welche Paketformate man verwendet (Flatpak), tritt die Update-Policy ohnehin in den Hintergrund, weil sich die Pakete selbst aktualisieren oder über die Flatpak-Paketverwaltung aus dem LTS-Zyklus ausbrechen.
These 1: LTS-Release-Modelle nerven durch häufige Updates genauso wie Rolling-Release-Modelle.
Obwohl Manjaro einem kuratierten rollendem Modell folgt, rauschen fast jeden Tag Updates herein. Ich fühle da kaum einen Unterschied zu einer reinen Arch-Installation. Die Updates kommen etwas später, aber sie kommen kontinuierlich.
These 2: Egal ob LTS oder Rolling, häufige Updates sind an der Tagesordnung.
Die entscheidende Frage ist, welchen Einfluss das auf die Systemstabilität hat. Rollende Distributionen haben zwei Vorteile:
Sie beheben spät erkannte Probleme schneller
Sie halten die Funktionalität auf dem neuesten Stand
Dem gegenüber gibt es Nachteile:
Sie führen nicht erkannte Probleme ein
Sie setzen höhere Kenntnisse der Anwender:innen voraus, um diese Probleme selbst zu beheben
Wie sieht der Vergleich zu LTS-Distros aus:
Anwendungen sind besser/länger getestet, weshalb sie weniger Probleme mit sich bringen
Spät erkannte Probleme hat man länger am Hals
Auf neue Funktionen muss man länger warten
These 3: Aufgrund der neuen Paketformate relativiert sich der Unterschied zwischen LTS und Rolling.
Nun stellt sich die Titel-Frage, wie lange Rolling Releases halten. Das Versprechen ist, dass man eine Distribution, die einem Rolling-Release-Modell folgt, nie mehr neu installieren muss. Bisher glaube ich nicht daran. Um das beurteilen zu können, muss man die Installationsdauer einer Distribution messen können. Das macht man mit diesem Befehl im Terminal:
Auf meinem Notebook:
stat -c %w /
2023-11-17 15:04:12.000000000 +0100
Auf meinem Desktop:
stat -c %w /
2023-04-14 08:48:38.000000000 +0200
Nun, in beiden Fällen liegt die Installation der Distribution weniger als zwei Jahre zurück, weshalb ein Vergleich mit einem 2-jährigen LTS-Update-Zyklus schwierig ist. Gelegentlich treten bei meinen Rechnern Probleme beim Update auf. In den meisten Fällen liegt es an Abhängigkeiten, die nicht aufgelöst werden können. Darüber habe ich erst neulich geschrieben. Auch heute bockte mein Desktop beim Update von ca. 125 Paketen. Wenn ich mich recht erinnere, waren es Abhängigkeiten von 32-Bit-Grafik-Bibliotheken von systemd. Durch das manuelle Löschen dieser Bibliotheken konnte ich das Problem schnell beseitigen.
These 4: Je länger man eine Rolling-Distribution betreibt, desto häufiger treten Fehler auf.
An dieser Stelle möchte ich die Fähigkeiten des Paketmanagers infrage stellen. Warum ist Pacman (bzw. Pamac) nicht in der Lage, solche einfachen zweistufigen Abhängigkeiten aufzulösen? Hier ist ein fiktives Beispiel:
Der Upate-Prozess kann nicht fortgeführt werden, weil Paket A von B abhängig ist, und Paket B von D1 und D2 benötigt wird.
Wenn ich mich recht erinnere, ist genau das die Kernaufgabe eines Paketmanagers.
Dieser Artikel bietet keine Antworten, sondern stellt Fragen. Was haltet ihr von meinen vier Thesen und wie sind eure Erfahrungen? Verrottet eine Rolling-Release-Installationen mit der Zeit? Schreibt es bitte in die Kommentare.
GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.
Die MZLA Technologies Corporation mit Thunderbird 9.0 ein Update für die Android-Version seines E-Mail-Clients veröffentlicht.
MZLA hat Thunderbird 9.0 veröffentlicht. Neben dem Download im Google Play Store stehen auch F-Droid, GitHub sowie erstmals auch archive.mozilla.org als weitere Distributionskanäle zur Verfügung.
Für das Einrichten eines neuen E-Mail-Kontots versucht Thunderbird nun zuerst die Autokonfiguration des jeweiligen E-Mail-Anbieters und greift erst danach auf die ISPDB-Datenbank von Thunderbird zurück.
Für Nutzer, die sich in ein Konto von Google Mail einloggen wollen, wird ab sofort ein Support-Artikel verlinkt, der bei häufigen Problemfällen unterstützt.
Die Unterstützung für Android 15 wurde verbessert. Dazu kommen wie immer weitere Detail-Verbesserungen unter der Haube sowie Fehlerkorrekturen.
Die digitalen Stromzähler (offizielle Bezeichnung: Moderne Messeinrichtung) sind inzwischen weit verbreitet. Viele können in zwei Richtungen zählen, was bei der Benutzung eines Balkonkraftwerks von großer Bedeutung sein kann. Ich habe vor einiger Zeit beschrieben, wie ich mit dem Impulsausgang auf der Vorderseite des Stromzählers den aktuellen Verbrauch ablese. Diese Methode klappt sehr gut, ist sehr einfach und braucht keine weitere Freischaltung des Netzbetreibers. Man kann einfach loslegen. Leider bringt der Impulszähler zwei Nachteile mit sich.
Über den Impulsausgang sieht man ausschließlich den aktuellen Stromverbrauch, nichts Weiteres. Man erfährt nicht den aktuellen Zählerstand oder die Flussrichtung. Außerdem gibt es keine Kontrolle, ob alle Impulse richtig gezählt werden. Summiert man die Leistung auf, erhält man zwar einen Jahresverbrauch, kann sich aber nicht sicher sein, ob er stimmt.
An sonnigen Tagen kommt es vor, dass man mit seinem Balkonkraftwerk mehr Strom erzeugt, als man im Haushalt verbraucht. In diesem Fall wird Strom ins Netz eingespeist. Der Impulszähler kann aber nicht unterscheiden, ob der Strom vom Netz kommt, oder ob er ins Netz geht. Folglich steigt scheinbar der Stromverbrauch im Haus, obwohl in Wirklichkeit ein Stromüberschuss erzeugt wird.
In diesem Artikel möchte ich eine alternative Auslesevariante vorstellen, die robuster und zuverlässiger arbeitet. Aussetzer in der Datenerfassung lassen sich durch späteres Zählerablesen wieder kompensieren, die Bilanz passt immer. Es können nicht nur der aktuelle Verbrauch, sondern auch die Zählerstände „in beide Richtungen“ erfasst werden. Das geschieht über das Auslesen von mehreren OBIS-Kennzahlen über die SML-Schnittstelle.
Die „Moderne Messeinrichtung“ verfügt über zwei optische Schnittstellen. Der Impulsausgang (oben Mitte) gibt den Momentanverbrauch via Impulsen aus. Diese Einbindung dieser Schnittstelle wurde in einem anderen Artikel bereits behandelt. Die SML-Schnittstelle (rechts) gibt mehrere Werte aus, unter anderem den Momentanverbrauch und den Zählerstand.
Die SML Schnittstelle des digitalen Stromzählers
Die digitalen Stromzähler haben eine zweite, wertvolle Schnittstelle: Die SML-Schnittstelle (Smart Meter Language). Über sie kommuniziert der Stromzähler mit einem genormten Protokoll (IEC 62056-6-1) mit uns Anwendern. In ihr werden die Zählerstände, der Momentanverbrauch und gelegentlich noch weitere Informationen bereitgestellt. Die Informationen sind als OBIS-Kennzahlen verfügbar und können leicht zugeordnet werden. Für mich sind die beiden OBIS-Kennzahlen 1.8.0 (Zählerstand, bezogen aus dem Netz) sowie 2.8.0 (Zählerstand, eingespeiste Energie ins Netz) relevant. Der OBIS-Kennwert 16.7.0 gibt mir die momentan bezogene Leistung aus.
Standardmäßig ist diese optische Schnittstelle deaktiviert und mit einer PIN geschützt. Diese PIN erhält man meist kostenlos von seinem Netzbetreiber. Der Netzbetreiber (nicht verwechseln mit dem Stromanbieter!) ist auf dem Stromzähler und der Stromrechnung genannt. In meinem Fall sind es die Stadtwerke. Eine freundliche E-Mail mit der Bitte um Bekanntgabe der PIN unter Nennung meiner Zählernummer hat bereits gereicht.
Diese PIN muss nun mit einer Taschenlampe in die optische Schnittstelle eingeblinkt werden. Schaut euch das kurze Video von Extra 3 dazu an, darin wird der ganze Frust damit gut zusammengefasst.
Bei erfolgreicher Eingabe der PIN muss die Funktion „Inf off“ auf „Inf on“ gestellt werden. Das gelingt, indem man sich durch das Menü des Stromzählers „blinkt“ und beim entsprechenden Eintrag mind. 4 Sekunden mit der Taschenlampe leuchtet. Diese Funktion schaltet die erweiterte Funktion des Stromzählers frei. Man erkennt das später daran, dass nicht nur der Zählerstand im Display angezeigt wird, sondern auch der Momentanverbrauch.
Ist die PIN eingegeben und die erweiterte Informationsvergabe freigeschaltet, kann es endlich losgehen!
DIY Komponenten und Controller ESP8266 vorbereiten
Ich verwende für die optische Schnittstelle einen ESP8266 und das Bauteil TCRT5000. Beides erhält man für weniger als 5 Euro bei Ebay oder anderen Händlern. Der TCRT5000 ist ein optischer LED-Sensor für Infrarot, die sowohl eine LED als auch eine IR-Diode verwendet.
TCRT5000 und seine Bauteile.
Die LED stört uns in diesem Fall, man muss sie vorher entfernen. Entweder zwickt man sie einfach ab, oder man lötet den Vorwiderstand von ihr weg. Ich habe mich für zweiteres entschieden. Der TCRT hat mehrere Vorteile gegenüber anderen Varianten. Manche Leute löten direkt eine IR-Diode an den ESP. Kann man natürlich machen, ich möchte nur auf die Vorteile meiner Variante hinweisen:
die elektrischen Bauteile sind aufgeräumt auf einer Leiterplatte, keine Bauteile fliegen einzeln herum. Außerdem gibt er genügend „Angriffsfläche“, um ihn – zumindest übergangsweise – per Klebeband zu fixieren.
die Schaltung enthält zwei kleine Status-LEDs: eine zeigt die Spannungsversorgung an, die zweite zeigt das Signal an der IR-Diode an. Vor allem die zweite Status-LED ist sehr, sehr hilfreich, wenn man die Bauteile installiert. Man erhält sofort eine Rückmeldung, ob die Diode ein Signal sieht oder nicht. Das ist besonders beim Ausrichten der Diode hilfreich, oder beim dritten Vorteil:
über das eingebaute Potentiometer kann man die Empfindlichkeit der Diode einstellen. Das ist manchmal notwendig, wenn das Signal der Stromzähler-LED zu stark oder zu schwach ist. Dann dreht man am Poti so lange, bis man über die Status-LED ein sinnvolles Signal sieht. Weiter unten im Artikel zeige ich nochmal genauer, was ich damit meine.
Jetzt verkabelt man die Baugruppe mit dem ESP8266. Ich habe die Variante Wemos D1 mini. Dieses hat bereits die UART-Schnittstelle vorbereitet, die wir verwenden wollen. Dadurch ergibt sich folgendes Verkabelungsschema. Ob ihr das nun verlötet oder mit Jumper-Kabeln verdrahtet, bleibt euch überlassen.
ESPHome konfigurieren und aufspielen
Die Installation von ESPHome im Windows Service for Linux habe ich bereits in einem anderen Artikel beschrieben. Wir erzeugen uns eine Textdatei mit dem Dateinamen stromzaehler-sml.yaml und füllen sie mit folgendem Inhalt.
esphome:
name: stromzaehlersml
esp8266:
board: d1_mini
# Enable logging
logger:
level: VERY_VERBOSE # kann spaeter auf DEBUG verringert werden
logs:
sml: DEBUG
text_sensor: DEBUG
# Enable Home Assistant API
api:
password: ""
ota:
password: ""
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
manual_ip:
static_ip:
gateway:
subnet:
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Stromzaehler Sml"
password: ""
captive_portal:
uart:
id: uart_bus
tx_pin: GPIO1
rx_pin: GPIO3 # dieser GPIO ist wichtig, hier ist das Signalkabel angeschlossen
baud_rate: 9600
data_bits: 8
parity: NONE
stop_bits: 1
sml:
id: mysml
uart_id: uart_bus
sensor:
- platform: sml
name: "Total energy SML 180"
sml_id: mysml
server_id: "0123456789abcdef"
obis_code: "1-0:1.8.0"
unit_of_measurement: kWh
accuracy_decimals: 3
device_class: energy
state_class: total_increasing
filters:
- multiply: 0.0001
- platform: sml
name: "Total energy SML 280"
sml_id: mysml
server_id: "0123456789abcdef"
obis_code: "1-0:2.8.0"
unit_of_measurement: kWh
accuracy_decimals: 3
device_class: energy
state_class: total_increasing
filters:
- multiply: 0.0001
- platform: sml
name: "Stromverbrauch SML 1670"
sml_id: mysml
server_id: "0123456789abcdef"
obis_code: "1-0:16.7.0"
unit_of_measurement: W
accuracy_decimals: 0
device_class: energy
filters:
- multiply: 1.0
text_sensor:
- platform: sml
name: "Total energy text"
sml_id: mysml
server_id: "0123456789abcdef"
obis_code: "1-0:1.8.0"
Es müssen folgende Zeilen angepasst werden:
Wifi Zugangsdaten
Feste IP-Adresse (kann auch erst im zweiten Schritt erfolgen)
die server_id passen wir an, sobald wir sie kennen. Sie ist ggf. auf den Stromzähler aufgedruckt. Weiter unten im Artikel finden wir sie aber auch über die SML-Schnittstelle heraus.
Zur Erklärung: Die Kommunikation zwischen unserer IR-Diode und dem ESP erfolgt über ein Protokoll namens UART. Diese Schnittstelle wird in den Zeilen nach uart: konfiguriert. Der GPIO-Pin 3 ist dabei derjenige, der auf dem Wemos D1 Mini mit RX gekennzeichnet ist. Falls ihr einen anderen verwendet, müsst ihr diese Zeile anpassen. Die SML Schnittstelle wird ab Zeile sml: konfiguriert. Die meisten Einstellungen könnt ihr so lassen, wie es oben beschrieben ist. Die wichtigen Zeilen sind die mit server_id. Dort wird die Server-Adresse eingestellt. Vermutlich kennt ihr sie nicht von Anfang an, lasst also erstmal die Voreinstellung. Wir ändern sie später, sobald wir sie erfahren haben.
Speichert die Datei nun und kompiliert sie über den Befehl
esphome run stromzaehler-sml.yaml
Nach ein paar Augenblicken ist der Vorgang abgeschlossen und irgendwo wird eine Datei namens firmware.bin abgelegt. Der Pfad ist in der Textausgabe angegeben, bei mir war es
Nun flashen wir die Datei auf den ESP8266. Dazu benutzen wir den Google Chrome (oder einen anderen kompatiblen Browser) und gehen auf die Webseite https://web.esphome.io Schließt den ESP mit einem USB-Kabel an den PC an. Auf der Webseite sollte ein Popup erscheinen.
Sollte dieser Schritt nicht funktionieren, liegt das sehr wahrscheinlich am USB-Kabel. Tauscht das Kabel gegen ein anderes, nicht alle Kabel sind dafür geeignet! Folgt den Anweisungen auf der Webseite, um die Datei firmware.bin auf den ESP zu flashen.
Kontrolliert nach dem Flashen, ob ihr den ESP in eurem WLAN findet. Falls ja, großartig! Wir binden ihn gleich in Home Assistant ein. Gehe in Home Assistant auf Einstellungen → Geräte und Dienste → Integration hinzufügen → ESPHome
Baut jetzt den ESP in der Nähe eures Stromzählers auf. Versorgt ihn mit Spannung (z.B. über ein Handy-Netzteil) und richtet die IR-Diode richtig aus. Jetzt hilft euch die Status-LED vom TCRT5000. Sollte sie regelmäßig blinken, habt ihr schon viel geschafft. Ich habe mit einem kleinen Schraubendreher das Poti noch so verstellt, bis ein wirklich sauberes Signal angekommen ist.
Sollte die Status-LED gar nicht leuchten, ist vermutlich die Diode noch nicht richtig ausgerichtet oder das Signal ist zu schwach. Ändert mit einem kleinen Schraubendreher die Empfindlichkeit am Poti. Kommen nur kurze Dauersignale, ist die Empfindlichkeit zu hoch. Dreht am Poti so lange, bis in der AN-Phase ein dezentes Flackern zu sehen ist (unteres Diagramm). Dann wird via UART auf diesem Kanal kommuniziert. Die Ausgabe in den Logs müsste nun mit Leben gefüllt sein.
Auslesen der Daten und Einbindung in Home Assistant
Ruft die Logs des Controllers auf. Über Home Assistant gibt es die entsprechende Schnittstelle, über WSL geht das mit dem Befehl
esphome logs stromzaehler-sml.yaml
Wenn alles bis hierher geklappt hat, müsste die Ausgabe sich stetig erweitern. Darin müssten auch Einträge nach dem folgenden Format auftauchen:
Hier findet ihr auch die Server-ID, die wir anfangs noch nicht kannten. Sie steht in runden Klammern und ist im Screenshot rot eingerahmt. Kopiert sie euch und fügt sie in der YAML-Datei in Zeilen, wo die server_id eingetragen werden muss (insgesamt vier mal).
Zur Kontrolle der Validität der Daten, könnt ihr den HEX-Wert mal umrechnen und checken, ob der Stromzählerwert korrekt übertragen wird. Im Beispiel oben:
0x056f8b25 entspricht 91196197. Multipliziert mit 0,0001 ergibt 9119,6 kWh
Ändert nun die YAML-Datei auf die für euch wichtigen Werte (Server-ID und ggf. andere OBIS-Codes) und flasht sie kabellos („Over the air“) auf den ESP
esphome run stromzaehler-sml.yaml
Seht im Home Assistant, ob die Werte dort ankommen. In aller Regel kommen die Werte dort an und können weiter verarbeitet werden. Ich habe mir noch einen Helfer gebaut, der den aktuellen Verbrauch in Kilowatt umrechnet. Das lässt sich mit anderen Energiequellen schöner in Diagrammen darstellen.
Fertig, ihr habt es geschafft! Kommentiert gerne, ob ihr diese Werte für andere Zwecke weiterverwendet. Realisiert ihr damit eine Nulleinspeisung oder beobachtet den Strompreis in Echtzeit?
Die MZLA Technologies Corporation hat mit Thunderbird 136.0.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.
Neuerungen von Thunderbird 136.0.1
Mit Thunderbird 136.0.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht. Die neue Version bringt mehrere Fehlerkorrekturen, welche sich in den Release Notes (engl.) nachlesen lassen.
Auf der c-base findet jeden Dienstag der NixOS-Stammtisch in Berlin statt.
Im September 2024 hatte ich mir dort NixOS auf meinem ThinkPad X201 installiert. Dabei hatte ich mich an der NixOS Installation von davidak orientiert. Die WLAN-Verbindung hatte ich anders eingerichtet, bin dann aber der Anleitung mit verschlüsselter Festplatte und LVM gefolgt.
Mein NixOS-Installer auf der c-base
Nach der Installation und Einrichtung von NixOS hatte ich das NixOS mit Xfce nicht wieder eingesetzt.
Gestern fand nun ein großes Update statt, da NixOS mit dem Channel stable alle 6 Monate erscheint.
Ich habe nun jeden Dienstag Zeit mein NixOS weiter kennenzulernen. Auf dem NixOS-Stammtisch treffen sich sehr erfahrende User*innen. Mein Fazit:
NixOS funktioniert völlig anders als andere Linux Distributionen und macht auch sehr viel Spaß.
Mit Firefox 136.0.2 behebt Mozilla das Problem, dass für Nutzer mit Hauptpasswort, auch wenn diese keine Synchronisation nutzen, dieses bei jedem Firefox-Start abgefragt worden ist.
Es wurde ein Fehler behoben, bei dem die Optionen „Cookies und Website-Daten“ sowie „Temporäre Dateien und Seiten im Cache“ nach dem Update auf Firefox 136 unerwartet aktiviert wurden, wenn in früheren Versionen die Chronik oder Website-Einstellungen beim Beenden von Firefox gelöscht werden sollten. Nutzer, welche bereits auf Firefox 136 aktualisiert haben, müssen diese Optionen manuell wieder deaktivieren.
Die mit Firefox 136 erst aktivierte CookieStore-API zum Setzen und Lesen von Cookies in JavaScript wurde aus Webkompatibilitätsgründen vorläufig wieder deaktiviert und wird zu einem späteren Zeitpunkt wieder aktiviert werden.
Ein Sichtbarkeitsproblem mit Radio-Buttons auf dunklen Hintergründen wurde korrigiert.
Verbessert wurde auch die CPU-Auslastung auf Windows, wenn der Bildschirm gesperrt oder der Laptop zugeklappt ist.
Darüber hinaus gab es noch eine weitere Webkompatibilitäts-Korrektur, die sich durch Scroll-Probleme bemerkbar machen konnte, sowie zwei behobene Absturzursachen.
