staging.inyokaproject.org

Schwäbisch Hall ist immer so ein Beispiel, das kommt, wenn von Erfolgen von Linux in der Verwaltung die Rede ist. c’t / Heise hat nun ein Interview mit dem IT-Leiter geführt. Fazit: Viel läuft gut, manches aber auch nicht.

Ich wurde auf dieses Interview aufmerksam gemacht, weil Linux und die öffentliche Verwaltung bekanntermaßen ein Thema ist, das mich sehr beschäftigt (z. B. hier, hier und hier). Schwäbisch Hall gehört da immer zu den Vorzeigebeispielen. Das Interview ist lesenswert (muss ich ja bei meiner häufigen Kritik an Heise mal so schreiben) und zeigt Stärken und Schwächen auf:

Die Migration ist grundsätzlich ein Erfolg, man ist schließlich bei Linux geblieben. Das ist als Punkt einfach festzuhalten. Ebenfalls teile ich die Erfahrung, dass die Zufriedenheit der Mitarbeiter mit der IT oft vom erlebbaren Support der IT-Abteilung abhängt und nicht von der Software. Allerdings gibt es eben auch viele handfeste Probleme: Die Produktivität ist tendenziell geringer, es gibt problematische Baustellen von Sicherheit über Office bis PDF-Bearbeitung und bei vielen Fachanwendungen ist Windows per RDP unersetzbar. Von einer völligen Abkehr von Windows kann man also nicht sprechen. Oft ist ein Problem fehlendes Verständnis bei Open Source Entwicklern im Bereich Linux-Desktop für Business-Anforderungen. Ein bundeseinheitlicher Behördendesktop wäre wohl der Weg zur Lösung, aber die Erfahrungen lassen Waack nicht besonders optimistisch auf den neuen Anlauf für einen Bundesclient blicken.

Stand heute, am 02. Mai 2022 hat der Artikel über 2000 Kommentare. Da gibt es natürlich die ganze Bandbreite an Meinungen. Erstaunlich finde ich nur wieder jene nicht gerade wenigen Kommentatoren, die Herrn Waack darüber belehren, was er alles nicht verstanden hat (z. B. hier) oder sich in Ausflüchte (z. B. hier) ergehen. Frei nach dem Motto: Es darf nicht sein, was nicht sein darf. Realitätsverweigerung für Fortgeschrittene. Allerdings ist das wenig überraschend, denn was soll man schon erwarten, wenn diese Menschen seit Jahren die Qualitätsberichterstattung im IT-Bereich lesen und ihnen dort quasi täglich und frei von Selbstzweifeln der Siegeszug von Linux erklärt wird.

Ich werde mich gerne an dieses Interview erinnern, wenn Schwäbisch Hall wieder als strahlendes Vorbild genannt wird. Freuen wir uns auf Schleswig-Holstein. Angeblich soll es da 2025 soweit sein, wobei „soweit wie möglich“ natürlich ein dehnbarer Begriff ist. Ich glaube es jedenfalls nicht und schon gar nicht bis 2025.

Mo, 2. Mai 2022, Lioh Möller

GNOME Flashback ähnelt im äusseren Erscheinungsbild dem eines GNOME 2 Desktops. Bis vor einiger Zeit wurde diese Variante als GNOME Fallback Mode bezeichnet, da sie zum Einsatz kam, sofern die Hardware nicht ausreichte, um einen vollständigen GNOME Desktop darzustellen.

Die Installation unter Ubuntu 22.04 ist denkbar einfach und lässt sich mithilfe des folgenden Befehls ausführen:

sudo apt install gnome-session-flashback

Daraufhin ist eine Auswahl der Sitzung am GDM Anmeldebildschirm möglich.

Als Windowmanager kommt Metacity zum Einsatz. Im Gegensatz zu GNOME 2 oder dem MATE Desktop, ist der Funktionsumfang bei GNOME Flashback eingeschränkt.

Allerdings lassen sich mithilfe eines Klicks auf das Panel mit gedrückter Alt-Taste weitere Elemente hinzufügen, oder vorhandene verschieben.

Die zu verwendende GTK Theme lässt sich mit dem GNOME Tweaks Hilfsprogramm auf einfache Weise umstellen. Installiert wird dieses mit folgendem Befehl:

sudo apt install gnome-tweaks

Aufrufen lässt es sich daraufhin beispielsweise durch die Eingabe von gnome-tweaks in der Kommandozeile.

Um das dunkle GTK-Theme durchgängig zu nutzen, kann folgender Befehl ausgeführt werden:

gsettings set org.gnome.desktop.interface color-scheme 'prefer-dark'

Alternativ dazu kann 'prefer-light' oder 'default' gewählt werden.

Weiter nützliche Tipps zur Optimierung finden sich im Wiki des Arch Linux Projektes. Unter anderem wird dort beschrieben, wie die Animationsgeschwindigkeit zur Einblendung von Panel-Elementen angepasst werden kann.

GNOME Flashback eignet sich damit nicht nur für Nostalgiker, sondern ist beispielsweise bei einem Remotezugriff oder bei eingeschränkten Hardwareressourcen eine gute Wahl.

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.

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)

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: eingesehen werden. Eine entsprechende Ausgabe könnte dann wie folgt aussehen: Wird ein RAID neu aufgebaut bzw. synchronisiert sieht die Ausgabe etwas ausführlicher aus: Die Synchronisation kann unter anderem über die Variable speed_limit_max gesteuert werden.

Quelle

Wenn Node.js unter der aktuellen Ubuntu-LTS Version 22.04 installiert werden soll, so kann hierfür apt benutzt werden: 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: zu installieren.

Quelle

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.

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.

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/

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,.

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.