staging.inyokaproject.org

8. September 2021

Die MZLA Technologies Corporation hat mit Thunderbird 78.14 und Thunderbird 91.1 planmäßige Updates für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 78.14

Mit dem Update auf Thunderbird 78.14 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.

Neuerungen von Thunderbird 91.1

Sicherheitslücken behebt ebenso Thunderbird 91.1. Darüber hinaus bringt das Update diverse Fehlerbehebungen der Versionsreihe 91, welche sich in den Release Notes (engl.) nachlesen lassen.

Der Beitrag Thunderbird 78.14 und Thunderbird 91.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mi, 8. September 2021, Ralf Hersel

Tails 4.22 macht den neuen Tor-Verbindungsassistenten, der mit Tails 4.20 eingeführt wurde, leistungsfähiger, indem die Schnittstelle für benutzerdefinierte Brücken so geändert wurde, dass nur noch die Eingabe einer Brücke möglich ist, eine benutzerdefinierte Brücke im Persistent Storage gespeichert werden kann und Tor Verbindungen, die Brücken verwenden, stabiler werden, indem Benutzer die Uhr manuell einstellen können.


Ausserdem wurde die Zeitüberschreitung, die bestimmt, ob eine Tor-Verbindung aufgebaut werden kann, von 30 auf 10 Sekunden reduziert, die Zeitüberschreitung zum Starten von Tor von 120 auf 600 Sekunden erhöht, was den Tor-Verbindungsassistenten bei langsamen Internetverbindungen stabiler macht, und es erlaubt den Nutzern nun, vom Fehlerbildschirm aus erneut zu versuchen, sich mit Tor zu verbinden.

Zudem behebt Tails 4.22 ein Problem, das auftrat, wenn man sich über die Standardbrücken mit Tor verband und die Wi-Fi-Einstellungen im persistenten Speicher gespeichert wurden, und versucht nicht mehr, sich im Hintergrund mit Tor zu verbinden, wenn der neue Tor-Verbindungsassistent den Fehlerbildschirm erreicht. Der unsichere Browser von Tails wurde in dieser Version auch verbessert, indem Tor nicht mehr neu gestartet wird, wenn der unsichere Browser verlassen wird und der persistente Speicher nur noch in der Warnung des unsicheren Browsers erwähnt wird, wenn persistenter Speicher verfügbar ist.

Neben anderen Änderungen lädt Tails nun immer automatische Upgrades von einem funktionierenden Mirror herunter, bietet bessere Unterstützung für AMD-Grafikkarten durch die Aktualisierung der AMD-Grafik-Firmware auf Version 20210818 und fügt Russisch zur Offline-Dokumentation hinzu. Unter der Haube wird Tails 4.22 weiterhin vom LTS-Kernel 5.10 angetrieben und nutzt die Software-Repositories von Debian 10 "Buster". In dieser Veröffentlichung sind der anonyme Webbrowser Tor Browser 10.5.6 und der E-Mail-Client Mozilla Thunderbird 78.13 enthalten.

Weitere Details stehen in den Release Notes:

Quelle: https://tails.boum.org/news/version_4.22/index.en.html

Mi, 8. September 2021, Marco

Am Montag wurde die Version 123 der debianbasierten Distribution Finnix veröffentlicht. Finnix ist eine kleine Linuxdistribution, welche von einer CD gestartet werden kann. Die Hauptzielgruppe von Finnix sind Systemadministratoren, welche Festplatten mounten und manipulieren, Netzwerke überwachen oder Boot records neu bauen müssen respektive möchten. Neben den vorgestellten Zwecken kann die Distribution auch für weitere Tätigkeiten verwendet werden.

In der aktuellsten Version wurden unterschiedliche Neuerungen vorgenommen und Fehler behoben. So gibt es neu die Kerneloptionen sshd und passwd. Ab dieser Version sollte die Rechner-ID auch über Reboots hinweg gleich bleiben. Dies ist beispielsweise bei der Konfiguration der IP-Adresse über DHCP ein erheblicher Vorteil. Neu beherrscht das Kommando finnix Bedienungshinweise für das ZFS-Dateisystem. Ab der Version 123 wird bei Befehlen, welche nicht gefunden werden konnten, ein Hinweis zum womöglich gemeinten Paket geliefert und Anweisungen zur Installation bereitgestellt. Das Team hinter Finnix spendierte einigen Finnix-eigenen Befehlen wie zum Beispiel wifi-connect oder locale-config eine Manpage. Neu sind die Pakete ftp, ftp-ssl und zile nicht mehr verfügbar. Dafür wurde der Emacs-ähnliche Editor jove hinzugefügt.

Neben diesen Neuerungen wurden in dieser Version auch einige Pakete aktualisiert. Normalerweise nutzt die Distribution den Testing-Zweig von Debian. Da der Release von Debian 11 allerdings erst vor Kurzem war, haben sich die Entwickler entschieden, direkt den stabilen Zweig von Debian 11 zu verwenden. Weitere Informationen, die ISO-Dateien sowie die GPG-Signaturen finden sich in den Release Notes.

Quelle: https://www.finnix.org/Finnix_123_release_notes

7. September 2021

Mozilla hat Firefox 92 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

Firefox 92 bringt Detail-Verbesserungen

Verglichen mit den vorherigen Veröffentlichungen ist Firefox 92 ein unauffälliges Update, welches vor allem Detail-Verbesserungen statt große neue Features bringt.

So gehört es schon fast zu den auffälligsten Neuerungen von Firefox 92, dass die Fehlerseite für Netzwerkfehler optisch überarbeitet worden ist und ohne grellen gelben Rand nun angenehmer zu betrachten ist.

Firefox 92 Netzwerk-Fehler

Optisch überarbeitet wurde auch die Ansicht von Ordnern in der Lesezeichen-Symbolleiste. Diese folgen nun dem Design der anderen Menüs in Firefox seit Version 89. Auch der Dialog zum Löschen der neuesten Chronik folgt jetzt dem mit Firefox 89 eingeführten Proton-Design.

Nutzer von Apple macOS erreichen die Teilen-Funktion jetzt auch über das Datei-Menü in der Menüleiste.

Verbesserungen der JavaScript-Speicherverwaltung sollen deren Performance und Speicherverbrauch verbessern. Auch die Performance mit Screenreadern und anderen Barrierefreiheits-Werkzeugen wurde verbessert und soll nicht mehr so stark beeinträchtigt werden, wenn Thunderbird nach Firefox installiert oder aktualisiert worden ist. Außerdem verursacht ein offener alert-Dialog nicht länger Performance-Probleme in anderen Tabs, welche den gleichen Prozess nutzen. Ebenfalls verbessert wurde die Performance mit geöffneten Entwicklerwerkzeugen.

Auch die Privatsphäre wurde weiter verbessert: Die Geolocation-API erlaubt keine Standort-Updates mehr, wenn der entsprechende Tab im Hintergrund ist.

Der SmartBlock-Mechanismus, welcher Scripts bekannter Tracking-Dienste durch eine Art Ersatz-Script ersetzt, welches sicherstellt, dass die Website-Kompatibilität nicht beeinträchtigt wird, wurde um Ersatz-Scripts für Optimizely und Ads By Google ergänzt.

Firefox kann Verbindungen jetzt automatisch auf HTTPS upgraden, indem HTTPS RR als Alt-Svc-Header verwendet wird.

Für die Wiedergabe von Videos werden nun auf vielen Systemen Vollbereichsfarbstufen unterstützt. Unter Apple macOS wurde die Unterstützung von Bildern mit ICC v4-Profil aktiviert.

Die Neuimplementierung des Local Storages, an welcher Mozilla bereits seit längerer Zeit arbeitete, wurde in Firefox 92 standardmäßig aktiviert.

Auf Webstandard-Seite erwähnenswert ist die Unterstützung der CSS-Eigenschaft accent-color. Die Eigenschaft font-family unterstützt jetzt system-ui als Wert. Diverse Verbesserungen gab es auch für die WebExtension-Schnittstelle für Downloads.

Eine Übersicht über alle Verbesserungen der Webplattform wie neue unterstützte Webstandards gibt es wie immer in den MDN web docs.

Natürlich kamen auch in Firefox 92 Fehlerbehebungen und sonstige Verbesserungen unter der Haube dazu.

Geschlossene Sicherheitslücken

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

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

OpenSSL ist eine Softwarebibliothek, die Implementierungen für bestimmte kryptographische Verfahren, die besonders in der Netzwerkkommunikation eingesetzt werden, bereitstellt. Heute wurde Version 3.0 veröffentlicht.

Neue Versionierung

Anwender und Entwickler, die bereits mit OpenSSL arbeiten, werden mitunter erschrocken sich fragen, warum dieser Versionssprung stattfindet – so war zuletzt Version 1.1.1l aktuell und OpenSSL für eine sehr zurückhaltende Numerierung bekannt.

OpenSSL steigt nun allerdings, wie bereits 2018 angekündigt, auf die Semantische Versionierung um, welche ein klares Schema vorgibt, welche Änderungen zu welcher Anhebung der Versionsnummer führen. Dabei liegt der Dreh- und Angelpunkt bei der API: wird die erste Versionsnummer (Major) erhöht, gibt es Änderungen an der API, die nicht abwärtskompatibel sind. Ergänzungen erhöhen die Versionnummer hinter dem ersten Punkt und Patches die nach dem zweiten Punkt. Ein Sprung von 1.1.1 auf 3.0 steht also für nicht abwärtskompatible API-Änderungen, weswegen alle, die auf OpenSSL setzen, einen Blick auf die Neuerungen werfen sollten, die wir uns gleich anschauen werden. Die Versionnummer 2.0 wurde im Übrigen übersprungen, da teilweise das FIPS-Modul schon auf die Weise numeriert wurde.

Änderungen

Folgende Änderungen fallen im Changelog auf:

  • Mit Version 3.0 wird ein neues Konzept zur Modularisierung eingeführt: die Provider. Sie ersetzen die ENGINE API sowie dessen Implementierungen und sollen die Wartbarkeit der Implementierungen erhöhen. Algorithmen können nun flexibel eingeführt werden, solange es eine API gibt, die den entsprechenden Typen unterstützt. Das Kontext wird in der entsprechenden Man-Page ausführlich erklärt. Die Algorithm Types heißen nun Operationen (operations).

  • Weiterhin soll vor allem aufgeräumt werden. Dafür wurden viele API-Funktionen als veraltet deklariert, darunter TLS_MAX_VERSION, DTLS_MAX_VERSION, DTLS_MIN_VERSION und viele Low-Level-Funktionen.

  • Ein Byte-Order-Mark am Anfang von PEM-formatierten Dateien wird nun ignoriert.

  • Die Validierung der Operationsparameter kann nun solange verzögert werden, bis die eigentliche Operation stattfindet, da die Implementierungen der kryptographischen Operationen in die Provider verschoben wurde. Somit lässt sich das Verhalten und die Fehlerbehandlung verändern. Als Beispiel wird angeführt, dass der Funktionsaufruf einer nicht unterstützen Kurve mit EVP_PKEY_CTX_set_ec_paramgen_curve_nid() nicht fehlschlagen wird, wohl aber Funktionen zur Schlüsselgenerierung mit EVP_PKEY_CTX.

  • ERR_GET_FUNC() wurde vollständig entfernt.

  • Datumsangaben können nun gemäß ISO 8601 formatiert werden. Dies ist allerdings keine Standardeinstellung.

  • Weiterhin gibt es Änderungen bei den Funktionssignaturen. So wechseln die Signaturen der Funktionen zum Setzen oder Ausgebnen von Optionen für SSL und SSL_CTX von unsigned long auf uint64_t. Somit kann sichergestellt werden, dass die Datentypen auf allen Systemen exakt 64 Bit lang sind statt der bisherigen Anforderung auf mindestens 32 Bit. Nebenbei entspricht ein uint64_t einem long long.

  • Clientseitig initiierte Renegotiations sind nun standardmäßig deaktiviert und können mit z. B. -client_renegotiation oder SSL_OP_ALLOW_CLIENT_RENEGOTIATION wieder aktiviert werden.

  • abspath- und includedir-Pragmas werden im Code verwendet, um Sicherheitsrisiken durch relative Inkludierung aus dem Weg zu gehen.

  • Die APIs für PKCS#12-Dateien, die oft eingesetzt werden, um Private Key und Zertifikat in einer Datei zu speichern, wurden so erweitert, dass sie nun einen Bibliothekskontext akzeptieren. pkcs12 selber nutzt nun PBKDF2, AES und SHA-256 mit einem MAC-Iterationszähler gemäß PKCS12_DEFAULT_ITER. openssl pkcs12 gibt überdies nun alle PKCS#12-Attribute und nicht mehr nur das erste aus.

  • Linux' Kernel TLS wird nun unterstützt.

  • Ausgaben verschiedener Kommandos wurden leicht angepasst.

  • openssl speed greift nun nicht mehr auf Low-Level-APIs zurück.

  • Die verfügbaren Provider können nun per openssl list -providers angezeigt werden.

  • CMP und CRMF gemäß RFC 4210, 4211 und 6712 wurden hinzugefügt.

  • DH Modulos müssen nun mindestens 512 Bits lang sein.

  • FFDHE Key Exchange in TLS 1.3 wird nun unterstützt.

Der Fokus lag bei diesem Release besonders beim FIPS-Modul. Darüber hinaus strebt OpenSSL eine Zertifizierung nach FIPS 140-2 an, weswegen einige Änderungen Anpassungen an Standards enthalten. So wird z. B. nicht mehr möglich sein, mehr als 264 TLS Records in einem Zug mit AES-GCM zu verschlüsseln, um die Einzigartigkeit von Schlüssel und Intialisierungsvektor (IV) zu gewährleisten. PBKDF2 orientiert sich überdies nun an SP800-132 statt an PKCS#5 RFC 2898.

Diese zahlreichen Änderungen machen mitunter eine Migrationen bei allen OpenSSL-einsetzenden Programmen notwendig. Die OpenSSL-Entwickler stellen hierfür eine entsprechende Migrationsanleitung bereit.

Neue Lizenz

Zu guter Letzt gibt es Anpassungen bei der Lizenz. OpenSSL 3.0 steht unter der Apache License 2.0. Somit gilt nun nicht mehr die angepasste BSD-Lizenz, die eine Werbeklausel enthält. Die Umstellung wurde bereits vor vier Jahren anvisiert.

Kurzeinordnung

Es freut mich, dass sich einiges beim OpenSSL-Projekt tut. Die Liste der Änderungen ist lang, es wird viel bereinigt. Allerdings bleibt in meinen Augen die Sorge, dass dieser große Release langsamer als sonst seinen Weg in die Endprodukte findet. OpenSSL wird in allen möglichen Systemen auch fernab von klassischen Computersystemen eingesetzt und stellt somit das Rückgrat sicherer Netzwerkkommunikation dar. Die Umstellung der Versionierung sorgt nicht nur für kurze Verwirrung, sondern sollte auch im Hinterkopf behalten werden, wenn Versionsprüfungen fehlschlagen: sie könnten so programmiert sein, dass sie nur den Major-Release überprüfen - dabei sollte der überwiegende Teil der Software, die bereits mit 1.1.1l lief, auch mit OpenSSL 3.0 laufen.

6. September 2021

Mo, 6. September 2021, Ralf Hersel

OpenWrt ist eine Linux-Distribution für eingebettete Systeme wie CPE-Router, Smartphones oder Pocket-Computer. OpenWrt bietet ein voll beschreibbares Dateisystem und beinhaltet den Paketmanager opkg. Das ist insbesondere für den Einsatz in CPE- und WLAN-Routern einzigartig. Die Paket-Quellen beinhalten mehr als 15.000 Software-Pakete. Mit diesen kann der Router umfassend konfiguriert und um viele Funktionen erweitert werden, die von der Firmware des Geräteherstellers nicht unterstützt werden. Nun ist die Version 21.02 der Distribution erschienen.

OpenWrt 21.02 enthält über 5800 Commits seit der vorherigen Version 19.07 und befindet sich seit etwa eineinhalb Jahren in der Entwicklung. Die Highlights der neuen Version sind:

WPA3-Unterstützung standardmässig enthalten
WPA3 wurde bereits in Version 19.07 unterstützt, war aber nicht in den Standardpaketen der OpenWrt-Images enthalten. Mit 21.02 werden alle Pakete, die für die Bereitstellung von WPA3 erforderlich sind, standardmässig in OpenWrt-Images installiert. WPA3 wird von den meisten Wifi-Treibern in OpenWrt unterstützt.

TLS- und HTTPS-Unterstützung standardmässig enthalten
TLS-Unterstützung wird nun standardmässig in OpenWrt-Images bereitgestellt, einschliesslich der vertrauenswürdigen CA-Zertifikate von Mozilla. Das bedeutet, dass wget und opkg nun das Abrufen von Ressourcen über HTTPS sofort unterstützen. Auf den opkg-Download-Server wird standardmässig über HTTPS zugegriffen. OpenWrt wechselte von mbedTLS zu wolfSSL als Standard-SSL-Bibliothek. mbedTLS und OpenSSL sind weiterhin verfügbar und können manuell installiert werden.

Erste DSA-Unterstützung
DSA steht für Distributed Switch Architecture und ist der Linux-Standard für den Umgang mit konfigurierbaren Ethernet-Switches. OpenWrt 21.02 kommt mit anfänglicher Unterstützung für DSA, die das swconfig-System ersetzt, das OpenWrt bisher verwendet hat. Nicht alle Ziele wurden portiert: einige Geräte verwenden noch swconfig, während einige Geräte bereits zu DSA gewechselt haben.

Erhöhte Mindestanforderungen an die Hardware: 8 MB Flash, 64 MB RAM
Aufgrund der Einführung neuer Funktionen und der allgemeinen Vergrösserung des Linux-Kernels benötigen Geräte nun mindestens 8 MB Flash und 64 MB RAM, um eine Standardversion von OpenWrt auszuführen. Mehr Flash-Speicher wird für die Erweiterbarkeit empfohlen.

Neue Netzwerkkonfigurationssyntax und board.json Änderung
Es gibt mehrere Änderungen an der Syntax der Netzwerkkonfiguration in /etc/config/network:

  • in config interface wurde die Option ifname in device umbenannt (da sie sich auf einen Geräteabschnitt bezieht)
  • in config device vom Typ bridge wurde ifname in ports umbenannt
  • Bei Neuinstallationen erstellt die generierte Konfiguration nun separate Abschnitte für die Konfiguration der Schicht 2 (config device) und der Schicht 3 (config interface).

Die alte Syntax wird weiterhin unterstützt, um den Übergang zu erleichtern, und es gibt keine automatische Migration beim Upgrade.

Neu unterstützte Hardware-Targets
Es wurde ein neues Realtek-Target hinzugefügt, das häufig in verwalteten Switches zu finden ist. Dadurch ist es nun möglich, OpenWrt auf Geräten mit einer grossen Anzahl von Ethernet-Ports zu betreiben. Darüber hinaus wurden neue bcm4908- und Rockchip-Targets hinzugefügt. Die bestehenden Targets wurden um Unterstützung für viele neue Boards ergänzt.

Gestrichene Hardware-Targets
Das ar71xx-Target ist in OpenWrt 19.07 veraltet und wurde schrittweise durch ath79 ersetzt. Mit OpenWrt 21.02 wurde das ar71xx nun entfernt und Benutzer müssen stattdessen ath79 verwenden. Andere Targets wurden ebenfalls entfernt: cns3xxx, rb532 und 'samsung'.

ASLR aktiviert
Netzwerkexponierte Userspace-Anwendungen werden als positionsunabhängige ausführbare Dateien (PIE) gelinkt, um eine vollständige Unterstützung der Address Space Layout Randomization (ASLR) zu ermöglichen. Dadurch wird es für Angreifer schwieriger, OpenWrt auszunutzen.

Kernel mit Container-Unterstützung
Mehrere Linux-Kernel-Kompilieroptionen, die für Linux-Container (LXC) und procd-ujail benötigt werden, sind für die meisten Targets standardmässig aktiviert. Dies ermöglicht die Verwendung von LXC und ujail mit den normalen Release-Builds.

SELinux-Unterstützung
Es ist möglich, OpenWrt mit SELinux-Unterstützung zu kompilieren. Diese ist derzeit standardmässig nicht aktiviert.

Weitere Neuigkeiten und Änderungen finden sich in den Release Notes:

Quelle: https://openwrt.org/releases/21.02/notes-21.02.0

5. September 2021

Windows ist der Standard, Linux und macOS die Alternativen. Selbst die meisten wechselwilligen Anwender haben fest gefügte Arbeitsabläufe und Anforderungen. Die Supportforen und Kommentarspalten sind voll davon, wie man auf solche Anforderungen nicht reagiert.

In der Regel handelt es sich um wechselwillige Anwender, manchmal sind diese Nutzer auch schon gewechselt und wollen nun ihren Workflow von Virtuellen Maschinen mit Windows oder Krücken wie Wine hin zu nativen Programmen umstellten oder aber native Programme werden eingestellt und sie suchen Alternativen. Entweder fragt man im Familien-, Freundes- und Bekanntenkreis oder schlägt auf einer der zahllosen Plattformen im Internet auf.

Dort wimmelt es dann von Beispielen, wie man auf solche Anfragen nicht reagiert:

  • Die Anforderung wird disqualifiziert, weil sie nicht der „Unix-Philosphie“ entspricht, die doch behauptet „Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen“. Dabei ist es unerheblich, dass die Vertreter dieses Unix-Philosophie-Arguments in der Regel keinen blassen Schimmer von Unix-Philosophie haben und wie alle Fanatiker überhaupt nicht kontextualisieren.
  • Die Anforderung wird disqualifiziert, weil der Anwender es schon immer falsch gemacht hat. Beispiel: So etwas macht man doch nicht mit einem Tabellenkalkulationsprogramm, dafür gibt es richtige Datenbanksysteme oder: Für so etwas nimmt man doch nicht Word, Profis arbeiten mit LaTeX.
  • Die Anforderung wird disqualifiziert, weil man den Anforderungsfall negiert. Beispiel: Das Dateiformat PDF ist nicht zum bearbeiten da. Dafür gibt es andere Formate. Du brauchst kein PDF-Bearbeitungsprogramm.
  • Die Anforderung ist legitim, eine Lösung von der Stange gibt es nicht: Beispiel: Das ist ein Problem, ich habe mir dazu eine Reihe von Skripten geschrieben, aber die sind schlecht dokumentiert und die kannst du nicht verwenden. Aber du kannst ja eben schnell selbst lernen solche Skripte zu schreiben.
  • Die Anforderung passt nicht zur Projekt-Philosophie, deshalb erklärt man sie für unsinnig. Beispiel: Dateien und Ordner auf dem Desktop. Wollen viele Leute haben, bieten Windows und macOS an. Desktopentwickler bei Linux haben sie zeitweilig (KDE) oder dauerhaft (GNOME) für überflüssig erklärt und die Claqueure unter den Anwendern sekundieren fleißig, indem sie allen die das fordern bzw. wünschen schlechte Dateiorganisation unterstellen.
  • Die Anforderung lässt sich mit Linux nicht umsetzen, deshalb erklärt man sie für veraltet/unsicher/was-auch-immer. Beispiel: Offline-Synchronisation zwischen Desktop und Smartphone ist doch total veraltet, das macht man inzwischen über die Cloud. Wenn du Bedenken wegen der Privatsphäre hast, setze dir doch eine Nextcloud auf einem Server auf. Wie du hast keinen Server?

Diese Liste ließe sich sicher noch um einiges verlängern. Stattdessen sollte man jeden Anwendungsfall erst mal legitim finden und analysieren.

Diese Analyse kann durchaus mal das Ergebnis haben, dass der Anwendungsfall Quatsch ist. Ich hatte beispielsweise mal einen Fall, wo bemängelt wurde, dass Taschenrechner und Tabellenkalkulation ständig den Fokus beim scrollen verlieren. Dem Anwender war nicht klar, dass jedes Tabellenkalkulationsprogramm selbst rechnen kann. Das zeigt man ein mal und dann ist das ursprüngliche Problem mit einem Schlag wirklich unwichtig.

Andere Probleme könnten sich durch ein alternatives Protokoll lösen lassen. Manche Anwender schlagen z. B. mit komplexen Synchronisationslösungen für Mails auf, weil sie immer noch POP3 anstelle von IMAP verwenden. Hier hilft manchmal einfach die Anwender in die richtige Richtung zu schupsen. Was nicht unbedingt bedeutet, dass im Einzelfall nicht dennoch POP3 die bessere Wahl bleiben könnte. Hier sollte man immer ergebnisoffen bleiben.

Meistens sind die Anwendungsfälle aber komplexer. Manchmal muss man etwas machen, was das Format nicht vorsieht, aber unter Systemen wie Windows möglich ist. Mein gegenwärtiges Lieblingsbeispiel ist das, was in Bibliotheken der sogenannte Konstanzer Workflow oder Konstanzer Methode genannt wird. Dabei geht es – ganz stark verkürzt – um eine Vorgehensweise, wie man die Verlagsversion von Aufsätzen (das sind PDFs) so bearbeitet, dass man sie über das institutionelle Repositorium zweitveröffentlichen kann, ohne die Policies und gesetzlichen Anforderungen zu verletzen. Das geht nur mit ausgefeilter PDF-Bearbeitung, einem PDF-Drucker (kein speichern) und einer Bearbeitung der Metadaten. Das ist total sinnlos, aber über manche Dinge kann man nicht streiten. Man sollte sie auch nicht pauschal disqualifizieren.

Ganz hilfreich ist der Typus des Besserwissers, der stark veraltetes Wissen oder stark selektives Wissen hat, aber das nicht eingestehen möchte. Ich nenne ihn immer gerne den „LaTeX-Typus“. Standardherangehensweise ist alle Anfragen zu LibreOffice oder MS Office, Scribus etc. pp. mit LaTeX zu kontern. Gerne in folgendem Argumentationsstil: Alle Wissenschaftler arbeiten mit LaTeX, weil nur LaTeX für die Langzeitarchivierung geeignet ist und alle Verlage gerne LaTeX akzeptieren. Jede Entwicklung neben LaTeX ist unbedeutend, der Fragesteller ist nur so faul die steile LaTeX-Lernkurve zu absolvieren. Das ist selektiv bis falsch und der Wissensstand von circa 2005-2010, aber dem Besserwisser ist das egal, weil seine Wissen vermeintlich überlegen ist.

Besonders fatal sind jene Kommentatoren (Hilfesteller mag ich sie nicht nennen, weil sie nicht helfen), die sich derart in ihr System eingeigelt haben, dass sie gar nicht wissen, was andere Systeme können und auf jedweden Verweis mit „Brauch ich nicht“ und „Brauchst du auch nicht“ reagieren.

Nur mal als Denkanstoß, nachdem ich heute morgen bei der Suche nach einer Lösung wieder in sehr vielen Supportforen in den Abgrund schauen durfte.

Der Artikel Wie man nicht auf Nutzer-Anforderungen reagieren sollte erschien zuerst auf [Mer]Curius

Synology bietet tolle NAS Systeme. Leider wird das Betriebssystem DiskStation Manager (DSM) mit älteren Versionen ausgeliefert. Updates kamen in der Vergangenheit schon selten. Ein dokumentiertes Problem mit OpenSSL zeigt aber erneut, wie fahrlässig Synology agiert.

In OpenSSL wurde vor gut 2 Wochen eine Lücke geschlossen (CVE-2021-3711). Die Lücke hat ein hohes Risiko und kann aus der Ferne ausgenutzt werden. Die bekannten Hersteller von NAS Systemen QNAP und Synology mussten ein paar Tage später einräumen, dass ihre Betriebssysteme von dem Problem betroffen sind.

Bei beiden Systemen handelt es sich um Serverbetriebssysteme, die vom Hersteller durchaus so ausgelegt sind, dass sie direkt aus dem Netz zu erreichen sind. Der einzelne Anwender kann sich natürlich trotzdem entscheiden das NAS nur im Heimnetz zu betreiben oder lediglich per VPN auf die Dienste zuzugreifen, aber man getrost davon ausgehen, dass viele Kunden direkt mit Port-Forwarding agieren.

Stand heute hat Synology für sein aktuelles Betriebssysteme DiskStation Manager 7 immer noch kein Update bereitgestellt. Es ist ein RC-Kandidat für ein Update verfügbar, aber aus dem Changelog geht nicht klar hervor, ob dieses Update auch besagte Lücke schließen soll. Aufgrund der stark verzögerten Roll-out Richtlinie von Synology bekommen die meisten Anwender das Update wohl erst in einigen Wochen.

Bei mir hört langsam das Verständnis für Synology auf. Der DiskStationManager ist letztlich nur eine Linux-Distribution. Bis auf einige eigene Lösungen baut man auf viel Vorarbeit der Community auf. Es ist mitnichten so, dass hier selbst Fehleranalyse betrieben und ein Update entwickelt werden musste, denn OpenSSL hat upstream das Problem behoben. Synology bekommt es nur nicht hin, dieses Update zeitnah für seine DSM auszurollen.

Das ist umso unverständlicher, als Synology, ähnlich wie z. B. Apple, den DSM nur für eine stark begrenzte Anzahl an Systemen anbietet und aktuell lediglich zwei supportete Varianten des DSM anbietet. Die aktuelle Version DSM 7 und die ältere DSM 6.2. Hier müssen nicht hunderte unterschiedliche Einsatzszenarien getestet werden, wie das bei allgemeiner ausgerichteten Linux-Distributionen der Fall ist.

Es drängt sich immer mehr der Eindruck auf, dass bei Synology die Entwicklung im übertragenen Sinne von drei Studenten im Keller gemacht wird, während in der Marketing-Abteilung der Champagner fließt.

Nachtrag vom 28.09.2021

Das notwendige Update 7.0.1-42218 ist nun endlich da. Die lange Dauer unterstreicht aber noch mal die Aussage aus dem Artikel.

Der Artikel Synologys fraglicher Umgang mit der Sicherheit erschien zuerst auf [Mer]Curius

2. September 2021

Gestern gab es nach langem Warten wieder ein Update für Fedy.
Bei diesem Update haben wir einige Fehler behoben und neue Software mit aufgenommen. Somit wurde Folgendes neu mit aufgenommen:

  • 1Password
  • Blanket
  • DBeaver
  • Gitfiend
  • Insync
  • Mailspring

Zusätzlich dazu haben wir die Software um weitere Themes erweitert:

  • Qogir Icon Theme
  • Qgoir GTK Theme

Die neuste Version ist bereits seit gestern in der Fedora Copr vorhanden und in der Readme von Github ist erläutert wir ihr Fedy installieren könnt.

Do, 2. September 2021, Ralf Hersel

Linux Lite ist eine einsteigerfreundliche Linux-Distribution, die auf der Long-Term-Support-Version (LTS) von Ubuntu basiert und den Xfce-Desktop enthält. Die neueste Version des Projekts, Linux Lite 5.6, basiert auf Ubuntu 20.04 LTS und bietet eine Reihe von Annehmlichkeiten und Upgrades. Python 3 wird nun standardmässig verwendet, es ist möglich, die Distribution über den Willkommensbildschirm auf dem Live-Medium zu installieren, und das Tool "Lite Tweaks" bietet die Möglichkeit, temporäre Dateien, die vom Brave-Browser verwendet werden, zu bereinigen.

"Linux Lite 5.6 Final steht ab sofort zum Download und zur Installation bereit. Diese Version enthält Aktualisierungen des Hilfe-Handbuchs - unsere ausführliche, leicht verständliche Linux-Lite-Anleitung, Du kannst Linux Lite jetzt direkt von Lite Welcome aus installieren, ein aktualisiertes Papirus-Symbolthema, 2 neue Funktionen für Lite Tweaks, die Einführung des digitalen Download-Modells 'Pay what You Want', 7 neue Hintergrundbilder, die Standardversion von Python ist jetzt auf Python3 eingestellt, und eine Vielzahl von Fehlerkorrekturen und Verbesserungen für unsere Zielgruppe. Wenn Du von Windows kommst, wirst Du feststellen, dass dies eine solide, stabile Version ist, die dir den Übergang zu einem linuxbasierten Betriebssystem erleichtern wird." so das Projektteam.

Details zum Release sowie Screenshots finden sich in der Release-Ankündigung:

Quelle: https://www.linuxliteos.com/forums/release-announcements/linux-lite-5-6-final-released/

Viele Linux-Nutzer, selbst die enthusiastischen Vertreter, kommen nicht um Windows herum. Weil Windows bei vielen Menschen immer noch den Arbeitsalltag prägt. Ein gern verschwiegener Bestandteil unseres Alltags.

Momentan schreiben viele Anwender tolle Gastartikel zu ihrer Reise zu Linux auf Linuxnews. Ein Bereich wird zwar ab und an am Rande gestriffen, aber sonst ignoriert. Die Arbeitswelt. Denn die Reise zu Linux ist bei den meisten eine unvollständige Reise. Vorausgesetzt, man hat einen Beruf, bei dem man mit Computern arbeiten darf/muss.

Windows prägt die Büros bis in die Gegenwart. Rational betrachtet, verbringe ich mehr Zeit vor einem Windows-Rechner als vor meinen Linux-Geräten, denn die Arbeitszeit von 41 Stunden pro Woche ist eine überwiegende Windows-Arbeitszeit. Die gleiche Zeit sitze ich (zum Glück) nicht nach Feierabend und am Wochenende vor einem Linux-System.

Wenn ich hier über Linux schreibe, dann schreibe ich vor allem über Linux im Privateinsatz (plus die noch nicht fertiggestellte Dissertation). Ein Privateinsatz, der zwar über das obligatorische surfen, mailen und Videos abspielen hinaus geht, aber ein Privateinsatz bleibt.

Dabei ist es nicht mal so, dass ich Windows für die Arbeit nutzen möchte. Mein Arbeitgeber stellt mir zwar ein Notebook, dessen Betriebssystem ich nicht auswählen kann, aber – Corona machts möglich – zumindest gegenwärtig dürfte ich auch mit meinem Privatgerät arbeiten. Die IT-Abteilung supportet zwar offiziell kein Linux, hat aber am Beginn der Pandemie einige Anleitungen für VPN & Co mit Linux erstellt.

Nur möchte ich das gar nicht. Ich arbeite gerne mit Windows.

Das liegt weniger an Windows 10, das ich für ein höchst bescheidenes System halte, sondern an den Programmen. Allerdings bereits hier mit Einschränkungen, denn DirectAccess ist eine sehr anwenderfreundliche Lösung, die den Arbeitskomfort im Homeoffice gegenüber klassischem VPN deutlich erhöht. Das Gleiche gilt für die Softwareverteilung über den Endpoint-Manager und die praktischen Admin-Kennwörter mit zeitlich beschränkter Gültigkeit, wodurch die IT mit als einfachem Anwender ab und an mal Admin-Rechte geben kann. Ob Linux hier gleichwertige Lösungen bietet? Keine Ahnung!

Spätestens bei den Programmen möchte ich aber gar nicht auf Windows verzichten. Meine komplette Arbeitsorganisation erfolgt über die obligatorische Microsoft Exchange & Outlook-Kombination. Mir ist keine freie Lösung bekannt, die sich so gut zur Terminverwaltung im Team eignet. Die Mail-Funktion ist da ja eher Beiwerk.

Hinzu kommen Word, Excel und Powerpoint. Hier gäbe es freie Pendants, aber die Zusammenarbeit ist nicht sattelfest. Ich möchte nicht derjenige sein, der die umfassenden Pivot-Abrechnungstabellen zerschießt, die eine Kollegin mit vielen Arbeitsstunden und viel Excel-Expertise mühevoll erstellt hat. Mal abgesehen davon, dass LibreOffice einfach keinen Spaß macht. Eine kleine Anekdote dazu: Als kürzlich eine knappe Präsentation erstellt werden sollte, fing eine Kollegin, die sonst privat nur mit LibreOffice arbeitet, an sich richtig in das Projekt rein zu knien. Sie war einfach so fasziniert davon, wie viel Spaß es machen kann, mit Powerpoint zu arbeiten, wo Impress einfach nur eine Qual ist. Und von Access schreibe ich da noch gar nicht.

Für meinen Arbeitsworkflow ist Citavi zudem ziemlich wichtig. Das ist problematisch und ich sollte dringend mal Alternativen evaluieren. Zotero hat ja einige Sprünge gemacht aber vielleicht wird es auch EndNote. Die Migration ist aber so aufwändig, das ich davor zurückscheue. Dank Windows habe ich hier ja auch die volle Auswahl.

Ein perfekt funktionierendes PDF-Bearbeitungsprogramme ist für einige Dienstleistungen ebenso Pflicht. Hier habe ich Adobe Acrobat Pro und PDF XChange Editor zur Wahl. Bei Linux bliebe nur der ebenfalls proprietäre Master PDF Editor. Ob der die beiden erstgenannten Programme ersetzen könnte, habe ich bisher nicht komplett geprüft.

Bei anderen Programmen ist die Stabilität unter Windows einfach besser. Zoom gibt es auch für Linux, aber meiner Meinung nach liegen zwischen den Clients für die unterschiedlichen Plattformen Welten. Hier dürfte die geringere Verbreitung von Linux sich bei Zoom in weniger Aufmerksamkeit umsetzen.

Das bedeutet nicht, dass wir nur auf proprietäre Software setzen. Gerade mal geprüft, was ich so aktuell nutze: Firefox, Rocket.Chat, OpenVPN, Git, FileZilla, Gephi, OpenRefine, Notepad++, VLC. Ich verwende für die Arbeit sicher mehr freie als proprietäre Software. Nur gibt es diese auch für Windows, weshalb Linux mir keine Vorteile bietet. Einige dieser Programme gibt es sogar nur für Windows.

Natürlich ist Windows und Office für den Datenschutz eine Katastrophe, das ist hinlänglich bekannt. Es ist nur nicht meine Katastrophe, sondern die meines Arbeitgebers und das ist mir bis zu einem gewissen Maß egal. Vor den schlimmsten Auswüchsen schützt mich im Zweifelsfall sowieso der Personalrat. Viele Maßnahmen, die ich privat nutze, wie beispielsweise Cookie Management, Site Isolation usw. ignoriere ich im Arbeitsalltag weitestgehend. Ich bin ja schließlich sowieso nur beruflich mit dem Gerät unterwegs.

Linux ist und bleibt mein Privatsystem und hat hier macOS nach 4 Jahren Ausflug ins Apple-Lager wieder fast vollständig ersetzt. Windows war immer da und bleibt es auch. Selbst wenn ich es ändern könnte, ich würde es nicht wollen. Linux würde meinen Arbeitsalltag einfach nur komplizierter machen. Ich würde deshalb auch niemals in einer internen Evaluation Linux das Wort reden.

Möchte ich deshalb Windows auch privat nutzen? Nicht eine Sekunde! Denn es fühlt sich einfach nach Arbeit an und diese Trennung schätze ich sehr.

Der Artikel Windows – Der verschwiegene Arbeitsbegleiter erschien zuerst auf [Mer]Curius

Do, 2. September 2021, Ralf Hersel

Linux From Scratch (LFS) ist ein Projekt, das eine Schritt-für-Schritt-Anleitung bietet, um sein eigenes, individuelles Linux-System zu erstellen, und zwar vollständig aus dem Quellcode. Nun gibt Bruce Dubbs vom LFS-Team die Veröffentlichung von LFS Version 11.0 bekannt.

Der Grund für die Erhöhung der Versionsnummer ist, dass diese Version nicht mehr das "Split-User"-System verwendet. Das heisst, wie bei den meisten aktuellen Distributionen, ist /bin ein symbolischer Link zu /usr/bin. Ebenso sind /lib und /sbin symbolische Links zu ihren /usr-Gegenstücken.

Zu den weiteren grösseren Änderungen gehören Aktualisierungen der Toolchain für gcc-11.2.0, glibc-2.34 und binutils-2.37. Der Linux-Kernel wurde ebenfalls auf die Version 5.13.12 aktualisiert. Insgesamt wurden 40 Pakete seit der letzten Veröffentlichung aktualisiert.

Ein zentraler Bestandteil des Projektes ist das LFS-Buch. Es liefert den Hintergrund und die Anweisungen, die man benötigt, um ein eigenes System zu entwerfen und zu bauen. Obwohl dieses Buch eine Vorlage bietet, die zu einem korrekt funktionierenden System führt, steht es jedem frei, die Anleitungen zu ändern, um sie an eigene Bedürfnisse anzupassen. Auch das Buch ist mit einigen Änderungen am Text in Version 11 erschienen.

Zusammen mit dieser Veröffentlichung wird auch eine neue Version von LFS mit dem systemd-Paket bereitgestellt. Dieses Paket implementiert den neueren systemd-Stil der Systeminitialisierung und -steuerung und ist in den meisten Paketen mit LFS konsistent.

Wer sich für die Tiefen einer GNU/Linux Distribution interessiert, der sei auch Lioh Möllers Linux Kurs empfohlen. Darin erfährt man auf Basis der Distribution Slackware alles darüber, wie man ein Linux-System Schritt für Schritt aufbaut.

Quelle: https://www.linuxfromscratch.org/news.html

31. August 2021

Di, 31. August 2021, Ralf Hersel

Während im Oktober die Ubuntu Version 21.10 "Impish Indri" erscheinen wird, liegt bereits der Entwurf des Releaseplans für die kommende Long-term-support Version 22.04 auf dem Tisch. Brian Murray veröffentlichte diese auf Canonicals Discourse Kanal.


Für Ubuntu 22.04 wird es als LTS-Version mindestens 5 Jahre Support geben. Die Feature Freeze-Phase ist für den 24. Februar angesetzt, zusammen mit dem Debian Import Freeze, während die Kernel Freeze- und Final Freeze-Phasen für den 7. bzw. 14. April geplant sind. Die fertige Version wird am 21. April 2022 erscheinen. Als Desktop-Umgebung wird man endlich auf die GNOME 40 Serie wechseln (vermutlich wird ein GNOME 41 oder 42 enthalten sein). Welchen Namen das übernächste Release tragen wird, ist noch nicht bekannt, da der Kosenamen immer erst kurz nach dem Erscheinen der vorherigen Version bekannt gegeben wird, also im Oktober 2021.

Quelle: https://discourse.ubuntu.com/t/jj-release-schedule/23906

30. August 2021

Mo, 30. August 2021, Niklas

Wie wir schon vor einigen Wochen berichteten, hat das Haiku Projekt nach etwas mehr als einem Jahr eine neue stabile Version seines quelloffenen BeOS Nachfolgers veröffentlicht. Nach dem Start lassen sich zunächst keine Unterschiede erkennen: Desktop, Icons, Taskleiste, ... - Alles sieht aus wie immer.

Die meisten Änderungen fanden unter der Haube statt, wie etwa bei verbesserten Treibern oder aktualisieren Programmbibliotheken. Haiku Beta 3 startet sogar auf meinem Medion Akoya von 2019 ohne weiteres, welches mit Beta 2 im Bootscreen hängen geblieben ist. Da hier aber Treiber für Touchscreen und Touchpad fehlen und das WLAN nicht richtig funktioniert, beende ich dieses Experiment schnell wieder.

Die viel angepriesenen Aktualisierungen von HaikuWebKit und dem WebPositive Browser sehen beim HTML5 Test eher enttäuschend aus: Beta 2 kommt auf 382 Punkte, Beta 3 nur noch auf 367. Die Unterstützung für die Eingabefeldtypen Datum, Zeit und Monat wurden anscheinend entfernt. Tatsächlich wurden diese aber auch in Beta 2 nicht unterstützt. Die entsprechenden Eingabefelder waren unsichtbar, bekamen beim Klick darauf einen schwarzen Rahmen und konnten nicht beschrieben werden. In Beta 3 tauchen sie immerhin in Form eines normalen Textfelds auf, das von Hand ausgefüllt werden kann.

Ansonsten sind die Messergebnisse identisch, wobei in der Praxis doch erhebliche Verbesserungen bei WebPositive in Beta 3 spürbar sind. In Beta 3 werden einige zusätzliche Unicode Icons unterstützt, die bei Beta 2 noch nicht vorhanden waren, was sich bereits auf der HTML5 Test Seite zeigt. Eine vollständige Liste der Unicode Icons gibt es hier. Was hingegen leider weiterhin gar nicht unterstützt wird, sind Icon Fonts wie Font Awesome, die für die Bedienelemente von zahlreichen Webseiten verwendet werden.

Beim WLAN erkenne ich Verbesserungen, diese sind aber eher subjektiv. Das WLAN meines Testlaptops, Intel PRO Wireless 3945ABG, hat auch vorher schon funktioniert, jedoch mit regelmässigen Verbindungsabbrüchen. In Beta 3 habe ich das Gefühl, dass die Abbrüche nicht mehr so häufig auftreten, ganz behoben wurde das Problem jedoch nicht.

Gerade mit Blick auf dieses Problem sind die Verbesserungen am Paketmanagement aber sehr deutlich zu spüren. Früher musste man das komplette Systemupdate mit allen Paketen wieder von null beginnen, wenn irgendwann zwischendrin die Verbindung unterbrochen wurde. Grössere Aktualisierungen waren an meinem Testlaptop nur mit LAN Verbindung oder durch Aktualisieren der einzelnen Pakete machbar.

Seit Beta 3 kann ich das Update einfach fortsetzen, bereits heruntergeladene Pakete werden wiederverwendet. Achtung Anzeigefehler: Es sieht weiterhin so aus, als müsste alles erneut heruntergeladen werden. Die Pakete tauchen immer wieder in der Liste der Pakete zum Herunterladen auf, bis die Aktualisierung komplett abgeschlossen ist.

Erfreulich ist auch, dass der Trend zu mehr Datenschutz inzwischen auch bei Haiku angekommen ist. Keine Sorge, Telemetriefunktionen hatte das System nie, in WebPositive gab es mit Google als Suchmaschine aber eine sehr fragwürdige Voreinstellung und diese musste durch Änderung der URL umgestellt werden. In Beta 3 ist DuckDuckGo Standard und die Suchmaschine kann aus einer Liste ausgewählt werden, in der Qwant und Ecosia weitere erfreuliche Optionen darstellen, neben den üblichen Datenkraken wie Google, Bing und Yahoo.

Auch Retro-Fans können sich über Beta 3 freuen: Wem das normale Haiku Interface noch nicht Retro genug aussieht, der kann das haiku_extras Paket aus dem HaikuDepot installieren und in den "Erscheinungsbild" Einstellungen den ControlLook auf Be umstellen. Nach einem Neustart hat Haiku nun das originale Aussehen seines Vorgängers. Das haiku_extras Paket ist nicht neu, doch in Beta 2 hatte die Umstellung auf den Be ControlLook nur minimale Auswirkungen. Hinweis: Der Be ControlLook funktioniert nur mit nativen Haiku Programmen. Das Aussehen von Qt Programmen verändert sich nicht.

Fazit: Mir gefällt es. Beta 3 ist ein weiterer wichtiger Schritt in Richtung Massentauglichkeit. Haiku eignet sich schon lange für alle Alltagsaufgaben, doch die Computerwelt entwickelt sich schnell weiter. Haiku nimmt das Wichtigste mit, gerade auch mit Blick auf bessere Hardwareunterstützung und moderneres WebKit, aber rennt auch nicht blind jedem fragwürdigen Trend hinterher.

Haiku Installieren: 32Bit x86 Download | 64Bit x86_64 Download | Installationsanleitung

Mo, 30. August 2021, Ralf Hersel

LibreELEC (kurz für Libre Embedded Linux Entertainment Center) ist ein nicht-kommerzieller Fork von OpenELEC, eine Distribution für den Kodi Media Player und Entertainment-Software. Die neue Version LibreELEC 10 bringt Kodi 19 "Matrix" zu den LibreELEC-Nutzern und bietet besserer Unterstützung für Raspberry Pi 4-Geräte, unterstützt HDMI-Ausgang bis zu 4Kp30, HDR-Ausgang (HDR10 und HLG), HD-Audio-Passthrough (Dolby TrueHD und DTS HD) sowie H264 und H265 Hardware-Decodierung.

Allerdings gibt es immer noch viele Blocker, die ein perfektes LibreELEC-Erlebnis auf dem Raspberry Pi 4 SBC verhindern. Zum Beispiel gibt es kein Deinterlacing mit den Hardware-Videodecodern, die 10-Bit- und 12-Bit-Videoausgabe ist nicht implementiert, und das Hyperion-Add-on funktioniert nicht mehr, da es den neuen Grafiktreiber-Stack nicht unterstützt.

Die Distribution kann von hier heruntergeladen und installiert werden.

Quelle: https://libreelec.tv/2021/08/26/libreelec-matrix-10-0/

Leap ist der stabile Zweig von openSUSE mit LTS-Support. Mit Version 15.3 aus dem Frühjahr 2021 handelt es sich dabei faktisch um SUSE Linux Enterprise mit einigen Zusatzpaketen. Anfangs gab es allerdings Probleme mit der Qualität.

Kurzfristig zum Release eingeführte Änderungen an den Update-Repositorien führten zu einem schweren Fehler, bei dem – Unachtsamkeit oder Automatismen vorausgesetzt – das halbe System deinstalliert werden konnte.

Diese Probleme sind inzwischen behoben. Ich schreibe das so dezidiert, da mich nach dem Artikel viele Anwender kontaktiert hatten, die ähnliche Probleme hatten oder ihr System bereits durch massenhafte Deinstallation von Paketen beschädigt hatten.

Woran es genau lag, ist bis heute nicht offen kommuniziert worden. Die Kommunikation von openSUSE war in diesem Zusammenhang wirklich schwach. Das betrifft sowohl die Erklärungen im Nachhinein als auch die Warnungen, während das Problem noch bestand. Eigentlich hätte man prominent auf der Webseite warnen müssen (oder das Release kurzzeitig zurückziehen müssen), aber entweder kam niemand auf die Idee oder die Abstimmungsmechanismen für so etwas sind bei openSUSE zu behäbig.

Wie dem auch sei: Die Probleme bestehen nicht mehr und openSUSE Leap ist nun wieder stabil zurück in der Spur. Ich habe alle Systeme umgestellt und kann keine Probleme mehr berichten.

Ganz im Gegenteil, denn erst die Aufteilung der Repositorien in Updates von SLE und openSUSE macht für den Anwender transparent, wie sehr er von der Zusammenführung von openSUSE und SLE profitiert. Ohne für Enterprise-Qualität zahlen zu müssen! Lediglich ein kleiner Teil der Pakete und der Updates kommen noch vom openSUSE-Projekt.

Bei den SLE-Updates profitieren openSUSE-Anwender von der Arbeitskraft der für ihre Arbeit an SLE bezahlten SUSE-Mitarbeiter und der Enterprise-Qualität. Meiner subjektiven (!) Meinung nach werden bei SLE (und damit auch openSUSE) auch mittelschwere Fehler hartnäckiger verfolgt als beispielsweise bei Debian oder Ubuntu und nicht nur absolut sicherheitsrelevante und total kritische Probleme nach dem Release beseitigt. Zu Red Hat fehlt mir da der Vergleich.

Die Roadmap für das nächste geplante Minorrelease des 15-Zweiges openSUSE Leap 15.4 steht übrigens fest. Die Veröffentlichung ist für den 22. Juni 2022 geplant. So lange kann man nun auf jeden Fall wieder mit und nicht am System arbeiten. Mal sehen was dort und im maßgeblichen Service Pack von SLE 15 kommt. Ich spekuliere fest auf einen aktuelleren Kernel und aktuellere Versionen bei den Desktopumgebungen, aber das wird sich zeigen.

Der Artikel openSUSE Leap 15.3 wieder in der Spur erschien zuerst auf [Mer]Curius

In diesem Beitrag möchte ich meine persönliche Meinung zu und über Linux-Container mit euch teilen. Ich freue mich, wenn sich daraus eine Diskussion entwickelt, in der ihr eure Erfahrungen und Gedanken zum Thema einbringt.

Mir geht es dabei ausschließlich um Linux-Container, welche ich von ähnlichen Konzepten wie z.B. den LDOMs und Kernel-Zones unter Solaris, etc. bewusst abgrenzen möchte.

Was habe ich mit Containern zu tun?

Nun, Container haben in vielen Branchen Fuß gefasst, in denen IT/EDV eine Rolle spielt und werden voraussichtlich nicht mehr verschwinden. Ich selbst bin als Sysadmin und Nerd sowohl aus privatem Interesse, als auch beruflich mit dem Thema in Berührung gekommen.

Mit den Konzepten und der Architektur bin ich vertraut. Mit dem Wochenendprojekt „Kanboard im Container…“ verfüge ich über wenig praktische Erfahrung.

Wie lautet das Versprechen der Container-Technologie?

Alles wird agiler, schneller, effizienter, sicherer UND einfacher. Das Übliche halt.

Im Wesentlichen bieten Container die Chance, dass Anwendungen mit all ihren Abhängigkeiten ausgeliefert werden können.

Damit könnte das Ende der Zeit eingeläutet werden, wo einer Anwendung eine Installationsanleitung mit dem Kapitel „Systemvoraussetzungen“ beiliegt, mit welcher der Administrator sich auf die Suche nach den benötigten Bibliotheken und Paketen macht, welche in seiner konkreten Umgebung zu installieren und zu konfigurieren sind, bevor die eigentliche Anwendung installiert werden kann.

In der schönen neuen Welt verpacken Entwickler alles, was ihre Anwendung braucht, in einen Container, welchen sie anschließend in den Versand geben (deployen) können. Auf dem Zielsystem wird nur noch eine kompatible Container-Engine benötigt und die Anwendung läuft.

Dabei sind Szenarien realistisch, in denen Anwendungen z.B. in einem Ubuntu-Userland auf einem RHEL-Kern laufen und umgekehrt.

Auch Update-Szenarien können deutlich vereinfacht werden. Ein neues Release kommt in Form eines neuen Container-Images, welches instanziiert wird. Gibt es Probleme, bringt man die laufende Instanz um und startet eine Instanz vom vorherigen Container-Image. Vorausgesetzt die Container beinhalten keine persistent zu speichernden Daten (was sie laut Konzept nicht sollen), kann das wirklich gut funktionieren.

Und wie fühlt sich das bis jetzt in der Praxis an?

Die kurze Antwort auf diese Frage lautet: „Sehr unterschiedlich. Das Spektrum reicht von gut bis durchwachsen.“

Ich möchte noch einmal erwähnen, dass ich Systemadministrator und kein Anwendungsentwickler bin. Ich entwickle also keine Software, welche dann mit CI/CD-Pipelines verarbeitet und ausgerollt wird. Meine Aufgabe ist eher die Bereitstellung und der Betrieb von Umgebungen, in denen Container ausgeführt werden können. Zu möglichen Kunden/Nutzern zählen dabei Teams, die eigene Anwendungen entwickeln, aber auch Teams, welche Anwendungen in Form von Container-Repositorien bzw. -Images geliefert bekommen und diese dann betreiben müssen.

Insbesondere in dem Bereich, wo uns die Aufgabe des Betriebs von extern erstellten Anwendungen obliegt, machen wir gerade ein paar Erfahrungen, die ich hier gerne aus meiner persönlichen Sicht teilen möchte.

Beginnen möchte ich mit der insgesamt positiven Erfahrung, die ich mit meinem Wochenendprojekt „Kanboard im Container…“ gemacht habe. Hier laufen eine Anwendung und eine Datenbank jeweils als Container in einem Pod auf einem RHEL 8 Host mit einer Rootless-Podman-Installation und einem Reverse-Proxy. Die Dokumentation von Red Hat und dem Kanboard-Projekt sind hinreichend genau und verständlich, um diese Anwendung ohne große Mühe zu betreiben. Ohne große Verrenkungen kann ich unterschiedliche Versionen aus dem Postgres-Container-Repo ausprobieren und verschiedene Releases der Anwendungen testen.

Leider hat man nicht immer soviel Glück. Ein anderes Software-Projekt, dessen Namen ich hier bewusst nicht nenne, liefert eine kleine Sammlung von Bash-Skripten aus, welche in einer bestimmten Reihenfolge auszuführen sind, um zur Laufzeit eine Docker-Compose-Datei zu generieren, auf deren Basis dann entsprechende Container gestartet werden. Wenn nun ein Update ansteht, ist der ganze Prozess mit der Ausführung der Bash-Skripte in wohldefinierter Reihenfolge erneut durchzuturnen. Das ganze lässt sich ausschließlich auf einem Host mit einer Docker-Installation ausführen und ist zu Podman inkompatibel. Ob es auch mit einer Rootless-Docker-Installtion läuft, ist noch zu testen. Ein Deployment auf einem Kubernetes-Cluster ist undenkbar. Das Projekt stellt keinerlei Informationen dazu bereit.

Übrigens handelt es sich bei diesem Projekt nicht um ein 1-2 Personen FOSS-Projekt, sondern um eines, hinter dem ein Unternehmen steht, welches kostenpflichtige Support-Verträge für seine Anwendung vertreibt.

Es bleibt also wieder mal nur, die eigene Umgebung der Anwendung anzupassen, die sich andernfalls nur mit extrem hohen Aufwand integrieren lässt. Das kennen wir schon aus dem Zeitalter vor der Container-Erscheinung. Es ist in diesem Fall halt etwas anders, aber nicht besser.

In einem anderen Fall blieb das Erfolgserlebnis aus ähnlichen Gründen aus. Der Container mit der gewünschten Anwendung lies sich nicht in die Zielumgebung integrieren, da ein für die Kommunikation benötigtes Software-Modul fehlt. Erste Aussage des Herstellers: „Da müssen sie noch Paket XY im Container nachinstallieren.“

Halt Stopp! Sollten mit dem Container nicht alle notwendigen Abhängigkeiten mit ausgeliefert werden? Jetzt sollen wir Software im Container nachinstallieren, was zur Folge hat, dass wir damit ein neues Image erzeugen, welches wir zukünftig wieder selbst weiterpflegen dürfen? So habe ich mir die schöne neue Welt aber nicht vorgestellt. Den Aufwand mit den eigenen Anpassungen haben wir ohne Container auch. Auch hier wird es erstmal nur anders, aber nicht besser.

Allerdings möchte ich zur Ehrenrettung des Anbieters hinzufügen, dass er das fehlende Modul in sein Image einbauen und zukünftig selbst pflegen und ausliefern möchte und uns hier lediglich um Unterstützung beim Test bittet. Dies ist für mich im Sinne von FOSS und vollkommen akzeptabel. Wir wissen allerdings noch nicht, ob der Anbieter sein Versprechen hält.

Wo ist nun das Dilemma?

Ich persönlich habe eine Präferenz, wie Betriebsplattformen für Container aussehen sollten. So sehe ich die Nutzung von Rootless-Podman für einfache Anwendungen und Kubernetes bzw. Kubernetes-kompatible Lösungen für die Orchestrierung als sinnvoll an.

Leider kann ich mir nicht immer aussuchen, welche Software es zu betreiben gilt. Allzu oft muss mit dem gearbeitet werden, was bestellt bzw. geliefert wurde. Und hier sind die Probleme fast so zahlreich wie außerhalb der Container-Welt. Die einen laufen nur mit Docker, aber nicht im Rootless-Modus. Die anderen verlangen eine Docker-Swarm-Umgebung und Kubernetes mögen sie beide nicht. Das ist halt Pech.

Manchmal lassen sich die gelieferten Container auch ganz einfach starten, dafür aber überhaupt nicht in bestehende Umgebungen integrieren. So kann es schon in Arbeit ausarten, wenn man den voreingestellten Datenbank-Container herausoperieren muss, um den vorhandenen Datenbank-Cluster nutzen zu können.

Ein wenig neidisch blicke ich dabei zu Berufskollegen, die eigene Softwareentwicklung betreiben und von den Vorzügen ihrer Kubernetes-Cluster schwärmen.

Allerdings stehe ich mit meinen Erfahrungen noch ganz am Anfang und lasse mich gerne überraschen, was die Zukunft noch bringt.

Was habt ihr für Erfahrungen im Umgang und mit dem Betrieb von Containern gemacht? Könnt ihr hier Geschriebenes in Teilen nachvollziehen oder sind eure Erfahrungen völlig anderer Natur? Ich freue mich auf eure Beiträge in den Kommentaren und per E-Mail.

Bis bald im schönen neuen Container-Land.

29. August 2021

Problem

Vor etwas weniger als einem Jahr bloggte ich bereits über mein Webcam-Setup, wo ich beschrieb, wie man eine Canon DSLR per Mini-USB unter Linux zum Laufen bringt. Das funktioniert zwar technisch, hatte aber ein paar Einschränkungen und Dinge, die mich nervten, weshalb ich das Setup wieder umgebaut habe. Hauptproblem: Das Setup braucht ein geladenes Kernel-Modul und bei jedem Anschalten der Kamera musste eine lange Befehlskette neu gestartet werden. Zudem war es nur das Preview-Bild was abgegriffen wurde. Das entsprach dann einer Auflösung von lediglich 960x640.

Hardware

Praktischer ist daher die Nutzung des HDMI-Ausgangs über ein HDMI-Capture Stick. Ich nutze dafür den Elgato Cam Link 4K. Der Stick wird direkt als Webcam identifiziert und kann ohne Probleme in jegliche Videokonferenztools genutzt werden.

Theoretisch wäre dieser Blogpost schon zu Ende. Allerdings fiel nach dem ersten Betrieb schon ein Problem auf: Über den HDMI-Ausgang wirft meine Canon 700D kein sauberes Bild aus, da dort typische Kamera Einstellungen und Darstellungen auf dem Bildschirm dargestellt werden, die auch über HDMI ausgegeben werden. Größeres Problem allerdings: Die Kamera schaltet den Live-View Modus nach 30min automatisch ab. Somit ist es nicht sonderlich gut nutzbar, dies war über USB nämlich kein Problem.

Magic Lantern

Zu dem Problem gibt es aber eine weitere Lösung: Mit Magic Lantern, eine Open Source Firmware für diverse Canon Kameras. Die Firmware wird dabei von der SD-Karte gestartet, nachdem man zuvor das passende Firmware-Update für die Kamera selbst installiert hat. Scheinbar gibt es aber für Magic Lantern selbst seit 3 Jahren keine Updates mehr. Für meinen Zweck ist das noch verkraftbar.

In den Einstellungen von Magic Lantern lassen sich dann extremst viele Konfigurationen einstellen, um mehr aus der Kamera herauszuholen zu können. In meinem Fall war ich da lediglich daran interessiert, das Auto-Abschalten des Live-Views zu deaktivieren.

Einschränkungen

Auch mit diesem Setup gibt es ein paar Einschränkungen, sonst wäre es ja langweilig. So hat das Live-View Bild im P-Modus der Kamera eine schwarzen Kasten, der auch so über HDMI ausgegeben wird. Im Automatik-Modus ist das zum Glück nicht der Fall, aber auch da hat man zumindest am linken und rechten Rand schwarze Balken, was dem Kamera-Format geschuldet ist. Dies kann man, wenn man möchte, über Software wie OBS croppen, aber das möchte ich in meinem Fall nicht.

Reguläre Webcams sind immerhin mittlerweile lieferbar zu bezahlbaren Preisen, im Gegensatz zum letzten Jahr. Ich bleibe nun erstmal bei dem Setup, alles andere wäre schließlich zu einfach (und zu günstig).

Viele Linux-Anwender haben einen gewissen missionarischen Eifer, ihre Erleuchtung in die Welt zu tragen. Doch entstehen dadurch neue mündige Linux-Anwender oder nur Abhängigkeiten?

Die ideologische Überhöhung von FOSS, die das Selbstverständnis, ein besseres System zu nutzen, das Verlangen nach dem Gang durch die Wüste nun auch andere in den Genuss der Erfahrung zu bringen – was es auch immer ist: Viele Linux-Anwender neigen dazu wie Wanderprediger um die Häuser zu ziehen und andere Anwender von dem System zu überzeugen. Deutlich mehr als Windows- oder macOS-Nutzer, die den armen Linux-Anwendern auch nicht andauernd die Segnungen ihres Systems aufdrängen möchten.

Kürzlich war ja der 30. Geburtstag von Linux und im Internet gibt es gerade zig lustige und unterhaltsame Geschichten, wie man selbst zu Linux gekommen ist. Das ist spannend, aber auch irritierend. Denn oft ergänzen Geschichten, wie man die Familie, die Oma und den Hund gleich mit gesegnet hat.

Mich würden da mal wirklich ehrliche Erfahrungen interessieren. Sind dadurch mündige Linux-Anwender entstanden oder letztlich nur von euch abhängige Netzwerke und diese kleine Linux-Nutzergemeinschaft würde in dem Moment erodieren, in dem ihr nicht mehr da seid oder vielleicht selbst das Betriebssystem wechselt?

Ich bin solchen Vorhaben, Linux anderen aufzudrängen, sehr kritisch gegenüber eingestellt. Aber vielleicht sehe ich das auch völlig falsch?

Der Artikel Was bleibt vom missionarischen Eifer? erschien zuerst auf [Mer]Curius

28. August 2021

Es gibt viele Wege Anwendungen und Konfigurationen in einen Kubernetes Cluster zu bringen.

Der Weg ueber Helm3 gefaellt mir besonders fuer third Party Software. Man fuegt das entsprechende Repository zu Helm hinzu, passt die Variablen ueber eine Konfigurationsdatei oder Parameter an und installiert das Chart. Der Uninstall Befehl hinterlaesst den Cluster meist besenrein.

Falls Dir das Thema Kubernetes fremd ist kannst Du innerhalb von ca 5. Minuten einen MicroK9s Cluster mit diesem Tutorial installieren und meine Schritte durchgehen. Es wird ein Monitoring Stack mit Grafana und den Backends Loki + Prometheus sowie einigen Dashboards installiert und konfiguriert. Hier die Dokumentation von den Grafanalabs.

Repo hinzufuegen

# Bitte das Kommando microk8s.helm3 statt helm3 verwenden falls Du microk8s nutzt.
helm3 repo add grafana https://grafana.github.io/helm-charts
helm3 repo update

Grafana, Loki, Prometheus, Fluent.d und den Alertmanager installieren

Um eine Anwendung zu testen starte ich gerne auf der Kommandozeile und Default Parametern in den Namespace

# Namespace anlegen microk8s.kubectl statt kubectel verwenden falls Du microk8s nutzt.
kubectl create  namespace monitoring

helm upgrade --install loki grafana/loki-stack \
  --set fluent-bit.enabled=true,promtail.enabled=false,grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=false

Nach ein paar Minuten sollten alle Pods hochgefahren sein und die Anwendung verfuegbar und man kann sich ein nacktes Grafana anschauen

# Passwort besorgen 

kubectl get secret --namespace monitoring loki-grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

# Port forwarden 
kubectl port-forward --namespace monitoring service/loki-grafana 3000:80


Jetzt solltest Du dich auf http://localhost:3000/ mit username: admin und dem Passwort aus der Commandline anmelden koennen.

Anwendung loeschen

microk8s.helm3 uninstall loki  -n monitoring

Anwendungskonfiguration als Yaml File

Cli Parametern sind pratkisch um mal etwas auszuprobieren aber bei komplexeren Einstellungen wird es schnell unuebersichtlich und eine Textdatei die man Versionieren kann ist ungemein praktischer. In ~ 50 Zeilen Yaml kann man die gleichen Einstellungen deployen mit ein paar Extras wie:

  • Plugins installieren
  • Admin Passwort setzen (bitte nur auf localhost so laufen lassen)
  • Vorgefertigte oder selbst erstellte Dashboards installieren

values.yaml

fluent-bit:
  enabled: true
promtail:
  enabled: false
grafana:
  enabled: true
  persistence:
    enabled: false 
  adminPassword: 1q2w3e4r
  plugins:
  - grafana-piechart-panel
  dashboardProviders:
    dashboardproviders.yaml:
      apiVersion: 1
      providers:
        - name: default
          orgId: 1
          folder:
          type: file
          disableDeletion: true
          editable: false
          options:
            path: /var/lib/grafana/dashboards/default
  dashboards:
    default:
      Logging:
        gnetId: 12611
        revison: 1
        datasource: Loki
      K8health:    
        gnetId: 315
        revison: 1
        datasource: Prometheus
      ApiServer:  
        gnetId: 12006
        revison: 1
        datasource: Prometheus
prometheus:
  enabled: true
  server:
    persistentVolume:
      enabled: false
  alertmanager:
    persistentVolume:
      enabled: false

Nun den Stack erneut installieren

microk8s.helm3 upgrade --install --namespace=monitoring loki grafana/loki-stack  -f values.yaml

Analog zu den Dashboards koennen alle moeglichen und unmoeglichen Settings der Anwendung, Versionen bis zu persistant Volumes konfiguiert werden. Mir gefaellt besonders, dass wesentlich weniger Yaml produziert werden muss als z.B. bei Kustomize und man sehr schnell von „ich bastel ein wenig rum“ in den Zustand „ich habe eine wiederverwendbare Komponente die ich leicht modifizieren kann“ iterieren kann. Im naechsten Schritt kann man dann z.B. mit ArgoCD wunderbar continuous Delivery betreiben.

Der Beitrag Helm Charts verwenden erschien zuerst auf Unerklärliches am Rande.

Die Standard-Kommandozeile Bash bei Kubuntu (wie auch bei vielen anderen Linux Distributionen) hat eine sehr praktische History bzw ein Verlauf, welche Befehle man so eingegeben hat.

 

Die entsprechende Datei heisst .bash_history (mit einem vorangehenen Punkt - weil es sich um eine versteckte Datei handelt) liegt im Benutzerverzeichnis z.B. /home/hoergen/.bash_history

 

Die gesamte History (Verlauf) auflisten mit dem Befehl: history
Dann wird ein Liste der Eingaben mit vorangestellter Zeilennummer ausgegeben.

 

Das können unter Umständen sehr viele Zeilen sein. Wenn man nach dem Befehl eine Zahl angibt, so werden die letzten Zeilen der History (Verlaufs) angezeigt wie z.B. history 8 zeigt die letzten 8 Zeilen der History an.

Damit man z.B. den Befehl aus der gefundenen Zeile nicht nocheinmal eingeben muss, kann man zur Abkürzung die Zeilennummer mit einem vorangestellten Ausrufezeichen verwenden z.B. !1500

 

In der History kann auch gesucht werden

  • Suchen - Strg+r - und anfangen zu tippen
  • Weitersuchen - nochmal Strg+r drücken
  • Zeile aus der Suche übernehmen und starten - Eingabe Taste drücken
  • Zeile aus der Suche übernehmen und etwas ändern - Ende- oder Pfeil nach rechts Taste

 

Und zum Korrigieren sind diese Tastenkürzel hilfreich

  • Will man die Zeile löschen und ist am Anfang der Zeile: Strg+k
  • Will man die Zeile löschen und ist am Ende der Zeile: Strk+u
  • Will man die zuvor gelöschte Zeile wieder herstellen: Strg+y
  • Das nächste Wort löschen Alt+d
  • Das vorherige Wort löschen Strg+w

 

In der Zeile bewegen

  • Pos 1 oder Strg+a springt an den Zeilenanfang
  • Ende oder Strg+e springt an das Zeilenende
  • Alt+f springt ein Wort vorwärts (Forward)
  • Alt+b springt ein Wort zurück (Back)

 

Es gibt noch wesentlich mehr Kürzel und Befehle, die sich mit der History der Bash beschäftigen. Was sind eure Highlights?

 

 

 

 

27. August 2021

Die MZLA Technologies Corporation hat Thunderbird 91 veröffentlicht. Die neue Version des Open Source E-Mail-Clients ist nach eigenen Angaben das größte Thunderbird-Update der letzten Jahre.

Neue Version zum Download verfügbar, Updates jedoch später

Thunderbird 91 steht zum Download bereit. Ein automatisches Update von Thunderbird 78 oder älter steht zu diesem Zeitpunkt aber noch nicht zur Verfügung. Das wird wieder, wie in der Vergangenheit, erst einige Wochen später erfolgen.

Neuerungen von Thunderbird 91

Multiprozess-Architektur

Die Multiprozess-Architektur (Electrolysis, e10s), an der Mozilla einige Jahre gearbeitet hatte, brachte Vorteile für die Performance, Stabilität und Sicherheit des Firefox-Browsers. Der E-Mail-Client Thunderbird, welcher auf der Mozilla-Plattform basiert, nutzte bislang nur einen Prozess. Mit Thunderbird 91 erhält auch Thunderbird eine Multiprozess-Architetktur und profitiert damit ebenso von diesen Vorteilen, wobei das Thunderbird-Team vor allem die verbesserte Performance hervorhebt.

Native Unterstützung von Apple Silicon M1 (ARM64)

Seit November 2020 gibt es die ersten Computer, welche mit dem Apple M1 auf der neuen Silicon-Plattform von Apple basieren. Die Trennung von Intel geht einher mit einem Wechsel der Prozessor-Architektur von x86-64 zu ARM64. Während Thunderbird 78 noch über Apples Rosetta 2 für ARM64 emuliert worden ist, läuft Thunderbird 91 nativ auf Geräten mit dem neuen Apple-Prozessor, was ebenso deutliche Performance-Vorteile für entsprechende Nutzer verspricht.

Apple macOS 10.9 bis 10.11 werden nicht länger unterstützt

Während die neue Version Unterstützung für die neuesten Apple-Geräte bringt, wurden alte Zöpfe abgeschnitten: Das Betriebssystem Apple macOS in den Versionen 10.9, 10.10 sowie 10.11 wird nicht länger unterstützt. Entsprechende Nutzer erhalten dementsprechend auch kein Update auf Thunderbird 91 und können Thunderbird 91 auch nach manueller Installation gar nicht erst starten.

Thunderbird kann jetzt PDF-Dateien anzeigen

Thunderbird hat jetzt pdf.js integriert, den von Mozilla entwickelten Betrachter für PDF-Dateien, welcher auch Teil von Firefox ist. Damit müssen PDF-Dateien nicht mehr heruntergeladen und dann mit einem externen Programm geöffnet werden, um diese zu lesen.

Thunderbird 91

Vereinfachtes Einrichten neuer Mail-Accounts

Der Assistent zum Einrichten eines neuen Mail-Accounts wird nicht länger in einem Dialog, sondern in einem Tab geöffnet. Aber nicht nur optisch gab es Verbesserungen. Auch werden bestehende und mit der E-Mail-Adresse verknüpfte Kalender und Adressbücher erkannt und können mit einem Klick eingerichtet werden. Nach der Einrichtung eines Accounts schlägt der Assistent weitere optinale Aktionen vor, wie das Anlegen einer Signatur der Ende-zu-Ende-Verschlüsselung für die E-Mails.

Thunderbird 91

Thunderbird 91

Thunderbird 91

Verbessertes Einfügen von Dateianhängen

In neue E-Mails eingefügte Dateianhänge werden nun unten im Fenster angezeigt und haben dort mehr Platz, so dass mehr Anhänge und auch die Dateinamen besser sichtbar sind als vorher. Beim Ziehen einer Datei in das Nachrichtenfenster zeigt Thunderbird jetzt ein Overlay an, welches dem die Nutzer die Wahl gibt, die Datei direkt in die E-Mail einzubetten, beispielsweise bei einem Bild, oder als Anhang mitzusenden.

Thunderbird 91

Dichte-Option

Im Menü unter Ansicht > Dichte gibt es jetzt eine sichtbare Option, um gewisse Elemente der Benutzeroberfläche etwas kompakter oder etwas größer (empfohlen für Geräte mit Touch-Bildschirm) darzustellen.

Thunderbird 91

Kalender-Verbesserungen

Der Kalender hat in Thunderbird 91 natürlich auch Verbesserungen erhalten. Vor allem die Verwaltung mehrerer Kalender in der Seitenleiste wurde verbessert. So gibt es nun eine Schaltfläche zum schnellen Aktivieren von deaktivierten Kalendern sowie ein Symbol zum Ein- und Ausblenden von Kalendern. Schreibgeschützte Kalender sind jetzt als solche erkennbar. In der Kalender-Ansicht selbst wird der aktuelle Tag nun farblich besser hervorgehoben. ics-Dateien können jetzt per Doppelklick geöffnet werden. Auch das Öffnen von webcal:-URLs in Thunderbird wird jetzt unterstützt.

Sonstige Neuerungen

Der Dark Mode von Thunderbird hat weitere Verbesserungen erhalten und zeigt nun weitere Dialoge dunkel an, die vorher noch hell waren.

Thunderbird unterstützt jetzt CardDAV-Adressbücher. Auch auf Outlook-Kontakte kann jetzt zugegriffen werden. Dafür muss in der erweiterten Konfiguration der Schalter ldap_2.servers.outlook.dirType auf 3 geändert werden. Das Thunderbird-Team warnt davor, dass dies die Startzeit von Thunderbird negativ beeinträchtigen kann.

Neu ist auch die nun plattformübergreifend gleich aussehende Drucken-Ansicht, welche der bereits aus Firefox bekannten Drucken-Ansicht entspricht.

Thunderbird 91

Die Reihenfolge der Mail-Accounts kann in den Konto-Einstellungen jetzt jederzeit via Drag and Drop geändert werden.

Antwortet der Nutzer auf eine E-Mail, welche von einer noreply-Adresse kommt, zeigt Thunderbird jetzt eine Warnung an, dass die E-Mail wahrscheinlich von niemandem gelesen werden wird.

Beim Schreiben von E-Mails werden E-Mail-Adressen, die sich in keinem Adressbuch befinden, mit einem Punkt gekennzeichnet. Die An-, CC- sowie BCC-Felder können jetzt auch via Tastatur-Shortcut erreicht werden.

.eml-Dateien mit X-Unsent: 1-Header öffnet Thunderbird nun direkt im Bearbeiten-Modus. Nicht-ASCII-Zeichen in Empfänger-Adressen werden von Thunderbird jetzt unterstützt.

In der Add-ons-Verwaltung können jetzt Vorschläge für Alternativen zu inkompatiblen oder nicht länger gepflegten Erweiterungen angezeigt werden.

Die Chat-Funktion unterstützt jetzt auch Matrix-Server (Beta-Unterstützung). Dafür muss in der erweiterten Konfiguration der Schalter chat.prpls.prpl-matrix.disable auf false gesetzt werden.

Und noch sehr viel mehr…

Dies war nur eine Auswahl der größen Highlights von Thunderbird 91. Darüber hinaus gab es noch zahlreiche weitere kleinere Verbesserungen sowie Fehlerbehebungen, welche sich in den Release Notes (engl.) nachlesen lassen. Und natürlich wurden auch wieder diverse Sicherheitslücken geschlossen.

Thunderbird 91.0.1

Mit dem Update auf Thunderbird 91.0.1 wurde eine Sicherheitslücke behoben. Außerdem hatte die OTR Chat-Verschlüsselung mit der 32-Bit-Version von Windows nicht funktioniert.

Thunderbird 91.0.2

Thunderbird 91.0.2 bringt eine neue Option für die erweiterte Konfiguration (mail.biff.show_badge), um die Anzahl ungelesener Nachrichten im Taskleisten-Icon unter Windows zu deaktivieren. Im Mail-Filter-Editor werden Tags jetzt farbig dargestellt. Auf macOS nutzt Thunderbird nun ein quadratisches App-Icon im Dock, wie es neuer Standard seit macOS 11 ist. Dazu kommen noch diverse weitere Bugfixes (engl.).

Thunderbird 91.0.3

Thunderbird 91.0.3 ist ein weiteres Bugfix-Update, welches einige Fehlerbehebungen (engl.) bringt.

Der Beitrag Thunderbird 91 mit vielen Neuerungen veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Fr, 27. August 2021, Marco

Die Linux-Distribution Alpine Linux wurde in der Version 3.14.2 veröffentlicht. Alpine Linux ist eine leichtgewichtige Distribution, welche oft in Containern verwendet wird und einen besonderen Fokus auf die Sicherheit legt. Dies merkt man auch an den Änderungen dieser Version, da neben normalen Aktualisierungen auch einige Sicherheitsaktualisierungen in diese Version geflossen sind.

Das Entwicklerteam beschreibt in der Ankündigung, dass die kürzlich bekannt gewordenen Sicherheitslücken von OpenSSL in dieser Version behoben sind. Ausserdem wurde die Programmiersprache Rust aktualisiert, sodass eine Schwachstelle im Zusammenhang mit IPv4-Adressen nicht mehr ausnutzbar sein sollte. Genauere Details zur Schwachstelle lassen sich in den Advisories hier nachlesen. Dies hat zur Folge, dass unterschiedliche Programme, welche in Rust geschrieben wurden, neu kompiliert wurden. Neben Rust wurden zudem die Programmiersprachen Go, Ruby und PHP aktualisiert.

In der Version 3.14.2 von Alpine Linux wurden auch unterschiedliche weiteren Pakete aktualisiert. So wurde die Codehosting-Plattform Gitea auf die Version 1.14.6, der XMPP-Server Prosody auf die Version 0.11.10 und der Webbrowser Firefox auf die Version 78.12.0 angehoben. Die Pakete nextcloud und nextcloud20 stehen nun in den Versionen 21.0.4 respektive 20.0.12 zur Verfügung. Die Liste aller Neuerungen kann im Gitlog eingesehen werden. Wer die neuste Version von Alpine Linux ausprobieren möchte, kann sich die ISO-Dateien von der offiziellen Webseite für unterschiedliche Architekturen herunterladen

Quellen:

26. August 2021

Linux wird 30 und von allen Seiten kommen die Glückwünsche. Zurecht, denn Linux ist eine riesige Erfolgsgeschichte und weiterhin unfassbar großem Potenzial. Wenn man den Blick auf den Kernel und freie Software als Idee verengt.

Beginnen wir diesen Artikel mit einem fröhlichen Einstieg. Linux ist eine gewaltige Erfolgsgeschichte. Linux hat die Idee, ein Haufen unabhängiger Entwickler könnte gemeinsam ein solches Projekt erstellen, erst salonfähig gemacht. Nebenbei hat Linux die FOSS-Community aus dem GNU-Keller geholt. Linux läuft heute auf so vielen Geräten, das man schon die Geräteklassen nicht mehr aufzählen kann. Von der Nähmaschine bis zum Supercomputer. 80 % der Verbraucher in Deutschland tragen in jedem Moment ein Gerät mit Linux-Kernel in ihrer Hosentasche, Hand an einem Halsband. Es ist der Kern des IoT.

Das ist eine Erfolgsgeschichte des Kernels und der Idee, freie Software zu schaffen. Viele der zahllosen Gratulationsartikel zielen mit Fug und Recht genau darauf ab.

Definition Linux vs. Linux

Daneben gibt es noch Linux als Bezeichnung für ein vollwertiges freies Betriebssystem, das über den Kernel hinaus geht. Natürlich um Linux als Kernel herum aufgebaut mit vielen weiteren Tools, die oft aus dem GNU-Universum stammen, freien grafischen Shells zur Bedienung und freien Endanwenderprogrammen. Um dieses System ist es weit weniger gut bestellt und darüber soll es in diesem Beitrag gehen.

Wir tun uns mit Definitionen dessen, was Linux ist schwer. Das macht es leicht, argumentative Nebelkerzen zu werfen und zu behaupten, Linux sei megaerfolgreich. Denn – siehe oben – es läuft ja auf Milliarden Geräten. Denn der Kernel läuft auf Milliarden Geräten.

Linux als Betriebssystem ist nach vielen Definitionen mehr als der Kernel. Es ist ein freies System aus Kernel, vielen GNU-Userland Tools, freien Shells („Desktopumgebungen“) zur menschlichen Interaktion und vielen Programmen, die das Ganze erst sinnvoll nutzbar machen. Ausgeliefert in Form von Distributionen läuft das auf Millionen Geräten weltweit. Diese Betriebssysteme existieren für Server, für Desktops bzw. Notebooks und in kleinen Nischen auch für andere Geräteklassen.

Sie sind zu unterscheiden von manchen IoT-Systemen oder auch Android, wo ein Linux-Kernel in einem völlig anderen System läuft, das absolut gar nichts mit den oben genannten Systemen gemein hat, außer eben den gleichen Kernel zu nutzen.

Zur Hälfte erfolgreich und hoch spezialisiert

Dieses beschriebene System läuft vor allem auf zwei Geräteklassen: Servern und Desktop bzw. Notebooksystemen (im weiteren einfach Desktops genannt). Rund um 2005-2005 als sich das heutige Linux-Ökosystem stabilisierte, gab es auch nichts anderes, was bis in die Gegenwart überdauert hätte.

Bei Server ist es unfassbar erfolgreich. Davon profitierte Linux auch in anderen Bereichen, denn ohne diesen Erfolg wären viele Entwicklungen undenkbar gewesen. Wie lange das noch so weitergeht weiß niemand. Die Synergien zwischen Server-Systemen und Desktop-Systemen sind überschaubar. Je spezieller die Server-Setups, desto weniger wird die dortige Entwicklung für den Desktop noch fruchtbar sein. Der Server-Part des Linux Betriebssystems entwickelt sich zudem immer stärker in eine Richtung, die Kritiker „Corporate Linux“ nennen. Wie viel der FOSS-Gedanke dort in Zukunft noch bedeutet, bleibt abzuwarten.

Wo FOSS als Ideal sicher noch eine große Rolle spielt ist der Desktop-Part des Betriebssystems Linux. In der Nische Desktop hat man sich über die letzten zwei Dekaden hoch spezialisiert. Interessanterweise hat sich der weniger erfolgreiche Teil von Linux als Betriebssystem mehr aufgespalten als der erfolgreiche Part. Es gibt jedenfalls nicht 200 Enterprise-Distributionen für Server. Über Ursache und Wirkung könnte man hier mal nachdenken. Wir dem auch sei: Für den Desktop gibt es hunderte Distributionen, zig Desktopumgebungen, noch mehr Alternativen bei den Endanwenderprogrammen. In Darwins Evolutionstheorie wäre Linux auf dem Desktop dieses eine hoch spezialisierte Wesen, das seine perfekte Nische gefunden hat bzw. sich perfekt an diese angepasst hat.

Das Problem ist nur: Das Ökosystem verändert sich, denn neue Geräteklassen kommen auf. Smartphones, Tablets, Smartwatches usw. usf. Linux in all seiner Spezialisierung war darauf nicht vorbereitet und hat sich nicht schnell genug angepasst. Linux als vollwertiges Betriebssystem ist abgesehen vom Server-Part festgenagelt auf dieser einen Geräteklasse: Desktop. Diese Geräteklasse wächst kaum noch, ihr Ende wird immer mal wieder vorhergesagt, ist dennoch mittelfristig unwahrscheinlich, aber sollte es so kommen, käme es plötzlich. Das haben all die plötzlichen Brüche in den letzten Jahren gezeigt.

Erfolge in der Nische?

Das drohende Ende des Desktops mal kurz beiseite gewischt. Wenigstens sagen manche, gegenwärtig sei das kein Problem, denn dafür ist Linux erfolgreich in seiner Nische. Dahinter möchte in ein großes Fragezeichen setzen. In den ganzen Meldungen über eine neue Distribution hier, eine neue Desktopumgebung dort und eine neue Version hier und da verliert man manchmal den Überblick. Man sieht den Wald vor lauter Bäumen nicht mehr.

Was war der letzte große Erfolg von Linux auf dem Desktop? Also ein Quantensprung, bei dem viele sagten, dass dies Linux insgesamt vorangebracht habe. Ich musste lange darüber nachdenken und kam zum Schluss, dass dies vermutlich die Verfügbarkeit von Steam für Linux war. Das war 2013. Das größte Erfolgsprojekt davor war vermutlich Ubuntu, das Linux für viele erst Salonfähig gemacht hat, bis heute ein Synonym für Linux bei vielen Menschen ist und vermutlich auch immer noch die Distribution mit der größten Reichweite darstellt.

Ich würde mich sehr über Kommentare mit Erfolgen seit 2013 freuen. Mir sind keine eingefallen.

Risiken nicht zu knapp

Es gibt diese romantische Vorstellung von einer Gemeinschaft, die Software entwickelt und dann kollaborativ ein super Produkt schafft. Im Kernel mit seinen vielen Entwicklern, die für ganz unterschiedliche Firmen arbeiten oder vielleicht sogar ehrenamtlich tätig sind, kommt das vielleicht am ehesten zum Tragen.

Diese Vorstellung hat nur nicht viel mit der Realität gemein. Ich hatte das bereits in einem anderen Artikel aufgedröselt. Das gilt nicht für den Server-Part mit seinen vielen Firmen und angestellten Entwickler, aber auch der Linux-Desktop hängt ganz zentral von wenigen Firmen ab. Diese haben einen enormen Einfluss auf wichtige Projekte und die dort angestellten Entwickler stemmen einen Großteil der Arbeit.

Der Server-Part läuft gut, die Firmen in dem Segment fahren gute Gewinne ein, werden auch weiter investieren und Entwicklungen voran treiben. Wobei es auch da durch die Konsolidierung von AWS, Azure & Co bedrohliche Perspektiven gibt. Im Kapitalismus sind Gewinnmöglichkeiten aber eine mächtige Triebfeder und nur ein Narr würde für den Server-Part von Linux schwarz malen.

Der Desktop-Part hat deutlich schlechtere Aussichten, weil er subventioniert wird. Red Hat (IBM) dominiert GNOME und ist zentral für wichtige Projekte wie systemd, PolicyKit, Flatpak, Wayland, X.Org usw. usf. Zusammen mit Collabora ist Red Hat auch immens wichtig für die Weiterentwicklung von LibreOffice. Für Privatanwender wichtiger ist Canonical, ohne dessen Arbeit Ubuntu nicht existieren würde und die der eher losen Ubuntu-Community das Rückgrat einziehen. Spielen auf dem Linux-Desktop kann man ohne Steam faktisch vergessen. Mozilla stellt mit Firefox den wichtigsten Browser für Linux-Nutzer zur Verfügung (gemessen am Standard der Distributionen) und der zweite wichtige Browser kommt von Google. Wie stabil die Weiterentwicklung von KDE ohne bluesystems wäre, darf man auch getrost bezweifeln. Zumal KDE auf Qt als Basis angewiesen ist, genau wie LXQt und viele weitere Projekte. Ein Toolkit, das von einer kommerziell agierenden Firma entwickelt wird.

Darum herum gibt es natürlich viele Freiwillige und zahllose Projekte, die ganz oder größtenteils ehrenamtlich entwickelt werden. Doch man muss kein großer Pessimist sein, um sich zu fragen, ob diese Projekte ohne diesen Kern wirklich eine große Zukunft hätten. Ein kleines Experiment gab es da ja bereits. In die mobilen Pläne der Community haben sich diese Firmen, abgesehen von Canonical nie eingemischt. Das Ergebnis sehen wir ja gerade.

Was eint alle diese Firmen? Sie verdienen mit Linux auf dem Desktop kein Geld. Red Hat ist da noch nahe dran durch sein Enterprise-Geschäft, aber Server-Infrastruktur und Desktop entfernen sich immer weiter. Die Synergien sind überschaubar. Canonical verdient an den Privatkunden sowieso nichts. Collabora hat jüngst die finanziellen Schwierigkeiten beklagt. Steams Linux-Projekte war alle Flops und Linux-Anwender machen nur 1 % der Nutzer aus – teure 1 %. Mozilla hängt am Tropf von Google, Ausgang ungewiss. Und auf Google ist kein Verlass, Projekte sterben dort wie die Fliegen und mit Fuchsia macht man erste Lockerungsübungen weg von Linux. Nicht zu vergessen die Probleme mit Qt und seiner Lizenzpolitik, durch die der Community gerade die LTS-Version von Qt genommen wurde. Das geschah sicher nicht, weil die Qt Company so richtig gute finanzielle Perspektiven hat.

Zusammengefasst

Linux wird 30 und der Kernel hat mit Sicherheit eine strahlende Zukunft vor sich. Das Entwicklungsmodell ist stabil und die Einsatzszenarien gewaltig. Man kann diesen Tag wirklich feiern und sehen, was die FOSS-Community in 30 Jahren erreicht hat.

Linux als Betriebssystem jenseits des Kernels hat da eine unsicherere Zukunft. Viele problematische Entwicklungen in den letzten Jahren, zahlreiche verpasste Chancen, Firmenübernahmen und Tendenzen jenseits der Einflussmöglichkeiten der Community haben einige Risiken entstehen lassen.

Am Server und im Enterprise-Segment mag das nicht so drastisch sein, weil hier noch genug Firmen gutes Geld verdienen, aber wie lange die Community noch von den Entwicklungen im Serverbereich profitieren kann, muss man abwarten. Zumal der Serverbereich unter dem Konsolidierungsdruck von AWS, Azure & Co auch noch interessante Entwicklungen durchlaufen könnte. Kubernetes & Co sind zudem nichts was ich am Desktop benötige. Von anderen Hardwareklassen mal ganz zu schweigen.

Die nächsten Jahre werden spannend für Linux als Betriebssystem und ich wünsche mir sehr, dass meine Bedenken alle grundlos waren und jene Kommentatoren recht behalten, die mir Miesepeterei vorwerfen.

Der Artikel Linux wird 30 – Als Betriebssystem am seidenen Faden? erschien zuerst auf [Mer]Curius

Do, 26. August 2021, Lioh Möller

Bei Escuelas LINUX handelt es sich um eine Linux-Distribution, die primär für den Einsatz im Bildungsumfeld konzipiert wurde. Dabei richtet sie sich sowohl an Schüler jüngeren und mittleren Alters als auch an Studierende.

Die Distribution basiert auf Bodhi Linux und nutzt den Enlightenment-Fork Moksha als Standard-Desktopoberfläche.

Bei der nun vorliegenden Version 7.1 handelt es sich um einen Point-Release der 7er Serie, welche von Bodhi Linux 6.0 abgeleitet wurde.

Viele der mitgelieferten Anwendungen wurden aktualisiert:

  • Audacity 3.0.2

  • Blender 2.93.3

  • Chromium/Google Chrome 92

  • eXe Learning 2.6

  • Firefox 91.0.1

  • Geogebra 5.0.650

  • Inkscape 1.1.1

  • GIMP 2.10.24

  • Kdenlive 21.04

  • LibreOffice 7.2

  • Scratch Desktop 3.25

  • Veyon 4.5.6

  • VLC 3.0.16

  • Wine 6.15

Die Distribution wurde laut der Initiatoren für den Online- und Offline-Einsatz entwickelt. Auch ausserhalb des schulischen Umfelds eignet sie sich durchaus als Desktop-Betriebssystem. Die aktuelle Version von Escuelas LINUX ist für 64bit x86 Rechner geeignet. Für Nutzer der 32-bit Architektur steht weiterhin der 6.x-Zweig zur Verfügung.

Quelle: https://sourceforge.net/p/escuelaslinux/blog/2021/08/escuelas-linux-71-64-bit-and-615-32-bit/