(236) [Mer]Curius · y0o.de · GNU/Linux Nachrichten u.Ä.\nIm 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.\nDas 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.\nNoch 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.\nDie 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.\nDas 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.\nKubuntu 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.\nUbuntu 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.\nWenig 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.\nInsgesamt 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.\nDer Artikel (x)Ubuntu 22.04 (Jammy Jellyfish) im Ausblick erschien zuerst auf [Mer]Curius\nKDE – Eine kleine Niedergangsgeschichte\nDas 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.\nKDE 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.\nBei 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.\nWir 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.\nIm 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.\n2006 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.\nDanach 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.\nEwig 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.\nWeil 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.\nDie 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.\nIm 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.\n2022 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.\nFü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:\nSchlechte Kommunikation der Entwicklung in Richtung der Distributionen und Anwender.\nAuf Kritik reagierten die KDE-Entwickler mit einer Wagenburg-Mentalität.\nAus 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.\nAus 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.\nDie 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.\nZig 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.\nIm 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.\nAber 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.\nZu 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.\nDer Artikel KDE – Eine kleine Niedergangsgeschichte erschien zuerst auf [Mer]Curius\nWerbung 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.\nIn 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.\nEs gibt aber auch ernste Implikationen durch solche Blocker, die man in seiner Entscheidungsfindung berücksichtigen sollte. Dazu aus den FAQ von GrapheneOS:\nApps 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.\nGrapheneOS FAQ, abgerufen am 15.01.2022\nDas 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.\nNur 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.\nFunktionsweise von Adblock via DNS\nDas 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.\nDiese 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.\nNormalerweise 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.\nAdblock 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.\nDadurch 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.\nDNS-Server Anbieter mit Adblock-Funktion\nEs 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:\nMullvad DNS: adblock.doh.mullvad.net (Kommerzieller Anbieter, der einen sehr beliebten und positiv bewerteten VPN-Dienst betreibt. DNS-Server kann kostenlos genutzt werden)\nAdGuard 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)\ndnsforge: dnsforge.de/dns-query (privater Anbieter, der sich mit Spenden finanziert. Die Blocklisten kann man transparent auf der verlinkten Webseiten einsehen)\nDie 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.\nAndroid-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.\nGrundsä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.\nAndroid macht es seinen Anwender wie so oft leicht, solche Funktionen zu nutzen. Das ist definitiv eine der Stärken des Betriebssystems von Google.\nMan navigiert in den Einstellungen in den Bereich Netzwerke & Internet:\nHier kann man im Punkt Privates DNS einen individuellen DNS-Server hinterlegen:\nEinrichtung und iOS (iPhone)\nApple 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.\nDie 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.\nGrundsätzlich sollten jetzt in keiner App und auf keiner Webseite mehr Werbung angezeigt werden.\nEin 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.\nDas 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.\nDer Artikel Adblock auf DNS-Ebene – Keine Werbung in Apps und Webseiten erschien zuerst auf [Mer]Curius\n14. Januar 2022 um 09:15\nDer Artikel KDE-Nutzer bei Debian aufgepasst! erschien zuerst auf [Mer]Curius\nApple hat seit vielen Jahren Datenschutz und Privatsphäre als Kundeninteresse und damit als lohnenswerte Marketingstrategie erkannt. Doch wie viel Substanz steckt eigentlich dahinter?\nIch 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.\nDabei ist das gar nicht nur meine Position, deshalb möchte ich in dieser Frage auf einen längeren Artikel dazu bei Dr. Datenschutz verweisen.\nDort 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.\nDas 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.\nMein 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.\nDer Artikel Lesetipp: Apple zwischen Datenschutz und Marketing erschien zuerst auf [Mer]Curius\n13. Januar 2022 um 19:45\nDer Artikel Lesetipp: Fedora Silverblue im Praxiseinsatz erschien zuerst auf [Mer]Curius\nManjaro 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.\nManjaro 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.\nManjaro 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.\nArch-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.\nManjaro mit KDE Plasma im Test\nVarianten und Installationsmedien\nDie 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.\nEs 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.\nManjaro 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.\nAnschließ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.\nIch 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.\nBei 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.\nManjaro 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.\nDie Installation ist dann schnell erledigt.\nNach einem Neustart begrüßt den Anwender KDE-Plasma in einem angepassten Design Namens „Breath“.\nDie 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.\nDie 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.\nBei 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.\nNichtsdestoweniger 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.\nManjaro macht vieles anders\nManjaro 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.\nEbenso 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.\nNatü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.\nZusä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.\nWirklich 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:\nUUID=1F65-2EB8                            /boot/efi      vfat    umask=0077 0 2\nUUID=2da043ef-a76c-4a18-8e2e-27969be465f4 /boot          xfs     defaults,noatime 0 2\n/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /              btrfs   subvol=/@,defaults,noatime,autodefrag,compress=zstd 0 0\n/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /home          btrfs   subvol=/@home,defaults,noatime,autodefrag,compress=zstd 0 0\n/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /var/cache     btrfs   subvol=/@cache,defaults,noatime,autodefrag,compress=zstd 0 0\n/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /var/log       btrfs   subvol=/@log,defaults,noatime,autodefrag,compress=zstd 0 0\nTimeshift 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.\nGeht 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.\nVor 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.\nDeutlich 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.\nManjaro 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.\nIch 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.\nManjaro ist eine Distribution, die es geschafft hat in die engere Wahl dessen, was ich so an Linux-Distributionen berücksichtige, aufgenommen zu werden.\nNachtrag vom 15.01.2022:\nPräzisierung der Passage zu AppArmor wegen Unterschiede bei der Installation mit minimaler und vollständiger Variante.\nDer Artikel Manjaro im Test – Rolling Release mit Sicherungsnetz erschien zuerst auf [Mer]Curius\n09. Januar 2022 um 15:05\nVor 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.\nInteressant 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.\nOhne 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.\nDie 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.\nAus 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.\nÜ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.\nDer Artikel Notizen – Es ist Joplin geworden erschien zuerst auf [Mer]Curius\n09. Januar 2022 um 13:43\nLinux 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.\nAnlä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.\nDie 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.\nMeiner 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.\nAber wenn es eine Einschränkung gibt, dann muss diese für den Anwender transparent sein! Transparenz kann man auf unterschiedliche Art herstellen:\nRadikale 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.\nEinen 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.\nSUSE 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.\nDie 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.\nOffene 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.\nOpen 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.\nDas 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.\nDer Artikel Linux und Sicherheit – Transparenz als Gebot erschien zuerst auf [Mer]Curius\n09. Januar 2022 um 12:31\nDies ist Beitrag 6 von 6 der Serie “Debian und Sicherheit”\nDebian 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.\nFü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.\nDas 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:\nFolgende Ausgabe erhalte ich für das oben beschrieben System.\nEinzelheiten: Only suitable for trusted content; see https://lists.debian.org/msgid-search/87lfqsomtg.fsf@mid.deneb.enyo.de\n- binutils (installierte Version: 2.35.2-2)\n- binutils-common:amd64 (installierte Version: 2.35.2-2)\n- binutils-x86-64-linux-gnu (installierte Version: 2.35.2-2)\n- libbinutils:amd64 (installierte Version: 2.35.2-2)\n- libctf-nobfd0:amd64 (installierte Version: 2.35.2-2)\n- libctf0:amd64 (installierte Version: 2.35.2-2)\n- libqt5webengine-data (installierte Version: 5.15.2+dfsg-3)\n- libqt5webengine5:amd64 (installierte Version: 5.15.2+dfsg-3)\n- libqt5webenginecore5:amd64 (installierte Version: 5.15.2+dfsg-3)\n- libqt5webenginewidgets5:amd64 (installierte Version: 5.15.2+dfsg-3)\n- qml-module-qtwebengine:amd64 (installierte Version: 5.15.2+dfsg-3)\nDiese 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.\nDas 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.\nInsgesamt finde ich das höchst fragwürdig.\nDer Artikel Debian und Sicherheit – Die empfohlenen Tools liefern unvollständige Daten erschien zuerst auf [Mer]Curius\n08. Januar 2022 um 18:02\nDies ist Beitrag 5 von 6 der Serie “Debian und Sicherheit”\nDebian 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.\nDie 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.\nEinige 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.\nIn den Release Notes schreibt Debian:\nDebian 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.\nDebian Release Notes, abgerufen am 08.01.2022\nDas 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.\nBesonders 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.\nDas 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.\nDas 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.\nGibt 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\nEs gibt also nur zwei Möglichkeiten. Die openSUSE-Changelogs listen zu viele Probleme oder Debian führt seine Liste der Sicherheitsprobleme nicht vollständig.\nWie 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.\nOb das bei den laut Release Notes unterstützten webkit2gtk-Paketen besser ist, habe ich nicht geprüft.\nIch würde mich freuen, wenn jemand das entkräften würde.\nDer Artikel Debian und Sicherheit – Risiko Rendering-Engines erschien zuerst auf [Mer]Curius\n07. Januar 2022 um 19:39\nCookies 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.\nCookies 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.\nNoch 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.\nEs 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.\nEine 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.\nIdentitä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.\nDie 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“…).\nNeu 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.\nDer Artikel Cookies sind tot – Was kommt danach? erschien zuerst auf [Mer]Curius\n07. Januar 2022 um 17:58\nChromium 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.\nGrundsä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.\nDaneben 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.\nLeider 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.\nChromium ist eng mit Google verbandelt, aber auch hier kann man einige Maßnahmen ergreifen um seine digitale Privatsphäre ein wenig zu schützen.\nGoogle und Ich: Synchronisierung und Google-Dienste abschalten\nDatenschutz und Sicherheit: Cookies und andere Webseitendaten –> Drittanbieter-Cookies blockieren\nDatenschutz und SIcherheit: Safe-Browsing deaktivieren (Hört sich absurd an, aber der Mehrwert ist gering, der Datenabfluss an Google groß)\nDatenschutz und Sicherheit: Privacy-Sandbox –> Alle Funktionen wie FloC abschalten.\nSuchmaschine: Ändern auf eine Datenschutz-freundliche Suchmaschine. Ich persönlich bevorzuge DuckDuckGo.\nDas Addon-Ökosystem von Firefox und Chrome/Chromium ist ziemlich ähnlich. Um den Google Web Store für die Installation kommt man leider nicht herum.\nublock origin: Inhalteblocker, um Tracker und Werbung zu blockieren. Mit optionalen Zusatzlisten, um bei Bedarf noch umfangreicher Inhalte zu filtern.\nLocalCDN: 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.\nCookie 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.\nChromium 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.\nDer Artikel Chromium – Einstellungen und Addons für digitale Privatsphäre erschien zuerst auf [Mer]Curius\n07. Januar 2022 um 11:13\nDer Artikel Open Source Notizen mit Synchronisation? erschien zuerst auf [Mer]Curius\n07. Januar 2022 um 08:53\nZur 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.\nDer Artikel Backup mit Borg und Vorta auf ein Synology NAS erschien zuerst auf [Mer]Curius\n06. Januar 2022 um 20:22\nBei 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.\nDer Artikel Mein Linux-Desktop – Teil 2 erschien zuerst auf [Mer]Curius\n02. Januar 2022 um 13:30\nDer Artikel Grundlagen: Fakt, Meinung, Interpretation, Unwahrheit erschien zuerst auf [Mer]Curius\n31. Dezember 2021 um 15:48\nDies ist Beitrag 3 von 3 der Serie “elementary OS 6 mit Flatpak”\nZum 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.\nDas 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.\nDas 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:\nSonstiges: Taschenrechner, Bildschirmfoto, Kamera etc. pp.\nAlso ein ziemlich normales 08/15 Office-Setup.\nEinzige 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.\nDas 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.\nDie 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.\nDas 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.\nProbleme 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.\nInteressant 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.\nDer Artikel Experiment: elementary OS mit Flatpak zum Jahresabschluss erschien zuerst auf [Mer]Curius\n30. Dezember 2021 um 13:38\nIn „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“.\nEigentlich 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.\nEinige 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.\nFlatpaks und Snaps sollen die klassische Paketverwaltung nicht vollumfänglich ersetzen. Niemand hat das nirgendwo gefordert.\nEs 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.\nDie 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.\nDie 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.\nKonzepte 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.\nFlatpak Is Not the Future – Die Kernargumente im Detail\nWarnung: Es könnte etwas knapp und leicht polemisch werden.\nIch 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.\nUnter 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.\nDas 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.\nDanach 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…\nBei „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.\nBei „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.\nDanach 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.\nWoher 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.\nUnter „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.\nUnter „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?\nDer Autor sieht hinter allen Lösungen sowieso nur den kommerziellen Masterplan „App Stores“ unter Linux zu verbreiten.\nIm 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.\nDanach 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.\nAm 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.\nUnzweifelhaft 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.\nFlatpaks, 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.\nEine 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.\nDas Konzept selbst ist aber in der Welt und wird nicht mehr verschwinden.\nDer Artikel „Flatpak Is Not the Future“ – Eine knappe Analyse erschien zuerst auf [Mer]Curius\nDer Artikel Windows 11 – Erstaunlich gelungenes Gesamtpaket erschien zuerst auf [Mer]Curius\n27. Dezember 2021 um 19:31\nWenn 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.\nVermeintliche 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.\nUmso 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.\nEbenso 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.\nDer Artikel Lesetipp: Digitale Mündigkeit fängt klein an erschien zuerst auf [Mer]Curius\n23. Dezember 2021 um 14:35\nIn 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.\nWas ist iodéOS\niodé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.\nÄ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.\niodé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.\nSystem und Ersteinrichtung\nNach 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.\nVerweis auf LineageOS\nDie 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.\nOptisch bietet das System ein normales AOSP-Erscheinungsbild, wie es bei LineageOS und Android 11 üblich ist.\nEs bleibt halt das Problem der Aktualität:\nNeben 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.\nInsgesamt 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.\nEine 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.\niodé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.\nWas iodéOS gänzlich fehlt ist der Versuch das Google-Ökosystem zu ersetzen, wie /e/ dies mit der eCloud unternimmt.\nInsgesamt 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.\nWer 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.\nDer Artikel iodéOS – Das bessere /e/OS? erschien zuerst auf [Mer]Curius\n22. Dezember 2021 um 14:01\nDies ist Beitrag 5 von 5 der Serie “GrapheneOS”\nDer Artikel GrapheneOS – Updates ohne Risiko erschien zuerst auf [Mer]Curius\nApple 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.\nDas 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.\nEine 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.\nAktiviert wird die Funktion in den Einstellungen unter Datenschutz und App-Datenschutz-Bericht.\nZwar 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.\nDiese Verbindungen lassen sich im Datenschutz-Bericht übrigens nicht blockieren. Um systemweites Tracking auf dem iPhone zu blockieren, bietet sich die App AdGuard Pro an.\nDamit 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.\nDer Artikel Apple integriert App-Datenschutz-Bericht in iOS 15.2 erschien zuerst auf [Mer]Curius


Sound Like – Marty Friedman | GITARRE & BASS\nvon German Schauss, 2. Dezember 2018\nHallo und willkommen zu Instant Shredding! In dieser Folge werden wir uns mit dem außergewöhnlichen Stil von Marty Friedman befassen. Bekannt wurde Friedman vor allem durch seine Zeit bei der Thrash-Metal-Band Megadeth. Zuvor hatte er sich bereits mit der Solo-Veröffentlichung ‚Dragon’s Kiss‘ und Cacophony – eine Kollaboration mit Super-Shredder Jason Becker – einen Namen gemacht. Mittlerweile hat sich Friedman wieder als Solo-Künstler etabliert und erneut bewiesen, dass er immer noch ein besonderes Gefühl für Melodien hat.\nSeine interessante Technik basiert auf ein paar einfachen Grundbausteinen: Arpeggien, Verzierungen, exotische Skalen, wie die japanische Pentatonik und Bendings, die eine kleine Sekunde unter den verschiedenen Akkordtönen beginnen. Außerdem setzt er häufig ganz bestimmte Intervalle ein: Über Dur-Akkorde legt er oft die kleine Septime (unabhängig von der Dominanten-Funktion des Akkords) und über Moll-Akkorde die große Sexte –egal, ob es sich um einen dorischen Akkord handelt oder nicht. Ich habe dazu ein paar Beispiele geschrieben. Beispiel 1 zeigt ein für Marty typisches Arpeggio in G-Dur. Hier beginne ich in der dritten Lage und verbinde ein paar andere G-Dur-Arpeggio-Positionen miteinander. Es endet mit einem Bending von der kleinen auf die große Terz. Beispiel 2 zeigt ebenfalls sehr typische Bendings, die Friedmans Spiel so melodisch machen. Hier ziele ich auf die kleine Septime und Quinte des G-Dur-Akkords, jeweils von einer kleinen Sekunde unterhalb der Akkordtöne. In Beispiel 3 umspiele ich einen E-Moll-Akkord und bende von der kleinen Sexte auf die große Sexte – auch wieder typisch für Martys Sound. Versuche selbst einfach mal, diese Ideen über eine Akkordfolge deiner Wahl zu spielen.\nLass uns jetzt noch einen Blick auf das Solo werfen, das ich im Stil von Marty Friedman geschrieben habe. Die Akkordfolge ist einfach: E-Moll, C-Dur, B-Dur, A-Moll, EMoll, C-Dur und B-Dur. In den ersten 4 Takten benutze ich eine einfache Skalensequenz, die aus der japanischen E-MollPentatonik (E, F#, G, B, C) stammt. Natürlich endet auch diese Phrase in einem Halbton-Bending, das auf die Quinte des Akkords zielt. Über den C-Dur-Akkord spiele ich ein einfaches Lick, das auf der verminderten Skala basiert. Diese Phrase endet dann in einem C-Dur-Dreiklang sowie einem Bending in die kleine Septime.\nAuch typisch für Marty ist, dass er kurze repetitive Skalenläufe benutzt, wie hier in Takt 7. Weiter geht es mit einem einfachen B-Dur-String-Skipping und Sweep-Picking-Arpeggio. Der A-Moll-Akkord wird mit der dazugehörigen Pentatonik umspielt, dabei benutze ich Verzierungen wie Slides, Hammer-Ons und Pull-Offs. Es geht dann in ein Bending von F zu F#. Über E-Moll spiele ich ein lange stehendes Bending sowie ein Zwei-Oktaven-Arpeggio, das sich chromatisch von D# zum Grundton E auflöst. Marty benutzt sehr oft auch chromatische Durchgangstöne, um Dissonanzen zu erzeugen. Die letzten vier Takte gehen über C-Dur und B-Dur und ich spiele zunächst ein Zwei-Oktaven-C-Dur Arpeggio, das dann in ein vermindertes Arpeggio überleitet. Ich habe hier auch chromatische Passagen zwischen den Akkordtönen untergebracht, damit das Ganze dissonanter klingt. Das Lick ist ebenfalls typisch für Marty Friedman und ist auch von anderen Shreddern wie z. B. Jeff Loomis übernommen worden.\nMehr Infos gibt es auf www.germanschauss.com. Bis nächstes Mal und viel Spaß beim Shredden!\nUnser Autor German Schauss\nSchlagwörter: Gitarre lernen, Gitarrenakkorde, Gitarrensolo, Gitarrist, Soundalike


Zebra One Stapelsessel carbon grey - Design online kaufen | Talaso - Gartenmöbel Outlet - Online Shop\nDer Zebra One Stapelsessel aus hochwertigem Kunststoffgewebe im Farbton carbon grey und einem... mehr\n"Zebra One Stapelsessel carbon grey"\nDer Zebra One Stapelsessel aus hochwertigem Kunststoffgewebe im Farbton carbon grey und einem Edelstahlgestell vereint Leichtigkeit mit Stabilität. Die eingelassenen Armlehnen sind aus Teakholz. Das lichtdurchlässige Textilen zeichnet sich durch eine angenehm natürliche Haptik aus. Die One Gartenstühle sind wetterfest, langlebig sowie mit wenig Aufwand zu pflegen und lassen sich ineinander gestapelt platzsparend verstauen.\nWeiterführende Links zu "Zebra One Stapelsessel carbon grey"\nKundenbewertungen für "Zebra One Stapelsessel carbon grey"


Sony SAL-30M28 DT 2,8/30 mm SAM Macro - Objektive im Test\nStartseite » Foto & Video » Objektive » Sony SAL-30M28 DT 2,8/30 mm SAM Macro\nSony SAL-30M28 DT 2,8/30 mm SAM Macro im Test\n Author: Janina Matthiessen Erschienen am: 08.09.2010\nDie Standard-Festbrennweite Sony SAL-30M28 DT 2,8/30 mm SAM Macro verspricht Makrto-Fähigkeiten für wenig Geld.\nUnter Miteinbeziehung des Crop-Faktors, der bei den meisten Sony Alpha-DSLRs (außer Vollformat) miteingerechnet werden muss, beträgt die Brennweite 45 mm.\nErstaunlich ist zunächst der günstige Preis des Objektivs. Laut Test ist es nur mittelmäßig bis gut verarbeitet, das Bajonett ist aus Kunststoff – hier spürt man den Rotstift. Der Fokusring wurde im Test als zu schmal und leichtgängig beschrieben, wodurch manuelles Scharfstellen erschwert wird. Die Filterfassung steht beim Fokussieren still. Der Lichtschutz des Sony SAL-30M28 DT 2,8/30 mm SAM Macro ist laut Test gut, auch wenn keine Gegenlichtblende im Lieferumfang enthalten ist.\nIn der Mechanik sind Kompromisse zugunsten des Preises leichter zu akzeptieren als in der Bildqualität. Die Auflösung ist grundsätzlich in Ordnung, aber es zeigten sich leichte Offenblendeinschränkungen, vor allem im Nahbereich. Schade – zwar schmerzt Abblenden bei f2,8 nicht schlimm, aber gerade im Nahbereich will man das Spiel mit der geringen Tiefenschärfe nutzen, dass durch eine große Blende/kleine Blendenzahl entsteht. Das Prädikat "Macro", dass Sony seinem Objektiv mit auf den Weg gegeben hat, bekommt hier ein kleines "aber" entgegengestellt.\nAbblenden verbessert auch die Vignettierung (Randabschattung), die vor allem im Fernbereich mit Offenblende deutlich ist. Auch abgeblendet verschwindet sie nicht ganz, wird aber sichtlich besser. Schade ist laut Test auch die für ein Makro recht hohe Verzeichnung. Starke Vignettierung und Verzeichnung sind ungewöhnlich für eine Festbrennweite – unter dem Strich lässt sich das Sony SAL-30M28 DT 2,8/30 mm SAM Macro nur Einsteigern empfehlen.\nVorteil: Sony SAL-30M28 DT 2,8/30 mm SAM Macro\nNachteil: Sony SAL-30M28 DT 2,8/30 mm SAM Macro\nTestberichte der Fachpresse zu Sony SAL-30M28 DT 2,8/30 mm SAM Macro\nZitat: Der Preistipp wiegt gerade einmal 150 Gramm und ist dabei so handlich, dass er in der Tasche kaum Platz benötigt.\nZitat: Auflösung: 89%, Objektivgüte: 94%, Ausstattung: 78%, Autofokus: 96%\nZitat: Bei Anfangsöffnung schwache Auflösung und starke Vignettierung. Abblenden steigert die Abbildungsleistung erheblich. Bei offener Blende sind die Bilder flau, fast wie etwas weichgezeichnet. Bei Blende 5,6 deutlich besser und schärfer. Leichte Konstruktion mit Kunststoff-Bajonett. MF-Ring rotiert mit beim AF-Betrieb. Guter Drehwinkel, wacklige Fassung. Anmerkung zum Test: Getestet an der Sony Alpha 580\nZitat: Bei Anfangsöffnung schwache Auflösung und starke Vignettierung. Abblenden steigert die Abbildungsleistung erheblich. […] Die mechanische Qualität bei manueller Fokussierung enttäuscht. Die Fassung ist sehr wackelig, der Fokus verstellt sich bereits, wenn man den glatten, schmalen MF-Ring loslässt. Anmerkung zum Test: Getestet an der Sony Alpha 580\nZitat: Auflösung: Im Ferbereich insgesamt gut. Leichter Offenblendfehler, akzeptabler Beugungseinfluss. Im Nahbereich sollte man um ein bis zwei Blenden schließen. Abblenden kommt auch der Randabdunklung zu Gute, die im Fernbereich recht deutlich ist und abgeblendet leicht sichtbar bleibt. Im Nahbereich ist die Randabdunklung insgesamt etwas geringer. Verzeichnung: Für ein Makro erstaunlich hoch und sichtbar.\nZitat: Das sehr kompakte... Normalobjektiv... liefert offen eine solide und gleichmäßige Schärfe. Beim Abblenden geschieht Ungewöhnliches: Während die Mitte deutlich zulegt, werden die Ecken schlechter. Insgesamt ist das 30-er dennoch ein gutes Objektiv, auch wenn die Vignettierung und Verzeichnung für eine Festbrennweite eher hoch liegen.\nWir benachrichtigen Sie gerne, sobald ein neuer Testbericht zum Produkt "Sony SAL-30M28 DT 2,8/30 mm SAM Macro" vorliegt!\nSie haben das Produkt Sony SAL-30M28 DT 2,8/30 mm SAM Macro bereits? Schreiben Sie Ihren persönlichen Testbericht und geben Sie hier Ihre Meinung ab.\nDienstag, den 16.09.2014 von Andreas\n...ich bin voll zufrieden damit.........ich möchte es von der a 77 gar nicht mehr runter geben........Fehler gleiche ich mit DXO 9 aus, kein Problem.....macht super -super scharfe Bilder. schade das Zeiss kein Macro für Alpha hat.\nDatenblatt Sony SAL-30M28 DT 2,8/30 mm SAM Macro