staging.inyokaproject.org

Die MZLA Technologies Corporation hat mit Thunderbird 102.3.2 ein Update außer der Reihe für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 102.3.2

Mit dem Update auf Thunderbird 102.3.2 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit eine Reihe von Problemen, welche sich in den Release Notes (engl.) nachlesen lassen.

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

Der Standard der Standards: Gestern wurde der Smart-Home-Standard Matter in Version 1.0 von der Connectivity Standards Alliance (CSA) veröffentlicht. Er soll Licht ins Dunkle bringen und das Standard-Chaos unter den Smart-Home-Geräten auflösen. Reflexartig werden viele meiner Leser jetzt die Zahl 927 in die Tastatur tippen, aber ich werde mich erstmal überraschen lassen, was sich ergibt. Vielleicht ist es nicht "yet another standard", sondern tatsächlich eine Verbesserung. Zudem haben sich viele große Smart-Home-Anbieter in der Allianz zusammengeschlossen, um diese Harmonisierung durchzuführen – bevor es die Regulatoren tun, wie wir gerade erst mit USB-C gesehen haben.

Ich werde mich in den nächsten Wochen genauer mit Matter beschäftigen und schauen, was sich dazu erforschen lässt. Auch die Security-Aspekte werden dabei relevant werden. Was ich aber ausgesprochen schade finde, ist, dass die Spezifikation (also der Kern des Standards), gar nicht öffentlich ist, wie sich in der Wikipedia lesen lässt:

Version 1.0 of the specification was published 30 September 2022. The Matter specification is provided at no charge upon request after providing full name, company name, email address and consenting to their privacy policy, but cannot be redistributed without permission from CSA.

Das steht natürlich im Kontrast zu anderen Standards wie QUIC, die einfach online und ohne Registrierung vom RFC Editor abgefragt werden können. Ich werde mir wohl für meine Arbeit einen Zugang diesbezüglich holen, kann dann aber im Blog höchstwahrscheinlich nicht mehr auf die Details aus der Spezifikation eingehen. Im Grunde ist es dann ähnlich wie mit Standards von z. B. der IEEE, aber die Chance der besseren Zugänglichkeit des Standards wurde offenbar nicht genutzt. Deswegen ein Blogartikel im Voraus mit meinen Hypothesen und Erwartungen.

Was ich bereits gut finde

Es gibt viele Standards, die sich in den vergangenen Jahren im IoT-Umfeld entwickelt haben. Das hat für eigene Anwendungen natürlich einen Einfluss auf den Layer 7 (Application), also die konkrete Implementierung von Anwendungen: wenn sich der Lichtschalter anders als der Heizkörperthermostat verhält (z. B. das eine System bietet nur HTTP REST auf einer Cloud an, das andere erwartet lokales MQTT), dann bedeutet das einen Mehraufwand, der verhindert werden könnte, wenn man sich auf ein Interface einigt. Aber bevor wir über Layer 7 überhaupt nachdenken können, muss Layer 3 (Network) geklärt sein. In beiden Fällen gibt Matter Vorgaben, wie in Abbildung 1 dargestellt: Layer 7 wird durch den Standard selber beschrieben und als Layer 3 wird IPv6 erwartet. Das ist spannend, da sich hier – sofern technisch dem Zugriff keine Schranken gesetzt werden – damit eine Integration in Heim- und Unternehmensnetze auf klassischen Standards möglich ist. Als Layer 1 bzw. 2 können Ethernet, Wi-Fi, Thread (IEEE 802.15.4), IPv6 for Bluetooth Low Energy, u. v. m. dienen.

Der Einsatz von IPv6 muss allerdings auch technisch implementiert werden: so müssen nicht nur Router und Firewall IPv6 generell unterstützen, sondern die (hoffentlich dedizierten) IPv6-Netze müssen auch bereitgestellt werden. Ob und in welchem Umfang die lokalen Unique Local Addresses (ULAs) nach RFC 1884 eingesetzt werden können, weiß ich zum aktuellen Zeitpunkt noch nicht. Begrüßenswert ist es in jedem Fall.

Warum rede ich überhaupt von ULA? Da IPv6 nativ kein NAT kennt, dürfte man doch damit gar nicht ins Internet kommen? Ja genau, das muss man bei Matter auch nicht, da der Standard auch lokal und ohne Cloud laufen kann. Somit müssen Schaltbefehle nicht umständlich über das Internet geroutet werden, sondern können den Weg direkt im Heim- oder Unternehmensnetz laufen. Auch das ist eine gute Sache, da so eine Zugriffskontrolle auf Vermittlungsebene in der Organisation durchgesetzt werden kann und man nicht vor verschlüsselten REST-Nachrichten steht.

Apropos Verschlüsselung, an die wurde auch gedacht. So sollen die ausgetauschten Nachrichten signiert und verschlüsselt werden können, ein Aspekt, der vielen Smart-Home-Geräten bisher fehlt.

Matter stellt weiterhin nicht nur eine Spezifikation, sondern auch ein SDK bereit. Dieses ist tatsächlich Open Source und unter der Apache-2.0-Lizenz auf GitHub verfügbar.

Wo ich noch genauer nachhaken werde

Grundsätzlich stellt sich die Frage der Zugänglichkeit zum System: es bleibt zu hoffen, dass die Geräte nicht nur mit fremden Smart-Home-Anwendungen, sondern auch mit den eigenen Smart-Home-Anwendungen kommunizieren können. Wenn ich mir ein Script schreiben will, das Steckdosen schaltet oder Heizthermostate einstellt, brauche ich einen standardisierten, nicht-diskriminierenden Zugriff. Konkret meine ich damit, dass das System – solange ich mich standardkonform verhalte – nicht danach unterscheiden (= diskriminieren) soll, ob ich ein anderes zertifiziertes Smart-Home-Device bzw. eine solche Anwendung bin, oder nicht. Wenn sich ein Ökosystem entwickelt, das zwar Institutionen freien Zugriff gewährt, aber interessierte Einzelpersonen kategorisch ausschließt, ist in der Frage dem fortgeschrittenen Smart-Home-Entwickler bzw. -Anwender wenig geholfen.

Auch der Punkt mit dem Distributed Compliance Ledger (vgl. diesen Artikel von Espressif, den ESP32-Machern, dazu) muss kritisch hinterfragt werden: die Funktionsweise liest sich wie die einer klassischen PKI, vor allem, da die CSA offenbar sowieso Top-Down organisiert ist. Vielen wird sowieso beim Begriff permissioned blockchain der Kamm hochgehen, da eine Blockchain-Datenbank mit Zugriffsverwaltung dem Urgedanken des P2P-Netzwerkes mit der gemeinsamen Konsensfindung zuwiderläuft. Bisher konnte ich diesbezüglich nur ein GitHub-Projekt der ZigBee-Alliance finden, bei dem als Grundlage die Cosmos-Blockchain läuft.

Von der Kritik deutlich zu trennen ist aber der lobenswerte Umstand, dass Firmware-Downloads überhaupt integritätsgeschützt und authentifiziert werden. Sollte es aber tatsächlich so sein, dass es sich beim DCL um eine PKI handelt, über die eine Blockchain gestülpt wurde, kann man sich die Blockchain mitunter gleich sparen.

Abschließend ist auch Kompatibilität ein Punkt: so sollen einige bereits existierende Smart-Home-Geräte zukünftig Matter-Fähigkeiten über ein Firmware-Update erhalten können. Mit Matter 2.0 stellt sich aber auch früher oder später die Frage, ob Matter sich als auf- und abwärtskompatibel erweisen wird: Können bestehende Matter-1.0-Geräte geupdated werden und wie gehen 2.0er-Geräte mit 1.0-Geräten um? Müssen diese mitunter neu gekauft werden?

Wofür ich einen Smart-Home-Standard brauche

Hier habe ich aktuell ein Projekt, das ich bei Gelegenheit implementieren möchte: so soll sich mein Heizthermostat an meinem Kalender orientieren. Wenn ich mir in meinem CalDAV-unterstützenden Kalender einen Außer-Haus-Termin setze, soll die Temperatur abgesenkt werden. Hierzu brauche ich ein Script auf einem Server und ein Heizthermostat. Dieses Heizthermostat selber soll nun aber nicht in meinen Kalender schauen können (Warum auch? Ich habe mehrere Kalender, die in Kombination betrachtet werden müssen.), sondern durch mein Script lokal angesteuert werden. Dieses Script arbeitet dann auf einer Workstation oder einem Raspberry Pi.

Somit managed das Script dynamisch die Heiztemperatur (Input: CalDAV-Kalender) und soll das den Aktoren, also den Thermostaten, über einen Standard mitteilen können.

Ich bin gespannt, ob Matter auch für so einen Fall gebaut ist oder ob der Schwerpunkt in Smart-Home-Zentralen größerer und kleinerer Hersteller liegt.

Mozilla hat mit Firefox 105.0.2 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 105.0.2

Mit dem Update auf Firefox 105.0.2 behebt Mozilla ein potentielles Hängenbleiben beim Laden mancher Websites, wenn Firefox im sogenannten Fehlerbehebungsmodus ausgeführt wird oder die versteckte Option gfx.e10s.font-list.shared auf den Nicht-Standardwert false gesetzt ist und bestimmte von der Website genutzte Schriften installiert sind.

WebExtension-Seitenleisten konnten in privaten Fenstern nicht mehr auf Grafik-Ressourcen von installierten Drittanbieter-Themes zugreifen.

Behoben wurden auch Webkompatibilitätsprobleme. So gab es Probleme mit der CSS-Eigenschaft appearance bei Nummernfeldern. Und in Sprachen, in denen von rechts nach links geschrieben wird, konnte sich der Scrollbalken bei select-Feldern auf der falschen Seite befinden.

Auf Linux-Systemen mit bestimmten Themes konnte es zu Kontrastproblemen in der Menüleiste sowie in select-Feldern kommen.

Firefox auf macOS unterstützt seit Version 100 die Wiedergabe von HDR-Videos. Firefox 105 ergänzt HDR-Telemetrie, welche ausschlaggebend für Mozillas künftige Planungen bezüglich HDR-Unterstützung auf weiteren Plattformen ist.

Darüber hinaus gab es diverse vorbereitende Änderungen für den sogenannten Firefox Major Release 2022 (Firefox 106).

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

Di, 4. Oktober 2022, Ralf Hersel

DietPi ist eine leichtgewichtige, Debian basierte Linux-Distribution für Einplatinencomputer und Serversysteme, welche auch die optionale Desktopumgebungen anbietet. Sie wird als minimales System bereitgestellt, erlaubt jedoch die Installation kompletter und nutzungsfertiger Softwarepakete mittels Konsolen-basierter Shell Dialoge und Skripte.

Das Projektteam hat die neue Version DietPi v8.9 am 24. September 2022 freigegeben.

Die Highlights dieser Version sind:

• HAProxy, phpBB, NoMachine: Update auf die Installation der neuesten Versionen
• Bugfixes für Amiberry und ownCloud
• Die raspberrypi-sys-mods Packages wurden minimiert, dadurch werden unnötige Installations-/Updateschritte auf dem Raspberry Pi vermieden
• Die Ethernet LEDs auf dem NanoPi R5S wurde aktiviert
• Bugfixes für Dietpi-Drive_Manager, Dietpi-Software, Dietpi-Imager und Dietpi-Installer

DietPi ist für mehr als 50 verschiedene Plattformen verfügbar. Die kompletten Versionshinweise findet ihr unter: https://dietpi.com/docs/releases/v8_9/

Quellen:

• https://dietpi.com/
• https://github.com/MichaIng/DietPi

Mo, 3. Oktober 2022, Fabian Schaar

Hinweis: Das ist ein Meinungsartikel.

Die Auswahl einer GNU/Linux-Distribution ist von vielen Faktoren abhängig - das ist wohl so ziemlich allen Teilen der Leserschaft hier klar. Manchmal scheinen die Unterschiede nur marginal, manchmal sind sie gravierender. Eine Entscheidung, um die offensichtlich so einige nicht herum kommen, ist die zwischen einem statischen oder rollenden Distributionsmodell.

Welche Distro rollt am angenehmsten?

Mit Folge 16 des GLN-Podcasts findet sich einer der vielen interessanten Beiträge zu diesem Thema auf GNU/Linux.ch. Nichtsdestotrotz möchte ich in diesem Text etwas genauer auf die verschiedenen Detailfragen rollender Distros eingehen: Einem subjektiven Vergleich unterziehe ich hier Arch Linux, Void Linux, openSUSE Tumbleweed, Debian Testing und Sid.

Arch Linux - Urvater der rollenden Distributionen?

Wenn es in einer Diskussion um Rolling Releases geht, ist Arch meist der erste Name, der fällt - und das nicht zu unrecht. Arch ist und bleibt extrem aktuell, selbsternannt leichtgewichtig und wirklich gut dokumentiert. Damit bietet die Distribution entscheidende Vorteile, die einem rollenden Veröffentlichungszyklus sehr entgegenkommen.

Die Installation eines Arch-Systems gilt als eine der unkomfortabelsten, wenn man grafische Installationsprogramme wie Calamares oder Ubiquity gewohnt ist. Dennoch halte ich die Installation für einigermassen sinnvoll: Ist es nicht gerade bei rollenden Distros wichtig, sein System zu kennen, zumindest, wenn es um wichtige Aspekte geht?

Vielleicht muss man nicht gleich alles selbst kompilieren, und doch sollte man zumindest einen Überblick über die installierten Pakete haben: Wie soll ich meine kaputte Rolling-Distro reparieren, wenn ich nichteinmal weiß, an welchem Paket es denn nun gelegen hat, dass sich das ganze nicht so benutzen lässt, wie ich das eigentlich möchte.

Distributionen, die auf Arch aufsetzen und einige, angeblich nutzerfreundliche Änderungen vornehmen, sind nach diesem Blickwinkel das genaue Gegenteil: EndeavourOS und Manjaro erfreuen sich höchster Beliebtheit, installieren aber teils Pakete, die bei Leibe nicht 100% der Nutzer/-innen brauchen können.

Wer schon einmal versucht hat, Pipewire unter EndeavourOS durch PulseAudio zu ersetzen, kann mich in diesem Punkt eventuell etwas besser nachvollziehen. Wer um die Ideale freier Software weiss und sich dann die Mengen an vorinstallierter, teilweise proprietärer Software in einer vollständigen Manjaro-Installation anschaut, dem können sich leicht die Zehennägel hochrollen.

Dementsprechend bleibt Arch nicht ohne Grund das unangefochtene Schwergewicht in der Distributionsfamilie, die von der Mutter-Distribution ausgeht.

Ein weiterer Aspekt, den ich an Arch nicht wirklich leiden kann, ist der Paketmanager Pacman -- und schon höre ich die ersten Arch Nutzer/-innen schreien. Ja, Pacman ist verdammt schnell, ja, das verwendete Paketformat mag wesentlich verständlicher sein als deb und RPM zusammen, dennoch: Pacman ist und bleibt verdammt kryptisch, wenn man dpkg- oder RPM-basierte Paketverwaltungen kennt.

Was wäre bitte falsch an 'pacman update' statt 'pacman -Syu'? Warum muss ich erst das halbe Alphabet in die Kommandozeile hämmern, um an die Funktionalität eines 'apt autoremove && apt autoclean' heranzukommen?

Was spart am Ende mehr Zeit: Eine kryptische Paketverwaltung, die ich mir vor der ersten Nutzung ersteinmal mehrere Stunden aneignen muss, nur weil die Pacman-Entwickler/-innen anscheinend auf Kommando-Neologismen stehen oder eine leicht zu erlernende Paketverwaltung, die pro Kommando vielleicht fünf Sekunden länger braucht?

Erschwerend kommt noch hinzu, dass Arch nicht wirklich für GNU/Linux-Anfänger geeignet ist: So lange die Einsteigerdistros in der Debian-Familie angesiedelt sind, vielleicht in Einzelfällen auch in der RPM-Welt vertreten sein mögen, werden sich Einsteiger zunächst mit apt, zypper oder dnf vertraut machen - Pacman mag noch so technisch weiterentwickelt sein, schlussendlich könnte man an der eigenen Kryptifizierung scheitern.

Ich möchte Arch hier keinesfalls schlecht reden: Eine Arch-Installation nach klassischer Vorgehensweise halte ich für sehr lehrreich, da man früher oder später auf Paketsuche gehen muss, um einen vollständigen Desktop zu erhalten -- dahingehend kann man eigentlich nur dazulernen.

Was mich allerdings stört, ist eine hohe Abhängigkeit, die sich auch bei trivialeren Paketen offenbart: Eine hohe Abhängigkeit vom AUR. Und schon habe ich wieder viele, viele Leser/-innen gegen mich aufgebracht:

Die einen halten das AUR für die Krönung aller Third-Party-Repos, andere für einen Sumpf aus teilweise unsicheren Paketen. Ich verweise hier mal auf einen Pro-Linux Artikel mit dem bezeichnenden Titel "Malware im Arch-User-Repositorium AUR gefunden".

Das mag ein Einzelfall gewesen sein; und doch zeigt er, dass alle Nutzer/-innen des AUR oftmals auf sich allein gestellt sind. Wer die PKGBuild-Skripte nicht liesst, ist potenziell selbst schuld an dem Schadcode, der auf das eigene System gelangen könnte -- ich wollte es nur mal gesagt haben.

Das AUR ist eben nicht das Allheilmittel, sondern wie so vieles ein zweischneidiges Schwert, auf der einen Seite unfassbar nützlich, auf der anderen potenziell gefährlich.

Arch bleibt eine tolle Distro; vielleicht muss man aber überdurchschnittlich viel wissen, was man tut, wenn man sich darauf einlässt.

Void Linux: Alles anders??

Eine weitere, nicht derartig bekannte, allerdings wirklich interessante Distribution ist Void Linux. Diese wurde von einem ehemaligen NetBSD-Maintainer ins Leben gerufen und war ursprünglich nur als Testumgebung für den neu entwickelten XBPS-Paketmanager konzipiert, ist heute aber eine ernstzunehmende rollende Distro, die Stabilität über Aktualität stellt.

Der bereits erwähnte Paketmanager XBPS hat es in sich: Der ist unfassbar schnell, möglicherweise sogar schneller als Pacman. Grundlegend gibt es aber nicht den einen Paketmanager, stattdessen ist XBPS eher eine Sammlung aus verschiedenen Einzelkomponenten, die zusammen eine runde Paketverwaltung ermöglichen:

Grundlegend wichtig sind beispielsweise die Komponenten xbps-install, xbps-remove und xbps-query, die durch dedizierte man-Pages und help-Ausgaben eine angenehmere Lernkurve ermöglichen. Doch nicht nur in diesem Aspekt ist Void anders:

Statt auf systemd setzt Void auf das flinke runit; diejenigen, die sich mit systemd wohlfühlen, müssen sich dahingehend natürlich umgewöhnen.

Was die Installation angeht, ähnelt der void-installer einem klassischen Slackware-Setup und erinnert ausserdem grob an die Installationroutinen von BSD-Systemen. Der Installer mag zwar einfacher sein als eine Arch Linux-Installation ohne archinstall, perfekt ist das System am Schluss aber auch nicht.

Meiner Erfahrung nach, merkt man Void an, dass die Distribution den Nutzer auffordert, die Dokumentation zu lesen -- und diese ist tatsächlich sehr gelungen und lesenswert. Trotzdem sind es die kleinen Details, die Void als Hauptsystem immer etwas umständlich machen:

Wie gesagt, dass sind nur Kleinigkeiten und trotzdem nervt es, wenn sich die X11-Tastaturbelegung nur über eine Konfigurationsdatei ändern lässt, die in der Dokumentation nichteinmal erwähnt wird:

Hier mal eine kleine Hilfestellung; um beispielsweise eine de_nodeadkeys-Belegung einzustellen, muss die Datei /etc/X11/xorg.conf.d/20-keyboard.conf erstellt, und wie folgt angepasst werden:

Section "InputClass"
        Identifier "keyboard"
        MatchIsKeyboard "yes"
        Option "XkbLayout" "de"
        Option "XkbVariant" "nodeadkeys"
EndSection

Grundsätzlich ist das natürlich kein Problem, allerdings halte ich so etwas für essentiell wichtig. Essentielle Informationen möchte ich eigentlich nicht auf Reddit sondern in einer offiziellen Dokumentation finden. Sollte ich den Abschnitt übersehen haben, freue ich mich, korrigiert zu werden.

Eine weite nervige Angewohnheit von Void ist der Standard-Display-Manager LXDM, der mit der Xfce-Ausgabe mitinstalliert wird: Leider verhindert dieser das Auswählen eines einheitlichen Mauszeiger-Themes - ebenfalls eine Kleinigkeit, trotzdem nervig.

Möchte man dann auf den üblicheren LightDM umsteigen, muss man erst den LXDM-Service aus /var/service löschen, um dann den symbolischen Link für LightDM dort anzulegen. Schon ein Wechsel auf LightDM würde die Nutzerfreundlichkeit dahingehend erhöhen.

'Dann nimm doch die minimale Basis-ISO!', höre ich die ersten anraten; das habe ich auch probiert, nur ist diese leider wirklich, wirklich rudimentär. Wer eine Basis-Installation von Arch oder Debian kennt, weiss, was eine standardmässige minimale Installation ist - wer eine Basisinstallation von Void ausprobiert, wird seinen Meister finden:

Es fängt bei meiner Hardware leider schon bei der Installation an: Die Einrichtung der WLAN-Verbindung über den Installer funktioniert nicht. Halb so wild, mag man denken, dann macht man das halt über die Kommandozeile.

Tja, schön wär's: Nutzerfreundliche Kommandozeilen-Tools wie etwa iwd, was die Netzwerkeinrichtung über die Konsole wirklich leicht macht, gibt es bei Basis-Void nicht; hier gibt es nur wpa_supplicant und wpa_passphrase. Naja, wenigstens etwas.

Dann muss man die Konfiguration eben darüber vornehmen und die Verbindung in die entsprechenden Textdateien eintragen. Wie bitte, es ist kein Texteditor ausser vi vorinstalliert, und der funktioniert auch nur halbgar? Schade.

Dann wünsche ich viel Spass und Geduld beim Eintragen von Konfigurationen über echo-Weiterleitungen. Und aus eigener Erfahrung kann ich sagen: Geduld wird man brauchen, per default ist diese Konfiguration eher nervenaufreibend als irgendetwas anderes.

Wenn das System allerdings einmal läuft ist es sehr, sehr angenehm, gerade, wenn man die nicht ganz so rudimentäre Xfce-ISO genommen hat. Wer aber ein rollendes System sucht, das sich nach üblichen Standards aufsetzen lässt, wird vermutlich kein Freund von Void werden.

Es ist und bleibt auch eine Geschmackssache, mit welcher Geschwindigkeit ein System rollen soll: An der Bleeding-Edge bewegt sich Void nicht wirklich. Beispielsweise steht Inkscape noch bei Version 1.1, obwohl schon im Juli Inkscape 1.2 erschienen ist. Der Linux-Kernel hingegen lässt sich schon in Version 5.19 installieren.

Unterm Strich kann ich Void nur denjenigen empfehlen, die wirklich mal etwas ganz anderes ausprobieren wollen: Dann ist Void wirklich toll. Ausserdem sollte man einen Reddit-Account mitbringen, sonst könnte Void schnell zur Distro mit sieben Siegeln werden.

openSUSE Tumbleweed: Btrfs oder nichts?

Mit openSUSE Tumbleweed findet sich in der RPM-Welt eine vergleichsweise aktuelle und dennoch stabile Rolling Release-Distro. Anstatt die Pakete direkt weiterzuleiten (Arch), ein bis zwei Wochen zurückzuhalten (Manjaro) oder in bestimmten Fällen monatelang auf dem gleichen Stand zu halten (Void), gilt bei Tumbleweed die Factory-First-Policy:

Anstatt in den Tumbleweed-Zweig aufgenommen zu werden, landen neue Pakete zunächst im Factory-Zweig. Die entsprechende Weiterleitung erfolgt dann nach automatisierten Tests relativ schnell, was sowohl Aktualität als auch Stabilität unter marginalen Einschränkungen zu garantieren versucht.

Das klingt natürlich ersteinmal wie das perfekte Rolling Release. Trotzdem sollte man bei Tumbleweed eine spezielle Gewohnheit der Entwicklung beachten: Die Pakete werden in der Regel im Verbund ausgeliefert, das kann im Falle grosser Desktopumgebungen schnell zu sehr, sehr wuchtigen Downloads führen.

Für diejenigen, die statt einer Internetverbindung eine Bambusleitung benutzen müssen, könnte das gegebenenfalls schwierig werden.

Sollte dann aber etwas nicht funktionieren, hält openSUSE einen interessanten Sicherheitsmechanismus bereit, der der Distribution weitgehend als Alleinstellungsmerkmal erhalten geblieben zu sein scheint, auch wenn er sich theoretisch unter anderen Distros umsetzen liesse.

Die Rede ist natürlich von den automatisierten Dateisystemschnappschüssen, die Tumbleweed über das Tool Snapper vornimmt und als Read-only-Snapshots als Booteinträge im GRUB-Bootloader verfügbar macht. So kann nach jedem Update ein älterer Schnappschuss gestarten werden, auf den über ein einfaches Kommando zurückgerollt werden kann.

Dabei gibt es allerdings eine Bedingung: Um die automatisierten Schnappschüsse erstellen zu können, muss openSUSE mit dem Dateisystem btrfs installiert werden; wer das nicht möchte, guckt gegebenenfalls in die Röhre, wenn das System mal kaputt geht:

Sicherlich können bei einem ext4-Dateisystem auch Schnappschüsse erstellt werden, meistens funktioniert das über rsync. So komfortabel wie die btrfs-Schnappschüsse ist das aber nicht wirklich, zumindest, was openSUSE angeht. Dann müsste man vermutlich auf externe Tools wie TimeShift zurückgreifen, die sich allerdings nicht so gut in openSUSE integrieren würden.

Für die meisten ist eine Installation mit btrfs vermutlich kein Problem; auch wenn sich dieses Dateisystem klar von ext4 unterscheidet und teilweise stabiler sein könnte -- schlussendlich kann man vermutlich alles lernen.

Ich hatte mit btrfs ein sehr merkwürdiges Problem, als ich openSUSE zum ersten mal mit diesem Dateisystem auf meiner Hardware installiert habe: Das System ist bei zwei von drei Bootversuchen im GRUB-Bootloader hängen geblieben, was mir mit ext4 noch nie passiert ist.

Mittlerweile hat sich herausgestellt, dass ich die SecureBoot-Option, die openSUSE standardmässig anschaltet, im letzten Abschnitt des YaST-Installers ausschalten muss. Woran das genau liegt, kann ich auch nicht wirklich sagen. Eigentlich habe ich SecureBoot schon auf UEFI-Ebene abgeschaltet.

Eventuell haperte es damals auch nicht an der vermeintlich falschen SecureBoot-Einstellung, sondern am allgemeinen Entwicklungsstand von btrfs. Wie auch immer; bei Tumbleweed scheint man sehr stark auf btrfs zu setzen.

Leider habe ich bis heute noch keine Option gefunden, über zypper Pakete unabhängig von den Dateisystem-Schnappschüssen zurückzurollen, wie es beispielsweise mit Arch über den Pacman-Cache möglich wäre. Vermutlich würde das aber ohnehin in einem Desaster enden, da grosse Paketgruppen bei Tumbleweed häufig als geschnürte Gesamtpakete ausgeliefert werden.

In meiner persönlichen Wahrnehmung sind mir Distributionen, die dediziertes Zurückrollen von Paketen erlauben lieber. Ein weiterer Kritikpunkt ist die teilweise stark veraltete oder fehlende Dokumentation, verschiedener Teile des Systems.

Die hier genannten Argumente bleiben eine subjektive Auffassung, womit ich zur letzten Distribution in diesem Beitrag kommen möchte.

Debian bleibt mein Favorit

Schon die Zwischenüberschrift macht deutlich: Dieser Abschnitt ist der mit Abstand subjektivste dieses Vergleichs: Nachdem ich in den vergangenen Monate wirklich viele Distributionen ausprobiert habe, von denen ich in diesem Beitrag nur einen Bruchteil beschrieben habe, bin ich bis jetzt immer wieder zu Debian GNU/Linux zurückgekehrt.

Debian wird häufig mit dem Stable-Zweig assoziiert, bietet daneben aber noch einiges mehr: Der Paketfluss ist im Debian Community-Projekt wie folgt aufgebaut.

Neue Pakete landen bei Debian zunächst im "Experimental"-Zweig; dieser ist keinesfalls für einen produktiven Einsatz empfohlen und nur als Auffangbecken für brandneue Pakete gedacht; so landete beispielsweise die Version 43 des GNOME-Desktops noch am Tag der Veröffentlichung bzw. einen Tag danach im experimentellen Zweig.

Wer Pakete aus diesem Zweig einbinden möchte, muss dies über das relativ umständliche apt-pinning tun, den Aufwand ist es in der Regel allerdings nicht wert: Der "Unstable"-Zweig ist im Gegensatz zu experimental ein vollständiges Paketrepository, dass die aktuellsten stabilen Pakete enthält, die in der Debian-Welt verfügbar sind.

Entgegen dem Namen ist Unstable ('Sid') relativ stabil, da besonders instabile Pakete durch Experimental zurückgehalten werden. Was die Stabilität angeht ist er am ehesten mit dem Tumbleweed-Zweig von openSUSE vergleichbar, auch wenn die Pakete hier nicht als grosse Batzen eintreffen sonder eher Stück für Stück ihren Weg in die Distribution finden.

Debian Sid bildet ausserdem die Basis für die Derivate Ubuntu und Siduction. Wer Debian Sid installieren möchte, muss entweder von einer stabilen Debian-Installation upgraden, das Upgrade von einem Testing-System vornehmen oder mit der mini-iso über den Experten-Installer installieren.

Das mag etwas umständlich klingen, allerdings machen die Release-Upgrades bei Debian meiner Erfahrung nach keine Probleme, lediglich einige Konfigurationsdateien können sich beim Wechsel von Stable bzw. Testing zu Sid ändern, wenn man das denn so möchte (dpkg/apt fragt dann entsprechend nach).

Wem Sid trotz dessen zu instabil ist, kann in der Debian-Familie auch auf den Testing-Zweig setzen. Dieser ist die Vorabversion des nächsten Debian Stable und wird entsprechend dem üblichen, aber nicht konkret festgelegten Debian-Release-Zeitplan schrittweise eingefroren und so zum nächsten Stable. Sobald entsprechende Freeze-Daten feststehen, können sie unter https://release.debian.org/ eingesehen werden.

Wenn sich Testing noch nicht in der Freeze-Phase befindet, kommen Pakete in der Regel nach einem festgelegten Muster im Repository an: Sobald ein Paket zwischen zwei und zehn Tagen ohne Probleme oder kritische Regressionen in Sid war, kann es nach Debian Testing weitergeleitet werden. Wenn es mal sehr dringend ist, kann ein Paket auch sofort aus Sid in Testing weitergeleitet werden. (Siehe auch: https://wiki.debian.org/DebianTesting)

Wer ein rollendes Debian einsetzen möchte, sollte meiner Ansicht nach eher auf Sid setzen, wenn dies ein langfristiger Plan ist: In der Regel kommen wichtige Pakete eher in Sid an und werden eben nicht sofort in Testing weitergeleitet; wichtig bleibt eben ein subjektiver Begriff.

In Einzelfällen können Pakete auch aus Testing rausfliegen, obwohl sie in Sid noch in der gleichen Version verfügbar wären, die schonmal in Testing waren -- das war in jüngster Vergangenheit zum Beispiel bei Audacity der Fall, vor kurzem ist aber eine neue Version in Sid eingetroffen, was mir Hoffnung gibt, dass Audacity in kürze nach Testing migriert wird.

Weitere Beispiele für ein derartiges Verhalten wären momentan die Pakete 'gufw' und 'mate-media'. Dementsprechend ist Testing als momentane Entwicklungsversion anzusehen, die entsprechend der Debian Stable-Veröffentlichungszyklen starken Schwankungen unterliegen kann.

Als rollendes Debian würde ich persönlich daher zu Debian Sid raten, Testing würde ich dann empfehlen, wenn eine stabile Veröffentlichung absehbar ist, und dementsprechend neuere Pakete eingefroren worden sind -- dann verändert sich theoretisch nur noch sehr wenig, wobei schon vor einer neuen stabilen Veröffentlichung die Paketstände angehoben werden können.

Dann sollte in der Datei /etc/apt/sources.list aber statt 'testing' der entsprechende Codename des nächsten Stable eingetragen werden. Möchte man also zum Beispiel kurz vor der Veröffentlichung von Debian 12 die entsprechenden Pakete austesten, sollte der Codename 'bookworm' eingetragen werden, sollte Bookworm seinen Lebenszyklus durchlaufen haben und zu Oldstable werden, könnte man dann 'trixie' eintragen und so weiter.

Dementsprechend würde man dann weitgehend bei einem stabilen System bleiben und einige Wochen eine relativ stabile Vorschau nutzen. Möchte man nicht von Stable aktualisieren, können unter folgender Adresse auch wöchentlich neu erstellte Testing-Snapshots heruntergeladen werden: https://www.debian.org/CD/http-ftp/

Doch auch für Sid-Nutzer/-innen ist Testing wichtig: Über die hold-Funktion von apt können auch in einer Sid-Installation installierte Pakete aus einem zeitweise aktivierten Testing-Repo installiert werden, und dem Namen entsprechend auf einem älteren Versionsstand gehalten werden.

Das mag eine kurzfristige Lösung sein, ist alles in allem aber auch nicht mehr als das. Auf lange Sicht ist die dauerhafte Installation von Testing-Paketen in einem Sid-System, gerade, wenn diese gehalten werden, als vorprogrammiertes Abhängigkeits-Chaos anzusehen.

Wer noch mehr über Debian-Sid-spezifisches Paketmanagement erfahren möchte, sollte sich das ausgezeichnete Siduction-Manual anschauen. Weitere Informationen finden sich auch im Debian Wiki.

Für mich persönlich stellt Debian Sid, auch wenn es nicht unbedingt dafür bekannt ist, eine der besten Rolling-Releases dar: Dpkg/apt ist in Verbindung mit aptitude eine verständliche Paketverwaltung, die ein leichtes installieren von Paketen sicherstellt, darüber hinaus aber auch eine kontrollierte Verwaltung von installierten Paketen aus den umfassenden Debian-Repos ermöglicht. Dahingehend ist man auch nicht von gegebenenfalls unsicheren Repos wie dem AUR abhängig.

Ich verstehe, dass Pacman oder XBPS schneller als apt sind, ich verstehe auch diejenigen, die sich ihre Distributionen dementsprechend aussuchen. Wer allerdings bei Debian bleiben möchte, sollte vielleicht mal einen Blick auf nala werfen, ein Programm, das versucht, flotter als apt zu arbeiten und auf Sid angepasst ist.

Gerade das Zusammenspiel der verschiedenen Repository-Zweige machen Debian für mich zu einem universell einsetzbaren Betriebssystem. ;)

Am Ende möchte ich noch einmal betonen, dass ich mit diesem Beitrag keinesfalls andere rollende Distributionen diskreditieren oder angreifen möchte; jede der hier vorgestellten Distributionen hat eine andere Herangehensweise an das Thema, die dem einen mehr, der anderen weniger gut gefällt.

Ausserdem repräsentieren meine Erfahrungen mit den verschiedenen Distros auch keinesfalls die Projekte an sich; das ist oftmals auch von den eigenen Vorkenntnissen oder der Hardware abhängig.

Wer Arch nutzen möchte, nutzt Arch. Void-Fans bleiben bei Void und openSUSE-Nutzer/-innen bei ihrer Distro. Und ich bleibe vermutlich bei Debian: jede dieser Entscheidungen hat seine Berechtigung.

Beitragsbild: Alextredz, CC BY-SA 4.0, via Wikimedia Commons: https://commons.wikimedia.org/wiki/File:Greasing_bicycle_chain.jpg

Dieser Artikel fasst alle Termine für Firefox und Firefox ESR im Jahr 2023 übersichtlich zusammen.

Neue Major-Releases von Firefox erscheinen in der Regel alle vier Wochen. Auf diese Weise erreichen Neuerungen schneller den Endnutzer, der nicht viele Monate auf bereits implementierte Funktionen warten muss.

Mittlerweile hat Mozilla die Veröffentlichungstermine von Firefox für das Jahr 2023 offiziell bestätigt.

Das sind die Firefox Release-Termine 2023

Firefox 109, Firefox ESR 102.7
17. Januar 2023 (5 Wochen nach Firefox 108)

Firefox 110, Firefox ESR 102.8
14. Februar 2023 (4 Wochen nach Firefox 109)

Firefox 111, Firefox ESR 102.9
14. März 2023 (4 Wochen nach Firefox 110)

Firefox 112, Firefox ESR 102.10
11. April 2023 (4 Wochen nach Firefox 111)

Firefox 113, Firefox ESR 102.11
09. Mai 2023 (4 Wochen nach Firefox 112)

Firefox 114, Firefox ESR 102.12
06. Juni 2023 (4 Wochen nach Firefox 113)

Firefox 115, Firefox ESR 115.0, Firefox ESR 102.13
04. Juli 2023 (4 Wochen nach Firefox 114)

Firefox 116, Firefox ESR 115.1, Firefox ESR 102.14
01. August 2023 (4 Wochen nach Firefox 115)

Firefox 117, Firefox ESR 115.2, Firefox ESR 102.15
29. August 2023 (4 Wochen nach Firefox 116)

Firefox 118, Firefox ESR 115.3
26. September 2023 (4 Wochen nach Firefox 117)

Firefox 119, Firefox ESR 115.4
24. Oktober 2023 (4 Wochen nach Firefox 118)

Firefox 120, Firefox ESR 115.5
21. November 2023 (4 Wochen nach Firefox 119)

Firefox 121, Firefox ESR 115.6
19. Dezember 2023 (4 Wochen nach Firefox 120)

Der Beitrag Firefox: Release-Termine 2023 erschien zuerst auf soeren-hentzschel.at.

Wenn das hier einfach nicht klappen will:

ssh -X user@ipadresse rxvt
urxvt: can't open display :0, aborting

Dann muss das nicht an Wayland liegen, sondern daran, dass auf beiden Seiten xauth installiert sein muß!

Puh!

Der aus Deutschland stammende Passwort-Manager heylogin will sich von anderen Produkten dieser Art dadurch unterscheiden, dass kein Master-Passwort eingetippt werden muss. Mozilla hat in heylogin investiert.

Passwort-Manager ohne Master-Passwort – so beschreibt sich heylogin selbst. Während andere Anwendungen dieser Art auf ein sogenanntes Master-Passwort setzen, um den Zugriff auf die gespeicherten Zugangsdaten zu schützen, sollen sich Nutzer von heylogin via Swipe-Geste auf ihrem Smartphone oder Tablet auf Websites anmelden.

In einer sogenannten Pre-Seed-Runde hat das noch junge Startup aus Deutschland insgesamt 900.000 Euro eingesammelt. Zu den Investoren gehört auch Mozilla.

Der Beitrag Mozilla investiert in Passwort-Manager heylogin aus Deutschland erschien zuerst auf soeren-hentzschel.at.

Was sich als Projekt vor zwei Jahren langsam abzeichnete, geht nun in die finale Umsetzung: der Linux-Kernel soll zukünftig nicht nur in der Programmiersprache C, sondern auch in Rust geschrieben sein. Während die Rust-Unterstützung noch die Aufnahme in Linux 6.0 knapp verpasst hat, soll es mit Linux 6.1 nun so weit sein. ZDNET berichtet von einer geplanten Aufnahme in die kommende Linux-Version:

The implementation has begun. In an email conversation, Linux's creator Linus Torvalds, told me, "Unless something odd happens, it [Rust] will make it into 6.1." (Steven Vaughan-Nichols, ZDNET.com, 19. September 2022)

Für die Implementierung ist das Projekt "Rust for Linux" zuständig (siehe Git-Repo auf GitHub). Federführend bei der Implementierung ist Miguel Ojeda, die Entwicklung wird von Unternehmen wie Google unterstützt und gesponsert.

Während C oft als "portable Assemblersprache" wahrgenommen wird, die viel Eigenverantwortung voraussetzt, abstrahiert Rust insbesondere das Speichermanagement zu gewissen Teilen über die Ownership-, Reference- und Borrowing-Konzepte weg. Die Sicherheit und Zuverlässigkeit des Linux-Kernels soll erhöht werden, indem bestimmte Programmierfehler konzeptionell verhindert werden.

Rust soll dabei den Kernel nur ergänzen und mittelfristig nicht ersetzen. Die Anstregungen, die das Rust-for-Linux-Projekt auf sich genommen hat, umfassen eine Infrastruktur und Umgebung, um Treiber in Rust für den Kernel entwickeln zu können.

Die MZLA Technologies Corporation hat mit Thunderbird 102.3.1 ein Update außer der Reihe für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 102.3.1

Mit dem Update auf Thunderbird 102.3.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht. Mit dem Update werden vier Sicherheitslücken im verwendeten SDK für das Chat-Protokoll Matrix behoben. Dazu kommen weitere Fehlerbehebungen und Verbesserungen, welche sich in den Release Notes (engl.) nachlesen lassen.

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

Fr, 30. September 2022, Samuel Rüegger

Über Ubuntu – und mein Verhältnis zur Distribution

Ubuntu ist wohl die bekannteste und umstrittenste Linux-Distribution auf dem Linux-Markt. Ich finde, Ubuntu zeigt wunderbar auf, wie eben oft die kommerziellen Interessen einer Firma hinter einer Distribution nicht zwingend den Interessen Linux-Community dienen und umgekehrt.
Das erste Mal mit Ubuntu in Berührung kam ich im Jahr 2005, ich probierte Ubuntu 5.04 (oder 5.10 – bin nicht mehr sicher) aus, und wechselte in diesem Jahr von SuSE Linux OSS (heute openSuSE) nach Ubuntu.

Ubuntu hat zum damaligen Zeitpunkt sehr vieles richtig gemacht. Einfacher Installer (Geburt der Live-Umgebungen), keine komplizierten Installationen von Extra-Repositorys, um eine mp3 oder eine mkv-Datei (die natürlich immer aus super seriösen Quellen stammten) abzuspielen und – in meinem Fall – keine ewiges herum fummeln an der xorg.conf, damit mein Display in der richtigen Bildschirmauflösung funktionierte.
Ubuntu war für mich die erste «Plug & Play» Distribution: Installieren und es funktionierte direkt alles, ohne dass ich etwas anpassen oder rumfummeln musste – ziemlich cool.

Ich bin dann Ubuntu viele Jahre treu geblieben, bis im Jahr 2011 der GNOME Desktop durch den Unity Desktop ersetzt wurde. Unity war damals kein schlechter Desktop, aber ich bin ein "GNOME-Kind" und das war ich auch damals schon.

Ich ging zu der Zeit zu Fedora, dann zu pop_OS! Und später (als pop_OS! angekündigt hatte, GNOME durch ihr eigenes Ding zu ersetzen) wieder zu Fedora.
Zu Fedora habe ich eine gewisse Hassliebe. Ich liebe die GNOME-Integration, da diese wirklich gut ist. Was ich nicht so mag, ist, dass man für Multimedia-Codecs wieder Extra-Repositories braucht und dass allgemein relativ wenig Pakete in den Standard Repositorys sind.

Das ist der Grund, warum ich mir immer wieder die aktuellen Ubuntu Releases anschaue. Mit den letzten paar Releases – auch mit Ubuntu 22.04 LTS – war ich nicht ganz glücklich. GNOME war immer ein Misch-Masch aus gefühlt 3-4 verschiedenen Releases und wurde nicht wirklich gut gepflegt.

Das Testsystem

Was macht Ubuntu 22.10 anders als die vorherigen Releases?


Das Wichtigste: GNOME ist kein Mischwarenkonzern mehr. Während man bei Ubuntu 22.04 noch versuchte, möglichst keine libadwaita Apps in den Paketquellen zu haben, ist bei Ubuntu 22.10 nun alles auf Version 43 und alles auf libadwaita. Sogar gedit wurde durch den neuen GNOME Text Editor ersetzt.

Ubuntu geht hier aber noch einen Schritt weiter: Das Design Team von Ubuntu zeigt nun allen libadwaita-Kritikern wie Distributionen trotz libadwaita noch eigene Akzente setzen können. Ubuntu hat bereits im 22.04-Release die Akzentfarben eingeführt – Ziel der GNOME Entwickler wäre es gewesen, Akzentfarben auch in GNOME 43 einzuführen – leider wurde das auf GNOME 44 verschoben.

Das hat die Ubuntu Entwickler aber nicht davon abgehalten, die Akzentfarben in ihr libadwaita-yaru-theme einfliessen zu lassen.
Bei der Wahl einer Akzentfarbe ändert sich das entsprechende libadwaita Theme. Ganz cool ist hier die komplette Konsistenz vom Design Team. Das Yaru Theme besteht aus diversen Themes, die für einen einheitlichen und konsistenten Desktop-Look sorgen.

Neben dem libadwaita/yaru Theme gibt es auch ein normales GTK4 Theme, ein GTK3 Theme und ein GTK2 Theme. Alles jeweils in hell und dunkel und mit Unterstützung für Akzentfarben. Das dürfte in der GNOME-Desktop Welt ziemlich einmalig sein und ist wirklich sehr angenehm.

Ich bevorzuge übrigens die dunkle Yaru Variante mit einer violetten Akzentfarbe ;)

Bei diesem Ubuntu-Release habe ich das erste Mal seit langer Zeit das Gefühl, dass die Ubuntu Entwickler wirklich wieder Liebe in die Desktop Version investiert haben.

Das GNOME Einstellungsmenü hat nun eine eigene «Ubuntu Desktop» Sektion, in der man Einstellungen zu Desktop Icons und zum Ubuntu eigenen Dock vornehmen kann. Alles sehr übersichtlich und nett gemacht.


Auch Snap hat Liebe bekommen…

Wenn wir über Ubuntu sprechen, müssen wir auch über Snap sprechen. Ich mache hier keine Pro- und Kontra Diskussion auf, Snap ist ein Teil von Ubuntu und wird es auch in absehbarer Zukunft bleiben.

Soweit ich es sehen kann, bleiben zurzeit Firefox und der App-Store die einzigen Apps, die standardmässig per Snap installiert sind.
Beim Ubuntu 22.04 Release gab es viele kritische Berichte zu Snap einerseits wegen der langsameren Startgeschwindigkeit (beim ersten Start), die fehlende Desktop-Integration (Passwortmanager und GNOME Extensions) und die VAAPI Unterstützung.

In den letzten paar Versionen von Snap und von Firefox haben Mozilla und Canonical zusammengearbeitet und es gab es einige Anpassungen und Bugfixes, um die Probleme der Startgeschwindigkeit anzugehen.

Die Änderungen sind extrem vielseitig aber ich versuche die wichtigsten aufzulisten:

• Firefox lädt beim Start nicht mehr alle Sprachpakete, sondern nur noch das Sprachpaket, das mit der Systemsprache übereinstimmt. (Von dieser Änderung profitieren auch alle Firefox-User, die Firefox nicht als Snap installiert haben).
• Die Snap-Abhängigkeiten für Firefox (gnome-3.38-x, gtk-common-themes) werden nun mit dem LZO Algorythmus komprimiert. LZO kann wesentlich schneller entpackt werden. (Von der Änderungen profitieren alle Snap-Apps, die diese Abhängigkeiten nutzen – unter anderem auch Chromium).
• Snap basiert auf Squashfs. Squashfs wurde optimiert, so dass es nun mehrere Prozessoren statt nur einen nutzen kann, was ebenfalls einen massiven Geschwindigkeits-Boost bringt.

Snap bekam einige Improvements, so dass Firefox nun nativ mit Wayland läuft und GPU Beschleunigung (VAAPI) unterstützt → vorerst noch in der Beta.

Ich persönliche merke auf einer SSD keinen Unterschied mehr, ob ich Firefox als Snap oder als APT Paket starte. Ich habe in gewissen Kommentarspalten gelesen, dass man die langsamere Startzeit bei klassischen Festplatten noch spüren kann.

Unter dem kryptischen Namen "XDG WebExtension Portal" gibt es ein neues Portal (Flatpak nutzt dies auch), mit dem es möglich ist, dass Erweiterungen von Firefox mit Host-System kommunizieren können.

In der aktuellen Snap-Firefox Beta Version funktioniert das Installieren von GNOME Erweiterungen bereits problemlos. Das Portal kann in Zukunft auch für Erweiterungen wie Passwortmanagern genutzt werden.

Dieses Portal wird zurzeit in Snap ausführlich getestet. Sobald es final freigegeben wird, wird es Mozilla innerhalb von Flatpak testen. Das Portal wurde absichtlich Flatpak kompatibel entwickelt, auch hier profitieren wieder viele weitere Linux-Distributionen von Entwicklungen innerhalb von Snap.


Sonstiges und mein Fazit

Wie immer mit einer neuen Ubuntu Version werden auch alle Paketversionen in Ubuntu Universe aktualisiert.
Das schöne an Ubuntu ist, dass ich so ziemlich alles installieren kann, ohne dass ich zusätzliche Repositories brauche. Docker ist da (fehlt z.B. bei Fedora), Multimedia Codecs sind da, und wenn doch was fehlt, gibt es noch die Snaps.

Auch Flatpak ist im Repo vorhanden und kann einfach installiert werden. Das Ubuntu Design Team liefert ihre GTK Layouts auch bei Flathub aus, so dass es auch bei Flatpak Apps zu keinen Inkonsistenzen kommt.

Gerade weil man in Ubuntu gefühlt jede Software installieren kann, war Ubuntu schon immer eine gute Distribution. Dank einem einheitlichen Desktop und einheitlichen Layouts von GTK2 bis libadwaita und einem einheitlichen GNOME dürfte Ubuntu aus meiner Sicht die wohl beste GNOME 43 Distribution werden. Und – aus meiner Sicht – kann Ubuntu ab Version 22.10 auch wieder bedenkenlos weiterempfohlen werden.

Achtung: Ich habe hier mit einer in Entwicklung befindlichen Linux-Distribution herum gespielt. Wenn Du ein Linux-Beginner bist, solltest du das nicht (!) tun. Ubuntu 22.10 bekommt zurzeit täglich grosse Aktualisierungen, bei denen oft viele Dinge schief gehen können – so startete bei mir z.B. zwei Mal nach einem Update die grafische Oberfläche nicht mehr.
Wenn du dich für Ubuntu 22.10 interessierst, dann warte bis zum finalen Release, das gegen Ende Oktober erscheinen wird.

In letzter Zeit gibt es mehr Berichte über Probleme mit zurückgehaltenen Paketen bei Ubuntu. Dahinter stecken aber meist gar keine zu lösenden Probleme, sondern die Ursache liegt im Phased Updates Mechanismus.

Wer lediglich grafische Frontends nutzt – was sicherlich auf die meisten Anwender von Ubuntu zutrifft und der Zielgruppe entspricht – hat das noch gar nicht bemerkt, weil die Updates dort überhaupt nicht aufgelistet werden. Wer jedoch die Konsole benutzt, sieht seit einiger Zeit häufiger mal folgende Meldung.

sudo apt full-upgrade
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
Die folgenden Pakete sind zurückgehalten worden:
  libnss-systemd libpam-systemd libspeechd2 libsystemd0 libudev1 systemd systemd-sysv systemd-timesyncd udev
Die folgenden Pakete werden aktualisiert (Upgrade):
  ghostscript ghostscript-x libgs9 libgs9-common
4 aktualisiert, 0 neu installiert, 0 zu entfernen und 9 nicht aktualisiert.
4 standard security updates

Dahinter verbirgt sich folgende Änderung in Ubuntu 22.04, die den Release Notes entnommen werden kann:

Since 21.04 APT respects phased updates, see the Phased updates in APT 21.04 93 thread for more details.

Jammy Jellyfish Release Notes

Die zurückgehaltenen systemd-Pakete im obigen Beispiel sind also kein Fehler, sondern Absicht. Es handelt sich dabei um nicht-sicherheitskritische Aktualisierungen, die dem Phased-Updates – also übersetzt in etwa schrittweise Aktualisierung – Mechanismus unterliegen. Die Updates werden also irgendwann in den kommenden Tagen verteilt und dann einfach bei „Die folgenden Pakete werden aktualisiert“ gelistet. Ein Update kann natürlich manuell angestoßen werden, aber das ist unnötig.

Dieser Mechanismus betrifft nur den SRU-Bereich. (Stable Release Updates). Also jene Updates, die keine sicherheitsrelevanten Probleme betreffen. Security-Fixes werden weiterhin sofort an alle Anwender verteilt.

Die Idee ist, dass nicht kritische Updates (SRU) die Anwender in verschiedenen Wellen erreichen. Sollten trotz Tests und Prüfungen Fehler in den Updates enthalten sein, dann schlagen die nicht bei allen Anwendern gleichzeitig auf und ein Update kann ggf. nach einem begrenzten Schaden zurückgezogen werden. Microsoft und Apple verfahren schon sehr lange nach diesem Mechanismus.

Wer sich daran stört, kann das Verhalten steuern. Dazu muss man einfach die folgende Konfiguration in APT vornehmen:

$ sudo nano /etc/apt/apt.conf.d/99-Phased-Updates

Dort dann folgende Zeile eintragen:

APT::Get::Always-Include-Phased-Updates True;

Das wirkt sich dann aber nur auf APT auf der Kommandozeile aus. Die grafischen Frontends behandeln Phased Updates wie zuvor und werden diese erst anzeigen, wenn sie an der Reihe sind.

Wie so oft gibt es mal wieder Vorbehalte bei irgendwelchen Unix-Veteranen. Diese Kritik ist wie so oft quasi ein umgekehrter Kompass und nur ein Zeichen dafür, dass die Idee gut ist und sich Linux in die richtige Richtung entwickelt.

Mi, 28. September 2022, Lioh Möller

Mit einem kürzlich applizierten Patch, deaktiviert das Fedora Projekt in den Mesa-Paketen die Unterstützung für Hardware-Video-Decoding in der GPU.

In den Commit-Notes wird angegeben, dass rechtliche Bedenken der Auslöser seien und dass zuvor die Hardwarebeschleunigung lediglich aktiv gewesen sei, da dies übersehen wurde.

Drop codecs.

We don't have legal approval for this. Previously it was accidentally
shipped.

Diese Änderung wird unmittelbare Auswirkungen auf die Nutzer der Distribution haben, da zur Darstellung von Multimediainhalten, welche die Codecs h264dec, h264enc, h265dec, h265enc oder vc1dec nutzen, von nun an ausschliesslich die CPU zum Einsatz kommt.

Bereits vor rund 6 Monaten hat das Mesa Upstream-Projekt in Menson die Möglichkeit zum Deaktivieren der Codecs integriert. Auch hier wurden lizenzrechtliche Gründe angegeben, insbesondere mit dem Verweis auf MPEG-LA.

Zur Erklärung wurde dabei ein Blog-Post von Jina Jiayang Liu genannt.

Inwieweit andere Distributionen dieser Entwicklung folgen werden, ist bisher unklar. Nutzern von Fedora 37 bleibt aktuell nur die Erstellung eines angepassten Mesa RPM-Paketes übrig. Möglicherweise wird in Zukunft ein Drittanbieter-Projekt diese Aufgabe übernehmen.

Quelle: https://debugpointnews.com/fedora-37-mesa/

Ich freue mich wie ein kleines Kind!

Wenn es soweit ist, muß ich unbedingt mal wieder eine Lan Party machen.

Zum Appetit holen, ein Blick auf die neuen Spiel Typen: new-game-types-for-world-of-padman/

worldofpadman.net/news/world-of-padman-1-7-in-development/

Unter Umständen kann es vorkommen, das bei einer Paketaktualisierung mittels apt folgende Meldung erscheint: Grund für diese Meldung kann unter anderem sein, das in der Abhängigkeitskette für eines der Pakete ein neues Paket dazugekommen ist. Daneben werden Pakete in der gleichen Version im Normalfall nicht noch einmal aktualisiert. Soll ein solches zurückgehaltenes Paket trotzdem installiert…

Quelle

In diesem Artikel möchte ich euch das Förderprogramm Media Tech Lab des Media Lab Bayern vorstellen.

Wie dem Titel bereits zu entnehmen ist, werden Open Source Projekte mit bis zu 50.000 EUR pro Projekt gefördert. Das Geld dafür kommt aus der Bayerischen Staatskanzlei. Doch der Reihe nach.

Vor einiger Zeit schrieb mich Jessica vom Media Lab Bayern an, um mich auf das Programm aufmerksam zu machen. Sie fragte, ob ich nicht Interesse habe, mich mit ihr und Erkan Kasap (CTO) über das Programm zu unterhalten, um ggf. darüber zu berichten und so dessen Bekanntheitsgrad zu steigern. Der Zufall sorgte dafür, dass Erkan und ich uns auf der FrOSCon 2022 an der Hochschule Bonn-Rhein-Sieg in Sankt Augustin begegnet sind, wo wir uns gemeinsam mit Dirk über das Programm ausgetauscht haben. Erkan strahlte dabei eine Leidenschaft und ein Commitment aus, welche mir den Eindruck vermittelten, dass er für dieses Projekt brennt.

Um was für Projekte geht es?

Das Programm sucht innovative Projektideen zu Themen aus den Bereichen:

• Infrastruktur & Web-Technologie
• UX-Design & User Experience
• Machine Learning & Natural Language Processing
• Web3 & Blockchain
• Augumented & Mixed Reality

Ihr arbeitet bereits an entsprechenden Projekten oder strebt dies an? Ihr seid dabei auf eine Anschubfinanzierung angewiesen oder braucht Unterstützung bei der Projektplanung? Dann könnt ihr euch mit eurer Idee hier bewerben.

Ihr habt noch keine konkrete Idee, würdet aber gern mal an einem Open Source Proejekt arbeiten, welches das Potenzial hat, die Medienbranche zu verändern? Dann schaut in die Projektideen und lasst euch inspirieren.

Wen sucht Erkan?

Erkan ist auf der Suche nach:

• Open Source-Entwickler:innen und
• Software-Freelancer:innen

die Lust auf ein cooles Forschungs- und Entwicklungsprojekt in und für die Medienbranche haben. Wichtig dabei ist, dass nur Einzelpersonen oder Teams aus Einzelpersonen gefördert werden können, jedoch keine Unternehmen.

Seid ihr z.B. Entwickler, die über ein Sabbatical nachdenken, um mal an einem richtig coolen Projekt zu arbeiten, aber in dieser Zeit auch Einkommen erzielen müssen, dann ist dieses Programm für euch.

Ihr seid jung, sprudelt vor innovativen Ideen, die ihr unbedingt umsetzen wollt? Doch es fehlt das Geld und ein wenig Unterstützung darin, wie man ein Projekt erfolgreich durchführt? Dann nehmt Kontakt zu Erkan auf. Vielleicht ist euer Projekt dann schon bald dabei und wird Realität.

Welche Projekte haben keine Chance?

Euer Projekt muss innovativ sein. Nicht innovativ sind z.B.:

• Noch eine Rechtschreib- und Grammatikkorrektur für Office-Programme
• Peer-Review-Portale
• Sync&Share-Lösungen

Halt alles was es prinzipiell schon gibt. Damit sind jedoch nicht bereits existierende Projekte gemeint, denen es vielleicht noch an Funktionalität fehlt, um produktiv eingesetzt zu werden.

TL;DR: Wenn ihr alten Wein in neuen Schläuchen verkaufen wollt, seid ihr bei Erkan an der falschen Adresse.

Die harten Fakten

Wenn dein/euer Projekt angenommen wird, arbeitet ihr bis zu sechs Monate an eurem Projekt. Dies geht remote oder beim Media Lab im Open Space in München. Der Arbeit am Projekt wird dabei die größte Zeit des Tages eingeräumt. Der Verwaltungs-Overhead wird auf ein Minimum reduziert. Die Messung und Kontrolle des Fortschritts gehört jedoch zu jedem ordentlichen Projekt dazu. So gibt es selbstverständlich auch hier Check-ins mit dem Media Lab Team, Tech-Experten auf CTO/Senior Level und Produkt Experten (Medienexperten). Mit diesen könnt ihr Fragen zum Tech-Setup diskutieren, die Nutzerperspektive kennenlernen und erhaltet Feedback zu eurem Projekt.

Ihr erhaltet alle zwei Monate ab Beginn des Projekts eine Auszahlung. An das Projektteam (nicht jedes Projektmitglied) werden so max. 45.000 EUR ausbezahlt, die ihr frei einsetzen könnt. Weitere 5.000 EUR sind zweckgebunden und können für Coaching und Mentoring eingesetzt werden. So könnt ihr euch bspw. Experten-Rat zu Themen wie Community-Management oder wie verwalte ich Contributer für mein Projekt einkaufen.

Was gibt es noch nicht?

Auf der FrOSCon kam unser Gespräch darauf, was mit den Projekten passiert, wenn sie fertig und abgenommen sind. Stichwort: Maintenance.

Dieser Punkt ist noch nicht abschließend geklärt. Erkan äußerte die Idee, dass Medienhäuser, die ein Open Source Projekt einsetzen und zu einem Bestandteil ihrer Geschäftsprozesse machen, als Paten auftreten können, um die Pflege und Wartung des Codes zu finanzieren. Dem Gemeinschaftsgedanken folgend, können sich mehrere Unternehmen auf diesem Weg die Kosten für die Software-Pflege teilen.

Eine interessante Idee, bei der allerdings noch offen ist, ob und in welchem Umfang sich Medienhäuser darauf einlassen.

Mein Eindruck

Ich persönlich finde es schon bemerkenswert, dass in Deutschland ein Förderprogramm aufgelegt wird, welches die Entwicklung von Open Source Projekten in diesem Umfang fördert. Etwas Vergleichbares war mir bis dato nicht bekannt.

Erkan hat auf mich den Eindruck hinterlassen, mit viel Herzblut und bis in die Bartspitzen motiviert hinter diesen Programm zu stehen.

In meinen Augen bietet das Programm eine gute Chance, um Open Source Projekten zu einem erfolgreichen Verlauf zu verhelfen. Auch wenn die Finanzierung der Maintenance-Phase nach Projektende noch nicht geklärt ist.

ich habe mir ein weiteres Script für Nautilus gestrickt.

Ab- und zu braucht man mal die Namen einer Anzahl von Dateien, zur Weiterverwendung z.B. Dokumentation o.ä.

Das script macht das einfach, es kopiert die Dateinamen in das Clipboard und als Addon auch mit den Pfaden der Dateinamen.

Nach dem starten vom Script copy-filenames.sh

erscheint das Ergebnis augenblicklich im clipboard

Das Script:

#!/bin/bash
#
#  Titel: copy_filenames.sh
#  Autor: Bed [@] zockertown.de
#  Web: zockertown.de/s9y/
#  Version 0.4
# $Revision: 1.2 $
#  Voraussetzung: Benötigt wird xsel 
#  Zweck: kopiert die Dateinamen als Liste zur weiteren Verarbeitung
# zum Clipboard
# eine weitere Variante enthält alle Fullpath namen in einem Rutsc

if [ ! -f /usr/bin/xsel ]
then
   echo "Bitte xsel installieren."
   exit 1
fi

TMP=/tmp/allin.txt

rm -f $TMP

 for file in $NAUTILUS_SCRIPT_SELECTED_URIS

 do

   file_name=$(echo $file | sed -e 's/file:\/\///g' -e 's/\%20/\ /g' -e 's/.*\///g')
   file_folder=$(echo $file | sed -e 's/file:\/\///g' -e 's/\%20/\ /g' -e "s/$file_name//g")
   echo "$file_name"|xsel -ib
   echo "$file_folder$file_name ">>$TMP
   # sleep ist notwendig, weil ohne Verzögerung werden Einträge unterschlagen
   sleep 0.1
done

cat $TMP|xsel -ib

rm $TMP

Dreh- und Angelpunkt ist das cmdline tool xsel. Es kann Einträge zum Clipboard hinzufügen.

Macht man zuviele Einträge hintereinander unterschlägt es einzelne Einträge, deshalb habe ich sleep 0.1 in der Schleife eingebaut.

Ich nutze gnome 42 als Desktop.

Bisher nahm ich immer clipman als Clipboard Manager, weil einfach keine andere extension funktionierte, bzw. vorhanden war.

Heute nun verschwand der clipman, einfach nicht mehr da.

auch ein install/enable mit 

gnome-extensions enable gnome-clipboard@b00f.github.io

wollte nicht funktionieren.

in der WebGui https://extensions.gnome.org/local/ ist die Rede von Ihr nativer Host-Connector unterstützt die folgenden APIs nicht: v6. 

Was mich zu allerlei Versuchen verleiteten, die allesamt nicht halfen.

Auch das nun vorhandene gnome-clipboard liess sich nicht einschalten.

und wenn, dann tauchte es als icon einfach nicht in der Leiste auf.

Irgendwann kam ich dann auf die Lösung. Die Extensions waren disabled!

Muss man erst mal drauf kommen, denn in der WebGui war das nicht zu erkennen

Mozilla hat mit Firefox 105.0.1 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 105.0.1

Mit dem Update auf Firefox 105 hatte Mozilla eine Änderung vorgenommen, so dass bei Verwendung einer benutzerdefinierten Startseite die Adressleiste anstelle der Website beim Öffnen eines neuen Fenster fokussiert worden war. Basierend auf dem Feedback der Nutzer hat Mozilla diese Änderung mit Firefox 105.0.1 wieder rückgängig gemacht.

Außerdem wurde mit Firefox 105.0.1 eine potentielle Absturzursache behoben, von der manche Linux-Nutzer betroffen waren.

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

Mit quarto setze ich unter anderem auch meine (Geschäfts)Briefe als PDF-Datei. Hierfür habe ich mir ein paar Vorlagen gebastelt, siehe z.B. dieses Beispiel.

Das funktioniert soweit auf dem PC sehr gut. Am Handy oder am Tablet ist quarto mit nicht verfügbar, weshalb ich mir einen kleinen Bot programmiert habe, der einen Nextcloud-Ordner “überwacht” und die vorhandenen .qmd-Dateien zu PDFs rendert.

Der Bot

• mountet den Nextcloud-Ordner per Webdav

• überwacht in einem vorgegebenem Zeitintervall (30 Sek.), ob .qmd-Dateien in diesem Verzeichnis vorhanden sind

• führt den Befehl quarto render DATEI.qmd auf jede .qmd-Datei im Verzeichnis aus. Quarto legt die erzeugten PDF-Dateien ins selbe Verzeichnis.

• verschiebt die .qmd-Datei nach .qmd-TIMESTAMP. So wird sie nicht erneut gerendert.

• wartet 30 Sekunden und fängt wieder von vorne an

• wird über systemd gesteuert.

• läuft nicht als root, sondern als normaler User, in meinem Falle produnis.

So kann ich “von überall”, z.B. am Handy, eine .qmd-Datei erzeugen, diese ins Nextcloud-Verzeichnis uploaden, 30 Sekunden warten, und die fertige PDF-Datei aus dem Nextcloud-Verzeichnis herunterladen.

Der Bot kann an jedem beliebigen Linux-PC mit Internetanschluss betrieben werden. Du musst “lediglich” sicherstellen, dass der Befehl

# muss fehlerfrei durchlaufen
quarto render Datei.qmd

korrekt auf dem Server ausgeführt wird. Der Bot führt ja letztendlich auch “nur” diesen Befehl aus.

# erstelle Verzeichnis
mkdir -p /media/Nextcloudquartobot

# Webdav-Adresse
https://DEINE.NEXTCLOUD/remote.php/dav/files/USERNAME/pfad/zu/ordner

# Passwörter hinzufügen
sudo nano /etc/davfs2/secrets

# Schema
MOUNTPOINT  USERNAME "PASSWORD"

/media/Nextcloudquartobot  produnis "!SuperSecret#Password!"

sudo nano /etc/systemd/system/media-Nextcloudquartobot.mount

/etc/systemd/system/media-Nextcloudquartobot.mount

[Unit]
Description=WebDAV-Mount-Nextcloud-Quarto-Renderbot
After=network-online.target
Before=quarto-nextcloud-bot.service

[Mount]
Type=davfs
What=https://MEINE.NEXTCLOUD/remote.php/dav/files/USER/pfad/zu/ordner
Where=/media/Nextcloudquartobot
Options=noauto,user,uid=produnis,gid=produnis

[Install]
WantedBy=multi-user.target

# mounten
sudo systemctl start media-Nextcloudquartobot.mount

#unmounten
sudo systemctl stop media-Nextcloudquartobot.mount

/etc/systemd/system/media-Nextcloudquartobot.mount

#!/bin/bash

while [[ true ]]; do
        if ls /media/Nextcloudquartobot/*.qmd 1> /dev/null 2>&1; then
                cd /media/Nextcloudquartobot

                for i in *.qmd; do
                    echo "Found file $i"
                        timestamp=$(date "+%Y-%m-%d--%H-%M-%S")
                        echo "Trying to run 'quarto render $i'..."
                        /sbin/quarto render "$i";
                        echo "Moving .qmd-file..."
                        mv "$i" "$i-$timestamp"
                done
        else
                echo "Nothing to do..."
        fi
        echo "Sleeping for 30 seconds."
        sleep 30
done

/etc/systemd/system/quarto-nextcloud-bot.service

[Unit]
Description=quarto-Nextcloud-RenderBot
Wants=media-Nextcloudquartobot.mount

[Service]
Type=simple
Nice=19
IOSchedulingClass=idle
ExecStart=/bin/bash -c "PATH=$PATH exec /pfad/zu/quarto-nextcloud.sh"
User=produnis

[Install]
WantedBy=multi-user.target

sudo systemctl start quarto-nextcloud-bot.service
sudo systemctl stop quarto-nextcloud-bot.service
sudo systemctl enable quarto-nextcloud-bot.service

# journal laufend ausgeben
journalctl -u quarto-nextcloud-bot.service -f

Sep 23 17:40:19 SERVER bash[9086]: Sleeping for 30 seconds.
Sep 23 17:40:50 SERVER bash[9086]: Nothing to do...
Sep 23 17:40:50 SERVER bash[9086]: Sleeping for 30 seconds.
Sep 23 17:41:20 SERVER bash[9086]: Nothing to do...
Sep 23 17:41:20 SERVER bash[9086]: Sleeping for 30 seconds.

Sep 23 17:42:52 SERVER bash[9086]: Found file Hinweise-zur-Klausuraufsicht.qmd
Sep 23 17:42:52 SERVER bash[9086]: Trying to run 'quarto render Hinweise-zur-Klausuraufsicht.qmd'...
Sep 23 17:42:55 SERVER bash[9360]: pandoc 
Sep 23 17:42:55 SERVER bash[9360]:   to: latex
Sep 23 17:42:55 SERVER bash[9360]:   output-file: Hinweise-zur-Klausuraufsicht.tex
Sep 23 17:42:55 SERVER bash[9360]: running xelatex - 1
Sep 23 17:42:58 SERVER bash[9360]: running xelatex - 2
Sep 23 17:43:01 SERVER bash[9360]:   This is XeTeX, Version 3.141592653-2.6-0.999994 (TeX Live 2022) (preloaded format=xelatex)
Sep 23 17:43:04 SERVER bash[9360]: Output created: Hinweise-zur-Klausuraufsicht.pdf
Sep 23 17:43:04 SERVER bash[9086]: Moving .qmd-file...
Sep 23 17:43:05 SERVER bash[9086]: Sleeping for 30 seconds.

Mit quarto setze ich unter anderem auch meine (Geschäfts)Briefe als PDF-Datei. Hierfür habe ich mir ein paar Vorlagen gebastelt, siehe z.B. dieses Beispiel.

Das funktioniert soweit auf dem PC sehr gut. Am Handy oder am Tablet ist quarto mit nicht verfügbar, weshalb ich mir einen kleinen Bot programmiert habe, der einen Nextcloud-Ordner “überwacht” und die vorhandenen .qmd-Dateien zu PDFs rendert.

Der Bot

• mountet den Nextcloud-Ordner per Webdav

• überwacht in einem vorgegebenem Zeitintervall (30 Sek.), ob .qmd-Dateien in diesem Verzeichnis vorhanden sind

• führt den Befehl quarto render DATEI.qmd auf jede .qmd-Datei im Verzeichnis aus. Quarto legt die erzeugten PDF-Dateien ins selbe Verzeichnis.

• verschiebt die .qmd-Datei nach .qmd-TIMESTAMP. So wird sie nicht erneut gerendert.

• wartet 30 Sekunden und fängt wieder von vorne an

• wird über systemd gesteuert.

• läuft nicht als root, sondern als normaler User, in meinem Falle produnis.

So kann ich “von überall”, z.B. am Handy, eine .qmd-Datei erzeugen, diese ins Nextcloud-Verzeichnis uploaden, 30 Sekunden warten, und die fertige PDF-Datei aus dem Nextcloud-Verzeichnis herunterladen.

Der Bot kann an jedem beliebigen Linux-PC mit Internetanschluss betrieben werden. Du musst “lediglich” sicherstellen, dass der Befehl

# muss fehlerfrei durchlaufen
quarto render Datei.qmd

korrekt auf dem Server ausgeführt wird. Der Bot führt ja letztendlich auch “nur” diesen Befehl aus.

# erstelle Verzeichnis
mkdir -p /media/Nextcloudquartobot

# Webdav-Adresse
https://DEINE.NEXTCLOUD/remote.php/dav/files/USERNAME/pfad/zu/ordner

# Passwörter hinzufügen
sudo nano /etc/davfs2/secrets

# Schema
MOUNTPOINT  USERNAME "PASSWORD"

/media/Nextcloudquartobot  produnis "!SuperSecret#Password!"

sudo nano /etc/systemd/system/media-Nextcloudquartobot.mount

/etc/systemd/system/media-Nextcloudquartobot.mount

[Unit]
Description=WebDAV-Mount-Nextcloud-Quarto-Renderbot
After=network-online.target
Before=quarto-nextcloud-bot.service

[Mount]
Type=davfs
What=https://MEINE.NEXTCLOUD/remote.php/dav/files/USER/pfad/zu/ordner
Where=/media/Nextcloudquartobot
Options=noauto,user,uid=produnis,gid=produnis

[Install]
WantedBy=multi-user.target

# mounten
sudo systemctl start media-Nextcloudquartobot.mount

#unmounten
sudo systemctl stop media-Nextcloudquartobot.mount

/etc/systemd/system/media-Nextcloudquartobot.mount

#!/bin/bash

while [[ true ]]; do
        if ls /media/Nextcloudquartobot/*.qmd 1> /dev/null 2>&1; then
                cd /media/Nextcloudquartobot

                for i in *.qmd; do
                    echo "Found file $i"
                        timestamp=$(date "+%Y-%m-%d--%H-%M-%S")
                        echo "Trying to run 'quarto render $i'..."
                        /sbin/quarto render "$i";
                        echo "Moving .qmd-file..."
                        mv "$i" "$i-$timestamp"
                done
        else
                echo "Nothing to do..."
        fi
        echo "Sleeping for 30 seconds."
        sleep 30
done

/etc/systemd/system/quarto-nextcloud-bot.service

[Unit]
Description=quarto-Nextcloud-RenderBot
Wants=media-Nextcloudquartobot.mount

[Service]
Type=simple
Nice=19
IOSchedulingClass=idle
ExecStart=/bin/bash -c "PATH=$PATH exec /pfad/zu/quarto-nextcloud.sh"
User=produnis

[Install]
WantedBy=multi-user.target

sudo systemctl start quarto-nextcloud-bot.service
sudo systemctl stop quarto-nextcloud-bot.service
sudo systemctl enable quarto-nextcloud-bot.service

# journal laufend ausgeben
journalctl -u quarto-nextcloud-bot.service -f

Sep 23 17:40:19 SERVER bash[9086]: Sleeping for 30 seconds.
Sep 23 17:40:50 SERVER bash[9086]: Nothing to do...
Sep 23 17:40:50 SERVER bash[9086]: Sleeping for 30 seconds.
Sep 23 17:41:20 SERVER bash[9086]: Nothing to do...
Sep 23 17:41:20 SERVER bash[9086]: Sleeping for 30 seconds.

Sep 23 17:42:52 SERVER bash[9086]: Found file Hinweise-zur-Klausuraufsicht.qmd
Sep 23 17:42:52 SERVER bash[9086]: Trying to run 'quarto render Hinweise-zur-Klausuraufsicht.qmd'...
Sep 23 17:42:55 SERVER bash[9360]: pandoc 
Sep 23 17:42:55 SERVER bash[9360]:   to: latex
Sep 23 17:42:55 SERVER bash[9360]:   output-file: Hinweise-zur-Klausuraufsicht.tex
Sep 23 17:42:55 SERVER bash[9360]: running xelatex - 1
Sep 23 17:42:58 SERVER bash[9360]: running xelatex - 2
Sep 23 17:43:01 SERVER bash[9360]:   This is XeTeX, Version 3.141592653-2.6-0.999994 (TeX Live 2022) (preloaded format=xelatex)
Sep 23 17:43:04 SERVER bash[9360]: Output created: Hinweise-zur-Klausuraufsicht.pdf
Sep 23 17:43:04 SERVER bash[9086]: Moving .qmd-file...
Sep 23 17:43:05 SERVER bash[9086]: Sleeping for 30 seconds.

Do, 22. September 2022, Lioh Möller

Microsoft machte vor einiger Zeit Furore, weil durch ein Windows Update UEFI Secure Boot Signaturen zurückgezogen wurden, was dazu führen konnte, dass einige ältere Linux-Distributionen nicht mehr starten.

Dieses sogenannte DBX (Secure Boot Forbidden Signature Database) Update steht nun auch für den Linux Vendor Firmware Service (LVFS) zur Verfügung.

Die mittels fwupd installierbare Aktualisierung, prüft allerdings, ob keinerlei betroffener Bootcode in einer ESP (EFI System Partition) liegt und führt die Aktualisierung nur dann aus, wenn dies der Fall ist.

So ist sichergestellt, dass ein Einspielen des Updates nicht zu einem nicht mehr startenden System führt. Darüber hinaus gewinnen Linux-Distributionen Zeit, ein entsprechendes Update bereitzustellen, sollte dies noch nicht der Fall sein.

Danke an Thorsten Leemhuis für den Hinweis.

Eigentlich wollte ich Kubuntu 22.04 dieses Frühjahr gegen openSUSE austauschen. Das habe ich dann doch nicht gemacht, weil ich die betroffenen Anwender nicht kurz vor einer größeren Transformation mit openSUSE vertraut machen wollte. Stattdessen bin ich sogar selbst zu Kubuntu zurück und ziemlich zufrieden.

Ich hatte mich wirklich auf openSUSE Leap 15.4 gefreut. Endlich Hardware-Unterstützung für mein Notebook und weg vom Rolling Release-Modell Tumbleweed. Leider gab es dann für mich persönlich ein paar zu viele Probleme, die teilweise erst rund um die Veröffentlichung auftraten. Bei Dracut hatten die openSUSE-Entwickler vergessen, dass der usr-merge bei Leap noch nicht vollzogen ist, weshalb wochenlang mein Bluetooth nicht ging, weil der Treiber nicht integriert wurde. Zudem harmoniert Vorta nicht mit der Python-Version (Bug #1199080) und das von mir gerne genutzt systemd-homed hat man auch nicht richtig integriert (Bug #1199804). Außerdem gibt es einen seltsamen Fehler im Autologin, der mich alle circa 10 Logins vor einem schwarzen Bildschirm sitzen ließ. Nein, das war dann doch ein bisschen viel des Guten. Ich brauche gerade wirklich ein System ohne Probleme und bin deshalb mit meinem Arbeitsgerät kurzerhand auf Kubuntu umgestiegen.

Das habe ich nicht bereut. Kubuntu 22.04 läuft sehr stabil. Das gilt natürlich auch für Ubuntu, da der Unterschied ja nur in der Desktopoberfläche liegt. Seit dem Jammertal 16.04 hat man sich konsequent verbessert und mit 22.04 ein wirkliches gutes Release herausgebracht. Das liegt natürlich auch daran, dass KDE Plasma am Ende des Qt5-Zyklus steht und die KDE-Entwickler deshalb ihr Lieblingshobby, Verschlimmbesserungen vorzunehmen, auf den Qt6/KF6-Zweig konzentrieren. Es gibt keine mich störenden Bugs – was natürlich nicht heißt, dass es keine Bugs gibt.

Kubuntu 22.04 wurde für mich persönlich eine Option als Canonical das bei Release fehlende systemd-cryptentoll nachträglich für die Ubuntu-Basis aktiviert hat (man ist dort halt nicht dogmatisch und korrigiert solche Sachen auch nach dem Release), wodurch ich mein System mit meinem Yubikey entsperren kann. Das war für mich bis dahin ein Grund an openSUSE Tumbleweed festzuhalten.

LTS-Distributionen sind für mich einfach die bessere Wahl. Die Basis mag von den Versionen her veralten, aber das tangiert meinen Arbeitsablauf nicht. Die wesentlichen Aktualisierungen meiner Arbeitsprogramme erhalte ich sowieso nicht aus den Paketquellen. SoftMaker Office, Zotero, Synology-Tools, Transkribus – alles Sachen, die per Drittanbieter eingebunden sein müssen, weil kaum eine Distribution sie in den Quellen hat. Hier bietet Ubuntu sogar richtige Vorteile, weil das alle Entwickler kennen und unterstützen wollen bzw. müssen. Andere Sachen wie KDE Plasma oder VirtualBox werden zumindest momentan ziemlich konsequent via SRU aktualisiert, was für mich eine wirklich positive Überraschung ist. Der Rest der Basis ist mir eigentlich egal: Welche Version Dolphin hat oder ob Okular in Version 21.12 oder 22.04 vorliegt – wen interessiert das schon? Ich verfolge die KDE-Updatemeldungen und sehe dort nichts, was den Arbeitsaufwand eines Rolling Release für mich rechtfertigen würde.

Kubuntu 22.04 ist wirklich eine gute Veröffentlichung geworden. Für mich genau zur richtigen Zeit. Mal sehen wo der Linux-Desktop 2024 steht.

Mozilla hat Firefox 105 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Text ohne Formatierung einfügen

In Textfeldern, welche Formatierungen erlauben, gibt es im Kontextmenü neben der bisher bereits vorhandenen Option, kopierten Text einzufügen, ab sofort auch noch eine weitere Option, um kopierten Text ohne Formatierung einzufügen.

Verbesserte Stabilität bei wenig verfügbarem Arbeitsspeicher

Mozilla hat nach eigenen Angaben die Stabilität auf Windows in Situationen signifikant verbessert, in denen wenig Arbeitsspeicher zur Verfügung steht. Unabhängig davon gab es auch für Linux Verbesserungen, welche dafür sorgen sollen, dass Firefox seltener der Arbeitsspeicher ausgeht.

Service Workers mit Netzwerk-Partitionierung

Das Tracking von Internet-Nutzern erfolgt heute längst nicht mehr nur über Cookies. Auch eine Vielzahl anderer Technologien wird dazu missbraucht, um Nutzer seitenübergreifend zu verfolgen. Um dies zu erschweren und die Privatsphäre der Nutzer weiter zu verbessern, hatte Mozilla mit Firefox 85 die sogenannte Netzwerk-Partitionierung eingeführt. Dadurch werden Ressourcen, welche bislang in einem gemeinsamen Pool gespeichert worden sind, auf Website-Basis isoliert. Während diese bereits einige Bereiche abdeckte, galt dies für sogenannte Service Workers bislang nicht. Firefox 105 partitioniert Third-Party Service Workers unter der Top-Level-Domain.

Mehr Sicherheit für Firefox-Nutzer

Auch in Firefox 105 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 105 daher für alle Nutzer dringend empfohlen.

Verbesserungen der Webplattform

Die Implementierung von array.includes sowie array.indexOf ist nun doppelt so performant im Vergleich zu vorher.

Die Unterstützung der Offscreen Canvas DOM API wurde hinzugefügt.

Zusätzliche optionale Argumente wurden zu den performance.mark- und performance.measure-Methoden hinzufügt, um benutzerdefinierte Start- und Endzeiten, Dauer und angehängte Details bereitzustellen.

Weitere Neuerungen für Web- und Erweiterungsentwickler lassen sich wie immer in den MDN Web Docs nachlesen.

Sonstige Neuerungen von Firefox 105

Auf Geräten mit Windows wird nun eine Zwei-Finger-Geste am Touchpad unterstützt, um zurück oder vorwärts zu navigieren.

Auf Apple macOS wurde das Scrollen mit dem Touchpad zugänglicher gemacht, indem das unbeabsichtigte diagonale Scrollen entgegen der beabsichtigten Scrollachse reduziert wurde.

Die Seiten-Auswahl in der Druckvorschau hat die Option erhalten, nur die aktuell ausgewählte Seite auszudrucken.

Bei Verwendung einer benutzerdefinierten Startseite wird beim Öffnen neuer Fenster ab sofort die Adressleiste fokussiert. Update 22.9.2022: Diese Änderung wurde mit Firefox 105.0.1 zurückgenommen.

Die Passwortverwaltung erlaubt jetzt auch wieder das Speichern von Proxy-Zugangsdaten (moz-proxy://-URIs).

Ein Fehler wurde behoben, der verursachte, dass bei Verwendung der separaten Suchleiste keine OpenSearch-Suchmaschine hinzugefügt werden konnte, wenn es nicht bereits mindestens eine aktivierte Suchmaschine gab.

Die Treiber-Version 22.2 oder höher vorausgesetzt, ist nun für alle Linux-Nutzer mit Mesa-Treiber das gegenüber der Software-Implementierung performantere Hardware-WebRender aktiv. Auf Linux-Systemen mit ARM-CPU wird außerdem nun GLES anstelle vom Desktop-GL als Grafik-Schnittstelle bevorzugt, da entsprechende Geräte häufig dafür besser optimiert sind.

Firefox auf Windows zeigt auf der Seite about:support jetzt die unterstützten Media-Codecs an und ob diese durch die Hardware beschleunigt wiedergegeben werden oder nicht.

Bei den Entwickler-Werkzeugen für den Browser handelt es sich ab sofort um die Multiprozess-Implementierung, welche die Inspektion sämtlicher Browser-Ressourcen erlaubt. Eine neue Modus-Auswahl ermöglicht außerdem den Wechsel zwischen dem performanteren Modus nur für den übergeordneten Firefox-Prozess und dem etwas langsameren Modus, der dafür alle Prozesse beinhaltet.

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