Das AftermarketOS /e/ bzw. nunmehr teilweise Murena wird seit einiger Zeit als große Hoffnung gehandelt. Vieles ist dort gut gelöst, weil man versucht die Stärken von iOS zu übernehmen. In der Umsetzung gibt es aber Mängel.

/e/ war in diesem Blog vor knapp zwei Jahren schon ein mal Thema. Damals konnte es nicht überzeugen, aber da es weiterhin als relevanes Thema durch einschlägige Plattformen geistert, wollte ich einen zweiten Blick darauf werfen und die weitere Entwicklung prüfen.

Was ist /e/ bzw. /e/OS?

Hinter der Gründung /e/ steht unter anderem Gaël Duval – ein Urgestein der Open Source Community. Vor 20 Jahren kombinierte er Red Hat mit KDE und schuf dadurch Mandrake Linux. Der Open Source Welt ist er Treu geblieben, doch wie so viele hat er sich aus der aktiven Linux-Entwicklung zurück gezogen und ist nun auf anderen Baustellen unterwegs.

/e/ ist ein ziemlich ungünstiger Name, das hat man inzwischen beim Projekt auch begriffen und firmiert deshalb nach und nach in Murena um. Wobei mir nicht klar ist, was alles unter der neuen Marke laufen wird.

Vom Prinzip her ist das /e/OS ein LineageOS plus microG, ein eigener Launcher und spezifische /e/-Mehrwertdienste. Das /e/OS hat zwar mit dem Launcher und dem eigenen Icon-Theme optische Alleinstellungsmerkmale, aber der versierte Nutzer erkennt sofort die LineageOS-Basis.

Vor allem Letztere machen hier den Unterschied aus und vermutlich der Grund, weshalb viele das Konzept von /e/ loben und hier die Zukunft sehen. /e/ bietet mit der eCloud ein Open Source-basiertes Pendant zum Google oder Apple-Ökosystem. E-Mail und PIM, ein Cloudspeicher und verschiedene WebApps sollen das Google Konto oder die iCloud ersetzen. Durch die direkte Integration in das AftermarktetOS kann man die eCloud genau so einfach wie ein Google Konto einrichten.

/e/OS als Kern des Ökosystems kann dabei ziemlich unterschiedliche Versionen bezeichnen. Neben den offiziellen Geräten, die sich als Murena Smartphones im Shop erwerben lassen, gibt es an die 200 „unterstützte“ Geräte, bei denen ganz unterschiedliche Android-Versionen laufen.

Kritikpunkte

Das Konzept ist interessant und versucht die Grenzen anderer Aftermarket-Lösungen hinter sich zu lassen, die doch eher den mündigen Nutzer angesprochen haben, der sein Gerät selbst einrichten kann und viele Details selbst konfigurieren möchte. /e/ will hingegen ganz offenkundig eher eine Lösung Out-of-the-Box bieten. Leider stößt man hier an zahlreiche Grenzen und macht vieles leider auch ziemlich schlecht.

• /e/ wirbt damit fast 200 Geräte zu unterstützen. Dabei haben nur ganz wenige wie z. B. das Fairphone oder Gigaset GS290 offiziellen Support. Bei allen anderen hat man mehr oder minder gut LineageOS mit den /e/ Zusatzbestandteilen versehen. Mein Testgerät, ein Samsung Galaxy S10, das offiziell bei LineageOS unterstützt wird, kommt bei /e/ mit Sicherheitsupdates vom 5. August und Herstellerpatches vom 01. Juli. Die /e/-Version ist dabei aus dem August. Das ist indiskutabel. Weniger wäre hier mehr.
• AftermarketOS können sowieso nur hinsichtlich des Datenschutzes punkten. Bei der Sicherheit sind sie den Herstellersystemen nahezu immer unterlegen. Das ist systemimmanent und kann durch die Entwickler der Aftermarket-Lösungen nicht beeinflusst werden.
• Als Store liefert man weder F-Droid, noch Aurora, sondern eine eigene Lösung. Woher die Apps kommen ist für den Anwender völlig intransparent. Lediglich über die FAQ erfährt man, dass die Apps von CleanAPK stammen – eine reichlich dubiose Lösung. Im Angebot sind zahlreiche Open Source Apps, aber auch proprietäre Apps. Wenigstens wird auf Tracker hingewiesen.
• Vorinstallierte sind zahlreiche Open Source Apps, denen man teilweise ein eigenes Branding übergezogen hat. Es gibt aber auch einige Spezialsachen wie die Karten-App Magic Earth. Bei einer Nutzung werden zahlreiche Verbindungen zum Anbieter initiiert. Die Seite hat kein Impressum und Büros in der Schweiz, Österreich, den Niederlanden und Rumänien.
• Das Gerät nimmt in der Standardkonfiguration Verbindungen zu Google-Servern wie „supl.google.com“ auf und ist damit nicht so Google-frei wie beworben.
• /e/OS implementiert vollumfänglich microG. Vom Servicekonzept ist das nachvollziehbar, aber ich persönlich stehe microG kritisch gegenüber.

Insgesamt bleibt es deshalb beim selben Fazit wie vor 2 Jahren. Das Konzept ist interessant, aber die Liste der Kritikpunkte und Mängel ist lang. Hier hat man seitdem keine substanziell erkennbaren Fortschritte gemacht. Ich hatte vor zwei Jahren durchaus noch das Entwicklungspotenzial gesehen, aber das fällt mir nun schon schwerer. Meiner Ansicht nach ist /e/ ein toter Zweig der Android-Entwicklung. Eine interessante Idee, die auf halber Strecke stecken geblieben ist. Auch weil viele Probleme im Android-Ökosystem jenseits der Einflussmöglichkeiten eines solchen Projekts waren und sind.

/e/OS ist in seinem gegenwärtigen Zustand sicherlich eine interessante Alternative für jene, die von ihrem Stock Android weg möchten, dabei aber wenig bis keine Kompromisse machen wollen. Hier sollte man aber genau prüfen, welche Version für die eigene Hardware bereit steht. Wie groß diese Zielgruppe ist und ob man als Anwender am Ende wirklich etwas hinsichtlich des Datenschutzes gewinnt oder es nicht doch mehr Placebo ist, wenn man auf /e/ wechselt, kann man durchaus bezweifeln.

Der Artikel /e/ – Viele gute Ansätze aber schlechte Umsetzung erschien zuerst auf [Mer]Curius

Es gibt mal wieder Schwachstellen in X.Org. Genauer gesagt wurden mal wieder neue Schwachstellen entdeckt. Die Software steckt sicherlich voll von noch mehr Problemen und ihre vollständige Ablösung ist mehr als überfällig.

Leider zieht sich die Wayland-Transformation länger hin, als das vor ein paar Jahren alle vermutet hatten. GNOME war zuerst Wayland-tauglich und seit diesem Jahr funktioniert auch KDE Plasma mehr oder minder gut mit Wayland. Alle anderen Desktopumgebungen und Fenstermanager sind noch nicht so weit oder werden vielleicht nie so weit sein. Hier wird sich vermutlich die Spreu vom Weizen trennen, wenn die Distributionen nicht mehr bereit sind X.Org zu pflegen. Die Linux-Welt muss also noch einige Zeit mit X.Org leben müssen.

Es tut mir fast schon ein wenig leid, dass ich schon wieder was Negatives über Debian schreiben muss. Die Updateprobleme bei Firefox reichen eigentlich schon. Leider sind die Fakten wie sie sind:

Es geht um folgende vier Sicherheitslücken: 2021-4008, 2021-4009, 2021-4010, 2021-4011. Diese wurden durch die Zero Day Initiative von Trend Micro gefunden.

Öffentlich bekannt sind die Lücken seit dem 14. Dezember. Die Distributionen wurden allerdings bereits vorab informiert, um schnell Sicherheitsupdates bereitstellen zu können. Entsprechende Patches lagen Upstream vor. Das Vorgehen ist somit ideal und die notwendige Eigenleistung der Maintainer überschaubar. Ein entsprechender Bugreport für CVE 2021-4008 datiert im SUSE Bugzilla auf den 24. November. Das Changelog bei SLE/openSUSE Leap verrät zudem, dass die Lücke bereits am 25. November geschlossen wurde.

Pünktlich am 14. Dezember verteilte SUSE die Updates für die Lücken. Das gilt ebenso für Ubuntu, wo Canonical ebenfalls am 14. Dezember pünktlich Updates verteilte. Fedora war ein bisschen langsamer, die Updates kamen erst vor einigen Stunden in die beiden unterstützen Varianten Fedora 34 und 35. Den Status für RHEL konnte ich nicht herausfinden, gehe aber davon aus, dass dieser mindestens analog zu Fedora ist. Bei Debian ist hingegen aktuell immer noch Schweigen im Walde. Lediglich für Sid und Testing hat man Updates bereits verteilt.

Ich möchte hier jetzt nicht schon wieder zum Rundumschlag ausholen, weil ich mit Sicherheit keine Kampagne gegen Debian fahren möchte. Fakt ist, dass sich Debian-Anwender die Entwicklung ganz genau ansehen sollten. Für mich ist aktuell Debian für den Desktop nur noch unter Vorbehalt empfehlenswert. Vorlieben bei Distributionen, lang gepflegte Distro-Wars, Kritik an irgendwelchen Communitys etc. sind nett für die eigene Entscheidungsfindung, aber bei offenen Sicherheitslücken hört der Spaß auf.

Der Artikel Debian – Verzögerung bei Sicherheitsaktualisierungen erschien zuerst auf [Mer]Curius

Sa 18. Dezember 2021, Norbert Rüthers

Nur eine kurze Mitteilung. Bereits in einem anderen Artikel wurde hier die neue Version 2021-4 von Kali Linux vorgestellt

Bisher lief Kali Linux auf dem Raspberry nur mit SD-Karte. Das hat sich mit der neuesten Version geändert

Kali Linux 2021-4 ist jetzt auch auf einem Raspberry Pi mit HDD oder SSD nutzbar. Man kann das Image von Kali einfach z.B. mit Balena Etcher auf die Festplatte übertragen. Beim ersten Start wird die Grösse der Festplatte automatisch angepasst, was bei grossen Festplatten ein paar Minuten dauern kann.

Die deutsche Sprachanpassung kann mit folgendem Kommando auf dem Terminal erfolgen

dpkg-reconfigure locales

Das Tastaturlayout lässt sich in den normalen Systemeinstellungen anpassen. Beim Test auf einem Raspberry Pi 4 mit 4 GB RAM und SSD ist ein ziemlicher Performance-Schub im Vergleich zur SD-Karte spürbar.

Quelle: https://www.kali.org/

Eine konstruktive Auseinandersetzung lebt davon, dass man grundsätzlich vom selben spricht und dasselbe unter den verwendeten Begriffen versteht. Das war bei Linux immer klar, weil sie Systeme sehr uniform waren. Das ändert sich nun.

Linux-Systeme waren in der Vergangenheit relativ gleichförmig und in den letzten Jahren gab es meiner Meinung nach sogar einen Trend zu noch mehr Gleichförmigkeit. Das ändert sich in einigen Teilen des Linux-Ökosystems nun wieder. Man denke nur an Fedora Silverblue oder openeSUSE MicroOS. Das sind keine rein experimentellen Projekte, sondern bei Fedora ist man sich sicher, dass hier die Zukunft liegt. Durch diese Entwicklung entsteht eine Chance, weil das ausufernde Distributionssystem nur bei wirklichen Alternativen Sinn macht und nicht, wenn man praktisch 100 Mal das Gleiche bekommt.

Es führt aber auch zu Problemen. Das konnte man jüngst beobachten, als sich verschiedene Personen mal wieder über das Für und Wider von Flatpak stritten. Den Anfang machte der ausufernde Artikel „Flatpak Is Not the Future“ auf den es verschiedene Repliken gab. Besonders hervorheben möchte ich „On Flatpak disk usage and deduplication„. In der Sache mag ich mich daran nicht mehr beteiligen, weil ich dazu in einem Artikel mal alles zusammen geschrieben habe, was zum Thema Flatpak, Snap und Paketverwaltung zu sagen ist.

Man kann aber bei der Argumentation sehen, dass es zunehmend schwieriger wird, sich auf eine gemeinsame Diskussionsgrundlage zu verständigen, weil die Voraussetzungen stark abweichen. Ich möchte das an zwei überzeichneten „Szenarien“ demonstrieren.

Die Befürworter moderner Paketformate wie Snap und Flatpak nutzen – und setzen damit auch als Diskussionsgrundlage voraus – moderne Systeme. Diese Systeme sind auf der Höhe dessen, was die Linux-Entwicklung in den letzten Jahren hervorgebracht hat. Ein aktueller Kernel wird begleitet von systemd, das zentrale Aufgaben im System effizient erledigt. Als Dateisystem nutzt man moderne Systeme wie Btrfs mit State-of-the-Art Funktionen wie z. B. Deduplizierung und flexible Subvolumes anstelle von Legacy-Partitionierungsschemata. Der Speicherbedarf ist bei solchen Systemen keine objektive Größe mehr und man kann flexibel auf Änderungen reagieren. Anstelle in dogmatischen Konzepten, denkt man in gewünschten Funktionen. Ein Beispiel dafür ist der Versuch, Betriebssystemupdates resistenter gegen Fehler zu machen, indem man Rollback-Methoden implementiert und dafür mit der Unix-Dateisystemstruktur bricht. Im openSUSE-Umfeld arbeitet man daran seit Jahren. Mit Fedora Silverblues rpm-ostree und read-only Dateisystemen hat man hier ganz neue Maßstäbe gesetzt. Updates werden vereinfacht gesagt als Images neben der bisherigen Installation eingerichtet und durch einen Neustart aktiviert. Das funktioniert nur, wenn man die Anwendungsinstallation vom Betriebssystem löst, weil der Anwender sonst andauernd neustarten müsste. Diese Entwicklungen bilden die Grundlage für weiterführende Überlegungen, wie man Linux noch sicherer machen könnte. Hier orientiert man sich an dem, was andere Hersteller in ihre Betriebssysteme implementieren. Entwickler Anwender solcher Systeme nutzen dann zudem meist noch einen modernen Desktop wie Plasma oder GNOME mit Wayland, weil sie X.Org als Sicheitsproblem wahrnehmen – aber das nur als Nebenaspekt.

Die Kritiker der Entwicklung gehen von gänzlich anderen Voraussetzungen aus. Konzepte und Grundlagen mit jahrzehntelanger Gültigkeit wie z. B. „Unix-Philosophie“ oder „KISS-Prinzip“ sind für sie handlungsleitend. Sie waren mit der Linux-Entwicklung zu einem gewissen Stichtag zufrieden. Das kann je nach Person variieren, aber liegt bei den meisten irgendwo um die Jahre 2008 bis 2014 herum. Dadurch ergibt sich ein völlig anderes Problem- bzw. Desideratbewusstsein. Weiterentwicklung bedeutet für sie eine evolutionäre Fortschreibung des Status quo. Die integrierte Paketverwaltung ist für sie die das Ergebnis von 20 Jahren Entwicklungsarbeit. Objektiv gemessene Effizienz und kleinteilige Patches sind für sie der Maßstab des Erfolgs. Der ganze Container-Hype war ihnen schon immer suspekt und wurde höchstens am Rande verfolgt. Objektiv messen können sie Sachen wie Speicherverbrauch, weil sie Entwicklungen wie Btrfs immer als instabil abgelehnt haben, das letzte Mal von ext3 auf ext4 migriert sind und deshalb viele Funktionen nur vom Hörensagen kennen. Subvolumes brauchen sie nicht, weil LVM ihnen genug Kontrolle gibt und sie keinen Mehrwert hinter flexibleren Lösungen sehen. Read-only Systeme sind für sie moderner Schnickschnack von Apple und Googles Smartphones, der ihnen Eingriffsmöglichkeiten und Kontrolle nimmt. Das gilt ebenfalls für Sachen wie Secure Boot oder TPM und darauf aufbauende Konzepte. Die Adaption scheitert hier schon, weil man der systemd-Entwicklung skeptisch gegenüber steht und es höchstens als Init-System nutzt und bei den anderen Bestandteilen auf spezialisierte Alternativen zurückgreift. Selbst die vorbereitenden Maßnahmen zu Schnappschüssen, wie z. B. der usr-merge sind für sie eigentlich Verrat an Unix-Prinzipien und wurden widerwillig mitgetragen. Probleme mit der Paketverwaltung und Upgrades hatten sie ja schließlich nie. Die Sicherheit von Linux ist unübertroffen, das zeigen schließlich die Fakten und ständigen Sicherheitslücken bei Windows. Abgerundet wird dieses Bild durch einen konservativen Desktop wie z. B. Xfce oder MATE und den X-Server, da sie keinesfalls auf wichtige Linux-Errungenschaften wie Netzwerktransparenz verzichten möchten.

Diese beiden Gruppen eint mit jedem Jahr weniger – abgesehen davon, dass beide glauben, sie würden Linux verwenden. Diese Auseinanderentwicklung ist der Grund für wenig zielführende Debatten wie sie oben beispielhaft verlinkt sind. Die eine Seite sagt, Flatpak braucht viel Speicherplatz, weil ein Flatpak so und soviel MB groß ist und ein klassisches Paket weniger hat. Außerdem würden Flatpaks außerhalb der Unix-Struktur abgelegt und die Partitionen wären an bestimmten Stellen dann zu klein. Die andere Seite sagt, das stimmt gar nicht, weil der Unterschied dank Deduplizierung von Runtimes marginal wäre und flexible Strukturen sich jederzeit an neue Erfordernisse anpassen lassen.

Beide Seiten haben auf ihre Art recht. Die Grundlagen, von denen man ausgeht, divergieren im Extremfall inzwischen so stark, das man eigentlich keine gemeinsame Diskussionsgrundlage mehr hat. Vielleicht wäre das auch einfach die Einsicht, an der man eine Diskussion beenden kann.

Der Artikel Das Problem: Wir reden nicht mehr vom selben Linux erschien zuerst auf [Mer]Curius

Mozilla hat mit Firefox 95.0.1 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht.

Download Mozilla Firefox 95.0.1

Mit dem Update auf Firefox 95.0.1 behebt Mozilla das Problem, dass Firefox-Nutzer diverse Microsoft-Websites nicht länger aufrufen konnten und nur den Fehlercode MOZILLA_PKIX_ERROR_OCSP_RESPONSE_FOR_CERT_MISSING erhalten hatten, nachdem Microsoft eine serverseitige Konfigurationsänderung (OCSP-Stapling mit SHA-256-Hashes) durchgeführt hat, die von Mozillas NSS-Bibliothek so bisher nicht unterstützt worden war.

Behoben wurde auch eine mögliche Absturzursache in Zusammenhang mit WebRender unter Linux/X11 sowie eine mögliche Absturzursache beim Beenden von Firefox unter Windows.

Der Vergangenheit angehören sollten auch Probleme mit dem Website-Kontrast für manche Linux-Nutzer, welche den Dark Mode auf Betriebssystem-Ebene aktiviert haben.

Der seit Firefox 95.0 bei Verwendung von Slack überschriebene User-Agent wird nicht länger überschrieben, nachdem Slack seit diesem Montag auch für Firefox-Nutzer das Huddles-Feature unterstützt.

Außerden wurden mehrere Verbesserungen in Zusammenhang mit Remote-Einstellungen vorgenommen, welche insbesondere Nutzer von Linux Mint betreffen, wo Suchmaschinen-Einstellungen bei einem Upgrade nicht ordnungsgemäß aktualisiert worden waren.

Schließlich wurde noch behoben, dass die Einstellungen für manche Nutzer einen neuen Reiter anzeigten, der noch nicht sichtbar sein sollte.

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

Mi, 15. Dezember 2021, Niklas

Lakka ist keine gewöhnliche Linux Distribution. Sie ist vollkommen auf Gaming ausgerichtet, und zwar auf sehr alte Spiele. Sie nutzt LibRetro und RetroArch als Emulator für eine Vielzahl alter Spielekonsolen. Die Emulatoren werden alle direkt mitgeliefert, nur die Spiele muss man selbst haben.

Lakka basiert auf der Distribution LibreELEC. Es ist sehr leichtgewichtig, das GZip komprimierte Image ist nur gut 600 MB gross. Lakka kann auf einer Vielzahl von Einplatinencomputern genutzt werden, wie zum Beispiel den meisten Versionen des beliebten Raspberry Pi. Auch eine x86 Version ist verfügbar. Ich teste es wie immer auf meinem Lenovo 3000 N200 Laptop.

Das System startet innerhalb von wenigen Sekunden vom USB-Stick in ein Live System. Alternativ kann es auch auf der Festplatte installier werden. Das User-Interface ist an die Playstation angelehnt. Es kann komplett mit einem Controller bedient werden, Maus und Tastatur sind nicht notwendig. Wer keinen Controller hat, kann allerdings auch eine Tastatur verwenden. Die Maus hat auf dem Betriebssystem keine Funktion.

Da Lakka keine Spiele mitbringt, ist es sinnvoll, zunächst die WLAN-Verbindung einzurichten. Man hat dann Zugriff auf den Online Updater, mit dem man im Bereich Content Downloader ein paar ausgewählte Spiele herunterladen kann. Bei meinem Test haben leider die wenigsten davon funktioniert. Die Verzeichnisstrukturen sind ausserdem sehr unübersichtlich, Lakka zeigt nicht nur die ausführbare Datei des Spiels, sondern alle zugehörigen Dateien.

Eine wesentlich grössere Auswahl an Spielen bieten spezielle Downloadportale für Retro Spiele, wie beispielsweise Retrostic. Das hier heruntergeladene Super Mario Kart funktioniert bei meinem Test auf Lakka einwandfrei. Da Lakka keinen eigenen Browser mitbringt, muss man die Spiele jedoch über einen anderen Computer herunterladen und per Samba auf die Lakka Installation übertragen. Der Samba Server von Lakka ist standardmässig aktiviert und wurde von meinem FreeBSD Computer ohne Weiteres gefunden.

Wer noch originale Spiel DVDs von früher hat, braucht diese nur ins DVD-Laufwerk des Lakka Computers zu legen und kann sie direkt starten oder wahlweise auch auf die Festplatte kopieren, um nicht immer die DVD zu brauchen. Diese Funktion konnte ich mangels DVDs nicht testen.

Auch Multiplayer Spiele sind mit Lakka kein Problem, es können bis zu 5 Controller angeschlossen werden, vorausgesetzt das verwendete Gerät hat so viele Anschlüsse. Über die Funktion Netplay können ausserdem mehrere Lakka Geräte miteinander verbunden werden, sodass Multiplayer Spiele auch aus der Ferne möglich sind. Eine Lakka Installation ist dabei der Server, andere können sich als Client verbinden.

Wer sich lieber online mit Spielern aus aller Welt messen möchte, findet bestimmt die Funktion Achievements interessant, die eine Integration von RetroAchievements bietet. Auf der Seite können Achievements in einer Vielzahl von Retro Spielen gesammelt werden, es gibt fast 200000 registrierte Spieler, eine Teilnahme ist kostenlos.

Fazit: Lakka bietet alles, was sich Fans von Retro Konsolen nur wünschen können und noch viel mehr, als die alten Originale konnten. Es wirkt ausgereift und ist einfach zu bedienen. Mit meinem Laptop habe ich allerdings mangels Alternativen ein denkbar schlechtes Testgerät gewählt - viel mehr Spass macht es am grossen Fernseher und mit richtigen Controllern, vor allem wenn man zusammen mit Freunden oder Familie zocken will.

Mi, 15. Dezember 2021, Lioh Möller

Trisquel wird von einigen Anwendern auch liebevoll als die Linux-Distribution der Herzen bezeichnet. Grund dafür ist, dass sie vollständig auf Freier Software basiert und den fsf Richtlinien für Freie GNU/Linux-Verteilungen entspricht. Damit einher geht allerdings, dass die eigene Hardware möglicherweise nicht lauffähig ist, sofern für deren Betrieb unfreie Treiber benötigt werden. Dies ist beispielsweise bei vielen W-LAN-Adaptern der Fall.

Darüber hinaus basiert Trisquel in der Regel auf einer älteren Ubuntu Version. So kommt bei der aktuellen stabilen Version Trisquel 9.0 "Etiona" beispielsweise Ubuntu 18.04 als Basis zum Einsatz.

Nun haben die Entwickler erste Pre-Release-Versionen von Trisquel 10.0 zum Testen bereitgestellt, welche auf der aktuellen Ubuntu LTS Version 20.04 basieren.

Ein Download ist aufgrund von Einschränkungen des Spiegelservers beispielsweise mithilfe von lftp möglich:

sudo apt install lftp

lftp -c 'set net:idle 10
         set net:max-retries 0
         set net:reconnect-interval-base 3
         set net:reconnect-interval-max 3
         pget -n 10 -c "http://cdbuilds.trisquel.org/trisquel_10.0_amd64.iso"'

Alternativ zur Hauptversion, bei der MATE als Desktopumgebung genutzt wird, wird eine Variante mit KDE Plasma namens Triskel angeboten. Für ältere Rechner eignet sich Trisquel lite bei der LXDE zum Einsatz kommt. Eine vollständige Liste aller verfügbaren Versionen ist auf dem Spiegelserver einsehbar.

Neben den bereits in Ubuntu 20.04 enthaltenen Aktualisierungen wie LibreOffice 7.1, bietet Trisquel 10.0 eine befreite Variante des Firefox Browsers mit dem Namen Abrowser an. Letztere wird aktuell in Version 95.0 mitgeliefert und regelmässig aktualisiert. Die Entwickler sind über Feedback dankbar.

Debian und Firefox ist momentan ein heißes Eisen. Eine Distribution, die sich Sicherheit und Stabilität auf die Fahnen schreibt und dann wochenlang keine Firefox-Updates verteilen kann, steht zurecht im Zentrum der Kritik. Zumindest dieses Problem scheint bald gelöst.

Normalerweise ist so etwas keinen Blogartikel wert, aber da ich mich zu dem Problem hier bereits zwei Mal geäußert hatte, gehört es zur Korrektheit auch die weitere Entwicklung zu spiegeln.

Ausgehend von der Phoronix-Meldung hatte ich hier wie auch andere berichtet, dass eine Inkompatibilität mit Mesa das Problem wäre. Dem scheint nicht so gewesen zu sein. Grund war vielmehr ein Problem mit dem Rust-Compiler, was unter anderem in diesem Bug nachzulesen ist. Diesen Compiler braucht aber nur der Maintainer, der Anwender benötigt für die Nutzung von Firefox keinen Rust-Compiler.

Es geht dabei also um ein eher „akademisches“ Problem. Ohne die Verfügbarkeit unter Debian Stable würde man allerdings keine „Reproducible Builds“ erreichen. Ich bin grundsätzlich ein Befürworter von reproduzierbaren Builds, denn wie soll man sonst sicher sein, dass die Binärprogramme wirklich dem freien Quellcode entsprechen und nicht davon abweichen. Das Problem hat uns schließlich bei TrueCrypt viele Jahre begleitet, bevor es „gelöst“ werden konnte. Reproduzierbare Builds als eher theoretisches Problem so hoch zu gewichten, dass dadurch alle Stable-Nutzer wochenlang auf ein sicherheitskritisches Firefox-Update warten mussten, ist aber eine andere Hausnummer.

Meine ursprüngliche Bewertung, dass es sich hier um ein originäres Debian-Problem handelt, gilt daher immer noch. Denn Debian hat anscheinend wochenlang mit sich gerungen, ob es für ein Programm eine Ausnahme machen möchte oder eine extra Abhängigkeit nur für Firefox in die stabile Distribution einziehen will. Zumal das Problem ja auch nur entstand, weil man zum Release ein relativ altes Paket rustc auslieferte. Zur Erinnerung: Die in Stable enthaltene Variante war aus dem November 2020.

Außerdem löst das Update von Firefox nur ein Problem und befreit die Anwender nicht von den unsicheren anderen Programmen, wie z. B. Chromium. Die Probleme sind und bleiben eben doch größer als Firefox.

Der Artikel Debian und Firefox – Nicht Mesa sondern Rust als Problem erschien zuerst auf [Mer]Curius

GrapheneOS ist nach der Installation ein sehr rudimentäres Betriebssystem. Es gibt wirklich nur das Android-Basissystem und ein paar wenige Apps: Telefon, SMS, Kontakte, Dateien, Kamera, Galerie, Browser. Zum Glück steht mit F-Droid ein Store mit freier Software zur Verfügung.

Die Installation wurde im letzten Teil der Serie schon kurz angerissen:

Dazu in Einstellungen –> Apps –> Spezieller Zugriff –> Installieren unbekannter Apps für Vanadium erlauben. Dann mittels eben jenes Vanadium die Webseite von F-Droid aufrufen und den Store herunterladen und installieren.

Danach in jedem Fall die Berechtigung für Vanadium rückgängig machen und entsprechend für F-Droid erteilen.

F-Droid

F-Droid ist nicht der optisch hübscheste Store, aber funktional. Ähnlich wie bei Linux stehen hinter den dortigen Angeboten Maintainer und nicht die Entwickler der Software selbst. Es kann deshalb zwischen einer Versionsänderung upstream und dem Erscheinen im F-Droid Store einige Zeit vergehen.

Es gibt eine Startseite, auf der ausgewählte Apps präsentiert werden. Klickt man auf eine dieser Apps, erscheint die auch von anderen Systemen bekannte Übersicht mit einer Beschreibung, Screenshots, weiterführenden Informationen und ggf. einem Änderungsprotokoll sowie der Schaltfläche, um die App zu installieren.

F-Droid benachrichtigt über anstehende Updates. Die GrapheneOS-Einbindung von F-Droid mit Benutzerrechten macht eine automatische Installation leider unmöglich. Stattdessen erfolgt die übliche Systemabfrage, um jede App einzeln zu aktualisieren.

F-Droid Apps

Die rudimentäre GrapheneOS-Ausstattung macht es nötig, einige Apps zu installieren. Im Folgenden sollen einige Vorschläge gemacht werden. Es gibt aber sicherlich noch viele weitere hervorragende Apps und sicher auch tolle Alternativen zu den unten genannten.

Im Großen und Ganzen bin ich mit den Apps sehr zufrieden. Lediglich zu OsmAnd hätte ich gerne eine Alternative. Natürlich hat die App einen tollen Funktionsumfang und OSM ist eines der Vorzeigeprojekte der kollaborativ arbeitenden freien Gemeinschaft. Die GUI von OsmAnd ist nur wirklich unhandlich und die Suchfunktion treibt mich regelmäßig zur Verzweiflung. Nachtrag: Alternative dank Hinweis auf Organic Maps gefunden.

Ich kann inzwischen tatsächlich einen Großteil meines Bedarfs über Open Source Apps decken. Lediglich den DB Navigator, WhatsApp, Signal, Threema und das PhotoTAN meiner Bank beziehe ich nicht über F-Droid. Das ist inzwischen der Sockel, der sich vermutlich nicht mehr reduzieren lässt. Besonders ärgerlich finde ich das bei Signal.

Der Artikel GrapheneOS – Eine Sammlung von F-Droid Apps erschien zuerst auf [Mer]Curius

Wenn man einen Anwendungs-Dienst betreibt, welcher nur für ein bestimmtes Release von Red Hat Enterprise Linux wie bspw. RHEL 8.4 freigegeben ist, gilt es effektiv zu verhindern, dass bei Updates Pakete installiert werden, die zu einem folgenden Release wie z.B. RHEL 8.5 gehören. Andernfalls verliert man bestenfalls die Unterstützung vonseiten des Herstellers der Anwendung. Im schlimmsten Fall ist die Anwendung nicht mehr lauffähig und man muss das Upade zurückrollen.

Hinweis von Steffen Frömer (Senior Technical Account Manager bei Red Hat): Um Updates für ein spezifisches Minorrelease zu bekommen, auch wenn wie im Beispiel RHEL 8.5 bereits verfügbar ist, müssen Repositories mit verlängertem Support (z.B. Extended Update Support, EUS) verwendet werden. Andernfalls bekommt man keine Paketupdates.

Weiterführende Informationen zum Thema Extended Update Support bietet der Link unter [3].

Der folgende Code-Block zeigt, wie man Updates für ein RHEL-8-System auf das Release 8.4 beschränkt:

# subscription-manager release --set=8.4
# rm -rf /var/cache/dnf

Das Kommando in der letzten Zeile, geht auf den Wissensartikel [1] zurück, welcher darauf hinweist, dass nur so der Paket-Cache sicher geleert wird. Dies ist notwendig, da der Paketmanager andernfalls fälschlicherweise Paketversionen eines höheren Release aus dem lokalen Cache installieren könnte, was zu Abhängigkeitsproblemen führt.

Mit folgendem Befehl lässt sich die Beschränkung wieder entfernen:

# subscription-manager release --unset
   Release preference has been unset

Das war auch schon alles.

Quellen und weiterführende Links

1. How to tie a system to a specific update of Red Hat Enterprise Linux? — https://access.redhat.com/solutions/238533 (Login erforderlich)
2. How to limit updates a [sic] specific version of Red Hat Enterprise Linux? — https://access.redhat.com/solutions/2761031 (Login erforderlich)
3. Red Hat Enterprise Linux (RHEL) Extended Update Support (EUS) Overview — https://access.redhat.com/articles/rhel-eus (Login erforderlich)