Flatpak und Snap sind nicht die Lösung des Problems, sondern machen es noch schlimmer

Im Moment wird heftig darüber diskutiert, ob der Support von Flatpak in Fedora 27 weiter ausgebaut werden soll oder nicht.

Ich persönlich halte Flatpak und Snap für den völlig falschen Ansatz, das Problem mit der Bereitstellung von Software für verschiedene Distributionen zu lösen. Beide haben in meinen Augen das große Problem, das im Grunde jedes Snap-/Flatpak-Paket seine eigenen Versionen von benötigten Shared-Objects mitbringt und man damit irgendwann so etwas ähnliches, wie die DLL-Hölle von Windows hat: zig verschiedene Versionen eines Shared-Object von denen die meisten im schlimmsten Fall auch noch verwundbar für Angriffe sind.

Zumal die meisten technisch unbedarften Anwender wahrscheinlich davon ausgehen werden, das der Paketmanager des Systems (z.B. dnf oder PackageKit) auch die Shared-Objects der Flatpak-Pakete aktualisiert, was aber eben genau nicht der Fall ist. Stattdessen müssen sich die Nutzer darauf verlassen, das die Anbieter der von ihnen verwendeten Flatpaks/Snaps verwundbare Versionen der von ihren Apps verwendeten Shared-Object zeitnah aktualisieren – eine Wette, die ich persönlich nicht eingehen möchte. Das funktioniert ja schon bei Windows Anwendungen eher bescheiden, warum sollte es dann diesmal besser klappen?

Nein, Flatpak und Snap sind in meinen Augen das, was man sprichwörtlich „den Teufel mit dem Beelzebub austreiben“ nennt: ein Problem lösen und dabei ein anderes Problem schaffen. Man macht es einfacher, Anwendungen für verschiedene Distributionen bereit zu stellen, öffnet damit aber ohne Not zusätzliche Angriffsvektoren, indem man dem Paketmanager die Kontrolle über einen Teil der installierten Software entreißt und die Anwender damit zwingt darauf zu vertrauen, das Dritte – von denen man im Grunde nicht weiß, wie vertrauenswürdig sie sind – ihre Hausaufgaben machen!

IMHO ist der Kommentar von Fedora-Blog.de.
IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).

Fritzbox NAS per fstab einbinden

Bitte beachtet auch die Anmerkungen zu den HowTos!

Wer eine Fritzbox mit NAS-Funktion sein Eigen nennt, sollte ernsthaft darüber nachdenken, ob er die Fritzbox nicht automatisch per fstab einbinden möchte. Das ist beispielsweise hilfreich, wenn man seine Daten regelmäßig sichern möchte.

Zur Vorbereitung muss zuerst das cifs-utils Paket installiert werden:

su -c'dnf install cifs-utils'

Als nächstes muss der lokale Einhängepunkt erstellt werden, sofern dieser noch nicht existiert:

su -c'mkdir /media/fritzbox'

Zu guter letzt wird noch eine .smbcredentials Datei im eigenen Home-Verzeichnis mit folgendem Inhalt erstellt:

username=ftpuser
password=<PASSWORT>

Die Datei dient später dazu, das man die Zugangsdaten für die Fritzbox nicht in die fstab schreiben muss.

Um die Fritzbox automatisch beim Systemstart einzubinden, muss nun noch /etc/fstab mittels

su -c'nano /etc/fstab'

zum Bearbeiten geöffnet und folgende Zeile eingefügt werden eingefügt werden:

//IP-DER-FRITZBOX/fritz.nas/ /media/fritzbox cifs credentials=/home/USERNAME/.smbcredentials,auto,defaults,uid=1000,gid=1000 0 0

Ob der Eintrag korrekt ist und sich die Fritzbox problemlos einbinden lässt, kann mittels

su -c'mount -a'

überprüft werden.

Evolution: Anzeige von Plaintext erzwingen

Bitte beachtet auch die Anmerkungen zu den HowTos!

Wem es wie mir geht und eine gewisse Abneigung gegen HTML-Nachrichten hat, der kann Evolution dazu zwingen, immer den Plaintext-Teil einer Mail zu bevorzugen, sofern dieser vorhanden ist.

Um dies zu erreichen, muss in den Einstellungen von Evolution unter „E-Mail-Einstellungen“ im Register „HTML-Nachrichten“ die Einstellung „HTML-Modus“ auf „Immer als einfachen Text anzeigen“ ändern.

Ab sofort wird Evolution bei Mails, die einen Plaintext-Teil enthalten, diesen anstelle des HTML-Teils anzeigen. Bei reinen HTML-Mails ohne Plaintext-Teil hat diese Einstellung jedoch keinen Auswirkungen zur Folge, das man eine leere Mail mit dem HTML-Teil als Anhang vorfindet.

Fedora und veraltete Software

Irgendwann vor 8 oder mehr Jahren wollte man mit dem Echo Icon-Theme Fedora ein eigenes Icon-Theme spendieren, damit sich Fedora noch ein wenig mehr von anderen Distributionen abhebt. Immerhin ist das derzeitige Fedora Icon-Theme im grunde nur eine Erweiterung des Mist Icon-Themes. Wie so oft bei solch ambitionierten Projekten schlief die ganze Sache aber irgendwann ein und somit dümpelt Echo seit fast 8 Jahren ohne Update als Zombie in den Repositories herum. Das dieses Theme wohl kaum mit aktuellen Versionen von Gnome, KDE, Xfce und Co vernünftig zu nutzen ist, dürfte wohl jedem einleuchten.

Ich frage mich jedoch, ob es wirklich sein muss, das solche Zombies jahrelang in den Fedora Repositories herumdümpeln, obwohl das Upstream Projekt inzwischen tot ist. Solange sich die Pakete ohne Fehler bauen lassen hat sie vom Fedora Projekt natürlich auch niemand auf dem Radar – wahrscheinlich nicht einmal mehr die eigentlichen Maintainer. Lassen sie sich irgendwann nicht mehr bauen, fliegen sie halt nach einer gewissen Zeit aus Fedora raus und fertig.

Wie wäre es jedoch, wenn man Pakete, die z.B. seit mehr als 2 Jahren nicht mehr aktualisiert wurden und alle Pakete, die von diesen abhängig sind, in ein standardmäßig deaktiviertes Legacy-Repository verschieben würde? Die Pakete, die sich in diesem Repository befinden würden der Einfachheit halber nur noch im Ramen des Massrebuilds vor jedem neuen Fedora-Release neu gebaut werden. Schlägt der Rebuild jedoch fehl, fliegt das Paket mitsamt seinen Abhängigkeiten mangels Paket für die betreffende Fedora-Version quasi automatisch aus der Distribution.

Das würde die Haupt-Repositories von Fedora übersichtlicher halten und man müsste sich nicht mehr mit veralteten Paketen herum ärgern, die sich zwar noch problemlos bauen lassen, aber (wie beispielsweise Themes) mittlerweile einfach nicht mehr vernünftig funktionieren.

IMHO ist der Kommentar von Fedora-Blog.de.
IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).

minibuild – mein kleines Build-Script

Wie der eine oder andere vielleicht mitbekommen hat, baue ich seit einiger Zeit selber rpm-Pakete und veröffentliche diese auf COPR.

Da das Bauen der Pakete aus einigen Arbeitsschritten besteht, die sich zum Glück relativ einfach automatisieren lassen, habe ich kurz nachdem ich angefangen habe, Pakete zu bauen, mir ein kleines Shellscript geschrieben, das die notwendigen Schritte automatisiert. Inzwischen ist dieses Script knapp 550 Zeilen lang, GPL lizenziert und auf GitHub veröffentlicht.

Das Script ist mittlerweile so mächtig geworden, das es den kompletten Build-Prozess, bestehend aus

  • dem Download der Quelltexte von der Projektseite,
  • dem Erzeugen der src.rpm Pakete,
  • dem Durchführen eines lokalen Testbuilds mit mock,
  • dem anschließenden Validieren der Pakete (Binary und src.rpm) sowie des Spec-Files mittels rpmlint,
  • dem Upload des src.rpm Paketes auf einen FTP-Space sowie
  • dem Start des finalen COPR-Builds

vollständig automatisiert. Das Script ist ferner in der Lage, in begrenztem Umfang Platzhalter in der Quelltext-URL aufzulösen und die korrekte URL zu erzeugen.

Gesteuert wird das Script hauptsächlich durch 3 Konfigurationsdateien:

  • chroots.conf: Hier werden die zu verwendenden chroots eines Projektes eingetragen, sofern ein Projekt nicht für alle chroots eines COPRs gebaut werden soll.
  • coprs.conf: Hier werden den Projekten (Name des Spec-Files) die COPRs zugeordnet, sofern der Projektname nicht dem Namen des COPRs entspricht.
  • ftp.conf: Hier werden die URL des FTP-Space, der Pfad innerhalb des FTP-Space sowie die notwendigen Zugangsdaten eingetragen.

Ich würde mich freuen, wenn mein Script auch anderen Paket-Maintainern helfen kann, ihnen Arbeit beim Bauen ihrer Pakete abzunehmen. Genau so sehr freue ich mich über Verbesserungsvorschläge, Anregungen und konstruktive Kritik.

Wayland

Ich habe jetzt mal ein paar Tage anstatt des X-Display-Servers dessen Nachfolger Wayland genutzt. Wieder erwarten hat Wayland soweit einen ganz ordentlichen Eindruck unter GNOME 3.18 hinterlassen.

Das einzige was mich ein wenig gestört hat, waren folgende Punkte:

  • kleinere Darstellungsfehler beim Start von Programmen (Teile des Programmfensters waren beim Programmstart für kurze Zeit schwarz).
  • Der Mauszeiger „klemmt“ immer mal wieder.
  • Waylands Font-Rendering unterscheidet sich erkennbar von dem des X-Servers.
  • Der Login-Sound wird, anders als unter X, erst abgespielt, wenn GNOME komplett geladen ist.
  • Die GNOME Shell verursacht etwas mehr Prozessorlast und lässt sich nicht via ALT+F2 und „r“ neustarten.
  • Fenster, die minimiert und dann wiederhergestellt werden, frieren beim Wiederherstellen ein und können nur durch einen Neustart der Anwendung „reanimiert“ werden (Bugreport).

Habt Ihr auch schon mal einen Blick auf Wayland geworfen und wenn ja, wo „klemmt“ es bei Euch noch?

Quick-Tipp: Man-Pages mit yelp lesen

Bitte beachtet auch die Anmerkungen zu den HowTos!

Vielen unbekannt, verfügt Gnome’s Betrachter für Hilfeseiten yelp über die Fähigkeit, man-pages anzuzeigen.

Sofern yelp bereits geöffnet ist, kann man eine man-page ganz einfach über STRG-L und anschließend in dem Eingabefeld

man:man-page

eingeben.

Alternativ kann man yelp auch direkt mit einer Man-Page aufrufen. Dazu einfach z.B. ALT+F2 drücken und anschließend

yelp man:man-page

eingeben.

In beiden Fällen muss man-page natürlich durch die zu öffnende Man-Page ersetzt werden.