Vor ein paar Tagen hatte ich euch um Hilfe bei meiner Suche nach einem Nachfolger für Synology Note Station gebeten. Viele von euch haben geantwortet. Letztlich habe ich mich jetzt für Joplin entschieden.
Interessant für mich war, dass meine Unzufriedenheit über die Rechercheergebnisse in dem Bereich von einigen geteilt wurde. Ich hatte bis dahin gar nicht auf dem Schirm, dass Linux im Bereich der Notizen noch Luft nach oben hätte.
Ohne die Kommentare von euch jetzt statistisch ausgewertet zu haben, würde ich festhalten, dass die meisten von euch entweder auf Nextcloud Notes oder Joplin setzen. Zusätzlich gab es natürlich noch ganz viele andere Lösungen. Viele davon sind interessant und ich habe mir einiges genauer angesehen. Sehr geholfen hat mir auch dieses YouTube-Video, in dem einige der Möglichkeiten aus den Kommentaren detaillierter vorgestellt wurden.
Die Wahl fiel dann im Ausschlussverfahren. Ich habe gegenwärtig keine Nextcloud im Einsatz, weil mir die integrierten Funktionen meines Synology DSM reichen und ich mich in der Vergangenheit häufiger über hakelige Updates bei Nextcloud geärgert hatte. Dadurch fiel diese Option weg.
Aus diesem Grund gebe ich nun Joplin eine Chance. Liebe auf den ersten Blick ist es nicht. Die Apps sind keine nativen Programmen und sowohl auf dem Desktop als auch auf meinem Android eher behäbig und integrieren sich nur leidlich in die jeweiligen Systeme. Aber funktional bietet Joplin alles was ich benötige und ich kann es via WebDAV über mein Synology NAS synchronisieren.
Überzeugt haben mich dann vor allem die umfassenden Exportmöglichkeiten, wodurch kein Lock-in Effekt entsteht. Denn sollte es Bewegung in dem Bereich geben und neue Alternativen auf den Markt kommen, könnte ich mir sehr gut vorstellen, Joplin wieder den Rücken zu kehren.
Linux ist ein sicheres System, aber es gibt immer Optimierungsbedarf. Das starre Festhalten an überkommenen Prinzipien und ein geringer Veränderungsdruck – sowohl von innen als auch von außen – haben fragwürdige Praktiken einschleifen lassen. Transparenz wäre hier wichtig.
Anlässlich einiger Probleme mit Debian ist hier zuletzt einiges zum Thema Linux und Sicherheit erschienen. Dabei ging es primär um Debian, aber man kann das Problem mit Sicherheit auf andere stabile Distributionen, vor allem solche mit LTS-Modell übertragen. Im Folgenden möchte ich einige der Aussagen aus der Serie Debian und Sicherheit ein wenig einordnen.
Die Art wie Linux-Distributionen allgemein konzipiert sind und die Art wie LTS- bzw. Enterprise-Distributionen funktionieren, ist alt. Das grundlegende Konzept hat ungefähr 15-20 Jahre auf dem Buckel. Währenddessen hat sich bei der Softwareentwicklung viel getan und das lässt sich vor allem mit einem Wort zusammenfassen: Beschleunigung. Das stellt die Distributoren vor extreme Herausforderungen.
Meiner Meinung nach ist es völlig in Ordnung, wenn Distributionen dann einschränken müssen, wofür sie, wie lange Support anbieten können. Manche Projekte lassen sich nicht mit der verfügbaren Arbeitskraft oder schlicht einfach gar nicht angemessen im LTS-Support unterstützen. Die Serie ist keineswegs als Angriff auf diesen Umstand zu verstehen.
Aber wenn es eine Einschränkung gibt, dann muss diese für den Anwender transparent sein! Transparenz kann man auf unterschiedliche Art herstellen:
Radikale Transparenz bietet z. B. Red Hat, indem man alle anderen Programme und zuletzt sogar das komplette KDE aus der Unterstützung ausgeschlossen hat und diese Programme schlicht nicht ausliefert. Anwender, die das nutzen wollen, müssen die EPEL-Quellen einbinden, wodurch der geringere Supportstatus automatisch deutlich wird.
Einen Zwischenschritt macht Canonical mit der Trennung in main und universe. Bei der Serverinstallation aktiviert Ubuntu automatisch nur main und fährt deshalb für diesen Bereich eine ähnliche Strategie wie Red Hat. Aber auch sonst ist die Trennung deutlich und den Anwendern klar. Schon alleine, weil alle Supporter in den Supportforen ständig auf den Umstand hinweisen.
SUSE hat für die Enterprise-Version SUSE Linux Enterprise das Vorgehen von Red Hat übernommen. Die Community-Variant openSUSE hat seine LTS-Version faktisch mit SLE fusioniert. In den Paketquellen ist für Anwender ersichtlich, ob Updates von SUSE oder openSUSE stammen. Hier wäre aber in der Transparenz noch Luft nach oben.
Die Art, wie Debian hier die Probleme in den Release Notes versteckt und in den offiziell angebotenen Tools klein rechnet, ist keine Transparenz. Hier kommen sicher wieder welche mit dem Argument der Freiwilligkeit und dass Debian keine kommerzielle Distribution ist. Das halte ich für vorgeschoben. Ein Projekt das es schafft endlose systemd-Debatten zu führen und aufwendige alternative Systeme zu etablieren, das fein austarierte unterschiedliche Paketquellen für main, contrib und non-free anbietet, das könnte auch hier für mehr technische Transparenz sorgen.
Offene Kommunikation bei Problemen und Schwierigkeiten ist keineswegs eine Forderung, die ich jetzt nur in Bezug auf Debian erhebe. Im Frühjahr war ich bei meiner Lieblingsdistribution openSUSE nicht weniger zurückhaltend als man Schwierigkeiten bei Updates in Leap 15.3 einfach tot schwieg.
Open Source hat sich transparente Entwicklung und transparenten Umgang mit Problemen immer auf die Fahnen geschrieben. Man wollte weg vom Konzept der Security through obscurity. Genau deshalb gibt es offene Bugtracker und offene Listen der kritischen Fehler. Mit der Verschleierung von Problemen in der Distribution kehrt man faktisch zu diesem Konzept zurück und ist im Umgang mit Fehlern dann auch nicht besser als Apple oder Microsoft.
Das Eingeständnis mit einem Distributionskonzept an Grenzen gestoßen zu sein, ist der erste Schritt zur Erarbeitung von Lösungen. Verweigert man dieses Eingeständnis und redet man sich weiter ein, keine Probleme zu haben, ist das wenig seriös. Zumal weil viele dann auch noch glauben, es gäbe keine Probleme.
Debian empfiehlt in seinen Release Notes das Paket debian-security-support um den Supportstatus der Installation zu prüfen. Das Paket liefert allerdings unvollständige Informationen.
Für meinen Test nahm ich ein aktuelles Debian 11 „Bullseye“. Die Softwareauswahl entspricht in etwa dem, was ich im zweiten Teil zu meinem persönlichen Linux-Setup geschrieben hatte. Eine relativ KDE-lastige Softwareauswahl, aber sie entspricht dem, womit ich persönlich arbeite.
Das Paket debian-security-support war nicht vorinstalliert, was ich schon als Manko empfinde. Bei der Installation wird aber gleich angezeigt, was betroffen ist. Alternativ kann man mit folgendem Befehl jederzeit den Supportstatus anzeigen:
$ check-support-status
Folgende Ausgabe erhalte ich für das oben beschrieben System.
Eingeschränkte Versorgung mit Sicherheitsaktualisierungen für eines oder mehrere Pakete
Leider war es nötig, die Versorgung mit Sicherheitsaktualisierungen
für einige Pakete einzuschränken.
Davon sind die folgenden auf diesem System gefundenen Pakete betroffen:
* Quelle:binutils
Einzelheiten: Only suitable for trusted content; see https://lists.debian.org/msgid-search/87lfqsomtg.fsf@mid.deneb.enyo.de
Betroffene Binärpakete:
- binutils (installierte Version: 2.35.2-2)
- binutils-common:amd64 (installierte Version: 2.35.2-2)
- binutils-x86-64-linux-gnu (installierte Version: 2.35.2-2)
- libbinutils:amd64 (installierte Version: 2.35.2-2)
- libctf-nobfd0:amd64 (installierte Version: 2.35.2-2)
- libctf0:amd64 (installierte Version: 2.35.2-2)
* Quelle:qtwebengine-opensource-src
Einzelheiten: No security support upstream and backports not feasible, only for use on trusted content
Betroffene Binärpakete:
- libqt5webengine-data (installierte Version: 5.15.2+dfsg-3)
- libqt5webengine5:amd64 (installierte Version: 5.15.2+dfsg-3)
- libqt5webenginecore5:amd64 (installierte Version: 5.15.2+dfsg-3)
- libqt5webenginewidgets5:amd64 (installierte Version: 5.15.2+dfsg-3)
- qml-module-qtwebengine:amd64 (installierte Version: 5.15.2+dfsg-3)
Diese kurze Liste erscheint wohlgemerkt auf einem System, auf dem Chromium installiert ist, in einer Version mit scheunentorartigen Sicherheitslücken. Die Qt-Webengine ist zwar gelistet, aber die darauf aufbauenden Programme wie KMail oder RSS Guard werden nicht genannt. Sehr überrascht bin ich auch, dass Debian glaubt für die ganzen installierten Multimedia-Codecs Support anbieten zu können. Der Zustand der Codec-Sammlung ist schließlich bekanntermaßen schlecht.
Das sind zudem nur die offenkundigen Probleme. Nach den Ereignissen der letzten Monate hege ich erhebliche Zweifel, dass man bei Debian in der Lage wäre, z. B. bei kritischen Problemen in KMail/Akonadi für die bereits bei Freeze vollständig veralteten Versionen ohne massive Hilfe von KDE Sicherheitsaktualisierungen zurück zu portieren. Ich vermute daher, dass man bei Tausenden Paketen auf das Prinzip Hoffnung setzt. Hoffnung darauf, dass im Supportzeitraum schon keine kritischen Fehler bekannt werden.
Debian beharrt auf einem rigiden Stable-Prinzip und hält Versionen exakt auf dem Stand, auf dem sie beim Release waren. Allerdings mit dem Versprechen, sicherheitskritische Probleme durch separate Patches zu beheben. Die Dokumentation der Probleme ist zumindest fragwürdig.
Die Sicherheitsprobleme mit Firefox und X.org bei Debian haben – obwohl inzwischen behoben – mein Interesse geweckt. Das mag sich für manche jetzt alles unfair lesen und vermutlich haben auch andere Distributionen erhebliche Probleme. Ubuntu entledigt sich seiner Sorgen ja einfach mit der Deklaration von universe als nicht supportet. Damit steht der Anwender zwar faktisch auch vor Sicherheitsproblemen, aber formell ist Ubuntu bzw. Canonical auf der sicheren Seite.
Einige Aspekte haben mein Interesse geweckt. Wie immer gehe ich von meinem persönlichen Nutzungsverhalten aus. Das bedeutet der Einsatz von Linux auf dem Desktop mit den für mich wichtigen Programmen. Ein großes Problem möchte ich am Beispiel der Rendering Engines schildern.
In den Release Notes schreibt Debian:
Debian 11 includes several browser engines which are affected by a steady stream of security vulnerabilities. The high rate of vulnerabilities and partial lack of upstream support in the form of long term branches make it very difficult to support these browsers and engines with backported security fixes. Additionally, library interdependencies make it extremely difficult to update to newer upstream releases. Therefore, browsers built upon e.g. the webkit and khtml engines are included in bullseye, but not covered by security support. These browsers should not be used against untrusted websites. The webkit2gtk and wpewebkit engines are covered by security support.
For general web browser use we recommend Firefox or Chromium. They will be kept up-to-date by rebuilding the current ESR releases for stable. The same strategy will be applied for Thunderbird.
Das hört sich erst mal nicht so schlimm an. Man nutzt halt keine Browser außer Firefox und Chromium. Wobei Letzteren sollte man angesichts der völlig veralteten Version auch nicht mehr nutzen. Hier sind dann sogar die Release Notes veraltet.
Besonders erstaunlich ist der Verweis auf mangelnden Upstream-Support. Immerhin kümmert sich KDE intensiv um Qt 5.15 und stellt LTS-Support bereit. Warum man diese Updates nicht einfach weiterreichen kann, erschließt sich mir nicht.
Das Problem ist, dass die Rendering Engines noch andere Funktionen haben. Nutze man z. B. das KDE-Mailprogramm KMail bezieht man über die Abhängigkeiten die Pakete libkf5webengineviewer5abi1 und libqt5webenginecore5. Diese benötigt KMail um HTML-Mails korrekt darstellen zu können. Das Problem betrifft auch andere Programme, wie z. B. die Feedreader Akregator oder RSSGuard. Vermutlich ist hier noch mehr betroffen, aber diese beiden Kandidaten kamen mir spontan in den Sinn. Ein Angriff über eine E-Mail ist nun wirklich kein abwegiges Szenario.
Das letzte Update des Pakets libqt5webengine5 gab es im Dezember 2020. Die genutzte Version ist 5.15.2, also nochmal deutlich älter. In Testing liegt eine neuere Version und das Changelog liest sich gar nicht so spektakulär. Das hat mich stutzig gemacht und deshalb habe ich mal bei openSUSE nachgeschaut. Dieses Changelog beschreibt die Änderungen im openSUSE-Paket der Qt5-Webengine. Die Liste der CVEs ist ordentlich.
Gibt man ein paar der CVE-Nummern in den Debian Security Tracker ein, ist immer nur Chromium als betroffenes Paket gelistet. Nur ein Beispiel: CVE-2021-37979. Bei älteren Fehlern ist das Problem angeblich sogar in Debian Stable behoben, was gar nicht sein kann, weil es keine Aktualisierung für die Qt5-Webengine gab. Beispiel: CVE-2021-21128
Es gibt also nur zwei Möglichkeiten. Die openSUSE-Changelogs listen zu viele Probleme oder Debian führt seine Liste der Sicherheitsprobleme nicht vollständig.
Wie dem auch sei: Im Grunde genommen dürfte man kein Programm nutzen, dass auf die Qt Webrendering-Engine zurückgreift bzw. müsste die entsprechende Funktion deaktivieren. Das Problem wird weder in den Release Notes, noch auf irgendwelchen anderen Seiten dargestellt.
Ob das bei den laut Release Notes unterstützten webkit2gtk-Paketen besser ist, habe ich nicht geprüft.
Ich würde mich freuen, wenn jemand das entkräften würde.
Chromium ist freie Software, aber nicht frei von Google, das den Browser maßgeblich entwickelt, selbst in Form des proprietären Chrome ausliefert und damit den weltweiten Browsermarkt dominiert. Nur kommt man manchmal nicht an dem Browser vorbei. Welche Addons dann sinnvoll sind.
Grundsätzlich halte ich es hinsichtlich Datenschutz und Sicherheit für geboten, wann immer es geht, Firefox den Vorzug zu geben. Zweifelsohne hat Mozilla in den letzten Jahren so manchen Bock geschossen, aber sie haben auch versucht, den Anwender vor übergriffigen Trackinganbietern zu schützen. Neben Mozilla unternimmt da nur noch Apple ernsthafte Anstrengungen. Es ist einhellige Meinung unter allen mir bekannten Sicherheitsexperten, dass kein Browser sich so gut mit entsprechenden Einstellungen und Addons absichern lässt, wie dies bei Firefox der Fall ist.
Daneben sollte die zunehmende Monopolstellung von Google im Browserbereich uns alle sorgen. Microsoft Edge, Brave, Vivaldi – selbst wie „Erfinder“ von WebKit (nämlich KDE mit KHTML) nutzen nun quasi Chromium als Basis in Form der Qt Webengine. Diese Marktmacht gibt Google die Möglichkeit, seine Position im finanziell wichtigen Werbemarkt durch Neuerungen zu zementieren. Den ersten Anlauf hierzu haben wir im vergangenen Jahr gesehen.
Leider kann man nicht immer Firefox nutzen. Denn Chromium bzw. Chrome ist kein schlechter Browser und vor allem bei modernen Webanwendungen wie Videokonferenzen Firefox überlegen. Viele benutzen Chromium deshalb mindestens als Zweitbrowser, was natürlich die Gefahr beinhaltet, dass aus dem Zweitbrowser schleichend der Erstbrowser wird.
Chromium ist eng mit Google verbandelt, aber auch hier kann man einige Maßnahmen ergreifen um seine digitale Privatsphäre ein wenig zu schützen.
Einstellungen
Google und Ich: Synchronisierung und Google-Dienste abschalten
Datenschutz und Sicherheit: Cookies und andere Webseitendaten –> Drittanbieter-Cookies blockieren
Datenschutz und SIcherheit: Safe-Browsing deaktivieren (Hört sich absurd an, aber der Mehrwert ist gering, der Datenabfluss an Google groß)
Datenschutz und Sicherheit: Privacy-Sandbox –> Alle Funktionen wie FloC abschalten.
Suchmaschine: Ändern auf eine Datenschutz-freundliche Suchmaschine. Ich persönlich bevorzuge DuckDuckGo.
Addons
Das Addon-Ökosystem von Firefox und Chrome/Chromium ist ziemlich ähnlich. Um den Google Web Store für die Installation kommt man leider nicht herum.
ublock origin: Inhalteblocker, um Tracker und Werbung zu blockieren. Mit optionalen Zusatzlisten, um bei Bedarf noch umfangreicher Inhalte zu filtern.
LocalCDN: Ein Fork bzw. Weiterentwicklung des bekannten Decentraleyes. Liefert viele Frameworks und Bibliotheken, die in Webseiten eingebunden werden lokal aus und verhindert damit Verbindungen und Tracking.
Cookie AutoDelete: Der Trend geht weg von Cookies, aber noch sind sie eines der wichtigsten Mittel zum Tracking. Anders als bei Firefox besitzt Chromium keine Container. Man sollte deshalb Cookies möglichst automatisiert entfernen lassen und lediglich per Whitelist einzelne Seiten für eine dauerhafte Speicherung zulassen.
Chromium ist kein empfehlenswerter Browser, wenn man Wert auf Datenschutz und Privatsphäre im digitalen Raum legt. Projekte wie Ungoogled Chromium oder Irdium sind interessant, aber oft schnelllebig und hinken bei den Updates gerne hinterher, was wiederum schlecht für die Sicherheit ist. Mit den Einstellungen und Addons verbessert man seine Sicherheit ein wenig, gut wird Chromium dadurch aber nicht.
Gegenwärtig arbeite ich noch mit der Note Station von Synology. Synology entwickelt diese aber seit Längerem nicht aktiv weiter, daher möchte diese gerne ablösen durch eine aktiv entwickelte und besser funktionierende Lösung.
Das Problem bei der Synology Note Station sind vor allem die schlechten Applikationen. Die mobile App für Android ist noch halbwegs funktional, aber die Linux-App ist nur eine automatisch konvertierte Windows-Applikation, steht nur als DEB zur Verfügung und hat leider viele Bugs. Synology scheint die Note Station nicht aktiv weiter zu entwickeln. Die wenig konstante Entwicklung der Applikationen ist meiner Meinung nach auch über die Note Station hinaus ein neuralgischer Punkt von Synology.
Was mir vorschwebt:
Open Source
Native Anwendungen für Linux und Android (gerne auch iOS)
Funktionsumfang jenseits von Plaintext, notfalls mit Markdown-Syntax
Synchronisation über WebDAV-Schnittstelle oder synchronisierten Cloud-Ordner.
Ich bin etwas konsterniert über das geringe Angebot und kann kaum glauben, dass das alles ist, was es dazu gibt. Bisher ist eigentlich nur Joplin in der engeren Auswahl. Das erfüllt zwar alle Kriterien, aber die Electron-Umsetzung ist schon ein Manko. Zudem ist Joplin nicht in F-Droid und nicht in den Paketquellen der meisten Distributionen. Auf Flathub ist nur ein Flatpak eines Drittanbieters. Sollte es nichts Besseres geben, würde ich wohl auf Joplin umsteigen.
Mich würde aber interessieren was die Leser dieses Blogs so im Einsatz haben?
Backups sind unabdingbar. Gab es von Daten kein Backup, waren diese Daten nicht wichtig. Bei der Verwendung durchgängig verschlüsselter Systeme sind Backups umso bedeutender, da beispielsweise defekte Geräte nicht einfach ausgelesen werden können. Besonderer Beliebtheit erfreut sich seit einiger Zeit Borg.
Ich experimentierte unter Linux seit vielen Jahren mit verschiedenen Backup-Lösungen. Bei macOS bin ich hingegen total glücklich mit Time Machine. Zuletzt hatte ich hier Déjà Dup vorgestellt, mit dem ich mein Pantheon-System sichere. Ich bin bekanntermaßen ein großer Freund grafischer Oberflächen. Nicht weil ich die Konsole nicht mag oder nicht mit ihr umgehen könnte, sondern weil ich viele Aufgaben einfach lieber mit einer grafischen Oberfläche erledige. Meiner Meinung nach ist die Konsole nur deshalb im Linux-Umfeld so beliebt, weil die grafischen Oberflächen oft so furchtbar gestaltet und/oder fehleranfällig sind. In den Kommentaren zu Déjà Dup wies man mich auf Vorta hin, das eine grafische Oberfläche für Borg ist.
Gefühlt hört man aus Admin-Kreisen permanent Borg, borg, borg, borgmatic, borg, borgbase, borg, wenn es um Backups geht. Umso mehr ein Grund, sich das mal anzusehen.
Borg ist eine schnelle, inkrementiell sichernde Backuplösung. Die Datensicherungen werden in einem Repositorium gespeichert, das entweder lokal vorliegen, auf einem externen Speichermedium oder einem Server bzw. NAS abgelegt werden kann. Anders als bei Lösungen wie Duplicity benötigt Borg ein Clientprogramm auf dem zu sichernden System und einen Serverpart auf dem System, welches das Repositorium bereitstellt. Die Backups sind verschlüsselte und bei entfernten Repositorien erfolgt die Übertragung via SSH.
Beides kann man mit Linux und einem Synology NAS einrichten, was aber nicht ganz trivial ist und mich einiges an Recherche gekostet hat. Die Vorgehensweise soll hier deshalb dargestellt werden.
Vorbereitung des Synology NAS
SynoCommunity Paketquelle hinzufügen und Borg installieren
Synology bietet nicht direkt ein Paket für Borg an. Deshalb muss man auf Pakete der Community zurückgreifen. Die SynoCommunity stellt glücklicherweise viele Pakete für Synology NAS bereit und dazu zählt auch Borg.
Die Paketquelle lässt sich leicht über die Administrationsoberfläche des Synology DSM hinzufügen. Dazu das Paket-Zentrum öffnen und rechts oben in den Einstellungen unter Paketquellen die SynoCommunity Paketquelle hinzufügen.
Anschließend erscheint bei der Paketauswahl ein neuer Bereich Community. Hier lässt sich das Paket Borg auswählen und installieren. Bei der Installation erfolgt zur Sicherheit eine Abfrage, ob man wirklich Pakete von Dritten installieren möchte.
Benutzer und Freigabe anlegen
Ich verwende auf meinem NAS unterschiedliche Benutzer für unterschiedliche Aufgaben, um gezielt Rechte vergeben zu können. Diese Schritte zeige ich hier auch für Borg. Wer nur mit einem Nutzer arbeitet, kann diese Schritte überspringen und muss ggf. die Anleitung ein wenig anpassen.
In der Synology Systemsteuerung ist zuerst die Gruppe borg-backup und ein Benutzer borg-backup anzulegen. Der Gruppe können die Zugriffsrechte auf alle Freigaben verweigert werden, ausgenommen natürlich homes. Der Benutzer ist der Gruppe borg-backup hinzuzufügen und zusätzlich der Gruppe administrators. Das ist natürlich total unsinnig, aber Synology erlaubt nur für Mitglieder der Gruppe administrators den SSH-Zugriff und diesen benötigt man für das Borg-Backup.
Hat man beides angelegt, kann man einen neuen freigegebenen Ordner namens borgbackup anlegen. Die Zugriffsrechte sind hier entsprechend für die eben angelegte Gruppe zu setzen. Bei Bedarf kann ein Quota vergeben werden, dass natürlich nicht zu knapp bemessen sein sollte.
SSH Schlüssel hinzufügen
Nun kommt der weniger triviale Teil. Borg benötigt einen SSH-Zugriff mittels SSH-Key und das sieht Synology so eigentlich nicht vor. Zum Glück ist der DiskStation Manager von Synology letztlich nur eine Linux-Distribution und deshalb kann man natürlich manuell einen SSH-Key hinzufügen.
Sollte man noch keinen SSH-Key besitzen, kann man einen anlegen (nicht auf dem Synology NAS, sondern dem Rechner!)
ssh-keygen -t ed25519 -C "mail"@domain.td"
Zuerst meldet man sich mit seinem normalen Administratoraccount via SSH an. Ggf. ist vorher in der Systemsteuerung unter Terminal & SNMP der SSH-Dienst zu aktivieren. Hier kann bei Bedarf auch eine abweichende Port-Nummer festgelegt werden.
Anschließend befindet man sich auf Shell des Synology DSM. Hier holt man sich zuerst Administratorrechte.
$ sudo -i
Nach der nochmaligen Passworteingabe ändert sich der Shell-Prompt zu: root@<hostname>:~#
Nun nimmt man die notwendigen Änderungen für den SSH-Zugriff vor. Hierbei legt man Verzeichnisse im Home-Verzeichnis des Benutzers borg-backup an und ändert die Rechte.
Anschließend kopiert man den Publickey des SSH in die Datei ~/.ssh/authorized_keys auf dem Synology NAS. Dazu gibt es eigentlich ein SSH-Tool, aber das hat bei mir bei der Synology NAS nicht funktioniert. Deshalb einfach den Inhalt der Datei ~/.ssh/id_ed25519.pub kopieren und mittels des SSH-Zugangs in die entsprechende Datei im Synology DSM schreiben.
Nun meldet man den Root- bzw. Adminaccount von SSH ab und testet ob man den neuen Account mittels Keyfile via SSH anmelden kann.
Klappt der Zugriff ist das Synology NAS bereit für das Borg-Backup.
Vorta
Sicherung konfigurieren
Auf dem zu sichernden System verwende ich Vorta als grafische Oberfläche für Borg. Dabei handelt es sich um ein Qt-Programm. Vorta befindet sich bei vielen Distributionen in den Paketquellen und zieht bei der Installation das notwendige Paket borgbackup nach sich.
Vorta arbeitet mit Profilen. Dadurch lassen sich verschiedene Sicherungen einrichten. Das kennt man vielleicht von LuckyBackup oder Back In Time.
Als erstes wählt man ein Sicherungsziel bzw. legt hier mittels „Neues Repository initialisieren“ ein neues Sicherungsziel an. Die Repository-URL folgt einem Schema, das bereits grau hinterlegt angezeigt wird. Bei einer Sicherung auf ein Synology NAS sieht die URL in etwa wie folgt aus:
Das vergebene Passwort dient der Verschlüsselung des Backups.
Unter Erweitert muss man bei Extra-Optionen ggf. noch den Remote-Path, also den Pfad zu Borg auf der Synology DiskStation, hinterlegen.
--remote-path=/usr/local/bin/borg
Bei den Quellen wählt man die zu sichernden Verzeichnisse. Bei mir ist dies das komplette Home-Verzeichnis. Zusätzlich kann man einen Zeitplan konfigurieren. Das halte ich grundsätzlich für sinnvoll, weil Faulheit und Vergesslichkeit die beiden größten Feinde eines jeden Backupkonzepts sind. Wenn man das Gerät natürlich nur sehr selten startet oder es sich regelmäßig nicht im selben Netzwerk wie das Synology NAS befindet, kann man darauf natürlich verzichten.
Abschließend kann man über die Schaltfläche Datensicherung starten die erste Sicherung erstellen. Das geht verglichen mit anderen Lösungen wie Déjà Dup oder Back In Time erfreulich flott.
Backup wiederherstellen
Sicherungen werden als inkrementelle Schnappschüsse gespeichert und lassen sich im Reiter Archive ansehen. Die erste Sicherung ist logischerweise sehr groß, die Schnappschüsse danach enthalten je nach Änderungen nur einige hundert MB.
Zur Wiederherstellung bieten sich zwei Optionen an. Über den Button Ausgewähltes Archiv kann über das Menü Extract die Sicherung extrahiert oder über Mount an einen beliebigen Ort eingebunden werden. Vor allem die Mount-Option ist für mich interessant, da ich glücklicherweise eher selten ein komplettes Backup wiederherstellen möchte, sondern meist nur einzelne Dateien aus einem bestimmten Stand ansehen will. Hierfür musste auf meinem System noch das Paket python38-llfuse nachinstalliert werden.
Zusammengefasst
Die Installation und Konfiguration ist etwas mühsam und nicht ganz trivial. Bei meiner Recherche bin ich oft auf Leute gestoßen, die an irgendwas gescheitert sind oder sich einfacheren Lösungen zugewandt haben. Hat man das aber erfolgreich hinter sich gebracht, belohnt einen Borg bzw. Volta mit geräuschloser Arbeit im Hintergrund. Die Sicherung ist schnell, robust und das Durchsuchen der Backups mittels Mount-Option klappt zuverlässig. Ich bin sehr zufrieden damit und werden vermutlich bei Gelegenheit auch mein Pantheon-System von Déjà Dup auf Vorta/Borg umstellen.
Bei meinen externen Speichermedien bleibe ich hingegen konservativ bei rsync. Es mag paranoid erscheinen, aber ich möchte nicht alle meine Datensicherungen in Repositorien, deren Inhalt ich nur mit Softwaretools durchsuchen kann.
Firefox Monitor ist ein Dienst von Mozilla, welcher Nutzer überprüfen lässt, ob deren Benutzerkonten im Web in der Vergangenheit Teil eines bekannten Datendiebstahls waren. In Zukunft sollen Nutzer im Rahmen von Firefox Monitor auch persönliche Daten von Websites entfernen lassen können. Interessierte Nutzer können sich auf eine Warteliste setzen lassen.
Das ist Firefox Monitor (bis jetzt)
Mozillas kostenfreier Dienst Firefox 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 Firefox Monitor allgemeine Tipps, welche man in Betracht ziehen sollte, wenn man von einem Datendiebstahl betroffen ist.
Entfernungs-Dienst für persönliche Daten von Mozilla
Aktuell bewirbt Mozilla für angemeldete Nutzer auf der Startseite von Firefox Monitor eine Warteliste für ein kommendes Feature. Damit soll es möglich sein, Mozilla die persönlichen Daten eines Nutzers wie die E-Mail-Adresse, aber auch die physische Adresse oder Telefonnummer von Websites entfernen zu lassen.
Informationen zur Verfügbarkeit und zum Preis
Dass Mozilla an einem solchen Feature arbeitet, habe ich bereits im August des letzten Jahres im Kontext eines Angebotes enthüllt, an dem Mozilla arbeitet und welches sich Mozilla Privacy Pack nennt. Dieses ist zwar noch nicht verfügbar, jedoch hat Mozilla im November 2021 mit Firefox Relay Premium bereits einen Teil daraus als Einzelangebot zur Verfügung gestellt. Diese Erweiterung von Firefox Monitor wäre ein weiterer Teil daraus, ebenso wie das bereits existierende Mozilla VPN. Es ist gut vorstellbar, dass Mozilla zu einem späteren Zeitpunkt alle kostenpflichtige Datenschutz-Produkte als Gesamtpaket, wahrscheinlich dann mit einem Preisnachlass, anbieten wird, die man ansonsten auch einzeln erwerben kann.
Aktuell ist der neue Entfernungs-Dienst als Teil von Firefox Monitor jedenfalls noch nicht verfügbar und auch ein Preis ist noch nicht bekannt. Wer sich auf die Warteliste setzen lässt, wird als erstes erfahren, sobald das Angebot verfügbar ist.
Meinen persönlichen Linux-Desktop habe ich hier bereits in einem ersten Artikel beschrieben. Das ist auf Interesse gestoßen und darum folgt nun der 2. Teil mit meinem alternativen KDE-Setup.
Ich bin kein Anwender, der sich vollständig auf ein System einschießt, sondern bewege mich schon immer zwischen den Welten. Linux, macOS – beruflich auch Windows. Mobil gegenwärtig iOS und Android, früher auch BlackBerry OS und Windows Mobile.
Bei Linux gibt es natürlich nicht das eine System und so fahre ich auch hier mehrgleisig. Hauptsächlich arbeite ich mit dem im ersten Teil beschriebenen Setup aus openSUSE Tumbleweed und Pantheon Shell. Auf einem zweiten Gerät nutze ich zudem noch KDE Plasma. Faktisch als Überbleibsel aus meiner KDE-zentrierten Arbeitsweise, aber nun schon alleine, um weiterhin über die Entwicklung dort meckern zu können MATE verwende ich gerne in virtuellen Maschinen, wo mir KDE Plasma oder Pantheon zu ressourcenintensiv sind. Von den größeren Desktopumgebungen sind somit lediglich Xfce und die GNOME Shell bei mir nicht im Einsatz.
Die Basis des KDE Plasma-Setups ist genau wie bei dem anderen System mit Pantheon Shell ein openSUSE Tumbleweed (wegen der noch inkompatibleren Hardware zu einer LTS). Hier habe ich aber mit den Nachteilen von RR-System zu kämpfen. Ich starte das Gerät vergleichsweise selten und dann sind da oft gleich 1-2 GB an Updates zu erledigen. Bei passender Gelegenheit werde ich das System daher auf eine LTS umstellen. Abhängig davon, was openSUSE Leap 15.4 für einen Kernel mitbringt.
Das Layout habe ich meinen Vorlieben (teilweise von Pantheon, teilweise noch aus meiner macOS-Zeit) angepasst. Plasma ist hier bekanntermaßen extrem flexibel.
Grundsätzliche habe ich mir angewöhnt, mit den jeweiligen Programmen des Systems bzw. der Desktopoberfläche zu arbeiten. Egal ob unter macOS, Windows, Pantheon, MATE oder KDE Plasma. Natürlich haben die Programme unterschiedliche Stärken und Schwächen, aber meiner Erfahrung nach, ziehen nicht zueinander passende Programme so viele Probleme nach sich, dass es alle Vorteile, die ein spezifisches Programm haben mag, konterkariert. Stattdessen setze ich auf Dienste mit offenen Standards, die ich überall einbinden kann und auf keine Insellösungen – sei es proprietäre oder freie Software. Entsprechend unterscheidet sich die Programmauswahl stark von der im ersten Artikel, aber die Daten sind die gleichen und ich kann geräteübergreifend gut arbeiten.
Dolphin, KCalc, KFind, KDE Connect, Spectacle, AnyDesk; usw. usf.
Dank Synology mit dem Cloud-Dienst Drive und der flexiblen Synchronisation beliebiger Ordner über das System sowie der PIM-Synchronisation via CalDAV und CardDAV ist eine systemübergreifende Arbeit kein Problem. Das gilt ebenso für den Nachrichtenkonsum über FreshRSS-Clients, wo hier RSS Guard zum Einsatz kommt. Ein etwas unhandliches Programm, das aber seinen Job erledigt.
Ob ich das KDE-Setup noch langfristig pflege oder es perspektivisch doch noch abwickele hängt davon ab, wie sich KDE und elementary weiter entwickeln. KDE steht vor dem Umstieg auf Qt 6 mit Plasma 6 und ich fürchte, sie nutzen das, um noch mehr Anwendungen durch Neuentwicklungen auf Kirigami-Basis zu ersetzen. Bei elementary muss man hingegen abwarten, wie sich Version 7 auf Basis von Ubuntu 22.04 gestaltet.
Mozilla hat Version 2.6 seiner VPN-Clients für das Mozilla VPN veröffentlicht. Dieser Artikel beschreibt die Neuerungen vom Mozilla VPN 2.6.
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.
Standardmäßig leitet das Mozilla VPN den Datenverkehr über einen Server an einem Standort. Mit dem Multi-Hop-Feature kann der Verkehr seit dem Mozilla VPN 2.5 von einem Standort über einen anderen Standort geleitet werden, quasi ein VPN nach dem VPN. Dieses Feature stand bislang nur unter Windows, MacOS und Linux zur Verfügung. Mit dem Mozilla VPN 2.6 bekommen auch Android und iOS die Möglichkeit zum Multi-Hop.
Zusammenarbeit mit Firefox Multi-Account Containers
Bei Firefox Multi-Account Containers handelt es sich um eine kostenfreie Mozilla-Erweiterung zur Verwaltung und Verwendung sogenannter Tab-Umgebungen in Firefox. Ein möglicher Anwendungsfall von Tab-Umgebungen ist beispielsweise das Anmelden mit sowohl einer privaten als auch mit einer geschäftlichen E-Mail-Adresse beim selben Anbieter – gleichzeitig, ohne einen anderen Browser hinzuziehen zu müssen oder ein privates Fenster dazu zweckzuentfremden. Als weiteres Beispiel wäre denkbar, auf Facebook angemeldet zu sein, ohne dass Facebook den Benutzer über die Facebook-Buttons auf Webseiten tracken kann. Wenn es um Tracking geht, ist es natürlich auch bis zur Werbung nicht so weit und so ist ein weiteres denkbares Szenario, dass man Webseiten privat besuchen möchte, ohne entsprechende Werbeanzeigen zu sehen, wenn man Firefox für die Arbeit benutzt. Mozillas Erweiterung ermöglicht es auch, bestimmte Webseiten immer in einem bestimmten Container zu öffnen.
Ab dem Mozilla VPN 2.6 für Windows, macOS und Linux ist es gemeinsam mit der Erweiterung Firefox Multi-Account Containers 8.0 oder höher möglich, unterschiedliche Standorte für Tab-Umgebungen zu nutzen. So könnte man die USA als Standort im VPN ausgewählt haben, gleichzeitig aber mit einzelnen Tabs in einem anderen ganz Land wie England oder der Schweiz sein.
Damit bietet das Mozilla VPN einen einzigartigen Mehrwert, der mit keinem anderen VPN möglich ist.
Sonstige Neuerungen
Die unterstützung von IPv6 ist nicht länger konfigurierbar, da diese nun immer aktiviert ist. Die im VPN-Client integrierte Feedback-Funktion ist jetzt auch für nicht angemeldete Nutzer zugänglich.
Dazu kommen diverse Fehlerbehebungen und Verbesserungen unter der Haube, die sich in den offiziellen Release Notes (engl.) nachlesen lassen.
Das Mozilla VPN steht jetzt auch unter Ubuntu 21.10 zur Verfügung. Die Installationspakete für Windows und macOS können ab sofort auch über archive.mozilla.org heruntergeladen werden.
Mozilla hat die Release-Termine für das Jahr 2022 offiziell bekannt gegeben. Dieser Artikel fasst alle Termine für Firefox und Firefox ESR übersichtlich zusammen.
Neue Major-Releases von Firefox erscheinen mittlerweile alle vier Wochen. Auf diese Weise erreichen Neuerungen schneller den Endnutzer, der nicht viele Monate auf bereits implementierte Funktionen warten muss.
Mozilla hat die Veröffentlichungstermine von Firefox für das Jahr 2022 mittlerweile offiziell bekannt gegeben.
Das sind die Firefox Release-Termine 2022
Firefox 96, Firefox ESR 91.5 11. Januar 2022 (5 Wochen nach Firefox 95)
Firefox 97, Firefox ESR 91.6 08. Februar 2022 (4 Wochen nach Firefox 96)
Firefox 98, Firefox ESR 91.7 08. März 2022 (4 Wochen nach Firefox 97)
Firefox 99, Firefox ESR 91.8 05. April 2022 (4 Wochen nach Firefox 98)
Firefox 100, Firefox ESR 91.9 03. Mai 2022 (4 Wochen nach Firefox 99)
Firefox 101, Firefox ESR 91.10 31. Mai 2022 (4 Wochen nach Firefox 100)
Firefox 102, Firefox ESR 102.0, Firefox ESR 91.11 28. Juni 2022 (4 Wochen nach Firefox 101)
Firefox 103, Firefox ESR 102.1, Firefox ESR 91.12 26. Juli 2022 (4 Wochen nach Firefox 102)
Firefox 104, Firefox ESR 102.2, Firefox ESR 91.13 23. August 2022 (4 Wochen nach Firefox 103)
Firefox 105, Firefox ESR 102.3 20. September 2022 (4 Wochen nach Firefox 104)
Firefox 106, Firefox ESR 102.4 18. Oktober 2022 (4 Wochen nach Firefox 105)
Firefox 107, Firefox ESR 102.5 15. November 2022 (4 Wochen nach Firefox 106)
Wer Linux intensiv nutzt, wird um die Kommandozeile nicht herumkommen. Hier läuft meist eine Shell, die kompatibel zur Bash ist oder bei der es sich direkt um die Bash handelt.
Interessant bei Bash (und vielen anderen Shells) ist die Leistungsfähigkeit. So beschränkt sich die Kommandozeile nicht auf einfache Programmaufrufe, sondern bietet einige Ausdrücke, die in Verbindung mit kleinen Hilfsprogrammen unter anderem bedingte Anweisungen oder Schleifen ermöglichen. Leider ist die Syntax im Gegensatz zu anderen Skriptsprachen manchmal ungewohnt, weswegen unregelmäßige Anwender öfter mal in der Dokumentation nachlesen müssen.
Eine interessante Unterstützung bietet hierbei explainshell.com. Hier kann man einen Bash-Ausdruck eingeben und ihn sich von der Seite erklären lassen. Dabei werden nicht nur die Manpages der verwendeten Kommandos wie find, grep oder git, sondern auch die passenden Auszüge der bash-Manpage selber eingebunden. Dies wird zusätzlich anschaulich visualisiert.
Der Quellcode von explainshell.com ist GPL-3-lizenziert und auf GitHub verfügbar.
Experiment: elementary OS mit Flatpak zum Jahresabschluss
Zum Jahresabschluss möchte ich noch kurz einen kleinen Zwischenstand zum experimentellen Projekt elementary OS und Flatpaks teilen. Allerdings gibt es eigentlich wenig Neues zu berichten, da alles problemlos läuft.
Das elementary-Team hat die meisten Anwendungen in Flatpaks überführt. Das hat stellenweise ein wenig geruckelt, wie ich im letzten Teil der Serie berichtete. Das System ist dadurch inzwischen sehr sauber in zwei Teile gespalten. Es gibt die (Ubuntu-)Basis, die Pantheon Shell und Desktop-nahen Anwendungen, wie denn Dateimanager oder das Terminal, die über die klassische Paketverwaltung installiert und aktualisiert werden und es gibt für alles andere Flatpaks.
Das Angebot in der Flatpak-Quelle von elementary ist dabei immer noch überschaubar. Ohne Flathub geht also nichts. Folgende Anwendungen werden über Flatpaks aus beiden Quellen bezogen und aktiv genutzt:
LibreOffic
Evince
GIMP
Firefox
Evolution
Aufgaben
VLC
Spotify
AnyDesk
File Roller
KeePassXC
Seahorse
Déjà Dup
VueScan
Sonstiges: Taschenrechner, Bildschirmfoto, Kamera etc. pp.
Also ein ziemlich normales 08/15 Office-Setup.
Einzige Ausnahme ist VirtualBox, das wegen der Kernel-Module nicht als Flatpak laufen kann. So etwas ist meiner Meinung nach aber eh nur eine Übergangslösung. Diese ganzen selbst gebauten Kernelmodule sind noch nie gut für die Stabilität des Systems gewesen und werden bei z. B. macOS seit Jahren zu Recht zurückgedrängt. Die Alternative GNOME Boxes hat leider bei Windows 10 eine zu schlechte Performance.
Das Testsystem hat übrigens nur die üblichen 512 GB SSD. Platzprobleme sind nicht in Sicht. Das Betriebssystem benötigt insgesamt immer noch deutlich unter 15 GB Speicher und die überall kommunizierten Verzögerungen beim Start gibt es auch nicht. Dabei handelt es sich um ganz ordinäre Consumer-Hardware.
Die inzwischen ziemlich abgehangene Ubuntu 20.04-Basis ist dabei bedeutungslos, da über die Flatpaks stets aktuelle Software verteilt wird und dies für den Anwender wirklich relevant ist. Entsprechend entspannt schaue ich deshalb auch auf die kommende LTS 22.04. Das elementary-Team benötigt hier sicherlich wieder ordentlich Zeit um ebenfalls den Umstieg zu vollziehen, aber das ist unter diesen Bedingungen eigentlich egal. Durch den massiven Rückgriff auf Flatpaks sind sowieso kaum Pakete aus universe im System enthalten.
Das Konzept funktioniert zudem „psychologisch“ ziemlich gut. Das App-Store Konzept haben nahezu alle vom Smartphone verinnerlicht. Apps über einen Store zu installieren und zu aktualisieren fühlt sich vertraut an. Die Paketverwaltung und Synaptic konnte ich denselben Anwendern über all die Jahre nicht wirklich nahe bringen.
Probleme gab es exakt nur an einer einzigen Stelle: Firefox hat einen eigenen Druckdialog und das harmoniert nicht mit dem Portal-System für die Berechtigungen. Hier musste man wieder auf den konventionellen Dialog in about:config wechseln.
Interessant ist, dass die elementary-Entwickler sich auch OSTree basierte Images anschauen. Das wird sicherlich nicht mit elementary OS 7 kommen, aber ist eigentlich die logische Konsequenz aus einem Flatpak-basierten Ansatz. Erst mit OSTree kann man nämlich die Stärken wirklich bei Upgrades von einer Basis zur nächsten ausspielen.
In „Flatpak is Not the Future“ ist momentan die gesammelte Kritik an Flatpak zu lesen und wird gegenwärtig durchgereicht. Dabei ist der Blogartikel eigentlich nur eine wilde Mixtur aus tendenziösen Informationen, Mischmasch mit Kritik an Fedora und einer gehörigen Portion „Perfektion als Feind des Guten“.
Eigentlich wollte ich mich nicht dazu im Detail äußern, weil ich in einer Aufstellung zur Paketverwaltung vs. Flatpak/Snap usw. mal alles zusammengestellt habe, was man dazu meiner Meinung nach sagen muss. Da ich mich aber scheinbar in der ganzen Flatpak-Debatte exponiert habe und entsprechend oft deshalb kontaktiert werde, muss ich nun wohl doch etwas dazu schreiben, bevor ich die 20. E-Mail-Antwort dazu verfasse.
Analysegrundlage
Einige Fakten gleich mal vorweg, weil das argumentativ bei vielen immer unterschlagen wird und die ganze Diskussion ins Absurde zieht. Darum möchte ich bei dem Thema immer gerne eine gemeinsame Grundlage herstellen.
Flatpaks und Snaps sollen die klassische Paketverwaltung nicht vollumfänglich ersetzen. Niemand hat das nirgendwo gefordert.
Es gibt keinen Zwang zu Flatpaks / Snaps. Es kann und wird sicherlich auch zukünftig Distributionen geben, die klassisch paketieren. Zumal für speziellere Einsatzszenarien auf leistungsschwächerer Hardware. Es ist freie Software, gemacht wird, was nachgefragt wird.
Die klassische Paketverwaltung ist nicht perfekt. Es gibt Sachen, die damit nicht oder nicht gut funktionieren und die sich deshalb als Folgewirkungen durch das Linux-Ökosystem ziehen (Stable vs. RR, inkompatible Bibliotheken, Softwareverteilung für upstream, Einsatz knapper Ressourcen bei den Distributionen usw.). Es gibt also mithin Verbesserungspotenzial bzw. Handlungsdruck. Das muss natürlich nicht bei Flatpak enden, sondern kann auch anders gelöst werden.
Die Paketverwaltung hat nichts mit freier Software zu tun. Die BSD-Systeme sind auch freie Software und haben ganz andere Softwareverteilungsmechanismen entwickelt. Sie muss deshalb argumentativ nicht direkt auf einen Sockel neben der GPL stehen.
Konzepte wie sogenannte „unveränderbare Systeme“ um Systeme stabil oder über komplett verifizierte Bootvorgänge sicherer zu machen, sind mit bisherigen Systeme nicht umzusetzen. Es gäbe hier sicher auch andere denkbare Ansätze als Flatpaks & Co für die Anwendungsverteilung, aber in diese Richtung geht es jetzt nun mal. Das ist wie bei Elektro vs. Wasserstoff im PKW. Es setzt sich das durch, was auch praktisch da ist und verbessert werden kann und nicht das theoretisch bessere Konzept, während die Verfechter eben jenes besseren Konzepts im Alltag praktisch beim Verbrenner stehen bleiben.
Flatpak Is Not the Future – Die Kernargumente im Detail
Warnung: Es könnte etwas knapp und leicht polemisch werden.
Ich setze für diesen Artikel explizit voraus, dass der Blogbeitrag „Flatpak Is Not the Future“ gelesen wurde, weil ich mich direkt darauf beziehe und nicht den kompletten Inhalt wiedergeben möchte.
Unter der Überschrift „Size“ ergeht sich der Autor sehr lange im Speicherplatzverbrauch. Dazu hat sich ein GNOME/EndlessOS-Entwickler bereits geäußert. Man muss halt auch andere Entwicklungen im Linux-Umfeld rezipieren und kann Flatpak nicht singulär betrachten. Jedes MB aufzurechnen und irgendwelche Low-Budget-Hardware von vor 6 Jahren oder Spezialsachen wie Raspberry Pi heranzuziehen, ist im Linux-Umfeld ein beliebtes Argument, um Entwicklung zu blockieren. Das kennen wir schon von jeder Veränderungsdebatte der letzten 20 Jahre. Deshalb hat Debian ~10 unterstützte Architekturen aber Probleme mit Sicherheitsupdates. Aber ich schweife ab, worauf ich hinaus will: Genau das Gleiche hatten wir bei der verbreiten Abschaffung der 32bit-Architektur in vielen Distributionen – hat bis auf ein paar Meckerköppe, die genau dafür wohl ihren Pentium III aus dem Keller holten, niemanden interessiert.
Das fährt letztlich in der gleichen Kategorie wie die langjährigen Klagen über den vermeintlich exorbitanten „RAM-Verbrauch“. Was man sich wohl von leerem Speicherplatz und Arbeitsspeicher kaufen kann? Das ist übrigens das nächste Argument im Artikel.
Danach kommt die Startzeit. Hier springt der Autor aber argumentativ von Flatpak zu Snap, weil dort mehr Probleme in der Richtung existieren. Klar, man kann sich die Dinge immer so legen, wie man sie braucht. Unbestritten: Flatpak und Snaps brauchen länger für den ersten Start. Danach nicht mehr, aber das zählt ja wohl nicht. Ob der Autor schon mal was von der verbreiteten Nutzung von Standby durch normale Anwender gehört hat? Auf Uralt-Hardware merkt man die Startzeit natürlich. Fraglich, wer da Fedora mit GNOME verwendet. Es ist ja nicht so, dass Flatpaks diktatorisch verordnet werden und es nicht spezialisierte Distributionen für andere Anforderungen geben könnte. Ach wartet mal, die gibts ja schon…
Bei „Drivers“ findet Autor, dass bisher alles paletti ist und es mit Flatpaks & Co nur schlimmer wird. Okay, paletti ist es nur bei Rolling Release Distributionen, was die Mehrheit gar nicht nutzt und definitiv nicht das Ziel des Flatpak-Konzepts ist, aber egal: Alles ist gut! Veränderung gar nicht notwendig.
Bei „Security“ können wir uns eine krude Mischung aus Kritik an den schlechten Voreinstellungen mancher Flatpaks, Kritik an der Erlaubnis, auf das gesamte Dateisystem bzw. das Homeverzeichnis zuzugreifen und die Unterstellung, die Flatpaks würden veraltete Versionen von Bibliotheken ausliefern. Die Argumentationsführung ist extrem schwach, das eigentliche Ziel ist ein anderes: Beim Leser soll hängen bleiben, Sandboxes bringen nichts. Komisch nur, dass alle Betriebssysteme von Android bis macOS heutzutage darauf setzen. Alles ahnungslose Idioten. Linux is King! Auf die Schwächen aktueller Rechtekonzepte ohne Sandbox geht er nicht ein. Wir wissen ja: Aktuell ist alles gut! Am Schluss des Artikels findet der Autor übrigens, dass Sandboxes das Beste an Flatpak sind und irgendwie übernommen werden sollten.
Danach geht es in einem Unterkapitel noch über die Portal-Implementierung. Das scheint für ihn aus Entwicklersicht nicht gut gelöst zu sein. Kann ich nicht beurteilen. Scheint viele andere Entwickler nicht zu stören.
Woher er dann die Autokonversion bei Fedora herzieht und was die dort argumentativ sucht: Keine Ahnung. Hier werden dann wahllos Fedora-Spezifika – über die man sicher streiten kann, z. B. was den Sinn eines eigenen Flatpak-Repo betrifft – mit Kritik am Flatpak-Konzept vermischt.
Unter „Complexity“ nähern wir uns dem Kern der Argumentation. Der Autor hat scheinbar keine Lust, der Entwicklung zu folgen und möchte zurück zu einfachen Prinzipien. Das Argument höre ich mindestens 4 mal pro Jahr von irgendwelchen Entwicklern oder Administratoren. Ist halt nicht. Er schreibt es nicht aus, aber der Abschnitt könnte auch mit KISS überschrieben sein. Möchten wir nicht alle zurück in eine vermeintlich weniger komplexe Welt mit einfacheren Mustern? Ich wünsche mir auch eine Wissenschaft ohne „publish or perish“ aber arbeiten muss ich dennoch mit dem Publikationsoutput der Gegenwart.
Unter „Services“ wird es dann richtig lustig. Es wird kritisiert, dass man für die Nutzung von Flatpak, Snap oder AppImage einen Systemdienst braucht. Das Problem muss man erst mal finden. Klassische Pakete laufen auf meinem Kernel durch den Willen Gottes?
Der Autor sieht hinter allen Lösungen sowieso nur den kommerziellen Masterplan „App Stores“ unter Linux zu verbreiten.
Im Abschnitt „Backwards Compatibility“ können wir dann lesen, dass des A.) nicht so schlimm ist B.) immer besser wird und C.) die Entwickler schlicht zu faul sind. Okay, gut das wir das geklärt haben. Sollen wir einen Link zu dem Abschnitt jedem Hilfesuchen geben, der nach einem Major-LTS-Upgrade wieder inkompatible Programme hat? Angeblich soll das dann zukünftig auch ohne Flatpaks besser werden. Das Argument ist etwas schwer nachzuvollziehen.
Danach wird uns erklärt, dass Kompatibilität sowieso ein spezifisches GTK-Problem ist. Der ein oder andere Punkt ist hier sicherlich richtig und nachvollziehbar, aber der Versuch, alle Probleme mit den Limitationen der Paketverwaltung in Richtung GNOME/GTK zu externalisieren ist leicht zu durchschauen. Beim anderen großen Toolkit Qt ist schließlich auch nicht alles perfekt. Die letzten Toolkit-Aktualisierungen liefen dort auch nicht problemlos und die gegenwärtig essenzielle Unterstützung von Qt5 wird nur durch das KDE-Team gewährleistet. Ohne stünden wir alle im Regen.
Am Schluss wird es dann in „Is Flatpak Fixable?“ ein bisschen versöhnlicher. Hier sind Sandboxes dann wieder toll, obwohl die oben doof waren. Das Problem ist nur, dass der Autor hier die komplette aktuelle Entwicklung in Richtung „immutable“ Systeme ignoriert.
Ein paar Worte zum Schluss
Unzweifelhaft ist auch, dass Flatpaks und Snaps Mehrwerte generieren müssen. Zum Beispiel durch aktuellere Software, sicherere Systeme, längere Kompatibilität, leichtere Upgrades, neue Distributionsmodelle. Wenn die neuen Systeme letztlich durch Kompatibilität und Konformitätsdruck in die Pfadabhängigkeit des bisherigen Linux-Ökosystems gezwängt werden und es keinen funktionalen Mehrwert zur klassischen Paketverwaltung gibt, dann braucht auch niemand Flatpaks und Snaps.
Flatpaks, Snaps & Co sind gegenwärtig alles andere als perfekt. Es gibt zweifelsohne Risiken z. B. durch die Bündelung mit Bibliotheken und die muss man im Blick behalten. Welche Lösung sich technisch durchsetzt und ob es nicht noch mal einen neuen Anlauf gibt, weiß niemand. Wie sich das Ökosystem genau ausgestaltet, ob es bei Flathub als zentraler Quelle bleibt, wie die Sicherheitsstandards in Zukunft sein werden etc. pp. Vieles ist „work in progress“ und wird stetig weiter modifiziert und verbessert. So wie die Linux-Paketverwaltung 2005 auch noch nicht perfekt war und danach noch viele Verbesserungen erhalten hat. Nicht umsonst arbeiten die Projekte bei Fedora oder openSUSE mit Silverblue und MicroOS in speziellen Zweigen, um hier voranzukommen, bevor man die Anwender großflächig damit konfrontiert.
Eine Kritik, die wild beliebige Argumente durcheinander wirft und mit Fedora-Spezifika vermengt, existierende Probleme leugnet oder kleinredet und aktuelle Entwicklungen ignoriert, kann ich aber nur begrenzt ernst nehmen.
Das Konzept selbst ist aber in der Welt und wird nicht mehr verschwinden.
Zu einem modernen Desktop gehört für mich auch eine funktionierende Zwischenablage dazu. In Xfce schalte ich immer die hauseigene Zwischenablage ein, denn nicht jede Zwischenablage funktioniert mit jedem Desktop gleich gut.
Nun arbeite ich seit einigen Tagen das erste Mal mit der GNOME Shell. Nach einem kurzen Versuch mit Clipit, hatte ich schnell bemerkt, dass die GNOME Shell das Diodon mag. Also installierte ich mir das Diodon.
sudo apt-get install diodon
Diodon fügt sich perfekt in die GNOME Shell ein. Ich habe dies unter Ubuntu 21.10 „Impish Indri“ vollzogen.
Ähnlich wie das bereits vorgestellteArtix Linux basiert auch Parabola GNU/Linux-libre auf Arch Linux. Das Projekt ist allerdings wesentlich älter, es startete bereits im Jahr 2009. Während Artix nur auf systemd verzichtet, liegt der Fokus von Parabola auf dem Verzicht unfreier Software. Hier wird Linux-libre als Kernel eingesetzt, ein Fork des Linux Kernels, aus dem alle proprietären Treiberblobs entfernt wurden.
Als Init System kann wahlweise OpenRC oder systemd genutzt werden, meinen Test habe ich natürlich mit der OpenRC Variante durchgeführt. Parabola ist übrigens auch für 32Bit x86 und ARMv7hf Systeme verfügbar, wobei es den Grossteil der Pakete von Arch Linux 32 und Arch Linux ARM bezieht und jeweils mit seinen freien Versionen bestimmter Pakete ergänzt.
Parabola GNU/Linux-libre bietet wahlweise ein CLI ISO für die traditionelle Installation über das Terminal oder ein ISO mit vorinstalliertem LXDE Desktop an. Ich installierte Arch normalerweise gerne über das Terminal, um genau zu wissen, was auf meinem System vorgeht. Angesichts der Tatsache, dass ich nur einen kurzen Test durchführen will, entscheide ich mich heute für die einfachere Variante mit LXDE. Ein Fehler, wie sich schnell herausstellen wird.
Das System startet ohne Probleme, alle Treiber bis auf WLAN sind vorhanden - das war auch nicht anders zu erwarten, ich nutze stattdessen USB Tethering, denn eine Internetverbindung ist zur Installation von Parabola zwingend erforderlich. Es holt alle Pakete bei der Systeminstallation direkt aus dem Repository.
Ich starte nun das Installationsprogramm. Ich erhoffe mir eigentlich ein ausgereiftes grafisches Programm, das mich durch ein paar wenige Konfigurationsschritte führt und mir dann ein funktionierendes System gibt. Leider ist das Installationsprogramm das genaue Gegenteil, eine Vollkatastrophe. Es zeigt ein User Interface im Terminal an, das sehr kompliziert gestaltet ist, keine klare Benutzerführung bietet und, selbst wenn man es geschafft hat, alles korrekt einzurichten, kein funktionierendes System hinterlässt.
Schon die Auswahl der Festplatte finde ich verwirrend. Es reicht nicht, einen Eintrag in der Liste auszuwählen und mit Enter zu bestätigen. Stattdessen muss vorher ein X mit der Leertaste gesetzt werden, sonst wird immer /dev/sda gewählt. Wenn ich hier nicht genau aufgepasst hätte, hätte ich mir meine NomadBSD Installation überschrieben, anstatt des USB-Sticks, den ich zum Testen verwenden möchte. Das Installationsprogramm wirft mir im weiteren Prozess sehr viele Fehlermeldungen entgegen, die ich allerdings nicht lesen kann, weil sie zu schnell wieder vom Menü verdeckt werden. Am Ende gehe ich mit arch-chroot in das neue System, um einige Fehler zu beheben und stelle fest, dass nicht mal pacman korrekt installiert wurde.
Ich breche an der Stelle ab, lösche alles und starte über die manuelle Installation mittels Terminal nochmal komplett von vorne. Die Anleitung von Parabola GNU/Linux-libre ist etwas umfangreicher, als die des normalen Arch Linux, da für OpenRC ein paar zusätzliche Schritte berücksichtigt werden müssen. Der Grossteil ist jedoch identisch, also führe ich einfach einmal die Routine aus, die ich inzwischen fast im Schlaf beherrsche.
Ich installiere zunächst die Basispakete plus Syslinux als Bootloader, dazu openrc-desktop, was bei Parabola für grafische Desktops gebraucht wird und als Desktopumgebung installiere ich das leichtgewichtige LXDE. Alles funktioniert einwandfrei. Ich sehe keine Fehlermeldungen mehr und das neu installierte System startet auf den ersten Versuch erfolgreich in die grafische Oberfläche mit minimalistischer Ausstattung an Programmen.
Parabola GNU/Linux-libre bietet eine riesige Auswahl an Programmen an, die meisten davon werden direkt von Arch Linux kopiert. Nur unfreie Software wird entfernt und oft durch freie Software mit dem gleichen Zweck ersetzt. So finde ich beispielsweise auch hier keinen original Firefox, stattdessen habe ich die Wahl zwischen GNU IceCat, der auf der LTS Version von Firefox basiert und IceWeasel, der vom Parabola Projekt selbst gepflegt wird und auf der normalen Firefox Version basiert.
Als langjähriger Arch Linux Nutzer finde ich mich bei Parabola schnell zurecht. Es orientiert sich auch 12 Jahre später noch stark am Original, bietet aber den grossen Vorteil, zu 100 % auf freie Software zu setzen. Die einzige Einschränkung ist, dass die Treiberverfügbarkeit bei Linux-libre schlechter ist, als beim normalen Kernel, da unfreie Treiber eben entfernt werden. Auf vielen Desktop Computern und auf Servern sollte einem Wechsel zu Parabola wenig im Weg stehen, auf Laptops besteht das Risiko, dass unter anderem WLAN, Touchpad und Touchscreen häufig nicht mehr funktionieren. Hier kann ein Test mit dem LXDE Live ISO vor der Installation sinnvoll sein.
Fazit: Wenn die Hardware passt, sehe ich keinen Grund, noch beim normalen Arch zu bleiben. Der Ausflug zu Parabola GNU/Linux-libre wirkt befreiend. Es ist ein Linux, wie es im Sinne der GNU Richtlinien für freie Systemdistributionen vorgesehen ist und fühlt sich einfach richtig an. Ausprobieren lohnt sich. Und wenn die Hardware doch nicht so gut mit Linux-libre harmonisiert, bietet Artix Linux einen guten Kompromiss, um zumindest systemd loszuwerden.
Tipp: Wer Arch Linux bereits installiert hat, muss Parabola GNU/Linux-libre nicht komplett neu installieren. Genau wie Artix bietet auch Parabola eine Anleitung zur Migration im laufenden System an. Der Wechsel der Distribution ist nicht viel mehr, als eine Änderung der Repository-Adressen. Nur die Umstellung von systemd zu OpenRC ist mit etwas mehr Aufwand verbunden.
In meinem Artikel zu /e/OS wurde ich auf iodéOS aufmerksam gemacht. Dabei handelt es sich um ein Android AftermarketOS mit dem Anspruch, ein besonders gut zu benutzendes Standardsetup auszuliefern.
Was ist iodéOS
iodéOS ist ein Aftermarket-System auf AOSP bzw. LineageOS-Basis. Es ist also ein Android mit Open Source-Software und ohne direkte Anbindung an Google oder proprietäre Google-Apps.
Ähnlich wie bei /e/ positioniert die professionell aufgemachte Webseite iodéOS als Betriebssystem mit Fokus auf Privatsphäre und Ökologie. Letzteres vermutlich wegen der längeren Verwendungsmöglichkeit der Smartphone-Hardware.
iodéOS kann man vorinstalliert mit einem Smartphone erwerben. Neue Smartphones wären das Teracube 2E und das Fairphone 3+. Daneben gibt es sogenannte „refurbished“ Smartphones von Samsung und Sony. Im Gegensatz zu /e/ fokussiert man sich hier auf einige wenige Modelle. Besitzt man bereits eines der unterstützten Modelle, kann man iodéOS auch manuell installieren.
System und Ersteinrichtung
Nach dem ersten Start begrüßt den Anwender eine leicht abgewandelte Einrichtungsroutine. Gut gefällt mir hier der direkte Hinweis, dass man auf der Arbeit von LineageOS aufbaut. Solche Credits gehören für mich einfach zum guten Ton und das ist bei /e/ ein großes Manko. Anschließend kann man auswählen, welche der vorausgewählten Apps man installiert haben möchte. Das ist ein schöner Kompromiss aus einem runden Gesamtpaket und der Möglichkeit, das System auf die eigenen Bedürfnisse anzupassen.
Verweis auf LineageOS
Vorinstallierte Apps
Die App-Auswahl hebt sich deutlich von dem ab, was man z. B. bei LineageOS von Haus aus bekommt. Als Stores stehen F-Droid und Aurora (Play Store Frontend) bereit. F-Droid ist mit der Rechteerweiterung vorinstalliert und kann deshalb automatisch im Hintergrund Aktualisierungen einspielen. Ebenfalls komplett integriert ist microG. Für ein System, das ein möglichst rundes Gesamterlebnis bieten möchte, ist das nachvollziehbar, aber wer es nicht braucht, sollte es bei der Einrichtung deinstallieren, weil man damit letztlich eben doch Google ins System holt.
Optisch bietet das System ein normales AOSP-Erscheinungsbild, wie es bei LineageOS und Android 11 üblich ist.
Es bleibt halt das Problem der Aktualität:
Apps & Dienste
Neben den üblichen AOSP-Apps wie z. B. Dateien, Rechner, Telefon oder Rekorder stehen mit dem iodé Browser (ein Firefox-Fork) auch eigene Anwendungen bereit. Dazu gibt es in F-Droid eine eigene Paketquelle. Hinzu kommen noch Open Source-Apps, die normalerweise nicht Bestandteil von AOSP sind. So liefert man als Tastatur z. B. OpenBoard anstelle des OAPS-Keyboard, QKSMS+ als Nachrichten-App, Carnet als Notizen-App und den PDF Viewer Plus. Der einzige Wermutstropfen: Ähnlich wie bei /e/ greift man auch auf Magic Earth zurück. Eine Entscheidung, die ich nicht ganz verstehe.
Insgesamt ist die App-Auswahl aber gelungen und mir gefällt gut, dass man transparent macht, auf welche Vorarbeiten man aufsetzt und nicht den Eindruck erwecken möchte, dass alles der eigenen Arbeitsleistung entspringt.
Eine Besonderheit ist die App iodé. Diese ist vorinstalliert und kann auf Grund privilegierter Rechte den Netzwerkverkehr zeigen und filtern. Das Ergebnis ist ähnlich wie z. B. bei Blokada, aber ohne die Notwendigkeit, dies über ein simuliertes VPN zu erreichen. Die App macht einen extrem guten Eindruck, hat viele Funktionen und ist übersichtlich. Sie ist vermutlich das größte Alleinstellungsmerkmal von iodéOS.
iodéOS ist hier auf dem Stand 1. Oktober bzw. 5. November. Das ist nicht so katastrophal wie bei /e/OS aber auch nicht perfekt. Der Kernel ist ebenfalls nicht ganz aktuell, denn Samsung liefert dort momentan 4.14.256 für das Galaxy S10 aus.
Was iodéOS gänzlich fehlt ist der Versuch das Google-Ökosystem zu ersetzen, wie /e/ dies mit der eCloud unternimmt.
Zusammengefasst
Insgesamt ist iodéOS aber ein interessantes Projekt. Die vorausgewählten Apps heben sich wohltuend vom AOSP-Einheitsbrei ab und sind gut aufeinander abgestimmt. Der konsequente Rückgriff auf Open Source-Apps und die transparente Darstellung, auf wessen Vorarbeit das Projekt basiert, heben iodéOS von Projekten wie z. B. /e/ ab. Die vorinstallierte App zum Filtern des Netzwerkverkehrs ist sehr sinnvoll und verschafft iodéOS die notwendige Einzigartigkeit im AOSP-Einheitsbrei.
Wer gerne ein bisschen ausprobiert und ein passendes Gerät hat, sollte sich das System mal ansehen. In jedem Fall lohnt es sich iodéOS im Blick zu behalten.
Keep or Delete Bookmarks ist eine in ihrer Art einzigartige Browser-Erweiterung, um Ordnung in die eigenen Lesezeichen zu bekommen. Mit Keep or Delete Bookmarks 2.0 habe ich ein Update mit zahlreichen Neuerungen veröffentlicht, welche sich die Nutzer der Erweiterung gewünscht haben.
Was ist Keep or Delete Bookmarks?
Erweiterungen für Firefox oder andere Browser, um Ordnung in seine Lesezeichen-Sammlung zu bekommen, gibt es einige. Was diese alle gemeinsam haben: Sie funktionieren recht konventionell, Innovation sucht man zumeist vergeblich. Man hat eine Liste von Lesezeichen (oder nicht einmal das) und bekommt im besten Fall die Möglichkeit, automatisiert nach Duplikaten zu suchen oder zu prüfen, ob die Lesezeichen überhaupt noch funktionieren. In diese Kategorie fällt auch meine eigene Lesezeichen-Erweiterung Bookmarks Organizer.
Einen anderen, dynamischeren Ansatz bietet meine exklusiv für Firefox verfügbare Erweiterung Keep or Delete Bookmarks. Keep or Delete Bookmarks funktionert anders als die anderen Lesezeichen-Erweiterungen und versucht in dem Bewusstsein, das Aufräumen normalerweise keinen Spaß macht, den Anwender durch seinen spielerischen Ansatz dazu zu motivieren, regelmäßig und vor allem gerne zu kontrollieren, welche Lesezeichen überhaupt noch benötigt werden.
Eine ausführliche Vorstellung des einzigartigen Konzeptes zur Lesezeichen-Organisation gibt es im Vorstellungs-Artikel von Keep or Delete Bookmarks auf diesem Blog.
Keep or Delete Bookmarks 2.0
Es gibt vieles, was eine Lesezeichen-Erweiterung alles leisten könnte, um so ein wirklich komplettes Paket zur Organisation von Lesezeichen zu schüren. Eine eierlegende Wollmilchsau ist hier allerdings ein explizites Nicht-Ziel. Stattdessen ist mir in Keep or Delete Bookmarks wichtig, den Fokus nicht aus den Augen zu verlieren: Die Erweiterung funktioniert nicht dadurch, alles zu können, was eine Lesezeichen-Erweiterung theoretisch leisten könnte. Die Erweiterung funktioniert durch ihre Einfachheit in der Handhabung und Präsentation. In diesem Sinne lag der Fokus bei der Entwicklung von Keep or Delete Bookmarks 2.0 auf Features, welche dem Nutzer sowohl bei der Entscheidungsfindung helfen als auch den Prozess weiter beschleunigen, ohne dabei die Oberfläche unnötig zu überladen.
Überprüfung auf fehlerhafte Lesezeichen
Die größte Neuerung im Bereich der Entscheidungsfindung ist zweifelsohne die Überprüfung auf fehlerhafte Lesezeichen. In der Vergangenheit habe ich bezüglich meiner Erweiterung Bookmarks Organizer immer wieder gehört, dass diese Erweiterung vielleicht im Gesamtpaket nicht die vollständigste Erweiterung zur Organisation von Lesezeichen ist, aber die Überprüfung auf fehlerhafte Lesezeichen zuverlässiger als bei anderen Erweiterungen für Firefox und Chrome funktioniert.
Das Ziel für dieses Update war es, diese gut funktionierende Komponente zu nehmen und für Keep or Delete Bookmarks in einer vereinfachten Variante zu portieren. Dabei wird jedes Lesezeichen in Echtzeit überprüft, ob dieses denn noch funktioniert oder wahrscheinlich defekt ist. Dabei kennt Keep or Delete Bookmarks nur drei Zustände: Das Lesezeichen scheint in Ordnung zu sein, Das Lesezeichen ist möglicherweise fehlerhaft, Keine Überprüfung möglich. Im Gegensatz zum Bookmarks Organizer unterscheidet Keeps or Delete Bookmarks also nicht zwischen Lesezeichen, deren URL unverändert funktioniert, und Lesezeichen, die auf eine andere URL weiterleiten. Die Formulierungen sind bewusst defensiv gehalten, um den Anwender nicht zu irritieren: Bevor Lesezeichen gelöscht werden, sollten diese immer noch einmal von Hand überprüft werden.
Gemeinsam mit dem Bookmarks Organizer ist eine interne Liste, um jene Lesezeichen nicht zu überprüfen, von denen bekannt ist, dass deren URLs aus technischen Gründen nicht auf Funktionalität überprüft werden können.
Wann wurde das Lesezeichen zu Firefox hinzugefügt?
Beim Thema Entscheidungsfindung hilft auch eine weitere Neuerung, die in den vorherigen Screenshots zu sehen ist: Keep or Delete Bookmarks zeigt jetzt das Datum an, wann das jeweilige Lesezeichen zu Firefox hinzugefügt worden ist. Bei der Formatierung des Datums hält sich die Erweiterung an den System-Standard: In einem deutschen Firefox ist das Datum im Format 23.12.2021, in einem US-Firefox im Format 12/23/2021.
Vorherige Lesezeichen anzeigen
Ein weiteres Feedback, welches ich von Nutzern erhalten hatte, war die Tatsache, dass man doch manchmal zu schnell klickt und es wünschenswert wäre, wenn man wieder zurück zum vorherigen Lesezeichen springen könnte. Auch dies ist in Keep or Delete Bookmarks 2.0 möglich. Eine neue „zurück“-Schaltfläche erlaubt es, so viele Schritte zurück zu navigieren, wie Lesezeichen bereits angezeigt worden sind. Ein Klick auf „weiter“ zeigt dann wie gehabt ein neues zufälliges Lesezeichen an.
Bedienung per Tastatur
Ebenfalls von Nutzern gewüscht und jetzt umgesetzt ist die Möglichkeit, die Bedienung durch die Unterstützung einer Tastatur-Nutzung zu beschleunigen. Dabei wurden folgende Tastatur-Befehle implementiert:
Backspace: Lesezeichen löschen (oder Bestätigungsdialog öffnen, wenn aktiviert)
im Bestätigungsdialog zum Löschen eines Lesezeichens:
ESC: Dialog schließen
Eingabe: Lesezeichen löschen
Sonstige Neuerungen
In der Whiteliste für Lesezeichen, die nicht erneut angezeigt werden sollen, wurde ein fehlerhafter Tooltip für die Schaltfläche zum Entfernen von der Whitelist korrigiert. Dieser sagte irrtümlich aus, dass das Lesezeichen gelöscht würde.
Nach Deutsch, Englisch, Niederländisch, Obersorbisch sowie Niedersorbisch steht die Erweiterung mit Japanisch nun in einer sechsten Sprache zur Verfügung.
Außerdem gab es kleinere Korrekturen und Verbesserungen unter der Haube. So wurde unter anderem ein veralteter Funktionsaufruf ersetzt und die Erweiterung mit Mozillas web-ext-Tool in Version 6.6.0 kompiliert (vorher: 3.1.0). Der Footer der Erweiterung zeigt nicht länger die Jahreszahl 2019, sondern stattdessen 2022 an.
Die neue Mindestanforderung der Erweiterung ist Firefox 91 oder höher, Firefox 68 bis Firefox 90 werden nicht länger unterstützt.
Zusätzliche Berechtigung benötigt
Keep or Delete Bookmarks 2.0 benötigt im Gegensatz zur Version 1.0 die zusätzliche Berechtigung, auf die Daten für alle Websites zugreifen zu können. Dahinter steckt, dass die Erweiterung seit dieser Version die Lesezeichen prüft, indem sie Anfragen an die entsprechenden URLs sendet. Dies kann nicht ohne die genannte Berechtigung funktionieren.
Download der Erweiterung
Wie alle meine Erweiterungen ist auch Keep or Delete Bookmarks über addons.mozilla.org zu beziehen:
Keep or Delete Bookmark ist Open Source (MPL 2.0) und der Quellcode auf GitHub zu finden. Dies ist auch der Ort, an welchem Fehler gemeldet und Vorschläge gemacht werden können.
Entwicklung unterstützen
Wer die Entwicklung des Add-ons unterstützen möchte, kann dies tun, indem er der Welt vom Keep or Delete Bookmarks erzählt und die Erweiterung auf addons.mozilla.org bewertet. Auch würde ich mich sehr über eine kleine Spende freuen, welche es mir ermöglicht, weitere Zeit in die Entwicklung des Add-on zu investieren, um zusätzliche Features zu implementieren.
Die MZLA Technologies Corporation hat mit Thunderbird 91.4.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht. Dieses behebt auch zwei Sicherheitslücken.
Neuerungen von Thunderbird 91.4.1
Mit dem Update auf Thunderbird 91.4.1 hat die MZLA Technologies Corporation ein Update außer der Reihe für seinen Open Source E-Mail-Client veröffentlicht und behebt damit mehrere Fehler der Vorgängerversion. Diese lassen sich in den Release Notes (engl.) nachlesen. Unter den Korrekturen befinden sich auch zwei als moderat eingestufte Sicherheitslücken, die mit dem Update behoben worden sind.
GNU Guix ist eine GNU/Linux Distribution, die vom GNU Projekt selbst entwickelt wird und ein ganz unkonventionelles Konzept der Paketverwaltung mitbringt. Die Distribution nutzt den Linux-libre Kernel und das GNU Shepherd Init System. Die Treiberverfügbarkeit ist aufgrund des Linux-libre Kernels eingeschränkter als bei anderen Distributionen, dafür wird aber nur 100 % freier Code verwendet. Achtung NixOS Fans: GNU Guix hat sich stark von NixOS inspirieren lassen, wer also von NixOS begeistert ist, sollte hier unbedingt weiterlesen.
GNU Guix lässt sich wahlweise manuell über das Terminal oder über ein Installationsprogramm installieren. Da ich die Distribution nur für einen kurzen Test benötige, habe ich mich für die unkomplizierte Variante über das Installationsprogramm entschieden. Dieses kommt ohne X Server aus, sondern stellt ein User Interface direkt im Terminal dar und wird mit der Tastatur bedient. Trotzdem ist es übersichtlich und meiner Einschätzung nach einfach zu bedienen.
Die Installation ist wahlweise mit oder ohne Internetzugang möglich, mit Internetzugang habe ich die Möglichkeit, zusätzliche Pakete direkt bei der Systeminstallation mitzuinstallieren. Hierzu zählt auch die Auswahl des Desktops. Die meisten bekannten Desktopumgebungen werden angeboten, ich entscheide mich hier für Enlightenment.
Nach der Installation starte ich den Computer neu und sehe... nur einen schwarzen Bildschirm. Mit Strg+Alt+F2 wechsle ich ins Vollbildterminal und schaue mir das Xorg Log an. Scheinbar sind Xorg und der AMD Grafiktreiber in verschiedenen, inkompatiblen Versionen installiert. Merkwürdig. Ich fahre GNU Guix wieder herunter und probiere den fertig installierten USB-Stick nochmal mit einem Computer mit Nvidia Grafikkarte.
GNU Guix bootet weiterhin innerhalb weniger Sekunden, obwohl dieser Computer nur USB 2.0 Anschlüsse hat. Von der Performance bin ich beeindruckt. Hier startet nun auch Xorg und das grafische Anmeldeprogramm, GDM. Ich logge mich ein, alles funktioniert wie erwartet, bis auf die Tatsache, dass kaum Programme vorinstalliert sind, nicht mal ein grafischer Terminalemulator.
Mit guix install terminology im Vollbildterminal (Strg+Alt+F2) installiere ich mir das zum Enlightenment Desktop passende Terminal Programm. Das geht hier sogar ganz ohne sudo: Bei Guix kann jeder Benutzer eigene Pakete installieren, ohne dafür Root Rechte zu brauchen. Diese werden dann in einem Unterordner des Home Verzeichnisses verlinkt. Gespeichert wird alles an einem Platz - Wenn 20 Benutzer das gleiche Programm installieren, wird der Speicherplatz für dieses also nicht 20 Mal verbraucht, sondern trotzdem nur einmal. Verschiedene Nutzer können das gleiche Programm auch in verschiedenen Versionen installieren. Dann wird es in verschiedenen Ordnern gespeichert. Die verschiedenen Versionen behindern sich nicht gegenseitig.
Das Angebot im Repository von Guix ist riesig, laut Webseite sind aktuell 19542 Pakete gelistet. Damit übertrifft es sogar Arch Linux mit 12343 Paketen, das den Ruf hat, fast jedes Programm direkt im offiziellen Repository anzubieten. Die Pakete werden auf der Webseite alphabetisch aufgelistet oder können im Terminal mit guix search [suchbegriff] gesucht werden. Bei Guix sind jedoch ausschliesslich freie Programme zu finden. Statt Firefox wird beispielsweise GNUs eigener Fork IceCat angeboten, statt Chrome gibt es Ungoogled Chromium.
GNU Guix eignet sich sowohl für normale Computer, als auch für Server. Beliebte Webserver wie lighttpd und nginx sind vorhanden, ebenso gängige Programmiersprachen-Interpreter wie PHP, Python oder Ruby und sogar Synapse (Matrix Server) oder Prosody (Jabber/XMPP Server) lassen sich ganz einfach installieren.
Es handelt sich hierbei um eine Rolling Release Distribution. Durch ihren besonderen Paketmanager ist sie trotzdem stabil genug für einen Server: Wenn etwas schiefgeht, lassen sich Updates einfach rückgängig machen und ältere Zustände wiederherstellen. Wenn der Updateprozess unterbrochen wird, beispielsweise durch einen Absturz, kann nichts kaputtgehen: Nur erfolgreich beendete Transaktionen werden angewendet.
Wie oben bereits angedeutet, ist GNU Guix und insbesondere der Paketmanager, der übrigens auch auf anderen Distributionen installiert werden kann, stark von NixOS inspiriert. Der Paketmanager nutzt sogar Teile des Nix Codes, die Konfiguration und die Paketrezepte sind bei Guix allerdings in der Sprache GNU Guile Scheme geschrieben. Auch GNU Guix nutzt ein funktionales Modell und speichert seine Pakete in einer ähnlichen Verzeichnisstruktur, /gnu/store statt /nix/store. Wer bereits mit NixOS gearbeitet hat, wird also sicherlich viel Freude mit GNU Guix haben.
Fazit: GNU Guix hat meine Erwartungen erfüllt. Es ist ein sehr spannendes Projekt, für das man sich aber auch mehr Zeit nehmen müsste, um es wirklich richtig zu verstehen. Wenn man das Glück hat, ein Gerät zu haben, bei dem der Linux-libre Kernel alle Treiber unterstützt, lohnt sich das Ausprobieren auf jeden Fall. Insbesondere NixOS Fans werden hier begeistert sein.
Updates sind bei vielen Systemen nicht ohne Risiko. Weggebrochene Verbindungen, leerer Akku, der falsche Handgriff, eine Inkompatibilität und zurück bleibt ein unbenutzbares Gerät. Viele meiden deshalb fatalerweise Updates. GrapheneOS vermeidet solche Fehler durch die Verwendung aktueller Methoden.
Updateprozesse sind bei den meisten Systemen nicht so resistent gegen Fehler, wie man das gerne hätte. Vermutlich ist schon jeder Mal bei Windows in einer Endlosschleife stecken geblieben oder hat bei Linux seine Paketverwaltung in einem blockierten Zustand vorgefunden. Besonders heikel ist bei allen Systemen der Schritt nach dem Download. Ist die Software fehlerhaft, gibt es ein Kernelproblem, ist der Akku leer oder tritt irgendein anderes unvorhergesehenes Ereignis ein, könnte im schlimmsten Fall das komplette System fehlerhaft sein. Michael Stapelberg hat für klassische Linux-Paketmanager da vor knapp 2 Jahren einen spannenden Blogartikel geschrieben.
Unter Android ist das bei den meisten Aftermarket-Varianten wie z. B. LineageOS noch viel schlimmer. Was oft unter dem Label Over-the-Air (OTA) verkauft wird, bedeutet meist technisch einen Wechsel in das Recovery-System, wo dann das OTA-Paket über die bestehende Version „rüber gebügelt“ wird. Dabei kann naturgemäß natürlich einiges schief gehen – schlimmstenfalls hat man ein unbenutzbares Gerät.
Um dieses Problem anzupacken, haben viele Hersteller unabhängig voneinander ein neues Verfahren entwickelt. Dieses funktioniert trotz technischer Unterschiede im Detail nach denselben Prinzipien. Dabei wird während des Upgrades eine zweite Version des Betriebssystems neben der laufenden Version installiert. Das macht Apple seit einiger Zeit mit macOS so, Fedora hat dieses Verfahren für Silverblue umgesetzt und Googles Stock Android verfährt ebenso. Durch einen Neustart bootet man dann in dieses „neue System“. Gibt es Probleme oder Fehler, kann das System immer noch automatisch in den alten Zustand zurückwechseln und das Update erneut initialisieren.
Genau auf dieses Verfahren setzt auch GrapheneOS. Updates bedeuten deshalb wirklich nur einen Neustart und sind risikofrei. Ein nicht unwichtiger Aspekt, denn die falsche verstandene Mär von „Never change a running system“ und verbreitete Vermeidung von Updates sind das größte Sicherheitsrisiko überhaupt.
Viele von euch haben schon von Lineageos gehört oder haben es sogar auf dem Smartphone installiert.
Nun hat das Team von Konstakang.com eine Implementation von Lineageos 19.0 herausgebracht, die auf Android 12 basiert und auf den Raspberry Pi 4 portiert wurde.
Empfohlen wird ein Raspberry Pi 4 Model B mit 2 oder 4 GB RAM, ein Raspberry Pi 400 oder das Compute module 4.
Das Image wird nicht offiziell vom Lineageos team supportet. Trotzdem läuft es sehr gut und flüssig auf meinem Testsystem.
Serial console (using external GPIO serial console adapters e.g. PL2303)
SPI
Touchscreen/multi-touch (official 7” touchscreen, USB touchscreens, Waveshare SPI touchscreens)
USB (mouse, keyboard, storage, etc)
USB-C (ADB, MTP, PTP, USB tethering)
Wifi (and wifi tethering)
Die Liste ist schon sehr beeindruckend wenn man bedenkt, dass Android normalerweise auf SBCs nur sehr rudimentär funktioniert. Diese halbherzigen Versuche haben deshalb bei mir auch nicht lange Bestand gehabt. Das könnte sich jetzt ändern.
Bei Artix Linux fühle ich mich als langjähriger Arch Nutzer schnell heimisch. Die Installationsanleitung für die traditionelle Terminal-Installation ist nahezu identisch zu der von Arch Linux. Da ich Artix Linux aber nur für mein Review brauche, mache ich es mir einfach und greife auf eine Variante mit vorinstalliertem grafischem Desktop zurück.
Artix Linux bietet ISOs mit Cinnamon, LXDE, LXQt, Mate, KDE Plasma und Xfce. Alle Varianten werden wahlweise mit OpenRC, runit, s6 oder suite66 als Init System angeboten. Bei den automatisch erstellen Weekly ISOs ist zusätzlich auch Dinit vorhanden. In der experimentellen Phase werden auch GNOME und i3 angeboten. Ich entscheide mich für Cinnamon und OpenRC.
Das Artix Linux Projekt entstand aus einem Zusammenschluss von Arch-OpenRC und Manjaro-OpenRC. Diese beiden waren keine eigenständigen Distributionen, sondern haben das normale Arch Linux und Manjaro so umgebaut, dass es OpenRC statt systemd nutzte, während man Pakete trotzdem noch aus den offiziellen Arch und Manjaro Repositorys bezogen hat.
Auch aus diesem Grund unterstützt Artix Linux beide Vorgehensweisen - die komplizierte Installation im Terminal und fertige live Systeme mit vorinstalliertem Desktop. Artix Linux ist heute ein ganz eigenständiges Projekt mit eigener Infrastruktur und eigener Community. Es hat ganz eigene Repositorys, in denen sich die Softwareauswahl deutlich von der bei Arch und Manjaro unterscheidet.
Nun starte ich also mein Artix Linux mit OpenRC und Cinnamon vom Live-USB-Stick. Alle Treiber werden perfekt unterstützt, schliesslich wird auch hier der ganz normale Linux Kernel eingesetzt (LTS optional verfügbar). Das System startet deutlich schneller als mit systemd, sonst spüre ich keinen grossen Unterschied. Noch deutlicher wird es beim Herunterfahren, wo OpenRC nur wenige Sekunden braucht, während sich systemd gerne mal über eine Minute an einzelnen Prozessen aufhängt.
Aus Gewohnheit starte ich als Erstes ein vollständiges Systemupdate mittels pacman -Syu im Terminal. Das war keine gute Idee: Die Live ISOs nutzen ein OverlayFS, sie sind schreibgeschützt und speichern Änderungen nur im RAM. Mit dem Update fülle ich also meinen RAM und beim nächsten Neustart ist alles wieder weg. Ich merke es schnell und entscheide mich zur Installation auf einen weiteren USB-Stick, damit es beschreibbar ist.
Die Installation ist über das grafische Installationsprogramm schnell erledigt, der Vorgang ist eigentlich selbsterklärend. Das einzige, was man an Fachwissen mitbringen muss, ist die Tatsache, dass man die NTFS Partition des ganz neuen USB-Sticks löschen und durch eine auf / gemountete Ext4 Partition ersetzen muss.
Als Nächstes möchte ich Firefox installieren. Vorinstalliert ist GNOME Web. Der ist schön leichtgewichtig, aber reicht mir nicht. Hier treffe ich auf die erste grosse Überraschung: Firefox ist nicht in den normalen Artix Repositorys verfügbar. Es gibt bei Artix Linux noch zwei weitere Repositorys, die standardmässig nicht aktiviert sind: Universe und Omniverse.
Universe enthält hauptsächlich Programme aus dem AUR und ist unbedingt zu empfehlen. Von hier können unter anderem der datenschutzfreundliche Firefox-Fork LibreWolf, der datenschutzfreundliche Chromium-Fork Ungoogled Chromium und der Tor Browser unkompliziert installiert werden. Das Omniverse Repository enthält Programme aus dem Community Repository von Arch und ebenfalls aus dem AUR. Hier sind hauptsächlich Pakete mit unfreien Bestandteilen, also sollte man genau hinschauen, bevor man etwas installiert. Hier wäre auch der normale Firefox mit Telemetrie, DRM und so weiter zu finden. Ich lehne dankend ab und installiere den LibreWolf aus dem Universe Repository. Falls das alles nicht reicht, können auch Repositorys von Arch Linux mit eingebunden werden oder Pakete aus dem AUR installiert werden.
Eine weitere Besonderheit von Artix Linux ist die Verfügbarkeit der Desktopoberfläche Trinity. Sie befindet sich nicht in den voreingestellten Repositorys und es werden keine vorgefertigten Images damit angeboten, aber in einem speziellen Unterordner auf dem Omniverse Server werden die entsprechenden Pakete angeboten und können von erfahrenen Nutzern installiert werden. Das Repository wird von einem der Artix-Gründer gepflegt und sollte damit relativ stabil sein. Für die, die Trinity nicht kennen: Es ist ein Fork von KDE 3, der mit seinem Design stark an ältere Windows Versionen erinnert. Wir haben es mit der Distribution Q4XP bereits vorgestellt.
Fazit: Artix Linux überzeugt in jeder Hinsicht voll und ganz. Man gewöhnt sich als Arch Nutzer schnell ein, es bietet eine riesige Auswahl an Paketen, wie man es von Arch gewohnt ist und packt sogar noch nette Extras wie datenschutzfreundliche Forks der grossen Browser und den genialen Trinity Desktop obendrauf. Ausprobieren lohnt sich hier wirklich, es bleiben keine Wünsche offen.
Tipp: Wer bereits Arch Linux installiert hat, muss Artix nicht ganz neu installieren, sondern kann im laufenden System von Arch zu Artix migrieren. Diesen Prozess werde ich im letzten Teil der Init Freedom Serie vorstellen.
Am Wochenende wurde die Version 11.2 der Linux-Distribution Debian veröffentlicht. Der zweite Point-Release von Debian 11 – auch bekannt unter dem Namen Bullseye – behebt 64 Fehler und enthält 30 Sicherheitsupdates. Es empfiehlt sich, das System in möglichst naher Zukunft zu aktualisieren.
Unter den aktualisierten Paketen sind unterschiedliche Pakete. Dem neu ausgelieferten Paket für cmake wurde die Version 13 von PostgreSQL zu den bekannten Versionen hinzugefügt. Bei plocate – einer schnellen Alternative zu locate – wurde ein Fehler behoben, welcher Zeichen, die nicht aus dem ASCII-Zeichensatz kommen, falsch escaped hat. Bei 32-Bit-Systemen sollte es nun zu keinen Problemen mehr kommen, wenn mit wget eine Datei heruntergeladen wird, welche grösser als 2 GB ist. Der ausgelieferte Linuxkernel hat jetzt die Version 5.10.83-rt58. Weitere aktualisierte Pakete sind unter anderem chrony, containerd, curl, golang-1.15, kodi und python-virtualenv.
Im Rahmen der Sicherheitsaktualisierungen wurde beispielsweise das Paket apache-log4j2 aktualisiert. Log4j ist eine beliebte Logging-Bibliothek für Javaanwendungen, welche eine kritische Schwachstelle aufwies (wir berichteten). Ausserdem wurde unter anderem der Browser Firefox, die Officeanwendung Libreoffice, die Datenbank PostgreSQL und das Netzwerkanalysewerkzeug Wireshark mit Updates versorgt. Zu den Sicherheitslücken hat das Security-Team jeweils einzelne Handlungsrichtlinien veröffentlicht.
Die komplette Liste der Änderungen findet sich in der Quelle. Personen, welche Bullseye bereits installiert haben, können die Aktualisierungen über die Paketverwaltung installieren. Zusätzlich stehen auf der Webseite des Projektes aktuelle Images zur Verfügung.
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?
Startscreen
Einstellungen
Versionen
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.
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.
MATE verwende ich gerne in virtuellen Maschinen, wo mir KDE Plasma oder Pantheon zu ressourcenintensiv sind. Von den größeren Desktopumgebungen sind somit lediglich Xfce und die GNOME Shell bei mir nicht im Einsatz.
