y0o.de · GNU/Linux Nachrichten u.Ä.

🔒
❌ Über y0o.de
Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere Beiträge[Mer]Curius

(x)Ubuntu 22.04 (Jammy Jellyfish) im Ausblick

16. Januar 2022 um 12:59
Von: Gerrit

Im April diesen Jahres ist es wieder soweit. Ubuntu und die offiziellen Derivate veröffentlichen eine neue LTS der beliebten Distribution. Mithin das wichtigste Ereignis im Linux-Kalender. Zeit mal einen kleinen Ausblick zu nehmen.

Das Release der neuen LTS von Ubuntu hat sicherlich die größte Breitenwirkung aller Linux-Distributionen. Die große Mehrheit der Linux-Anwender nutzt Ubuntu, eines der offiziellen Derivate oder eines jener inoffiziellen Derivate wie beispielsweise Linux Mint oder elementary OS. Hier treffen zwei Jahre Entwicklung am Linux-Desktop auf den Anwender und damit die Wirklichkeit.

Noch ist einiges im Fluss, denn der Feature Freeze steht erst am 24. Februar an, aber einige Aussagen lassen sich bereits jetzt treffen. Große Umbrüche sind dieses Jahr nicht zu erwarten, aber einige Änderung an der Oberfläche der jeweiligen Derivate und unter der Haube stehen an.

Die größte und wichtigste Neuerung. Es wird nach Jahren einen neuen Installer geben. Unter der Haube lässt man es hingegen eher bedächtig angehen und wird den Linux Kernel 5.15 nutzen, der bereits jetzt bei vielen Rolling Release-Distributionen zum Einsatz kommt. Allerdings ist das wenig dramatisch, weil Ubuntu traditionell im Laufe des Lebenszyklus der Distribution neuere Kernel-Versionen an die Anwender verteilt.

Das Hauptderviat Ubuntu wird standardmäßig Wayland nutzen und damit die endgültige Abkehr von X.org einleiten. Es dürfte sicherlich spannend werden, ob Wayland wirklich schon reif für den produktiven Einsatz bei Massen von normalen Anwendern ist. Bei der Desktopumgebung fährt man eine Zwischenmethode, die bereits bei früheren Releases zum Einsatz kam. Eine aktuelle GNOME Shell (vermutlich 42) wird mit älteren Apps kombiniert, da Ubuntu noch nicht auf Gtk4-Apps umsteigen möchte. Optisch gestaltet man die Shell weiterhin im Stil von Unity. Anwender müssen sich also nicht umorientieren. Firefox ist standardmäßig als Snap enthalten. In den Paketquellen ist aber immer noch ein normales Firefox-Paket im Bereich main enthalten. Die Anwender haben also die Wahl. Ansonsten gibt es nur wenige Änderungen gegenüber Ubuntu 21.10 – was aber für ein LTS-Release nicht unüblich ist.

Kubuntu aktualisiert wie üblich KDE Frameworks, KDE Plasma und die Programmsammlung KDE Gear. KDE Gear wird vermutlich in der Version 21.12 aus dem vergangenen Dezember ausgeliefert werden. KDE Plasma ist bereits in einer Vorschauversion von 5.24 enthalten. Diese Version wird es somit mit Sicherheit ins Release schaffen. Diese Version könnte möglicherweise wieder eine LTS-Version mit Upstream-Unterstützung werden. Mit Sicherheit ist Kubuntu 22.04 die letzte LTS-Version mit einer Qt 5-Basis. Anwender dürfte dies freuen, da KDE gegen Ende eines Releasezyklus meist die besten Produkte ausliefert, bevor man wieder von vorne anfängt. Kubuntu liefert ebenso Firefox als Snap aus und bleibt bei der Abkehr von KDEPIM zugunsten von Thunderbird.

Ubuntu MATE modernisiert leicht sein Design verglichen mit der Version 20.04. Dabei orientiert man sich am Yaru-Theme des Hauptderivats, das in das charakteristische Grün gefärbt wird. Ubuntu MATE unterscheidet sich hierdurch stark von anderen Distributionen, die MATE ausliefern. Auffällig ist die stärkere Bezugnahme auf GNOME-Programme wie Rhythmbox oder Shotwell. Firefox liegt noch nicht in der Snap-Version bei, aber vermutlich sind die Arbeiten hier nur noch nicht abgeschlossen, da Ubuntu MATE traditionell bereits Snaps ausliefert.

Wenig Neues zu berichten gibt es bei den Derivaten Xubuntu, Lubuntu und Ubuntu Budgie. Das liegt schlicht daran, dass die entsprechenden Desktopumgebungen kaum Veränderungen erfahren haben. Hier integriert man lediglich die neuen Versionen der Desktopumgebungen, welche so aber auch schon in beispielsweise 21.10 enthalten waren. Auffällig ist der vollständige Verzicht auf Snaps bei Xubuntu und Lubuntu. Ubuntu Budgie nutzt gegenwärtig Snaps nur Testweise für den Welcome-Screen.

Insgesamt hat die kommende Version 22.04 das Potenzial wieder ein stabiles und unaufgeregtes LTS-Release zu werden. Bei keinem Derivat sind momentan schwierige Strukturen oder potenziell problematische technische Umbrüche zu erwarten. Allerdings ist bis zum Feature Freeze noch ein wenig Zeit und somit kann das nur als erster Ausblick gewertet werden.

Der Artikel (x)Ubuntu 22.04 (Jammy Jellyfish) im Ausblick erschien zuerst auf [Mer]Curius

KDE – Eine kleine Niedergangsgeschichte

15. Januar 2022 um 15:00
Von: Gerrit

Das Kool Desktop Environment war mal gestartet als Versuch „den“ Linux-Desktop zu erschaffen. Nach Jahren des schleichenden Niedergangs kann man sich nun hinter GNOME in der zweiten Reihe neben Xfce, MATE und anderen einreihen.

KDE konnte letztes Jahr sein 25-jähriges Jubiläum feiern und sieht sich natürlich selbst auf der Erfolgsspur. Das kann man auch anders sehen und wo, wenn nicht in diesem Blog, wo bekanntermaßen immer alles schlecht gemacht wird – vor allem Linux und hier insbesondere KDE und Debian – sollte man so eine Geschichte schreiben.

Bei der Recherche bin ich auf die Meldung zum 10-Jährigen Jubiläum von KDE gestoßen. Das deckt sich fast mit meinem persönlichen Linux-Einstieg, deshalb lassen wir diese Geschichte 2006 beginnen.

Wir schreiben das Jahr 2006. Smartphones brauchen noch ein paar Jahre und Microsoft hat gerade mit Windows Vista ein richtiges Fiasko erlebt. Im Linux-Land wittert man Morgenluft und tatsächlich wechseln merkbar enttäuschte Windows-Nutzer ins Linux-Lager. Passenderweise hatte sich kurz zuvor ein ambitionierter Unternehmer namens Mark Shuttleworth aufgemacht, eine Linux-Distribution zu erschaffen, die für normale Anwender benutzbar sein soll. Leider mit GNOME und hier gehts los.

Im Jahr 2006 gibt es im wesentlichen drei Linux-Desktops. KDE, GNOME und für Anwender mit geringeren Ressourcen und Anforderungen Xfce. Dazu natürlich noch eine Menge Windowmanager und andere Lösungen, aber die machen zusammen nicht nennenswert Marktanteile aus. GNOME und KDE haben sich bereits in den 1990ern parallel entwickelt, weil Qt nicht frei war und Alternativen schön sind. Mal so ganz stark verkürzt ausgedrückt.

2006 ist die Sache aber nicht entschieden. Die berühmten Desktopwars bestimmen die Diskussion und KDE und GNOME dürften in etwa gleich viele Nutzer auf sich vereinen. Es gibt regionale Schwerpunkte, auch abhängig von regionalen Schwerpunkten entsprechender Distributionen. KDE ist auf dem Höhepunkt des Entwicklungszweiges der Version 3.5. Bis heute eine der Versionen, an die sich viele Anwender gerne zurückerinnern. KDE ist so wichtig, dass Canonical nicht umhinkommt mit Version 6.06 KDE bzw. Kubuntu den gleichen Status wie dem Hauptderivat Ubuntu zuzusprechen und mit Jonathan Riddell einen Entwickler dafür hauptamtlich anzustellen.

Danach beginnt der Niedergang. Im Jahr 2008 veröffentlicht KDE die Version 4. Ein Debakel sondergleichen in der öffentlichen Wahrnehmung. Obwohl nur als Vorschauversion gedacht, kommuniziert man derart schlecht, dass der Ruf nachhaltig leidet. Denn die Software ist funktional nicht ausgereift und strotzt nur so vor Fehlern. Wohlmeinende Anwender bleiben bei 3.5, andere wenden sich enttäuscht ab.

Ewig können die Distributoren aber nicht an KDE 3.5 festhalten. In den Folgejahren stellen nach und nach die Distributionen um. Der Support von Kubuntu 8.04 endet beispielsweise bereits im Oktober 2009, weil Kubuntu angesichts der Entwicklung auf LTS-Support verzichten musste – gewissermaßen das erste KDE-Opfer, bei dem man hinter der offiziellen Hauptvariante zurückstecken musste. Nahezu zeitgleich erscheint openSUSE 11.2 ohne KDE 3.5. Die Nutze können nun nur noch migrieren, aber KDE SC 4 ist zu diesem Zeitpunkt immer noch von Alltagstauglichkeit weit entfernt. Entsprechend verschieben sich die Nutzerzahlen bei den Anwender und Distributionen.

Weil KDE es nicht hinbekommt, die Destopumgebung und die zugehörigen Programme ausreichend zu stabilisieren und die Nachfrage sinkt, ziehen die Distributoren Konsequenzen. War KDE bei SUSE Linux Enterprise bereits im Jahr 2009 mit Version 11 optional geworden, fliegt es in Version 12 im Jahr 2014 komplett aus der Distribution. 2012 degradiert Canonical Kubuntu zu einem normalen Derivat, in der Folge verlässt Jonathan Riddel Canonical. Mandriva und seine diversen Nachfolgelösungen als KDE-Hochburg gerät ebenso in Schwierigkeiten und verliert nachhaltig an Bedeutung. Zuletzt gab im Jahr 2018 Red Hat bekannt, dass KDE nicht mehr in der Enterprise-Distribution RHEL enthalten sein würde. Linux-Desktops im professionellen bzw. Enteprise-Umfeld sind nun durchweg GNOME-Desktops. Wer hätte das 2006 gedacht.

Die KDE-Entwickler sehen diese katastrophale Entwicklung. Man startet man eine beispiellose Kampagne, um die letzte Hochburg von KDE als Standarddesktop zu bewahren: openSUSE. Es gelingt KDE als Standarddesktop durchzudrücken. Ein kurzer Erfolg, denn nach einigen Umstrukturierungen hat openSUSE von vielen unbemerkt wieder den Verzicht auf einen Standarddesktop beschlossen.

Im Zuge der Querelen zwischen Kubuntu und Canonical kommt man 2016 auf die Idee, mit KDE neon eine eigene Distribution zu erschaffen. Die letzten verblieben Distributoren mit KDE-Schwerpunkt sind nachhaltig irritiert durch diese Aktion. Ein großer Erfolg wird KDE neon nicht, sondern dient eher als Anschauungsbeispiel für die aktuelle KDE-Version.

2022 gibt es keine verbreitete Distribution mit KDE als Standarddesktop. Wichtige Linux-Distributionen wie Debian, Ubuntu oder Fedora setzen standardmäßig auf GNOME oder haben von GNOME abgeleitete Alternativen entwickelt, wie z. B. Mint oder Pop OS!. KDE-Software spielt vor allem bei Rolling Release Distributionen noch eine nennenswerte Rolle und erfreut sich bei Arch Linux und Manjaro einiger Beliebtheit. Zudem kann es natürlich optional bei vielen Distributionen genutzt werden. Hiermit steht es aber auf einer ähnlichen Stufe wie die Xfce, MATE, LXQt und andere kleinere Lösungen.

Für einen solchen Niedergang gibt es keine einfachen Erklärungen. Dahinter stehen sicherlich auch Entwicklungen außerhalb der Reichweite der KDE-Entwickler und Verschiebungen im Distributonssegment. Aber einige Punkte kann man dennoch feststellen:

  • Schlechte Kommunikation der Entwicklung in Richtung der Distributionen und Anwender.
  • Auf Kritik reagierten die KDE-Entwickler mit einer Wagenburg-Mentalität.
  • Aus der Wagenburg-Mentalität folgte das konsequente Ignorieren der Bedarfe von stabilen Distributionen und vor allem der LTS-Distributionen, die von der Masse der Anwender genutzt werden. Das hat zu einer nachhaltigen Entfremdung zwischen Distributionen und KDE geführt.
  • Aus der Wagenburg-Mentalität folgte das konsequente Ignorieren der Anwenderbedarfe nach einer halbwegs stabilen, logisch zu bedienenden Desktopumgebung. Das hat nachhaltig Anwender vertrieben. Wir erinnern uns an fehlende Icons auf dem Desktop, eine Erdnuss in der Desktopecke, ein bis heute wackeliges KDEPIM. Irgendwann sind die KDE-Entwickler meist eingeknickt, nachdem der Kollateralschaden bereits gewaltig war. KDE ist immer noch damit beschäftigt Anwender zurück zu gewinnen, die man nach 2008 verloren hat.
  • Die KDE-Entwickler haben sehr oft lieber tolle Konzepte entwickelt als an Funktionen für die Anwender gedacht. Wir erinnern uns an aRts, Phonon, Nepomuk, Sonnet, Akonadi, KDE Frameworks.
  • Zig Umbennenung von KDE zu KDE SC zu KDE Plasma, von KDE zu KDE Applications zu nichts und zurück zu KDE Gear waren sicherlich nicht hilfreich für das Marketing.

Im Grunde genommen ist das schade, weil KDE Plasma gegenwärtig eine sehr stabil und funktional gut zu benutzende Desktopumgebung ist. Viele der Programme aus dem KDE-Umfeld sind funktional allen anderen Alternativen im Linux-Bereich überlegen. Sofern man von einer manchmal irrlichternden VDG und ihren Missetaten absieht, liefert KDE heute eine tolle Desktopumgebung aus und diese wird natürlich weiter eine Zukunft haben.

Aber Entwicklungen lassen sich nicht umkehren und KDE wird nicht mehr die Bedeutung von 2006 erreichen. Als man sich am Ende des 4er-Releasezyklus hinsichtlich Funktionen und Qualität gefangen hatte, waren die Distributoren als wichtige Mittler zwischen Upstream und den Nutzern bereits umgeschwenkt oder die Anwender hatten sich andere Distributionen gesucht. Einmal verlorene Marktanteile zurückzugewinnen, ist ein sehr hartes Unterfangen. Zu viele im Open Source-Segment unterschätzen dies.

Zu viele Fehler, zu viele schlechte Entscheidungen und ein auf GNOME ausgerichtetes Gesamtökosystem haben sich zementiert. KDE wird es weiter geben, das Projekt liefert gute Software. In einem Atemzug mit GNOME muss man es aber vermutlich nicht mehr nennen.

Der Artikel KDE – Eine kleine Niedergangsgeschichte erschien zuerst auf [Mer]Curius

Adblock auf DNS-Ebene – Keine Werbung in Apps und Webseiten

15. Januar 2022 um 12:52
Von: Gerrit

Werbung und Tracker zu blockieren ist eines der wichtigsten Elemente zum Schutz der digitalen Privatsphäre. Am Desktop reicht dafür oft ein Adblocker im Browser. Durch die vielen Apps muss man bei Android oder iOS anders vorgehen.

Vorbemerkungen

In der Vergangenheit hatte ich hier im Blog bereits zwei Lösungen vorgestellt: Blokada für Android und AdGuard Pro für das iPhone. Beide setzen auf ein virtuelles VPN, um den Datenverkehr des Geräts filtern zu können. Bei Lösungen halte ich auch immer noch für mögliche Vorgehensweisen. Es gibt noch zahlreiche weitere Apps, die vergleichbare Funktionen bieten. Sie funktionieren aber nicht in jeder Situation, z. B. wenn man aus anderen Gründen VPN benötigt.

Es gibt aber auch ernste Implikationen durch solche Blocker, die man in seiner Entscheidungsfindung berücksichtigen sollte. Dazu aus den FAQ von GrapheneOS:

Apps and web sites can detect that ad-blocking is being used and can determine what’s being blocked. This can be used as part of fingerprinting users. Using a widely used service like AdGuard with a standard block list is much less of an issue than a custom set of subscriptions / rules, but it still stands out compared to the default of not doing it.

GrapheneOS FAQ, abgerufen am 15.01.2022

Das ist beileibe keine Minderheitenmeinung, sondern so funktioniert im Prinzip auch der Tor Browser. Durch massive Maßnahmen zum Blockieren von Inhalten verstärkt man faktisch auch den eigenen Fingerabdruck. Beim Tor Browser versucht man stattdessen in der Masse unterzugehen und die Trackingmaßnahmen dadurch ins Leere laufen zu lassen.

Nur möchte ich wie viele andere eben auch trotzdem keine Werbung haben und dazu empfiehlt GraphenOS den Einsatz eines Private DNS (DNS-over-TLP) Server mit Unterstützung für Adblocking.

Funktionsweise von Adblock via DNS

Das Prinzip dieser Lösung ist ziemlich einfach erklärt. Webseiten oder Apps kontaktieren zur Auslieferung von Werbung die Adresse der Werbenetzwerke. Genau wie normale Anwender, wenn sie im Internet surfen, rufen die Apps keine konkrete IP-Adresse auf, sondern eine Domain. Diese Aufrufe von Drittanbietern kennen die meisten durch die Anzeige von Addons wie ublock origin im Browser.

Diese Domain muss in eine IP-Adresse übersetzt werden und dafür kommt der DNS-Server (Domain Name System) als „Telefonbuch des Internets“ zum Einsatz. Das ist ein normaler Vorgang und passiert immer, wenn wir im Netz unterwegs sind. Normalerweise sind bei jedem im Router die DNS-Server des Internetanbieters zur korrekten Weiterleitung hinterlegt. Dafür kann man aber auch individuelle Server hinterlegen.

Normalerweise sind solche DNS-Server neutral und verweisen auf die korrekte Ziel-IP. DNS-Server sind aber in manchen Ländern auch ein Instrument, um unerwünschte Netzinhalte zu blockieren, indem z. B. durch den Staat eine Blacklist gepflegt wird, die nicht aufgelöst werden darf. Ich schreibe dies deshalb, weil die Frage, ob man DNS-Server für so etwas wie Adblocking verwenden sollte, durchaus umstritten ist und es Leute gibt, die finden, solche Dienste sollten strikt neutral sein und die entsprechenden Funktionen sollten anderweitig umgesetzt werden.

Adblock via DNS-Server funktioniert, indem man einen DNS-Anbieter wählt, der eben keinen neutralen Server betreibt, sondern eine Blacklist mit eben jenen Servern verwaltet, die Werbung und/oder Tracker ausliefern.

Dadurch stellen die Webseiten oder Apps nicht fest, dass etwas blockiert wird, sondern bekommen die Rückmeldung, dass die gewählte Adresse nicht erreichbar ist. Ein Vorgang, der auch aus anderen Gründen zeitweilig passieren kann.

DNS-Server Anbieter mit Adblock-Funktion

Es gibt einige Betreiber entsprechender DNS-Server. Einen besonders wichtigen Anbieter listet GrapheneOS in seinen FAQ. Eine kleine Liste von DNS-over-TLS oder DNS-over-HTTPS Betreibern kann man im Privacy-Handbuch finden. Folgende drei Anbieter möchte ich hier explizit nennen:

  1. Mullvad DNS: adblock.doh.mullvad.net (Kommerzieller Anbieter, der einen sehr beliebten und positiv bewerteten VPN-Dienst betreibt. DNS-Server kann kostenlos genutzt werden)
  2. AdGuard DNS: dns.adguard.com/dns-query (AdGuard ist ein kommerzieller Anbieter, der sich durch den Verkauf von Apps und Addons im Bereich des Adblock finanziert. Der DNS-Server kann kostenlos genutzt werden)
  3. dnsforge: dnsforge.de/dns-query (privater Anbieter, der sich mit Spenden finanziert. Die Blocklisten kann man transparent auf der verlinkten Webseiten einsehen)

Die Wahl des Anbieters ist letztlich eine persönliche Entscheidung und ich kann und will hier keine fundierte Empfehlung abgeben. Neben den drei hier gelisteten und sicherlich sehr populären Servern, kann man auch andere im Privacy-Handbuch verlinkte DNS-Server-Anbieter wählen.

Android-Nutzer haben hier die volle Auswahl. Anwender mit einem iPhone sollten einen DNS-Server-Betreiber wählen, der DNS-over-TLS anbietet. Das wäre z. B. dnsforge.

Einrichtung

Grundsätzlich kann man einen DNS-Server individuell für jeden Browser und jedes Desktopbetriebssystem konfigurieren. Hier empfehle ich aber eher, den DNS-Server bei Bedarf zentral im Router auszutauschen oder ein Pi-Hole einzurichten (aber achtet dabei die Privatsphäre der anderen Nutzer im Netzwerk). Bei mobilen Geräten ist man natürlich nicht immer im heimischen Netzwerk oder mit diesem über VPN verbunden und hier kann es deshalb sinnvoll sein, zentral einen eigenen DNS-Server mit entsprechender Adblock-Funktion zu hinterlegen.

Einrichtung unter Android

Android macht es seinen Anwender wie so oft leicht, solche Funktionen zu nutzen. Das ist definitiv eine der Stärken des Betriebssystems von Google.

Man navigiert in den Einstellungen in den Bereich Netzwerke & Internet:

Hier kann man im Punkt Privates DNS einen individuellen DNS-Server hinterlegen:

Einrichtung und iOS (iPhone)

Apple macht das etwas anders. Hier gibt es für solche Konfigurationen (und auch andere Sachen) sogenannte Profile. Dabei handelt es sich um Konfigurationsdateien mit der Endung .mobileconfig Zur Verwendung muss man mittels Safari die Seite des entsprechenden Dienstanbieters aufrufen und dort das Profil herunterladen. Bei dnsforge sind diese prominent auf der Seite verlinkt. Mit einem Klick auf Zulassen aktiviert man das Profil. Anschließend kann man in den Einstellungen die geladenen Profile ansehen und aktivieren.

Funktion prüfen

Die korrekte Funktionsweise lässt sich mit verschiedenen Checkseiten prüfen. Mullvad bietet hierfür z. B. eine eigene Seite namens Mullvad-Check an. Eine andere Möglichkeit wäre dnsleaktest.

Grundsätzlich sollten jetzt in keiner App und auf keiner Webseite mehr Werbung angezeigt werden.

Grenzen der Methode

Ein Problem von Adblock via DNS ist die geringe Konfigurierbarkeit. Entweder man nutzt den Dienst oder nicht. Wenn man Probleme mit Overblocking hat oder den Datenverkehr überwachen und granularer steuern möchte, sollte man auf alternative Methoden setzen.

Das zentrale Aussperren von Werbung und Trackern über einen solchen Dienst ist aber eine sehr taugliche Lösung für all jene, die gerne einmal etwas einrichten und es dann vergessen wollen.

Der Artikel Adblock auf DNS-Ebene – Keine Werbung in Apps und Webseiten erschien zuerst auf [Mer]Curius

KDE-Nutzer bei Debian aufgepasst!

14. Januar 2022 um 09:15
Von: Gerrit

Debian verliert einen wichtigen Leistungsträger und ist daran nicht unschuldig. KDE-Nutzer sollten zur Kenntnis nehmen, dass sich Norbert Preining zurückzieht.

Debian hat Probleme. Nicht nur die Sicherheit, nicht nur in den verknöchterten Strukturen, es knirscht an vielen Stellen. Seit Jahren treten jedes Jahr Projektleiter an mit großen Agenden und nichts passiert. Die Strukturen, die das Projekt stabilisieren sollten, scheinen jede Bewegung zu verhindern, oft dienen sie nur noch der Blockade durch Minderheiten, die irgendetwas aufhalten wollen und dann in mühsamen Prozessen überstimmt werden müssen.

Norbert Preining ist seit einiger Zeit die Säule der Paketierung von KDE in Debian. Ohne ihn hätte man die aktuelle Stable-Version nicht mit halbwegs aktuellen KDE-Paketen ausgeliefert worden. Nun hat Norbert Preining seinen Rückzug angekündigt. Zwischen ihm und dem Debian-Projekt bzw. Menschen im Debian-Projekt knirscht es ja seit Längerem, deshalb musste er auch bereits in der Vergangenheit viel seiner Arbeit in OBS auslagern.

Der Verlust für Debian ist gewaltig. Die Liste der Pakete und die sachliche Analyse von Norbert Preining machen das deutlich. Einiges hat sicher eine Zukunft, aber vor allem für alles, was mit KDE zu tun hat und für Cinnamon in Debian sieht es nun düster aus. Norbert Preining legt zudem den Finger in eine Wunde, die viele ignorieren. Die vielen „Gruppen“ bei der Paketbetreuung sind oft nur eine Illusion und letztlich steht dahinter oft nur ein aktiver Betreuer – wie bei vielen „Teamarbeiten“ eben sonst auch.

Die Geschichte erinnert mich an Michael Stapelberg und seinen Rückzug aus Debian 2019. Dieser ist übrigens genau wie Norbert Preining zu Arch Linux gewechselt, aber das nur am Rande.

Debian brüstet sich immer mit seinen vielen Maintainern und Entwicklern, aber die Zahl der Leistungsträger im Desktop-Bereich ist überschaubar und große Weggänge gehen unweigerlich zulasten der Aktualität und Qualität. Darunter leiden übrigens auch abgeleitete Distributionen, wenn sie die Pakete nur übernehmen und die betroffenen Bereiche nicht selbst paketieren. Das Problem reicht deshalb über Debian hinaus.

Debian hat ein Problem, auch wenn nun wieder alle Debian-Nutzer standhaft leugnen und böse Kommentare im Stil von „Ach, der Gerrit mag Debian nicht“ schreiben werden. Vor allem Anwender von KDE Plasma und Cinnamon sollten die Entwicklung von Debian Testing im Auge behalten und sich mental darauf vorbereiten, beim nächsten Stable-Release eine neue Heimat zu suchen und bis dahin hoffen, dass nichts sicherheitsrelevantes für die Versionen in Stable passiert. Denn mir ist nicht klar, wer dort nun noch verantwortlich zeichnet.

Nachtrag 14.01.2022:

Nun hat auch Ferdinand bei Linuxnews berichtet, der ja ein guter Kenner der Debian-Gemeinschaft ist. Dort finden sich auch die Informationen zum Ablauf der Degradierung vor einiger Zeit und was für Mechanismen bei Debian hinter den Kulissen laufen.

Der Artikel KDE-Nutzer bei Debian aufgepasst! erschien zuerst auf [Mer]Curius

Lesetipp: Apple zwischen Datenschutz und Marketing

13. Januar 2022 um 20:02
Von: Gerrit

Apple hat seit vielen Jahren Datenschutz und Privatsphäre als Kundeninteresse und damit als lohnenswerte Marketingstrategie erkannt. Doch wie viel Substanz steckt eigentlich dahinter?

Ich habe mich hier im Blog bereits häufiger wohlwollend damit beschäftigt und bekomme dafür dann auch immer viel Kritik. Apple = kommerziell, geldgeil, proprietär – da scheint bei vielen die rationale Abwägung auszusetzen.

Dabei ist das gar nicht nur meine Position, deshalb möchte ich in dieser Frage auf einen längeren Artikel dazu bei Dr. Datenschutz verweisen.

Dort werden die positiven Entwicklungen wie die Anti-Tracking-Strategie und sinnvolle Funktionen bei den Apps abgewogen gegen das Messen mit zweierlei Maß, wenn es um eigene Dienste geht. Hinzu kommt der Firmensitz in den USA und der immanente Datenabfluss. In manchen Bereichen kann die Realität zudem nicht mit den Versprechen mithalten, dazu zählen die Voreinstellungen und die Qualität der Verschlüsselung bei vielen Diensten.

Das Fazit ist dann auch entsprechend differenziert. Apple hat zweifellos einen Sinn für Datenschutz und es spielt auch immer wieder eine Rolle, aber es wird nicht bis ins Letzte effizient umgesetzt – vor allem wenn es um die eigenen Dienste geht.

Mein Punkt ist dann halt oft folgender: Google hat noch nicht mal einen Sinn für Datenschutz und das spielt bei Google immer nur eine Rolle, wenn man irgendwo wieder Apple hinterher eilt. Deshalb: Im Zweifel Apple-Hardware kaufen. Im mobilen Bereich haben wir ja fast nur die Wahl zwischen diesen beiden Polen.

Der Artikel Lesetipp: Apple zwischen Datenschutz und Marketing erschien zuerst auf [Mer]Curius

Lesetipp: Fedora Silverblue im Praxiseinsatz

13. Januar 2022 um 19:45
Von: Gerrit

Fedora Silverblue gehört zu den ambitionierten und gleichermaßen umstrittenen Projekten im Linux-Ökosystem. Read-only Dateisysteme, Flatpak, Container – alles dabei für einen kräftigen Shitstorm. Zum Glück gibt es auch rationalere Berichte.

Lennart Diener hat auf linuxnews zwei Artikel über seinen Langzeittest von Fedora Silverblue geschrieben:

Dabei kommt der Autor zu einem sehr differenzierten Bild. Das Problem sind – wenn man die ideologischen Scheuklappen ablegt – eher nicht die Flatpaks, sondern die mangelnde Stabilität der grafischen Paketmanager und die Notwendigkeit bei einem Update an der Betriebssystembasis immer neustarten zu müssen. Toolbox scheint zudem eine nette Idee zu sein, deren praktische Verwendung irgendwie noch nicht richtig klappt.

Ich empfehle beide Artikel. Viel davon kann ich nachvollziehen. Betriebssysteme mit Read-Only-Root-Dateisystem auf Basis von Ostree vertragen sich nicht so gut mit der Updatefrequenz von Fedora und die Oberfläche von GNOME ist halt wie sie ist.

Der Artikel Lesetipp: Fedora Silverblue im Praxiseinsatz erschien zuerst auf [Mer]Curius

Manjaro im Test – Rolling Release mit Sicherungsnetz

12. Januar 2022 um 20:34
Von: Gerrit

Manjaro ist im Rolling Release-Segment vielleicht das, was bei den stabilen Distributionen Linux Mint ist. Der Anspruch ist eine einfach zu verwendende, nutzerfreundlichen Distribution, selbst wenn es mal ideologisch oder konzeptionell nicht ganz sauber ist. Höchste Zeit für einen Test.

Einordnung

Manjaro ist eine sehr beliebte Distribution. Seit sie vor knapp 10 Jahren aus der Taufe gehoben wurde, hat sie immer mehr Anhänger gewonnen und es sieht nicht so aus, als ob sich das schnell ändern wird. Denn diese Beliebtheit hat Gründe, wie sich zeigen wird.

Manjaro ist ein Abkömmling von Arch Linux. Im Grunde genommen nehmen die Manjaro-Entwickler die Arch-Paketquellen und fügen einige eigene Pakete und Metapakete hinzu. Hinzu kommt eine Installationsroutine und eigene Live-Medien. Das Ganze wird dann ein wenig entschleunigt, denn während bei Arch mitunter mehrmals täglich Updates kommen, verfolgt Manjaro – ähnliche wie beispielsweise openSUSE Tumbleweed – ein Snapshot-Modell, bei dem Updates immer in einem größeren Schwung alle paar Tage/Wochen an den Anwender weiter gegeben werden. Idealerweise dann schon ein bisschen besser getestet als bei Arch, wo – wenn auch selten – mal ein kleiner oder größerer Fehler bei den hochfrequenten Updates erfolgen kann.

Arch-Nutzer sagen gerne, dass niemand Manjaro bräuchte, weil man alles mit Arch selbst erledigen könnte. So wie auch Ubuntu-Anhänger behaupten, niemand bräuchte Linux Mint und Debian-Anhänger finden gerne, dass sowieso alle Derivate von Debian überflüssig seien. Das ist eine ewige Diskussion. Letztlich finden die Distributionen Anhänger und das hat Gründe.

Manjaro mit KDE Plasma im Test

Varianten und Installationsmedien

Die Manjaro-Entwickler unterstützen offiziell die drei Desktopumgebungen Xfce, KDE Plasma und GNOME. Hinzu kommt Community-Support von Budgie bis Sway. Leider ist die Pantheon Shell nicht dabei, obwohl sie mittlerweile in Arch Linux angekommen ist. Für den Test entschied ich mich deshalb für KDE Plasma.

Es gibt Live-/Installationsmedien für alle Desktopumgebungen. Jeweils aufgeteilt in eine vollständige und eine minimale Variante. Hierbei ist zu beachten, dass die minimale Variante keineswegs so minimal ist. Wer sich ein bisschen mit Linux auskennt und seine Programme überwiegend selbst zusammen stellen möchte, der sollte sich für die minimale Variante entscheiden.

Installation

Manjaro beherrscht kein Secure Boot. Das ist bedauerlich und verglichen mit anderen Distributionen schade. Es ist aber auch nicht überraschend, da Arch Linux dieses ebenso nicht unterstützt. Daher muss man – so noch nicht geschehen – in den UEFI-Einstellungen vor der Installation Secure Boot abschalten.

Anschließend bootet das Live-Medium. Hier kann man wie üblich erst die Distribution testen oder gleich installieren. Als Installationsroutine verwendet Manjaro Calamares. Dabei handelt es sich um eine distributionsübergreifend verfügbare Installationsroutine, die sich zunehmender Beliebtheit erfreut.

Ich finde Calamares etwas sparsam bei den Funktionen, aber man bekommt damit die Installation hin. Seit meinem letzten Test von Calamares bei KDE neon hat man die Verschlüsselung offenkundig verbessert, womit mein schlimmster Kritikpunkt ausgeräumt ist.

Bei der Installation wähle ich mein persönlich präferiertes Setup mit einer unverschlüsselten Boot-Partition und einer verschlüsselten Btrfs-Partition ohne weitere Trennung in Root und Home. Die unverschlüsselte Boot-Partition nutze ich, da bei einer verschlüsselten Boot-Partition die Entsperrung von GRUB bei meinen Notebooks sehr lange dauert und der Sicherheitsgewinn den Komfortverlust nicht ausgleicht.

Manjaro verlangt bei der Installation neben der obligatorischen Anlage eines Benutzers auch die Vergabe eines root-Kennworts. Damit sträubt man sich gegen den Trend. Nachdem Ubuntu lange Jahre mit seinem sudo-Konzept allein auf weiter Flur stand, haben sich zuletzt Debian und Fedora dem angeschlossen und bieten ebenfalls die Möglichkeit den root-Account zu deaktivieren.

Die Installation ist dann schnell erledigt.

Erster Eindruck

Nach einem Neustart begrüßt den Anwender KDE-Plasma in einem angepassten Design Namens „Breath“.

Die Entwickler der Desktopumgebungen hassen das ja bekanntermaßen und GNOME bekämpft dies inzwischen aktiv, aber ich mag das gerne. Ich finde es schön, wenn Distributionen versuchen, ein gemeinsames Corporate Design über alle Desktopumgebungen zu legen und den Anwendern vermitteln „Du benutzt nicht irgendeine Distribution mit KDE Plasma, sondern Manjaro“. Wenn es einem nicht gefällt, kann man es ja ändern.

Die Softwareauswahl ist dann gar nicht so minimal und leider auch etwas inkonsistent. Neben Plasma und den wichtigsten KDE-Tools ist auch Firefox dabei. Warum ich aber Okular und Evince vorinstalliert brauche, erschließt sich mir nicht. Ebenso ist unter der Haube einiges an Gerümpel. Dazu zähle ich die vorinstallierte Multilib-Umgebung (Lib32-Bibliotheken), die auf dem System gar nicht benötigt werden und einiges weiteres.

Bei der Gelegenheit fragte ich mich mal wieder, warum Arch eigentlich als schlankes System gilt. Natürlich hat ein Setup mit meiner gewohnten KDE-Umgebung bei Arch bzw. Manjaro nur knapp 1000 Pakete, während es bei openSUSE oder debianoiden Systemen eher >2000 sind. Das liegt aber nicht daran, dass openSUSE oder Debian „fetter“ wären, sondern daran, dass die Arch-Paketierung ziemlich grobschlächtig ist. So enthält z.B. das Paket firewalld auch gleich die GTK-GUI zur Konfiguration oder pinentry alle Oberflächen, was bei openSUSE und Debian in eigene Pakete ausgelagert ist. Arch ist also sogar ganz im Gegenteil eher ziemlich fett. Dafür kann aber natürlich Manjaro nichts und ist letztlich auch eine Frage der Gewohnheit.

Nichtsdestoweniger sollten Anwender nach der Installation erst einmal aufräumen, unnützes entfernen und vielleicht auch manches nachinstallieren. So setzt Manjaro nach der Installation immer noch auf X.org und der Anwender muss die Wayland-Session erst nachinstallieren und aktivieren. Am Ende hat man dann aber eine konsistente Arbeitsumgebung, auf der sich weiter aufbauen lässt.

Manjaro macht vieles anders

Manjaro macht vieles anderes. Das reicht von Kleinigkeiten bis zu einem Rollback-System für das Betriebssystem. Beginnen wir mit den Kleinigkeiten. Der Screenshot zeigt es schon: Manjaro verwendet standardmäßig nicht die Bash, sondern zsh mit einem hübschen, aber durchaus eigenwilligen Design.

Ebenso eigene Wege geht man bei den verfügbaren Programmen. In den Paketquellen findet sich auch so etwas wie SoftMaker Office oder Vivaldi. Hier steht Pragmatismus und gute Angebote für die Anwender über ideologischen Abwägungen.

Natürlich kann man Manjaro ebenso wie Arch komplett auf der Kommandozeile administrieren. Im Unterschied zu Arch bietet man den Anwendern aber grafische Konfigurationswerkzeuge. Diese integrieren sich bei KDE durchaus ansehnlich in die Systemeinstellungen als sogenannte KCM. Dazu gehört die Hardwarekonfiguration, die grafische Installation von verschiedenen Kerneln und die Verwaltung von Sprachpaketen.

Zusätzlich kann man noch nette grafische Paketmanager wie Octopi einsetzen, das im Gegensatz zum vorinstallierten Pamac eine Qt-Oberfläche hat und sich gut in KDE Plasma integriert. Mit ein wenig Nacharbeit entsteht so ein konsistenter Desktop mit guten grafischen Verwaltungstools.

Wirklich besonders ist an Manjaro aber der konsequente Einsatz von Timeshift. Das Ganze funktioniert Out-of-the-Box mit bei einem Brtrfs-Dateisystem-Layout. Das legt die Manjaro Installationsroutine gleich mit einem passenden Subvolume-Schema an:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=1F65-2EB8                            /boot/efi      vfat    umask=0077 0 2
UUID=2da043ef-a76c-4a18-8e2e-27969be465f4 /boot          xfs     defaults,noatime 0 2
/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /              btrfs   subvol=/@,defaults,noatime,autodefrag,compress=zstd 0 0
/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /home          btrfs   subvol=/@home,defaults,noatime,autodefrag,compress=zstd 0 0
/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /var/cache     btrfs   subvol=/@cache,defaults,noatime,autodefrag,compress=zstd 0 0
/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /var/log       btrfs   subvol=/@log,defaults,noatime,autodefrag,compress=zstd 0 0

Timeshift legt nun vollautomatisiert regelmäßige Schnappschüsse des Systems an. Das Home-Subvolume wird dabei ausgeklammert, kann aber optional ebenfalls einbezogen werden. Dabei nutzt Timeshift die in Btrfs integrierte Schnappschussfunktion.

Geht mal etwas schief, kann man in GRUB einfach einen älteren Schnappschuss booten. Das klappt auch bei einer verschlüsselten System-Partition mit unverschlüsselter Boot-Partition. Hier ist man sogar openSUSE voraus, wo das dort zum Einsatz kommende Snapper mit diesem Setup nicht zurechtkommt.

Probleme und Kritik

Vor allem im Bereich der Sicherheit gibt es einige problematische Bereiche. Das erste sind die Verzögerungen bei den Updates. Hier müsste man schauen, ob sicherheitsrelevante Aktualisierungen schneller durch gereicht werden als normale Updates, bei denen es letztlich egal ist, ob sie eine Woche früher oder später kommen.

Deutlich negativer fällt da das Fehlen vieler Sicherheitsmaßnahmen auf (die Spannbreite dessen habe ich hier mal dargestellt), die anderswo bereits Standard sind. Nicht nur verzichtet man auf eine vorinstallierte Firewall wie z. B. firewalld oder ufw (beides kann man natürlich nachinstallieren). Man installiert noch nicht mal konsequent ein Sicherheitsframework wie AppArmor. Dies wird nur bei der vollständigen und nicht bei der minimalen Installation eingerichtet. Angesichts der alles andere als minimalen Ausstattung der Minimal-Version in anderen Bereichen ist das unverständlich. Das ist ansonsten doch schon ziemlicher Standard und kommt von Debian bis openSUSE überall zum Einsatz. Hier sehe ich deutliches Verbesserungspotenzial, zumal AppArmor natürlich in den Paketquellen vorhanden ist und vom Anwender eingerichtet werden kann. Bei der Zielgruppe werden das nur leider zu wenige tun.

Zusammengefasst

Manjaro macht einen richtig guten Eindruck. Ich bin selten nach einem Distributionstest so positiv überrascht. Manjaro liefert ein sehr rundes Gesamtpaket aus und mit ein bisschen Nacharbeit bekommt man ein wirklich gutes Desktopsystem.

Ich bin mit Arch Linux nie wirklich warm geworden, was zu einem guten Teil auch an der Community lag, die ich als arrogant und überheblich wahrgenommen habe. Manjaro baut zwar auf bewährten Arch-Prinzipien auf, macht aber vieles anders, manches besser und wirkt sehr sympathisch.

Manjaro ist eine Distribution, die es geschafft hat in die engere Wahl dessen, was ich so an Linux-Distributionen berücksichtige, aufgenommen zu werden.


Nachtrag vom 15.01.2022:

Präzisierung der Passage zu AppArmor wegen Unterschiede bei der Installation mit minimaler und vollständiger Variante.

Der Artikel Manjaro im Test – Rolling Release mit Sicherungsnetz erschien zuerst auf [Mer]Curius

Notizen – Es ist Joplin geworden

09. Januar 2022 um 15:05
Von: Gerrit

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.

Der Artikel Notizen – Es ist Joplin geworden erschien zuerst auf [Mer]Curius

Linux und Sicherheit – Transparenz als Gebot

09. Januar 2022 um 13:43
Von: Gerrit

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.

Der Artikel Linux und Sicherheit – Transparenz als Gebot erschien zuerst auf [Mer]Curius

Debian und Sicherheit – Die empfohlenen Tools liefern unvollständige Daten

09. Januar 2022 um 12:31
Von: Gerrit

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.

Insgesamt finde ich das höchst fragwürdig.

Der Artikel Debian und Sicherheit – Die empfohlenen Tools liefern unvollständige Daten erschien zuerst auf [Mer]Curius

Debian und Sicherheit – Risiko Rendering-Engines

08. Januar 2022 um 18:02
Von: Gerrit

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.

Debian Release Notes, abgerufen am 08.01.2022

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.

Der Artikel Debian und Sicherheit – Risiko Rendering-Engines erschien zuerst auf [Mer]Curius

Cookies sind tot – Was kommt danach?

07. Januar 2022 um 19:39
Von: Gerrit

Cookies als Trackinginstrument sind ein Auslaufmodell. Ausufernde Einwilligungspflichten der DSGVO, omnipräsente Banner und die technische Blockade von Drittanbietercookies in immer mehr Browsern macht eine Abkehr von der Technologie unausweichlich. Damit hört natürlich das Tracking nicht auf.

Cookies als Mittel zum Verfolgen von Nutzern durch das Internet, mit dem Ziel, den Nutzer wiederzuerkennen und sein Verhalten zu analysieren, meist mit dem Ziel möglichst passgenaue Werbung auszuspielen, ist ein Auslaufmodell. DSGVO, TTDSG, technische Blockaden durch Hersteller wie Apple, für das Thema sensibilisierte Nutzer – das Ende von Cookies hat viele Gründe.

Noch sind Cookies allerdings ein wichtigstes, vermutlich sogar noch das wichtigste Mittel der Trackingindustrie. Die verbreiteten Berichte über neue Technologien sollte man daher nicht zum Anlass nehmen, die alten Schutzmaßnahmen einzustellen. So wie die Seitenbetreiber bzw. die Trackingunternehmen zunehmend mehrgleisig fahren und alte neben neuen Methoden nutzen, so müssen auch die Anwender die alten Schutzmauern intakt halten, während sie bereits neue Barrieren bauen.

Es ist noch keineswegs ausgemacht, was Cookies als dominierende Methode ablösen wird. Googles erster Versuch im vergangenen Jahr scheiterte am geballten Widerstand der anderen Browserhersteller, CMS-Entwickler, Seitenbetreiber – alle waren dagegen. Das ändert natürlich nichts an Googles Bestrebungen.

Eine möglicherweise wichtige Rolle gewinnen sogenannte Identitätsprovider. Dazu möchte ich auf eine Recherche von Matthias Eberl verweisen. Eine kürzere und leichter zu lesende Variante findet sich in der SZ, die längere und technische Ausgabe im Kuketz-Blog. Sein Fazit, die Dienste sind noch kein Standard, aber bei vielen großen Seiten bereits zu finden.

Identitätsprovider sind Unternehmen, die zentral erfassen, wenn sich eine Person irgendwo im Netz einloggt und diese Information an die Werbeindustrie weitergeben. Als Identifier dient meist die E-Mail Adresse. Die Methode hat ganz nebenbei Potenzial, den feuchten Traum der Werbeindustrie zu erfüllen: Die Verknüpfung des Online- und Offline-Konsumverhaltens. Bisher sind diese Bereiche noch relativ stark getrennt, mit Identitätsprovidern könnte man dies stärker als bisher verknüpfen.

Die halbwegs positive Nachricht ist, dass die bekannten Gegenmaßnahmen teilweise weiter funktionieren: Blocker und aktives Vermeiden von Diensten, die sich über Werbung finanzieren. Rein rechtlich sind diese neuen Methoden genau so wie Cookies einwilligungspflichtig, weshalb sie sich in Cookie-Abfragen ablehnen lassen sollten (die Betonung liegt auf „sollten“…).

Neu hinzukommt ein sorgsamerer Umgang mit potenziellen Identifiern. Aktuell primär E-Mail-Adresse und Telefonnummer. Möglicherweise helfen hier Verschleierungsdienste, wie sie nun Apple und Mozilla Relay anbieten. Die alten Fronten von Unternehmen, die sich gegen Tracking stellen und ihr Geld anders verdienen und der Werbeindustrie würden dann wohl bestehen bleiben.

Der Artikel Cookies sind tot – Was kommt danach? erschien zuerst auf [Mer]Curius

Chromium – Einstellungen und Addons für digitale Privatsphäre

07. Januar 2022 um 17:58
Von: Gerrit

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.

Der Artikel Chromium – Einstellungen und Addons für digitale Privatsphäre erschien zuerst auf [Mer]Curius

Open Source Notizen mit Synchronisation?

07. Januar 2022 um 11:13
Von: Gerrit

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?

Der Artikel Open Source Notizen mit Synchronisation? erschien zuerst auf [Mer]Curius

Backup mit Borg und Vorta auf ein Synology NAS

07. Januar 2022 um 08:53
Von: Gerrit

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.

$ ssh -p <Portnummer> <benutzer>@<hostname>
z.B. $ ssh -p 26 gheim@synology218

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.

# mkdir -p /var/services/homes/borg-backup/.ssh
# touch /var/services/homes/borg-backup/.ssh/authorized_keys
# chown -R borg-backup:borg-backup /var/services/homes/borg-backup
# chmod 0700 /var/services/homes/borg-backup
# chmod 0700 /var/services/homes/borg-backup/.ssh
# chmod 0600 /var/services/homes/borg-backup/.ssh/*

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.

ssh -i ~/.ssh/id_ed25519 <benutzer>@<hostname> -p <portnummer>

Sollte es hier Probleme geben, können mittels folgendem Kommando erweiterte Debug-Informationen ausgegeben werden.

ssh -vvvT -i ~/.ssh/id_ed25519 <benutzer>@<hostname> -p <portnummer>

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:

ssh://<username>@domain:<port>/volume1/<freigabe>/ordner

z.B.

ssh://borg-backup@synology218:26/volume1/borgbackup/notebook

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.

Der Artikel Backup mit Borg und Vorta auf ein Synology NAS erschien zuerst auf [Mer]Curius

Mein Linux-Desktop – Teil 2

06. Januar 2022 um 20:22
Von: Gerrit

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.

Folgende Programme nutze ich auf dem Desktop:

AufgabeProgramm
OfficeSoftMaker Office 2021
ScannenVuescan
Finanzenmoneyplex
DokumentenbetrachterOkular
PDF-Bearbeitungauf dem System nicht notwendig
BildbearbeitungKrita
BildbetrachterGwenview & Digikam
NotizenSynology Notes
CloudSynology Drive
BrowserFirefox & Tor Browser Bundle
FeedreaderRSS Guard mit FreshRSS Sync
E-Mail, Kontakte und TerminorganisationKMail, KOrganizer
IRCKonversation
AufgabenKOrganizer
FTPKrusader
MusikVLC
VideoVLC
EditorKate
VirtualisierungVirtualBox
PasswortverwaltungKeePassXC
NavigationMarble
BackupBorg / Vorta
SonstigesDolphin, 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.

Der Artikel Mein Linux-Desktop – Teil 2 erschien zuerst auf [Mer]Curius

Grundlagen: Fakt, Meinung, Interpretation, Unwahrheit

02. Januar 2022 um 13:30
Von: Gerrit

Vielen Menschen scheint es schwerzufallen, Fakten (synonym: Tatsachen) von Meinungen und Interpretationen zu unterscheiden. Das ist vor allem in Diskussionen immer eine Herausforderung. Hier mal eine kurze Einführung.

Ich hätte nie gedacht, dass ich so einen Artikel mal schreiben muss, aber immer wieder bekommt man im Blog Kommentare, in denen mir vorgeworfen wird, ich solle nur Fakten berichten, die Beiträge wären voller Meinung und/oder ich könnte mit andere Meinungen nicht akzeptieren.

Das macht Diskussionen mühsam oder gar unmöglich. Dazu passend aus der APUZ:

Die Kompetenz, zwischen Meinung und Faktum unterscheiden zu können, ist aber nur eine Voraussetzung für einen sachlich fundierten Diskurs; dazu muss die Bereitschaft treten, überhaupt differenzieren zu wollen.

Faktum = Meinung? in: APUZ 12-13/2020

Fakt

Der oder das Fakt[um] (synonym: Tatsache, Wirklichkeit) ist eine Tatsache, die belegt werden kann. Also zum Beispiel durch Zahlen, eine exakte Zustandsbeschreibung oder eine objektive Begründung. Einen Fakt kennzeichnet, dass überprüft, gezeigt, demonstriert werden kann.

Beispiele für Fakten:

  • Linux-Distributionen nutzen den Linux-Kernel
  • GNU steht für das rekursive Akronym „GNU’s Not Unix“
  • SUSE ist im Jahr 2021 an die Börse gegangen.
  • Im April 2022 erscheint eine neue LTS Version von Ubuntu

Nicht-Fakt: Meinung oder Interpretation

Von Fakten zu unterscheiden sind Meinungen oder Interpretationen. Dabei handelt es sich um Ansichten, die auf persönlichen Erlebnissen und Wahrnehmungen beruhen. Der Verfasser hält sie für sinnvoll oder wahr, sie lässt sich aber nicht objektiv beweisen. Meinungen basieren auf unterschiedlichen Erfahrungsräumen, die einen unterschiedlichen Erwartungshorizont erzeugen. Man kann deshalb die Meinung eines Diskussionsteilnehmers nicht ablehnen oder korrigieren.

Beispiele für Meinungen:

  • Ich finde GNOME ist eine schlechte Desktopumgebung
  • Ubuntu wird jedes Jahr schlechter
  • Jeder weiß, Flatpaks sind besser als Snaps
  • „immutable“ Systeme sind die Zukunft unter Linux

Nicht-Fakt: Unwahrheit, Lüge, „Fake-News“

Eine weitere Kategorie von „Nicht-Fakten“ sind unwahre Informationen, also Lügen, heute oft als „Fake-News“ bzw. einfach „Fake“ tituliert. Dabei handelt es sich nicht um eine Meinung oder eine Interpretation, sondern um eine (bewusste) Lüge. Durch digitale Verbreitungsmethoden sind Meinungen heute viel präsenter als früher und Medien wie Ton und Videos sind gut geeignet, emotionale Ansichten ohne Faktenbasis zu verbreiten.

Unwahrheiten sind von Meinungen oder Interpretationen zu unterscheiden, da Meinungen oder Interpretationen eine unterschiedliche Auslegung der gleichen Faktenlage oder die Darstellung einer persönlichen, aber nicht objektivierbaren Wahrnehmung ist. Unwahrheiten basieren jedoch nicht auf „Fakten“, sondern sind nicht belegbare Behauptungen. Diese Lücke hat eine Beraterin von Präsident Trump mal mit dem Terminus der „alternativen Fakten“ schließen wollen.

Unwahrheiten, Lügen oder „Fake-News“ muss man im Gegensatz zu Meinungen oder Interpretationen der gleichen Faktenbasis nicht einfach hinnehmen, da sie den sachlich fundierten Diskurs unterminieren.

Beispiele für unwahre Informationen:

  • Ubuntu zwingt den Anwendern Snaps auf
  • Microsoft verhindert mit Korruption die Verbreitung von Linux in der öffentlichen Verwaltung
  • Windows ist ein UNIX-Betriebssystem
  • Freie Software wird nur von ehrenamtlicher Entwicklungsarbeit erstellt
  • Linux ist 50 Jahre alt

Exkurs: Medium Blog

Ein Weblog, kurz Blog, ist eine Tagebuch-artig geführtes, öffentlich zugängliches Medium, das ständig um Ergänzungen und Kommentare zu einem mehr oder minder spezifischen Thema ergänzt wird.

Ein Blog ist ein Meinungsmedium. Darin unterscheidet es sich von einem Lexikon oder auch Wiki, das lediglich objektive Informationen wiedergibt. Die Forderung an einen Blogger, bitte ausschließlich Fakten wiederzugeben, ist folglich absurd und zeugt von Unkenntnis über den Unterschied zwischen Fakt und Meinung. Blogs sind in der Regel sogenannte Ich-Medien mit einem einzigen Autor oder einer kleinen Gruppe von Autoren. Im Unterschied zu Medien wie Zeitschriften, Zeitungen oder Online-Magazinen gibt es keinen Anspruch auf eine ausgewogene Berichterstattung.

Blogs sind zudem in chronologisch sortierte Beiträge gegliedert. Informationen und Meinungen können durch neue Erkenntnisse oder Fakten überholt werden. Es besteht im Unterschied zu einem Lexikon oder Wiki kein Anspruch auf eine Aktualisierung der alten Beiträge.

Der Artikel Grundlagen: Fakt, Meinung, Interpretation, Unwahrheit erschien zuerst auf [Mer]Curius

Experiment: elementary OS mit Flatpak zum Jahresabschluss

31. Dezember 2021 um 15:48
Von: Gerrit
  1. Experiment: elementary OS 6 mit Flatpaks
  2. Experiment: Licht und Schatten bei elementary OS
  3. 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.

Der Artikel Experiment: elementary OS mit Flatpak zum Jahresabschluss erschien zuerst auf [Mer]Curius

„Flatpak Is Not the Future“ – Eine knappe Analyse

30. Dezember 2021 um 13:38
Von: Gerrit

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.

Der Artikel „Flatpak Is Not the Future“ – Eine knappe Analyse erschien zuerst auf [Mer]Curius

Windows 11 – Erstaunlich gelungenes Gesamtpaket

30. Dezember 2021 um 11:04
Von: Gerrit

Windows ist nach wie vor das wichtigste Desktopbetriebssystem. Wie wenig Aufmerksamkeit die neue Version 11 erhielt, sagt daher auch einiges darüber aus, wie wenig Bedeutung der Desktop- bzw. Notebooksektor noch hat. Dennoch liefert Microsoft ein erstaunlich gelungenes Gesamtkonzept aus.

Windows ist kein System, dem ich in den letzten Jahren viel abgewinnen konnte. Dennoch ist es letztlich für die meisten ein steter Begleiter. Linux oder macOS mag man privat nutzen, aber nur die wenigsten kommen im Arbeitsleben ohne Microsoft Windows aus. Als nun das Upgrade auf Windows 11 anstand, hatte ich ehrlich gesagt keine Erwartungen daran und außer „die Fensterleiste ist nun standardmäßig zentriert“ aus der Berichterstattung auch nichts mitgenommen. Umso erfreulicher war dann das Erlebnis nach abgeschlossener Aktualisierung.

Windows hat mit dem so titulierten Fluent Design eine völlig neue Designsprache erhalten. Dabei handelt es sich natürlich um eine Fortentwicklung bisheriger Prinzipien, aber der Bruch zu Windows 10 ist schon sehr deutlich. Die Icons für viele Bereiche wurden komplett überarbeitet und die Listen und Kontextmenüs deutlich aufgelockert und neu designt. Optisch nähert man sich ein wenig macOS an, ohne jedoch eine billige Kopie zu erstellen.

Erstmals seit Windows 7 hat man nun auch wieder ein weitestgehend konsistentes Design für das komplette Betriebssystem. Von der Shell über zentrale Applikationen wie den Dateiexplorer bis hin zu den Einstellungen.

Dabei handelt es sich keineswegs um rein kosmetische Änderungen, sondern die Bedienelemente wie Menüs und Kontextmenüs wurden deutlich entschlackt, intuitiver und übersichtlicher gestaltet.

Deutlich aufgewertet hat Microsoft den Store, über den sich nun auch herkömmliche Programme installieren lassen. Was die Auswahl betrifft, ist hier sicher noch Luft nach oben, aber für Windows-Nutzer essenzielle Applikationen wie Firefox, Adobe Reader, TeamViewer etc. sind verfügbar. Das gilt ebenso für das neue Office 2021 – auch in der Einmalkauf-Variante. Dadurch ist die Installation und Aktualisierung der Programme viel einfacher und Windows nähert sich hier macOS und Linux an. Eine sehr erfreuliche Entwicklung.

Sachen, die schon unter Windows 10 und seinen Vorgängern gut funktioniert haben, bleiben natürlich erhalten. Was z. B. den Multimonitor-Betrieb betrifft, ist Windows allen Linux-Desktopumgebungen und auch macOS haushoch überlegen. Bei diesen kritischen Funktionen für den Business-Betrieb hat man bei Microsoft immer zugesehen, auf der Höhe der Zeit zu bleiben. Schließlich sitzen dort die Kunden.

Unter der Haube bleibt Windows 11 deshalb auch weiterhin das alte Windows NT mit seinen über 20 Jahren Entwicklungszeit auf dem Buckel. Tief im Menü vergraben findet man z. B. auch noch die klassischen Systemeinstellungen. Die Neukonzeption unter dem Namen Windows 10X hatte man im Frühjahr endgültig beerdigt. Microsoft hat sich aber sichtlich Mühe gegeben, Windows 11 zu entschlacken, ein konsistentes Äußeres zu verpassen und die schlimmsten Wildwüchse aus Windows 10 zu beseitigen. Ein Blick in die Systemordner auf C: offenbart daher das übliche Dateischema mit all seinen Widersprüchen. Keine Nachteile ohne Vorteile, denn unter Windows 11 werden die meisten alten Programme lauffähig bleiben. Etwas, wovon Linux- und macOS-Nutzer nur träumen können. Puristen und Fans von „cleanen“ Systemen ist das sicherlich ein Graus, aber den normalen Windows-Nutzer dürfte es freuen.

Windows 11 ist definitiv eine positive Überraschung und zeigt, wie man eine Oberfläche gelungen neu gestaltet kann, ohne sich in übertriebenen Reduktionismus zu ergehen. Davon könnte sich beispielsweise KDE einiges abschauen, die sich ja von der Bedienlogik immer eher an Windows als an macOS orientiert haben und wo sich die Entwickler in den letzten Jahren eher in tief verschachtelten Menüs und Einstellungen verlaufen haben.

Leider bleiben die problematischen Entwicklungen von Windows 10 erhalten. Ohne Microsoft-Konto lässt sich Windows 11 für Privatnutzer kaum noch komfortabel betreiben, Telemetriedaten erhebt das System reichlich und nicht völlig abschaltbar und der Schadsoftwaredruck auf Windows bleibt hoch. Für mein Arbeitsgerät ist mir das egal, privat würde ich es eher nicht verwenden.

Der Artikel Windows 11 – Erstaunlich gelungenes Gesamtpaket erschien zuerst auf [Mer]Curius

Lesetipp: Digitale Mündigkeit fängt klein an

27. Dezember 2021 um 19:31
Von: Gerrit

Wenn man sich das erste Mal mit den Themen Datenschutz und Privatsphäre im digitalen Alltag befasst und hinein in den Kaninchenbau des Schreckens steigt, weiß man oft gar nicht, wo genau man bei sich selbst anfangen soll. Immer schön zu wissen, dass es auch anderen so ergeht.

Vermeintliche Experten, die sich selbst im Netz als Lichtgestalten inszenieren, sind mir ja bekanntermaßen schon länger ein Dorn im Auge. Zu oft beschleicht mich der Eindruck, dass man hier nur eine Seite präsentiert bekommt und die Schatten und Grauzonen großzügig ausgespart werden. Genau deshalb schreibe ich ja ein Mal pro Jahr über das, was ich so persönlich nutze.

Umso erfreuter war ich über das heute erschienene Interview mit Katharina Larisch, Volker Wittpahl und Klaudia Zotzmann-Koch auf netzpolitik.org. Denn dort inszenieren sich keine Lichtgestalten, sondern es gibt einen schönen Einblick in die Mühen der Ebene beim Schutz der digitalen Privatsphäre und dass alle mal klein anfangen.

Ebenso der Hinweis auf die „Quick Wins“ am Anfang, mit denen man auch schon viel erreicht, bevor man in die tiefsten Tiefen des technischen Privatsphärenschutzes eintaucht. Manchmal kann es sogar klug sein, einen Schritt zurück zu machen und z. B. auf ein Hosted-Service zurückzugreifen. Denn Datenschutz ist nicht weit her, wenn mangels Zeit oder Kenntnisse die Sicherheit nicht gewährleistet werden kann.

Der Artikel Lesetipp: Digitale Mündigkeit fängt klein an erschien zuerst auf [Mer]Curius

iodéOS – Das bessere /e/OS?

23. Dezember 2021 um 14:35
Von: Gerrit

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.

Der Artikel iodéOS – Das bessere /e/OS? erschien zuerst auf [Mer]Curius

GrapheneOS – Updates ohne Risiko

22. Dezember 2021 um 14:01
Von: Gerrit

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.

Der Artikel GrapheneOS – Updates ohne Risiko erschien zuerst auf [Mer]Curius

Apple integriert App-Datenschutz-Bericht in iOS 15.2

22. Dezember 2021 um 13:08
Von: Gerrit

Apple verfolgt seit Längerem den Ansatz, Tracking durch aktive Maßnahmen und Transparenz zu bekämpfen. In der neuen iOS Version hat man dazu den Datenschutz-Bericht nachgerüstet.

Das Prinzip der radikalen Transparenz verfolgt Apple schon länger. Es ist ein weiterer Baustein in Apples Maßnahmen gegen Tracking der Anwender. Der andere wichtige Baustein ist der Zwang für App-Entwickler aktiv die Einwilligung für Maßnahmen einzuholen. Beides ist ein großes Problem für Werbebetreiber und senkt deren Gewinne erheblich. Denn die meisten Anwender stehen den Maßnahmen ablehnend gegenüber und werden sie damit konfrontiert, lehnen sie entweder ab oder wandern zu anderen Angeboten ab.

Eine weitere Maßnahme in diese Richtung ist nun der Datenschutz-Bericht in iOS 15.2 (engl. App Privacy Report). Im Gegensatz zu der Funktion in Safari geht es nicht nur um Tracker, sondern auch um Zugriffe auf Sensordaten.

Aktiviert wird die Funktion in den Einstellungen unter Datenschutz und App-Datenschutz-Bericht.

Zwar zeigt die Funktion nicht den Inhalt der übertragenen Daten, wohl aber die Aufrufe und das reicht oft schon als Aussage. Durch solche Maßnahmen steigt der Druck auf App-Entwickler, ihre Apps sauber zu programmieren und nicht unreflektiert irgendwelche Bausteine zu integrieren, die sie nicht kontrollieren oder lediglich Alibi-Einwilligungen einzuholen, während im Hintergrund bereits Daten fließen.

Diese Verbindungen lassen sich im Datenschutz-Bericht übrigens nicht blockieren. Um systemweites Tracking auf dem iPhone zu blockieren, bietet sich die App AdGuard Pro an.

Damit geht Apple mal wieder einen Schritt weiter als Google, das zwar in Android 12 ein Privatsphäredashboard integriert hat. Dieses beschränkt sich aber mal wieder auf Sensor-Daten und klammert Datenübertragung aus. Warum kann sich wohl jeder denken: Google wird bei Datenschutz getrieben durch Apple und setzt immer nur das absolut Nötigste um.

Der Artikel Apple integriert App-Datenschutz-Bericht in iOS 15.2 erschien zuerst auf [Mer]Curius

❌