Fr, 24. Juni 2022, Lioh Möller

In Fedora Silverblue ist die Aktualisierung mittels rpm-ostree bereits in GNOME Software integriert. Das KDE Projekt arbeitet ebenfalls seit einer Zeit an einer Integration in Discover, welche allerdings noch nicht abgeschlossen wurde.

Nutzer von Alternativen wie Vauxite bleibt bisher nur ein Griff zur Kommandozeile. Abhilfe schafft das in Python geschriebene Programm RPM OSTree GUI.

Die Installation kann mittels pip3 im Benutzerkontext erfolgen:

pip3 install rpm-ostree-gui

Daraufhin lässt sich die Anwendung über den entsprechenden Eintrag im Startmenü aufrufen.

Aktuell ist es mit dessen Hilfe möglich, zusätzliche Pakete zu installieren, sofern der Paketname bekannt ist. Eine Deinstallation kann ebenfalls ausgelöst werden, sowie eine Suche über die installierten Overlays.

Nützlich ist die integrierte Aktualisierungsfunktion sowie die Möglichkeit, die bisher experimentelle 'Apply live' Funktion aufzurufen, welche eine Aktivierung von neuen Overlays unter bestimmten Umständen ohne Neustart durchführen kann.

Quelle: https://github.com/epiccakeking/rpm-ostree-gui

Vor etlichen Jahren hatte ich mit qrencode ein Werkzeug vorgestellt, um QR-Codes auf der Kommandozeile zu generieren. Neben normalen QR-Code können mit dem Werkzeug auch andere Codes wie EPC-QR-Codes erstellt werden. Dazu muss im ersten Schritt eine Textdatei erzeugt und entsprechend befüllt werden: Der Wert in der ersten Zeile ist der Service Tag, welcher immer BCD ist und in der nächsten…

Quelle

Mo, 20. Juni 2022, Stefan

... Android riecht auch ohne Playstore sehr nach Google und iOS kommt sowieso nicht infrage? Glücklicherweise gibt es Menschen, die ähnlich denken und diesen Gedanken Taten folgen lassen. Daraus entstanden sind nicht nur (weitgehend) Google freie Android-Distributionen, sondern auch Systeme, welche unabhängig von den grossen Konzernen und deren veröffentlichten Quelltexten entwickelt werden.

Neben Entwicklungen wie UBports, welche versuchen ein eigenes Software-Ökosystem auf die Beine zu stellen, gibt es auch Projekte, welche darauf abzielen, bereits bestehende Systeme für Mobiltelefone nutzbar zu machen.

Letztere haben mit der Veröffentlichung des PinePhones gewaltige Fortschritte gemacht. Zum Teil ist dies wohl der Tatsache zu verdanken, dass der Hersteller die Hardware bewusst so gestaltet hat, dass es einfach ist, das Gerät neu aufzusetzen ist. Erreicht wurde dies, indem es standardmässig von der SD-Karte startet, sofern diese ein bootfähiges System enthält.

Zum Anderen verkaufte das Unternehmen über einen gewissen Zeitraum hinweg sogenannte 'Community Editions'. Diese Geräte waren mit dem Logo eines Softwareprojekts bedruckt und es ging ein Teil der Einnahmen an letzteres. So erhielten diese nicht nur finanzielle Unterstützung, sondern auch einiges an Aufmerksamkeit. Zudem stellt der Hersteller kein eigenes System zur Verfügung, sondern unterstützt unabhängige Entwickler, so gut es ihm möglich ist.

Wie bei Linux am Desktop, ist es auch hier so, dass die Desktopumgebung sozusagen das Gewand darstellt und die Wahl der Distribution erst am zweiten Blick für Unterschiede sorgt. Weshalb wir einen Blick auf die Mobilen Desktopumgebungen werfen wollen, bevor wir die Distributionen betrachten.

Im Moment scheinen drei Windowmanager für Linux am Mobilgerät populär zu sein. sxmo ist ein auf Minimaleismus getrimmter Vertreter. Plasma Mobile ist als für Mobilgeräte optimierte Variante des KDE Plasma Desktops interessant und wird standardmässig mit dem PinePhone als Teil einer Manjaro ARM Installation ausgeliefert. Wer es etwas schlichter mag, aber dann doch nicht auf sxmo setzen will, für den könnte Phosh die richtige Wahl sein.

Phosh wurde von Purism, einem Hardwarehersteller aus den USA für deren Mobiltelefon dem Librem5 entwickelt. Ich verwende auf meinem Mobiltelefon Phosh als Teil einer Mobian Installation. Erwähnenswert ist auch, dass Phosh auf gtk basiert, und auf Komponenten der Gnome-Shell aufbaut. Seit einiger Zeit hat darüber hinaus das GNOME-Projekt selbst damit begonnen, die GNOME-Shell für Mobilgeräte nutzbar zu machen.

Doch zurück zu den Distributionen. Eine, welche bereits vor der Veröffentlichung des Pinphones beträchtliche Entwicklungsfortschritte aufweisen konnte, ist postmarketOS. Dabei handelt es sich um einen Ableger von Alpine Linux, mit einem Focus auf Mobilgeräte. Neben dem Beitriebsystem selbst, entwickelt das Team auch an Softwarelösungen, um dieses möglichst einfach auf Androidgeräten installieren zu können. Auch das Portieren auf noch nicht unterstützte Hardware, soll durch diese Tools vereinfacht werden.

Wie bereits erwähnt, basiert das Image, mit dem das PinePhone ausgeliefert wird, auf Manjaro Arm. Hier scheint es sich um ein Image zu handeln, bei dem die Paketquellen der Desktopversion zum Einsatz kommen und sich nur die Auswahl der vorinstallierten Pakete unterscheidet.

Einen ähnlichen Weg ist auch Mobian. Das System stellt weniger eine eigenständige Distribution dar, als ein Installationsimage für Debian, welches Repositories mit für Mobilgeräte optimierte Software wie der Phosh Desktopumgebung zur Verfügung stellt.

Auch von anderen Distributionen gibt es Bestrebungen, diese auf dem Mobilgerät sinnvoll einsetzbar zu machen. In dieser kurzen Übersicht fanden nur diejenigen Erwähnung, von denen ich bisher am meisten mitbekommen habe.

Ein Freund bat mich kürzlich um meine Meinung zum Thema Software-Verteilung und Dokumentation des Installations- bzw. Bereitstellungsprozesses. Die Gedanken, die ich mir dazu gemacht habe, möchte ich an dieser Stelle mit euch teilen. Dabei schreibe ich aus dem Blickwinkel eines Systemintegrators, der von Dritten erstellte Software integrieren und betreiben muss.

Den Anwendungsentwicklern, Software-Architekten und Produkt-Managern unter euch soll dieser Text als Information dienen, was ich und ggf. weitere Personen meiner Zunft von einer Dokumentation erwarten bzw. wie wir uns Software-Verteilungsprozesse vorstellen.

Als Leser seid ihr alle eingeladen, eure Gedanken ebenfalls zu teilen und eine Diskussion zu diesem Thema zu führen.

Das Szenario

Ich habe bei meinen Gedanken ein Szenario im Kopf, in dem ein Anwendungsentwickler eine Anwendung in einer Sprache seiner Wahl schreibt. Diese Anwendung soll später über ein Web-Frontend erreichbar und nutzbar sein. Die Anwendung benötigt eine Datenbank, um Informationen darin abzulegen. Binärdateien werden ggf. außerhalb der Datenbank in einem Dateisystem gespeichert.

Die Anwendungsentwickler freuen sich, wenn ihre Software einen hohen Verbreitungsgrad erreicht. Dazu muss die dazugehörige Dokumentation folgende Informationen bieten.

Werkzeuge zum Erstellen und Ausführen der Anwendung

• Welcher Compiler ab welcher Version wird benötigt?
• Welche Bibliotheken werden ab welcher Version benötigt?
• Sind abweichende Versionen möglich oder funktioniert nur genau eine?
• Welche Laufzeitumgebung wird benötigt?
• Was ist in welcher Reihenfolge zu tun, um vom Quelltext zu einem ausführbaren Programm zu kommen?

Voraussetzungen zur Integration der Anwendung

• Wird eine Datenbank benötigt?
• Welche Datenbank-Management-Systeme werden unterstützt?
• Ab welcher Version?
• Über welche Rechte muss ein DB-User mindestens verfügen, damit der Anwendungs-Installer die notwendigen Tabellen, Views, etc. erstellen kann?
• Welche Webserver werden unterstützt?
• Welche Protokolle, Parameter bzw. Optionen sind für die Kommunikation mit der Anwendung notwendig?

Ich bin immer enttäuscht, wenn hier auf ein einziges System eingeschränkt wird. Dies limitiert unnötig den Nutzerkreis.

• Wird ein Snakeoil-Zertifikat mitgeliefert oder hat der Systemintegrator dieses beizustellen? Eigene Zertifikate auf Wunsch verwenden zu können ist obligatorisch.

Die bis jetzt genannten Informationen müssen so umfassend sein, dass Paketbetreuer bzw. Software-Paketierer daraus Debian-, Flatpak-, RPM-, Snap-Pakete, Container-Images und Windows-Installer bauen können.

Nehmen die Anwendungsentwickler in Personalunion die Rolle von Software-Paketierern wahr, scheint es dennoch unrealistisch, dass sie allein alle Formate unterstützen können. Sie sollten sich für einige wenige Formate entscheiden, die auf möglichst vielen Plattformen lauffähig sind. In dem von mir gedachten Szenario sind dies OCI-kompatible Container-Images.

Bei einer GUI-Anwendung würde ich mich vermutlich für Flatpak entscheiden. Die Paketierung als DEB oder RPM würde ich auf jeden Fall den Paketbetreuern der jeweiligen Distributionen überlassen.

Systemintegration

Für den Systemintegrator, welcher den Webserver, die Anwendung und die Datenbank zusammenbringt (integriert), muss klar beschrieben werden:

• Gibt es ein fertiges Container-Image? Wo bekommt man es her?
• Optional: Wie erstellt man das Container-Image selbst?
• Welche (Umgebungs-)Variablen gehören zum Image? Welche Werte können diese annehmen?
• Ein Kommunikationsdiagramm, damit der Sysadmin weiß, was wann mit wem spricht und welche Firewall-Regeln evtl. benötigt werden.

Referenzimplementierungen sind ebenfalls schön. Diese sollten für Docker, Docker-Compose, Kube-YAML (K8s) und Podman bereitstehen. Die Doku zum Container-Image muss jedoch so ausgestaltet sein, dass auch ohne Referenzimplementierung die Instanziierung mit den verschiedenen Engines und Orchestrierern gelingen kann.

Was Sysadmins (wie ich) nicht mögen

Ich mag es nicht, wenn in den Abhängigkeiten ein Webserver (Apache, NGINX, lighttpd) oder ein Datenbank-Management-System unnötig hart verdrahtet ist. Gleiches gilt für die Festlegung der zu verwendenden Container-Registries. Ich will dem Installer sagen können, wo er die Images findet und nicht auf den Dockerhub festgelegt werden.

Und ja, mir ist bewusst, dass eine gute Dokumentation genauso viel Aufwand und Pflege bedeutet wie der Quelltext einer Anwendung selbst. Aber ist es eine Alternative, wenn Systemintegratoren die Anwendung nach dem ersten Installationsversuch hassen?

Eure Meinung ist willkommen

Wie steht ihr als Entwickler zum Thema Dokumentation? Was erwartet ihr als Sysadmin und User von ihr?

Stimmt ihr mit mir überein oder habt ihr ganz andere Ansichten dazu? Nutzt gern die Kommentarfunktion und lasst es mich wissen.