staging.inyokaproject.org

10. März 2022

Die MZLA Technologies Corporation hat mit Thunderbird 91.7 ein planmäßige Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.7

Mit dem Update auf Thunderbird 91.7 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit aktuelle Sicherheitslücken. Darüber hinaus bringt das Update diverse Fehlerbehebungen der Versionsreihe 91, welche sich in den Release Notes (engl.) nachlesen lassen.

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

Do, 10. März 2022, Stephan Schultze

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-basierten Shell Dialogen und Skripten.


Der Quellcode ist auf GitHub bereitgestellt: https://github.com/MichaIng/DietPi
Die DietPi Webseite finden Sie unter: https://dietpi.com/

Die Highlights dieser Version sind:

  • Neue Images für virtuelle Maschinen unter VMware ESXi/vSphere, Proxmox, UTM sowie Hardkernel's Odroid C4/HC4 Einplatinencomputer wurden veröffentlicht.
  • Die Kubernetes-Plattform MicroK8s von Canonical wurde als Software-Option hinzugefügt.
  • Die audiophile Weboberfläche von Allo.com für Raspberry Pi und Sparky SBC hat ein umfangreiches Upgrade erhalten. Dabei wurden viele Probleme und Sicherheitsaspekte behoben und die zugrunde liegenden Laravel-Abhängigkeiten auf die neuesten Versionen aktualisiert.
  • Die Benutzer werden nun darauf hingewiesen, wenn ein Neustart erforderlich ist, um ein aktuelles Kernel-Upgrade abzuschliessen, wodurch sichergestellt wird, dass Software-Installationen und andere System-Wartungsaufgaben bei Bedarf Kernelmodule laden können.

Die kompletten Versionshinweise finden Sie unter: https://dietpi.com/docs/releases/v8_2/

9. März 2022

Mi, 9. März 2022, Fabian Schaar

Im Dschungel der vielen, vielen GNU/Linux-Distributionen finden sich nur sehr wenige, die den Idealen freier Software vollkommen konsequent entsprechen. Die Free Software Foundation informiert auf ihrer Website über die Abwandlungen des Betriebssystems, die dem Gedanken freier Software am nächsten kommen. Eine dieser Distributionen ist Trisquel GNU/Linux.

Als Richard Stallman in den 80er Jahren das GNU-Projekt initiierte, war sein erklärtes Ziel die Entwicklung eines vollkommen freien Betriebssystems. Bis heute hat sich daran nicht sonderlich viel geändert, anders als in der GNU/Linux-Szene: An Stelle von „Freier Software“ setzte sich zunehmend die Begrifflichkeit „Open Source“ durch; die Gemeinschaft öffnete sich kommerzieller Akteure wie RedHat und Distributionen wie Ubuntu, die einfache Benutzung in den Vordergrund stellten und stellen nahmen immer mehr Fahrt auf. Die Liste der Distributionen zählt heute hunderte von Einträgen, hunderte mehr oder minderverschiedene Betriebssysteme – vollkommen frei sind allerdings nur die wenigsten.

Trisquel GNU/Linux ist kein Neuling in der Distro-Landschaft, immerhin wird das Projekt schon seit 2007 entwickelt – während die erste Version noch auf Debian 4 aufsetzte, wechselte das Projekt relativ schnell zur Ubuntubasis. In dieser Hinsicht scheint Trisquel die Einfachheit und Nutzerfreundlichkeit von Ubuntu mit der konsequenten Umsetzung der Ideale freier Software kombinieren zu wollen. Die randvollen Repositories mit einer Aktualität auf dem Stand von Ubuntu 20.04 LTS veranlassten mich dazu, dem Projekt eine Chance zu geben – nicht nur auf einer virtuellen Maschine, sondern auf echter Hardware.

Kurzerhand habe ich also meine wichtigsten Dateien zusammengepackt, einen Livestick mit Trisquel GNU/Linux erstellt und installiert. Die Installation war hierbei wirklich einfach, immerhin setzt Trisquel standardmäßig auf den Ubiquity-Installer von Ubuntu. Nach der Installation begrüsst Trisquel neue Nutzer*innen mit einem doch sehr ansprechenden Desktop, standardmäßig ist das Mate. Mit seinem dicken Panel schafft die Distro eine praktische Oberfläche, natürlich nichts Extravagantes; aber doch praktisch. Wer die voreingestellten Pastellfarben des leicht angepassten Greybird-Themas („Trisquel“) nicht mag, kann neue installieren oder die CSS-Dateien der Themen anpassen. Trisquel bedient sich bekannter und beliebter Konzepte, schafft ein angenehmes Nutzungserlebnis und tauscht seine Ideale nicht gegen Bequemlichkeit.

Die Entwicklung des Betriebssystems kann als Dekommerzialisierung Ubuntus zugunsten der Freiheit der Nutzer*innen gesehen werden: Das Projekt stützt sich auf die Community und deren Spenden und ist organisiert als Non-Profit-Organisation.

Eine Besonderheit ist, wie oben schon erwähnt, die Auswahl der Software. Anstatt des Browsers Firefox kommt dessen augenscheinliche Abwandlung „Abrowser“ daher, aktuell in Version 97. Mozillas Thunderbird wird ersetzt durch IceDove, diese Bezeichnung könnte alt eingesessenen Debian-Nutzer*innen bekannt vorkommen. Was die Nutzung auswirkt, ergeben sich durch die Abwandlungen kaum merkliche Unterschiede.

Bemerkenswert finde ich den Appstore, den Trisquel mitbringt: Hier haben die Distributor*innen eine angenehme, grafische Oberfläche zu schaffen. Über die Anwendung lassen sich leicht klassische .deb-Pakete aus den Repos installieren. Flatpak und Ubuntus Snap sind nicht vorinstalliert.

Die Softwareverwaltung ist gewohnt einfach, sie entspricht dem Standard bei debianbasierten Systemen. Wegen der geringen Verbreitung der Distro sind die Mirrors etwas weit entfernt und standardmäßig etwas behäbig, zumindest im deutschsprachigen Raum, wirklich schlimm ist das nicht.

Trisquels Alleinstellungsmerkmal ist und bleibt der besondere Fokus auf der Freiheit der Software. In der Folge werden keinerlei unfreie Anwendungen, Treiber usw. unterstützt. Um das WLAN auf dem Laptop zum Laufen zu kriegen, musste ich daher über die iwlwifi-firmware als .deb über Gdebi installieren. Hier ist Trisquel allerdings auch nicht sonderlich anders als die offizielle Ausgabe von Debian, die auch keine unfreien Pakete beinhaltet.

Meinen ersten Eindrücken zufolge ist Trisquel eine der vollkommen freien Distros, die verhältnismässig leicht genutzt werden können. Die Mission, die das Projekt im Sinne freier Software verfolgt, ist in der unübersichtlichen GNU/Linux-Szene doch bemerkenswert.

Sicher fragen sich jetzt die ein oder anderen, warum eine solche Distro überhaupt genutzt werden sollte, wenn man am Ende doch auf unfreie Firmware für das WLAN angewiesen ist. Diese Frage ist natürlich gerechtfertigt. Und doch sehe ich digitale Rechte mit Trisquel besser verteidigt als mit anderen GNU/Linux-Varianten, besser als bei denen, die gerne mal auf das„GNU“ im Namen verzichten. Trisquel hat sich als Projekt der freien Desktop-Software verschrieben, hat also ein konkretes Ziel. Bei anderen ist das nur eine Nebensache.

Meiner Ansicht nach kann es nicht schaden, wenn unfreie Software aus dem System so gut wie es geht fern gehalten wird. Weitere Beispiele, wo das Konzept gut aufgeht, sind Abrowser und IceDove. Allen, die auf unfreie Software verzichten wollen und können, kann ich Trisquel ans Herz legen. Zumindest in einer virtuellen Maschine ist das Ganze einen Versuch wert.

Trisquel erhält die Vision des GNU-Betriebssystems aufrecht. Eine Vision, die nicht vergessen werden sollte. Die Vision, dass sich die Anwender*innen von Software selbst befreien können.

Quelle: https://trisquel.info/de

8. März 2022

Di, 8. März 2022, Lioh Möller

Das FreedomBox Projekt hat neue Images für die Nutzung auf Raspberry Pi Geräten bereitgestellt. Bisher war eine Installation von FreedomBox auf dem Raspberry Pi 4 nur über Umwege mithilfe des allgemeinen arm64 Images möglich.

Die neuen Abbilder eignen sich für Raspberry Pi 3B, Raspberry Pi 3B+ und Raspberry Pi 4B und sind für die arm64 Architektur optimiert worden. Sie beinhalten die Raspberry Pi Boot- und Wi-Fi-Firmware. Während der Einrichtung wird automatisch ein WLAN-Netzwerk konfiguriert, was den Zugriff auf die FreedomBox zur Einrichtung deutlich vereinfacht.

Ankündigung: https://discuss.freedombox.org/t/new-64-bit-images-for-raspberry-pi-3b-3b-and-4b/1971
Download: https://freedombox.org/download/

Da ich tmux (Alternative zu screen) sehr häufig benutze, nutze ich auch bei remote ssh logins einen Befehl, der mich nach dem erfolgreichen Login gleich in eine detachte tmux session bringt.

ssh -l <USERNAME> <HOST> -p <PORT> -t "tmux a"

Weitere Artikel zu tmux

  1. tmux – neues Fenster oder Pane im aktuellen Verzeichnis öffnen
  2. tmux ein Windowmanager für die Konsole
  3. Live-Anzeige der Webserver-Client Verbindungen
  4. Eine tmux.conf Konfiguration

The post Beim ssh login tmux aufrufen first appeared on Dem hoergen Blog.

7. März 2022

Herzlich Willkommen zu Teil 4 meines Wochenend-Projekts „Nextcloud im Container“. Diesem gingen die folgenden Teile voraus:

  1. Der Plan
  2. Die Ansible-Rolle
  3. NGINX als Reverse-Proxy

Nach Teil 3 habe ich die Zwei-Faktor-Authentisierung über TOTP für meine Nutzerkonten aktiviert, die Bookmark-, Calendar- und Contact-App installiert bzw. aktiviert, ein paar Kalendertermine erstellt und ein paar Dateien hochgeladen. Nichts Wichtiges. Lediglich ein paar Daten, die ich nach einem Backup zerstören kann, um anschließend den Restore-Prozess zu testen. Zuvor möchte ich aber noch ein paar Dinge festhalten, die mir bisher aufgefallen sind.

Background jobs: Cron does not run

In den Grundeinstellungen der Nextcloud werden Hintergrund-Aufgaben konfiguriert. Diese sind laut des dortigen Hinweises wichtig, um die optimale Geschwindigkeit zu erreichen:

Um die optimale Geschwindigkeit zu erreichen ist es wichtig, dass die Hintergrund-Aktivitäten richtig konfiguriert sind. Für größere Installationen ist ‚Cron‘ die empfohlene Einstellung. Weitere Informationen findest Du in der Dokumentation.

Grundeinstellungen in den Nextcloud-Einstellungen

Die Überschrift ist der Titel des GitHub-Issues #1695. Dieser beschäftigt sich damit, dass Cron in der Container-Instanz nicht läuft. Halt genau so, wie Cron dies bei mir auch nicht tut.

Der Benutzer beryl03, welcher den Issue eröffnet hat, beschreibt, dass Cron in der Container-Instanz nicht verfügbar ist und er in der Dokumentation keinen Hinweis darauf gefunden hat. Um das Problem zu mitigieren hat beryl03 einen Cronjob auf seinem Container-Host konfiguriert, welcher sich mit der Container-Instanz verbindet und darin die Datei cron.php ausführt. Welch elender Workaround. Aber immerhin gibt es einen. Denn die Hintergrund-Aufgaben mit AJAX auszuführen, scheitert leider ebenfalls. Schade, so habe ich mir das tatsächlich nicht vorgestellt.

Im Verlauf von Issue #1695 wird darauf hingewiesen, dass zur Verwendung von Cron ein weiterer Container benötigt wird (siehe [3]). Dies wird in den Beispielen zu den Compose-Dateien beschrieben (siehe [4]). Da ich Podman und Ansible statt Docker-Compose verwende, habe ich mir diese Beispiele natürlich nicht angesehen. Das ist dem Projekt nicht anzulasten, da ich mich ja bewusst für einen anderen Weg entschieden habe. Doch denke ich, dass man das Thema Hintergrund-Aufgaben innerhalb der Projekt-Dokumentation als auch in der Nextcloud-Dokumentation etwas ausführlicher behandeln könnte und sollte. Doch wie gehe ich nun mit dem Problem um, dass meine Hintergrund-Aufgaben nicht ausgeführt werden?

Docker-Compose mit Podman nutzen

Tatsächlich habe ich einen Artikel gefunden, welcher beschreibt, wie man Docker-Compose ab Podman 3.0 nutzen kann. Allerdings bietet dieser nur eine Lösung für den Fall, dass man Podman als User root bzw. mit Root-Rechten ausführt. Da Podman bei mir rootless läuft, kommt die Lösung für mich nicht in Frage.

Nach etwas weiterer Recherche habe ich einen RFE gefunden, welcher diese Funktionalität auch für rootless-Podman fordert. Die gute Nachricht lautet, dass diese Funktion mit Podman 3.2 veröffentlicht wurde. Pech für mich, dass unter Debian stable lediglich Podman 3.0.1 in den Quellen verfügbar ist.

Ein Workaround ist besser als gar keine Lösung

Tatsächlich erscheint mir aktuell der Workaround von beryl03 (siehe [1]) der beste Weg zu sein, um die Hintergrund-Aufgaben ausführen zu lassen. Dazu führe ich auf meinem Container-Host folgenden Befehl aus:

$ podman exec -u 33 -t nextcloud php -f /var/www/html/cron.php

Damit wird das Skript cron.php innerhalb der Container-Instanz mit der Nextcloud ausgeführt. Mit -u 33 wird die UID von www-data innerhalb der Container-Instanz angegeben. Für eine genaue Erklärung des Befehls und seiner Optionen siehe podman-exec(1).

Hintergrund-Aufgaben wurden erfolgreich ausgeführt.
Die Hintergrund-Aufgaben wurden nun erfolgreich ausgeführt

Da ich nicht gern lange Befehle in die Crontab schreibe, erstelle ich ein kurzes Skript namens nextcloud_cron.sh, welches obigen Befehl aufnimmt und welches ich alle 5 Minuten von Cron ausführen lasse. Damit werde ich sich noch sehr lange arbeiten, denn nicht umsonst sagen manche: „Nichts hält so lange, wie ein gutes Improvisorium.“

Fazit von Teil 4

Ich hoffe, die Artikelserie hat euch bis hierhin ein wenig unterhalten. Wer nach einer einfachen Lösung gesucht hat, bei der man ein bis zwei Container-Images aus dem Regal nimmt, ein paar Variablen mit Werten füllt, sie auf einen Container-Host provisioniert, ausführt und fertig ist, wird sicher gemerkt haben, dass er diese Lösung in dieser Artikelreihe nicht findet.

Auch ich habe mir zu Beginn nicht vorgestellt, dass es so hakelig werden würde. Schließlich soll mit Containern doch alles einfacher werden, nicht wahr? Warum mache ich also weiter und lasse das ganze Wochenend-Projekt nicht einfach fallen? Neugier, Sturheit, eine nutzbare Nextcloud-Instanz und auch ein bisschen Spaß bilden die Antwort auf vorstehende Frage. Und deshalb mache ich auch weiter. In Teil 5 wird es um Backup und Restore gehen.

Wie betreibt ihr eure Nextcloud? Mit Container oder ohne? Unter Docker, K3s, K8s, Podman, OpenShift oder einer noch ganz anderen Lösung? Lasst es mich gern in den Kommentaren wissen. Habt ihr über eure Erfahrungen in eurem eigenen Blog geschrieben, lasst mir gern einen Link hier. Macht es gut, bis nächste Woche.

Quellen und weiterführende Links

  1. Background jobs: Cron does not run #1695
  2. AJAX Background Jobs Fail After a Period of Inactivity #1442
  3. https://github.com/nextcloud/docker/issues/1695#issuecomment-1042602441
  4. https://github.com/nextcloud/docker/blob/master/.examples/docker-compose/insecure/mariadb/apache/docker-compose.yml
  5. Using Podman and Docker Compose. Podman 3.0 now supports Docker Compose to orchestrate containers. Enable Sysadmin. 2021-01-07.
  6. [RFE]Make docker-compose work with rootless podman #9169

6. März 2022

Kurz angemerkt: beim Update eines GitLab-Servers per APT trat folgende Fehlermeldung auf:

The following signatures were invalid: EXPKEYSIG 3F01618A51312F3F GitLab B.V. (package repository signing key) <packages@gitlab.com>

Der Hintergrund ist recht einfach und wird auch auf der entsprechenden Hilfeseite erklärt:

This key’s expiration was extended from 2022-03-02 to 2024-03-01. If you encounter a complaint of expiration on 2022-03-02, perform the steps in Update keys after expiry extension to incorporate the updated public key content.

So lief tatsächlich der Repository Key in der Mitte der Woche regulär aus und muss nun erneuert bzw. aktualisiert werden, da seine Laufzeit erweitert wurde. Die Anleitung, wie man den Key aktualisieren kann, wird auf besagter Hilfeseite ebenfalls zur Verfügung gestellt. Danach verläuft das Upgrade wieder wie gehabt.

[GitLab.com Issue]

Ich verwende in meinem Blog KaTeX (siehe hier) und cactus.chat (siehe hier), und beides für sich genommen funktioniert ganz gut. Ein Problem tritt dann auf, wenn KaTeX und cactus.chat gemeinsam verwendet werden.

Dann kann es passieren, dass KaTeX in dem <div>-Container von cactus.chat herumschreibt, was dazu führt, dass cactus.chat nur “Getting comments…” anzeigt, ohne diese jedoch wirklich zu laden und ohne die Chance, einen neuen Kommentar hinzuzufügen.

Die Lösung besteht darin zu verhindern, dass KaTeX den <div>-Container anfasst. Die lässt sich in 2 Schritten umsetzen…

1. cactus.chat einrahmen

Wir modifizieren /layouts/shortcodes/chat.html (siehe hier) und packen den cactus.chat-Abschnitt komplett in ein eigenes <div>:

# {{< highlight html "linenos=table,hl_lines=2 15,linenostart=1" >}}
<br>
<div class="no-katex-here">
<script type="text/javascript" src="https://latest.cactus.chat/cactus.js"></script>
<link rel="stylesheet" href="https://latest.cactus.chat/style.css" type="text/css">
<div id="comment-section"></div>
<script>
initComments({
  node: document.getElementById("comment-section"),
  defaultHomeserverUrl: "https://matrix.cactus.chat:8448",
  serverName: "cactus.chat",
  siteName: "YOUR-SITE-NAME",
  commentSectionId: "{{ index .Params 0 }}"
})
</script>
</div>
#{{< / highlight >}}

In Zeile 2 beginnt unser Container mit der Klasse "no-katex-here", und in Zeile 15 endet er.

2. KaTeX anpassen

Man kann KaTeX anweisen, bestimmte Bereiche der Seite nicht anzufassen. Dies erfolgt entweder über den Parameter ignoredTags oder ignoredClasses (siehe KaTeX-Docs). Da wir oben im Cactus-Shortcode den <div>-Container der Klasse "no-katex-here" zugewiesen haben, bedienen wir uns der letzteren Option und übergeben ignoredClasses:['no-katex-here'] beim Funktionsaufruf.

Dafür muss die Datei /layouts/partials/katex.html (siehe hier) entsprechend angepasst werden.

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/katex.min.css" integrity="sha384-MlJdn/WNKDGXveldHDdyRP1R4CTHr3FeuDNfhsLPYrq2t0UBkUdK2jyTnXPEK1NQ" crossorigin="anonymous">

<!-- The loading of KaTeX is deferred to speed up page rendering -->
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/katex.min.js" integrity="sha384-VQ8d8WVFw0yHhCk5E8I86oOhv48xLpnDZx5T9GogA/Y84DcCKWXDmSDfn13bzFZY" crossorigin="anonymous"></script>

<!-- To automatically render math in text elements, include the auto-render extension: -->
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/contrib/auto-render.min.js" integrity="sha384-+XBljXPPiv+OzfbB3cVmLHf4hdUFHlWNZN5spNQ7rmHTXpd7WvJum6fIACpNNfIR" crossorigin="anonymous" onload="renderMathInElement(document.body,{ignoredClasses:['no-katex-here']});"></script>

<script>
    document.addEventListener("DOMContentLoaded", function() {
        renderMathInElement(document.body, {
            ignoredClasses:['no-katex-here'],
            delimiters: [
                {left: "$$", right: "$$", display: true},
                {left: "$", right: "$", display: false}
            ]      
        });
    });
</script>

In Zeile 7 und 12 haben wir den Funktionsaufruf um die Option ignoredClasses:['no-katex-here'] ergänzt.


Jetzt lässt KaTeX cactus.chat in Ruhe und beides funktioniert gemeinsam.




kommentiere per [matrix]:

Ich verwende in meinem Blog KaTeX (siehe hier) und cactus.chat (siehe hier), und beides für sich genommen funktioniert ganz gut. Ein Problem tritt dann auf, wenn KaTeX und cactus.chat gemeinsam verwendet werden.

Dann kann es passieren, dass KaTeX in dem <div>-Container von cactus.chat herumschreibt, was dazu führt, dass cactus.chat nur “Getting comments…” anzeigt, ohne diese jedoch wirklich zu laden und ohne die Chance, einen neuen Kommentar hinzuzufügen.

Die Lösung besteht darin zu verhindern, dass KaTeX den <div>-Container anfasst. Die lässt sich in 2 Schritten umsetzen…

1. cactus.chat einrahmen

Wir modifizieren /layouts/shortcodes/chat.html (siehe hier) und packen den cactus.chat-Abschnitt komplett in ein eigenes <div>:

# {{< highlight html "linenos=table,hl_lines=2 15,linenostart=1" >}}
<br>
<div class="no-katex-here">
<script type="text/javascript" src="https://latest.cactus.chat/cactus.js"></script>
<link rel="stylesheet" href="https://latest.cactus.chat/style.css" type="text/css">
<div id="comment-section"></div>
<script>
initComments({
  node: document.getElementById("comment-section"),
  defaultHomeserverUrl: "https://matrix.cactus.chat:8448",
  serverName: "cactus.chat",
  siteName: "YOUR-SITE-NAME",
  commentSectionId: "{{ index .Params 0 }}"
})
</script>
</div>
#{{< / highlight >}}

In Zeile 2 beginnt unser Container mit der Klasse "no-katex-here", und in Zeile 15 endet er.

2. KaTeX anpassen

Man kann KaTeX anweisen, bestimmte Bereiche der Seite nicht anzufassen. Dies erfolgt entweder über den Parameter ignoredTags oder ignoredClasses (siehe KaTeX-Docs). Da wir oben im Cactus-Shortcode den <div>-Container der Klasse "no-katex-here" zugewiesen haben, bedienen wir uns der letzteren Option und übergeben ignoredClasses:['no-katex-here'] beim Funktionsaufruf.

Dafür muss die Datei /layouts/partials/katex.html (siehe hier) entsprechend angepasst werden.

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/katex.min.css" integrity="sha384-MlJdn/WNKDGXveldHDdyRP1R4CTHr3FeuDNfhsLPYrq2t0UBkUdK2jyTnXPEK1NQ" crossorigin="anonymous">

<!-- The loading of KaTeX is deferred to speed up page rendering -->
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/katex.min.js" integrity="sha384-VQ8d8WVFw0yHhCk5E8I86oOhv48xLpnDZx5T9GogA/Y84DcCKWXDmSDfn13bzFZY" crossorigin="anonymous"></script>

<!-- To automatically render math in text elements, include the auto-render extension: -->
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/contrib/auto-render.min.js" integrity="sha384-+XBljXPPiv+OzfbB3cVmLHf4hdUFHlWNZN5spNQ7rmHTXpd7WvJum6fIACpNNfIR" crossorigin="anonymous" onload="renderMathInElement(document.body,{ignoredClasses:['no-katex-here']});"></script>

<script>
    document.addEventListener("DOMContentLoaded", function() {
        renderMathInElement(document.body, {
            ignoredClasses:['no-katex-here'],
            delimiters: [
                {left: "$$", right: "$$", display: true},
                {left: "$", right: "$", display: false}
            ]      
        });
    });
</script>

In Zeile 7 und 12 haben wir den Funktionsaufruf um die Option ignoredClasses:['no-katex-here'] ergänzt.


Jetzt lässt KaTeX cactus.chat in Ruhe und beides funktioniert gemeinsam.




kommentiere per [matrix]:

5. März 2022

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

Neuerungen von Thunderbird 91.6.2

Mit dem Update auf Thunderbird 91.6.2 hat die MZLA Technologies Corporation ein Update außer der Reihe für seinen Open Source E-Mail-Client veröffentlicht und behebt damit eben jene kritische Sicherheitslücken, die heute auch in Firefox 97.0.2 respektive Firefox ESR 91.6.1 behoben worden sind. Außerdem wurde noch das Problem behoben, dass temporäre Dateien aus geöffneten Dateianhängen mit zu hohen Berechtigungen gespeichert worden sind.

Der Beitrag Sicherheits-Update Thunderbird 91.6.2 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mozilla hat mit Firefox 97.0.2 ein wichtiges Sicherheits-Update für seinen Browser veröffentlicht. Dieses behebt zwei Sicherheitsprobleme, von denen bekannt ist, dass diese bereits ausgenutzt werden.

Mit dem Update auf Firefox 97.0.2 reagiert Mozilla innerhalb kürzerster Zeit nach Bekanntwerden auf zwei kritische Sicherheitslücken. Wie wichtig dieses Update ist, zeigt sich neben der untypischen Veröffentlichung eines Updates am Wochenende vor allem daran, dass noch ein Update für Firefox 97 veröffentlicht worden ist, obwohl bereits in drei Tagen Firefox 98 veröffentlicht werden wird. Nach Angaben von Mozilla liegen Berichte vor, nach denen beide Sicherheitslücken bereits aktiv ausgenutzt werden.

Auch Firefox ESR ist betroffen. Dort wurden die Sicherheitslücken mit dem Update auf Firefox ESR 91.6.1 behoben.

Der Beitrag Kritisches Sicherheits-Update: Mozilla veröffentlicht Firefox 97.0.2 erschien zuerst auf soeren-hentzschel.at.

3. März 2022

Do, 3. März 2022, Lioh Möller

Die kommende Version der openSUSE Leap Distribution 15.4 hat den Beta-Status erreicht. Interessierte Anwender werden gebeten, die nun vorliegende Version zu testen und mögliche Fehler zu berichten. Die finale Veröffentlichung ist für den 8. Juni 2022 geplant.

Im Gegensatz zu früheren Versionen der 15er-Serie bringt Version 15.4 eine Vielzahl von Aktualisierungen mit sich. So sind Qt 5, Plasma, GNOME, und Enlightenment in neueren Versionsständen enthalten. Aktuell arbeiten die Entwickler noch an einem vereinfachten Weg, um H.264 und gstreamer Plugins installieren zu können.

Darüber hinaus wird parallel zur Version 15.4 erstmals eine MicroOS Variante von Leap angeboten werden. Dabei handelt es sich um eine Immutable Linux-Distribution, ähnlich wie Fedora Silverblue. Eine erste installierbare Version, soll in Kürze zur Verfügung stehen.

Download: https://get.opensuse.org/testing/
Ankündigung: https://news.opensuse.org/2022/03/02/leap-reaches-beta-build-phase/

Meinem Blog fehlt noch eine Kommentarfunktion, und HUGO bietet mir mehrere Möglichkeiten, dieses Vorhaben umzusetzen.

Eine davon ist Cactus Chat, welche das Matrix-Protokoll verwendet um die Kommentare bereitzustellen. Da schlägt das Herz des Datenveganers höher!

1. Matrix-Account erstellen

Ihr benötigt also einen Matrix-Account, um Cactus verwenden zu können.

2. Cactus klarmachen

Für den Anfang könnt ihr den bereitgestellten öffentlichen Service nutzen, oder aber cactus selbst installieren und hosten.

Startet eine Unterhaltung mit @cactusbot:cactus.chat. Sobald beide im Raum sind setzt ihr folgenden Befehl als Chatnachtricht ab:

register YOUR-SITE-NAME

wobei YOUR-SITE-NAME ein eindeutiger Name sein muss (es geht hier aber nicht um eurer tatsächlichen Servernamen oder URL). Ich hab mal produnistest gewählt:

register produnistest

Der Bot wird eure Seite registrieren und euch in den Raum #comments_YOUR-SITE-NAME:cactus.chat einladen, in meinem Falle #comments_produnistest:cactus.chat. Dieser gilt als Haupt-Moderationsraum.

3. In HUGO einbinden

Im Ordner /layouts/shortcodes/ erzeugt ihr die Datei chat.html und gebt ihr folgenden Inhalt:

<br>
<script type="text/javascript" src="https://latest.cactus.chat/cactus.js"></script>
<link rel="stylesheet" href="https://latest.cactus.chat/style.css" type="text/css">
<div id="comment-section"></div>
<script>
initComments({
  node: document.getElementById("comment-section"),
  defaultHomeserverUrl: "https://matrix.cactus.chat:8448",
  serverName: "cactus.chat",
  siteName: "YOUR-SITE-NAME",
  commentSectionId: "{{ index .Params 0 }}"
})
</script>

wobei ihr YOUR-SITE-NAME entsprechend ersetzen müsst.

Dieser Shortcode kann nun innerhalb der Posts aufgerufen werden mittels:

   {{< chat RAUMNAME >}}

wobei RAUMNAME ein frei wählbarer Name ist. Wenn RAUMNAME in allen Posts gleich ist, steht unter jedem Post der selbe Chatverlauf. Es bietet sich daher an, für jeden Post einen eigenen Raum zu erstellen. Das geht ganz einfach. Sobald die Seite das erste mal aufgerufen wird (z.B. als Preview), erfolgt die Raumerstellung automatisch anhand der Angaben im Shortcode. Die Kommentarfunktion funktioniert dann bereits auch im Preview. Anschließend solltet ihr selbst mit eurem Matrix-Account dem Raum beitreten, sonst könnt ihr die Beiträge nicht moderieren. Hierbei folgt die Notation der Comment-Räume dem Schema:

    #comments_YOUR-SITE-NAME_RAUMNAME:cactus.chat

Also z.B.

    #comments_produnistest_testraum:cactus.chat

Das funktioniert hier direkt auf Anhieb. Im nächsten Schritt werde ich Peter mal darauf anfixen, Cactus selbst zu hosten.

Links




kommentiere per [matrix]:

Meinem Blog fehlt noch eine Kommentarfunktion, und HUGO bietet mir mehrere Möglichkeiten, dieses Vorhaben umzusetzen.

Eine davon ist Cactus Chat, welche das Matrix-Protokoll verwendet um die Kommentare bereitzustellen. Da schlägt das Herz des Datenveganers höher!

1. Matrix-Account erstellen

Ihr benötigt also einen Matrix-Account, um Cactus verwenden zu können.

2. Cactus klarmachen

Für den Anfang könnt ihr den bereitgestellten öffentlichen Service nutzen, oder aber cactus selbst installieren und hosten.

Startet eine Unterhaltung mit @cactusbot:cactus.chat. Sobald beide im Raum sind setzt ihr folgenden Befehl als Chatnachtricht ab:

register YOUR-SITE-NAME

wobei YOUR-SITE-NAME ein eindeutiger Name sein muss (es geht hier aber nicht um eurer tatsächlichen Servernamen oder URL). Ich hab mal produnistest gewählt:

register produnistest

Der Bot wird eure Seite registrieren und euch in den Raum #comments_YOUR-SITE-NAME:cactus.chat einladen, in meinem Falle #comments_produnistest:cactus.chat. Dieser gilt als Haupt-Moderationsraum.

3. In HUGO einbinden

Im Ordner /layouts/shortcodes/ erzeugt ihr die Datei chat.html und gebt ihr folgenden Inhalt:

<br>
<script type="text/javascript" src="https://latest.cactus.chat/cactus.js"></script>
<link rel="stylesheet" href="https://latest.cactus.chat/style.css" type="text/css">
<div id="comment-section"></div>
<script>
initComments({
  node: document.getElementById("comment-section"),
  defaultHomeserverUrl: "https://matrix.cactus.chat:8448",
  serverName: "cactus.chat",
  siteName: "YOUR-SITE-NAME",
  commentSectionId: "{{ index .Params 0 }}"
})
</script>

wobei ihr YOUR-SITE-NAME entsprechend ersetzen müsst.

Dieser Shortcode kann nun innerhalb der Posts aufgerufen werden mittels:

   {{< chat RAUMNAME >}}

wobei RAUMNAME ein frei wählbarer Name ist. Wenn RAUMNAME in allen Posts gleich ist, steht unter jedem Post der selbe Chatverlauf. Es bietet sich daher an, für jeden Post einen eigenen Raum zu erstellen. Das geht ganz einfach. Sobald die Seite das erste mal aufgerufen wird (z.B. als Preview), erfolgt die Raumerstellung automatisch anhand der Angaben im Shortcode. Die Kommentarfunktion funktioniert dann bereits auch im Preview. Anschließend solltet ihr selbst mit eurem Matrix-Account dem Raum beitreten, sonst könnt ihr die Beiträge nicht moderieren. Hierbei folgt die Notation der Comment-Räume dem Schema:

    #comments_YOUR-SITE-NAME_RAUMNAME:cactus.chat

Also z.B.

    #comments_produnistest_testraum:cactus.chat

Das funktioniert hier direkt auf Anhieb. Im nächsten Schritt werde ich Peter mal darauf anfixen, Cactus selbst zu hosten.

Links




kommentiere per [matrix]:

2. März 2022

Mi, 2. März 2022, Ralf Hersel

Das Gaming Handheld SteamDeck wird mit einer neuen Version von SteamOS ausgeliefert, einer speziellen Linux-Distribution für Spielegeräte, an der Valve und Collabora seit mehreren Jahren gemeinsam arbeiten. SteamOS 3 basiert auf Arch Linux, einer Rolling-Release-Distribution, die die neueste Mesa-Version für Open-Source-Grafikbeschleunigung enthält und die auf Debian basierende Version SteamOS 2 ablöst, die für das frühere Steam Machine-Projekt verwendet wurde. SteamOS 3 ist noch nicht als eigenständige Distribution verfügbar, soll es aber in Kürze sein.


Ein Handheld-Gerät benötigt ein solides Update-Framework, daher bestand einer der wichtigsten Beiträge von Collabora zu SteamOS 3 darin, nahtlose System-Updates zu implementieren. Mit dem neuen "A/B"-Design gibt es jetzt zwei Betriebssystempartitionen mit zwei verschiedenen Versionen von SteamOS. Bei einem Upgrade wird ein neues Betriebssystem-Image auf die Partition geschrieben, die gerade nicht in Gebrauch ist, bevor das System neu gestartet wird. Ein spezielles Bootloader-Modul wählt dann automatisch das neuere Betriebssystem aus und bootet es. Wenn das Upgrade erfolgreich war, kann man das neue Betriebssystem weiter verwenden, und die vorherige Systempartition wird für das nächste Upgrade eingesetzt. Wenn die aktualisierte Version nicht erfolgreich bootet, fällt der Bootloader automatisch auf die vorherige Systempartition zurück.

Für Ihre Nicht-Gaming-Bedürfnisse ist auf dem Gerät KDE Plasma Desktop vorinstalliert, sodass man das Deck für Desktop-Aufgaben verwenden und vorhandenen Peripheriegeräte über den USB-C-Anschluss nutzen kann.

Bei normaler Nutzung ist die aktive Betriebssystempartition schreibgeschützt, um das Steam Deck so robust wie möglich zu machen. Im Gegensatz zu den meisten Spielekonsolen handelt es sich jedoch um ein vollständig offenes Gerät, das in einen Entwicklermodus umgeschaltet werden kann, in dem die Betriebssystempartition schreib- und lesbar ist und verändert werden kann. Der Paketmanager "pacman" von Arch Linux ist für die Verwendung im Entwicklermodus verfügbar.

Quelle: https://www.collabora.com/news-and-blog/news-and-events/portable-linux-gaming-with-the-steam-deck.html

1. März 2022

Mozilla wird in Kürze das Mozilla VPN in weiteren Ländern starten und damit in insgesamt 17 Ländern zur Verfügung stehen.

Mit dem Mozilla VPN bietet Mozilla in Zusammenarbeit mit Mullvad sein eigenes Virtual Private Network an und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.

Jetzt Mozilla VPN nutzen

Start in weiteren Ländern

Neben Deutschland, Österreich und der Schweiz steht das Mozilla VPN auch in Belgien, Italien, Irland, Frankreich, Kanada, Malaysia, Neuseeland, den Niederlanden, Singapur, Spanien, dem Vereinigten Königreich sowie den Vereinigten Staaten von Amerika zur Verfügung.

Beginnend mit dem 8. März expandiert Mozilla nach Schweden und nach Finnland, womit das Mozilla VPN dann in insgesamt 17 Ländern angeboten wird.

Der Beitrag Mozilla VPN startet in weiteren Ländern erschien zuerst auf soeren-hentzschel.at.

Di, 1. März 2022, Norbert Rüthers

Mit Freude habe ich heute erfahren das die Armbian-Gemeinschaft die allgemeine Verfügbarkeit von Armbian 22.02 als neueste stabile Version des Debian- und Ubuntu-basierten Betriebssystems für ARM-Geräte angekündigt hat. In dieser Version wird nun erstmals auch der Raspberry Pi unterstützt.

Bisher wurde, warum auch immer, kein einziger Raspberry unterstützt. Ich habe immer vermutet das man bei Armbian davon ausgegangen ist, dass der Raspberry ohnehin genug Unterstützung erhält, was wohl auch stimmt. Dies kann man von anderen Plattformen leider nicht behaupten, die oft schnell die Unterstützung seitens der Maintainer verlieren.

Sechs Monate nach Armbian 21.08 wird also nun mit Armbian 22.02 die erste Unterstützung für Raspberry Pi Geräte eingeführt. Das Raspberry Pi 4 Model B Board wird derzeit mit 64-Bit-Builds unterstützt, die die Kernel 5.15 LTS und 5.16 der Raspberry Pi Foundation sowie das Flash-Kernel-Tool von Debian verwenden.

Während die Unterstützung für den Raspberry Pi noch als "Work in Progress" gekennzeichnet ist, scheint es, dass die Community von Erfolgen bei der Ausführung von Armbian auf verschiedenen 64-Bit Raspberry Pi Boards berichtet, einschließlich des älteren Raspberry Pi 3 Model B und Raspberry Pi CM3 und CM4.

Aber die Arbeit an der Raspberry Pi Portierung ist noch lange nicht abgeschlossen, und die Armbian-Entwickler brauchen Ihre Hilfe, um die Community mit einer voll funktionsfähigen Portierung zu versorgen. Im Moment könnt ihr helfen, indem ihr die offiziellen Raspberry Pi-Images herunterladet (Link) und diese testet. Die Images  basieren auf Ubuntu 20.04 LTS (Focal Fossa) (nur CLI) sowie auf Ubuntu
Ob es auch schon wie bei anderen SBCs möglich ist das Image selbst zu kompilieren und damit weitere Anpassungen zu ermöglichen konnte ich noch nicht testen. Einen älteren Beitrag mit der Vorstellung von Armbian findet ihr hier

Zur Projektseite geht es hier

28. Februar 2022

Kurz notiert: Rust ist in Version 1.59 erschienen. Die spannendste Neuerung ist hierbei aus meiner Sicht die Unterstützung für Inline-Assembly-Instructions. Dabei lassen sich innerhalb von Rust-Quellcodedateien Assembly-Instructions übergeben, die so in das Kompilat übernommen werden können. Dies ist immer dann nötig, wenn bestimmte Spezialbefehle benötigt werden, welche der Compiler nicht standardmäßig ausgibt.

Manuelle Assembler-Programmierung wird bei den meisten Programmen nicht benötigt. Beispiele sind eher vor allem in der Embedded-Programmierung zu finden, wo meist direkt Interrupts konfiguriert werden, die wiederum in vielen Architekturen über spezielle Operationen eingestellt werden können. Aber auch der Einsatz von SIMD benötigt spezielle Befehle. Dies ist besonders für Bibliotheken hilfreich, die Daten parallel verarbeiten.

Klassischerweise können die Assembler-Module in .S-Dateien geschrieben werden, welche dann, ähnlich wie C-Dateien, zu .o-Objektdateien assembliert resp. übersetzt werden. Verschiedene Objektdateien, welche auch aus unterschiedlichen Programmiersprachen stammen können, lassen sich dann zu einem Programm linken. Die Option von Assembler-Sektionen innerhalb einer höheren Programmiersprache vereinfacht den Umgang allerdings deutlich. So bietet auch GNU GCC für C ein spezielles asm-Keyword an, mit dem direkt Assembler-Befehle übergeben werden können. Mehr Informationen diesbezüglich bietet die GCC-Doku.

Das Rust By Example-Handbuch bietet eine eigenen neue Sektion zur Inline Assembly mit Beispielen an. Es lässt sich erkennen, dass es einige Parallelen zum C-Äquivalent gibt, obgleich die Syntax Unterschiede aufweist. Es ist möglich, ähnlich wie bei format-Strings, Zusatzinformationen zu Variablen und Registern zu übergeben. Dabei sollte jedoch bedacht werden, dass für den asm-Code natürlich keine strenge Typsicherheit gelten kann und der Einsatz nur innerhalb von unsafe-Blöcken möglich ist.

Weitere Änderungen in der neuen Rust-Version beziehen sich auf destructuring assignments und const generics-Standards und Verschachtelungen. Die destructuring assignments können bei der Lesbarkeit helfen, da mehrere Werte auf der rechten Seite mehreren Variablen auf der linken Seite in einem Statement zugewiesen werden können. Ähnliches ist man auch schon im Python mit dem Unpacking gewohnt.

Alles in allem aus meiner Sicht ein sehr spannender Release, der besonders die Entwickler von Bibliotheken freuen wird, da weitere Optimierungsmöglichkeiten komfortabler zur Verfügung stehen.

Mo, 28. Februar 2022, Christian Imhorst

Ausser GNU/Linux gibt es noch weitere freie Betriebssysteme. Eins davon ist FreeDOS, das in diesen Tagen in Version 1.3 erschienen ist.

Blinky ist weder Fisch noch Wal und das etwas komisch guckende Maskottchen von FreeDOS. © FreeDOS Project (CC-BY-2.5)

Doch was ist DOS überhaupt und warum ist es heute noch von Bedeutung? Die Wurzeln von DOS liegen zwar in Betriebssystemen der Mainframes der 1960er Jahre. Es erreichte allerdings einen grösseren Bekanntheitsgrad, als in den 1980er Jahren die damals noch junge Firma Microsoft QDOS, Kurzform für „Quick and Dirty Operating System“, von Tim Patterson kaufte und daraus MS-DOS machte. MS-DOS wurde schliesslich mit den damals Massenmarkt tauglichen IBM-PCs ausgeliefert.


Im April 1994 erschien mit MS-DOS 6.22 die letzte eigenständige Version für PCs. Zu der Zeit war es das dominierende Betriebssystem für Einzelplatzrechner. Noch im selben Jahr hatte Jim Hall, damals Physik-Student an der Universität von Wisconsin, FreeDOS ins Leben gerufen, das heute aktiv, wenn auch langsam, als eine freie und kompatible Alternative zu MS-DOS unter der GPL 2.0 Lizenz entwickelt wird. Interessant dazu sind auch Jims Vorträge auf der Kielux zu Geschichte und Anspruch von FreeDOS, zeitgemäße Erweiterungen und Anpassungen an DOS vorzunehmen und dabei trotzdem mit MS-DOS kompatibel zu bleiben. Er hatte damals schon GNU/Linux installiert und war von den GNU-Programmen begeistert, weshalb er sich fragte: Wenn es eine Gruppe von Entwicklerinnen und Entwicklern schafft, etwas Komplexes wie Unix nachzuprogrammieren, indem sie einfach über das Internet zusammenarbeiten, warum sollte das nicht mit einem vergleichsweise simplen Betriebssystem wie DOS funktionieren?

Dass es funktioniert hat, sieht man in diesen Tagen, denn zum ersten Mal seit sechs Jahren hat FreeDOS ein grösseres Update erhalten, das es von Version 1.2 auf 1.3 bringt. Wer FreeDOS einmal virtuell zum Beispiel mit QEMU oder auf dem alten PC, der noch auf dem Dachboden verstaubt, ausprobieren möchte, benötigen eine Festplatte mit 20 MB Speicher für die Installation eines „einfachen DOS-Systems“ oder etwa 275 MB für eine „vollständige Installation mit Anwendungen und Spielen“ darunter auch viele GNU-Anwendungen, aber auch FreeDOOM und Vim. Weitere optionale Pakete befinden sich auf einer BonusCD, die man noch zusätzlich von der Webseite des Projekts herunterladen kann.

Doch wozu braucht man noch so alte Betriebssysteme? Mit der Informatik, besonders mit Software ist es Menschen gelungen, Mittel und Methoden zur Formalisierung und Automatisierung geistiger Tätigkeiten zu erzeugen. Programme, die in der DOS-Ära Handlungssysteme ersetzt oder modifiziert haben, können als Artefakte durch FreeDOS noch heute weiter verwendet werden. So trägt FreeDOS zum Erhalt eines technischen Teils der Menschheitsgeschichte bei, indem es dafür sorgt, dass Hard- oder Software, die mit einem modernen Betriebssystem nicht mehr funktioniert, immer noch lauffähig ist. Niemand braucht heute mehr VisiCalc, das erste Tabellenkalkulationsprogramm für PCs. Aber zu sehen, wie es einmal funktioniert hat, hält unsere Computergeschichte lebendig.

Ausser extreme Puristinnen oder Autoren von Fantasy-Romanen wie George R. R. Martin würde heute vermutlich niemand mit einem DOS arbeiten wollen, um Dokumente zu schreiben, Tabellen zu erstellen oder E-Mails zu bearbeiten. Dafür ist FreeDOS auch nicht gedacht. FreeDOS soll kein Paralleluniversum sein, in dem Microsoft Windows nie erfunden und weiter auf MS-DOS gesetzt hätte. FreeDOS hat aber genug Anhängerinnen und Anhänger, von der Spielerin klassischer Spiele wie Doom, Descent oder Duke Nukem über den Programmierer für veraltete Schnittstellen und Hardware, bis zur Elektroingenieurin, die sich mit Embedded-Plattformen beschäftigt, um eine Nische auszufüllen. Nicht zu vergessen wissenschaftliche Bibliotheken und Archive, die ihren Nutzerinnen und Nutzern Information von Disketten und CDs mit alten proprietären Programmen und Datenformaten bereitstellen müssen, von denen der Hersteller heute nicht mehr existiert oder das Produkt aufgeben hat. Aber auch kleine Unternehmen brauchen die Steuerung alter Fräsen in der Holzwerkstatt oder das Kassensystem nicht auszutauschen. Man kann sich im Unternehmens- oder im privaten Bereich den Upgrade-Stress sparen und diese Systeme mit einem freien Betriebssystem wie FreeDOS weiter betreiben. In diesem Bereich hat FreeDOS vielleicht eine Zukunft, um dorthin zu gehen, wo noch kein DOS zuvor gewesen ist.

27. Februar 2022

Das finnische Unternehmen Jolla geriet 2015 in massive finanzielle Schwierigkeiten und wurde maßgeblich durch eine enge Kooperation mit russischen (Staats-)Unternehmen gerettet. Wie geht es da jetzt eigentlich angesichts massiver Sanktionen gegen Russland weiter? Nur Fragen, keine Antworten.

Ich hatte mich in diesem Blog in zwei Artikeln mit der nicht sehr transparenten Finanzierungsstruktur hinter Jolla befasst:

Ein der wenigen offiziell von Jolla bekannt gegebenen Investoren war Rostelecom. Eben jener Konzern steht neben vielen anderen auf einer US-Sanktionsliste, nachdem Russland seinen völkerrechtswidrigen Angriffskrieg gegen die Ukraine vom Zaun gebrochen hat. Interessant dürften ebenfalls die Beschränkungen zum Technologieexport nach Russland sein, wobei mir nicht klar ist, ob Smartphone-Betriebssysteme darunter fallen. Wobei auch unabhängig davon die engen Wirtschaftsbeziehungen zwischen Jolla und dem russischen Staat problematisch werden dürften angesichts der Sanktionen. Schließlich war die Kooperation mit Russland und die Verwendung der angepassten Sailfish-Version Aurora OS ein wichtiges Standbein für Jolla.

Ich bin gespannt ob und wenn ja wann wir offiziell etwas von Jolla dazu hören.

Der Artikel Wie geht es eigentlich weiter mit Jolla? erschien zuerst auf [Mer]Curius

Der Kern von Android ist freie Software, aber dieser Kern hat keinen App Store. Die meisten Anwender von Aftermarket-Systemen wie LineageOS oder GrapheneOS nutzen daher F-Droid, um Open Source-Apps zu beziehen. Das ist nicht unproblematisch, aber leider alternativlos.

Via Linuxnews erreichte mich heute dieser sehr lesenswerte Artikel zu den problematischen Implikationen von F-Droid für die Sicherheit von Android. Der Autor nennt einige substanzielle Probleme von F-Droid, die ich im Folgenden knapp zusammenfassen möchte. Für die ausführliche Darstellung bitte den Artikel lesen.

  • Die Probleme beginnen schon bei den Signaturen der Apps, da F-Droid alle Apps mit seinen eigenen Keys signiert. Das untergräbt den sonst verfolgten Ansatz, dass Entwickler ihre Apps selbst signieren und der Anwender dem Vertriebskanal nicht vertrauen muss.
  • Die Apps bei F-Droid müssen frei von proprietären Bibliotheken sein und unterscheiden sich deshalb von den Varianten der gleichen App, die auf anderen Wegen bezogen werden können.
  • Die Qualitätskontrollen von F-Droid sind praktisch wertlos. Ein offener Quellcode bedeutet nicht, dass die Überprüfung leicht ist.
  • Updates werden mit teils starker Verzögerung verteilt.
  • F-Droid hinkt beim API-Level hinterher, für den Apps gebaut werden, was wiederrum negativ für die Sicherheit sein kann.
  • Mehrere Repositorien in einer einzigen App widersprechen dem Android-Sicherheitsprinzip.
  • Die neue API in Android für automatische Hintergrundaktualisierungen von Apps ohne Root-Privilegien wird mit F-Droid nicht funktionieren bzw. nur mit einem „schmutzigen“ Hack.
  • Viele kleinere Probleme, die der Autor als „mangelnde gute Praxis“ beschreibt wie z. B. fehlendes Zeritfikat-Pinning oder ganz allgemein, dass Änderungen bei F-Droid erst nachvollzogen werden, wenn sie dazu durch Änderungen in der Android-Basis gezwungen werden und nicht wenn diese bereits ratsam sind.

Einige dieser Probleme wie die Updateverzögerung, die fehlende tiefgreifende Überprüfung von Anwendungen oder die Signaturproblematik könnte man auch auf Linux-Distribution übertragen, ebenso den oft unbegründete Konnex von Open Source und Sicherheit. Das ist keineswegs ein Problem, das auf Android oder F-Droid beschränkt wäre. Andere Probleme wie das fehlende tiefergehende Verständnis für Sicherheit und laxe Praktiken kann man auch bei anderen Projekten im AOSP-Umfeld wie LineageOS, XDA & Co beobachten und wurde von mir bereits mehrfach kritisiert. Ein Grund, weshalb ich inzwischen GrapheneOS nutze.

Der Autor empfiehlt als sichere Alternative den Play Store. So mancher mag da aufschreien, aber das ist eben einer dieser Bereiche, bei denen sich Datenschutz und Sicherheit in die Quere kommen. Was für die Sicherheit geboten wäre, muss nicht zwangsläufig gut für den Datenschutz sein. Deshalb finde ich persönlich den Artikel zwar interessant und bedenkenswert, aber werde trotzdem vorerst weiter an F-Droid festhalten, denn mein GrapheneOS ist frei von Play Diensten und Play Store und es gibt aktuell keinen anderen App Store außer F-Droid.

Mittelfristig interessant könnte der „App Store“ werden, den die GrapheneOS-Entwickler in der Pipeline haben.

Hier bleibt aber abzuwarten, was der alles enthalten wird und ob das ausreicht, um auf F-Droid zu verzichten.

Der Artikel F-Droid untergräbt die Sicherheit von Android erschien zuerst auf [Mer]Curius

26. Februar 2022

Es gibt viele Distributionen, aber nur wenige Distributionen mit langfristigem Support. Doch auch zwischen diesen Distributionen gibt es erhebliche Unterschiede. Der Versuch einer kleinen Einordnung.

Natürlich können Anwender genau die Distribution verwenden, die sie bevorzugen. Das kann ein Rolling Release sein oder eine Distribution mit nur kurzer Laufzeit wie Fedora oder Mageia. Die meisten Anwender machen sich aber meiner Erfahrung nach nicht so viel aus Updates, wollen über mehrere Jahre in Ruhe ihre Systeme nutzen und bekommen neue Funktionen lieber mit einem großen Schwung. Das betrifft nicht exklusiv Linux-Anwender, sondern ich erlebe das auch bei macOS-Nutzern und Windows 10-Anwendern, wo meist erst mit deutlicher Verzögerung und kurz vor Supportende einer jeweiligen Version aktualisiert wird. Das mögen nicht mehr die 10 Jahre von früher sein, aber häufiger als alle 2-3 Jahre möchten die meisten Anwender keine umstürzenden Aktualisierungen. Sie arbeiten schließlich mit den Systemen und nicht an den Systemen.

Die hier getroffenen Abwägungen haben einen Fokus auf den Sicherheitsaspekt. Wer ideologische Gesichtspunkte höher gewichtet, kann durchaus zu anderen Ergebnissen zu kommen. Grundsätzlich respektiere ich es, wenn einem dieser Aspekt nicht so wichtig ist, da Linux gegenwärtig keinem großen Schadsoftwaredruck ausgesetzt ist und längerfristig offene Sicherheitslücken mit hoher Wahrscheinlichkeit keine direkten nachteiligen Auswirkungen auf den normalen Anwender haben. Vermutlich könnte man sogar mit einer seit Längerem abgekündigten Version ohne jegliche Sicherheitsupdates noch einige Zeit problemlos auch im Internet unterwegs sein. Doch wenn man Sicherheit ernst nimmt, dann auch konsequent.

Ich habe 2015 im freien magazin mal einen Artikel zu LTS-Distributionen für den Linux-Desktop geschrieben, der die Grundlage für den hiesigen Schwerpunkt-Bereich zu Linux wurde. Erstaunlich wenig hat sich in dem Bereich seitdem getan. Allerdings würde ich das heute teilweise anders bewerten. Da aufgrund meiner Debian-Serie mich einige gefragt haben, möchte ich das hier kurz einordnen.

Folgende Reihenfolge sehe ich bei den LTS-Distributionen. Die wesentlichen Vor- und Nachteile habe ich mal aufgelistet.

1. Red Hat Enterprise Linux & Klone

Wer gerne mit der GNOME Shell arbeitet, sollte sich RHEL oder einen der freien Klone wie Alma Linux genauer ansehen. Für diese Enterprise-Distribution gibt es keine andere Desktopumgebung, deshalb ist diese Einschränkung die maßgebliche erste Abwägung, die jeder Anwender treffen muss.

Red Hat beschäftigt wohl die meisten Entwickler im Linux- und GNOME-Umfeld in einer Firma. Die Entwicklungen aus der Red Hat-Schmiede sind heute überwiegend die Quasi-Standards im Linux-Segment. Nach einem ausführlichen Test in Fedora landen diese immer in RHEL.

RHEL bietet für Anwender einige substanzielle Vorteile:

  • RHEL folgt mit Verzögerung direkt der Upstream-Entwicklung und die Wahrscheinlichkeit, in Entwicklungssackgassen zu geraten, wie dies oft bei Canonicals Eigenentwicklungen der Fall ist, sind äußerst gering. RHEL ist deshalb für seine Anwender sehr nachhaltig. Red Hat ist ebenso in der Position, in entscheidenden Momenten Einfluss auf die GNOME-Entwicklung zu nehmen, um Enterprise-Tauglichkeit herzustellen. Das hat man in der Vergangenheit beim Classic-Mode gesehen, der genau dann kam, als der Wechsel von GNOME 2 zu GNOME Shell in RHEL anstand.
  • Red Hat besitzt die Leistungsfähigkeit, um Sicherheitsprobleme schnell und konsequent zu beheben. Das gilt sowohl für die versionsstabil gehaltenen Bestandteile wie den Linux-Kernel, aber auch für die variableren Bestandteile, bei denen Red Hat durchaus mal pragmatisch Versionen anhebt, um die hohe Qualität für den Anwender zu gewährleisten.
  • Keine andere Distribution setzt das Sicherheitsframework SELinux so konsequent ein wie RHEL.

Der Einsatz von RHEL hat aber zwei substanzielle Nachteile:

  • Der Fokus liegt eindeutig auf dem Servereinsatz. Der Kernel ist daher einige Zeit nach dem Release veraltet und unterstützt moderne Desktop-Hardware unzureichend.
  • Die Paketauswahl ist auf einen klassischen Office-Desktop beschränkt und beinhaltet meist nur sehr wenige Softwarelösungen und nicht die komplette FOSS-Bandbreite. Viele Anwender setzen daher auf Drittanbieter wie EPEL mit den üblichen Folgen für die Sicherheit, da diese Drittanbieterquellen nicht im gleichen Maße gepflegt werden.

2. openSUSE Leap

Bevorzugt man einen anderen Desktop als die GNOME Shell, wäre openSUSE Leap eine Alternative. Die stabile openSUSE-Variante unterstützt alle verbreiteten Linux-Desktopumgebungen auf einer stabilen SUSE Linux Enterprise-Basis. SLE selbst bietet eigentlich nur GNOME und deshalb eigentlich keine Vorteile gegenüber RHEL und taucht deshalb nicht als eigener Eintrag in diesem Artikel auf.

Der Einsatz von openSUSE Leap hat für den Anwender gegenüber RHEL substanzielle Vorteile:

  • Die SLE-Basis wird sehr gut gepflegt und Sicherheitsaktualisierungen kommen zeitnah und umfassend.
  • Durch das leistungsfähige Entwicklerteam werden auch Bugs in der SLE-Basis sehr konsequent behoben.
  • Das openSUSE-Projekt trifft keine ideologischen Entscheidungen – weder konzeptionell noch während des Betriebs.
  • Die Paketauswahl ist deutlich größer als bei RHEL und umfasst die übliche Mainstream-Software im FOSS-Bereich.

Allerdings gibt es auch Nachteile:

  • Die Qualität der Pflege fällt von der SLE-Basis zu den Bestandteilen ab, die das openSUSE-Projekt beisteuert.
  • Der Umfang der Aktualisierungen bei den jährlichen Minor-Versionen ist schwer vorherzusagen und damit nicht gut planbar.
  • Neue Hauptversionen folgen den SLE-Hauptversionen und für diese gibt es keine langfristige Roadmap.

3. Ubuntu

Bei Ubuntu muss man differenzieren zwischen der Kerndistribution Ubuntu und den Derivaten. Die Derivate halte ich für keine empfehlenswerte LTS-Distribution, wenn der Fokus auf Sicherheit liegt, da es für diese kein Sicherheitsversprechen gibt, sondern alle Pakete in universe liegen und durch die jeweiligen Communitys höchst unterschiedlich intensiv gepflegt werden.

Wenn man aber die Hauptvariante nutzt und primär Pakete aus main nutzt, dann ist Ubuntu eine sehr gut gepflegte Distribution. Es gibt substanzielle Vorteile:

  • Planbare Releasezyklen und ein Supportversprechen für 5 Jahre ohne die Pflicht jährliche Minoraktualisierungen wie bei RHEL oder openSUSE Leap vornehmen zu müssen.
  • Halbjährlich aktuelle Kernel- und Grafikstackversionen ermöglichen den Einsatz moderner Hardware.

Folgende Nachteile gibt es:

  • Die Universe-Paketquelle ist bei Desktopinstallationen standardmäßig aktiviert. Anwender müssen hier genau prüfen, welche Pakete sie aus welcher Quelle installieren und ob es für diese Support gibt. Die beliebte Oberfläche Synaptic zeigt dies aber praktisch mit kleinen Icons an.
  • Universe ist ungepflegt und teilweise in einem extrem schlechten Zustand. Mit wachsendem zeitlichen Abstand zum Releasedatum der LTS verstärkt sich dieses Problem.
  • Canonical bzw. Ubuntu entwickeln gerne eigene Lösungen, die vom Linux (RHEL) Mainstream abweichen. Es gab in der Vergangenheit deshalb häufiger starke Brüche, bei denen Anwender sehr plötzlich mit Entwicklungen konfrontiert wurden, die bei RHEL oder openSUSE längerfristig vorbereitet wurden.

4. Debian

Kaum überraschend kommt Debian bei mir tatsächlich als letzte Distribution. Debian hat den Vorzug – im Gegensatz zu den drei oben genannten Distributionen – von keiner Firma entwickelt zu werden oder direkt von einer Firma abhängig zu sein. Damit kommt es dem FOSS-Gedanken sehr nahe, ebenso mit der konsequenten Thematisierung unfreier Bestandteile.

Es gibt durchaus Vorteile von Debian die für den Einsatz sprechen:

  • Debian ist sehr nachhaltig. Es gibt immer einen Upgradepfad und Anwender bleiben von tiefgreifenden Umbrüchen verschont.
  • Der Umfang der Paketquellen ist unübertroffen. Die direkte Notwendigkeit unsichere Fremdquellen einzubinden ist selten gegeben.

Inzwischen gibt es aber auch viele substanzielle Nachteile:

  • Die Software in den Paketquellen ist unterschiedlich gut gepflegt. In einigen Bereichen werden über viele Jahre veraltete Versionen mitgeschleppt.
  • Das Supportversprechen ist für einige Pakete über die Release Notes eingeschränkt, was sich faktisch auf weitere Pakete, die diese nutzen, auswirkt und nicht transparent gemacht wird.
  • Versionsstabilität oder Reproduzierbarkeit von Builds wird im Zweifel höher als die zeitnahe Verteilung von Sicherheitsupdates gewichtet.
  • Backports sind von Supportversprechen ausgenommen.

Der Artikel Welche Linux LTS Distribution wählen? erschien zuerst auf [Mer]Curius

23. Februar 2022

Mozilla hat Version 2.7 seiner VPN-Clients für das Mozilla VPN veröffentlicht. Dieser Artikel beschreibt die Neuerungen vom Mozilla VPN 2.7.

Mit dem Mozilla VPN bietet Mozilla in Zusammenarbeit mit Mullvad sein eigenes Virtual Private Network an und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.

Jetzt Mozilla VPN nutzen

Die Neuerungen vom Mozilla VPN 2.7

Multi-Hop für Android und iOS

Standardmäßig leitet das Mozilla VPN den Datenverkehr über einen Server an einem Standort. Mit dem Multi-Hop-Feature kann der Verkehr seit dem Mozilla VPN 2.5 von einem Standort über einen anderen Standort geleitet werden, quasi ein VPN nach dem VPN. Dieses Feature stand bislang nur unter Windows, MacOS und Linux zur Verfügung. Mit dem Mozilla VPN 2.7 bekommen auch Android und iOS die Möglichkeit zum Multi-Hop.

Mozilla VPN 2.7

Nach Updates suchen

Updates für das Mozilla VPN konnten bisher dann installiert werden, wenn das Mozilla VPN mitgeteilt hat, dass es ein Update gibt. Eine neue Schaltfläche im Info-Dialog erlaubt jetzt die manuelle Suche nach Updates.

Mozilla VPN 2.7

Sonstige Neuerungen

Dazu kommen diverse Fehlerbehebungen und Verbesserungen unter der Haube, die sich auf GitHub nachvollziehen lassen. Das Mozilla VPN 2.7.1 für Windows beinhaltet außerdem noch die Behebung einer Sicherheitslücke.

Der Beitrag Mozilla VPN 2.7 veröffentlicht erschien zuerst auf soeren-hentzschel.at.