ubuntuusers.de

Mo, 2. Mai 2022, Ralf Hersel

Die Idee hinter Flatpaks geht auf Red Hat und die GNOME Foundation zurück. Die App-Container wurden erstmals in Fedora 24 unter Gnome 3.22 einer breiteren Anwenderschaft vorgestellt. Flatpaks sind nicht an eine bestimmte Distribution gebunden und auch nicht mehr nur an die Desktop-Umgebung GNOME. Viele Linux-Distributionen liefern die Flatpak-Runtime heute vorinstalliert aus und eignen sich damit zur Installation der isolierten App-Container. Flatpak selbst charakterisiert sich als die universelle Desktop-API für Linux und steht in Konkurrenz zu Canonicals Snap-Format, den AppImages und natürlich den nativen Formaten (rpm, deb, usw.).

Flathub.org arbeitet daran, ein Bezahl- und Spendensystem umzusetzen. Entwickler können entscheiden, ob Nutzer die Flatpaks gratis erhalten, eine freiwillige Spende entrichten oder einen Mindestpreis bezahlen müssen. Die Erlöse sollen nach Abzug einer kleinen Gebühr (?) für die Flathub-Store direkt an Entwickler gehen. Zur Abwicklung erörtert man derzeit eine Rechtsform. Es soll eine 'Flathub LLC' gegründet werden. Die finanziellen Transaktionen soll der Dienstleister Stripe abwickeln.

Für Softwareprojekte, die üblicherweise in den Paketquellen einer Linux-Distribution vertreten sind, ist dieser Schritt attraktiv, um unkompliziert neue Versionen direkt an Anwender zu liefern, ohne dass weitere Paket-Maintainer zwischengeschaltet sind. Das Problem hierbei sind unscharfe Verantwortlichkeiten bei Fehlerbehebungen und lange Wartezeiten, bis eine Linux-Distribution die neue Ausgabe einer umfangreichen Software mit Abhängigkeiten aufnehmen kann.

Wie dieser Schritt von der Community aufgenommen werden wird, ist abzuwarten. Es besteht die Gefahr, dass sich viele alte Hasen auf die distributionsspezifischen Formate zurückbesinnen werden. Damit erweist man den Entwicklern einen Bärendienst. Sie werden zweier Möglichkeiten beraubt: dem generischen Paketformat für alle Distributionen, was weniger Arbeit bedeutet, und einer realistischen Möglichkeit, eine Einnahme aus ihrer Leistung zu erzeugen. Ob die Spenden- und Bezahl-Idee von Flathub.org ziehen wird, werden wir sehen. Ich denke, es liegt daran, wie sensibel und Community-freundlich die Monetarisierung umgesetzt wird.

Quelle: https://conf.linuxappsummit.org/event/4/contributions/83/

In der Vergangenheit war der Umgang von Synology mit Sicherheitslücken eher durchwachsen. Der jüngste Sicherheitsvorfall gibt aber Anlass zu Hoffnung.

In der Vergangenheit hatte ich den Umgang von Synology mit Sicherheitslücken im eigenen Betriebssystem DiskStation Manager kritisiert. Der Umgang mit dem neuesten Problem war aber deutlich besser. Die Probleme betrafen Netatalk. Das ist für Linux-Implementierung für das AFP-Protokoll, welches vor allem für Apple-Anwender von Bedeutung war und in Teilen immer noch ist, jedoch langsam aus der Mode kommt. Nichtsdestotrotz haben vor allem Besitzer älterer Macs oder einfach auch älterer Netzwerk-Setups das Protokoll noch oft aktiv und entsprechende Freigaben eingerichtet.

Folgende Sicherheitslücken waren aufgetreten:

• CVE-2022-0194
• CVE-2022-23121
• CVE-2022-23122
• CVE-2022-23123
• CVE-2022-23124
• CVE-2022-23125

Die Lücken waren Ende März bekannt geworden und betreffen eigentlich alle Linux-Distributionen und Linux-basierte NAS-Systeme, da alle auf die gleiche Linux-Implementierung des Apple-Protokolls setzen. Glücklich sind da Distributoren wie openSUSE oder Red Hat, die Netatalk schon länger nicht mehr unterstützen. SUSE hat für SLE 12 bereits einen Patch veröffentlicht, Debian zieht dann vermutlich irgendwann mal nach.

Grundsätzlich sollte Betroffene diese Lückenserie zum Anlass nehmen und sich fragen, ob sie AFP bzw. Netatalk wirklich noch benötigen oder nicht doch lieber auf SMB wechseln sollten. Das hat zwar auch immer mal wieder Probleme, aber abgekündigte Protokolle sind selten gut für die Sicherheit.

Synology hat jedenfalls relativ schnell einen Patch veröffentlicht und am 27. April für die Allgemeinheit ausgerollt. Die Updateaufforderung erreichte mich auch tatsächlich automatisch über das NAS und ohne manuelle Initialisierung. Möglicherweise ein glücklicher Zufall, aber man darf hoffen.

Der Artikel Synology – Auf dem Weg der Besserung? erschien zuerst auf [Mer]Curius

Mozilla hat MDN Plus, das Premium-Angebot der MDN Web Docs, in 16 weiteren Ländern gestartet, darunter auch Deutschland, Österreich und die Schweiz.

Mozilla ist vor allem für seine kostenlosen Produkte wie den Browser Firefox bekannt. Um den Nutzern zusätzliche Mehrwerte zu bieten, aber auch um die finanzielle Abhängigkeit von Suchmaschinen-Anbietern zu reduzieren, setzt Mozilla vermehrt auch auf kostenpflichtige Premium-Angebote wie das Mozilla VPN oder Firefox Relay Premium. Mozillas neuestes Premium-Angebot, MDN Plus, richtet sich an Webentwickler.

Jetzt MDN Plus abonnieren

MDN Plus: Premium-Modell mit drei Stufen

Die zahlreichen Artikel der MDN Web Docs werden natürlich auch in Zukunft kostenlos bleiben. MDN Plus bietet zusätzliche Funktionen für Nutzer, die so außerdem den Betrieb sowie die Weiterentwicklung (auch der kostenfreien Version) der MDN Web Docs unterstützen können. Außerdem erwägt Mozilla, einen Teil der Einnahmen in Open Source-Projekte zu investieren, welche zu den MDN Web Docs beitragen.

Mozilla bietet drei verschiedene Preisstufen an, jeweils mit 20 Prozent Rabatt bei jährlicher Vorauszahlung:

• MDN Core – Diese kostenlose Variante dient zum Reinschnuppern für alle Interessierten. Damit können Benachrichtigungen für bis zu drei Artikel aktiviert werden und bis zu fünf Artikel können in der persönlichen Sammlung gespeichert werden.
• MDN Plus 5 – Dies ist die reguläre Premium-Version, welche alle Premium-Features ohne Begrenzung beinhaltet. MDN Plus 5 kostet 5 Euro pro Monat oder 50 Euro pro Jahr.
• MDN Supporter 10 – Für alle, die Mozilla noch mehr unterstützen wollen. Neben den Features von MDN Plus 5 erhält man Vorab-Zugriff auf kommende Funktionen und Zugang zu einer Feedback-Plattform, um mit dem MDN-Team in Kontakt zu treten. Diese Preisstufe kostet 10 Euro pro Monat oder 100 Euro pro Jahr.

Start in Deutschland, Österreich und Schweiz

Vor knapp einem Monat ist MDN Plus in den USA sowie Kanada an den Start gegangen. Die kostenlose Variante MDN Core ist ab sofort weltweit verfügbar. Die kostenpflichtigen Optionen MDN Plus 5 sowie MDN Supporter 10 lassen sich jetzt in 16 weiteren Ländern abonnieren, darunter Deutschland, Österreich und die Schweiz. Die weiteren Länder sind Belgien, Finnland, Frankreich, das Vereinigte Königreich, Irland, Italien, Malaysia, die Niederlande, Neuseeland, Puerto Rico, Schweden, Singapur sowie Spanien. Weitere Länder sollen in Zukunft folgen.

Das sind die Premium-Features von MDN Plus

Über Änderungen an Artikel benachrichtigen lassen

Nutzer können Artikeln folgen und so über Änderungen benachrichtigt werden, zum Beispiel wenn ein Artikel mit neuen Informationen zur Browser-Unterstützung aktualisiert wird. Über eine Stern-Funktion in der Benachrichtigungs-Liste können Benachrichtigungen auch markiert werden, um diese später zu lesen.

Artikel zu persönlicher Sammlung hinzufügen

Wer ein besonderes Interesse an bestimmten Artikeln hat, kann diese seiner ganz persönlichen Sammlung hinzufügen und findet die Artikel somit ganz einfach an einem zentralen Ort, auf den von überall aus zugegriffen werden kann. Außerdem ist es möglich, Notizen zu den gespeicherten Seiten zu hinterlassen. Seiten, welche häufig besucht werden, werden ebenfalls zur Sammlung, allerdings in einen gesonderten Abschnitt hinzugefügt.

Artikel auch ohne Internet-Zugang lesen

MDN Plus bietet die Möglichkeit, Artikel zur Offline-Nutzung zu speichern, so dass diese auch ohne Internet-Zugang gelesen werden können. Auch die persönliche Sammlung kann offline durchsucht werden und bereits erhaltene Benachrichtigungen können gelesen werden.

… und noch mehr in der Zukunft

Die Beschreibung der Option MDN Supporter 10 deutet es bereits an: In der Zukunft sind weitere Features zu erwarten, zu denen jetzt natürlich noch keine genaueren Angaben gemacht werden können. Zu erwarten ist außerdem, dass es auch den einen oder anderen exklusiven Artikel von Branchen-Experten für MDN Plus geben wird, worin ein bestimmtes Thema besonders genau beleuchtet wird.

Jetzt MDN Plus abonnieren

Der Beitrag MDN Plus startet in Deutschland, Österreich, Schweiz erschien zuerst auf soeren-hentzschel.at.

Do, 28. April 2022, Lioh Möller

Produktives Arbeiten am Computer ist sehr subjektiv und lässt sich schwer messen. Es ist abhängig vom eigenen Workflow und Betriebssysteme oder Desktopoberflächen können den Anwender letztendlich nur unterstützen das Gerät schnell und effektiv zu nutzen.

Viele Nutzer werden bereits im Kindesalter oder spätestens in der Schule auf bestimmte Betriebssysteme oder Anwendungen getrimmt. In den meisten Fällen heisst dies Microsoft Windows oder auch macOS, sowie Applikationen wie Microsoft Office.

Die Struktur deren Benutzeroberflächen ist dabei stark vordefiniert, wobei sich Windows tendenziell besser an die eigenen Bedürfnisse anpassen lässt, als macOS.

Somit gewöhnt sich der Computer nicht an den Anwender, sondern umgekehrt. Der vorgegebene Workflow wird durch Gewöhnung vertraut gemacht.

Freie Software und das Linux Betriebssystem hingegen zeichnen sich durch eine schier unendliche Vielfalt und Anpassbarkeit aus. Zwar ist einige Zeit notwendig, die Oberfläche an die eigenen Bedürfnisse anzupassen, hat man diese jedoch einmal investiert, zahlt sich der individuelle Desktop langfristig aus. Ob Tiling, ein klassisches Layout oder etwas bisher nie dagewesenes, alles ist möglich.

Potenzial hat Freie Software dennoch, so wäre eine automatische Anpassung von Applikationen an das eigene Nutzerverhalten optional wünschenswert. Wenig benutzte Bedienelemente könnten automatisch ausgeblendet werden und andere dafür prominenter platziert werden. Applikationen wie AntennaPod für Android bieten diese Funktionen bereits an.

Optional allerdings insofern, als auch dies nicht allen Anwendern zusagt, insbesondere Menschen, die gerne die volle Kontrolle über ihren Computer behalten möchten, mögen solche Automatismen eher ängstlich stimmen.

Bildungseinrichtungen, die Kinder dahingehend vorbereiten, ein vorgefertigtes Produkt zu nutzen, könnten die Chance wahren, die Vielfalt von Freier Software zu verdeutlichen. Das Arbeiten mit dem Computer sollte funktional erlernt werden, anstatt einen definierten Stand eines kommerziellen Produktes zu erlernen, welches sich in wenigen Jahren wohl möglich vollständig ändert.

Nutzerbefragungen, wie sie beispielsweise im openSUSE Projekt durchgeführt wurden, zeigen deutlich, dass ein Grossteil der Anwender 10 oder mehr Jahre Linux auf dem Desktop nutzt. Das spricht eindeutig für das nachhaltige und anpassbare Betriebssystem.

Screenshot: Window Tiling For The Win (wtftw)

Warum muss ich ein Distributions-Update machen, damit ich die neueste Version von git verwenden kann? Oder von LibreOffice? Damit ich in einer aktuellen Version von Python programmieren kann? Die Zeiten, in denen sich Linux mit jedem Distributions-Update grundlegend verändert, sind seit etlichen Jahren vorbei. Die Zeit ist reif für Rolling-Release-Distributionen, bei denen eine einmalige Installation und in der Folge »kleine« Updates ausreichen.

Wer heute ein neues Notebook kauft und darauf Linux installiert, sollte dieses während der Lebenszeit des Geräts (vielleicht fünf bis sieben Jahre?) mit simplen Updates nutzen können.

In den vergangenen drei Jahren habe ich auf meinem Notebook alle halbe Jahr ein Release-Update von Ubuntu n auf Ubuntu n+1 durchgeführt. Grundsätzlich sind diese Updates keine Hexerei, aber sie dauern relativ lange und durchbrechen die »normale« Nutzung. Nicht selten gibt es während des Updates oder danach Probleme.

Die Verwendung einer LTS-Version, wie ich dies auf meinen Servern handhabe und »Normalanwendern« empfehle, kommt für mich privat nicht in Frage: Als IT-Autor muss ich die gerade neuesten Versionen diverser Programme ausprobieren und will dabei nicht (nur) in virtuellen Maschinen bzw. mit Docker arbeiten.

Natürlich könnte ich statt Ubuntu auch Debian, Fedora oder openSUSE verwenden — aber das Grundproblem ändert sich nicht. Regelmäßig sind, losgelöst von »normalen« Paket-Updates, disruptive Distributions-Updates erforderlich.

In der fernen Vergangenheit waren derartige Distributions-Updates oder gar Neuinstallationen unumgänglich, weil es fundamentale Neuerungen gab: Der Wechsel des Init-Systems von Init-V über Upstart zu systemd, der Wechsel des Dateisystems von ext2 zu ext3, reiserfs, btrfs, xfs oder ext4 (je nach Vorliebe), neue Verfahren, um das Internet per Modem, ISDN, ADSL und WLAN zu nutzen etc. Wann gab es zuletzt derart weitreichende Strukturänderungen in einer Linux-Distribution?

Linux ändert sich aktuell nur inkrementell. Das ist nichts Negatives, sondern ein Zeichen dafür, wie sehr sich Linux im Verlauf von drei Jahrzehnten stabilisiert hat.

Man kann über Extra-Paketformate wie Snap oder Flatpak streiten, über die Segnungen der neuesten Gnome-Version diskutieren, aber letztlich sind die so eingeführten Neuerungen kein zwingender Grund für einen Komplettumbau der ganzen Distribution, weder durch eine Neuinstallation, noch durch ein Distributions-Update.

Was für Firefox, Google Chrome und Thunderbird nun schon seit Jahren selbstverständlich ist, nämlich ein sofortiges Update zur nächsten Version sobald diese fertig ist, genau das will ich auch für andere Werkzeuge des täglichen Bedarfs: git, ssh, zsh, Python, Emacs, vi, Gimp, LibreOffice usw.

Rolling-Release-Distributionen

Die Lösung sind Rolling-Release-Distributionen: Nach einer einmaligen Installation werden je nach Gusto und Sicherheitslage täglich, wöchentlich oder monatlich Paket-Updates installiert. Damit bleibt die ganze Distribution auf dem aktuellen Stand — über viele Jahre hinweg (im Idealfall über die ganze Lebensdauer des Computers).

Natürlich gibt es derartige Distributionen seit Jahren, ja Jahrzehnten (!), wie der folgende Überblick ohne Anspruch auf Vollständigkeit zeigt:

• Arch Linux (verfügbar seit 2001) richtet sich schon bei der Installation dezidiert an Experten. In seiner eng umrissenen Zielgruppe ist Arch Linux seit Jahren sehr populär und gewinnt immer mehr Zulauf, zuletzt auch vom Autor dieser Zeilen …

• EndeavourOS und Manjaro sind benutzerfreundlichere Varianten von Arch Linux. Das reicht immerhin für die Plätze 2 und 4 im distrowatch-Ranking. Auch wenn dieses Ranking umstritten ist, ist es ein Indiz dafür, dass das Rolling-Release-Modell im Mainstream angekommen ist. (Arch Linux, also das Original, lag im April 2022 übrigens nur auf Platz 22.)

• Mit openSUSE Tumbleweed beweist auch SUSE seit 2014, dass das Rolling-Release-Modell funktioniert. Dennoch fliegt Tumbleweed weitgehend unter dem Radar der IT-Berichterstattung. Es ist schwer zu sagen, ob das am mangelnden Marketing oder an den YaST-Eigenheiten liegt. Persönlich hat meine Begeisterung für SUSE-Distributionen jeder Art in den letzten 10 Jahren stark nachgelassen, wobei ich nicht konkret festmachen kann, weshalb: Vielleicht ist es die Kombination von vielen distributionsspezifischen Sonderwegen kombiniert mit zu wenig aktueller Dokumentation?

• Der Rolling Rhino Remix versucht, Ubuntu zu einer Rolling-Release-Distribution macht. Im Wesentlichen ersetzt es die regulären Paketquellen durch devel-Quellen. Um die Updates kümmert sich dann das Script rhino-update. Dieser Ansatz ist zwar simpel, richtet sich aber an sehr experimentierfreudige Linux-User. (So gesehen kann man den Debian-Unstable-Zweig sid auch als Rolling-Release-Distribution bezeichnen.)

Rolling Release für die Massen?

Bei aller Begeisterung für die verfügbaren Rolling-Release-Distributionen fristen diese doch ein Nischendasein. Linux-Einsteiger starten typischerweise mit Ubuntu, Mint oder einer ähnlichen Distribution. Um das Rolling-Release-Modell massentauglich zu machen, müsste einer der Big Player, also z.B. Red Hat (IBM) oder Canonical, auf diesen Zug aufspringen. Das ist unwahrscheinlich: Das Rolling-Release-Modell entfaltet seine Attraktivität eher auf dem Desktop als auf dem Server. Red Hat, SUSE, Canonical & Co. verdienen Ihr Geld aber mit Server-Kunden.

Außerdem gibt es für technisch nicht versierte Desktop-Nutzer noch ein Hindernis: Gnome! Mit wirklich jedem Update funktioniert irgendeine der von mir genutzten Extensions nicht mehr (und ich bin schon dankbar, wenn es nur eine ist). Und leider sind viele Gnome-Konzepte einfach inkompatibel zu meinen persönlichen Vorlieben: Ohne Dash-to-Dock mag ich Gnome ganz einfach nicht verwenden.

Fazit

Meine Wünsche werden wohl Träume bleiben. Für mich persönlich heißt die Lösung aktuell Arch Linux. Nach zwei Monaten im Dauereinsatz bin ich auf keine unüberwindlichen Hindernisse gestoßen. Ob meine Begeisterung ausreicht, dass ich mein Notebook bis zu seiner Ablöse ohne Linux-Neuinstallation nutzen kann, muss sich aber erst zeigen.

Dessen ungeachtet kann ich mir nicht vorstellen, dass sich Arch Linux außerhalb der Freak- und Experten-Liga durchsetzt. Das Rolling-Release-Linux, das ich guten Gewissens auf den Rechner eines technisch nicht versierten Freunds oder einer Verwandten installieren würde, habe ich noch nicht gefunden.

Quellen/Links

• https://archlinux.org
• https://endeavouros.com
• https://manjaro.org
• https://get.opensuse.org/tumbleweed
• https://rollingrhinoremix.github.io

Wenn man sich ein Smart Home aufbaut, möchte man aus verschiedenen Gründen Temperaturen messen. In meinem Fall möchte ich im Heizungsraum die Temperaturen an den Wasserrohren, sowie im Warmwasserspeicher aufzeichnen. Eine einfache und kostengünstige Lösung ist es, das mit einem ESP8266 und dem DS18B20 Temperatursensor umzusetzen. Mit der Software ESPHome ist das auch schnell eingerichtet. Im Folgenden zeige ich, wie man das macht.

ESP8266 und DS18B20 verdrahten

Für dieses Beispiel verwende ich einen ESP8266 Wemos D1 Mini mit drei DS18B20 Temperatursensoren. Sie werden nach folgendem Schema verdrahtet. Das einzige zusätzliche Bauteil ist ein 4,7 kOhm Widerstand, der zwischen den Signal-Pin und VCC gelötet wird.

• 

• 

Der Vorteil von den DS18B20 ist, dass man sehr viele von ihnen parallel betreiben kann. Wenn die Schaltung einmal geschafft ist, kann man weitere Sensoren einfach anschließen. Das ist der Grund, warum ich schraubbare Kontaktklemmen verwendet habe: Dadurch kann ich mit wenig Aufwand neue Sensoren anschließen.

DS18B20: Adresse herausfinden

Dieser Temperatursensor arbeitet mit dem 1-Wire-Protokoll. Um jeden Sensor eindeutig ansprechen zu können, ist die Adresse des Sensors notwendig. Die kann man leider nicht am Gehäuse ablesen, sondern man muss sie via Software erfragen. Wir nutzen das gleich, um unsere Verdrahtung zu überprüfen!

Die Adresse der Sensoren findet man ebenfalls mit ESPHome heraus, indem man ein sehr minimalistisches Programm aufspielt. Wie schon beim Auslesen des Gaszählers startet man mit

esphome wizard heizungstemperatur.yaml

und beantwortet dem Wizard wahrheitsgemäß die 4 Fragen. Die entstandene heizungstemperatur.yaml öffnet man mit einem Editor und fügt unten die folgenden Zeilen hinzu:

# Example configuration entry
dallas:
  - pin: GPIO2

Mittels des folgenden Befehls kompiliert man die Datei und flasht sie auf den ESP8266 (siehe Artikel über den Gaszähler).

esphome run heizungstemperatur.yaml

Der folgende Befehl öffnet die Logdatei des Controllers:

esphome logs heizungstemperatur.yaml

Dort werden die Adressen der angeschlossenen Sensoren angezeigt. Kleiner Tipp: Wenn man immer nur einen Sensor anschließt, behält man den Überblick!

ESPHome für Temperaturmessung flashen

Wenn man nun alle Adressen der Sensoren herausgefunden und notiert hat, kann man das den ESP8266 wie folgt konfigurieren. Den Code fügt man an die bereits erzeugte Datei aus dem Wizard an.

dallas:
  - pin: GPIO2

sensor:
  - platform: dallas
    address: 0x773c01f096c1ee28
    name: "Heizung Vorlauf Temperatur"
  - platform: dallas
    address: 0x783c01f096729728
    name: "Heizung Rücklauf Temperatur"
  - platform: dallas
    address: 0x883c01f096ade428
    name: "Warmwasserspeicher oben Temperatur"

Da mittlerweile der Chip schon die ESPHome-Software aufgespielt hat, kann man bereits jetzt kabellos den neuen Programmcode übertragen. Bei ESPHome nennt sich diese Technik „Over the air“, kurz OTA. Der PC und der ESP8266-Chip müssen sich nur im gleichen Netzwerk befinden.

esphome run heizungstemperatur.yaml

Integration der Temperatursensoren in Home Assistant

Jetzt fehlt nur noch die Integration in den Home Assistant. Glücklicherweise arbeiten die beiden Systeme sehr gut miteinander. Man navigiert im Home Assistant auf Einstellungen, Geräte& Dienste und fügt über das Plus unten rechts eine neue Integration hinzu. Dort sucht man nach „ESPHome“ und gibt im folgenden Fenster die IP-Adresse ein. Wichtig: hierfür muss die API aktiviert sein (das ist eine der Fragen des esphome-Wizards).

Weitere Informationen: https://esphome.io/components/sensor/dallas.html

The post ESPHome: Temperaturmessung mit DS18B20 für Home Assistant first appeared on bejonet.

Ich möchte gar nicht lange um den heißen Brei herumreden: Git ist eine Versionsverwaltung, die hervorragend mit Textdateien bzw. Source Code zurechtkommt, aber nicht mit Binärdateien (Bilder, Musik, Videos, etc.).

Jetzt ist es aber so, dass man gelegentlich doch gleichzeitig Code und Binärdateien in einem Repository braucht.

Bis ca. 1 GB Daten klappt das auch noch recht gut, aber darüber wird's wirklich unangenehm. Leider sind meine Repos, bei denen ich Binärdateien mit drin habe, mittlerweile 2-50 GB groß, und um's kurz zu sagen: Das macht einfach keinen Spaß mehr.

Abhilfe schafft Git LFS - der Git Large File Storage.

Da Git LFS in der Standard-Git-Installation schon enthalten ist (außer ihr habt irgendein total kurioses Setup), gibt's eigentlich keinen Grund das nicht zu verwenden. Die größeren Code-Hosting-Plattformen wie GitHub und GitLab unterstützen Git LFS, und auch der mittels Gitea selbst gehostete Server hat bereits ein entsprechendes Backend integriert, man muss es maximal noch aktivieren.

Für die, die selbst einen Git-Server betreiben übrigens auch ein Vorteil: Das LFS-Backend kann man i.d.R. auslagern, d.h. das muss nicht zwangsweise auf dem gleichen Server liegen. Gitea kann bspw. einen S3-Storage dafür verwenden. Und wer auch den S3-kompatiblen Storage gerne selbst hostet kann dafür bspw. Min.io verwenden. Ich liebe sowas ja :D

Git LFS einrichten

Bevor man Git LFS nutzen kann muss die Erweiterung einmalig installiert werden ("einmalig" bedeutet hier pro Nutzeraccount/pro Gerät gemacht werden):

$ git lfs install

Ein neues Repo mit Git LFS anlegen

Zuerst legt man fest, welche Art von Dateien (im aktuellen Repo) über LFS getrackt werden sollen:

$ git lfs track "*.jpg"
$ git lfs track "*.png"

Daraufhin wird eine Datei namens .gitattributes angelegt, welche man zum Repo hinzufügen muss:

$ git add .gitattributes

Anschließend den Spaß ins Repo committen und fertig:

$ git commit -m "Added .gitattributes file/LFS"
$ git push origin main

Vorhandenes Repo zu Git LFS migrieren, inklusive Rewrite der History

Wenn man ein bestehendes Repo konvertieren möchte wird's etwas komplexer. Hier gibt's zwei Möglichkeiten:

• Nur neue Dateien via Git LFS tracken lassen
• Das komplette Repo neu schreiben um auch bestehende Daten via Git LFS zu tracken

Die erste Option funktioniert im Prinzip so, wie oben beim Anlegen eines neuen Repos bereits beschrieben: Mittels git lfs track tracken lassen, und .gitattributes mit ins Repo aufnehmen.

Hat nur einen gravierenden Nachteil: Wenn man schon ein gutes Gigabyte Daten in einem Repo hat, wird es dadurch nicht schneller. Es vermeidet nur, dass Checkout, Commit, etc. noch langsamer werden.

Migration eines bestehenden Repos

Die wesentlich bessere Option (sofern möglich, schließlich muss jede Person, die das Repo nutzt, mitziehen), ist eine komplette Migration.

Dazu kann man zuerst einen Dry-Run machen:

$ git lfs migrate info --everything --include="*.jpg,*.png"

Und wenn man sich sicher ist, dass das passt, führt man die Migration aus:

$ git lfs migrate import --everything --include="*.jpg,*.png" --verbose

Die Migration erstellt im Prinzip ein komplett neues Repo, welches dann gepusht werden muss. Ein Upload kann entsprechend lange dauern.

Checkout im lokalen Repository

Wer ein bestehendes Repository migriert muss gegebenenfalls noch einen LFS checkout durchführen:

$ git lfs checkout

Führt man den Befehl nicht aus, kann es vorkommen, dass lokalen Dateien, die über LFS verwaltet werden, 0 Byte groß sind.

File-Locking

Git LFS unterstützt auch Lockfiles, wobei vom verwendeten Server abhängt ob man diese benutzen kann oder nicht. In der Regel wird man von Git beim Pushen darauf hingewiesen, wenn ein Server Lockfiles unterstützt, man diese aber noch nicht nutzt.

Um Lockfiles global für alle Repositories zu aktivieren reicht folgender Befehl:

$ git config --global lfs.locksverify true

---

Alternativen zu Git LFS

Ich habe mir auch Alternativen zu Git LFS angesehen und mal zusammengefasst. Ist nicht hübsch, und einzig relevant ist im Prinzip nur git-annex. Da Git LFS aber mehr oder weniger schon Teil der Standard-Git-Installation ist, ergibt git-annex für mich nur dort Sinn, wo es bereits verwendet wird. Für neue Repos würde ich immer zu Git LFS greifen.

Sortierung ist nach absteigender Relevanz bzw. Datum der letzten Aktivität

• git-annex - Dateien werden hierbei in einem seperaten Repository über git-annex verwaltet und auch nur bei Bedarf bzw. auf Befehl heruntergeladen, unterstützt prinzipiell viele und gleichzeitig mehrere Storage-Backends (verteiltes System), Projekt scheint etwas altbacken, öffentliches Repo schwer zu finden, wäre gut möglich, dass das Projekt gerade einen langsamen Tod stirbt, letzter Release August 2020

• git-bigstore - begrenzte Möglichkeit bzgl. Storage-Backend, arbeitet wie git-lfs via .gitattributes`, letzte Änderung Februar 2020

• git-fat - Integration in git ähnlich git-lfs, arbeitet via .gitattributes, Storage muss pro Repo wenn man's richtig macht nur einmalig konfiguriert werden, ein separater Storage ist dennoch nötig, letzte Änderung August 2018

• git-sym - arbeitet mit Symlinks, benötigt einen separaten Befehl (git-sym), keine Automatisierung bzw. viel Handarbeit nötig, letzte Änderung März 2018

• git-bigfile - Fork von git-media mit gleichen Vor-/Nachteilen, Projekt offiziell deprecated (letzte Änderung Juli 2016), empfiehlt die Migration nach git-lfs

• git-media - arbeitet wie git-lfs via .gitattributes, externer Storage nötig welcher separat konfiguriert werden muss, ansonsten scheinbar gut in git integriert, letzte Änderung September 2015

---

Die Inspiration für diesen Artikel stammt übrigens von hier.

Di, 26. April 2022, Lioh Möller

Das openSUSE Projekt hat die Ergebnisse der jährlichen Benutzerbefragung veröffentlicht. Insgesamt nahmen 1320 Personen an der Umfrage teil, von denen 80.83% angegeben haben männlichen Geschlechts zu sein. Der Frauenanteil ist mit lediglich 2.42% weiterhin verschwindend gering.

Ein grosser Teil der Befragten ist zwischen 35 und 44 Jahre alt, um den Nachwuchs bracht sich das Projekt allerdings nicht zu sorgen, den 171 Teilnehmende gaben an unter 25 Jahre alt zu sein.

43.48% gaben an, Linux auf dem Desktop bereits über 10 Jahre hinweg oder länger zu nutzen.

Interessanterweise wählt mit 44.09% ein Grossteil der openSUSE Anwender die Rolling-Release-Variante Tumbleweed. Leap erfreut sich hingegen mit 21.82% nur mässiger Beliebtheit.

Neben Paketen aus den Repositories der Distribution selbst sowie Drittanbieterpaketen im rpm Format gaben 28.79% an Flatpaks zu nutzen.

Die vollständigen Ergebnisse sind im Wiki des Projektes einsehbar.

Wenn ein Ubuntu-Server mit einem Software-RAID betrieben wird, so kann der Status des RAIDs über den Befehl:

cat /proc/mdstat

eingesehen werden. Eine entsprechende Ausgabe könnte dann wie folgt aussehen:

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sda2[0] sdb2[1]
      11714556864 blocks super 1.2 [2/2] [UU]
      bitmap: 6/88 pages [24KB], 65536KB chunk

md0 : active raid1 sda1[0] sdb1[1]
      4189184 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Wird ein RAID neu aufgebaut bzw. synchronisiert sieht die Ausgabe etwas ausführlicher aus:

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sda2[0] sdb2[1]
      11714556864 blocks super 1.2 [2/2] [UU]
      [==================>..]  resync = 94.6% (11088768000/11714556864) finish=153.3min speed=67991K/sec
      bitmap: 12/88 pages [48KB], 65536KB chunk

md0 : active raid1 sda1[0] sdb1[1]
      4189184 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Die Synchronisation kann unter anderem über die Variable speed_limit_max gesteuert werden. Der Standardwert für dieses Limit liegt bei 200000. Wird dieser Wert höher gesetzt:

echo 1250000 > /proc/sys/dev/raid/speed_limit_max

kann die Synchronisation mehr Ressourcen nutzen und läuft somit schneller. Das bedeutet natürlich auch, dass das System im Allgemeinen stärker ausgelastet wird. Nach einem Neustart wird der geänderte Wert wieder auf seinen ursprünglichen Wert gesetzt.

Wenn Node.js unter der aktuellen Ubuntu-LTS Version 22.04 installiert werden soll, so kann hierfür apt benutzt werden:

apt install nodejs

Das Problem an dieser Version aus den offiziellen Paketquellen ist, das sie ziemlich veraltet ist und mittlerweile meist neuere Node.js Versionen benötigt werden. Der gängige Weg wäre es nun die aktuelle LTS-Version von Node.js über den Befehl:

curl -sL https://deb.nodesource.com/setup_16.x | sudo -E bash -
apt install -y nodejs

zu installieren. Allerdings schlägt dies mangels eines für Ubuntu 22.04 hinterlegtem Paket mit folgender Meldung fehl:

Your distribution, identified as „jammy“, is not currently supported, please contact NodeSource at https://github.com/nodesource/distributions/issues if you think this is incorrect or would like your distribution to be considered for support

Hier kann sich beholfen werden, indem das Paket manuell heruntergeladen und installiert wird, um die Prüfung zu umgehen:

wget https://deb.nodesource.com/node_16.x/pool/main/n/nodejs/nodejs_16.9.1-deb-1nodesource1_amd64.deb
apt install ./nodejs_16.9.1-deb-1nodesource1_amd64.deb

Sobald die Pakete für Ubuntu 22.04 (Jammy) unter Nodesource bereitstehen kann das Setup-Skript wieder genutzt werden, um die Pakete aktuell zu halten. Alternativ kann Node.js auch über Snap installiert werden:

snap install node --classic

Dabei wird die aktuelle 18er-Version von Node.js installiert.

Zum Erstellen von fryboyter.de nutze ich Hugo. Und als Webspace nutze ich uberspace.de. Wenn ich beispielsweise einen neuen Artikel schreibe, erstelle ich für diesen einen Commit, den ich in ein Mercurial-Repository auf den Webspace hochlade. Jeder neue Commit löst dann die Ausführung eines Scripts aus, welches die Seite neu erzeugt.

Das Script nutzt hierfür die fertig kompilierte Version von Hugo die von den Entwicklern angeboten wird und die auf dem Webspace abgespeichert ist. Aufgrund von kürzlich erfolgten Änderungen an der Internetseite benötige ich nun die sogenannte extended Version von Hugo. Die aber leider bei Uberspace.de nicht funktioniert, da dort aktuell CentOS 7 zum Einsatz kommt, sodass einige benötigte Pakete zu stabil sind. Oder anders ausgedrückt zu veraltet sind. Hugo bricht daher mit der folgenden Fehlermeldung ab.

/home/laythos/bin/hugo: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /home/laythos/bin/hugo)
/home/laythos/bin/hugo: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /home/laythos/bin/hugo)
/home/laythos/bin/hugo: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/laythos/bin/hugo)

Das Problem ist den Entwicklern bekannt (https://github.com/gohugoio/hugo/issues/9330), aber aus nachvollziehbaren Gründen werden für alte Distributionen keine fertig kompilieren Versionen angeboten.

Also bleiben in dem Fall zwei Möglichkeiten. Man erzeugt die Internetseite jedes Mal lokal und lädt diese beispielsweise mit rsync auf den Webspace. Oder man kompiliert eine Version von Hugo die CentOS 7 unterstützt. Ich habe mich für letzteres entschieden.

Das Kompilieren direkt auf einem Uberspace sollte man allerdings nicht probieren. Denn dort kann man maximal 1,5 GB RAM nutzen. Alles, was mehr braucht, wird automatisch beendet. Was bei Hugo der Fall ist.

Daher habe ich mir von https://www.osboxes.org eine virtuelle Umgebung von CentOS 7 heruntergeladen und mit VirtualBox gestartet. Anschließend habe ich golang sowie gcc-c++ installiert. Ersteres über Umwege, da Go scheinbar nicht in den offiziellen Paketquellen vorhanden ist.

Danach bin ich wie folgt vorgegangen.

wget https://github.com/gohugoio/hugo/archive/refs/tags/v0.97.3.zip
unzip https://github.com/gohugoio/hugo/archive/refs/tags/v0.97.3.zip
cd hugo-0.97.3
go build --tags extended

Mit dem ersten Befehl wir der Sourcecode der derzeit aktuellen Version heruntergeladen. Mit dem zweiten Befehl wird dieser entpackt. Der dritte Befehl wechselt in das betreffende Verzeichnis, in dem die Dateien entpackt wurden. Und der letzte Befehl kompiliert die extended Version von Hugo.

Wenn der letzte Befehl erfolgreich ausgeführt wurde, was je nach Hardware ein paar Minuten dauern kann, sollte man im gleichen Verzeichnis die Datei hugo finden. Diese kopiert man dann einfach auf seinen Uberspace. Damit sollte dann das Erzeugen der Internetseite ohne Fehlermeldungen funktionieren.

Unter https://e1.pcloud.link/publink/show?code=kZSMfzZx0nn3yYPAEVOyuhqvPPdgLfvF5ek habe ich die aktuelle von mir erzeugte Version von Hugo die bei Uberspace.de funktioniert hochgeladen. Wer will (und mir vertraut), kann diese gerne nutzen.

Ubuntu 22.04 liefert Firefox als Snap aus und nicht mehr als klassische DEB-Datei. Man kann das Snap deinstallieren und Firefox in der ESR-Version über ein PPA installieren. Wie du das tun kannst und vor allem wann du das tun solltest, steht in diesem Artikel.

Warum macht Canonical das bei Ubuntu?

Der Internetbrowser und der Mailclient sind die häufigsten Einfallstore für Schadsoftware am Desktop. Entsprechend oft werden hier Sicherheitslücken entdeckt und ausgebessert. Das bedeutet für Distributoren viel Arbeit.

Klassische Linux-Programme, wie sie in DEB oder RPM-Dateien paketiert sind, haben zudem keine modernen Sicherheitsfunktionen, wie z. B. Sandboxes oder Beschränkungen der Berechtigungen. Diese sind durch die mobilen Betriebssysteme Android und iOS inzwischen weit verbreitet und werden auch am Desktop adaptiert. Die Entwicklungen bei Linux heißen Flatpak und Snap. Große und wichtige Distributoren wie SUSE, Red Hat oder Canonical entwickeln bereits länger in diese Richtung.

Außerdem gibt es Probleme durch die Verschränkung von Basissystem und Anwenderprogrammen und dadurch Schwierigkeiten, neue Programme für eine alte Basis zurück zu portieren. Deshalb sind Linux-Distributionen momentan in zwei Lager „Rolling Release“ und „Stable“ getrennt und du bekommst in Ubuntu-Versionen während der Supportdauer nie neue Programme. Das wollen die Entwickler damit auch lösen.

Das Snap wird zudem direkt durch Mozilla, die Entwicklerorganisation hinter Firefox, gepflegt. Das spart Arbeit für den Distributor und sorgt für Verlässlichkeit für die Anwender. Verzögerungen bei Updates, wie sie bisher immer mal wieder vorkamen, gehören damit vermutlich der Vergangenheit an.

Aber man liest so viel schlechtes darüber

Die meisten schreiben nur nach, was sie irgendwo gelesen haben. Die meisten Kritiker nutzen es nicht selbst und haben eher ideologische Vorbehalte. Bei Linux ist die Zahl der Novitätenskeptiker noch größer als in anderen gesellschaftlichen Bereichen, weil viele Linux-Anwender mal vor Entwicklungen bei Windows oder macOS zum konservativen Linux geflohen sind. Wenn man diesen Leuten immer gefolgt wäre, hätte die Menschheit heute weder Rad noch Feuer.

Vertraue niemandem, der irgendetwas von bewährter Technik schreibt. Hinterfrage bei denjenigen immer, ob sie sich wirklich mit der neuen Technik beschäftigt haben oder einfach nur aus Prinzip alles doof finden. Mit krampfhaftem Festhalten an alten Konzepten manövrierst du dich in eine Sackgasse und landest da, wo die Novitätenskeptiker jetzt schon stehen. Vollkommen überfordert durch die Entwicklung, ängstlich gegenüber der Gegenwart, was sie hinter einem Schutzpanzer aus Trotz und „Brauch ich nicht“ verstecken, bis es gar nicht mehr anders geht, weil dein Arbeitgeber, Familie oder Freunde dich zwingen jahrzehntelange Entwicklungen auf einen Schlag nachzuholen.

Ein anderes Problem sind konzeptionelle Differenzen, ob Flatpak oder Snap der richtige Weg sind und ob es nicht noch eine bislang unbekannte noch bessere Lösung gibt. Darüber kann und sollte man diskutieren, aber das tangiert dich als normalen Anwender nicht. Ist man wie du Ubuntu-Anwender folgt man den Entscheidungen von Canonical und das ist gegenwärtig Snap. Wenn Canonical in ein paar Jahren was anderes macht, gibt es für dich einen Upgradepfad, auch darum brauchst du dich nicht kümmern.

Wann sollte ich also mein Snap durch ein PPA ersetzen?

Wenn du ein konkretes Problem hast, von dem du belegbar weißt, dass es durch die Umstellung auf Snap ausgelöst wurde. Dann solltest du überlegen, das PPA einzubinden. Aber nur dann!

Also nicht, wenn du irgendwie das Gefühl hast, ein Problem zu haben oder dir ein Schlaumeier erzählt, dass Snaps irgendwie blöd sind, sondern wenn du ein verifizierbares Problem hast. Davon gibt es ein paar, aber es sind nicht so viele wie oft suggeriert wird. Beispielsweise weil du eine KeePass-Passwortdatenbank nutzt und diese mit einem Browseraddon mit Firefox verbinden möchtest. Oder weil du richtig alte Hardware hast und z. B. noch eine normale Festplatte, wodurch Firefox als Snap merkbar verzögert startet.

Soll ich zu Distribution xyz wechseln?

Wenn du ansonsten mit Ubuntu zufrieden bist nicht. Auch in anderen Teilen des Linux-Universums wird die Welt nicht stehen bleiben. Alle Distributoren mit sogenannten LTS-Distributionen experimentieren aktuell mit neuen Zukunftsmodellen. Red Hat arbeitet bei Fedora an Projekt Silverblue, dagegen ist das eine Snap in Ubuntu gar nichts. Bei SUSE überlegt man aktuell eine ganz neue Linux Plattform zu konzipieren.

Aber über das PPA gibt es nur Firefox ESR

In dem unten aufgeführten PPA ist nicht der normale Firefox enthalten, weil den Mozilla ja als Snap bereitstellt, sondern die ESR-Variante von Firefox. Manche erzählen, dass das doof ist und du deshalb die Distribution wechseln solltest. Das ist Quatsch.

Erstens ist Firefox ESR bis auf ganz kleine Unterschiede ein normaler Firefox. Man überspringt lediglich einige Releases und bekommt neue Funktionen nur alle paar Monate. Wer eine LTS bei Linux nutzt, dürfte dieses Konzept eher befürworten.

Zweitens hilft ein Wechsel auf eine andere Distribution nicht. Debian, die RHEL-Klone (Alma Linux, Oracle Linux oder Rocky Linux) oder openSUSE Leap nutzen ebenfalls die ESR-Version von Firefox.

Wie ersetze ich das Snap Paket durch ein PPA?

Vor der Umstellung unbedingt das Firefox-Profil sichern, wenn du bereits Daten in Firefox hast.

Wenn du wirklich ein Problem hast und deshalb das klassische DEB-Programm brauchst, ist das nicht weiter schwierig. Mozilla pflegt nämlich extra für Ubuntu mehrere PPAs, weil Ubuntu die wichtigste Linux-Distribution ist.

Du brauchst nur drei Terminalbefehle, um deinen Snap-Firefox gegen das PPA zu ersetzen.

$ sudo snap remove firefox

$ sudo add-apt-repository ppa:mozillateam/ppa && sudo apt update

$ sudo apt install firefox-esr firefox-esr-locale-de

Fertig! Total einfach und sicher kein Grund, die Distribution zu wechseln.

Änderung 23.04.2022

Zwei Punkte dazugenommen (Distributionswechsel, Firefox ESR) und einen Aspekt umgestellt.

Der Artikel Ubuntu – Wie du Firefox als PPA anstelle von Snap einbindest und wann du es tun solltest erschien zuerst auf [Mer]Curius

Nun ist es soweit. Ubuntu ist da und die Firefox-Snap-Realität ist eingetreten. Die Hölle gefriert, es regnet tote Frösche und so mancher Altvorderer vor seinem 19″ (4:3 Formaaaaat!) beißt in seine mechanische IBM-Tastatur. Eine nicht ganz ernst gemeinte Presseschau.

Ich hatte überlegt, einen Test zu schreiben, aber alles wesentliche hatte ich hier bereits in einer Vorschau geschildert. Das Osterwochenende nutzte ich bereits um ein paar Maschinen auf Kubuntu 22.04 (es ist leider vorerst kein openSUSE geworden) umzustellen. Teilweise per Upgrade, teilweise per Neuinstallation, um hartnäckige Probleme endlich loszuwerden. Kubuntu 22.04 ist ein sehr rundes Release geworden. Plasma 5.24 LTS in Kombination mit KDE Gear 21.12 ist in einem Zustand, den man bedenkenlos 3 Jahre nutzen kann. Angesichts des demnächst sicher irgendwann mal einsetzenden Wechsels auf Qt 6 bzw. Plasma 6 ist Kubuntu 22.04 vielleicht für manche Anwender ein sicherer Hafen, um die Stürme auszusitzen (die hoffentlich nicht Orkanstärke erreichen). Die Zahl der Neuerungen hält sich aber dermaßen in Grenzen – standardmäßig setzt Kubuntu nicht mal auf Wayland – dass ich mir einen umfassenden Testbericht spare. Ich wüsste gar nicht, was ich schreiben sollte. KDE-Software liegt halt in einer neuen Version vor.

Das erledigen andere und ich hatte ja bereits prognostiziert, dass die Entscheidung für Snaps es in viele Artikel schaffen würde. Gewohnt niveaulos und schwer zu übertreffen startet Heise, die in ihrem Titel schreiben: „GNOME 42, Wayland als Standard und Snap-Ärger„. Was dieser Snap-Ärger sein soll, erschließt sich nach Lektüre des Artikels nicht. Es werden viele Behauptungen in den Raum gestellt, aber der Autor hat vor allem Probleme mit KeePass. Nun, logische Argumentation darf man bei Heise-Autoren schon lange nicht mehr erwarten. Letztlich sind die Artikel ja auch nur noch der Auftakt für den Trollsportverein im Forum, dessen Klicks vermutlich die Existenz des Verlags sichern.

Michael Kofler mag Snaps auch nicht. Aber wenigstens argumentiert er nicht auf Heise-Niveau, sondern zeigt ein paar Lösungswege auf. Dass Snaps eine Antwort auf die von ihm bemängelten veralteten Versionsstände sind, ist ihm irgendwie entgangen. Ansonsten scheint das Problem mit KeePass als Textbaustein wohl an alle Snap-Gegner geschickt worden zu sein. Ich wünschte ja wirklich, dass das ein Problem für die Allgemeinheit wäre, denn dann wären Passwortverwaltungen endlich Standard. Träume darf man noch haben. Kofler hat auch noch nichts von modernen Dateisystemen mit Deduplizierung gehört (die mag er auch nicht so), wobei das in diesem Fall sogar in Ordnung geht, weil Ubuntu ja standardmäßig ext4 nimmt. Wenigstens kommt er abschließend zur Einschätzung, dass Ubuntu (oder Mint) eben doch die Einstiegsdistribution ist und bleibt. Bei vielen im Linux-Universum hat sich ja hier eine komische Wahrnehmungsverzerrung eingebürgert und alle glauben jeder würde MX Linux oder Arch Linux nutzen.

Bei Golem haben sie Snaps mit keinem Wort erwähnt. Sakrileg! Ich bin schwer enttäuscht. Zum Glück hat ein Kommentator diesen Fauxpas erkannt und halbherzig ergänzt. Mal schauen, ob noch jemand den KeePass-Textbaustein einbaut.

Auf Linuxnews werden Snaps auch nicht gerne gesehen, aber Ferdinand Thommes verweist da eher auf den Ubuntu-Sonderweg und fragt sich, ob die Reise nicht doch eher in Richtung Flatpak geht. Kann man definitiv so sehen, wir erinnern uns ja alle an Unity, Mir, Upstart usw. usf.

MichlFranken hat immerhin mal einen tieferen Blick ins System geworfen und festgestellt, dass außer Firefox gar keine anderen Snaps vorinstalliert sind. Bei Heise & Co hört sich das manchmal anders an. Aber vielleicht konnten die auch einfach nicht so gut testen, weil Virtualisierung auf den neuen Apple M1 Maschinen ja nicht mehr so gut klappt.

Andreas Proschofsky hat für DerStandard einen sehr lesenswerten und umfassenden Testbericht geschrieben. Snap ist bei ihm nur ein Thema unter vielen und Proschofsky konzentriet sich auf wirkliche Probleme anstelle pauschaler Kritik. Außerdem wirft er die Frage auf, warum Canonical es nicht gleich richtig macht und viel stärker auf Snap setzt. Wenn schon, denn schon. Berechtige Fragen.

Den meisten Anwendern wird dieses Problem wohl verborgen sein. Hast du ein Problem mit Snaps? Nein, nur ohne. Zum Wohl! Auf ein weiteres gutes Release. Mal sehen, wie die Linux-Welt bei der nächsten LTS 2024 aussieht.

Nachtrag 24.04.2022

Test aus dem Standard ergänzt.

Der Artikel Ubuntu 22.04 erschienen – Jeder Tag fängt mit einem Schnaps an erschien zuerst auf [Mer]Curius

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

Neuerungen von Thunderbird 91.8.1

Mit dem Update auf Thunderbird 91.8.1 hat die MZLA Technologies Corporation ein Update außer der Reihe für seinen Open Source E-Mail-Client veröffentlicht und behebt damit mehrere Fehler der Vorgängerversion. Diese lassen sich in den Release Notes (engl.) nachlesen.

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

Do, 21. April 2022, Ralf Hersel

Canonical hat heute Ubuntu 22.04 LTS mit dem Namen 'Jammy Jellyfish' zum Download freigegeben. Diese Long-term-support Version erhält während der nächsten fünf Jahre Updates. Wer es genau wissen möchte, kann die Details über LTS hier nachlesen. Ubuntu 22.04 LTS enthält die neueste GNOME-42-Desktop-Umgebung mit dem Triple-Buffering-Patch, verwendet aber aufgrund von Kompatibilitätsproblemen zwischen GTK4-Applikationen in der Upstream-Version und Ubuntus Yaru-Theme noch Anwendungen aus dem GNOME-41-Stack, wie z.B. den Dateimanager Nautilus (Files).

In dieser Version gibt es neue Einstellungen, um das Aussehen und Verhalten des Docks zu steuern, einen systemweiten dunklen Stil für alle Anwendungen und Dialoge, eine verbesserte Integration von Dock-Geräten und Dateimanager sowie 10 Akzentfarben für die dunklen und hellen Stile des Standard-Yaru-Themas, das nun das Aussehen und die Bedienung von GTK4-Anwendungen nachahmt.

Ein weiteres wichtiges Merkmal von Ubuntu 22.04 LTS ist die langjährig unterstützte Linux-Kernel-Serie 5.15 LTS, die eine neue Implementierung des NTFS-Dateisystems mit sich bringt, mit der man Daten lesen und schreiben kann, ohne auf einen Treiber oder eine Software eines Drittanbieters angewiesen zu sein. Der Linux-Kernel 5.15 LTS wird bis mindestens Oktober 2023 mit Sicherheits- und Bugfix-Updates unterstützt.

Darüber hinaus bringt Jammy Jellyfish RDP-Unterstützung für die gemeinsame Nutzung des Desktops aus der Ferne mit besserer Sicherheit, Privatsphäre und Leistung, Wayland als Standardsitzung für die meisten Systeme, die keine NVIDIA-Grafikkarte haben, es gibt Unterstützung für Hardware mit Privacy-Screen-Unterstützung, UDP ist jetzt standardmässig für NFS-Mounts deaktiviert und es gibt ein neues Logo, das man auf dem Startbildschirm und auf der Info-Seite der Einstellungen-App sehen kann.

Zu den weiteren Änderungen in dieser Version gehört die Unterstützung des Pakets linux-restricted-modules auf der ARM64-Plattform (AArch64) für NVIDIA-Treiber, um die Verwendung des Tools ubuntu-drivers zur Installation und Konfiguration von NVIDIA-eigenen Treibern aus den Ubuntu-Repositories zu ermöglichen, sowie die Unterstützung der neuesten Linux 5.17-Kernel-Serie für OEMs. Ausserdem ist ssh-rsa jetzt standardmässig in OpenSSH deaktiviert, um die Sicherheit zu erhöhen.

Darüber hinaus zeigt Ubuntu beim Upgrade keine anderen installierten Betriebssysteme mehr im Boot-Menü an, es sei denn, man führt eine Neuinstallation durch und hat bereits ein anderes Betriebssystem installiert. Nftables ist jetzt das Standard-Backend für die Firewall und der Mozilla Firefox Webbrowser wird in Ubuntu nur noch als Snap-Paket angeboten.

Ubuntu 22.04 LTS (Jammy Jellifish) steht als Desktop- und Server-Images sowie als eine der offiziellen Varianten (z.B. Kubuntu, Xubuntu, Lubuntu, etc.) zum Download bereit. Eine Übersicht über die Neuerungen bei den Varianten findet ihr hier. Ubuntu wird in den nächsten 5 Jahren bis April 2027 mit Standard-Wartungsupdates und regelmässigen Point-Releases alle sechs Monate unterstützt, während die anderen Varianten bis April 2027 verfügbar sein werden.

Wie immer, gibt es die "Things to do After Installing Ubuntu", zum Beispiel hier. Abhishek Prakash hat dort eine ziemlich vollständige Liste mit 22 Punkten abgeliefert, die man sich nach der Installation anschauen kann. Einen wichtigen Punkt hat er jedoch vergessen: Firefox als Snap-Paket kommt nicht mit dem KeePass-Plugin zurecht. Denn das Keepass-Plugin für Firefox versucht, ein externes Hilfswerkzeug aus GNOME für die Passwort-Eingabe aufzurufen – aber das entsprechende Binary ist im Snap-Paket nicht vorhanden. Daher ist es ratsam, das Snap-Paket vollständig zu entfernen und durch ein Debian-Paket von Firefox zu ersetzten.

Quelle: https://www.releases.ubuntu.com/22.04/

Mit Ubuntu 22.04 »Jammy Jellyfish« hat Canonical die neueste LTS-Version von Ubuntu fertiggestellt. Aktuelle Software kombiniert mit einem Update-Versprechen über fünf Jahre sind die Hauptargumente für die Distribution — und zwar gleichermaßen im Desktop- wie im Server-Segment. Fundamentale technische Neuerungen gibt es keine, einige richtungsweisende Entscheidungen aber sehr wohl: Wayland gilt nun als Default-Grafiksystem, und Firefox wird als Snap-Paket ausgeliefert. Letztere Entscheidung wird nicht nur auf Zustimmung treffen …

Anmerkung: Dieser Blog-Beitrag berücksichtigt ausschließlich das »originale« Ubuntu für den Desktop, nicht die diversen Derivate bzw. die Server-Version.

Installation

Eigentlich wollte Canonical Ubuntu einen neuen, mit der Bibliothek Flutter entwickelten Installer verpassen. Daraus ist nichts geworden, das Programm wurde nicht rechtzeitig fertig. Der Installer ist somit im Vergleich zu den Vorversionen unverändert, was aus meiner Sicht kein Nachteil ist: Das Programm ist einfach zu bedienen und funktioniert gut.

Der Platzbedarf für eine Standardinstallation beträgt ohne /swapfile ca. 6,4 GByte. Wie viel Platz der Installer für die Swap-Datei vorsieht, hängt von der Hardware des Rechners ab, auf dem Sie Ubuntu installieren.

Gut 6 GByte sind zwar angesichts des breiten Software-Angebots akzeptabel, das Attribut »schlank« trifft auf Ubuntu aber schon lange nicht mehr zu. Die Snap-Pakete sind daran nicht alleine Schuld, leisten aber natürlich auch einen Beitrag: Der Platzbedarf für /var/lib/snapd/snaps beträgt anfänglich ca. 640 MByte. Selbst wenn Sie keine weiteren Snap-Pakete installieren, verdoppelt sich der Umfang des Snap-Verzeichnisses früher oder später, weil bei Updates immer auch die vorige Version aller Snap-Pakete erhalten bleibt.

Desktop-Neuerungen

Relativ viele Änderungen bzw. neue Einstellmöglichkeiten gibt es im Gnome-Desktop. Zum Teil handelt es sich dabei einfach um neue Features von Gnome 42, zum Teil um Erweiterungen, die Canonical in den Gnome-Desktop integriert hat:

• In den Einstellungen kann zwischen der normalen Darstellung der Fenster und dem »Dark Mode« gewechselt werden.
• Es stehen zehn Kontrastfarben für ausgewählte Elemente zur Auswahl.
• Auf dem Desktop können unkompliziert Icons abgelegt werden. Dazu ziehen Sie Dateien oder Verzeichnisse per Drag&Drop aus dem Dateimanager auf den Desktop. Intern werden die Dateien dadurch in das Verzeichnis Schreibtisch verschoben.
• Bei Notebooks kann im Systemmenü einer von mehreren Energiemodis aktiviert werden.
• Die Tools zur Aufnahme von Screenshots bzw. Screencasts wurden modernisiert.

Beachten Sie, dass die Verwaltung der Gnome Shell Extensions im Snap-Firefox nicht funktioniert. Sie müssen stattdessen das Paket gnome-shell-extensions installieren und ausführen.

Software-Versionen

Wie üblich wurden fast alle Software-Versionen auf den aktuellen Stand gebracht. Erfreulicherweise trifft dies auch für Gnome zu, das in der aktuellen Version ausgeliefert wird. Ausgenommen sind lediglich vereinzelte Gnome-Anwendungen: In Gnome 42 wurden einige Apps auf die neue Bibliothek GTK4 aktualisiert. Ubuntu geht solchen Programmen aus dem Weg und verwendet gegebenenfalls die ältere Version. Das betrifft z.B. die Kalender-App (gnome-calendar).

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel     5.15   Gnome          42   bash       5.1   Apache     2.4
glibc      2.35   Firefox        99   docker   20.10   CUPS       2.4
X-Server   1.21   Gimp         2.10   gcc       11.2   MySQL      8.0
Wayland    1.20   LibreOffice   7.3   git       2.34   OpenSSH    8.9
Mesa       22.0   Thunderbird    91   Java        11   qemu/KVM   6.2
Systemd     249                       PHP        8.1   Postfix    3.6
NetworkMan 1.36                       Python    3.10   Samba     4.15
GRUB       2.06 

Firefox und Snap

Wie bereits in Version 21.10 wird Firefox nicht mehr als »gewöhnliches« Paket, sondern in Kooperation mit der Mozilla-Organisation als Snap-Paket ausgeliefert. Für Canonical erleichtert das die Wartung. Für den Anwender ergeben sich daraus aber drei Nachteile:

• Der Platzbedarf auf dem Datenträger und im RAM ist wesentlich höher.

• Der erstmalige Start des Programms spürbar langsamer. Selbst die Ubuntu-freundliche Website omgubuntu macht sich darüber in einem Video lustig (siehe ab 3:40). Der lahme Start hat damit zu tun, dass nicht nur Firefox an sich geladen wird, sondern auch ein riesiges Paket von (vollkommen redundanten) Bibliotheken.

• Es gibt Kompatibilitätsprobleme, z.B. im Zusammenspiel mit der Verwaltung der Gnome-Shell-Erweiterungen oder mit dem Passwort-Tool KeePass.

Wenn Sie das Firefox-Snap-Paket durch ein traditionelles Paket ersetzen möchten, gehen Sie so vor:

sudo snap remove firefox
sudo add-apt-repository ppa:mozillateam/ppa
sudo apt install -t 'o=LP-PPA-mozillateam' firefox

Vorsicht: Einfach sudo apt install firefox funktioniert nicht, weil dadurch neuerlich das Snap-Paket installiert wird! Damit das nächste apt update nicht wieder die Snap-Version von Firefox installiert, müssen Sie außerdem die Priority-Einstellungen für apt verändern:

sudo sh -c 'cat > /etc/apt/preferences.d/mozilla-ppa' << EOF
Package: firefox*
Pin: release o=LP-PPA-mozillateam
Pin-Priority: 501
EOF

Alternativ können Sie natürlich auch Chrome (von der Google-Website) oder Chromium (Paket chromium-browser) installieren.

Wayland per Default

Wie alle gängigen Distributionen werden auch bei Ubuntu der herkömmliche Grafik-Server Xorg und das neue System Wayland parallel installiert. Nach Möglichkeit kommt in Ubuntu 22.04 standardmäßig Wayland zum Einsatz. Im Idealfall soll das sogar bei Grafikkarten mit NVIDIA-Treiber funktionieren. Auf meinem Notebook (Lenovo P1, Quadro P1000 Mobile), ist das aber nicht der Fall: Beim Login gibt es keine Wahl zwischen den unterschiedlichen Grafikbibliotheken, Gnome verwendet wie in älteren Ubuntu-Versionen Xorg (X11) als Grafiksystem. Vermutlich liegt das daran, dass Hybridsysteme (Intel + NVIDIA GPU) noch nicht unterstützt werden.

Dafür hat Wayland bei meinen Tests anstandslos in virtuellen Maschinen funktioniert. Auch das Zusammenspiel auf Computern mit Intel- oder ADM-Grafik sollte klappen.

Distributions-Update mit »do-release-upgrade«

Auf meinem Arbeits-Notebook habe ich zwei Tage vor dem offiziellen Release ein Update von Version 21.10 auf die aktuelle Version durchgeführt. Der Prozess hat zwar ca. eine Stunde gedauert, ist aber komplett problemlos verlaufen.

sudo apt update
sudo apt dist-upgrade
sudo reboot
sudo do-release-upgrade -d --allow-third-party

  ...
  11 packages are going to be removed. 174 new packages  
  are going to be installed. 2198 packages are going to 
  be upgraded. 

  You have to download a total of 2,857 M. This download 
  will take about 7 minutes with your connection. 

  Installing the upgrade can take several hours. Once the 
  download has finished, the process cannot be canceled. 
  ...

Fazit

Für Linux-Einsteiger bzw. Leute, die Linux als Desktop-Betriebssystem anwenden möchten, ohne sich Gedanken über technische Hintergründe zu machen, ist Ubuntu weiterhin eine gute Wahl:

• In aller Regel funktioniert Ubuntu ganz einfach.
• Das Aussehen und Verhalten des Desktops ist (aus meiner Sicht) besser als bei Distributionen mit dem originalen Gnome.
• Ubuntu bietet inklusive PPAs und Snaps das wohl beste Software-Angebot in der Linux-Welt.
• Dank der großen Verbreitung ist es einfach, im Freundeskreis oder im Internet Hilfe zu finden.

Ich kann für diese Zielgruppe unter den aktuellen Distributionen keine bessere Alternative zu Ubuntu erkennen. Am ehesten ist wohl Linux Mint geeignet (das aber selbst von Ubuntu abgeleitet ist).

Persönlich spricht mich Ubuntu allerdings immer weniger an. Ich halte Snap-Pakete für einen Irrweg (und die von Red Hat favorisierte Alternative FlatPak auch nicht nennenswert besser). Der LTS-Vorteil einer langen Lebenszeit ist für mich angesichts des über den Verlauf der Jahre zunehmend veralteten Software-Stacks für meine Desktop-Anwendung als Entwickler/Admin uninteressant.

Quellen und Links

• Download
• Release Notes
• DistroWatch
• heise.de
• golem.de
• derstandard.at
• omgubuntu.co.uk

Sonstiges:

• https://ubuntuhandbook.org/index.php/2022/04/install-firefox-deb-ubuntu-22-04
• https://www.omgubuntu.co.uk/2022/04/installed-ubuntu-22-04-do-these-things-next
• https://www.omgubuntu.co.uk/2022/04/ubuntu-22-04-video-jammy-jellyfish
• https://www.omgubuntu.co.uk/2022/01/ubuntu-22-04-may-include-gnome-42-but-not-gtk4

Für Videokonferenzen nutze ich das Tool Jitsi Meet Electron. Das ist das einzige Programm, welches ich auf meinem GNU/Linux Desktop als AppImage ausführe.
Ich gehe auf GitHub https://github.com/jitsi/jitsi-meet-electron und lade mir das AppImage jitsi-meet-x86_64.AppImage herunter. Nun werden noch die Rechte auf die Datei gesetzt.

chmod u+x Downloads/jitsi-meet-x86_64.AppImage

Jetzt ist das AppImage ausführbar und kann z.B. mit einem Doppelklick gestartet werden.
Der Vorteil im Gegensatz zu Jitsi Meet im Webbrowser ist unter anderem der, dass ihr Jitsi Meet schon vorher konfigurieren(*) könnt, bevor ihr einer Videokonferenz beitretet.

(*) Nickname festlegen; Mikrofon und Kamera AN oder Aus stellen

Die Veröffentlichung von openSUSE Leap 15.4 steht in einigen Wochen an. Die revolutionären Veränderungen bei SUSE für die Enterprise-Distribution SUSE Linux Enterprise werfen jedoch schon ihre Schatten voraus. Einen ersten Ausblick gibt es nun.

Lubos Kocman, seines Zeichens Produktmanager für openSUSE Leap, äußerte sich dazu auf der Factory Mailingliste. Natürlich sind das alles noch frühe Überlegungen, da die Entwicklungen bei SUSE für SLE 16 noch nicht substanziell begonnen haben. Klar scheint aber zu sein, dass es nächstes Jahr nochmal eine Leap-Version des bewährten 15er-Zweiges gibt. Diese wird deutlich konservativer als die unmittelbar bevorstehende Version 15.4 werden und sich mehr auf Produktpflege konzentrieren.

Während es für SLE 15 noch weitere Service Packs geben wird, ist für openSUSE Leap aktuell keine Veröffentlichung des 15er Zweiges über die Version 15.5 hinaus geplant. Stattdessen soll danach auf das neue ALP-SUSE umgestellt werden. Das angekündigte offene Entwicklungsmodell von SLE 16 soll hier dabei helfen die Umbrüche frühzeitig einschätzen zu können, um für openSUSE die richtigen Schlüsse ziehen zu können. Ob das alles so kommt, weiß zum aktuellen Zeitpunkt sowieso niemand sicher.

Bis dahin wird aber noch einiges an Zeit vergehen. Bei einer Veröffentlichung von openSUSE Leap 15.5 im Juni 2023 und der Nachfolgeversion im Sommer 2024 und der obligatorischen Übergangsperiode können Anwender also noch bis Ende des Jahres 2024 den bewährten openSUSE Leap 15er Zweig nutzen. Genug Zeit also um das neue ALP-Konzept auf sich wirken zu lassen und zu entscheiden, ob man den Weg mitgehen möchte oder eben nicht,.

Der Artikel Ausblick auf die mittelfristige Zukunft von openSUSE Leap erschien zuerst auf [Mer]Curius

Di, 19. April 2022, Ralf Hersel

In einem Blog-Beitrag äussert sich der Debian-Entwickler Steve McIntyre zum Umgang mit proprietärer Firmware im Debian Projekt. Seiner Meinung nach ist die Art und Weise, wie das Projekt mit (unfreier) Firmware in Debian umgehen, ein Schlamassel, das vielen Benutzer:innen schadet. Lange Zeit habe man so getan, als ob die Unterstützung und Einbindung von (unfreier) Firmware auf Debian-Systemen nicht notwendig sei. Man wollte den Benutzern keine (unfreie) Firmware zur Verfügung stellen, was in einer idealen Welt auch nicht nötig wäre. Für McIntyre ist dies jedoch kein vernünftiger Weg mehr, wenn man aktuelle Hardware unterstützen möchte.

Firmware ist die Low-Level-Software, die dafür sorgt, dass Hardwaregeräte funktionieren. Firmware ist eng an die Hardware gekoppelt, stellt ihre Funktionen zur Verfügung und bietet übergeordnete Funktionen und Schnittstellen für andere Software an. Aus einer Vielzahl von Gründen ist sie typischerweise keine Freie Software.

In der Vergangenheit wurde die gesamte erforderliche Firmware normalerweise direkt von den Herstellern in die Geräte/Erweiterungskarten integriert. Im Laufe der Zeit wurde es jedoch für die Gerätehersteller immer attraktiver (und daher auch üblicher), nicht auf allen Geräten eine vollständige Firmware mitzuliefern. Stattdessen enthalten einige Geräte nur einen sehr einfachen Satz von Firmware, der das Hochladen eines vollständigeren Firmware-"Blob" in den Speicher ermöglicht. Von den Gerätetreibern wird dann erwartet, dass sie diesen Blob während der Initialisierung des Geräts bereitstellen.

Für diese Änderung gibt es mehrere Hauptgründe. Kosten: Es ist in der Regel billiger, einen kleineren Flash-Speicher (oder gar keinen Flash-Speicher) in ein Gerät einzubauen. Flexibilität: Es ist viel einfacher, das Verhalten eines Geräts zu ändern, indem man einfach zu einem anderen Blob wechselt. Aus diesen Gründen müssen heute immer mehr Geräte in einem typischen Computer zur Laufzeit mit Firmware versorgt werden, damit sie korrekt funktionieren.

Vor etwa 10 Jahren brauchten die meisten Computer nur Firmware-Uploads, damit die WiFi-Hardware funktionierte. Eine wachsende Zahl von kabelgebundenen Netzwerkadaptern erfordert jetzt Firmware-Uploads. Einige funktionieren in begrenztem Umfang, sind aber auf zusätzliche Firmware angewiesen, um erweiterte Funktionen zu ermöglichen. Andere weigern sich, ohne Firmware-Upload überhaupt zu funktionieren. Immer mehr Grafikkarten benötigen jetzt auch Firmware-Uploads, um alle nicht grundlegenden Funktionen bereitzustellen. Ein einfacher (S)VGA-kompatibler Framebuffer reicht den meisten Anwendern heutzutage nicht mehr aus; moderne Desktops erwarten 3D-Beschleunigung, und viele aktuelle Hardware bietet diese nicht ohne zusätzliche Firmware. Aktuelle Generationen gängiger Intel-basierter Laptops benötigen ebenfalls Firmware-Uploads, damit Audio funktioniert.

Debians Main-Repository enthält einen kleinen Satz von Free-Firmware-Binärdateien, welche auf den Installations- und Live-Medien enthalten sind. Allerdings gibt es viele weitere Firmware-Binärdateien, die nicht frei sind. Wenn das Projekt rechtlich in der Lage ist, diese Binärdateien weiterzugeben, werden sie paketiert und dem unfreien Teil des Archivs beigefügt. Die Debian-Richtlinien trennen klar zwischen Freier und unfreier Software. Daraus ergibt sich eine Spannung, die auch die Installations- und Live-Medien betrifft. Da non-free offiziell nicht als Teil von Debian angesehen wird, können die offiziellen Medien nichts von non-free enthalten. Dies ist eine bewusste Politik für viele Jahre gewesen. Stattdessen hat das Projekt seit einiger Zeit einen begrenzten parallelen Satz von "inoffiziellen Non-Free"-Images erstellt, die Non-Free-Firmware enthalten. Diese unfreien Images werden mit der gleichen Software erstellt, die auch für die offiziellen Images verwendet werden, und zwar vom gleichen Team. Daraus ergeben sich Probleme:

1. Das Erstellen, Testen und Veröffentlichen von zwei Image-Sets erfordert mehr Aufwand.
2. Vom philosophischen Standpunkt aus möchte das Projekt gar keine unfreien Images anbieten. Deshalb werden hauptsächlich die bevorzugten offiziellen Images beworben. Das kann bei den Nutzern zu Verwirrung führen, weil die unfreien Images nicht so leicht zu finden sind.
3. Die Verwendung unfreier Installationsmedien wird dazu führen, dass mehr Installationen standardmässig unfreie Software verwenden, obwohl diese kein Teil des Debian Projekts ist.
4. Eine Reihe von Benutzern und Entwicklern beschweren sich, dass das Projekt offizielle Images veröffentlicht, die für viele der Benutzer einfach nicht nützlich sind.

Um diese Probleme zu lösen, schlägt McIntyre fünf Optionen vor:

1. Nichts ändern
2. Einstellen der non-free unofficial Images
3. Aufhören, so zu tun, als ob die unfreien Images inoffiziell wären
4. Das Image-Team könnte unfreie Pakete in die offiziellen Images aufnehmen und Firmware-Pakete zu den Eingabelisten für diese Images hinzufügen.
5. Man könnte die unfreien Firmware-Pakete in eine neue Komponente für unfreie Firmware im Archiv ausgliedern und nur eine bestimmte Ausnahme zulassen, um die Aufnahme dieser Pakete in die offiziellen Medien zu ermöglichen. Dann würde nur einen Satz offizieller Medien generiert, der diese unfreien Firmware-Pakete enthält.

Steve McIntyre bevorzugt die letzte Option.

Quelle: https://blog.einval.com/2022/04/19

Herzlich willkommen zu Teil 6 meiner Reihe Nextcloud im Container. Dieser Teil behandelt das Thema Updates. Zum Verständnis empfehle ich, zuerst Teil 1 und Teil 2 zu lesen.

Nun wünsche ich euch viel Spaß beim Lesen und gute Unterhaltung.

Gedanken zum Update

Meine Nextcloud-Instanz läuft in einem Podman-Pod. Das sieht im Terminal wie folgt aus:

$ podman pod ps
POD ID        NAME    STATUS   CREATED       INFRA ID      # OF CONTAINERS
e84bec6108d1  nc_pod  Running  2 months ago  5e52555c5060  3

Dieser Pod besteht aus den folgenden drei Container-Instanzen:

$ podman ps
CONTAINER ID  IMAGE                                  COMMAND               CREATED       STATUS         PORTS                    NAMES
5e52555c5060  k8s.gcr.io/pause:3.2                                         2 months ago  Up 7 days ago  127.0.0.1:40671->80/tcp  e84bec6108d1-infra
c6571aa338ce  docker.io/library/mariadb:10.5.7       mysqld                2 months ago  Up 7 days ago  127.0.0.1:40671->80/tcp  nc_mariadb
21739d36eef1  docker.io/library/nextcloud:23-apache  apache2-foregroun...  2 months ago  Up 7 days ago  127.0.0.1:40671->80/tcp  nextcloud

Diese Container-Instanzen sind zustandslos und ephemeral (engl. für kurzlebig, vergänglich oder flüchtig). Persistent zu speichernde Daten werden außerhalb der Container-Instanzen gespeichert. Diese Eigenschaften erlauben es, Container einfach entfernen und durch neue Instanzen ersetzen zu können.

Um die Nextcloud zu aktualisieren, wird in dieser Umgebung also nicht die Anwendung innerhalb des Containers aktualisiert. Stattdessen werden die Container-Instanzen entfernt und Container-Images mit aktuelleren Versionen der Anwendung und Datenbank instanziiert.

Der Update-Prozess

Die aktuell laufenden Versionen von Nextcloud und MariaDB sind obigen Codeblock zu entnehmen. Diese Images wurden durch die beiden folgenden Zeilen in der Datei {role_path}/defaults/main.yml definiert:

MARIADB_IMAGE: docker.io/library/mariadb:10.5.7
NC_IMAGE: docker.io/library/nextcloud:23-apache

Hier kann man nun die gewünschten Versionen der zu verwendenden Container-Images eintragen. Alternativ kann man die Default-Werte auch durch entsprechende Einträge in {role_path}/vars/main.yml überschreiben. Die Einträge sehen dann bspw. wie folgt aus:

MARIADB_IMAGE: docker.io/library/mariadb:10.5.9
NC_IMAGE: docker.io/library/nextcloud:23.0.3-apache

Nun kann das Playbook mit der Ansible-Rolle aus Teil 2 dieser Reihe erneut ausgeführt werden:

$ ansible-playbook -i hosts deploy_nextcloud.yml --ask-vault-pass                                                 
Vault password:                                                                                                   
                                                                                                                  
PLAY [localhost] **************************************************************************************************
                                                                                                                  
TASK [Gathering Facts] *******************************************************************************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Main folder, needed for updating] *************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for installed/modified apps] ***********************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for local configuration] ***************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for the actual data of Nextcloud] ******************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for the MySQL data files] **************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create the podman-pod(1)] *********************************
changed: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create MariaDB container] *********************************
changed: [localhost]                                                                                               
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Wait for DB to initilize] *********************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create Nextcloud container] *******************************
changed: [localhost]                                                                                               
                                                                                                                  
PLAY RECAP *******************************************************************************************************
localhost                   : ok=10   changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Nun kann man sich auf dem Zielsystem davon überzeugen, dass die neuen Container-Images zur Instanziierung verwendet wurden:

$ podman ps
CONTAINER ID  IMAGE                                      COMMAND               CREATED         STATUS             PORTS                    NAMES
5e52555c5060  k8s.gcr.io/pause:3.2                                             2 months ago    Up 7 days ago      127.0.0.1:40671->80/tcp  e84bec6108d1-infra
248f87e1135b  docker.io/library/mariadb:10.5.9           mysqld                35 seconds ago  Up 36 seconds ago  127.0.0.1:40671->80/tcp  nc_mariadb
59ac1aad168c  docker.io/library/nextcloud:23.0.3-apache  apache2-foregroun...  10 seconds ago  Up 11 seconds ago  127.0.0.1:40671->80/tcp  nextcloud

Fertig. Schon kann Nextcloud in Version 23.0.3 mit einer MariaDB 10.5.9 genutzt werden.

Fazit

Mit diesem Artikel habe ich das letzte noch offene Ziel Nr. 5 „Konfiguration und Test automatischer durch Ansible gesteuerter Updates“ erreicht. Der Update-Prozess folgte dem Container-Paradigma, die Container komplett zu ersetzen und nicht die Anwendung innerhalb der Container zu aktualisieren.

Es handelte sich im dokumentierten Fall um Updates auf ein neues Patch-Release, bei denen das Risiko für Fehler ohnehin sehr gering ist. Ob das Update auch bei Minor- bzw. Major-Releases so gut funktioniert, muss sich noch zeigen. Ich werde diesen Artikel aktualisieren, wenn es Erkenntnisse dazu gibt.

Mit diesem Artikel endet meine Reihe „Nextcloud im Container“. Ich hoffe, ich habe euch damit ein wenig unterhalten und konnte euer Wissen durch die ein oder andere Information erweitern.

Quellen und weiterführende Links

1. Nextcloud im Container – Teil 1: Der Plan
2. Nextcloud im Container – Teil 2: Die Ansible-Rolle
3. Nextcloud im Container — Teil 3: Mit Reverse-Proxy
4. Nextcloud im Container — Teil 4: Hier und da klemmt es
5. Nextcloud im Container – Teil 5: Backup und Restore
6. ansible_role_deploy_nextcloud_with_mariadb_pod auf GitHub
7. Semantic Versioning 2.0.0

SUSE Linux Enterprise 15 ist im Kern bald 4 Jahre alt. Service Packs aktualisieren zwar regelmäßig große Teile des Systems, aber Kunden und Community warteten bereits seit einiger Zeit auf erste Signale, in welche Richtung es für SUSE Linux Enterprise 16 laufen könnte.

Durch das unter dem Motto „Closing the Gap“ in den letzten Jahren vollzogene Zusammenrücken von SUSE Linux Enterprise (SLE) und openSUSE Leap, hat diese Entwicklung nicht nur Auswirkungen auf die zahlenden Kunden von SLE, sondern auch auf die normalen Nutzer von openSUSE, sofern sie nicht auf das rollende Tumbleweed setzen.

Auf der Mailingliste hat sich nun der Produktmanager für SLE, Stefan Behlert, geäußert. Die Planungen sind noch in einem frühen Stadium, aber es zeichnet sich nichts weniger als eine Revolution der Art wie SLE funktionieren wird ab.

With the next generation of Enterprise releases we want to tackle the above. Intending to do radical changes (regarding technology-but also design-wise)we choose „Adaptable Linux Platform“ or short „ALP“ as codename for that next generation. This indicates already that some things will be quite different than a „mere „SLE 15++ would be 😉
[…]
Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of „host OS“, and the and the layer providing and supporting applications, which will be container (and VM) based.

Wer die aktuelle Linux-Entwicklung nicht so engmaschig verfolgt, wird daraus natürlich erst mal nicht wirklich schlau. Die Ankündigungen sind zugegebenermaßen auch etwas wolkig. Man sollte zum Verständnis sich anschauen, was Richard Brown die letzten Jahre bei SUSE so getrieben hat. Er ist ja nicht nur in der openSUSE Community sehr aktiv, sondern auch seit vielen Engineer bei SUSE. Das Projekt MicroOS war bisher nur Insidern bekannt und immer eher eine Technologievorschau als ein für die breitere Allgemeinheit benutzbarer Zweig von openSUSE. Im Kern ist MicroOS aber genau das, was hier angekündigt wird. Ein kleines „Host OS“ mit vielen Vorzügen gegenüber einer klassischen Distribution wie z. B. eine unveränderbar eingehängte Systempartition oder Updates mit Rollback-Funktion.

Wenn ich jetzt raten müsste, glaube ich, dass SUSE diesen Weg nun konsequent weiter beschreiten wird. Damit sind sie auch nicht alleine, da Red Hat mit Fedora Silverblue einen ähnlich konzipierten Testballon gestartet hat. Vermutlich wird es ein solches Kernbetriebssystem geben, das je nach Einsatzszenario unterschiedlich angepasst wird. Am Desktop dürfte die Entwicklung weiter in Richtung Flatpaks für die Installation von Anwendungen gehen. Im Server-Segment dürfte stattdessen der konsequente Einsatz von Container-Technologien vorangetrieben werden.

Ich persönlich kann solchen Veränderungen bekanntermaßen viel abgewinnen und stehe dem sehr offen gegenüber. Die Ankündigung hatte aber nun auch einen Nachteil für mich. Ich überlege seit Monaten, die letzten in meiner Obhut verbliebenen Kubuntu-Systeme auf openSUSE Leap zu migrieren. Das erscheint mir nun aber nicht mehr so klug, weil es eine Migration in eine unbekannte Zukunft ist. Vermutlich werde ich die Systeme deshalb doch nochmal auf Kubuntu 22.04 hochziehen und dann 2024 nochmal den Stand evaluieren. Zumal eher unwahrscheinlich ist, dass alle Geräte das Jahr 2024 technisch noch erreichen werden.

Der Artikel Zukunftspläne bei SUSE erschien zuerst auf [Mer]Curius

Mozilla hat mit Firefox 99.0.1 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht.

Download Mozilla Firefox 99.0.1

Mit dem Update auf Firefox 99.0.1 behebt Mozilla ein Problem, welches für Windows-Nutzer mit neueren Intel-Treibern verursachen konnte, dass die Wiedergabe von Videos nicht mehr durch die Hardware beschleunigt worden ist.

Beim Drag and Drop einer Datei aus dem Download-Panel wurde unabhängig vom gewählten Element immer das erste Element der Liste genutzt.

Ein Darstellungsproblem mit bengalischen Schriftzeichen auf macOS wurde korrigiert.

Nutzer von Zoom können jetzt auch den Galerie-Modus nutzen, wenn die zoom.us-Domain und keine Domain der Art subdomain.zoom.us genutzt wird.

Dazu kamen noch mehrere Korrekturen der JavaScript-Engine für WebAssembly-Code sowie für den Bild-im-Bild-Modus von Videos.

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

Di, 12. April 2022, Frank Slotta

S.u.S.E. 4.4.1 aus dem Jahr 1997 feiert seinen 25. Geburtstag und lässt sich immer noch in einer virtuellen Maschine wie zum Beispiel KVM/QEMU installieren, auf YouTube findet sogar sich ein Video dazu. Die Installation war komplex (mehrere Boot-Vorgänge notwendig), das Handbuch beschrieb jeweils den Weg von DOS, Windows 95, OS/2 und Linux/Unix hin zur Linux-Installation.

Softwareumfang, Handbuch und Karton fehlen

Die beiliegenden CD-ROM-Medien konnten nicht direkt ein Live-Linux starten, das Booten erfolgte über die Diskette, um dann Zugriff auf die erste CD zu erhalten. Über eine CD mit Live-Filesystem konnte S.u.S.E. Linux testweise in einem DOS-Verzeichnis installiert werden, wobei die Programme von der CD nachgeladen wurden. Im Test wurde zuerst FreeDOS in QEMU installiert, anschliessend gelang die Linux Installation. Fehler beim Vorgehen wurden schon mal mit «Glückwunsch! Keine freie Partition gefunden - Abbruch» quittiert.

Für Nostalgiker: Welches CD-ROM Laufwerk besitzen Sie?

Dank der Kompatibilität zu alten Techniken wie PS/2 (Maus, Tastatur) und VGA liess sich auch die grafische Umgebung konfigurieren und nutzen. Diese Konfiguration war ebenfalls nicht trivial, aber das über 500 Seiten lange Handbuch half auch hier. Im Karton befanden sich drei CD-ROMs sowie eine Boot-Diskette. Die Installationsvoraussetzungen betrugen 8 MB RAM für textbasiertes Arbeiten (Terminal) sowie 12 MB für die grafische Oberfläche X-Windows, Kernel 2.0.28 wurde ausgeliefert. Auszüge aus dem Handbuch: «Die NE2000-kompatiblen Karten machen immer wieder Ärger!» und «Mindestanforderungen sollten verdoppelt werden».

Das X Window System 1997

Die grafische Oberfläche startete nicht automatisch, es musste startx im Terminal eingegeben werden, um das X Window System aufzurufen. Die grafische Oberfläche verwendete bereits drei Maustasten, wer nur zwei hatte, konnte sich durch das gleichzeitige Drücken der ersten beiden behelfen. Linux unterstützte bereits zum damaligen Zeitpunkt eine ganze Reihe von Hardware, wie man zum Beispiel aus dem Scrollbalken für alle unterstützten Grafikkarten erahnen kann.

Grafikkarten Auswahl

YaST half bei der Konfiguration des Systems und machte Linux für den Einsteiger zugänglich. Für viele Komponenten gab es einen Dialog, der bei der Einrichtung half.

YaST zur Systemkonfiguration

Benutzereinrichtung mit YaST

Fazit: die grafischen Oberflächen haben sich bis heute nicht grundlegend verändert und auch die Installation klappt noch dank Kompatibilität zu alten Technologien wie dem Legacy BIOS. Der Editor vim und der Midnight Commander mc als Dateimanager waren bereits vorinstalliert. S.u.S.E. 4.4.1 stellte 1997 einen einfachen Einstieg in Linux dar und die Distribution war für viele der Startpunkt in eine auch 25 Jahre später noch faszinierende Betriebssystemwelt.

SUSE Linux bei Wikipedia: https://en.wikipedia.org/wiki/SUSE_Linux
FreeDOS https://freedos.org/
Suse 4.4.1 Grafische Oberfläche: https://invidious.sp-codes.de/watch?v=DFLVVRACwFo

Eigentlich hatte ich mich schon auf Xubuntu 22.04 „Jammy Jellyfish“ gefreut. Da aber in dieser Version Firefox und Thunderbird als snap ausgeliefert werden, hatte ich mir Gedanken, um eine Alternative, gemacht. Debian verwende ich schon seit vielen Jahren auf meinem Notebook und meinem Server.
Also habe ich mir Debian 11 „Bullseye“ mit Xfce auch auf meinem Desktop PC installiert.

Ich hatte mir vorher Sorgen gemacht, ob mein Dual Monitor Setup mit dem nouveau-Treiber funktioniert. Der Treiber wurde während der Installation von Debian automatisch installiert. Mein Dual Monitor Setup läuft wie es soll.

Der größte Vorteil der Debian-Installation war für mich aber, dass ich die Konfigurationsdateien .firefox und .thunderbird in meinem Homeverzeichnis weiter verwenden konnte.

Für eine bequeme Nutzung des PC’s habe ich mir noch SSH eingerichtet. Dafür habe ich mir die Pakete gvfs-backends, gvfs und sshfs nachinstalliert.

Ich bin mit Debian auf meinem Dektop PC sehr zufrieden. Ich musste keine Kompromisse im Gegensatz zur Xubuntu-Installation eingehen. Die Funktion Zusätzliche Treiber in Xubuntu vermisse ich nicht.

Mo, 11. April 2022, Ralf Hersel

EndeavourOS ist eine rollende Linux-Distribution, die auf Arch Linux basiert. Das Projekt zielt darauf ab, ein geistiger Nachfolger von Antergos zu sein - es bietet eine einfach einzurichtende und vorkonfigurierte Desktop-Umgebung auf der Basis von Arch. EndeavourOS bietet sowohl Offline- als auch Online-Installationsoptionen. Der Offline-Installer, Calamares, verwendet standardmässig den Xfce-Desktop. Das Online-Installationsprogramm kann optionale Softwarekomponenten installieren, darunter die meisten gängigen Desktop-Umgebungen.

EndeavourOS-Gründer Bryan Poerwo kündigte am Freitag die Veröffentlichung von EndeavourOS Apollo an, dem neuesten ISO-Snapshot dieser Arch Linux-basierten GNU/Linux-Distribution für die breite Masse.

Zu den wichtigsten Funktionen von EndeavourOS Apollo gehören der neue 5.17-Kernel und der Mesa 22 Grafik-Stack. Das ist die beste Kombination, die man derzeit bekommen kann, wenn die modernste Hardwareunterstützung und Spieleleistung gewünscht wird.

Eine weitere neue Funktion in dieser Version ist der Fenstermanager Worm, der von einem Mitglied der EndeavourOS-Community entwickelt wurde. Worm wurde in Nim geschrieben und ist ein leichtgewichtiger Fenstermanager für X11, der Floating- und Tiling-Modi unterstützt.

Darüber hinaus wird bei neuen EndeavourOS Installationen nun die Firewall FirewallD aktiviert, ein neues grafisches Dienstprogramm, mit dem Benutzer die benötigten Anwendungen auswählen und installieren können, sowie ein Kommandozeilen-Tool, das Benutzern von NVIDIA-Grafikprozessoren bei der Installation der neuesten NVIDIA-Grafiktreiber hilft, einschliesslich der Legacy-Treiber der 470er- und 390er-Serie.

EndeavourOS Apollo bietet ein deutlich verbessertes Installationserlebnis, mit dem man sowohl Xfce- als auch i3-Grafikumgebungen installieren kann. Zudem fügt der neue Login-Manager eine Info-Schaltfläche für angepasste Installationen hinzu und komprimiert Dateien bei Btrfs-Installationen. Auch Calamares, der grafische Installer von EndeavourOS, hat verschiedene Verbesserungen erhalten.

Quelle: https://endeavouros.com/news/the-apollo-release-has-landed/