ubuntuusers.de

Wer IRC genutzt hat oder vielleicht noch nutzt, wird den Client HexChat kennen. Und sei es nur vom Namen her. Vor ein paar Tagen wurde Version 2.16.2 veröffentlicht. Was wohl die finale uns somit letzte Version darstellt.

Der Grund ist wie so oft der übliche. Das Projekt wurde längere Zeit nicht gewartet und niemand wollte den Job übernehmen.

Da der Code laut Ankündigung weiterhin auf Github vorhanden sein wird, hätte er auch nichts gegen einen Fork. Aus genannten Gründen und weil IRC heutzutage nicht mehr den Stellenwert hat den er früher hatte, wage ich es zu bezweifeln, dass jemand einen Fork erstellt. Zumindest keinen der längerfristig aktiv entwickelt wird.

Mozilla Hubs ist eine Plattform, um virtuelle Treffpunkte zu erstellen. Mozilla hat nun bekannt gegeben, wie genau es mit Hubs in Zusammenhang mit der Einstellung als Mozilla-Produkt weitergehen wird.

Was ist Mozilla Hubs?

Mit dem Start von Mozilla Hubs im April 2018 ging eine Online-Plattform an den Start, welche es Nutzern ermöglicht, sich in sogenannten Räumen virtuell zu treffen. Das Besondere an Hubs: es spielt sich komplett im Web ab – keine geschlossene Plattform, keine Installation einer Anwendung, keine Abhängigkeit von einem bestimmten Gerät. Einfach eine URL teilen und miteinander treffen. Hubs funktioniert in jedem Browser, am Smartphone – und auch mit der VR-Brille, wo Hubs als virtuelle Plattform sein volles Potenzial entfaltet. Mozilla Hubs ist quasi eine Miniatur-Ausgabe eines Web-basierten „Metaverse“, aber Open Source und mit Fokus auf Datenschutz, vom Macher des Firefox-Browsers.

So geht es mit Mozilla Hubs weiter

Vor wenigen Tagen hat Mozilla eine Umstrukturierung angekündigt, welche auch direkte Auswirkungen auf Mozilla Hubs hat. Nun hat Mozilla Details bekannt gegeben.

Mit dem 1. März 2024 wird Mozilla die Erstellung neuer Abonnements deaktivieren. Bestehende Kunden können ihre Instanz weiterhin nutzen. Am 1. April 2024 wird Mozilla ein Tool veröffentlichen, mit welchem sowohl Demo-Nutzer als auch Abonnenten ihre Daten herunterladen können. Am 31. Mai 2024 soll schließlich die Abschaltung von Mozilla Hubs erfolgen. Dies betrifft die Instanzen der Abonnenten, den Demo-Server sowie weitere von Mozilla betriebene Community-Ressourcen.

Die Hubs Community Edition, die seit Oktober 2023 verfügbar ist, ist als Open Source-Software zum selber Hosten nicht von Mozilla als Dienstleister abhängig. So hofft das Hubs-Team, dass die Software auch außerhalb von Mozilla eine Zukunft hat. Seitens Mozilla wird es ab dem 31. Mai 2024 jedoch keine Weiterentwicklungen und Fehlerbehebungen mehr geben.

Das geplante Tool zum Herunterladen der Daten soll alle mit der E-Mail-Adresse verknüpften Medien herunterladen können, einschließlich 3D-Modelle, Audiodateien, Bilddateien und Videodateien, die über Spoke hochgeladen wurden, sowie gLTFs von veröffentlichten Spoke-Szenen und Avataren. Das Tool wird es auch ermöglichen, alle Hubs-URLs abzurufen, einschließlich Szenen-URLs, Raum-URLs, Avatar-URLs und Spoke Projekt-URLs.

Von den Assets, die das Hubs-Team im Laufe der Jahre erstellt hat, sollen so viele wie möglich vor der Abschaltung als Open Source veröffentlicht werden.

Der Beitrag Das ist der Plan mit Mozilla Hubs erschien zuerst auf soeren-hentzschel.at.

Es ist so traurig, aber Firefox kennt wirklich nur noch eine Richtung, was die Marktanteile angeht. Dabei hat sich funktional in letzter Zeit so viel zum Besseren verändert und auch so manches Fehlverhalten von Mozilla hat sich verbessert.

Vor wenigen Tagen konnte man bei dem ausgewiesenen Mozilla-Experten Sören Hentzschel lesen, dass Mozilla nach dem unerwarteten Wechsel auf dem CEO-Posten mal wieder Leute entlässt, Dienste neu priorisiert und Firefox stärken will. Dies ist nur die jüngste Kehrtwende in einem jahrelangen Niedergang und seien wir ehrlich: Hätte Google nicht aus Wettbewerbsgründen ein Interesse am Überleben von Mozilla Firefox, hätte Alphabet die Kooperation mit Mozilla bei der Standardsuchmaschine schon längst beenden und dem Feuerfuchs den Todesstoß versetzen können.

Natürlich kommen jetzt wieder die üblichen Nörgler mit irgendwelchen Geschichte von vor dem Krieg, die sich in der Community schon lange verselbständigt haben. Damals als Mozilla die Extensions getötet hat, weshalb “Millionen” User abgewandert sind, weil man ohne drölfzig Extensions das Internet nicht nutzen kann oder damals als das Design geändert wurde. Wer kann schon ohne Menübar professionell arbeiten. Wir kennen das alles. Ich halte das für Quatsch, für den sich eine kleine Minderheit zu wichtig nimmt.

Sicherlich hat Mozilla einige fragwürdige Entscheidungen getroffen. Das Hin und Her mit Thunderbird, die Pocket-Geschichte, die zähe Entwicklung, als man noch erfolgreich war. Man könnte sicher einiges aufzählen. Aber Firefox war bereits auf dem absteigenden Ast und Mozilla stand unter Druck. In dieser Situation werden manchmal Entscheidungen getroffen, die sich im Nachhinein als falsch herausstellen. Die Geschichte ist immer offen und es ist immer leicht, sich im Nachhinein hinzustellen und alles besser gewusst zu haben.

Die Ursache für die Misere liegt aber woanders und das wird immer wieder thematisiert. Firefox ist ein Opfer der Entwicklungen im Mobilbereich. Immer weniger Menschen nutzen Desktopsysteme, immer mehr Menschen arbeiten nur noch mit Smartphones und Tablets. Es ist nicht so als ob Mozilla es nicht versucht hätte, aber alternative Systeme wie damals Firefox OS hatten keine Chance. Nichts besteht neben dem Duopol aus Android und iOS. Apple und Google haben mit ihren Systemen eine unangefochtene Dominanz und diktieren den Standardbrowser. Nur sehr wenige Menschen installieren hier überhaupt Alternativen und bei iOS war das dann bis zuletzt sogar nur die Oberfläche, weil die Apple-Engine festgelegt war.. Die Regulierungsbehörden haben das Thema viel zu lange missachtet und das was jetzt aus Brüssel kommt ist vermutlich zu wenig und zu spät.

Schaut man sich die Zahlen an, dann ist das aber noch ernüchternder als ich vermutete. Für Deutschland kommt Statista noch auf wenigstens 18% und der Sinkflug hat sich zuletzt auch verlangsamt. Weltweit sind es deutlich unter 10%. Selbst Apples Safari liegt hier deutlich vor dem traditionsreichen Open-Source-Browser. Jetzt kann man sagen, dass Statista halt auch nur eine Quelle ist und irgendwelche “gefühlten” Zahlen angeben. Ich führe aus datenschutzgründen nur eine sehr rudimentäre Statistik, die ziemlich fehleranfällig ist, weil sie auf Fingerprinting und Cookies verzichtet, aber selbst die Logs hier ergeben nur noch circa 25% für Firefox und über 40% für Chrome.

Das hat mich doch überrascht, weil Firefox bei Linux immer noch der Standardbrowser unter allen Distributionen ist und oft auch der einzig richtig gut mit Sicherheitsupdates versorgte Weg ins Internet. Zudem lässt sich Firefox immer noch deutlich besser für eine privatsphäre- und datenschutzorientierte Nutzungsweise konfigurieren als die meisten Chromium-Varianten (Brave, Vivalid, Ungoogled Chromium etc.). Bei der Zielgruppe dieser Seite hätte ich daher mehr Firefox-Nutzer vermutet. Zuletzt hat man hier im Bereich Trackingschutz einiges richtig gemacht und die neu eingeführte automatische Cookiebannersteuerung ist auch vielversprechend.

Eine Umkehr werden wir nicht mehr erleben. Für die Zukunft ist das bedenklich, weil Google seine Torwächterfunktion immer hemmungsloser ausnutzen kann. Zuletzt kommentierte ich dies anlässlicher der Blockade von Drittanbieter-Cookies. Ob Abspaltungen von Chromium wirklich eigenständig lebensfähig sind und sich fragwürdigen Entscheidungen von Google konsequent widersetzen können, wird sich noch zeigen. Wir werden es vermutlich zeitnah bei den Werbeblockern sehen.

Der Artikel Kommentar: Firefox im ewigen Niedergang erschien zuerst auf Curius

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.

Jetzt Mozilla VPN nutzen

Die Neuerungen vom Mozilla VPN 2.20

Mit dem Update auf das Mozilla VPN 2.20 ist es bei Nutzung eines Monats-Abos nun innerhalb der App möglich, ein Upgrade auf ein Jahres-Abo vorzunehmen. Ansonsten bringt das Update vor allem Fehlerbehebungen sowie Verbesserungen unter der Haube.

Der Beitrag Mozilla VPN 2.20 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Viele, die sich überlegen Linux zu nutzen bzw. die Linux erst seit kurzer Zeit verwenden, stellen sich die Frage wie sie helfen können. Meist führt das zu der Frage, welche Programmiersprache man kennen muss. Meine Antwort lautet, keine.

Viele Neulinge finden es beispielsweise erstrebenswert möglichst bald Änderungen am Linux-Kernel vorzunehmen. Ich sage, lasst es sein. Zumindest vorerst. Denn wenn es um den Kernel geht, arbeiten daran schon viele Leute, die euch deutlich überlegen sind. Und nein, ich bin keiner davon.

Meiner Meinung nach gibt es wichtigere Dinge.

Zum Beispiel das Erstellen einer guten Dokumentation für Endbenutzer für ein bestimmtes Programm. Denn viele Programmierer sind zwar gut, wenn es um das Programmieren geht. Aber sie sind unfähig oder unwillig eine gute Dokumentation zu erstellen.

Was auch oft fehlt, ist die Übersetzung einer grafischen Oberfläche eines Programms in eine andere Sprache als Englisch. Wer also sprachlich begabt ist, kann sich bei unzähligen Projekten austoben.

Oder offene “Issues”. Bei vielen Projekten sind oft sehr viele Issues noch offen. Viele dieser “Probleme” werden von Nutzern erzeugt, weil sie das Programm falsch benutzt. Andere hingegen, wurden zwischenzeitlich aufgrund einer anderen Meldung bereits behoben, aber nicht alle Issues geschlossen. Hier zu testen, ob ein gemeldetes Problem noch aktuell ist, kann den Entwicklern ebenfalls helfen. Oder vielleicht könnt ihr ein Problem sogar selbst beheben und den entsprechenden Code beisteuern.

Vielleicht denkt sich nun der eine oder andere Leser dieses Artikels, dass es vielleicht doch sinnvoller ist, nicht gleich am Kernel zu arbeiten. Aber er stellt sich die Frage, wo anfangen? Im Grunde ist das ganz einfach. Schaut euch an, welche Programme ihr selbst nutzt. Dann schaut euch beispielsweise die Issues an. Oder prüft, ob die grafische Oberfläche auch in einer Sprache angeboten wird, die ihre sprecht und ob es Verbesserungsmöglichkeiten gibt. Oder helft Leuten bei Ihren Problemen. Oder veröffentlicht Artikel zu bestimmten Dingen die es nicht schon unzählige Male im Internet gibt.

Ich persönlich habe ehrlich gesagt mehr Respekt vor Leuten die sich um solche “niederen Aufgaben” kümmern als vor den Leuten die gleich nach der ersten Installation einer Linux-Distribution am Kernel mitarbeiten wollen. Denn ohne die kleinen Zahnräder funktionieren auch die großen meist nicht.

Seit drei Jahren arbeitet das unabhängige Entwicklerteam hinter Asahi Linux daran, Linux auf Apple Silicon Macs lauffähig zu machen.

Anfänglich war Asahi Linux ein "instabiles Experiment", mittlerweile ist es aber ein überraschend funktionales und benutzbares Desktop-Betriebssystem geworden. Sogar Linus Torvalds, der Schöpfer von Linux, hat es benutzt, um Linux auf Apples Hardware laufen zu lassen. Apple selbst beteiligt sich nicht an diesem Projekt.

Seit Dezember 2022 hat das Team seinen Open-Source-GPU-Treiber für die M1- und M2-Chips stetig verbessert. Nun hat es einen wichtigen Meilenstein erreicht: Die OpenGL- und OpenGL ES-Unterstützung des Asahi-Treibers ist wieder einmal besser als die von Apple in macOS. Der neueste Asahi-Treiber unterstützt OpenGL 4.6 und OpenGL ES 3.2, die neuesten Versionen dieser APIs. Apples macOS hingegen unterstützt nur OpenGL 4.1, das schon seit 2010 aktuell ist.

Die Entwicklerin Alyssa Rosenzweig erklärt in einem Blogbeitrag, warum die Implementierung der neueren APIs auf Apples GPUs so schwierig war. Trotz der Herausforderungen hat das Asahi-Team es geschafft, einen performanten und konformen Treiber zu entwickeln. Als Nächstes will das Team Vulkan unterstützen, eine moderne Grafik-API mit geringem Overhead. Vulkan ist in macOS nur mit Übersetzungsschichten wie MoltenVK verfügbar, die die Leistung beeinträchtigen können.

Asahi Linux ist noch nicht perfekt. Es gibt einige Funktionen, die noch nicht funktionieren, z. B. Thunderbolt und Touch ID. Trotzdem ist es eine beeindruckende Leistung, dass ein kleines Team von Entwicklern so viel erreicht hat.

Asahi Linux macht Apple Silicon Macs zu einer attraktiven Option für Linux-Benutzer. Die überlegene OpenGL-Unterstützung und die bevorstehende Vulkan-Unterstützung sind wichtige Fortschritte, die Linux auf dieser Plattform noch attraktiver machen.

Quellen:

Asahi Linux Projekt: https://asahilinux.org

Blogbeitrag von Alyssa Rosenzweig: https://rosenzweig.io/blog/conformant-gl46-on-the-m1.html

Mozilla steht vor einer Umstrukturierung. Wenige Tage nach der Ernennung einer neuen CEO streicht Mozilla 60 Stellen und kürzt Investitionen in manchen Bereichen, um dafür stärker in andere Bereiche zu investieren. Mozilla Hubs wird eingestellt.

Vor wenigen Tagen hat Mozilla die Ernennung von Laura Chambers als neue CEO der Mozilla Corporation angekündigt. Heute hat Mozilla die Mitarbeiter über eine Umstrukturierung informiert. Demnach werden 60 Stellen gestrichen, was in etwa fünf Prozent der Gesamtbelegschaft entsprechen soll.

So möchte Mozilla in manchen Produktbereichen weniger investieren, um sich stärker auf andere Bereiche zu konzentrieren. Am stärksten davon betroffen ist Mozilla Hubs, was im Laufe des Jahres eingestellt werden soll. Aber auch die Investitionen in die eigene Mastodon-Instanz mozilla.social, das Mozilla VPN, Firefox Relay und den letzte Woche in den USA erst gestarteten Dienst zur Entfernung persönlicher Informationen von Personen-Suchmaschinen sollen laut TechCrunch reduziert werden.

Firefox Mobile wird in einem Statement von Mozilla (via Bloomberg) explizit als Produkt genannt, welches dafür mehr Ressourcen erhalten soll. Auch das Thema Künstliche Intelligenz und KI-Integration in Firefox wird einen noch stärkeren Fokus als bisher einnehmen. Zu diesem Zweck werden die Teams, die an Pocket, Content sowie Künstliche Intelligenz / Maschinellem Lernen arbeiten, mit der Firefox-Organisation zusammengeführt.

Wie sich das Ganze konkret auswirken wird, bleibt abzuwarten. Während sich einige Firefox-Fans darüber freuen werden, dass der Browser als Hauptprodukt einmal mehr einen stärkeren Fokus erhalten soll, klingt dies gleichzeitig nach einem signifikanten Strategiewechsel, der eine Diversifizierung der Einnahmequellen nicht länger priorisiert.

Das vollständige interne Memo (via TechChrunch), übersetzte Fassung:

Zurückfahren der Investitionen in mozilla.social: Mit mozilla.social gingen wir 2023 eine große Wette ein, um eine sicherere, bessere Social-Media-Erfahrung zu schaffen, die auf Mastodon und dem Fediverse basiert. Unser anfänglicher Ansatz basierte auf der Überzeugung, dass Mozilla schnell ein großes Ausmaß erreichen muss, um die Zukunft der sozialen Medien effektiv gestalten zu können. Das war eine edle Idee, aber wir hatten Schwierigkeiten, sie umzusetzen. Wir haben mozilla.social zwar stark mit Ressourcen ausgestattet, um diese ehrgeizige Idee zu verfolgen, aber im Nachhinein betrachtet hätte uns ein bescheidenerer Ansatz ermöglicht, mit wesentlich größerer Agilität an diesem Bereich teilzunehmen. Die Maßnahmen, die wir heute ergreifen, werden diese strategische Korrektur vornehmen, indem wir mit einem viel kleineren Team arbeiten, um am Mastodon-Ökosystem teilzunehmen und kleinere Experimente schneller zu den Menschen zu bringen, die sich für die mozilla.social-Instanz entscheiden.

Schutz, Experimentieren und Identität (PXI): Wir reduzieren die Investitionen in einige unserer eigenständigen Verbraucherprodukte im Bereich Sicherheit und Datenschutz. Wir reduzieren unsere Investitionen in Marktsegmenten, die von Wettbewerbern verdrängt werden und in denen es schwierig ist, ein differenziertes Angebot zu liefern. Konkret planen wir, unsere Investitionen in VPN, Relay und Online Footprint Scrubber zu reduzieren. Wir werden weiterhin in Produkte investieren, die den Kundenbedürfnissen in wachsenden Marktsegmenten entsprechen.

Hubs: Seit Anfang 2023 haben wir eine Verschiebung des Marktes für virtuelle 3D-Welten erlebt. Mit Ausnahme von Spielen, Bildung und einer Handvoll Nischenanwendungen hat sich die Nachfrage von virtuellen 3D-Welten entfernt. Dies wirkt sich auf alle Akteure der Branche aus. Die Benutzer- und Kundenbasis von Hubs ist nicht robust genug, um den weiteren Einsatz von Ressourcen gegen den Gegenwind der ungünstigen Nachfrageverschiebung zu rechtfertigen. Wir werden den Dienst abwickeln und den Kunden einen Plan für einen geordneten Ausstieg mitteilen.

Verkleinerung des Mitarbeiterteams: In Anbetracht des Personalabbaus und des geringeren Budgets für die Mitarbeiterzahl bei MozProd wurden einige Funktionen in der Personalabteilung und anderen Support-Organisationen konsolidiert, damit wir unserem Produktportfolio das richtige Maß an Unterstützung bieten können. Optimierung unserer Organisation, um den Fokus zu schärfen.

Im Jahr 2023 begann die generative KI, die Industrielandschaft schnell zu verändern. Mozilla ergriff die Gelegenheit, vertrauenswürdige KI in Firefox einzubringen, vor allem durch die Übernahme von Fakespot und die darauf folgende Produktintegration. Darüber hinaus ist die Suche nach großartigen Inhalten immer noch ein wichtiger Anwendungsfall für das Internet. Daher werden wir als Teil der heutigen Änderungen Pocket, Content und die KI/ML-Teams, die Inhalte unterstützen, mit der Firefox-Organisation zusammenführen. Weitere Details zu den spezifischen organisatorischen Änderungen werden in Kürze folgen. Innerhalb von MozProd gibt es keine Änderungen bei MDN, Ads oder Fakespot. Auch in den Bereichen Legal/Policy, Finance & Business Operations, Marketing und Strategy & Operations gibt es keine Änderungen.

Der Beitrag Mozilla strukturiert um, Hubs wird eingestellt erschien zuerst auf soeren-hentzschel.at.

Diese Änderung wird es der UBports Foundation ermöglichen, Fehler- und Sicherheitskorrekturen schneller als bisher bereitzustellen, um ein stabileres und zuverlässigeres Ubuntu Touch-Erlebnis zu gewährleisten.

Die UBports Foundation hat gestern angekündigt, dass sie für zukünftige OTA (Over-the-Air)-Updates für ihr mobiles Betriebssystem Ubuntu Touch zu einem Fixed-Release-Modell wechseln wird.

Vor fast einem Jahr hat die UBports Foundation das erste Ubuntu Touch OTA-Update auf Basis von Ubuntu 20.04 LTS veröffentlicht, nachdem sie jahrelang an der Migration von der Ubuntu 16.04 (Xenial Xerus) Serie gearbeitet hatte. Dieser Schritt brachte viele Vorteile für die Nutzer von Ubuntu Touch mit sich, führte aber auch einige Probleme mit sich, wie z.B. die Tatsache, dass sie keine individuellen Fehlerbehebungen oder Sicherheitslücken veröffentlichen können, ohne alle anderen Änderungen, die in der Codebasis gelandet sind, zu veröffentlichen oder die Tatsache, dass sie die Entwicklung einfrieren müssen, wenn ein neues OTA-Update erscheint.

Um diese Probleme, die durch die Umstellung von Ubuntu 16.04 auf Ubuntu 20.04, auf dem die aktuellen Ubuntu Touch-Builds basieren, zu beheben, hat die UBports Foundation einen Plan entwickelt, um zu einem Fixed-Release-Modell zu wechseln, wenn sie Ubuntu Touch auf die kommende Ubuntu 24.04 LTS (Noble Numbat) Version umstellen.

"Mit dem bevorstehenden Upgrade des Basis-Betriebssystems Ubuntu 24.04 nehmen wir die Gelegenheit wahr, unser Release-Modell zu ändern: Wir planen, auf das Fixed-Release-Modell umzustellen", so die UBports Foundation.

Diese Änderung hat keinerlei Auswirkungen auf Ubuntu Touch Nutzer. Der Wechsel zu einem Fixed-Release-Modell ermöglicht es der UBports Foundation, Fehler- und Sicherheitskorrekturen schneller als bisher bereitzustellen, um die Stabilität und Zuverlässigkeit von Ubuntu Touch zu erhöhen.

Das neue Ubuntu Touch Versionsmodell wird das Format <Jahr>.<Monat>.<Minor> verwenden, wobei die <Jahr> und <Monat> Versionsstrings mit dem erwarteten Jahr und Monat der jeweiligen Version nummeriert und der <Minor> Versionsstring bei 0 beginnt (z.B. 24.6.0), wobei Minor Releases um 1 erhöht werden.

Die UBports Foundation sagte auch, dass sie plant, alle sechs Monate ein grosses Funktionsupdate für Ubuntu Touch zu veröffentlichen und alle zwei Monate eine kleinere Version. Sie sagten auch, dass jede grössere Funktionsaktualisierung etwa einen Monat lang unterstützt wird, nachdem die nächste grössere Funktionsaktualisierung veröffentlicht wurde.

Quelle: https://ubports.com/en/blog/ubports-news-1/post/announcement-of-release-model-changes-3920

Nachdem ich mich vor ein paar Wochen ausführlich mit der Installation von Fedora Asahi Linux auseinandergesetzt habe, geht es jetzt um die praktischen Erfahrungen. Der Artikel ist ein wenig lang geworden und geht primär auf Tools ein, die ich in meinem beruflichen Umfeld oft brauche.

Ich habe mich für die Gnome-Variante von Fedora Asahi Linux entschieden, die grundsätzlich ausgezeichnet funktioniert. Dazu aber gleich eine Einschränkung: Der Asahi-Entwickler Hector Martin ist KDE-Fan; insofern ist die KDE-Variante besser getestet und sollte im Zweifelsfall als Desktop-System vorgezogen werden.

Hardware-Unterstützung

Asahi Linux unterstützt aktuell noch keine Macs mit M3-CPUs. Außerdem hapert es noch bei USB-C-Displays (HDMI funktioniert), einigen Thunderbolt-/USB4-Features und der Mikrofon-Unterstützung. (Die Audio-Ausgabe funktioniert, bei den Notebooks anscheinend sogar in sehr hoher Qualität. Aus eigener Erfahrung kann ich da beim Mac Mini nicht mitreden, dessen Lautsprecher ist ja nicht der Rede wert.) Auf die Authentifizierung mit TouchId müssen Sie auch verzichten. Einen guten Überblick über die Hardware-Unterstützung finden Sie am Ende der folgenden Seite:

https://asahilinux.org/fedora/

Ich habe Fedora Asahi Linux nur auf einem Mac Mini M1 getestet (16 GB RAM). Damit habe ich sehr gute Erfahrungen gemacht. Das System ist genauso leise wie unter macOS (sprich: lautlos, auch wenn der Lüfter sich immer minimal dreht). Aber ich kann keine Aussagen zur Akku-Laufzeit machen, weil ich aktuell kein MacBook besitze. Wie gut Linux die Last zwischen Performance- und Efficiency-Cores verteilt, kann ich ebenfalls nicht sagen.

Der Ruhezustand funktioniert, auch das Aufwachen ;-) Dazu muss allerdings kurz die Power-Taste gedrückt werden. Ein Tastendruck oder ein Mausklick reicht nicht.

Tastatur

An meinem Mac Mini ist eine alte Apple-Alu-Tastatur angeschlossen. Grundsätzlich funktioniert sie auf Anhieb. Ein paar kleinere Optimierungen habe ich vor einiger Zeit hier beschrieben.

Konfiguration bei der Linux-Installation

Ich habe ja schon in meinem Blog-Beitrag zur Installation festgehalten: Während der Installation von Fedora gibt es praktisch keine Konfigurationsmöglichkeiten. Insbesondere können Sie weder die Partitionierung noch das Dateisystem beeinflussen (es gibt eine Partition für alles, das darin enthaltene Dateisystem verwendet btrfs ohne Verschlüsselung).

Wenn Sie davon abweichende Vorstellungen haben und technisch versiert sind, können Sie anfänglich nur einen Teil des freien Disk-Speichers für das Root-System von Fedora nutzen und später eine weitere Partition (z.B. für /home) nach eigenen Vorstellungen hinzuzufügen.

Swap-File

Während der Installation wurde auf meinem System die Swap-Datei /var/swap/swapfile in der Größe von 8 GiB eingerichtet (halbe RAM-Größe?). Außerdem verwendet Fedora standardmäßig Swap on ZRAM. Damit kann Fedora gerade ungenutzte Speicherseite in ein im RAM befindliches Device auslagern. Der Clou: Die Speicherseiten werden dabei komprimiert.

Beim meiner Konfiguration (16 GiB RAM, 8 GiB Swap-File, 8 GiB ZRAM-Swap) glaubt das System, dass es über fast 32 GiB Speicherplatz verfügen kann. (Etwas RAM wird für das Grafiksystem abgezwackt.) Ganz geht sich diese Rechnung natürlich nicht aus, weil ja das ZRAM-Swap selbst wieder Arbeitsspeicher kostet. Aber sagen wir 4 GB ZRAM entspricht mit Komprimierung 8 GB Speicherplatz + 11 GB restliches RAM + 8 GB Swapfile: das würde 27 GB Speicherplatz ergeben. Wenn nicht alle Programme zugleich aktiv sind, kann man damit schon arbeiten.

cat /proc/swaps

Filename             Type          Size      Used    Priority
/var/swap/swapfile   file          8388576   0       -2
/dev/zram0           partition     8388592   0       100

free -m
           total    used     free      shared  buff/cache   available
Mem:       15444    8063     2842        1521        7112        7381
Swap:      16383       0    16383

Weil ich beim Einsatz virtueller Maschinen gescheitert bin (siehe unten), kann ich nicht beurteilen, ob diese Konfiguration mit der Arbeitsspeicherverwaltung von macOS mithalten kann. Die funktioniert nämlich richtig gut. Auch macOS komprimiert Teile des gerade nicht genutzten Speichers und kompensiert so (ein wenig) den unendlichen Apple-Geiz, was die Ausstattung mit RAM betrifft (oder die Geldgier, wenn mehr RAM gewünscht wird).

Gnome + Fractional Scaling: mühsam wie vor 10 Jahren

Ein altes Problem: Auf meinem 4k-Monitor (27 Zoll) ist der Bildschirminhalt bei einer Skalierung von 100 % arg klein, bei 200 % sinnlos groß. Seit Jahren wird gepredigt, wie toll Gnome + Wayland ist, aber Fractional Scaling funktioniert immer noch nicht standardmäßig?

Dieses Problem lässt sich zum Glück lösen:

gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

Aus Gnome ausloggen, neu einloggen. Jetzt können in den Systemeinstellungen 125 % eingestellt, optimal für mich.

Die meisten Programme, die ich üblicherweise verwende, kommen mit 125 % gut zurecht. Wichtigste Ausnahme (für mich): Emacs. Die Textdarstellung ist ziemlich verschwommen. Angeblich gibt es eine Wayland-Version von Emacs (siehe hier), aber ich habe noch nicht versucht, sie zu installieren.

Webbrowser: kein Google Chrome

Als Webbrowser ist standardmäßig Firefox installiert und funktioniert ausgezeichnet. Chromium steht alternativ auch zur Verfügung (dnf install chromium). Ich bin allerdings, was den Webbrowser betrifft, in der Google-Welt zuhause. Ich habe mich vor über 10 Jahren für Google Chrome entschieden. Lesezeichen, Passwörter usw. — alles bei Google. (Bitte die Kommentare nicht für einen Browser-Glaubenskrieg nutzen, ich werde keine entsprechenden Kommentare freischalten.)

Insofern trifft es mich hart, dass es aktuell keine Linux-Version von Google Chrome für arm64 gibt. Ich habe also die Bookmarks + Passwörter nach Firefox importiert. Bookmarks sind easy, Passwörter müssen in Chrome in eine CSV-Datei exportiert und in Firefox wieder importiert werden. Mit etwas Webrecherche auch nicht schwierig, aber definitiv umständlich. Und natürlich ohne Synchronisation. (Für alle Firefox-Fans: Ja, auch Firefox funktioniert großartig, ich habe überhaupt keine Einwände. Wenn ich die Entscheidung heute treffen würde, wäre vielleicht Firefox der Gewinner. Google bekommt auch so genug von meinen Daten …)

Drag&Drop von Nautilus nach Firefox funktionierte bei meinen Tests nicht immer zuverlässig. Ich glaube, dass es sich dabei um ein Wayland-Problem handelt. Ähnliche Schwierigkeiten hatte ich auf meinen »normalen« Linux-Systemen (also x86) mit Google Chrome auch schon, wenn Wayland im Spiel war.

Nextcloud: perfekt

Zum Austausch meiner wichtigsten Dateien zwischen diversen Rechnern verwende ich Nextcloud. Ich habe nextcloud-client-nautilus installiert und eingerichtet, funktioniert wunderbar. Damit im Panel das Nextcloud-Icon angezeigt wird, ist die Gnome-Erweiterung AppIndicator and KStatusNotifierItem Support erforderlich.

Spotify + Firefox: gescheitert

Ich höre beim Arbeiten gerne Musik. Die Spotify-App gibt es nicht für arm64. Kein Problem, ich habe mich schon lange daran gewöhnt, Spotify im Webbrowser auszuführen. Aber Spotify hält nichts von Firefox: Wiedergabe von geschützten Inhalten ist nicht aktiviert.

Das Problem ist bekannt und gilt eigentlich als gelöst. Es muss das Widevine-Plugin installiert werden. Asahi greift dabei auf ein Paket der ChromeBooks zurück. Es kann mit widevine-installer installiert werden. (widevine-installer befindet sich im gleichnamigen Paket und ist standardmäßig installiert.) Gesagt, getan:

sudo widevine-installer 

This script will download, adapt, and install a copy of the Widevine
Content Decryption Module for aarch64 systems.

Widevine is a proprietary DRM technology developed by Google.
This script uses ARM64 builds intended for ChromeOS images and is
not supported nor endorsed by Google. The Asahi Linux community
also cannot provide direct support for using this proprietary
software, nor any guarantees about its security, quality,
functionality, nor privacy. You assume all responsibility for
usage of this script and of the installed CDM.

This installer will only adapt the binary file format of the CDM
for interoperability purposes, to make it function on vanilla
ARM64 systems (instead of just ChromeOS). The CDM software
itself will not be modified in any way.

Widevine version to be installed: 4.10.2662.3
...
Installing...
Setting up plugin for Firefox and Chromium-based browsers...
Cleaning up...

Installation complete!
Please restart your browser for the changes to take effect.

Nach einem Firefox-Neustart ändert sich: nichts. Ein weiterer Blick in discussion.fedoraproject.org verrät: Es muss auch der User Agent geändert werden, d.h. Firefox muss als Betriebssystem ChromeOS angeben:

Mozilla/5.0 (X11; CrOS aarch64 15329.44.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36

Es gibt zwei Möglichkeiten, den User Agent zu ändern. Die eine besteht darin, die Seite about:config zu öffnen, die Option general.useragent.override zu suchen und zu ändern. Das gilt dann aber für alle Webseiten, was mich nicht wirklich glücklich macht.

Die Alternative besteht darin, ein UserAgent-Plugin zu installieren. Ich habe mich für den User-Agent Switcher and Manager entschieden.

Langer Rede kurzer Sinn: Mit beiden Varianten ist es mir nicht gelungen, Spotify zur Zusammenarbeit zu überreden. An dieser Stelle habe ich nach rund einer Stunde Frickelei aufgegeben. Es gibt im Internet Berichte, wonach es funktionieren müsste. Vermutlich bin ich einfach zu blöd.

Spotify + Chromium: geht

Da wollte ich Firefox eine zweite Chance geben … Stattdessen Chromium installiert, damit funktioniert Spotify (widevine-installer vorausgesetzt) auf Anhieb. Sei’s drum.

Chromium läuft übrigens standardmäßig als X-Programm (nicht Wayland), aber nachdem ich den Browser aktuell nur als Spotify-Player benutze, habe ich mir nicht die Mühe gemacht, das zu ändern.

Visual Studio Code: weitgehend problemlos

VSCode lässt sich unkompliziert installieren; unter https://code.visualstudio.com/download gibt es arm64-Pakete (RPM).

Wie Emacs und Chromium läuft auch Code vorerst als X-Programm. Entsprechend unscharf ist die Schrift bei 125% Scaling. Das ArchWiki verrät, dass beim Programmstart die Option --ozone-platform-hint=auto übergeben werden muss. Das funktioniert tatsächlich: Plötzlich gestochen scharfe Schrift auch in Code.

Ich habe mir eine Kopie von code.desktop erstellt und die gerade erwähnte Option in die Exec-Zeile eingebaut. Bingo!

cp /usr/share/applications/code.desktop .local/share/applications/

qemu/libvirt/virt-manager: keine Grafik, keine Maus, keine Tastatur, kein Glück

Meine Arbeit spielt sich viel in virtuellen Maschinen und Containern ab. QEMU und die libvirt-Bibliotheken sind standardmäßig installiert, die grafische VM-Verwaltung gibt es mit dnf install virt-manager dazu.

Als nächstes habe ich mir ein Daily-ISO-Image für Arm64 von Ubuntu 24.04 heruntergeladen und versucht, es in einer virtuellen Maschine zu installieren. Kurz nach dem Start stürzt der virt-manager ab. Die virtuelle Maschine läuft weiter, allerdings nur im Textmodus. Später bleibt die die Installation in einer snap-Endlosschleife hängen. Nun gut, es ist eine Entwicklerversion, die noch nicht einmal offiziellen Beta-Status hat.

Nächster Versuch mit 23.10. Allerdings gibt es auf cdimage.ubuntu.com kein Desktop-Image für arm64!? Gut, ich nehme das Server-Image und baue dieses nach einer Minimalinstallation mit apt install ubuntu-desktop in ein Desktop-System um. Allerdings stellt sich heraus, dass apt sehr lange braucht (Größenordnung: eine Stunde, bei nur sporadischer CPU-Belastung; ich weiß nicht, was da schief läuft). Die Textkonsole im Viewer von virt-manager ist zudem ziemlich unbrauchbar. Installation fertig, Neustart der virtuellen Maschine. Es gelingt nicht, den Grafikmodus zu aktivieren.

Dritter Versuch, Debian 12 für arm64. Obwohl ich mich für eine Installation im Grafikmodus entscheide, erscheinen die Setup-Dialoge in einem recht trostlosen Textmodus (so, als würde die Konsole keine Farben unterstützen).

Schön langsam dämmert mir, dass mit dem Grafiksystem etwas nicht stimmt. Tatsächlich hat keine der virtuellen Maschinen ein Grafiksystem! (virt-manager unter x86 richtet das Grafiksystem automatisch ein, und es funktioniert — aber offenbar ist das unter arm64 anders.) Ich füge also das Grafiksystem manuell hinzu, aber wieder treten diverse Probleme auf: der VGA-Modus funktioniert nicht, beim Start der VM gibt es die Fehlermeldung failed to find romfile vgabios-stdvga.bin. QXL lässt sich nicht aktivieren: domain configuration does not support video model qxl. RAMfb führt zu einem EFI-Fehler während des Startups. Zuletzt habe ich mit virtio Glück. Allerdings funktioniert jetzt die Textkonsole nicht mehr, der Bootvorgang erfolgt im Blindflug.

Der Grafikmodus erscheint, aber die Maus bewegt sich nicht. Klar, weil der virt-manager auch das Mauseingabe-Modul nicht aktiviert hat. Ich füge auch diese Hardware-Komponente hinzu. Tatsächlich lässt sich der Mauscursor nach dem nächsten Neustart nutzen — aber die Tastatur geht nicht. Ja, die fehlt auch. Wieder ‚Gerät hinzufügen‘, ‚Eingabe/USB-Tastatur‘ führt zum Ziel. Vorübergehend habe ich jetzt ein Erfolgserlebnis, für ein paar Minuten kann ich Ubuntu 23.10 tatsächlich im Grafikmodus verwenden. Ich kann sogar eine angemessene Auflösung einstellen. Aber beim nächsten Neustart bleibt der Monitor schwarz: Display output is not active.

An dieser Stelle habe ich aufgegeben. Die nächste Auflage meines Linux-Buchs (die steht zum Glück erst 2025 an) könnte ich in dieser Umgebung nicht schreiben. Dazu brauche ich definitiv eine Linux-Installation auf x86-Hardware.

Docker, pardon, Podman: voll OK

Red Hat und Fedora meiden Docker wie der Teufel das Weihwasser. Dafür ist die Eigenentwicklung Podman standardmäßig installiert (Version 4.9). Das Programm ist weitestgehend kompatibel zu Docker und in der Regel ein guter Ersatz.

Ich setze in Docker normalerweise stark auf docker compose. Dieses Subkommando ist in Podman noch nicht integriert. Abhilfe schafft das (einigermaßen kompatible) Python-Script podman-compose, das mit dnf installiert wird und aktuell in Version 1.0.6 vorliegt.

Mein Versuch, mit Podman mein aus LaTeX und Pandoc bestehendes Build-System für meine Bücher zusammenzubauen, gelang damit überraschend problemlos. In compose.yaml musste ich die Services mit privileged: true kennzeichnen, um diversen Permission-denied-Fehlern aus dem Weg zu gehen. Auf jeden Fall sind hier keine unlösbaren Hürden aufgetreten.

Fazit

Soweit Asahi Linux mit Ihrem Mac kompatibel ist und Sie keine Features nutzen möchten, die noch nicht unterstützt werden (aus meiner Sicht am schmerzhaftesten: USB-C-Monitor, Mikrofon), funktioniert es großartig. Einerseits die Apple-Kombination aus hoher Performance und Stille, andererseits Linux mit all seinen Konfigurationsmöglichkeiten. Was will man mehr?

Leider sind die arm64-Plattform (genaugenommen aarch64) und Wayland noch immer nicht restlos Linux-Mainstream. Alle hier beschriebenen Ärgernisse hatten irgendwie damit zu tun — und nicht mit Asahi Linux! Der größte Stolperstein für mich: Mit virt-manager lässt sich nicht vernünftig arbeiten. Mag sein, dass sich diese Probleme umgehen lassen (Gnome Boxes?; Cockpit), aber ich befürchte, dass die Probleme tiefer gehen.

Eine gewisse Ironie an der Geschichte besteht darin, dass ich gerade am Raspberry-Pi-Buch arbeite: Raspberry Pi OS ist mittlerweile ebenfalls für die arm64-Architektur optimiert, es verwendet ebenfalls Wayland. Aber Fractional Scaling ist für den PIXEL Desktop sowieso nicht vorgesehen, damit entfallen alle damit verbundenen Probleme. So fällt es nicht auf, dass diverse Programme via XWayland laufen. Und um die arm64-Optimierungen hat sich die Raspberry Pi Foundation in den letzten Monaten gekümmert — zumindest, soweit es für den Raspberry Pi relevante Programme betrifft. Ich arbeite also momentan sowie schon in einer arm64-Welt, und es funktioniert verblüffend gut!

Wenn es also außer dem Raspberry Pi und den MacBooks noch ein paar »normale« Notebooks mit arm64-CPUs gäbe, würde das sowohl dem Markt als auch der Stabilität von Linux auf dieser Plattform gut tun.

Bleibt noch die Frage, ob Asahi Linux besser als macOS ist. Schwer zu sagen. Für hart-gesottene Linux-Fans sicher. Für meine alltägliche Arbeit ist der größte Linux-Pluspunkt absurderweise ein ganz winziges Detail: Ich verwende ununterbrochen die Linux-Funktion, dass ich Text mit der Maus markieren und dann sofort mit der mittleren Maustaste wieder einfügen kann. macOS kann das nicht. Für macOS spricht hingegen die naturgemäß bessere Unterstützung der Apple-Hardware.

Losgelöst davon funktionieren fast alle gängigen Open-Source-Tools auch unter macOS. Über den Desktop von macOS kann man denken, wie man will; ich kann damit leben. Hundertprozentig glücklich machen mich auch Gnome oder KDE nicht. In jedem Fall ist es unter macOS wie unter Linux mit etwas Arbeit verbunden, den Desktop so zu gestalten, wie ich ihn haben will.

PS: Ein persönliches Nachwort

Seit zwei Monaten verwende ich versuchsweise macOS auf einem Mac Mini (wie beschrieben, M1-CPU + 16 GB RAM) als Hauptdesktop. Ich schreibe/überarbeite dort meine Bücher, bereite den Unterricht vor, administriere Linux-Server, entwickle Code. Virtuelle Maschinen laufen mit UTM. Docker funktioniert gut, allerdings stört, dass der Speicher für Docker fix alloziert wird. (Docker unterstützt sogar Rosetta. Ich habe eine Docker-Umgebung, die ein x86-Binary enthält, zu dem es kein arm64-Äquivalent gibt. Und es läuft einfach, es ist schwer zu glauben …)

Ich verwende Chrome als Webbrowser, Thunderbird als E-Mail-Programm, LibreOffice für Office-Aufgaben, Gimp als Bitmap-Editor, draw.io als Zeichenprogramm, Emacs + Code als Editoren, Skim als PDF-Viewer. Im Terminal sind diverse SSH-Sessions aktiv, so dass ich den Raspberry Pi, meine Linux-Server usw. administrieren kann. Zusatzsoftware installiere ich mit brew so unkompliziert wie mit dnf oder apt. Im Prinzip bin ich auf keine unüberwindbaren Hindernisse gestoßen, um meine alltägliche Arbeit auszuführen.

Es gibt nur ganz wenige originale macOS-Programme, die ich regelmäßig ausführe: das Terminal, Preview + Fotos. Außerdem finde ich es praktisch, dass ich M$ Office nativ verwenden kann. Ich hasse Word zwar abgrundtief, muss aber beruflich doch hin und wieder damit arbeiten. Das habe ich bisher auf einem Windows-Rechner erledigt.

Letzten Endes ist der Grund für dieses Experiment banal: Mich nervt der Lüfter meines Linux-Notebooks (ein fünf Jahre alter Lenovo P1) immer mehr. Wenn ich die meiste Zeit Ruhe haben will, muss ich den Turbo-Modus der CPU deaktivieren. Ist es für Intel/AMD wirklich unmöglich, eine CPU zu bauen, die so energieeffizient ist wie die CPUs von Apple? Kann keiner der Mainstream-Notebook-Hersteller (Lenovo, Dell etc.) ein Notebook bauen, das ganz gezielt für den leisen Betrieb gedacht ist, OHNE die Performance gleich komplett auf 0 zu reduzieren?

Im Unterschied zum Lenovo P1 läuft mein Mac komplett lautlos und ist gleichzeitig um ein Mehrfaches schneller. Es ist nicht auszuschließen, dass mein nächstes Notebook keine CPU von Intel oder AMD haben wird, sondern eine M3- oder M4-CPU von Apple. Die Option, auf diesem zukünftigen MacBook evt. auch Linux ausführen zu können, ist ein Pluspunkt und der Grund, weswegen ich mich so intensiv mit Asahi Linux auseinandersetze.

Links/Quellen

• Asahi installieren: https://kofler.info/fedora-asahi-remix/
• Hardware-Unterstützung: https://asahilinux.org/fedora/
• Swap on RAM: https://fedoraproject.org/wiki/Changes/SwapOnZRAM
• Mac-Tastatur unter Linux: https://kofler.info/apple-aluminium-tastatur-unter-linux
• Firefox + Widevine: https://docs.fedoraproject.org/en-US/fedora-asahi-remix/faq/#_how_do_i_access_protected_content_in_browsers_widevine_drm, https://discussion.fedoraproject.org/t/firefox-and-widevine-aarch64-support/86797/4
• Emacs für Wayland: https://discussion.fedoraproject.org/t/wayland-native-emacs/99994
• VSCode für Wayland: https://wiki.archlinux.org/title/Wayland#Electron
• Podman Compose Permission Denied: https://stackoverflow.com/questions/72182709/weird-permissions-podman-docker-compose-volume

Ich habe es nicht ausprobiert, aber Sie können auch Ubuntu auf M1/M2-Macs installieren. Canonical überlegt anscheinend sogar, das irgendwann offiziell zu unterstützen.

• https://ubuntuasahi.org/
• https://github.com/UbuntuAsahi/ubuntu-asahi
• https://www.youtube.com/watch?v=EJ8hdpXkkMI&ab_channel=UbuntuOnAir

Stellt euch vor, ihr habt eine Menge von Servern, welche ausschließlich über IPv6-Adressen verfügen und deshalb keine Dienste nutzen können, welche nur über IPv4 bereitgestellt werden. Wer sich dies nicht vorstellen mag, findet in „IPv6… Kein Anschluss unter dieser Nummer“ ein paar Beispiele dafür.

Was kann man nun tun, damit diese IPv6-only-Hosts dennoch mit der IPv4-only-Welt kommunizieren können?

Eine mögliche Lösung ist die Nutzung eines Dualstack-Proxy-Servers. Das ist ein Server, welcher über Adressen beider Internet-Protokoll-Versionen verfügt und so stellvertretend für einen IPv6-Host mit einem IPv4-Host kommunizieren kann. Das folgende Bild veranschaulicht den Kommunikationsablauf:

Im Bild ist zu sehen:

1. Wie IPv6-Host A eine Verbindung über IPv6 zum Proxy-Server B aufbaut und diesem bspw. die gewünschte URL mitteilt
2. Der Proxy-Server B baut nun seinerseits eine IPv4-Verbindung zu IPv4-Host C auf, welcher die gewünschten Inhalte bereitstellt
3. IPv4-Host C sendet seine Antwort über IPv4 an den Proxy-Server
4. Der Proxy-Server sendet die gewünschten Inhalte anschließend via IPv6 an den IPv6-Host A zurück

Das obige Video demonstriert die Nutzung eines Proxy-Servers durch den Abruf einer Demo-Seite mit curl:

1. Mit dem host-Kommando wird gezeigt, dass für die Demo-Seite kein AAAA-Record existiert; die Seite ist also nicht via IPv6 erreichbar
2. Mit dem ip-Kommando wird geprüft, dass der Host auf dem Interface ens18 ausschließlich über IPv6-Adressen verfügt
3. Ohne Proxy ist die Demo-Seite nicht abrufbar
4. Erst durch Nutzung des Proxys kann die Seite abgerufen werden

Funktioniert das auch von IPv4 nach IPv6?

Ja. Entscheidend ist, dass der verwendete Proxy beide IP-Versionen unterstützt.

Welcher Proxy ist empfehlenswert?

Der Proxy-Server muss beide IP-Versionen beherrschen. Ich persönlich bevorzuge Squid. Dieser ist in so gut wie allen Linux-Distributionen verfügbar, weit verbreitet, robust und selbstverständlich Freie Software.

Sind damit alle Herausforderungen bewältigt?

Für eine Virtualisierungs-Umgebung mit einer IPv4-Adresse und einem /64-IPv6-Netzsegment funktioniert diese Lösung gut. Sie funktioniert auch in jeder anderen Umgebung, wie gezeigt. Man beachte jedoch, dass man mit nur einem Proxy einen Single-Point-of-Failure hat. Um diesem zu begegnen, kann man Squid mit keepalived hochverfügbar gestalten.

Keepalived ist ebenfalls Freie Software. Sie kostet kein Geld, erhöht jedoch die Komplexität der Umgebung. Verfügbarkeit vs. Komplexität möge jeder Sysadmin selbst gegeneinander abwägen.

Wie mache ich meine IPv6-Dienste für IPv4-User erreichbar, die keinen Proxy haben?

Das Stichwort lautet Reverse-Proxy. Ein Artikel dazu erscheint in Kürze in diesem Blog. ;-)

Weiterführende Quellen und Links

• http://www.squid-cache.org/
• https://keepalived.org/
• RHEL 9 Docs: Configuring the Squid caching proxy server
• https://wiki.ubuntuusers.de/Squid/
• https://de.wikipedia.org/wiki/Squid
• Enable Sysadmin: Setting up a Linux cluster with Keepalived: Basic configuration
• Enable Sysadmin: Keepalived and high availability: Advanced topics
• https://keepalived.readthedocs.io/en/latest/introduction.html

Firefox bekommt eine neue Funktion, um bei Herüberfahren mit der Maus über einen Tab eine Vorschau der jeweiligen Website anzuzeigen.

Bislang zeigt Firefox bei Herüberfahren mit der Maus über einen Tab einen ganz einfachen Tooltip mit dem Titel der Website als Inhalt an. Diesen hat Mozilla für die Tabs nicht nur optisch überarbeitet, sondern zeigt jetzt zusätzlich die URL sowie einen Screenshot der geöffneten Website an.

Die Funktion kann ab Firefox 123 über about:config aktiviert werden, indem der Schalter browser.tabs.cardPreview.enabled per Doppelklick auf true gesetzt wird. Allerdings ist zu beachten, dass die Arbeiten an der Funktion noch nicht komplett abgeschlossen sind und daher für die finale Version von Firefox 123 auch noch keine standardmäßige Aktivierung geplant ist.

Wird zusätzlich der Schalter browser.tabs.cardPreview.showThumbnails auf false gesetzt, können die neuen Tooltips ohne Vorschaubilder genutzt werden. Der Schalter browser.tabs.cardPreview.delayMs kontrolliert die Verzögerung, wann der Tooltip gezeigt werden soll. Standardmäßig steht diese Option auf 1000 (Millisekunden), sodass der Tooltip erst erscheint, nachdem man wenigstens eine Sekunde mit der Maus auf dem Tab war.

Der Beitrag Firefox bekommt Tabvorschau erschien zuerst auf soeren-hentzschel.at.

Gestern hatte ich einen Artikel veröffentlicht, in dem ich darauf hingewiesen habe, dass ich vorerst nichts mehr (automatisiert) auf Mastodon veröffentlichen werden. Grund hierfür war, dass nach der Deaktivierung des Applets (durch mich selbst) bei IFTTT eine erneute Aktivierung gescheitert ist. Der Grund ist wohl, dass die Funktion, neue Einträge eines RSS Feeds bei Mastodon (oder anderen Plattformen) per Webhook zu veröffentlichen, nun kostenpflichtig ist.

Bis gestern hat das Applet, soweit ich es nachvollziehen kann, aber seinen Dienst getan. Hätte ich es nicht deaktiviert, würde es vermutlich immer noch funktionieren. Wenn ich recht habe, finde ich die Art Leute zu kostenpflichtigen Tarifen zu “überreden” fragwürdig. Laut Quellen wie beispielsweise https://old.reddit.com/r/ifttt/comments/18p7pxa/webhooks_suddenly_stopped_working_requires_pro/ sind scheinbar auch andere Nutzer betroffen.

Aufgrund meines Artikels hat PepeCyB eine Alternative bei https://rss-parrot.net erstellt https://fryboyter.de/vorerst-keine-veroeffentlichungen-mehr-bei-mastodon/#isso-977. Und Masin hat auf den Dienst https://mastofeed.org hingewiesen https://fryboyter.de/vorerst-keine-veroeffentlichungen-mehr-bei-mastodon/#isso-978

Vielen Dank hierfür.

Ich habe mich allerdings für eine andere Lösung entschieden, da ich möglichst unabhängig von Diensten Dritter sein möchte. Gestern hatte ich mir noch diverse alternative Lösungen angesehen. Schlussendlich bin ich bei https://gitlab.com/chaica/feed2toot gelandet. Das Tool macht, was es soll und man kann es leicht selbst hosten. Auf “Dirks Logbuch” wurde schon vor einiger Zeit eine entsprechende Anleitung veröffentlicht, an der ich mich orientiert habe.

Das Konto bei IFTTT habe ich übrigens gelöscht.

… und warum und wie ich es trotzdem tat.

Vor wenigen Wochen habe ich mein zweites Fachbuch fertiggestellt. In diesem Blogpost gehe ich ein wenig tiefer ein, was meine Motivation war, wie sich der Fortschritt gestaltet hat und welche Hilfsmittel (nicht) geholfen haben.

Bücher schreiben klingt für viele total toll. Die Realität fühlte sich häufig allerdings das Meme oben an …

Rückblick

Vor langer Zeit fing ich hier auf meinem Blog eine vierteilige Tutorial-Reihe zu Git an. Der erste Blogpost erschien im Oktober 2014. Das ist jetzt auch schon fast zehn Jahre her. Meine damalige Intention war recht einfach: Ich hatte Lust etwas über das Thema zu schreiben, denn ich bekam sowohl bei der Arbeit, als auch bei der Mitarbeit in Open-Source-Projekten ständig Fragen, wie dieses Git denn nun funktioniert. Da ich keine Lust hatte, es immer wieder zu erklären, schrieb ich es eben einmal ordentlich runter und verlinkte diese Blog-Posts und beantwortete erst später konkretere Fragen.

Durch eine Verkettung von Umständen kam es dann dazu, dass ich die Möglichkeit hatte, ein Buch über Git zu schreiben. Diese vier Artikel dienten als Basis für das Buch, wo ich natürlich dann sehr sehr viel erweitert habe. Zwei Jahre später im August 2016, erschien dann die erste Auflage meines Git-Buches beim mitp-Verlag. Im Mai 2019 folgte die zweite Auflage, im März 2021 die dritte und im März 2022 folgte der Git Schnelleinstieg als abgespeckte Variante. Über die vergangenen 7,5 Jahre verkauften sich knapp über 4000 Exemplare.

Die Vor- und Nachteile des Autorendaseins

Ein Buch geschrieben zu haben, hat sowohl diverse Vor- als auch Nachteile. Jedes Mal, wenn mir jemand Anfängerfragen zu Git gestellt hat, folgte von mir ein stark ironisches „Also … ich kann dir da ein Buch empfehlen“. Das war immer wieder zur Aufheiterung lustig. Was ich meistens nicht so geil fand, waren Random Gespräche bei Feiern jeglicher Art. Da wurde man plötzlich von Freunden, Bekannten und Verwandten anderen Personen als Autor vorgestellt … was dazu geführt hat, dass ich ständig wildfremden Leuten, die nicht in der IT sind, erklären musste, was denn diese Versionsverwaltung mit Git ist. Meistens sah ich nach zwei oder drei Sätzen schon, wie sie bei meinem Versuch es zu erklären, ausgestiegen sind, aber natürlich empfanden sie es als super und toll! Spaß macht das nicht. Außerdem ist scheinbar „Buch schreiben“ ein Bucketlist-Item für viele Leute. Ich weiß bis heute nicht, warum, aber ich muss auch nicht alles verstehen.

Wer übrigens etwas näher hören will, wie so ein Buch entsteht, darüber habe ich in der zweiten Folge unseres Podcasts TILpod von und mit Dirk Deimeke gesprochen.

Ursprüngliche Motivation & Umsetzung

Zurück zur Motivation und der Umsetzung: Nachdem ich die ursprünglichen Blogposts ohne tieferen Hintergedanken geschrieben habe, war das bei einem Buch natürlich etwas anderes. Die Qualitätsansprüche sind hier natürlich deutlich höher, denn hier bezahlen die Kunden mit Geld. Von diesem Geld blieb allerdings nicht sehr viel in meinem Geldbeutel hängen. Dass man als Autor nicht reich wird, war mir bewusst.

Eine gewisse Reputation und ein „einfacherer“ Einstieg in idealerweise gut bezahlten Job mit guten Arbeitsbedingungen war mein Hauptmotivationstreiber. 2015, als ich mit der Arbeit am Buch begann, war ich gerade erst mit dem Bachelor fertig. Die darauffolgenden Jobwechsel waren beim Hinblick auf Gehalt, Arbeitsbedingungen und Interessantheit der Tätigkeiten alle nicht so das wahre (in verschiedenen Konstellationen).

Long story short: Im April 2020 fing ich meinen Job als Solutions Architect bei GitLab an. Zu den ausgeschriebenen Jobs bei GitLab hatte ich ohnehin schon seit einigen Jahren einen Blick geworfen und dann hat es auch auf Anhieb geklappt. Ein deutlicher Gehaltssprung war dabei, deutlich bessere Arbeitsbedingungen und auch die Tätigkeit im Pre-Sales, was ich so vorher auch nie gemacht habe, hat super gepasst. Mein Plan ging also einige Jahre später auf: Durch das Git-Buch habe ich mich deutlich tiefer in Git und dem gesamten Software-Delivery-Lifecycle eingearbeitet, sodass ich mich für den Job qualifizieren konnte.

Soweit so gut. Ein Grund für ein komplett neues Buch brauchte ich eigentlich nicht … oder? Oder?

Motivation für das zweite Buch

Tja, ich wäre nicht ich, wenn ich immer wieder ein größeres Projekt angehen würde.

Fachliche Motivation

Zunächst zur fachlichen Motivation: In tagtäglichen Gesprächen mit diversen (potenziellen) Kunden von GitLab merkte ich primär eins: Viele fokussieren sich viel zu stark auf die eingesetzten Tools – etwa GitLab –, ohne jedoch zu schauen, ob und wie „kaputt“ die Arbeitskultur ist.

GitLab selbst positioniert sich als ganzheitliche DevOps-Plattform, womit man einfacher und schneller Projekte mit DevOps-Prinzipien umsetzen kann, in dem besser in einem, statt in vielen, Tools kollaboriert wird. Das ist gut, richtig und wichtig.

Wichtige Voraussetzung ist allerdings, dass man erst die Arbeitskultur anpasst und dann die Prozesse anpasst, gefolgt vom Tooling. Im DevOps-Kontext spricht man nicht umsonst von „People over Processes over Tools“. Die besten Tools helfen nicht, wenn die Prozesse beschissen sind. Die Prozesse helfen nicht, wenn die Kolleginnen und Kollegen mit den verschiedenen Rollen (Development, Operations, Security, QA, …) gegeneinander statt miteinander arbeiten.

Mit diesem Buch möchte ich aufklären, wie es „richtig“ geht. Das beste, tollste, schnellste und effizienteste Auto bringt schließlich auch nicht, wenn man keine Straßen hat … und einen Führerschein auch nicht.

Fachlich war die Motivation also klar: Wenn es um DevOps geht, gibt es großen Nachholbedarf, das sehe ich schließlich bei den ganzen Gesprächen. Ein „echtes“ deutsches Buch zu DevOps gab es auch nicht, sondern nur zwei Übersetzungen aus dem Englischen. Und so reifte die Idee für das zweite Buch.

Nicht fachliche Motivation

Auf der nicht fachlichen Ebene sah es noch ein wenig anders aus. Hier kommen gleich mehrere Faktoren ins Spiel. Zunächst einmal war das Git-Buch recht technisch. Obwohl ich die Arbeit an dem Buch schon ziemlich herausfordernd fand, gab es hier meist nur eine technische Lösung, was das Schreiben deutlich vereinfacht hat. Bei DevOps ist das Ganze anders. Hier geht es viel um „weiche“ Themen, wie Menschen miteinander arbeiten. Das ist um ein Vielfaches herausfordernder. Das hat mich auch angespornt.

Weiterhin wollte ich dieses Mal bei einem größeren Verlag veröffentlichen. Die Zusammenarbeit mit dem mitp-Verlag war zwar gut und ich soweit zufrieden, aber im Marketing und bei Verkaufszahlen merkt man dann schon einige Unterschiede. Der Einstieg beim größten deutschen IT-Verlag, dem Rheinwerk-Verlag, hat mit diesem Buch dann auch funktioniert.

Die damalige Motivation für einen „besseren“ Job hatte ich beim DevOps-Buch hingegen nicht. Finanzielles spielte demnach weder primär noch sekundär eine Rolle. Ich bin trotzdem gespannt, welche neue Türe sich hierdurch gegebenenfalls öffnen.

Meine grundlegende Motivation liest sich bis hierhin eigentlich gut, aber die Motivation muss schließlich nicht nur beim Start vorhanden sein, sondern auch während man das Buch schreibt …

Der Fortschritt …

Die Motivation kontinuierlich und mit (höchster) Disziplin am Buch zu arbeiten, klang zu Beginn viel einfacher als es am Ende dann war. Um es kurz zu sagen: Es war ein Kampf. Und das war überhaupt nicht geil.

Der Unterschied zu damals™

Im Vergleich zum Git-Buch hatte ich ein Aspekt komplett vernachlässigt. Mein Job damals war deutlich weniger anstrengend. Damals war ich rein in der Technik und ohne Reisetätigkeiten. Das lässt sich viel einfacher steuern, als mein jetziger Job. Bei GitLab hatte und habe ich jeden Tag etliche Videocalls mit Kunden. Bei diesen Calls muss ich stets fokussiert und effizient sein, was für den Kopf deutlich anstrengender ist. Zudem machte mir der Job auch noch deutlich mehr Spaß, ich hatte auch noch (ab Mai 2022) etliche Dienstreisen, die einen regelten Tagesablauf nicht ermöglicht haben. Am Ende des Arbeitstages und auch am Wochenende war so nicht mehr so viel Gehirnkapazität übrig, um stetigen Fortschritt zu gewährleisten.

Das „weiche“ Thema führte auch dazu, dass ich immer wieder überlegen musste, wie ich diverse Themen angehen sollte, damit man daraus auch etwas Sinnvolles herausziehen kann. Das führte immer wieder zu Verzögerungen, da ich dann noch die Gedanken schweifen lassen oder mit der ein oder der anderen Person aus dem Arbeitsumfeld besprechen musste, um mir neue Eindrücke abzuholen. Gleichzeitig hing die Frist immer im Nacken …

Produktivitätstechniken

Während des Schreibens probierte ich auch immer wieder ein paar Produktivitätstechniken aus. Je nach Phase des Buches war das auch relativ gut und hilfreich.

Zu Beginn, nachdem die Grobstruktur gestanden hatte, fokussierte ich mich zunächst um Stichpunkte. Ich tippte also, was mir in den Kopf kam zu den einzelnen Themen in Stichpunkten herunter, und kümmerte mich kaum um die Grammatik. Das war wichtig, um überhaupt mal die Gedanken strukturieren zu können. Dabei fielen mir noch etliche Themen ein, die ich vorher gar nicht betrachtet hatte … die dann zu neuen Kapiteln führten.

Ich setzte hierfür auf die Pomodoro-Technik: Ich versuchte jeden Tag mindestens 25min, ohne Ablenkungen, Stichpunkte herunterzuschreiben, gefolgt von einer 5min Pause. Danach habe ich weiter gemacht … oder häufig auch nicht. Das war auch völlig in Ordnung.

Das Ganze funktionierte so lange, bis es nicht mehr funktionierte. Irgendwann hatte ich dann alles notiert und es ging mehr Zeit drauf, zu überlegen, was man noch vergessen hat. Gerade für diese Phase benötigte ich viel Ruhe und Zeit, die durch Real-Life und Vollzeitjob nicht sonderlich gegeben war.

Es gab also immer wieder Phasen – teilweise einige Monate – wo ich wenig bis gar nicht am Buch gearbeitet habe. Dabei war das offene Großprojekt, das Wissen, noch etwas erledigen zu müssen, die Frist und was sonst noch dazu gehört, stets im Hinterkopf. Schön war das zugegeben nicht wirklich.

Später, beim Ausformulieren der Stichpunkte, habe ich mir hingegen ein Output-Ziel gesetzt. An Arbeitstagen wollte ich für zwei zusätzliche Seiten sorgen, an arbeitsfreien Tagen hingegen fünf. Da dann primär viel ausformuliert werden musste, klappte das für eine Weile auch einigermaßen gut.

Öffentlicher Statusbericht

Gleichzeitig habe ich meinen eigenen Podcast TILpod, den ich mit Dirk Deimeke betreibe, vorangetrieben. Dort erzählte ich in jeder Folge, wie der Fortschritt am Buch ist. Treue Hörer und Hörerinnen haben also stets mitbekommen, wie ich vorankomme … oder auch nicht.

Das öffentliche Dokumentieren des Fortschritts hat hingegen nicht zu mehr Druck geführt, zumindest nicht bewusst. Einige lustige Gegebenheiten haben sich hingegen schon dadurch ergeben. Vergangenes Jahr war ich dienstlich bei der KubeCon in Amsterdam, wo ich Standdienst bei GitLab gemacht habe. Es kamen erstaunlich viele mir unbekannte Personen auf mich zu und fragten, ob mein Buch denn nun fertig ist. Auch eine spannende Form, auf Hörer vom Podcast zu treffen.

Ursprünglich war mein Plan, bis Ende 2022 fertig zu werden. Dass das nicht zu halten war, war mir schon zu Beginn klar. Unterschrieben habe ich den Autorenvertrag übrigens im Januar 2022. Erst im Sommer 2023, nachdem ich mehrfach die Fertigstellung nach hinten schieben musste, war der erste Entwurf fertig. Und dann ging erst die Arbeit mit diversen Korrekturläufen, dann zusammen mit meinem Lektor, los.

Mein Ziel es dann noch im Jahr 2023 fertigzustellen hat dann nicht auch nicht mehr geklappt. Nachdem ich selbst für so viel Verspätung gesorgt hatte, lag es dann auch noch eine Weile bei meinem Lektor auf Halde: Mein Buch ist schließlich nicht das Einzige, meins musste entsprechend warten.

Der Spätsommer und Herbst war dann ebenfalls ziemlich frustrierend. Jeden Monat verschob sich die Fertigstellung um einen Monat. Jedes Mal, wenn ich dachte, dass ich jetzt wirklich mal fertig wurde, mussten wir es abermals um einen Monat verschieben. Insgesamt lagen zwischen der Unterzeichnung des Autorenvertrags und der Fertigstellung ziemlich genau zwei Jahre.

(Keine) Hilfsmittel

Ganz unabhängig von der Motivation und der Produktivität finde ich es auch noch spannend auf mögliche Hilfsmittel zu werfen. Insbesondere ChatGPT, LanguageTool und Obsidian.

ChatGPT

Während des Schreibens des Buches ploppte dann auch noch ChatGPT auf und der AI-Hype ging so richtig los. An vielen Stellen las ich dann, dass man ja jetzt „ganz einfach“ Texte schreiben lassen kann und bald nur noch AI-generierte Bücher gibt.

Ich dachte dann: Ja gut, ich habe hier ja ein Beispiel, schauen wir mal, ob ChatGPT hier überhaupt realistisch helfen kann. Tja, nun … tat es nicht wirklich.

Ich hatte natürlich nicht vor, mein Buch per ChatGPT schreiben zu lassen. Das funktioniert ohnehin nicht. Die Frage, die ich mir stattdessen stellte, ging mehr in die Richtung: Wie kann mir ggf. ChatGPT helfen?

Typische Prompts à la „Schreib mir etwas zu $THEMA im Rahmen von DevOps“ produzierten (natürlich) sehr, sehr oberflächliche Texte, die sich zu 95 % ohnehin immer nur wiederholten. Praktisch war hingegen, ChatGPT zu nutzen, um zu prüfen, ob man etwas vergessen hatte. So ergänzte ich zur „normalen“ Recherche auch ChatGPT, wobei der tatsächliche Nutzen eher gering war, schließlich stand der Großteil und ChatGPT kann man ja bekanntlich auch nicht alles glauben. Häufig kam da auch nur Mist raus.

LanguageTool

ChatGPT war also nur wenig hilfreich, anders sah es bei LanguageTool aus, was für sprachliche Korrekturen sehr hilfreich war. Dafür setzte ich auf die Premium-Variante für knapp 60 € pro Jahr.

LanguageTool gab mir einige Hinweise für die korrekte Nutzung der deutschen Sprache. Viel zu lange Sätze, Wortwiederholungen, Kommasetzung und noch etliche weitere Hinweise wurden mir dann regelmäßig angezeigt, sodass ich da noch einmal drauf geschaut habe.

Praktisch war zudem das Feature „Sentence rephrasing by A.I.“. Hier konnte man einzelne Sätze aus einigen Paragrafen neu formulieren lassen. Das half mir insbesondere dann, wenn ich an einigen komplexen Sätzen viel zu lange hing, weil diese kaum verständlich waren.

Obsidian

DIe meiste Zeit beim Schreiben verbrachte ich im Tool Obsidian. Das ist eigentlich mehr als persönliches Knowledge-Base gedacht. Für mich half es hingegen das Buch primär in Markdown herunter zu schreiben, da es mich nicht zu sehr abgelenkt hat. Viele der Features von Obsidian habe ich allerdings nicht verwendet. Einige fehlerhafte Verlinkungen fielen mir dann nur regelmäßig auf. LanguageTool ließ sich zudem als Plug-in einbinden und nutzen.

Zum Ende hin musste ich allerdings sowieso auf Microsoft Word switchen, weil das der Workflow vom Verlag so vorgibt. Bis dahin konnte man es wenigstens gut in Git-Repositorys tracken, sodass ich Anpassungen von Reviewern und Lektor einfach nachvollziehen konnte.

Fazit

Warum sollte man also eher kein Fachbuch schreiben?

Es ist verdammt anstrengend, es geht richtig viel Zeit drauf und ist häufig auch echt frustrierend. Reich wird man nicht. Ob es sich für mich gelohnt hat, wird sich zeigen. In den letzten zwei Jahren verbrachte ich also sehr viel Zeit mit meinem Vollzeitjob und dem Schreiben des Buches. Viel Zeit drum herum, blieb da nicht. Gesund war das ganze auch nicht sonderlich.

Das fertige Buch

Wer bis hierhin gelesen hat, wird gemerkt haben, dass das Thema des Buches eine untergeordnete Rolle gespielt hat, dazu folgt noch ein weiterer Artikel. Das DevOps-Buch gibt es überall da, wo es Bücher gibt – insbesondere direkt beim Verlag. Es erscheint am 5. März 2024. Ich warte zurzeit noch auf meine Belegexemplare und kann es kaum erwarten.

Seit einiger Zeit wird unter https://social.tchncs.de/@fryboyter ein Hinweis angezeigt, wenn ich einen neuen Artikel veröffentlicht habe. Damit ist vorerst Schluss.

Für die automatische Veröffentlichung hatte ich bisher den Dienst IFTTT verwendet. Vorhin wollte ich etwas an dem betreffenden Applets ändern und habe dies hierbei deaktiviert. Was ich wohl lieber nicht gemacht hätte. Wenn ich das Applet nun aktivieren will, erhalte ich nun den Hinweis “This Applet has Pro features”. Scheinbar sind Webhooks bei IFTTT zwischenzeitlich kostenpflichtig geworden. Und sobald man ein ehemalig kostenloses Applet deaktiviert, hat man die Arschkarte gezogen und soll nun zahlen, wenn man es wieder aktivieren will. 2,92 Dollar im Monat, wenn man jährlich zahlt oder 3,49 Dollar, wenn man monatlich bezahlt.

Wenn man bedenkt, dass ich bei Mastodon im Grunde nicht aktiv bin und dort nur entsprechende Hinweise auf neue Artikel veröffentlicht habe, will ich weder 2,92 noch 3,29 Dollar bezahlen. Zumal ich auch beispielsweise RSS-Feeds wie https://fryboyter.de/index.xml anbieten über die man sich über neue Artikel in Kenntnis setzen lassen kann und ich IFTTT für nichts anderes nutze.

Ich hatte schon vor einiger Zeit mit Alternativen wie Node Red oder N8N experimentiert. Leider bin ich entweder komplett daran gescheitert, dass es funktioniert hat oder es wurden alle Beiträge der angegebenen Feed-Adresse bei Mastodon veröffentlicht und nicht nur der neuste Beitrag. Falls jemand hierfür eine Lösung hätte und bereit ist mir sinnvoll zu helfen, wäre es sehr nett. Ich aktiviere daher bei diesem Beitrag die Kommentarfunktion. Alternativ kann man mir auch eine E-Mail schreiben. Die Adresse ist im Impressum genannt.

Vor circa einem Monat habe ich mein Notebook gegen ein Google Pixel Tablet ersetzt. Es ist ein Experiment, weil ich immer häufiger gesehen habe, dass andere das machen und ich mein Notebook nur noch selten nutze. Zuletzt war ich damit ein bisschen unterwegs und konnte das praktisch testen.

Zunächst zur Hardware. Das Pixel Tablet reicht von den Leistungsdaten natürlich spielend für meine Anforderungen. Den Stylus benötige ich überraschend selten, aber ab und an ist er ganz hilfreich. Wegen des praktischen Covers stört er auch nicht, sondern ist immer gut aufgeräumt. Die Tastatur ist leider ziemlich mäßig, da muss ich nochmal schauen, ob es Alternativen gibt. Andererseits war es zum längere Texte tippen sowieso nicht gedacht.

Android taugt als Notebook-Ersatz überraschend gut. Das Dock ist als zentrales Steuerungsinstrument im Alltag brauchbar und ermöglicht einen schnellen Wechsel zwischen den wichtigsten Apps im Vollbildmodus. Die Möglichkeit zwei Apps gleichzeitig anzuzeigen nutze ich erstaunlich selten. Die verfügbaren System-Apps und das Angebot an Drittanbieter-Apps genügen meinen Ansprüchen weitestgehend. Allerdings ist das Angebot in F-Droid für diese Zwecke noch schmaler als beim Smartphone, weshalb der Aurora Store auf dem Tablet für mich unverzichtbar ist.

Es überrascht kaum, dass das Tablet für rein konsumierende Nutzung geeignet ist. Surfen im Internet, Videos schauen, Musik hören. Dafür hat Google es ja auch ausgelegt. Die Android-Version von VLC überzeugt schon auf dem Smartphone und skaliert auf dem Tablet ebenso hervorragend.

Ein paar Veränderungen bei den Apps verglichen mit meinem Smartphone-Nutzungsverhalten habe ich aber vorgenommen. Beim Browser bin ich von Firefox (Fennec) zu Vanadium gewechselt und bei der E-Mail-App von K9 zu FairEMail. Die Gründe waren unterschiedlich. K9-Mail ist eine gute Smartphone-App, aber war mir auf dem Tablet zu limitiert. FairEmail ist zwar bei den Einstellungen maßlos überladen, aber kann dadurch natürlich viel kleinteiliger angepasst werden. Bei Fennec vs. Vanadium überwogen Sicherheitsüberlegungen. Chromium-Forks haben insbesondere auf der Android-Plattform die Nase vorn und da ich den Browser viel intensiver nutze als auf dem Smartphone, habe ich hier umgestellt. Für den PIM-Bereich habe ich auf Fossify Kalender umgestellt (Fork von Simple Mobile Tools nach dem Verkauf). Etar wird kaum noch entwickelt und für das Tablet genügte die App mir dann einfach nicht mehr. nicht mehr.

Andere Programme spielen auf dem Smartphone nur eine untergeordnete Rolle. Die integrierte Dateiverwaltung reicht auch am Tablet völlig für meine Bedarfe. Synology Drive nutze ich nun intensiver und synchronisiere die wichtigsten Verzeichnisse mit meinem Desktop. Office-Arbeiten lassen sich sehr gut mit SoftMaker Office erledigen.

Das ist zwar von der UI kaum auf Touchgeräte ausgelegt, aber funktioniert dafür erstaunlich gut. Als Ansicht habe ich “Symbolleisten: Modernes Thema” mit Toucheingabe gewählt. Dadurch lässt es sich gut mit einem Stylus bedienen, aber die Elemente sind sehr dezent in einer Leiste angeordnet. Passend für meinen Umsteig auf das Tablet hat Zotero eine erste Beta der App für Android veröffentlicht. Die ist zwar optisch ein ziemlich “billiger” iOS-Port, aber funktioniert gut.

Verglichen mit meinem letzten Artikel zu Apps für GrapheneOS ergeben sich am Tablet ein paar Abweichungen.

Insgesamt bin ich immer noch hoch zufrieden mit meiner Entscheidung. Ich schleppe jetzt deutlich weniger Ballast durch die Gegend. Sowohl was das physische Gewicht betrifft als auch den Wartungsaufwand eines zweiten Desktopsystems betreffend. Einschränkungen habe ich noch nicht erlebt. Das Notebook ist nun verkauft.

Der Artikel Google Pixel Tablet als Notebook-Ersatz: Erste Erfahrungen erschien zuerst auf Curius

Wenn ich meinen eigenen Aussagen vertrauen kann, habe ich zum Hervorheben von Code seit 2018 Prism.js verwendet. Seit einiger Zeit habe ich allerdings öfters darüber nachgedacht, ob ich Prism.js weiterhin nutzen will. Und die Antwort lautet nein.

Ja, Prism.js funktioniert technisch gesehen. Zwar nicht perfekt, aber es gab bisher keine größeren Probleme damit. Prism.js verwendet allerdings JavaScript. Wer also diese Internetseite ohne aktiviertes JavaScript aufruft, bekommt nur den nackten Code angezeigt. Das ist zwar nicht schön aber auch nicht tragisch.

Schlimmer ist, dass das Projekt Prism.js scheinbar tot ist. Die Entwicklung von Version 1.x wurde zugunsten der Entwicklung von Version 2 mehr oder weniger auf Eis gelegt, sodass Version 1.29 die letzte veröffentlichte Version darstellt. Diese wurde im Augst 2022 veröffentlicht. Die letzten Änderungen an Version 2 wurden vor 9 Monaten durchgeführt. Seit dem gab es unter https://github.com/PrismJS/prism/discussions/3531 mehrere Nachfragen in den letzten Wochen und Monaten wie es um Prism.js steht. Eine Reaktion seitens der Entwickler gab es bisher keine, obwohl diese zwischenzeitlich durchaus auf Github aktiv waren. Daher meine Vermutung, dass das Projekt nicht weiterentwickelt wird. Über die Hintergründe kann ich nur spekulieren, also lasse ich es.

Ja, aber Prism.js funktioniert doch? Richtig. Aber es gäbe Verbesserungsbedarf. Und es wurden in den letzten Jahren schon ein paar Sicherheitslücken entdeckt und behoben. Und genau diese Sicherheitslücken machen mir immer mehr Sorgen. Was, wenn nächste Woche eine weitere entdeckt wird? Wird darauf reagiert und eine neue Version veröffentlicht? Oder zumindest ein Patch? Oder wird darauf nicht reagiert?

Da mir die Situation zu ungewiss ist, habe ich mir einige Code Highlighter wie Highlight.js angesehen. Schlussendlich habe ich mich allerdings für Chroma entschieden. Und das hauptsächlich aus zwei Gründen.

• Ich nutze Hugo zum Erzeugen dieser Internetseite. Und Chroma ist Bestandteil von Hugo.

• Und Chroma kommt ohne JavaScript aus. Denn das Hervorheben des Codes wird direkt beim Erzeugen der Internetseite durchgeführt. Ganz so, wie wenn ich das Hervorheben des Codes manuell mit ein paar Tags und CSS gemacht hätte.

Der erste Grund spart mir somit die manuelle Aktualisierung. Der zweite Grund sorgt dafür, dass der Code auch dann hervorgehoben wird, wenn man JavaScript nicht aktiviert hat. Und die beim Aufruf von fryboyter.de übertragene Datenmenge wird auch weniger. Nicht, dass dies ins Gewicht fallen würde, aber ca. 50 Kilobyte sind für diese Seite prozentual gesehen durchaus nicht wenig.

Es gibt aber auch Nachteile.

Ein Umbruch langer Zeilen ist mit Chroma für mich nicht zufriedenstellend möglich. Ich frage mich allerdings, ob es vielleicht nicht sowieso besser ist, darauf zu verzichten. Auch, wenn man somit in einigen Fällen horizontal scrollen muss. Ein Zeilenumbruch im Code verbessert auch nicht unbedingt dessen Lesbarkeit.

Ein weiterer Nachteil ist, dass Chroma manchen Code nicht so gut hervorhebt wie es Prism.js gemacht hat. Dafür unterstützt Chroma zum Beispiel Go Templates, welche oft in meinen Code-Beispielen zum Einsatz kommen. Na ja, nichts ist perfekt.

Alles in allem hat sich meiner Meinung nach die Umstellung und der damit verbundene Aufwand aber gelohnt.

Das Trusted Platform Module 2 (TPM 2) wurde bereits 2014 als Standard veröffentlicht. Dennoch fristete es lange Zeit ein Schattendasein. Microsoft hob es mit den Versionen Windows 10 und Windows 11 aus dem Schatten und seit einigen Jahren befassen sich auch unter Linux mehr Entwickler damit.

Unter Linux ist aktuell TPM 2 bereits jetzt ein wichtiger Baustein für einen verifizierten Systemstart und die Möglichkeit, ein verschlüsseltes System ohne initiale Passworteingabe zu starten. Für einen Überblick über den aktuellen Stand empfehle ich folgende zwei Artikel hier im Blog:

• Verschlüsseltes Linux mit LUKS mittels TPM 2.0 entsperren
• Verifizierter Systemstart (Verified Boot) – Der Stand bei Linux

Parallel zu den Entwicklungen bei systemd haben openSUSE und Canonical eigene Anstrengungen gestartet, um TPM stärker in die eigenen Systeme einzubinden. Ich vermute trotzdem, dass systemd als gemeinsamer Nenner vieler Distributionen, ein wichtiger Bestandteil bleiben wird.

Auf der FOSDEM 24 wurde TPM in einem anderen spanneden Kontext präsentiert, und zwar als sicheren Schlüsselspeicher. Für den Hintergrund muss man sich ein wenig mit einem gar nicht mehr so aktuellen Problem befassen. Moderne mobile Hardware wie iPhones, iPads oder Android-Smartphones haben etwas, das bei Apple als Secure Enclave bezeichnet wird oder bei Google als Titan M. Microsoft hat dafür auf einen Standard gesetzt: TPM. Das ist sehr gut, weil dadurch für Desktop-Hardware etwas ähnliches Verbreitung gefunden hat, das auch Linux das nachnutzen kann.

Das Problem ist nämlich, dass manche Daten wie biometrische Daten, aber auch wichtige Schlüssel besser nicht ohne zusätzliche Schutz im System aufbewahrt werden. Sie können dort einfach nicht so sicher geschützt werden, wie das notwendig ist. Datei- und Benutzerrechte hin oder her. Aus diesem Grund rate ich auch dringend davon ab, biometrische Verfahren mit Linux zu nutzen.

In dem FOSDEM Talk werden nun weitere Szenarien präsentiert (siehe auch den Bericht bei Heise). Ihnen gemein ist, dass sie erst möglich sind, seitdem grundlegende Arbeiten unter Linux TPM 2 auch praktisch nutzbar gemacht haben. Zu den neuen Ansätzen gehört die Möglichkeit das TPM 2-Subsystem zum versiegeln (engl. “sealed” – schwierige Übersetzung) und laden von privaten GnuPG-Schlüsseln zu nutzen. Das Verfahren ist in dem vor über einem Jahr veröffentlichten GnuPG 2.4 bereits enthalten, aber wurde bisher wenig beachtet. Möglicherweise auch, weil viele Distributionen ältere Versionen von GnuPG nutzen. Ebenso denkbar ist dies aber auch für OpenSSH, wenngleich hier noch mehr Arbeit investiert werden muss.

Vermutlich ist auch das nur der Anfang und Schlüsselspeicher werden folgen. Ich hatte lange die Sorge, dass der lautstarke FUD aus der angst- und hasserfüllten kleinen Minderheit von Linux-Anwendern, die sich unter entsprechenden Artikeln immer zu Wort meldet, bei Linux hinderlich für die Entwicklung sein könnte, aber glücklicherweise scheinen die Entwickler diese inzwischen zu ignorieren.

Der Artikel TPM 2 als sicherer Datenspeicher für Linux erschien zuerst auf Curius

Vor einiger Zeit habe ich vom X11.org Displayserver auf Wayland umgestellt. In diesem Zusammenhang fingen an meine GTK/Gnome Applikationen überwiegend schlecht auszusehen. Die Schriftarten (Fonts) sahen einfach furchtbar pixelig aus.

Eine Abhilfe schuf dann die Installation des Pakets xdg-desktop-portal-gnome.

sudo apt install xdg-desktop-portal-gnome
sudo apt install adwaita-qt

Zusätzlich musste ich noch folgende Dateien anpassen

sudo vim /usr/share/xdg-desktop-portal/kde-portals.conf

[preferred]
default=kde
org.freedesktop.impl.portal.Settings=kde;gtk;
~                                               

Und dann noch in vim .fonts.conf

<fontconfig>
 <dir>~/.fonts</dir>
<match target="font">
  <edit name="hinting" mode="assign">
    <bool>true</bool>
  </edit>
</match>
</fontconfig>

Dann einmal neu booten und die GTK/Gnome Applikationen sehen wieder gut aus.

The post GTK Apps in KDE gut aussehen lassen first appeared on Dem hoergen Blog.

In diesem Blogpost möchte ich zeigen, wie ich ArchLinux auf einem Laptop installiere. Hierbei erfolgt die Installation auf eine verschlüsselte Partition, was bei tragbaren Geräten empfehlenswert ist. So fallen keine Daten in falsche Hände, falls das Gerät geklaut oder vergessen wird.

$ lsblk

NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS  
sda             259:0    0 931,5G  0 disk
sdb               8:0    1   7,4G  0 disk 

$ dd if=archlinux*.iso of=/dev/sdb

$ iwctl

$ devices list

$ station wlan0 connect <SSID>

$ exit

$ systemctl start sshd

$ passwd

$ ip a

$ ssh root@IP-ADRESSE

$ lsblk

NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda             259:0    0 931,5G  0 disk 
sdb               8:0    1   7,4G  0 disk  
├─sdb1            8:1    1   917M  0 part  
└─sdb2            8:2    1    15M  0 part  

$ gdisk /dev/sda

$ modprobe dm-crypt
$ modprobe dm-mod

$ cryptsetup luksFormat -v -s 512 -h sha512 /dev/sda2

$ cryptsetup open /dev/sda2 luks_lvm

$ pvcreate /dev/mapper/luks_lvm
$ vgcreate arch /dev/mapper/luks_lvm

$ lvcreate -n swap -L 10G arch

$ lvcreate -n root -l +100%FREE arch

$ mkfs.fat -F32 /dev/sda1 

$ mkfs.btrfs -L root /dev/mapper/arch-root
# oder
$ mkfs.ext4 -L root /dev/mapper/arch-root

$ mkswap /dev/mapper/arch-swap

$ swapon /dev/mapper/arch-swap
$ swapon -a

$ mount /dev/mapper/arch-root /mnt

mkdir -p /mnt/boot

$ mount /dev/sda1 /mnt/boot

$ pacstrap -K /mnt base base-devel linux linux-firmware nano openssh

$ genfstab -U -p /mnt > /mnt/etc/fstab

$ arch-chroot /mnt /bin/bash

$ nano /etc/mkinitcpio.conf

HOOKS=(... block encrypt lvm2 filesystems fsck)

$ pacman -S lvm2

$ pacman -S efibootmgr dosfstools gptfdisk

$ bootctl install

$ blkid /dev/sda2

/dev/sda2: UUID="272b13c4-ce78-47de-b04c-66210edb977d" TYPE="crypto_LUKS" PARTLABEL="Linux LUKS" PARTUUID="6b6b86e4-b8fe-4b7d-874d-96c67075b90c"

$ nano /boot/loader/entries/arch-uefi.conf

title    Arch Linux
linux    /vmlinuz-linux
initrd   /initramfs-linux.img
options  root=/dev/mapper/arch-root cryptdevice=UUID=<uuid>:luks_lvm  locale=de_DE.UTF-8

options  root=/dev/mapper/arch-root cryptdevice=UUID=272b13c4-ce78-47de-b04c-66210edb977d:luks_lvm  locale=de_DE.UTF-8

$ nano /boot/loader/loader.conf

default   arch-uefi
timeout   1

$ mkdir /secure

$ dd if=/dev/random of=/secure/root_keyfile.bin bs=512 count=8

$ chmod 000 /secure/*

$ cryptsetup luksAddKey /dev/sda2 /secure/root_keyfile.bin

$ nano /etc/mkinitcpio.conf

FILES=(/secure/root_keyfile.bin)

$ mkinitcpio -p linux

$ ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

$ nano /etc/systemd/timesyncd.conf

[Time]
NTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org 
FallbackNTP=0.pool.ntp.org 1.pool.ntp.org

$ systemctl enable systemd-timesyncd.service

$ nano /etc/locale.gen

#de_CH ISO-8859-1
de_DE.UTF-8 UTF-8
#de_DE ISO-8859-1
#de_DE@euro ISO-8859-15

$ locale-gen

$ nano /etc/locale.conf

LANG=de_DE.UTF-8

$ echo KEYMAP=de-latin1-nodeadkeys > /etc/vconsole.conf
$ localectl --no-convert set-x11-keymap de pc105 deadgraveacute
$ localectl --no-convert set-keymap de-latin1-nodeadkeys

$ localectl status

System Locale: LANG=de_DE.UTF-8
    VC Keymap: de-latin1-nodeadkeys
   X11 Layout: de
    X11 Model: pc105
  X11 Variant: deadgraveacute

$ echo "Norbert" > /etc/hostname

$ useradd -m -G wheel -s /bin/bash produnis

$ passwd produnis

$ EDITOR=nano visudo

%wheel ALL=(ALL:ALL) ALL

Defaults passwd_timeout=0

$ pacman -S networkmanager
$ systemctl enable NetworkManager

$ systemctl enable sshd

# Für AMD
$ pacman -S amd-ucode
# ODER
# Für Intel
$ pacman -S intel-ucode

$ pacman -S plasma-desktop plasma-wayland-session  kde-applications  sddm sddm-kcm plasma-nm

$ systemctl enable sddm

$ exit
$ umount -R /mnt
$ reboot now

Weblinks

• https://wiki.archlinux.de/title/Anleitung_f%C3%BCr_Einsteiger
• https://github.com/dreamsofautonomy/arch-from-scratch
• https://www.youtube.com/watch?v=YC7NMbl4goo

Diskussion per Matrix unter https://matrix.to/#/#produnis-blog:tchncs.de

 

Mozilla hat heute einen Wechsel auf der CEO-Position der Mozilla Corporation bekannt gegeben. Demnach wird Laura Chambers für Mitchell Baker übernehmen.

Mozilla besetzt die höchste Position der Mozilla Corporation, welche unter anderem für die Entwicklung von Firefox verantwortlich ist, neu. Laura Chambers, die bereits seit drei Jahren Mitglied im Verwaltungsrat der Mozilla Corporation sitzt, ist ab sofort und zunächst bis zum Ende des Jahres neuer CEO der Mozilla Corporation. Chambers hatte bereits Führungspositionen bei eBay, PayPal, Skype und AirBnb, zuletzt war sie CEO von Willow Innovations.

Mitchell Baker, bereits seit 25 Jahren bei Mozilla und seit 2020 in der Rolle des CEO, wird wieder in die Rolle des Executive Chairwoman zurückkehren und ihren Fokus verstärkt auf die Repräsentation von Mozilla als Ganzes und in der Öffentlichkeit legen. Schwerpunkte dabei sind Politik, Open Source und Community. Die Öffentlichkeitsarbeit schließt Vorträge und direkten Kontakt mit der Community ein.

Als die zwei Hauptziele von Laura Chambers werden zum einen die Verfeinerung der Unternehmensvision und Ausrichtung der Unternehmens- und Produktstrategie auf diese Vision genannt. Zum anderen sollen die Bemühungen bei den Kernprodukten wie Firefox verstärkt und neue Produkte auf den Markt gebracht werden.

Der Beitrag Laura Chambers ersetzt Mitchell Baker als CEO der Mozilla Corporation erschien zuerst auf soeren-hentzschel.at.

New Tab Override ist eine Erweiterung zum Ersetzen der Seite, welche beim Öffnen eines neuen Tabs in Firefox erscheint. Die beliebte Erweiterung ist nun in Version 16.0 erschienen.

Was ist New Tab Override?

Die Erweiterung New Tab Override erlaubt das Überschreiben der Seite, welche beim Öffnen eines neuen Tabs in Firefox erscheint. Dies kann eine beliebige Website, immer automatisch die aktuelle Startseite, eine lokale Datei, eine Hintergrundfarbe oder die neuesten Nachrichten von diesem Blog sein.

New Tab Override war das erste Add-on, welches das Überschreiben des neuen Tabs ermöglichte, und ist damit das Original und auch heute noch die meistgenutzte Erweiterung dieser Art. New Tab Override wurde im Dezember 2016 auf dem offiziellen Mozilla-Blog vorgestellt, schon mehrfach im Add-on Manager von Firefox beworben und gehört außerdem zu Mozillas handverlesener Auswahl empfohlener Erweiterungen.

Download New Tab Override für Firefox

Die Neuerungen von New Tab Override 16.0

Eine wichtige Änderung betrifft New Tab Override unter der Haube: Die Erweiterung nutzt jetzt das Manifest v3. Während diese Anpassung für den Nutzer nichts ändert, gewährleistet dies die langfristige Kompatibilität von New Tab Override mit Firefox. Dafür ist New Tab Override nicht länger mit Firefox ab Version 78 kompatibel, sondern erfordert in Zukunft Firefox 115 oder höher.

Neben URLs, die mit https:// oder http:// beginnen, können ab sofort auch URLs als Seite für den neuen Tab eingetragen werden, die mit moz-extension:// beginnen, also Seiten anderer Erweiterungen sind.

Wird ein nicht unterstütztes Protokoll angegeben, zeigt New Tab Override nun eine Fehlermeldung anstatt einfach http:// voranzustellen. Wird kein Protokoll durch den Nutzer angegeben, ergänzt New Tab Override jetzt https:// anstelle von http://.

Bei Verwendung eines dunklen Themes flackert der Hintergrund nicht länger für einen ganz kurzen Moment in weißer Farbe, sondern verwendet einen dunklen Hintergrund.

Wird die Option verwendet, eine farbige Fläche als neuen Tab anzuzeigen, wird dabei eine leere Adressleiste angezeigt.

Für eine verbesserte Barrierefreiheit wurden die Farben der Einstellungsseite sowohl im hellen als auch dunklen Theme überarbeitet.

Mit Indonesisch steht eine komplett neue Sprache zur Verfügung. Damit ist New Tab Override jetzt in insgesamt 15 Sprachen übersetzt.

Dazu kam noch eine ganze Reihe kleinerer Verbesserungen unter der Haube, welche Altlasten entfernen und den Code modernisieren.

Der Beitrag New Tab Override 16.0 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Zumindest bis auf Weiteres. Wenn es um die Speicherverwaltung von Linux geht bzw. darum wie viel Speicher tatsächlich belegt bzw. frei ist, wird gerne auf www.linuxatemyram.com verwiesen. Immer mehr Nutzer raten von dieser Quelle allerdings ab, weil die dort genannten Informationen teilweise veraltet, ungenau bzw. falsch sind. Und das seit Jahren.

Ein Nutzer hat sich im April letzten Jahres die Mühe gemacht und einen Pull Request mit 12 Commits erstellt, um die Internetseite an die aktuellen Gegebenheiten anzupassen.

So wie es aussieht hat die betreffende Seite für den Betreiber, welcher übrigens auch für das von mir geschätzte Tool shellcheck verantwortlich ist, allerdings keine allzu hohe Priorität. Zumindest ist bisher weder eine Reaktion auf den Pull Request erfolgt noch wurde dieser angenommen oder abgelehnt. Vielleicht wäre es daher sinnvoller die Seite einfach zu deaktivieren. Zumal .com Domains ja auch nicht zu den billigsten Domains gehören.

Mozilla hat seinem Dienst Firefox Monitor wie erwartet einen neuen Anstrich verpasst und diesen in Mozilla Monitor umbenannt. In den USA ist außerdem das kostenpflichtige Premium-Angebot Mozilla Monitor Plus gestartet.

Bereits im April 2023 hatte ich exklusiv darüber berichtet, dass Mozilla an einer Premium-Version von Firefox Monitor arbeitet, und seit dem mehrfach über neue Informationen berichtet, zuletzt im Januar über den bevorstehenden Relaunch am 6. Februar.

Relaunch von Mozilla Monitor

Mozillas kostenfreier Dienst Mozilla Monitor zeigt nach Eingabe einer E-Mail-Adresse an, ob diese Teil eines bekannten Datendiebstahls in der Vergangenheit war. Neben dem Zeitpunkt des Diebstahls und dem Zeitpunkt des Bekanntwerdens wird auch angegeben, welche Daten gestohlen worden sind, zum Beispiel E-Mail-Adressen, Benutzernamen oder Passwörter. Darüber hinaus nennt Mozilla Monitor allgemeine Tipps, welche man in Betracht ziehen sollte, wenn man von einem Datendiebstahl betroffen ist.

Der bisher als Firefox Monitor bekannte Dienst, der nach Angaben von Mozilla über zehn Millionen angemeldete Nutzer hat, ist ab sofort unter dem neuen Namen Mozilla Monitor und mit neuer Website online.

Mozilla Monitor Plus in den USA

Für Nutzer in den USA ist außerdem Mozilla Monitor Plus an den Start gegangen. Damit können persönliche Informationen von über 190 Personen-Suchmaschinen entfernt werden – einer laut Mozilla 240 Milliarden Dollar schweren Industrie, welche mit der Bildung von Profilen und dem Verkauf dieser Daten Profit generiert.

Nutzer der kostenlosen Version von Mozilla Monitor können ihre Daten einmalig überprüfen lassen. Für Nutzer von Mozilla Monitor Plus erfolgt eine monatliche Überprüfung – immerhin könnten diese Seiten ja jederzeit wieder neue Informationen hinzufügen. Außerdem kann Mozilla Monitor Plus automatisch die Entfernung von diesen Seiten in die Wege leiten, während Nutzer der kostenlosen Version beim einmaligen Check zwar gesagt bekommen, wo ihre Daten zu finden sind, die Entfernung aber manuell bei den jeweiligen Websites beantragen müssen.

Mozilla Monitor Plus kostet 13,99 USD pro Monat bei nur einem Monat Vertragsbindung. Wer sich direkt für ein ganzes Jahr bindet, spart 35 Prozent und zahlt nur 8,99 USD pro Monat.

Da Mozilla für das neue Feature auf die Dienste von OneRep setzt, welche ausschließlich in den USA aktiv sind, ist mit keiner zeitnahen Ausrollung in weiteren Ländern zu rechnen – sofern OneRep selbst keine Expansions-Pläne verfolgt. Sollte der Dienst in den USA gut angenommen werden, ist natürlich nicht auszuschließen, dass sich Mozilla mittelfristig nach vergleichbaren Lösungen auch für andere Länder umsehen wird.

Der Beitrag Relaunch von Mozilla Monitor, Premium-Angebot in den USA gestartet erschien zuerst auf soeren-hentzschel.at.

Die Distro wurde vor einem Jahr angekündigt, im August gab es die Entwicklervorschau und nun steht die Beta-Version zum Testen bereit.

Orchid ist eine komplette Neufassung des Projekts Vanilla OS mit dem Ziel, ein stabiles, sicheres, schnelles und benutzerfreundliches Betriebssystem ohne Kompromisse zu bieten. Das Projekt von Grund auf neu bewertet, wobei das umfangreiche Feedback, welches mit der ersten Version eingegangen ist, berücksichtigt.

Alles zu beschreiben, was sich in Vanilla OS 2 Orchid geändert hat, ist in einem Artikel kaum möglich, denn auch wenn es auf den ersten Blick ähnlich aussieht wie die erste Version, ist es unter der Haube eine völlig neue Welt mit neuen Technologien, Konzepten und Standards.

Daher beschränke ich mich auf eine Kurzfassung der Neuerungen. Viel mehr Details findet ihr in diesem Blog-Beitrag des Entwicklerteams zur Beta Version.

Es gibt ein neues Hintergrundbild in heller und dunkler Version, dass das Thema der Orchidee wiedergibt (siehe Titelbild). Die Version 2 verabschiedet sich von Ubuntu als Basis und setzt nun auf Debian auf. Dabei kommen Debian Pakete und Vib Container Images zum Einsatz. Bei den Updates wurde von einer paketbasierten Struktur auf eine OCI-Image basierte Struktur gewechselt.

Auch die A/B-Partitionierung wurde weiterentwickelt. Die Version 2 von ABRoot soll zuverlässiger und schneller arbeiten. Die Transaktionen erfolgen nun über die OCI-Image-Erweiterung, anstatt über die Anwendung von Paket-Updates, wodurch sichergestellt wird, dass das System eine exakte Kopie des getesteten Images erhält. In ABRoot v1 konnten Benutzer auf die transaktionale Shell zugreifen, um atomare Systemänderungen vorzunehmen. In ABRoot v2 wurde diese Funktion entfernt und durch die Unterstützung für die Erstellung benutzerdefinierter lokaler Images ersetzt. Wenn etwa ein Treiber installiert wird, der nicht im System vorhanden ist, kann ABRoot ein benutzerdefiniertes Abbild mit dem installierten Treiber erzeugen.

Um einen der Hauptkritikpunkte von Vanilla OS 22.10 zu beseitigen, nämlich den zugewiesenen Speicherplatz für die beiden Root-Partitionen, die insgesamt 20 GB für Root ausmachen und 40 GB Festplattenplatz beanspruchen, wurde Unterstützung für LVM Thin Provisioning eingeführt. Diese Technologie ermöglicht die Erstellung von logischen Volumes mit variabler Grösse und optimiert so die Nutzung des Festplattenplatzes. Jetzt teilen sich die beiden Root-Partitionen insgesamt 20 GB, die dynamisch auf der Grundlage der Grösse der beiden Partitionen zugewiesen werden, wodurch mehr Speicherplatz für Benutzerdaten zur Verfügung steht.

In Vanilla OS 2 Orchid wurde sudo durch PolKit-Richtlinien ersetzt, die es den Benutzern ermöglichen, privilegierte Operationen auf eine kontrolliertere und sicherere Weise durchzuführen. Der Benutzer hat weiterhin Zugriff auf sudo, aber nur innerhalb des VSO-Subsystems (Vanilla System Operator).

Benutzer haben nun keinen direkten Zugriff mehr auf die System-Shell; wenn sie die Konsole öffnen, gelangen sie in die VSO-Shell, ein integriertes und veränderbares Subsystem von Vanilla OS. Es ermöglicht den Nutzern, Anwendungen wie in jeder Linux-Distribution zu installieren und auszuführen, ohne das System zu beeinträchtigen. Ausserdem unterstützt VSO jetzt Android-Anwendungen, die als native Anwendungen installiert und ausgeführt werden können, ohne dass ein Emulator erforderlich ist. Zudem wurde F-Droid als Paketquelle integriert. Nutzer können .deb- und .apk-Pakete installieren, indem sie sie einfach mit der Sideloading-Anwendung öffnen, die die Installation in das richtige Subsystem übernimmt.

Apx v2 spielt jetzt eine völlig neue Rolle, indem es als leistungsstarkes Werkzeug für Entwickler und Kreative dient. Es ermöglicht die Erstellung von benutzerdefinierten Umgebungen (Stacks) für verschiedene Bedürfnisse. Benutzer können etwa einen Stack auf Basis von Arch Linux erstellen, yay als Paketmanager anstelle von pacman definieren und Pakete von AUR ohne Probleme installieren.

FsGuard ist das Tool, das während des Systemstarts die Integrität der System-Binärdateien prüft, um sicherzustellen, dass keine Diskrepanzen mit dem vom System-Image bereitgestellten Zustand bestehen. Wird eine Änderung festgestellt, startet FsGuard FsWarn, das den Systemstart unterbricht, den Benutzer über das Problem informiert und ihm rät, das System im vorherigen Zustand neu zu starten, um die Integrität des Systems zu gewährleisten.

Das Installer-Backend wurde von DistInst zu Albius gewechselt, weil dieser die Systeminstallation von OCI-Images unterstützt. Dem Vanilla-Installer wurden einige überarbeitete Fenster spendiert:

Sobald das System installiert ist, fragt das First Setup nicht nur nach den zu installierenden Anwendungen, sondern ermöglicht dem Benutzer auch die Konfiguration von Benutzername, Gerätename, Zeitzone, Sprache, Tastatur und Netzwerk.

Nach Abschluss der Ersteinrichtung wird der Benutzer von einer neuen Anwendung auf eine Systemtour mitgenommen, die die wichtigsten Funktionen des Systems vorstellt und so die erste Begegnung mit Vanilla OS einfacher und verständlicher macht.

Wie geht es weiter?

Orchid befindet sich derzeit in einem Feature Freeze, und das Team arbeitet an der Behebung kleinerer und während des Testzeitraums gemeldeter Fehler. Die stabile Version wird veröffentlicht, sobald alle gemeldeten Fehler behoben sind, optimistischerweise noch in diesem Sommer.

Wer beim Testen mitmachen möchte, findet die Beta-Version zum Downloaden auf dieser Seite. Dabei hilft auch die aktualisierte und zusammengeführte Dokumentation, die allerdings noch nicht vollständig ist.

Quelle: https://vanillaos.org/blog/article/2024-01-30/vanilla-os-2-orchid-beta-is-here

Mozilla hat Firefox 122.0.1 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 122.0.1

Mit dem Update auf Firefox 122.0.1 behebt Mozilla das Problem, dass bei Benachrichtigungen unter Windows trotz Klicken auf die Schaltfläche zum Ausblenden die mit der Benachrichtigung verknüpfte Website geöffnet worden ist.

Für Linux-Nutzer mit dem Yaru Remix Theme sowie für Nutzer älterer Ubuntu-Versionen wurden nicht die korrekten Farben verwendet.

Das Kontextmenü für Tab-Umgebungen in der Bibliothek sowie in der Sidebar zeigte nur die Icons und nicht die Namen der jeweiligen Umgebungen.

Mit Firefox 122 hatte Mozilla die Tastatur-Steuerung des Regeln-Panels im Inspektor-Werkzeug überarbeitet. Diese Änderung hat Mozilla aufgrund von Nutzer-Feedback wieder rückgängig gemacht. Wer das geänderte Verhalten bevorzugt hat, kann dieses über about:config wieder aktivieren, indem der Schalter devtools.inspector.rule-view.focusNextOnEnter auf false gesetzt wird. Ab Firefox 124 wird es dafür eine sichtbare Option in den Einstellungen der Entwicklerwerkzeuge geben.

Beim Kopieren von CSS aus dem Inspektor wurde fälschlicherweise die öffnende Klammer in einer neuen Zeile angezeigt.

Ein Webkompatibilitätsproblem wurde behoben, bei dem das Einfügen einer Importmap verursachen konnte, dass darauffolgende Module nicht geladen werden konnten. Ein weiteres Webkompatibilitätsproblem betrifft eine in Firefox 122 durchgeführte Änderung bezüglich externer Protokoll-Handler, welche korrekt gemäß Spezifikation war, in der Praxis aber Probleme verursacht hat und mit Firefox 122.0.1 rückgängig gemacht worden ist.

Eine mögliche Absturzursache beim CSS-Rendering wurde behoben, ebenso ein Rundungs-Problem bei der Berechnung der Scroll-Position. Außerdem wurde eine hohe CPU-Auslastung auf Websites korrigiert, welche Animationen und einen ResizeObserver verwenden.

Darüber hinaus gab es noch Verbesserungen in Zusammenhang mit der Funktion, über das Firefox-Menü Kompatibilitätsprobleme mit Websites an webcompat.com zu melden, welche derzeit experimentell für einen Teil der Nutzer aktiviert ist.

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