ubuntuusers.de

Neueste Artikel

gestern

Die MZLA Technologies Corporation hat mit Thunderbird 78.10.2 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 78.10.2

Mit dem Update auf Thunderbird 78.10.2 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht. Mit dem Update behebt MZLA mehrere Fehler, welche überwiegend in Zusammenhang mit der OpenPGP-Implementierung stehen. Dazu kommen kleinere Darstellungs-Fixes. Außerdem zeigt der Add-ons Manager in den Details jetzt ein Icon zum Öffnen der Einstellungen an, wenn eine Erweiterung eine Einstellungsoberfläche implementiert hat. Dazu kommen zwei geschlossene Sicherheitslücken in Zusammenhang mit OpenPGP, deren Gefahrenpotential als niedrig eingestuft wird.

Der Beitrag Thunderbird 78.10.2 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Die Entscheidung zwischen den großen Betriebssystemrichtungen fällt bei mir ziemlich schnell. Das System mit dem Apfel fällt für mich raus, weil ich keine 1000€ für einen Laptop ausgeben will, wenn man gute Businesslaptops schon für weniger als 500€ haben kann. Somit gibt es für die meisten Menschen nur noch dieses wundervolle System aus Redmond. Version 7 davon war ein wirklich tolles Betriebssystem mit einer meiner Meinung nach intuitiven Benutzeroberfläche und vielen netten Details. Ich weiß nicht so recht, wer auf die Idee kam, mit Windows 8 mit allen bisherigen Gewohnheiten der Windowsnutzer zu brechen und einmal den gesamten Desktop auf den Kopf zu stellen. Ich verstehe immer noch nicht, warum es “da” Entwickler gibt, die denken, dass man den Desktop in ein übergroßes Smartphone verwandeln muss. Ich zumindest will das nicht - und viele Andere wollten sich die Benutzeroberfläche von Win8 nicht antun und sind deshalb bei Version 7 geblieben. Das ging natürlich auch nicht an der Firma dieses unglaublich sympathischen Mannes vorbei, die hinter diesem “Betriebssystem” steht und es musste einen neue Windows-Version her: Windows 10 entsteht! Zur Oberfläche von Windows 10 hat Gerrit eine emotionale Zusammenfassung geliefert. Ich persönlich sehe Windows 10 als die “logische” (Logik scheint auch immer relativ zu sein…) von Windows 8 und den Weg, den man versucht hatte, um dieses OS zu retten. Tatsächlich wirkt Windows 10 etwas stümperhaft zusammengeschustert mit Elementen aller bisheriger Windows-Versionen und will trotzdem mit den bekannten Regeln brechen und anders sein. Die Idee dahinter mag gut sein, ist aber meiner Meinung nach nicht sonderlich gut umgesetzt.

Da ich aber mit vielen Programmen arbeite, die es zum Großteil nur für Win, ApfelOS und Linux gibt, fallen für mich andere alternative - zum Teil auch vielversprechende - Betriebssysteme wie HaikuOS aus dem Wettbewerb heraus und es gibt eigentlich nur eine wirkliche Alternative: Linux!

Jetzt ist das ja nicht so einfach, weil es ja nicht ein “Linux” gibt. Wie bekannt ist Linux ja eigentlich nur der Betriebssystemkernel und das was landläufig als “Linux” bezeichnet wird, sind Distributionen, von denen es ja nicht so wenige gibt. Jetzt gibt es ja Stimmen, die eher für eine große einheitliche Linux-Distribution sind; ich bin da nicht für und finde diese Vielfalt zwar manchmal verwirrend, aber dennoch gut - warum dem so ist, habe ich schoneinmal erläutert.

Ich will so viel wie möglich über die normale Paketverwaltung installieren (und nicht über Flatpaks, Snaps, AppImages etc.pp.), also bleiben eigentlich nur noch ein paar große Distris übrig:

  • Debian und seine Ableger
  • Ubuntu (ja ich weiß, dass das ein Debian-Derivat ist, aber ich behandle es doch einmal gesondert)
  • Arch Linux
  • RHEL & Fedora und die jeweiligen Ableger

Vor allem was den letzten Punkt betrifft, kann ich nicht viel sagen, da ich weder RHEL, noch Fedora, noch einen Ableger der beiden jemals getestet habe, aber der Vollständigkeit wegen zähle ich sie trotzdem auf, da sie ja recht verbreitet und wohl auch nicht so schlecht sind.

Ich selber leide sicher nicht an Versionitis, brauche also auch nicht immer die neuesten Versionen. Mir ist wichtig, dass ich mich auf mein Betriebssystem verlassen kann, dass es täglich funktioniert, ich möglichst lange Updates erhalte und ich erwarte, dass ich eigentlich auch möglichst schnell Bugfixes erhalte. B Mein Einstieg in Linux fand mit einem Ubuntu-Derivat statt, das recht nah an Ubuntu ist, hauptsächlich etwas Theming betreibt und ein paar eigene Programme mitliefert. Dadurch bin ich dann durch ein paar Anleitungen im Wiki zu der wirklich tollen Community auf ubuntuusers.de gelangen und habe mich Ende letzten Jahres dort angemeldet. Ubuntu habe ich seitdem wirklich liebgewonnen und benutze es (bzw. das oben schon angesprochene Derivat Linux Lite) gerne. Wenn man sich mit Ubuntu intensiv auseinandersetzt, hört von Debian und beschäftigt sich früher oder später auch damit. Sowohl Debian als auch Ubuntu haben den Ruf, möglichst stabil zu laufen - und das stimmt so auch; ich hatte es bisher zumindest noch nie, dass Ubuntu plötzlich abgestürzt wäre und die meisten Fehler, die im Forum mit solchen oder so ähnlichen Problemen auftauchen sind im Regelfall selbstverschuldet. Wie gesagt: im Regelfall! Immer wieder gibt es auch Probleme, die durch Bugs ausgelöst werden, allerdings ist die Quote, was das betrifft, eher gering. Hier kommen wir aber auch zu einem großen Nachteil an diesen “stabilen” Betriebssystemen. Ein Bug muss ersteinmal gemeldet werden und dann bearbeitet werden. Die Änderungen landen, sofern sich überhaupt jemand des Bugreports animmt, bei Ubuntu ersteinmal in den Proposed-Quellen und werden dann später erst in die eigentlichen Quellen geschoben - das kann alles insgesamt schon einmal etwa zwei Wochen dauern. Man hat dann also zwei Wochen einen nervenden Bug. Ein im Moment recht prominentes Beispiel, war der Bug, der ein Ubuntu-Upgrade von Ubuntu 20.10 auf die aktuelle STS-Version 21.04 verhinderte. Der Bug wurde am 19.04.2021 auf Launchpad gemeldet, eine Fehlerkorrektur kam am 6.5.2021 in die Proposed-Quellen und am 11.5.2021 in die normalen Quellen für Updates. Und liebe Ubuntu-Entwickler (das was ich hier schreibe, gilt für die Debian-Entwickler und alle anderen Entwickler ebenso): Danke für eure Arbeit! Das ist gut so und macht so weiter, aber der ein oder andere Bug ist störend, wenn er gut drei Wochen offen ist.

Natürlich können in den vermeintlichen Bugfixes auch neue Bugs sein und von daher ist es sinnvoll, dass nicht alles im Akkordtempo in die normalen Quellen geschoben wird, sondern vorher getestet wird - gerade bei einer Distribution, die sich selbst das Ziel gesetzt hat, einsteigerfreundlich zu sein.

Leider, leider hat es bisher weder Ubuntu, Debian noch irgendeine Rolling-Release-Distribution geschafft, Bug 1 zu fixen. :)

Bisher habe ich hier in diesem Text Ubuntu und Debian eher zusammen behandelt. Wenn man mal von dem “Ballast”, den Ubuntu mit sich herumschleppt (z.B. Snaps, früher die Amazon-Integrierung) absieht, könnte man den Einruck bekommen, Ubuntu sei ein Debian in warmen Farben. Jetzt nehmen wir uns mal ein reguläres Debian-Installations-Medium und eines von Ubuntu. Wenn wir jetzt das Debian-Medium starten, werden wir früher oder später während der Installation gefragt, ob und wenn ja welche Desktopumgebung wir haben wollen. Das gibt es bei Ubuntu so nicht. Es gibt für jedes offizielle Derivat ein eigenes Image und dann noch das offizielle Image mit GNOME und das Server-Image ohne irgendeine Desktopumgebung. Wenn man sich außerdem mal eine Debian-Installation und eine Ubuntu-Installation anschaut, so sind bei Ubuntu wahrscheinlich meistens deutlich mehr Programme installiert, als bei Debian.

Das ist ein großer Punkt, bei dem man bei Distributionen unterscheiden muss: Es gibt Distributionen, die alles vorkonfiguriert und vorinstalliert haben (so Ubuntu) und es gibt die Distributionen, die dem Nutzer viel Wahl geben, wie er sein System gestalten will (so Debian und Arch). Das ist auch genau der Punkt, warum ich Debian und Ubuntu weiter oben in der Aufzählung getrennt habe (ganz abgesehen davon, dass Ubuntu recht autark arbeitet und sich (leider?) nur seht wenig von Debian beeinflussen lässt).

Während Debian und Ubuntu in vielen Punkten ähnlich (beziehungsweise vom Unterbau fast identisch) sind, geht Arch einen völlig anderen Weg.

Arch perfektioniert das Ziel, den Benutzer alles beeinflussen zu lassen. Das hat dann zwar zur Folge, dass die Installation rein auf Textebene ist und man (außer man installiert explizit etwas Anderes) auch nur ein System ohne irgendeinen Schnickschnack hat. Ich musste bei meiner Arch-Installation sogar die usbutils nachinstallieren. Was Arch außerdem von allen anderen hier genannten Distributionen unterscheidet, ist die Tatsache, dass es eine Rolling-Release-Distribution ist. Das bedeutet, dass man nicht alle 3 Jahre eine neue Version installieren muss, sondern jeden Tag mittels des Befehles pacman -Syu seine Installation auf den neuesten Stand bringt. Arch liefert außerdem eigentlich alles so gut wie ungepatcht aus, was vom Upstream an Paketen kommt. Wobei man hier anmerken muss, dass Arch auch so etwas wie die Proposed-Quellen unter Ubuntu hat, nur landen Änderungen sehr viel schneller in den regulären Quellen.

Arch Linux hat den Ruf eine Distri für fortgeschrittene Benutzer zu sein, weil man alles selbst machen muss und eigentlich nichts vorkonfiguriert ist. Das hat natürlich Vor- und Nachteile. Ein enormer Nachteil ist natürlich der Zeitaufwand, den man dafür aufbringen muss, dafür weiß man am Ende aber auch ziemlich genau, was das eigene System eigentlich so treibt und am Ende ist man wahrscheinlich selbst schuld für die meisten Fehler, weiß dann aber im Idealfall auch, wo man suchen muss. Außerdem gilt Arch als eine instabile Distribution, die häufiger mit Bugs zu kämpfen hat, weil ja alles direkt vom Upstream übernommen wird. Tatsächlich ist die Instabilität von Arch Linux wohl eher ein Mythos, der aus der Anfangszeit der Distribution stammt. Ich benutze Arch jetzt seit bald 2 Monaten und hatte bisher genau einen(!) Bug, den ich wirklich bemerkt hatte. Durch ein Update von GTK+ konnte Thunar nicht mehr starten und ich bin dann vorübergehend auf Natilus ausgewichen. Dieser Fehler war allerdings schon am nächsten Tag durch ein Update behoben und ich konnte Thunar wieder wie gewohnt nutzen! Andere (langjährige) Archnutzer haben mir berichtet, dass sie bisher in der ganzen Zeit noch nie durch einen Bug eingeschränkt wurden. Trotzdem würde ich Arch nicht als eine Einsteigerdistribution bezeichnen. Zwar ist man recht gut bedient, wenn man wirklich Willens ist und es gibt nichts was man nicht mithilfe der Wikis von Arch und dem von ubuntuusers lösen könnte (gut dann ist halt etwas Transferleistung gefragt), aber ich habe zum Beispiel mein allererstes Linux so verbastelt, das ich nicht glaube, dass damit irgendjemand gerne sicher gearbeitet hätte und bin deshalb froh, dass ich diese Installation sowieso stilllegen musste, weil sie keinen Support mehr hatte und das gibt es eben so bei Arch nicht, da man sein System ja kontinuierlich aktuell hält.

Natürlich gibt es wenn man gerne “so etwas wie ein Rolling-Release” haben möchte, andere Alternativen. Wenn man sich zum Beispiel schon besser mit Debian respektive Ubuntu auskennt, ist vielleicht Debian Sid (oder das darauf aufbauende Siduction) eine schöne Alternative. Hierbei setzt man immer auf den Entwicklungszweig von Debian und muss nicht regelmäßig ein Dist-Upgrade von einer Debian-Version auf die Andere machen, sondern ist immer auf dem neuesten Stand (den Debian anbietet). Meiner Erfahrung (bisher allerdings nur in VMs) ist Sid eine recht gute Mischung aus aktueller Software und Debian-Stabilität. Man kann hier aber weder erwarten, dass man das selbe hat, wie bei einem normalen Debian Stable oder bei einem Arch. Außerdem gibt es für die Ubuntu-Nutzer auch einen Entwicklungszweig, mit dem man theoretisch sein System in ein Semi-Rolling-Release verwandeln kann. Da gibt es sogar ein Skript von Martin Wimpress. Inwiefern das sinnvoll kann jeder für sich selber entscheiden. Ich würde das allerdings nicht auf einem Produktivsystem machen!!

Wie schon erwähnt kann ich (leider) noch nichts zu RHEL, Fedora, openSUSE etc. sagen beziehungsweise schreiben.

Für jeden sind andere Distributionen passend und natürlich hat da jeder seine Präferenzen, aber ich habe auch meine:

Grundsätzlich habe ich mittlerweile wirklich Gefallen an Arch gefunden, auf den fremden Rechnern, die ich administriere kommt aber immer noch ein Ubuntu oder ein Derivat darauf, weil sich das System in meiner Erfahrung als sehr stabil und zuverlässig erwiesen hat und ich verstehe auch, warum Unternehmen eher LTS-Distributionen einsetzen. In nächster Zeit - bin ich mir sicher - landet bei mir irgendwo auf einer Festplatte sicher noch Debian Sid.

17. Mai 2021

Dies ist ein Update zu den Beiträgen:

  1. Konzept zum Deployment meines Blogs mit Ansible und
  2. Erfahrungsbericht zum Deployment meines Blogs mit Ansible.

Umgebung

Aktuell nutze ich als Ansible Control Node (ACN) ein Debian Buster mit Ansible 2.7.7. Die Backups liegen wie gehabt auf einem Speicher im lokalen Heimnetzwerk.

Als Zielsysteme für die Wiederherstellung dienen ein Debian 10 (Buster) und Debian Testing (das kommende Bullseye). Bei beiden Zielsystemen handelt es sich um minimale Installation in zwei VMs auf einem KVM-Hypervisor.

Ablauf

Zuerst habe ich meinen Blog aus dem Backup auf der Debian 10 VM wiederhergestellt. Dabei gab es tatsächlich ein Problem. Das VHOST-Template für den Webserver entsprach nicht mehr der Version, die auf dem Produktivsystem zum Einsatz kommt. Ich hatte schlicht vergessen, die Änderung nachzupflegen. Der Fehler wurde schnell identifiziert und behoben. Anschließend verlief der Wiederherstellungsprozess reibungslos.

Beim zweiten Versuch erfolgte die Wiederherstellung auf einer VM mit Debian Testing (Bullseye). Dieser Test ist für mich wichtig, um zu sehen, ob ich meinen Blog auch auf der kommenden stabilen Debian-Version ausrollen kann. Hier waren etwas mehr Anpassungen an der Rolle „deploy-my-blog“ notwendig, um dieses Blog erfolgreich wiederherstellen zu können. So haben sich einige Paketnamen geändert:

Alter NameNeuer Name
python-aptpython3-apt
python-mysqldbpython3-mysqldb
Gegenüberstellung der alten und neuen Paketnamen

Doch auch an der VM selbst war ein manueller Eingriff notwendig, bevor sich mein ACN überhaupt mit dem Node verbinden konnte. Ansible konnte auf dem Node keinen Python-Interpreter finden. Ich schiebe die Schuld der Version 2.7.7 in die Schuhe. Nachdem ich einen Symlink von /usr/bin/python auf /usr/bin/python3 erstellt hatte, klappte der Zugriff.

Der letzte Stolperstein war php-fpm. Kommt unter Buster Version 7.3 zum Einsatz so ist dies unter Bullseye 7.4. Da die Versionsnummer in meiner Ansible-Rolle hart verdrahtet ist, war auch hier eine Anpassung notwendig. Anschließend gelang auch hier die Wiederherstellung.

Fazit

Grundsätzlich klappte die Wiederherstellung wie gewohnt. Den Fehler mit der VHOST-Datei könnte ich zukünftig vermeiden, indem ich diese einfach mit aus dem Backup wiederherstelle, statt ein Template zu nutzen.

Das bei der Wiederherstellung auf einer neueren Betriebssystemversion Anpassungen erforderlich sind, hatte ich erwartet. Diese halten sich meiner Meinung nach in Grenzen und sind akzeptabel.

Die längste Zeit beanspruchte das Kopieren der Backups auf die Zielsysteme. Die eigentliche Wiederherstellung war mit den Stolpersteinen in 10-15 Minuten. Mit fehlerbereinigter Rolle sogar nur noch ca. 5 Minuten. Eine manuelle Wiedereinrichtung hat mich früher eher zwischen 30-60 Minuten gekostet. Von daher bin ich sehr zufrieden.

16. Mai 2021

Seit etwas über einem Jahr arbeite ich bei GitLab und habe engen Kontakt mit Kunden, die entweder schon GitLab einsetzen oder bald einsetzen werden. Ein Thema was zuletzt immer häufiger aufkommt, ist das Thema „Monorepo“. Noch spannender ist, wie einige Kunden sagen, sie haben „mehrere Monorepos“, was keinen Sinn ergibt. Denn nicht umsonst setzt sich das Wort auf „mono“ und „repo“ zusammen, also „einzel“ und „Repository“. Im Endeffekt hat man also ein großes Repository wo der komplette Quellcode enthalten und verwaltet wird. Jedes Mal, wenn ein Kunde von „mehreren Monorepos“ spricht, dann zwickt mein Auge immer wieder stark, denn meistens ist damit eigentlich nur gemeint, dass es sich um „Multi-Projekt Repositorys“ handelt. Also sind es meist eher Repositorys wo mehrere Projekte innerhalb eines Repositorys verwaltet werden.

Stellenweise finden sich im Internet diverse Blogposts wo Monorepos die Abkürzung von „monolithisches Repository“ ist. Das ist nicht die Definition, die ich wählen würde und auch nicht die, die gängig verbreitet ist. Ein Monolith aus Sicht der Software-Entwicklung kann schließlich auch aus mehreren Repositorys bestehen – und tut es in vielen Umgebungen auch. Überschneidungen gibt es hier aber sicherlich.

Echte Monorepos finden sich in der freien Wildbahn eher selten. Der wohl bekannteste Vertreter ist Google. Google hat für ihre internen Tools ein großes Repository, was nicht auf Git aufsetzt, sondern eine proprietäre Eigenentwicklung ist. Enthalten ist dort der Quellcode und die Versionshistorie der ganzen Firma seit Anbeginn der Zeit. In einem Paper von Juli 2016 beschreiben sie recht ausführlich, wie ihr Monorepo aufgebaut ist, wie sie damit Arbeiten und wie groß es mittlerweile ist. Wem die Details interessieren, sollte da mal reinlesen. Knapp 5 Jahre später dürfte das Repository noch deutlich riesiger geworden sein.

Ein weiterer bekannter Nutzer von Monorepos sind weitere große Techfirmen wie Facebook, Microsoft oder Twitter. Bei jeder Firma dürfte die Nutzung durchaus unterschiedlich sein. Facebook setzt beispielsweise auf Mercurial als SCM tool. Details darüber schrieben sie im Blogpost „Scaling Mercurial at Facebook“. Der Artikel ist von Januar 2014, also auch schon etwas älter.

Warum überhaupt Monorepos?

Egal ob man mit multiplen Repositorys arbeitet oder mit einem Monorepo: Beide Varianten haben je nach betrachteten Aspekt Vor- und Nachteile. Während man bei einem Monorepo-Ansatz vielleicht nicht die Probleme des Multi-Repo-Ansatzes hat, bekommt man stattdessen andere Herausforderungen.

Statt hier plump die Vor- und Nachteile beider Varianten einzugehen, verfolge ich hier einen etwas anderen Ansatz und beleuchte einzelne Aspekte und Methodiken mit beiden Varianten. Dies betrifft sowohl technische Herausforderungen vom eingesetzten Versionsverwaltungsprogramm, als auch die Build-Tools, sowie die Arbeitsweise.

Internes Dependency-Managements

Ein wichtiger Grund für ein Monorepo (oder auch Multi-Projekt-Repository) ist die vereinfachte Möglichkeit des Managements von internen Abhängigkeiten. Und dieser Use-Case ist generell gar nicht mal so selten.

Häufig sieht es so aus, dass es innerhalb einer Firma mehrere Projekte gibt, welche die gleiche Abhängigkeit nutzen. Soweit nichts Besonderes. Aber wie sieht nun der Vorgang aus, wenn eine Änderung an der Abhängigkeit gemacht werden muss?

Im klassischen Konzept, also ohne einem Monorepo, werden gleich jeweils eine Änderung an zwei Repositorys benötigt: Einmal in der Library, wo die eigentliche Änderung durchgeführt wird und anschließend die nächste Änderung im Hauptprojekt. Diese ist allerdings abhängig von der Änderung der Abhängigkeit. Hier muss also erst einmal abgewartet werden, bis die Änderung eingeflossen ist, bevor so wirklich die Änderung im Hauptprojekt gemacht werden kann. Der Prozess dauert also automatisch etwas länger und führt zu längeren Entwicklungszeiten. Zusätzlich könnte auch noch sein, das mehrere Projekte diese Abhängigkeit verwenden und diese auch eine Änderung benötigen, diese muss – auch wenn es sich vielleicht nur um eine kleine Anpassung handelt – in jedem Projekt nachgepflegt werden.

Hier ist also schonmal ein wesentlicher Vorteil von Monorepos beziehungsweise Multi-Projekt-Repos: Eine Änderung in einer Abhängigkeit kann in einem Rutsch und einem Review durchgeführt werden. Komplexere Abhängigkeiten beim Mergen von Änderungen über verschiedene Repositorys hinweg wird vermieden und das Review ist gleichzeitig transparenter durchführbar, da man in einer Ansicht und mit einem Review projektübergreifend die Änderung überblicken kann.

Was ich hier allerdings noch nicht betrachtet habe, ist das CI (und CD) Setup, denn das hat auch einen wesentlichen Einfluss auf die Arbeitsweise. Aber dazu im nächsten Abschnitt mehr.

CI/CD und Build Tools

Ein weiterer Aspekt der wichtig zu betrachten ist, ist das Setup rund um CI/CD und den Build Tools. Wie im Abschnitt zuvor schon erwähnt steht und fällt es der verwendete Ansatz an den Tools und Workflows.

Um das Beispiel aus dem vorherigen Abschnitt fortzuführen ist es nun wichtig zu betrachten, wie der Build-Prozess nun aussieht. Im traditionellen Umfeld mit mehreren Repositorys hat jedes Projekt im Repository meistens eine Pipeline-Definition, welche bei jedem Merge-Request ausgeführt wird, um das Projekt zu bauen und zu testen. Kompliziert wird es aber, wenn man es auch „richtig“ testen will und das ist gar nicht so einfach.

Angenommen, die Abhängigkeit mit dem Namen „DependencyA“ ist die Abhängigkeit von „HauptprojektA“ und „HauptprojektB“. Wenn also für eine Änderung in „HauptprojektA“ eine Änderung in „DependencyA“ benötigt wird, dann muss diese Änderung da normal eingepflegt werden, worin dann die Pipeline läuft und das Projekt baut und die Tests ausführt. Wenn es erfolgreich war, dann wird ggf. eine neue Version getaggt, damit es dann von „HauptprojektA“ und „HauptprojektB“ referenziert und verwendet werden kann. Dort müssen dann nochmals Merge Requests erzeugt werden, die dann die Version von „DependencyA“ hochziehen und dann alles Bauen und Testen.

Das ist im Prinzip das, was ich auch zum internen Dependency-Management geschrieben habe. Das Problem hierbei ist, dass immer nur jedes Projekt für sich getestet wird, aber nicht alle Projekte als ganzes. Das heißt im Konkret, wenn die Änderung in „DependencyA“ zu einem Fehler im „HauptprojektB“ führt, muss der ganze Workflow wieder von vorne gestartet werden.

Was häufig aber fehlt, ist die Möglichkeit alle Projekte zu bauen, die voneinander abhängen für die einzelne Änderung. Das heißt, ich mache eine Änderung an „DependencyA“, die Pipeline baut nicht nur das Projekt selbst und testet es, sondern es zieht bei „HauptprojektA“ und „HauptprojektB“ die Änderung „trocken“ mit und baut es im gleichen Zuge auch mit durch und führt die Tests aus. So kann sichergestellt werden, dass die Änderung nicht zu Folgefehlern in den eigentlichen Projekten führt.

Beim Einsatz von mehreren Repositorys ist das nicht soo einfach zu lösen, da theoretisch automatisiert in den entsprechenden Reverse-Dependency-Projekten neue Branches mit den Änderungen erstellt werden müssen, um die Pipeline zu triggern. Oder es muss eine andere Art der Parametrisierung eingebaut werden, um dies zu bewerkstelligen. zuul-ci.org ist ein Projekt um so etwas umzusetzen. Praktische Erfahrung habe ich damit allerdings nicht.

In Monorepos ist das grundsätzliche Problem eine Änderung in allen Projekten durchzubauen auch enthalten, ist da aber grundsätzlich einfacher zu verwalten, weil es eben in einem Repository enthalten ist. Nichtsdestotrotz wird auch hier ein eigenes bzw. spezielles Buildtool benötigt, was selbstständig die Abhängigkeiten auf allen Projekten im Repository erkennt und entsprechend durchbaut. Das Buildtool Bazel unterstützt das und baut etwa nur die Änderungen durch, die auch wirklich benötigt werden.

Kollaborationen im Team und zwischen Teams

Beim Arbeiten über den Grenzen von verschiedenen Teams ist die Abstimmung bei Änderungen essenziell. Beim Einsatz von mehreren Repositorys sind die Verantwortlichkeiten über die Repository-Berechtigungen selbst gesetzt. Die Hürde bei „fremden“ Teams die Änderung an einer gemeinsam genutzten Abhängigkeit und beim Projekt selbst einzubringen ist häufig eher hoch. Aber das ist mehr eine organisatorische und auch kulturelle Frage.

In Monorepos und Multi-Projekt-Repos ist das nicht so einfach möglich, weil sich hier das klassische Modell nicht anwenden lässt. Dafür gibt es allerdings das Konzept der CODEOWNERS wo sich eintragen lässt, welcher User der „Eigentümer“ welches Unterverzeichnisses ist, damit diese im Code-Review automatisch benachrichtigt werden und nur diese es mergen dürfen. Diese Funktion ist keine Funktion von Git selbst, sondern wird von den verschiedenen Git-Hosting-Diensten selbst implementiert. In GitLab ist die Code Owners Funktionalität kostenpflichtig, in GitHub je nach Visbilität des Projekts auch.

Git Funktionen für große Repositorys

Bisher habe ich mich hauptsächlich mit den konzeptionellen Vor- und Nachteilen beschäftigt. Fakt ist allerdings, dass die echten Vor- und Nachteile sehr stark von den eigentlichen Firmen, Strukturen und Projekten ab.

Bisher habe ich nicht nur die Arbeitsweise und Workflows betrachtet, weniger wie gut bzw. schlecht es mit Git selbst funktioniert. Darum geht es nun in den folgenden Abschnitten.

Performance

Das Git von Haus aus nicht wirklich für große Repositorys gemacht ist, ist vielen mittlerweile hinlänglich bekannt, da alle Versionen aller Dateien im Standard im Repository enthalten sind. Je mehr Dateien und Verzeichnisse sind, desto eher wird die Performance leiden. Dies ist nicht nur daran geschuldet, dass das Repository sehr groß (in Gigabyte gemessen) wird, sondern auch, dass nicht effizient mit mehreren Millionen von Dateien umgehen kann.

Wie sich das ganze Auswirken kann, zeigt ein Konferenz-Vortrag von Microsoft: „Scaling Git at Microsoft“. Dort wird erzählt welche Probleme Microsoft hatte, um das Windows Repository auf Git zu migrieren. Es resultierte in ein 270GB großes Repository, wo das Klonen 12h gedauert hat, ein git checkout 3h, das Ausführen von git status auch immerhin 8 Minuten und Ausführen von git commit dauerte auch schon mal eben 30 Minuten. Alles wohlgemerkt auf SSDs. Aus technischer Sicht ist das ein sehr spannender Vortrag, bei dem ich erst richtig verstanden hab, was für Probleme Git bei großen Repositorys hat.

Allerdings muss man sowieso hervorheben, dass wohl die wenigsten Projekte wirklich so große Repositorys haben werden.

Git LFS

Ein angesprochenes Problem von Git ist wie zuvor erwähnt die Handhabung von Binärdateien. Dazu gibt es Git LFS, womit sich Binärdateien außerhalb des eigentlichen Git-Repositorys von Git speichern und verwalten lassen. Der einzige Zweck ist wirklich nur die Handhabung von Binärdateien und weniger von generellen großen Repositorys.

In einem separaten Blogpost habe ich das Thema Git LFS näher beleuchtet.

git submodule und git subtree

Wenn man mit mehreren Repositorys arbeitet, gibt es verschiedene Möglichkeiten die Abhängigkeiten mit hereinzuziehen. Wenn diese Abhängigkeiten einfach über den Paketmanager der verwendeten Programmiersprache verwendet werden kann, ist es am einfachsten. Wenn man allerdings den Code einer Abhängigkeit direkt in das Hauptprojekt einbinden muss, dann gibt es die Möglichkeit mit Submodulen zu arbeiten. Die eher unbekanntere Methode ist Subtree zu nutzen.

Beide Varianten haben Vor- und Nachteile. Die Handhabung von git submodule ist eher aufwändig und mühselig. Es müssen relativ viele Schritte durchgeführt werden, damit alles ordnungsgemäß funktioniert. Mit git subtree kann man hingegen das Zurückführen der Änderung gut und gerne mal vergessen, ist dafür aber angenehmer zu nutzen.

Auch auf diese beiden Befehle gehe in einem weiteren Blogpost näher darauf ein.

git sparse-checkout

Sowohl git submodule als auch git subtree waren zwei Funktionen, die eher nicht für Monorepos relevant sind. Was hingegen relevant ist, ist die Möglichkeit nur mit einem Teil des Repositorys arbeiten zu können. Ein gängiges git clone lädt schließlich das komplette Repository herunter, was bei einem echten Monorepo eher ungünstig ist, da man dann auch allen Code lokal vorliegen hat, den man gar nicht braucht. Mit einem Sparse-Checkout lässt sich ein Klonen und Arbeiten mit einzelnen Unterverzeichnissen bewerkstelligen.

Das GitHub-Blog hat einen ausführlichen Blogpost veröffentlicht in dem genauer beschrieben wird, wie man mit git sparse-checkout arbeiten kann, damit das Arbeiten mit einem Monorepo überhaupt erst halbwegs ordentlich möglich ist.

Fazit

Wenn ihr nun diesen Blogpost gelesen habt, habt ihr vielleicht das Gefühl, dass die Vorteile den Nachteilen von Monorepos überwiegen und dies auch meine Einstellung ist. Tatsächlich ist diese Frage gar nicht so einfach zu beantworten.

Prinzipiell bin ich kein großer Fan von Monorepos. Die meisten Firmen dürften viel zu klein sein, um überhaupt die Vorteile von Monorepo-Ansätzen profitieren zu können. Die Nachteile überwiegen da häufig, da eher speziellere Tools für das Bauen und Verwalten der ganzen Toolchain gebraucht wird, die zu meist auch komplexer sind. Und ich meine hier ganz bewusst echte Monorepos und nicht Multi-Projekt-Repositorys. Die sind nicht ganz so komplex und umspannen in der Regel nicht völlig verschiedene Teams, Abteilungen die nichts miteinander zu tun haben.

Bei ganz großen Firmen sieht das natürlich anders aus, aber sehr viele ähnlich große Firmen die vergleichbar mit Microsoft, Google oder Twitter sind, gibt es dann doch eher seltener. Und die haben auch genug Personal, um spezielles eigenes Tooling zu entwickeln.

Was man hingegen nicht verleugnen sollte, ist der Fakt, dass an Git aktuell vor allem Verbesserung bei der Handhabung von großen Repositorys sichtbar ist. Da dürften noch viele weitere Neuigkeiten mit einfließen, so wie git sparse-checkout ein relativ neues Feature ist.

Unabhängig davon: Das Thema Monorepos haben Dirk und ich in unserem Podcast TILpod in Folge TIL006 besprochen mit einer etwas anderen Art und Weise.

Firefox bekommt Unterstützung für neue Bildformate. Neben der Unterstützung für AVIF, welche für Firefox 90 geplant ist, soll Firefox in Zukunft auch das neue Bildformat JPEG-XL (JXL) unterstützen.

Bereits seit längerer Zeit arbeitet Mozilla an der Unterstützung des neuen Bildformats AVIF in Firefox. AVIF steht für AV1 Image File Format und ist ein Bildformat, welches auf dem Video-Codec AV1 basiert und wie AV1 von AOMedia spezifiziert worden ist. Ähnlich wie AV1 bei Videos verspricht auch AVIF bei Bildern bei gleichbleibender Qualität deutlich geringere Dateigrößen als konkurrierende Formate wie JPG oder WebP. Die Aktivierung der AVIF-Unterstützung ist derzeit für Firefox 90 geplant. Firefox 90 wird nach aktueller Planung am 13. Juli 2021 erscheinen.

AVIF ist aber nicht das einzige neue Bildformat, welches Firefox in Zukunft unterstützen wird. Eine initiale Unterstützung für das von der Joint Photographic Experts Group entwickelte Bildformat JPEG-XL, kurz: JXL, ist in der Nightly-Version von Firefox 90 gelandet.

Bildformate Vergleich 2021
Bildquelle: cloudinary.com

Bei der Unterstützung von JPEG-XL in der Nightly-Version von Firefox 90 handelt es sich um eine erste Integration, bei der einige Features noch nicht implementiert sind. An einen produktiven Einsatz ist zu diesem Zeitpunkt also noch nicht zu denken. Standardmäßig ist die Unterstützung aus diesem Grund auch noch hinter dem Schalter image.jxl.enabled in about:config deaktiviert. Welche Firefox-Version JPEG-XL final unterstützen wird, lässt sich zu diesem Zeitpunkt noch nicht sagen. Mit Sicherheit wird es aber noch einige Monate dauern.

Der Beitrag Firefox bekommt Unterstützung für Bildformat JPEG-XL (JXL) erschien zuerst auf soeren-hentzschel.at.

Cyberchef (The Cyber Swiss Army Knife) hatte ich vor fast 4 Jahren auf ITrig erwähnt. Das Tool sagte mir damals wegen seiner praktischen Encoding beziehungsweise Decoding Funktionen zu.

Seitdem ist einige Zeit vergangen und Arbeitsweisen haben sich geändert. So verwende ich inzwischen unter anderem Visual Studio Code fürs tägliche Editieren. Durch die vielen Plugins ist der Editor sehr gut erweiterbar.

Genau hier kommt die Erweiterung Swiss Knife ins Spiel

 

VS Code – Swissknife

swissknife

Die Visual Studio Code Erweiterung von Luis Fontes beherrscht eine Menge an Funktionen, vom Hashes generieren, über Hex oder Base64 bis Markdown.

Das heißt eurer Editor wird mit wenigen Klicks um viele Alltagsanwendungen erweitert.

Folgende Funktionen beherrscht das Schweizer Messer für Visual Studio momentan:

  • Base64 decode

  • Base64 encode

  • Binary To Text

  • Bip39 Mnemonic

  • CSV to Markdown

  • Count characters

  • Count words

  • Crypto currency value

  • Date to Timestamp

  • Eliptic Curve Key Pair

  • Generate Password

  • HTML Encode (AlL)

  • Hex decode

  • Hex encode

  • Hex to RGB

  • Identify hash

  • JWT Decode

  • Join lines

  • Lorem Ipsum

  • Markdown to HTML

  • Md5 hash

  • New Swissknife Script (JS)

  • New Swissknife Script (TS)

  • Password strength

  • RGB To Hex

  • RSA Key pair

  • Random String

  • Request to fetch

  • SHA1 hash

  • SHA256 hash

  • SHA512 hash

  • Self Signed Certificate

  • Start Local HTTP Server

  • Start Local HTTPS Server

  • Stop HTTP Server

  • Text To Binary

  • Text to String

  • Timestamp to Date

  • To Camel Case

  • To Lower Case

  • To Morse code

  • To Upper Case

  • UUIDv4

  • Unicode decode

  • Unicode encode (js format)

  • Unix/Linux Permission To Human Readable

  • Url Decode

  • Url Encode

  • Url Encode (All Characters)

  • Url Shorten

  • Url Unshorten (url expand)

Die Funktionen lassen sich mit swissknife.show oder Strg+Shift+9 beziehungsweise cmd+shift+9 im Terminal aufrufen. (Text markieren vorher nicht vergessen).

Hat man die Tastenkombination einmal im Kopf erleichtert die Erweiterung das Arbeiten an vielen Stellen sehr, vorrausgesetzte die Anwendungsfälle kommen öfters vor.

Download swissknife

 

Wenn ich aktuell unter Arch Linux die OSS-Version des Editor VSCode starten will, startet diese zwar, friert sofort ein so dass man das Programm nur noch gewaltsam beenden kann. Die Lösung ist aber erfreulicherweise ziemlich einfach.

Öffnet man die Datei /usr/bin/code-oss mit einem Editor (vorzugsweise nicht VSCode ;-) ) sollte der Inhalt wie folgt aussehen.

ELECTRON_RUN_AS_NODE=1 exec electron11 /usr/lib/code/out/cli.js /usr/lib/code/code.js "$@"

Alles was man machen muss ist electron11 auf electron zu ändern. Danach sollte VSCode wieder normal starten.

Vermutlich handelt es sich hierbei um einen Bug seitens Arch Linux. VSCode benötigt als Abhängigkeit das Paket electron (aktuell Version 12). Mit diesem wird die Datei /usr/bin/electron installiert. Im Paket code wurde allerdings letzten Monat /usr/bin/electron auf /usr/bin/electron11 geändert (https://github.com/archlinux/svntogit-community/commit/412cf018280fd9b9f612eb84075354b9fe555af8). Vermutlich weil VSCode zu der Zeit noch von Version 11 von electron abhängig war. Und nach dem Update auf Version 12 wurde vermutlich vergessen es entsprechend anzupassen. Aber das ist nur eine Vermutung. Eventuell betrifft das Problem auch andere Distributionen (und ggf. auch die normale Version von VSCode)

15. Mai 2021

Die MZLA Technologies Corporation hat vor kurzem mit Thunderbird 78.10.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 78.10.1

Mit dem Update auf Thunderbird 78.10.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht. Neben einer Fehlerbehebung schafft das Update auch eine als moderat eingestufte Sicherheitslücke für Nutzer einer Windows-Version älter als Windows 10 Build 1709 aus der Welt.

Der Beitrag Thunderbird 78.10.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

14. Mai 2021

Die Veröffentlichung von Firefox 90 war ursprünglich für den 29. Juni 2021 vorgesehen. Nun hat Mozilla den Veröffentlichungstermin von Firefox 90 und allen nachfolgenden Versionen verschoben.

Zwischen neuen Feature-Updates von Firefox liegen normalerweise exakt vier Wochen. Bereits vor etwas mehr als einem Monat wurde entschieden, die Veröffentlichung von Firefox 89 und allen nachfolgenden Versionen um zwei Wochen nach hinten zu schieben. Nun kommt es zu einer weiteren Verschiebung: Auch zwischen Firefox 89 und Firefox 90 werden sechs statt der üblichen vier Wochen liegen. Neuer Veröffentlichungstermin für Firefox 90 ist damit der 13. Juli 2021.

Weiter wurde der Zeitraum zwischen Firefox 94 und Firefox 95 sowie zwischen Firefox 95 und Firefox 96 auf jeweils fünf Wochen angehoben.

Der Release-Kalender dieser Seite ist bereits an die neuen Daten angepasst.

Der Beitrag Mozilla verschiebt Firefox 90 erschien zuerst auf soeren-hentzschel.at.

Ein möglichst offenes und ein möglichst vertrauenswürdiges System widersprechen sich manchmal. Besonders deutlich wird dies beim Thema Verified Boot unter Linux.

Linux kennt mit LUKS/cm-crypt eine gute und sichere Verschlüsselungslösung. Man kann ein solchermaßen verschlüsseltes System sogar zusätzlich mit einem Hardware-Token wie z. B. einem YubiKey absichern. Doch woher weiß man beim Hochfahren eines Systems eigentlich, das man ein unverändertes System startet und nicht eine heimlich manipulierte Variante?

Ein sogenannter Verifizierter oder Vertrauenswürdiger Start (Verified / Trusted Boot) ist bei Mobilgeräten schon länger Standard. Der Ansatz ist – stark vereinfacht dargestellt – eine Vertrauenskette vom Bootloader, über die Boot-Partition bis hin zu den verifizierten System-Partitionen. Während des Systemstarts überprüft jede Stufe die Integrität und Sicherheit der nächsten Stufe, bevor sie übergibt. Erkennt das System eine Manipulation, führt es automatisch einen Rollback zur letzten verifizierten Version durch.

Klassische Desktop- oder Notebooksysteme kennen so etwas nicht. Das meist völlig ungesicherte BIOS erlaubt den Start von jedem beliebigen Medium und sofern man dabei nicht den Bootloader versehentlich zerstört, kann man so ziemlich alles mit dem System machen, was man möchte.

Apple hat das Prinzip des Verified Boot bereits vor längerer Zeit auf den Desktop gebracht mit den sogenannten T1/T2 Sicherheitschips. Der T1 brachte die Secure Enclave vom Mobilgerät auf das MacBook bzw. den iMac, der T2 brachte den sichereren Start.

Bei normaler Desktop-/Notebook-Hardware wäre so etwas theoretisch auch möglich. Microsoft hat vor einigen Jahren mit Secure Boot versucht, einige Schritte in diese Richtung zu unternehmen. Aus der ersten Debatte um diese Funktion hat sich leider in der Linux-Community das Gerücht gehalten, dass man Secure Boot immer deaktivieren sollte. Dabei funktionieren professionelle Linux-Distributionen schon lange mit Secure Boot (und alle anderen verwendet man sowieso nicht, wenn einem Sicherheit wichtig ist).

Alle heute verkauften Geräte haben zudem einen sogenannten TPM-Sicherheitschip (verdankt man den Basis-Anforderungen von Microsoft). Die neueste systemd-Version unterstützt nicht nur die Bindung der LUKS-Verschlüsselung an diesen TPM-Chip, sondern SUSE hat auch eine Implementierung von Trusted Boot für GRUB entwickelt (mehr Informationen dazu), die theoretisch mit dem TPM-Chip zusammen arbeitet.

Meiner Meinung nach sind das sinnvolle Schritte in die richtige Richtung. Wie immer stört das natürlich die Frickler und Bastler in der Community, aber wenn man im Bereich Sicherheit am Ball bleiben möchte, kann man diese Entwicklung nicht ignorieren.

Secure Boot ist unter openSUSE schon lange kein Problem mehr, mit der nächsten systemd-Version werde ich mein LUKS-Systemvolume auch an den TPM-Chip binden. Danach folgt dann TrustedGRUB/Trusted Boot aber hier scheint es noch wenige Erfahrungen und folglich auch wenige Bericht zu geben.

Der Artikel Verified Boot – Leerstelle unter Linux? erschien zuerst auf [Mer]Curius

12. Mai 2021

Seit Januar ist mein privates Haupt-Arbeitsgerät ein HP EliteBook G7 440. Die Linux-Kompatibilität ist hervorragend und das Gerät für mich perfekt. Firmware-Updates kann man auch als Linux-Anwender machen.

Die lange Unterstützung mit Firmware-Aktualisierungen ist eine der Stärken von Business-Notebooks. Egal ob sie von Lenovo, Dell oder eben HP stammen. Ein nicht zu unterschätzender Vorteil, da sich auch in der Firmware Sicherheitslücken und Bugs befinden können.

In meinem Bericht zum Gerät bemängelte ich damals die fehlende Unterstützung durch LVFS/fwupd. Prinzipiell ist das zwar eine tolle Infrastruktur, aber bisher habe ich noch kein Gerät gefunden, das dadurch mit Updates versorgt wird. Weder das alte ThinkPad, noch eben das neue EliteBook. Lediglich der Dongle meiner Logitech-Maus hat damit tatsächlich mal ein Update spendiert bekommen.

Allerdings wollte ich das letzte „BIOS“-Update nun wirklich haben, weil es Probleme mit den Tasten zur Helligkeitssteuerung unter Linux beseitigt. Ein bisschen Recherche brachte mich nun dazu, dass es viel einfacher als gedacht sein kann.

Im „BIOS“-Menü gibt es eine Funktion „BIOS-Update“. Sofern das Gerät per Ethernet mit dem Internet verbunden ist, lädt die Funktion alle Firmware-Updates für die verbaute Hardware (UEFI, SSD, Thunderbold, Intel ME) automatisch herunter und installiert sie. Völlig egal was für ein Betriebssystem installiert ist. Damit natürlich auch für Linux-Nutzer. Die Warnung für Nutzer der BitLocker-Verschlüsselung kann man dabei getrost überspringen.

Damit ist das letzte Manko an dem Gerät im Linux-Einsatz für mich beseitigt. Allerdings ist es natürlich eine Erinnerung daran, wie viele Funktionen sich inzwischen in der Firmware eines Notebooks (vom Hersteller oft noch „BIOS“ tituliert) befinden. Ein nicht zu unterschätzender Aspekt, wenn man über Privatsphäre und Datenschutz in Kombination mit Betriebssystemen diskutiert.

Der Artikel HP EliteBook G7 – Firmware Updates unter Linux erschien zuerst auf [Mer]Curius

11. Mai 2021

Föderierte Systeme sind in einigen Kreisen gerade sehr angesagt. Das Konzept ist nicht neu, hat aber mit Matrix (Element), Mastodon und anderen Instanzen des Fediverse inzwischen neue prominente Vertreter. Hinsichtlich Datenschutz und digitaler Privatsphäre haben diese Systeme aber strukturelle Probleme.

Föderiert vs. Zentral

Föderierte Systeme sind das Gegenteil von zentralisierten Systemen, die von ihren Kritikern auch gerne als „Walled Gardens“ bezeichnet werden. Zentralisierte Systeme werden so bezeichnet, da in ihrem Kern eine zentral verwaltete Serverinfrastruktur steht, über welche die beteiligten Clients miteinander kommunizieren. Das System nutzen nahezu alle proprietären Dienste, aber auch freie Systeme wie Signal.

Föderierte Systeme bestehen dagegen aus einem Netz unabhängiger Server, auf denen dieselbe bzw. eine kompatible Software läuft, die miteinander kommunizieren und gewissermaßen ein Netz bilden. Das System kennt eigentlich jeder Anwender, da die E-Mail so funktioniert. Praktisch gesagt: Während man von WhatsApp zu Signal keine Nachricht schreiben kann, geht das von GoogleMail zu Posteo natürlich schon. Im Messenger-Bereich ist es auch nichts wirklich neues, denn XMPP („Jabber“) funktioniert ebenfalls nach diesem System.

Ein föderiertes System ist beim Aspekt der Unabhängigkeit vom zentralen Anbieter unschlagbar. Es wird deshalb vor allem von Befürwortern der digitalen Souveränität gerne hervorgehoben. Bei zentralisierten Systemen wie z. B. Signal hängt alles vom zentralen Betreiber ab. Schaltet Signal seine Server ab, ist das Kommunikationsnetz Signal Geschichte. Die Serversoftware ist zwar quelloffen, aber ein neuer Betreiber könnte nicht automatisch an die Stelle des ehemaligen zentralen Betreibers treten.

Risiken offener Protokolle

Ein grundlegendes Risiko dieser offenen Protokolle zeigt schon ein Blick auf die Geschichte von XMPP. Ist die Entwicklung noch jung, gibt es meist nur einige wenige Clients und eine Serversoftware. Die Zahl der Betreiber und Nutzer ist ebenso noch recht gering. Neue Funktionen und Änderungen am Protokoll werden schnell verteilt und erreichen schnell alle beteiligten Anwender.

Mit der Zeit differenzieren sich die Softwarelösungen aber immer mehr aus. Genau das finden die Befürworter solcher Systeme ja auch gut. Änderungen und sinnvolle Weiterentwicklungen brauchen immer mehr Zeit, um alle Beteiligten zu erreichen. Es wird immer mehr zurückhängende Instanzen geben und Inkompatibilitäten im Netzwerk.

Ein Beispiel dafür ist die Einführung von OMEMO bei XMPP, die bis heute nicht alle Clients erreicht hat. Ein anderes Beispiel ist die klassische E-Mail, wo immer noch nicht alle Server standardmäßig Transportverschlüsselung anbieten. Kunden von Posteo konnten vor einigen Jahren einstellen, dass eine E-Mail nicht verschickt wurde, wenn die Gegenseite keine Transportverschlüsselung gewährleistete. Das waren insbesondere in der Anfangszeit ganz schön viele, ist mit der Zeit aber natürlich weniger geworden.

Systembedingte Probleme

Die Zeit kann aber nicht alle Probleme lösen. Einige Schwierigkeiten sind systemimmanent und können nicht sinnvoll überwunden werden. Sobald man Matrix nutzt, ist man Teil des föderierten Netzwerkes. Die einzelnen Instanzen müssen miteinander Daten austauschen können, da man ansonsten nur mit anderen Anwendern des Servers kommunizieren könnte, auf dem man selbst registriert ist.

Während man bei einem zentralisierten Anbieter wie Signal nur einem Anbieter vertrauen muss, bedarf der Einsatz von Matrix Vertrauen in alle Anbieter von Matrix-Serverinfrastruktur. Das ist umso gefährlicher, weil Metadaten-Vermeidung strukturell bei verteilten Infrastrukturen aufgrund der Einbeziehung vieler Server und Clients schwierig ist.

Ein paar praktische Beispiele: Alle an einer Kommunikation beteiligten Matrix-Server speichern beispielsweise theoretisch unbegrenzt die komplette Kommunikation. Umso bedenklicher, da einige Clients des heterogenen Ökosystems (siehe Nachteile solcher Netzwerke oben) wie KDEs NeoChat nicht mal Verschlüsselung beherrschen. Gleichwohl würde das sowieso nur die Inhalte und nicht die Metadaten schützen. Man kann Nachrichten zwar löschen, aber technisch handelt es sich dabei lediglich um eine Art „Löschwunsch“ an andere Server, ob diese das auch umsetzen, entzieht sich der Kontrolle.

Der Homeserver, auf dem man sein Konto angelegt hat, speichert zudem noch deutlich mehr: Kontaktliste, Mitgliedschaften in Gruppenchats, Nachrichtenverläufe usw. Diesem Betreiber muss man extrem vertrauen. Allerdings hat man hier wenigstens ein wenig Steuerungsmöglichkeit.

Nicht das Ende der Probleme

Dabei handelt es sich noch nicht mal um das Ende der Fahnenstange. Es gab im Gegensatz zu Signal oder Threema keinen Audit der kompletten Infrastruktur, sondern nur 2016 der E2E-Verschlüsselungslösung. Die Implementierung von E2E-Verschlüsselung in den Clients steht noch auf einem ganz anderen Papier. Oft ist ja nicht die Verschlüsselung das Problem, sondern die Umsetzung im Client. Ein Problem das vor allem bei so heterogenen Ökosystemen natürlich zum Problem wird, weil man nicht weiß was die anderen Beteiligten für Software nutzen.

Die Finanz- und Entwicklungsstruktur der zentralen Bausteine sind auch kein Beispiel für Transparenz. Matrix bzw. Element (ehm. Riot) wird primär von der New Vector Ltd. entwickelt. Eine Firma, die nicht gerade die transparenteste Finanzsituation hat. Hier ist man gegenüber Signal oder auch Telegram nicht im Vorteil.

Alles schlecht? Nein, aber die falsche Außendarstellung

Sind föderierte Kommunikationssysteme im Allgemeinen und Matrix im Speziellen deshalb schlecht? Nein! Zumindest wenn man die richtige Perspektive wählt und keine falschen Erwartungen weckt.

Zentrale Systeme haben Nachteile, weil man sich abhängig von einem Betreiber macht. Im Hinblick auf eine digitale Souveränität des Individuums, kleiner Gruppen, Firmen oder gar Staaten können föderale Systeme einen Ausweg bieten. Je nach Anforderungen und Wünschen ist das ein interessantes Angebot.

Das hat aber alles nichts – wirklich gar nichts – mit Datenschutz und digitaler Privatsphäre zu tun! Wer bei dieser langen Liste von Defiziten und Problemen zum aktuellen Zeitpunkt Matrix als Privatsphären- und Datenschutz-freundliche Alternative zu Signal oder Threema bewirbt, hat ganz gewaltige Scheuklappen auf. Ich finde es erschreckend wie viele Kommentatoren sich hier vom Begriff der digitalen Souveränität und dem Open Source-Charakter blenden lassen.

Der Artikel Föderierte Messenger – Konzeptionelle Probleme am Beispiel Matrix erschien zuerst auf [Mer]Curius

Das Ikhayateam von ubuntuusers.de hat mein Blog im Planet aufgenommen. Vielen Dank für die Ehre.
Mein Name ist Andreas und ich nutze Ubuntu GNU/Linux seit 2005 auf meinen Computern. In der Linux-Community bin ich auch als waldstepper bekannt.

Ich schreibe unregelmäßig über Meine Erfahrungen mit Linux in meinem Blog. Ich wünsche euch viel Spaß beim Lesen meiner Artikel.

10. Mai 2021

Über World of Padman las man lange nichts hier bei Zockertown.

Aus gegebenen Anlaß will ich das hier nachholen.

Wann war eure letzte Lan Party? Sicherlich einige Jahre her, oder?​

Auf meiner lezten Lan Party war auch die eine oder andere WoP Session drin.

Schön zu lesen, dass sich das alte Team wieder aufgerafft hat und wieder an die Arbeit geht!

worldofpadman.net/news/wop-team-back-in-action

Ich liebe diesen Fun Shooter über alle Maßen. Wenn es hier Neues gibt, schreibe ich das hier.

In diesem Beitrag dokumentiere ich eine Lösung für die Meldung: „554 5.7.1 REJECT policy violation – too many different Display Names – code #242 (in reply to end of DATA command)“

Umgebung

Ich betreibe einen Virtual Private Server (VPS) im Internet, sowie einige Raspberry Pis und weitere Geräte, die man heute wohl am ehesten dem Internet der Dinge zuordnen würde.

Diese Systeme sollen mir Systemmeldungen per E-Mail senden. Dafür habe ich mir ein günstiges E-Mail-Postfach bei Mailbox.org gebucht und auf den betroffenen Systemen Postfix installiert und zum Versand über einen Smarthost konfiguriert. Die Konfiguration erfolgte über die Ansible-Rolle relaymail von Yannik. Diese dient jedoch nur als Werkzeug. Die Konfiguration kann selbstverständlich auch manuell durchgeführt werden.

Problembeschreibung

Bei einer Systemüberprüfung fielen mir einige Fehlermeldungen der folgenden Art ins Auge (einige Werte durch <Platzhalter> ersetzt):

„<Hostname und IP-Adresse> said: 554 5.7.1 id=<ID> – Rejected by next-hop MTA on relaying, from MTA(smtp:[<IP-Adresse>]:10025): 554 5.7.1 REJECT policy violation – too many different Display Names – code #242 (in reply to end of DATA command)“

Weitere Informationen zu dieser Meldung und deren Ursache finden sich im Mailbox.org-Benutzerforum in: „mailbox.org als smtp Relay nutzen“

Während meine Raspberry Pis mit Raspbian GNU/Linux 10 (buster) und Postfix 3.4.14-0+deb10u1 sich wie erwartet verhalten und lediglich meine E-Mail-Adresse in das Header-Feld „From“ eintragen, fügt mein VPS mit Debian GNU/Linux 10 (buster) und Postfix 3.4.14-0+deb10u1 den Namen des jeweiligen Benutzers bzw. Dienstes mit ein, welcher die E-Mail versenden möchte. Diese Informationen nimmt der VPS aus dem Kommentarfeld der /etc/passwd. Während die Kommentarfelder auf meinen Raspberry Pis leer sind, sind diese auf dem VPS entsprechend gefüllt.

Im E-Mail-Header stellt sich das dann wie folgt dar.

Header-Auszug bei E-Mail von Raspberry Pi

Date: Mon, 10 May 2021 04:56:32 +0200 (CEST)
From: no-reply@example.com

Header-Auszüge bei E-Mails vom VPS

From: no-reply@example.com (Cron Daemon)
To: root
Date: Mon, 10 May 2021 04:44:12 +0200 (CEST)
From: Jörg Kastning <no-reply@example.com>
Date: Mon, 10 May 2021 04:44:36 +0200 (CEST)
From: root <no-reply@example.com>

Lösung

Um das Problem aufzulösen, lasse ich nun Postfix das Header-Feld „From“ umschreiben und explizit auf den Wert no-reply@example.com setzen. In der /etc/postfix/main.cf müssen dazu folgende Zeilen vorhanden sein:

sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps =  regexp:/etc/postfix/sender_canonical_maps
smtp_header_checks = regexp:/etc/postfix/header_check

Inhalt der /etc/postfix/sender_canonical_maps:

/.+/    no-reply@example.com

Dies sorgt dafür, dass Postfix das Feld „Envelope-From“ explizit auf no-reply@example.com setzt.

Inhalt der /etc/postfix/header_check:

/From:.*/ REPLACE From: no-reply@example.com

Hiermit wird der Wert des Header-Felds „From“ explizit auf no-reply@example.com gesetzt. Die Lösung habe ich hier gefunden. Damit läuft der Versand meiner Systembenachrichtigungen wieder.

Weitere Artikel zu Postfix und Smarthosts in diesem Blog

9. Mai 2021

Wir erheben nur Metadaten“ – Wie oft hat man diesen Satz in den letzten Jahren gehört. Dabei sind Metadaten das wahrlich interessante und Metadaten-Vermeidung, die hohe Kunst. Dieser Aspekt ist leider in der Praxis oft immer noch im toten Winkel der Debatte.

Definition: Metadaten oder Metainformationen sind strukturierte Daten, die Informationen über andere Daten enthalten. Das kann ganz unterschiedliche Bereiche umfassen. Im hier behandelten Kontext meint es Informationen wie Wer, wann, wo, mit wem, worüber usw.

Ein lange bekanntes Problem

Bei jeder Novelle der Überwachungsgesetze und bei jedem Skandal um Telemetrie-Datenerhebung durch Firmen kommt zuverlässig das Argument, dass man nur Metadaten sammeln würde und die Inhalte nicht tangiert wären. Die meisten Menschen sind dann beruhigt, weil sie glauben, ihre wahrhaft sensiblen Daten wären weiterhin geschützt. Weit gefehlt!

Für einen Einstieg in die Materie empfiehlt sich immer noch ein Artikel auf netzpolitik.org von 2014: Wie dein unschuldiges Smartphone fast dein ganzes Leben an den Geheimdienst übermittelt. Ergänzend dazu ein Bericht der SZ von 2014 was sich aus Telefonüberwachung ableiten lässt: Die Lüge von den Metadaten. Wohin die Sammlung von Metadaten führen kann, hat die ZEIT 2015 eindrücklich dargelegt: BND speichert 220 Millionen Telefondaten – jeden Tag.

Die Berichte entstammen der Hochphase der Globalen Spionage- und Überwachungsaffäre, aber der Sachverhalt hat sich seitdem kaum geändert. Immer noch sammeln Firmen und Geheimdienste systematisch Metadaten, immer noch beschwichtigen Politiker und immer noch glauben die meisten Menschen, ihre Kommunikationsinhalte wären das wirklich schützenswerte.

Das ist verständlich, weil die Inhalte vermeintlich unsere Vorlieben, Interessen, Ziele, Wünsche und Träume enthalten, aber unsinnig, denn die Kommunikationsinhalte sind bei den meisten Menschen völlig uninteressant und ohne Kontext auch meistens wenig aussagekräftig. Wirklich interessant für Firmen und den westlichen Überwachungsstaat sind die Metadaten. Denn sie geben Auskunft über Bewegungsprofile, Netzwerke und Verbindungen.

Zumindest gegenwärtig lassen sich Metadaten auch immer noch leichter automatisiert auswerten als Video-, Sprach- oder Textinhalte. Wobei angesichts der Fortschritte in der automatischen Spracherkennung und Inhaltserschließung das bald hinfällig sein könnte.

Wir erzeugen mehr und nicht weniger Metadaten

Die oben referenzierten Artikel sind alle 6-7 Jahre alt. Damals wurde nur das Bewegungsprofil, Internet, WhatsApp und E-Mail berücksichtigt. Smart Watches, intelligente Fitness-Armbänder, Smarte Lautsprecher, Smarte Autos – all diese Entwicklungen waren noch nicht so weit wie heute. Das Ausmaß der genutzten Dienste und die Zahl der Sensoren im Smartphone hat seitdem somit definitiv noch zugenommen.

Im Unterschied zu den Inhalten kann man Metadaten nicht vermeiden, indem man selbst ein bisschen verschlüsselt und ein wenig sensibler im Umgang mit seinen Daten ist. Möglicherweise ist das Thema auch deshalb so wenig im Fokus, weil es ein Ohnmachtsgefühl auslöst. Bei den Inhalten kann der Einzelne aktiv werden und zu wirkungsvoller Verschlüsselung greifen. Dabei gibt es erfolgversprechende Verfahren, bei denen wir mit großer Wahrscheinlichkeit davon ausgehen könnten, hinterher unsere Inhalte effektiv geschützt zu haben.

Um Metadaten zu reduzieren, hilft es nur Dienste zu nutzen, die genau diese Daten vermeiden. Mit ein bisschen Verschlüsselung seiner Dateien im kommerziellen Cloud-Dienstleister oder der Inhalte seiner E-Mails beim gleichen Anbieter kommt man da nicht weiter.

Umdenken nicht in Sicht

Eine komplette Änderung alle Gewohnheiten und Dienste kann man von niemandem verlangen. Bei neuen Diensten oder Geräten sollte man diesen Faktor aber endlich berücksichtigen. Die Erkenntnis wie wichtig und gefährlich Metadaten sind, ist schließlich alt genug.

Es gibt gute und verbreitete Dienste, die sich zumindest des Problems angenommen haben. Die Signal-Entwickler beschäftigen sich seit Jahren mit der Reduzierung und Vermeidung von Metadaten. Bei Threema hat man dieses Problem auch immer beachtet. Wer freie Software bevorzugt, hat ebenfalls Alternativen: Die Vermeidung von Metadaten als Konzept gilt auch für den besonders sicheren Messenger Briar.

Viele andere Dienste tun dies nicht. Einerseits weil die Vermeidung von Metadaten kompliziert ist, andererseits weil es bei vielen Entwicklern keine Priorität hat. Das gilt natürlich für viele kommerzielle Dienste, aber auch für die neuen Lieblinge der verschränkten FOSS/Datenschutz-Community.

Die neuen föderierten Messenger (z. B. Delta Chat / Matrix) sind strukturell bedingt genau so ungeeignet für die Vermeidung von Metadaten wie XMPP und E-Mail vor ihnen. Die Vernetzung eines föderierten Systems benötigt einfach systembedingt Metadaten und bringt einen Kontrollverlust mit sich, weil man den Serverbetreibern vertrauen muss.

Vor allem den Hype um die neuen föderierten Protokolle kann ich unter diesem Gesichtspunkt nicht verstehen. Hier werden zu offensiv Konzepte vermischt, die sich nicht immer vertragen: Digitale Souveränität und Datenschutz. Man mag auf die alten Protokolle, wie beispielsweise die E-Mail, nicht verzichten können, aber muss doch nicht sehenden Auges im Bewusstsein der hier beschrieben Problematik neue Protokolle etablieren, die genau die gleichen strukturellen Probleme haben.

Zusammengefasst

Metadaten sind das wirkliche Problem. Sie sind für alle Feinde unserer digitalen Sicherheit und unserer Privatsphäre interessant, wir erzeugen immer mehr davon und das Problem steht zu wenig im Fokus. Verschlüsselung ist nett und so lange sie mit wenig Aufwand zu realisieren ist, auch ratsam – sie geht aber am Kernproblem vorbei. Das gilt auch für die neuen gehypten Dienste.

Der Artikel Metadaten – Immer noch zu wenig beachtet erschien zuerst auf [Mer]Curius

Fail2ban kann genutzt werden um Server gegen unbefugte Logins zu sichern. Dabei durchsucht Fail2ban die entsprechenden Logs und blockiert böswillige Versuche in das System einzubrechen. Damit gehört Fail2ban zu den Intrusion Prevention Systemen.

Manchmal kommt es allerdings vor das eine IP-Adresse gesperrt wird, welche nicht gesperrt werden sollte. Problematisch ist dies z.B., wenn es die eigene IP-Adresse ist. Der Fail2ban-Client bietet hierfür eine Operation an um IP-Adressen wieder zu entsperren:

fail2ban-client unban 192.168.1.2

Damit wird die entsprechende IP-Adresse von der Sperrliste gelöscht und die Firewall-Regel entfernt. Anschließend ist besagte IP-Adresse wieder in der Lage auf den Server zuzugreifen.

8. Mai 2021

Audacity soll nach der Übernahme durch die Muse Group Telemetriefunktionen erhalten. Ein Kommentar über den Sinn und Unsinn solcher Funktionen, Diskussionen und Übernahmen von Open Source-Projekten.

Vor einigen Tagen ging die Meldung durch den Ticker, dass die Audiobearbeitungssoftware Audacity (Link zu audacityteam.org) durch Muse Group gekauft wurde. (LinuxNews und heise.de berichteten). Ich war über diese Meldung etwas überrascht, weil es etwas seltsam ist, ein OSS-Projekt zu „kaufen“. Die Software an sich ist GPLv2-lizenziert und ansonsten lässt sich lediglich eine US-Wortmarke finden. Ich konnte nicht einmal eine deutsche/europäische Marke hierzu ausfindig machen. Es geht bei dem Vorhaben der Muse Group sicherlich eher darum, den Einfluss auf die Entwicklung von Audacity auszubauen, um das eigene Produktportfolio zu erweitern.

Tantacrul hat diesbezüglich ein 15-minütiges Video zu seinen neuen Aufgaben erstellt, das auf YouTube verfügbar ist.

Es ist sehr zu begrüßen, dass ein Unternehmen die Mittel bereitstellt, eine Software wie Audacity weiterzuentwickeln. Ein Vorteil von kommerziell getriebener Entwicklung ist es, dass Leute dafür bezahlt werden, die unschöne, aber nötige Arbeit zu erledigen, um die Qualität beim Gesamtprodukt zu steigern. Auf der anderen Seite tauchen natürlich bei einer solchen „Übernahme“, die sich bei so einem Projekt immer noch ungewohnt anhört, Befürchtungen auf, dass Interessenkonflikte zu einer Strategieänderung bei der Entwicklung führen. Darüber hinaus ändert sich mitunter die Kultur der Entwicklung und die Gemeinschaft wird mit neuen Vorstellungen konfrontiert.

Dass es irgendwann Krach gibt, habe ich nicht ausgeschlossen. Dass es aber so schnell geht, hätte ich auch nicht gedacht. Am Dienstag, dem 04. Mai wurde ein Pull Request eröffnet, der den Namen „Basic telemetry for the Audacity“ trägt. Zum Zeitpunkt, an dem ich diesen Artikel hier schreibe, umfasst der Diskussionsthread schon über 850 Beiträge und wurde als „Draft“ zurückgestuft. Bei diesem offenbar kontrovers diskutierten Thema geht es darum, Audacity Telemetriefunktionen zu verpassen.

Ich könnte jetzt mit euch die konkreten Änderungen Stück für Stück auseinander nehmen, aber die dort verknüpften GitHub-Kommentare (besonders die Emojis) sprechen für sich. Alle, die einen C++-Hintergrund haben und CMake kennen, können sich die Implementierung zu Gemüte führen. Ich werde an geeigneter Stelle vereinzelt darauf eingehen.

Ein Glaubenskrieg

Telemetrie ist immer ein heikles Thema, besonders in der Open-Source-Welt. Hierbei geht es darum, die Nutzungsweise der Software an eine zentrale Stelle, dem Hersteller, zu melden, damit dieser Schlüsse daraus ziehen kann. Geht man noch einen Schritt weiter zurück, geht es darum, die Nutzung der Software messbar zu machen. Dies ist besonders im Management beliebt, da es Außenstehenden die Möglichkeit gibt, die Nutzung der Software zu analysieren und die Entwicklung zu regeln. Fragen wie „Entwickle ich an der richtigen Stelle?“, „Wollen die Nutzer das?“ oder „Haben wir genug Nutzer?“ sollen damit beantwortet werden.

In der vollen Ausbaustufe gleicht die Telemetrie einer Bildschirmaufnahme, bei der jeder Klick, jede Eingabe und jede Ausgabe an den Hersteller versendet werden. Das alles ist bei dem oben genannten Pull Request nicht der Fall, wie das Team nachdrücklich beteuert. Datenschutzrechtliche Aspekte lasse ich in dieser Betrachtung erst einmal außen vor, weil diese Diskussion das eigentliche Problem verschleiert.

Das Problem an diesem gesamten Umstand mit der Telemetrie ist, dass FOSS, also freie, offene Software, vom „mündigen Anwender“ ausgeht. Ich habe dieses Thema schon mal im Blog thematisiert. Dabei wird eine sehr aufgeklärte Weltanschauung vertreten: hat ein Anwender ein Problem, meldet er sich in einem Issue Tracker oder der Mailing Liste. Nur hat dieses Wunschdenken nichts mehr mit der Realität zu tun, vor allem, wenn die Zielgruppe nicht größtenteils aus Softwareentwicklern besteht, die diese Verfahrenswege kennen. Jetzt gibt es zwei Möglichkeiten: entweder auf das Feedback verzichten oder andere Wege finden, die Metriken zu erheben. Die Metriken sind zudem nur dann aussagekräftig, wenn sie eine repräsentative Nutzermenge abbilden - ergo: man müsste sie bei allen erzwingen.

Erschwerend kommt bei Audacity dazu, dass wir es hier mit einer Offline-Anwendung zu tun haben. Ist man es bei Webseiten gewohnt, dass die Inanspruchnahme von solchen zwangsläufig Verkehrsdaten erzeugt (seien es die Browserhistory, Logfiles auf dem Server, Analytics, o. ä.), so erwartet man bei lokaler Software nicht, dass diese „nach Hause telefoniert“. Zumindest früher.

Genau das soll bei Audacity jetzt allerdings passieren. Hierzu wurde extra die cURL-Bibliothek in den Source Tree eingefügt, was nebenbei noch eine komplett neue Abhängigkeit mit sich bringt. Diese Abhängigkeit wurde sogar sehr brachial hinzugefügt, wie aus dem diff hervorgeht, da während des Bauens sich Inhalte aus dem Git-Repository heruntergeladen werden sollen.

Die Telemetriedaten werden an ein zentrales Konto bei Google Analytics und Yandex geschickt.

FOSS-Prinzipein

Hier ergibt sich teilweise ein Bruch mit den üblichen FOSS-Prinzipien. Bei FOSS gibt man seinen Quelltext nicht frei, damit andere in diesem lediglich Lesen können, sondern, damit andere ihn in ihre Systeme integrieren können. Nutze ich z. B. den NetworkManager, der einen Connectivity Check durchführt, um zu erkennen, ob ich in das Internet komme, wird als Endpunkt meist ein von meinem Distributor bereitgestellter Server genutzt. Der Distributor ist es auch, dem ich mein ultimatives Vertrauen schenken muss, da dieser oft vorkompilierte Pakete bereitstellt. Ist ein Build nicht reproduzierbar, kann ich als Anwender nicht zweifelsfrei feststellen, ob lediglich die Inhalte ausgeführt werden, die auch angegeben sind. Unter diesem Aspekt ist der Umstand, dass der Distributor durch oben genannte Connectivity Checks meine IP-Adresse erfahren kann, fast zu vernachlässigen.

Freie Open Source Programme sind somit nur Bausteine, die von einem Intermediär aufbereitet und zur Verfügung gestellt werden. Somit sollte es aus meiner Sicht faktisch keinen Durchgriff von FOSS-Maintainern auf die Endnutzer geben, sofern nicht ein triftiger Grund dafür spricht.

Ein solcher triftiger Grund wären in meinen Augen Crashdumps: stürzt ein Programm ab, bieten einige Programme die Möglichkeit an, hilfreiche Daten zur Crash-Ursache (Tracebacks, Umgebungsvariablen, etc.) an die Hersteller zu melden. Oftmals wird dem Nutzer hier die Wahl gelassen, ob er diese Informationen mit den Entwicklern teilen möchte.

FOSS-Geschäftsmodelle

Freilich ist es schwierig, Geschäftsmodelle bei einer solch schwierigen Beziehung zwischen Softwarehersteller und -anwender zu etablieren. Dabei ist die „letzte Meile“ zwischen Distributor/OEM und Endkunden am attraktivsten, da dort Support verkauft werden kann. Beste Beispiele sind hier Red Hat und SUSE. Red Hat wurde für 34 Milliarden US-Dollar an IBM verkauft und der in Deutschland ansässigen SUSE GmbH steht am 19. Mai ein mit 5,7 Milliarden Euro bewerteter Börsengang bevor. Das bloße Schaffen und (entgeltliche) Zurverfügungstellen von Softwarequelltext und den Binaries wird heutzutage immer unattraktiver.

Fazit

Was Audacity angeht, bin ich optimistisch. Am Ende kann der Anwender nur gewinnen: entweder wird die Software verbessert oder es bildet sich ein Fork (wie schon geschehen), der die Nutzerschaft übernimmt.

Audacity ist eine Software, die ihren Zweck erfüllt. In meinen Augen kein Anwärter für Designauszeichnungen, aber plattformübergreifend und funktional.

Trotzdem muss man schauen, wie sich Audacity nun weiterentwickelt. Meine Prognose ist, dass die nächste Änderung, die ähnliche Kritik hervorruft, ein Auto-Updater wie bei MuseScore sein wird. ;-)

Lesen ist etwas, was ich generell viel zu wenig mache. Auf gedruckten Papier habe ich seit Ewigkeiten nicht mehr gelesen. Schon seit einigen Jahre besitze ich zwar einen Kindle Paperwhite von Amazon, aber die Nutzung variierte stark. Mal mehr, mal gar nicht.

Ein paar Gründe führten zu dem Umstand, dass ich das Kindle weniger genutzt habe:

  • Es ist von Amazon und ich versuche aus verschiedenen Gründen so wenig bei Amazon wie möglich zu kaufen. Vor allem keine Bücher, da dann am wenigstens beim Autor hängen bleibt. (Kauft am besten beim Verlag!)
  • Keine Unterstützung für .epub und somit Zwang auf Tools wie Calibre zu setzen.
  • Keine (gute) Unterstützung für PDF-Dateien.
  • Keine (gute) Möglichkeit Annotationen an Dokumenten zu erstellen.

Die letzten beiden Use-Cases sind speziellere Funktionen die ich nicht so häufig brauche. Als Autor und somit bei der Arbeit an der dritten Auflage meines Git Buches muss ich mehrfach vor der Drucklegung die Fahne Korrekturlesen. Ich weiß, dass beim Verlag sehr viel gedruckt wird, weil es sich einfach besser liest als auf einem Bildschirm und dann mit Stift Anmerkungen gemacht werden. Ich hatte das eine Weile lang auf einem Android Tablet gemacht, das war aber wegen des Displays eher auf der Kategorie „nicht so geil zum Lesen“. Notizen für Korrekturen waren auch eher umständlich und zudem besitze ich gar kein Tablet mehr.

Ich wollte also mehr Lesen und wollte auch die Möglichkeit haben, Notizen machen zu können, idealerweise mit Stift.

Zur Wahl standen letztendlich drei Geräte:

Alle drei Geräte sind E-Book-Reader mit guter Funktionalität um Notizen machen zu können. Das reine Lesen von Büchern ist ja eher der langweilige Part. Alle Geräte besitzen ein 10,3" großes Display. Die Größe war wichtig, damit das Machen von Notizen auf einem nicht ganz so kleinem Gerät erfolgen muss. Ich hatte zwar Angst, dass es zu groß sein könnte, aber das war dann doch passend.

Gekauft habe ich letztendlich das Onyx BOOX Note 3. Und hab mich im Wesentlichen gegen ein reMarkable entschieden, was die eher bekanntere Marke ist. Meine Gründe sind folgende:

  • Das reMarkable ist an die Hersteller-Cloud gebunden (Minus-Punkt)
  • Das Onyx BOOX läuft mit Android und ohne Zwang zur Bindung an Google (Plus-Punkt)
  • Das Onyx BOOX kann ohne Hersteller-Cloud und somit relativ „frei“ betrieben werden
  • Kollege Dirk hatte mal ein reMarkable 1 und kaufte sich später ein Onyx BOOX Max 3, darüber schreibt er auch in seinem Blog, und ist sehr zufrieden (Plus-Punkt)

Der Preis war natürlich nicht ganz so klein, aber man gönnt sich ja sonst nichts.

Grundsätzlich hat sich der Kauf gelohnt, es tut genau das, was es soll und es kommen auch Updates mit weiteren Funktionen. Die Notiz-Funktion habe ich nicht nur für die Korrekturen an meinem Buch genutzt, sondern auch für generelle Notizen, um ablenkungsfrei Nachdenken zu können. Die App dafür hat sehr viele Funktionen, wovon ich für meinen Zweck nicht so viel brauche.

Diejenigen die sich für richtig tiefe Reviews für solche Geräte interessiert, denen kann ich den YouTube-Kanal My Deep Guide empfehlen, wo der Herr die verschiedensten E-Book-Reader miteinander vergleicht. Es gibt einen sehr guten Eindruck was die Geräte können und in welchen Aspekten die Geräte besser als die anderen sind.

Die Anzahl an Android Apps hab ich gering gehalten. Über den F-Droid Store habe ich lediglich einen anderen Browser und den Nextcloud-Client für Datentransfers installiert und das klappt wunderbar.

Ein Use-Case den ich beim Kauf noch nicht im Blick hatte, ist, dass ich über meinen Arbeitgeber Zugang zur O’Reilly Learning Platform bekommen habe. Da gibt es nicht nur Bücher zu lesen, sondern auch Video-Kurse sind dort enthalten. Und das sind nicht nur Bücher von O’Reilly, sondern auch deutsche Verlage wie dpunkt oder mitp sind vertreten, sodass ich da auch mein Buch entdeckt habe. Die Inhalte lassen sich entweder im Browser lesen oder über die eigene App, ansonsten bekommt man die Daten da nicht so einfach raus, da es quasi eher dem Netflix-Modell entspricht. Die App konnte ich mir also auf mein E-Book-Reader geladen und konnte so schon einige Bücher lesen, die ich auf jeden Fall nicht im Browser am Bildschirm gelesen hätte. Vertraut mir, ich habs versucht…

tl;dr: Onyx BOOX Note 3 für relativ viel Geld gekauft. Ich lese jetzt deutlich mehr. Es deckt meine Use-Cases gut ab. Es nervt nicht. Notizen machen per Stift fühlt sich erstaunlich „echt“ an. Gerne wieder.

7. Mai 2021

OpenSUSE und YaST sind in vielen Artikeln und Meinungsäußerungen untrennbar miteinander verbunden. Man braucht aber kein YaST und kann es sogar komplett deinstallieren.

OpenSUSE ist meine präferierte Distribution. Das hat vermutlich viel mit Gewohnheit zu tun, aber auch damit, dass Leap oder Tumbleweed meistens für meine Einsatzzwecke reichen. Momentan bin ich mit Tumbleweed unterwegs, da meine Hardware durch den alten Leap-Kernel nicht unterstützt wird. Eigentlich hatte ich vor, schnellstmöglich wieder auf eine LTS zu wechseln, aber daraus wird wohl nichts werden.

OpenSUSE gilt bei seinen Kritikern immer als fett und behäbig. Diese Ausdrücke sprechen für ein Gefühl, denn im Grunde genommen unterscheiden sich die Speicherplatzbedarfe der meisten Linux-Distributionen kaum und vieles hängt von der installierten Software ab. Zypper ist auf der Kommandozeile zudem viel schneller als beispielsweise die behäbigen Routinen von APT.

Nur YaST ist wirklich langsam. Das ist auch der Grund, weshalb ich so gut wie nie mit YaST arbeite. Man muss auch schon sehr lange nicht mehr zwingend irgendetwas in YaST konfigurieren, weil alle Einstellungen in den üblichen Konfigurationsdateien geschrieben werden.

Puristen stören sich zudem oft an den vielen doppelten Funktionen. Drucker kann man z. B. in den Einstellungen von KDE/GNOME konfigurieren und in YaST.

Das Schöne ist: Bei openSUSE hat man aber nicht nur die Freiheit YaST nicht zu nutzen, man kann es auch komplett deinstallieren. Man setzt bei openSUSE nämlich keine unnötigen harten Abhängigkeiten (man kann bei der GNOME-Variante z. B. auch Nautilus oder das GNOME Terminal entfernen ohne die Kern-Metapakete zu brechen) und ermöglicht so wirklich schlanke System. Voraussetzung für den schlanken Betrieb ist bei openSUSE natürlich, dass man die automatische Installation empfohlener Abhängigkeiten deaktiviert hat.

Kleiner Exkurs: Hier darf man sich als Anwender nicht täuschen lassen von vermeintlich kleinteiliger Paketierung oder einem wie auch immer gearteten Ruf in der Community. Das ist ein Irrtum, dem schon viele aufgesessen sind. Debian ist ein Beispiel für ein pseudo-schlankes System, das durch die Unterteilung in viele Subpakete und eine systematische Benennung selbiger schlanke Strukturen vorgaukelt. Das Gleiche mit dem vermeintlichen Ruf als schlankes System. Hier hat aus irgendeinem Grund Arch Linux einen guten Ruf. Dabei sind dort Abhängigkeiten oft viel zu großzügig gesetzt. Ein gutes Negativbeispiel ist bei Arch Linux Digikam.

Mit einem beherzigten Befehl auf der Kommandozeile kann man alle YaST Module entfernen. Die Liste sollte man vorab prüfen. Der Befehl entfernt die Module und die Pattern-Metapakete.

# zypper rm yast*
# zypper rm libyui*

Danach hat man ein YaST-freies System und kann entweder mit der Kommandozeile arbeiten oder die grafischen Einstellungsmöglichkeiten der jeweiligen Desktopumgebung nutzen.

Der Artikel openSUSE geht auch ohne YaST erschien zuerst auf [Mer]Curius

6. Mai 2021

Heute bin ich auf eine interessante Webseite gestoßen: https://mysteries.wizardzines.com/. Hier sind momentan vier „Fälle“ verfügbar, die sich allesamt mit typischen oder weniger bekannten Netzwerkproblemen beschäftigen. Das wären:

  • The Case of the Slow Websites
  • The Case of the Connection Timeout
  • The Case of the DNS Update that Didn't Work
  • The Case of the 50ms Request

Ich habe mir die Puzzles heute angeschaut und bin begeistert, weil es Netzwerkthemen auf eine Art und Weise abseits von Lehrbüchern und Q&A-Seiten einem näher bringt.

Man wird vor ein Problem gestellt, das es zu lösen gilt. Dabei stehen einem verschiedene Mittel zur Verfügung, die interaktiv aufgerufen werden können. Das ganze Spiel ist geführt gestaltet, sodass man nicht alleine gelassen wird und man gleichzeitig verschiedene Werkzeuge kennenlernt, die zur Problemlösung herangezogen werden können. An einigen Stellen wird man selber nach Problemlösungen, Kommandozeilenprogrammaufrufen (strace, tcpdump, ...) gefragt, die allerdings in vielen Fällen nur informativ sind und keinen großen Einfluss auf das Spiel haben.

Wie so oft führen viele Wege nach Rom, so auch bei den hier angesprochenen Fällen. An vielen Stellen ist Zusatzwissen zu finden, das über den Hintergrund aufklärt. Am Abschluss eines jeden Falls wird die Ursache erläutert.

Ich werde nicht weiter die konkreten Fälle spoilern, sie sind auf jeden Fall ganz nett. Besonders in der Netzwerkwelt ist es schwierig, zu debuggen, weil es keine klassische statische Analyse wie aus der Softwareentwicklung gibt. Gerade erst habe ich wieder einen Fall gehabt, bei dem ein Port an einem VLAN-fähigen Switch konfiguriert werden sollte. Access Port konfigurieren reichte scheinbar nicht aus, denn seltsamerweise kam nur ein Teil der Pakete durch. Die Lösung war, dass noch die PVID für den Port konfiguriert werden muss. Das Debugging wird dahingehend erschwert, dass Dinge gerne mal einfach „nicht funktionieren“ und keine Fehler werfen. Um Probleme zu lösen ist es wichtig, Muster zu erkennen und diese zu bewerten. Und genau darauf zielen die Mysteries ab.

Aus diesem Grund ist es wichtig, immer in der Übung zu bleiben, und da kann ich mir solche Spiele gut als Lernwerkzeug vorstellen, auch, wenn sie nicht aktiv auf einem System arbeiten.

Der Source für das Projekt ist auf GitHub verfügbar.

Open Source wird vor allem von Freiwilligen entwickelt. Die vorhandene Software und das Linux-Ökosystem sind somit eine gemeinschaftliche Leistung der Community und können deshalb nicht mit proprietärer Software verglichen werden. Aber ist dem so?

Ich setze mich in diesem Blog häufig kritisch mit Open Source auseinander. Nicht weil ich es nicht gerne nutze oder mit meinem Linux-System im Großen und Ganzen unzufrieden wäre, sondern weil ich die Wohlfühlblase, in die sich Teile der Open Source Community abgesetzt haben (inklusive mancher alternativer Wahrheiten) für gefährlich halte und meine Reichweite gerne für Denkanstöße nutze.

Mit ziemlich hoher Wahrscheinlichkeit kommt bei Vergleichen immer das Argument „Das machen Freiwillige, denen kann man nichts vorschreiben und das kann man nicht vergleichen“. Doch ist dem so oder handelt es sich hierbei nicht um einen schönen Mythos, hinter dem sich Teile der Community argumentativ verschanzen.

Schaut man auf den Kernel, ist schon seit Längerem bekannt, dass hier große Firmen mit ihren Mitarbeitern den Löwenanteil der Arbeit machen. Das löste immer mal wieder Kontroversen aus. Die letzte Aufschlüsselung stammt vom Entwicklungsyzklus der Version 5.10.

GNOME hat ebenfalls vor einiger Zeit transparent gemacht, wer hier die meiste Entwicklungsarbeit leistet. Überraschung: Red Hat. Gefolgt von einigen anderen Organisationen. KDE hat die Affiliation seiner Entwickler leider nicht offen gelegt, aber durch bekannte Förderungen z. B. durch blue systems kann man vermuten, dass hier auch nicht alle ehrenamtlich unterwegs sind.

LibreOffice hat im Zuge der Auseinandersetzung um die Betitelung „Community Edition“ ebenfalls Einblicke in die Verhältnisse gewährt. 73% der Beiträge zu LibreOffice stammen von den Partnern der TDF. Bekannt dürften hier besonders Collabora, Red Hat und CIB sein.

Bei Projekten wie Oracle VirtualBox oder Mozilla Firefox steht der Finanzier ja sogar schon im Namen. Für zahllose weitere Projekte könnte man das sicherlich auch problemlos durch deklinieren.

Bei den Distributionen gilt das sowieso. Red Hats Beteiligung an Fedora ist bekannt, Ubuntu Main wird natürlich von Canonical entwickelt. Als openSUSE-Nutzer kann man im Changelog die Bedeutung der Beiträge von SUSE-Mitarbeitern sehen. Manjaro ist inzwischen eine GmbH und auch bei Debian arbeiten viele bezahlt mit.

Natürlich gibt es auch ganz viel ehrenamtliche Arbeit und die Community leistet Großartiges. Je nach Projekt macht diese Arbeit auch einen großen Anteil aus. Viele kleinere Softwareprojekte werden auch ausschließlich in der Freizeit entwickelt. Das alles soll hier nicht in Abrede gestellt werden! Das gibt es nur bei Windows oder macOS auch. Die vielen Open Source/Freeware-Programme und die Supportforen und Support-Communitys werden dort auch nicht von hauptamtlichen Mitarbeitern gemacht.

Die Freiwilligkeit vieler Einzelentwickler als Argument für mangende Qualität oder komische Entwicklungsprozesse ist somit eine eher romantische Vorstellung von Open Source-Entwicklung und sollte nicht zu exzessiv als Argument vorgeschoben werden. Es wird auch nicht besser, wenn man die Größe der Entwicklerteams proprietärer Software in der Argumentation immer maßlos überschätzt.

Der Artikel Open Source-Entwicklung – Freiwillige oder Firmen? erschien zuerst auf [Mer]Curius

5. Mai 2021

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

Download Mozilla Firefox 88.0.1

Mit dem Update auf Firefox 88.0.1 behebt Mozilla ein durch ein Update von Google Widevine verursachtes Problem, welches dafür sorgte, dass diverse Streaming-Plattformen wie Amazon Prime Video nicht länger hochauflösende Inhalte bereitstellten.

Bei der Wiedergabe von Videos auf Twitter oder auch in WebRTC-Videotelefonaten konnte es zu Darstellungsproblemen für Nutzer mancher Grafikchips von Intel der sechsten Generation kommen. Dieses Problem gehört der Vergangenheit an, ebenso wie nicht sichtbare Elemente in den Firefox-Einstellungen bei Nutzung des Hochkontrastmodus.

Außerdem wurde mit Firefox 88.0.1 eine Sicherheitslücke in Zusammenhang mit WebRender behoben.

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

4. Mai 2021

Linux-Anwender rühmen sich ja immer der Vielfalt, die sich auf dem Desktop bietet. Aber ist es wirklich Vielfalt oder ist es die Unfähigkeit zum Kompromiss?

Michael Kofler hat vor einigen Tagen einen Blogartikel „Fluch und Segen von Gnome“ geschrieben. In diesem zieht er die Schlussfolgerung, dass die geringen Modifikationsmöglichkeiten von GNOME letztlich zur sinnlosen Auffächerung des Ökosystems beitragen:

Natürlich kann niemand kann den Gnome-Entwicklern vorschreiben, in welche Richtung sie ihr Projekt weiterentwickeln. Aber die oft überraschenden, eigenwilligen Design-Entscheidungen irritieren nicht mich alleine. Sie führen dazu, dass Ubuntu das Gnome-40-Update vorerst nicht mitmacht, dass jetzt auch Pop!OS den Desktop neu erfinden will, dass es mit Elementary, Cinnamon, Mate sowieso schon ein Dutzend Varianten gibt, die in Wirklichkeit (fast) keiner haben will. Deren Daseinsberechtigung sich durch einige Details ergibt, die sich außerhalb des Gnome-Universums offenbar einfacher realisieren lassen als innerhalb. Die in einem sinnlosen Ausmaß Entwickler-Ressourcen binden. Die nicht fertig werden. Zu denen es schon bald keine Updates mehr geben wird.

kofler.info – Fluch und Segen von Gnome

Mich hat dieser Artikel erinnert an einen Blogartikel, den ich vor einigen Jahren über die ausufernden Auswahl an Desktopumgebungen geschrieben hatte.

Seitdem hat sich mal wieder was getan. Mit Deepin und COSCMIC sind nun zwei weitere Kandidaten dazu gekommen. Kein einziges Projekt wurde eingestellt.

DesktopumgebungVeröffentlichtEinstellung
Xfce1997 
KDE Plasma1998 
GNOME1999 
LXDE2006 
Trinity2009 
RazorQt20102013
MATE2011 
Cinnamon2011 
Unity20112017
Pantheon2012 
Budgie2014 
LXQt2014 
Deepin2015 
COSMIC2021 

Seit der Pandemie lieben wir ja alle Diagramme. Um also die offensichtliche Entwicklung noch etwas dramatischer darzustellen:

Linux hat bei ungefähr gleichen Nutzungszahlen und ungefähr gleichen Entwicklerzahlen (GNOME und KDE haben das jeweils transparent gemacht) also eine tendenziell wachsende Anzahl an Desktopumgebungen. Die mobilen Umgebungen wurden hier dezidiert nicht berücksichtigt.

Die von Michael Kofler thematisierte „Schuld“ von GNOME ist offensichtlich. Die meisten Desktopumgebungen sind Derivate oder Forks von GNOME und zeitlich vor allem nach der Veröffentlichung von GNOME 3 entstanden.

Man mag nun denken, dass sei eben Linux, aber eigentlich stimmt das nicht. Linux bietet bei vielen wichtigen Sachen entweder keine oder lediglich ein paar Alternativen. Beginnend beim Kernel über so wichtige Sachen wie die Verschlüsselung (LUKS) oder sogar das Initsystem (so viele Alternativen neben systemd gibt es auch nicht). Das sieht bei den Desktopprogrammen nicht groß anders aus. Es gibt 4-5 Mailclients (Evolution, Kontact, Thunderbird, Clawsmail, mutt), zwei Browser (Firefox, Chromium), eigentlich nur eine Office-Suite usw. usf.

Das Problem der ausufernden Alternativen konzentriert sich also tatsächlich vor allem auf die Desktopumgebungen. Ursächlich scheint hier wirklich der Dogmatismus zu sein, der bei Desktopumgebungen Einzug gehalten hat. Es gibt keinerlei Bereitschaft, alternative Ansätze zu integrieren, sondern Abweichler werden quasi ins Exil gedrängt.

Das ist umso absurder, als es im Grunde genommen trotzdem immer das gleiche Konzept ist. Auch GNOME hat hier das Rad nicht neu erfunden, sondern im Kern ein klassisches Fensterkonzept mit (ausgeblendetem) Symboldock vorgelegt. So wie alle anderen Umgebungen eben auch. Bei vielen anderen Umgebungen ist sogar gänzlich unklar, warum es beide geben muss (z. B. MATE und Xfce).

Viele stehen hier auf dem Standpunkt, dass so etwas kein Problem ist, weil Linux durch seine Alternativen profitiert. Bei gleichbleibender Entwicklerzahl ist es aber eine massive Ressourcenverschwendung, wenn das Rad 12 Mal erfunden wird. Es gibt bei jedem Phänomen einen Kipppunkt, bei dem sich die Vorteile in Nachteile umkehren. Bei den Desktopumgebungen ist dieser sicher erreicht. Der Punkt, an dem die Anwender durch die Anzahl an Alternativen noch profitierten ist schon lange überschritten.

Die Befürworter der Alternativen haben dabei meist ein negatives Menschenbild. Sie glauben, die Entwickler der Alternativen würden sonst gar nichts beitragen. Meiner Meinung nach ist das ein Irrtum, vor allem bezüglich des großen Kreises der Entwickler, die „nur“ zum Projekt beitragen und keine Hauptentwickler sind. Diese würden sich bei weniger Auswahl einfach für eines der anderen Projekte entscheiden.

Das Feld wird sich hier hoffentlich demnächst lichten. Die Schwierigkeiten der großen Entwickerteams von GNOME und KDE bei der Migration zu Wayland lassen erahnen, dass die meisten anderen Projekte daran scheitern könnten.

Der Artikel Linux-Desktop – Vielfalt oder Kompromissunfähigkeit? erschien zuerst auf [Mer]Curius

3. Mai 2021

Die Linux-Gemeinschaft lässt sich grob in drei Lager unterteilen. Dabei nimmt ein Lager den Extremwert „stabil wie ein Fels“ mit z.B. Debian oldstable ein, während der andere Extremwert „bleeding edge“ durch Anhänger z. B. von Arch Linux besetzt wird. Das dritte Lager besetzt die Mitte, in der sich unzählige weitere Distributionen tummeln, die mehr zu dem einen oder dem anderen Extremwert hin tendieren.

Warum das so ist und welche Distribution einen, wie ich finde, ganz interessanten Mittelweg eingeschlagen hat, möchte ich in diesem Artikel beleuchten. Bierernst bin ich dabei allerdings nicht. Die ein oder andere Ausführung ist durchaus mit einem Augenzwinkern zu verstehen. ;-)

Stabil wie ein Fels

So soll eine Linux-Distribution aus Sicht vieler Systemadministratoren sein. Gut getestet, alle Komponenten perfekt aufeinander abgestimmt und über ihren Lebenszyklus nur wenigen — am besten gar keinen — Änderungen unterworfen. Einzig Sicherheitsaktualisierungen dürfen und sollen zeitnah geliefert werden.

Distributionen, die sich diesem Paradigma unterwerfen, versprechen geringe Wartungsaufwände und sind des Sysadmins Freund. In meinen Augen dürfen Debian, RHEL, SLES, etc. dieser Kategorie zugeordnet werden.

Doch bergen diese Distributionen paradigmenbedingt auch einige Nachteile. Da Kernel und Bibliotheken meist schon etwas älter sind — manche sagen dazu steinalt, andere gut abgehangen — wird neue Hardware evtl. nicht in vollem Umfang unterstützt. Oder die mitgelieferten Bibliotheken und Laufzeitumgebungen sind schlicht zu alt, um mit aktuellen Versionen verfügbarer Software noch kompatibel zu sein.

Um den Nachteilen zu begegnen, bleibt Sysadmins häufig nichts anderes übrig, als das wohlige Heim der Distribution zu verlassen und Laufzeitumgebungen aus Upstream- oder Drittanbieter-Repos zu installieren, Software selbst zu übersetzen oder sich Container in die heilige Halle zu stellen. Die Distributionen versuchen dem zu begegnen, in dem sie unter Umständen zu Minor-Releases neuere Software-Versionen als sogenannte Rebases oder Backports nachliefern. Das dies passiert ist jedoch keineswegs garantiert und stellt im Zweifel ein Risiko für die Stabilität dar.

Wenn die Distribution dann aber doch eine neue Softwareversion ausliefert, hat der Sysadmin meist keine Wahl. Entweder er bleibt auf der alten Version und erhält voraussichtlich keinerlei Sicherheitsupdates mehr für diese oder installiert die aktuelle Version und lernt die Neuerungen lieben bzw. damit zu leben.

Bleeding Edge

Mit diesem Beinamen werden häufig Distributionen bezeichnet, welche dem Rolling-Release-Modell folgen und Software mitliefern, die sehr nah am aktuellen Stand der Upstream-Entwicklung ist (the latest and greatest). In dieser Ecke findet man z. B. Distributionen wie Arch Linux, Manjaro, Fedora Rawhide, etc. wobei diese Liste keinen Anspruch auf Vollständigkeit erhebt.

Der Betrieb dieser Distributionen ist geprägt von häufigen Updates. Die stetige Weiterentwicklung birgt das Risiko, dass auch mal etwas kaputt geht und plötzlich nicht mehr funktioniert. Doch versprechen die Distributionen meist, dass gerade durch den schnellen Entwicklungszyklus gefundene Fehler auch schnell behoben werden. Wohingegen die Nutzer stabiler Version häufig Monate, wenn nicht Jahre oder gar vergebens auf einen Bugfix warten müssen.

Blöd wird es, wenn man Software betreiben muss, die nur für eine bestimmte Version einer Laufzeitumgebung, oder bestimmter Bibliotheken freigegeben ist und unterstützt wird. Wer solche Software betreibt, sollte sich jedoch von vornherein fragen, ob er bei rollenden Releases richtig aufgehoben ist.

Dann sind da auch noch jene unter uns, die für den Betrieb auf gewisse Zertifizierungen ihrer Betriebssysteme angewiesen sind. Hier sind die Zertifizierungsverfahren häufig länger, als die Lebensspanne eines Bleeding-Edge-Release.

Das Mittelfeld

Dieses Feld ist weitgespannt. Hier tummeln sich Distributionen wie Fedora, Ubuntu sowie viele weitere. Ihnen allen unterstelle ich, dass sie den besten Kompromiss suchen, um so stabil wie möglich und so aktuell wie nötig zu sein.

So habe auch ich in der Vergangenheit auf Ubuntu LTS gesetzt, da ich es für den besten Kompromiss hielt. Leider waren unsere Entwickler mit den mitgelieferten Software-Versionen nicht lange zufrieden und ließen sich nicht bis zum nächsten Release hinhalten. Also wurden auch hier wieder {Dritanbieter,Upstream}-Repos eingebunden und die Software von dort installiert. Eine Erfahrung die ich bisher unter jeder Distribution machen durfte.

Genauso gut kenne ich den umgekehrten Fall, wo Paket XY auf gar keinen Fall aktualisiert werden darf, da sonst ein Dienst unrettbar kaputt geht. Lasst euch gesagt sein, man hat es schon nicht leicht in der Systemadministration. ;-)

Appstreams und Module

Mit RHEL 8 hat Red Hat eine interessante Neuerung eingeführt, die sog. Module im Appstream-Repository. Nun ein Listing sagt vermutlich mehr, als viele Sätze:

$ sudo dnf module list nginx php postgresql
Updating Subscription Management repositories.
Last metadata expiration check: 0:27:21 ago on Mi 21 Apr 2021 05:41:58 CEST.
Extra Packages for Enterprise Linux Modular 8 - x86_64
Name            Stream        Profiles                        Summary                                 
nginx           mainline      common                          nginx webserver                         

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Name            Stream        Profiles                        Summary                                 
nginx           1.14 [d]      common [d]                      nginx webserver                         
nginx           1.16          common [d]                      nginx webserver                         
nginx           1.18          common [d]                      nginx webserver                         
php             7.2 [d]       common [d], devel, minimal      PHP scripting language                  
php             7.3           common [d], devel, minimal      PHP scripting language                  
php             7.4           common [d], devel, minimal      PHP scripting language                  
postgresql      9.6           client, server [d]              PostgreSQL server and client module     
postgresql      10 [d]        client, server [d]              PostgreSQL server and client module     
postgresql      12            client, server [d]              PostgreSQL server and client module     

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

Wie ihr sehen könnt, hat man damit die Auswahl aus mehreren Versionen ein und der selben Anwendung. Das kannte ich so bisher noch nicht, ohne zusätzliche Repos einbinden zu müssen, oder mich gar mit den berüchtigten Red Hat Software Collections beschäftigen zu müssen.

Als Sysadmin habe ich damit etwas Flexibilität dazugewonnen. Ich kann z. B. eine Altlast mit NGINX 1.14, PHP 7.2 und PostgreSQL 9.6 auf einem Host und eine aktuelle Anwendung mit NGINX 1.18, PHP 7.4 und PostgreSQL 12 auf einem anderen Host betreiben, dabei aber das gleiche stabile Release RHEL 8 nutzen.

Allerdings kann man nicht zwei verschiedene Versionen von z. B. PHP oder PostgreSQL parallel auf dem gleichen Host betreiben. Wer dies wünscht, kann die entsprechenden Anwendungen lokal in Podman-Containern ausführen. Auch hier stehen Images für die verschiedenen Versionen bereit.

Red Hat verspricht, neue Versionen von Anwendungen, Sprachen und Werkzeugen auf diesem Weg verfügbar zu machen. So sind in der Beta des kommenden RHEL 8.4 zum Beispiel PostgreSQL 13, Python 3.9 und Podman 3.0.1 enthalten. Zu beachten ist jedoch, dass die jeweiligen Streams ihre eigenen Life-Cycles besitzen, die es im Auge zu behalten gilt. Hier hilft ein Blick in die offizielle Dokumentation weiter:

Fazit

Ob diese Neuerung und die damit einhergehenden Vorteile in der Praxis von Relevanz sein werden, kann ich heute noch nicht sagen. Dafür fehlt mir noch etwas Erfahrung mit diesem neuen Konzept.

Ich persönlich glaube, dass sich Application Streams und das Konzept zur Verwendung von Containern nicht gegenseitig ausschließen, sondern sinnvoll ergänzen können. In meinen Augen gelingt es Red Hat mit Appstreams, seine stabile Distribution etwas in Richtung Aktualität zu schieben, ohne dabei Stabilität aufgeben zu müssen.