Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Einrichtung Proxmox

Beginnen wir mit den notwendigen Schritten im Proxmox Mail Gateway. Meldet euch dazu mit eurem root-Login im Webinterface an. Dieses erreicht ihr unter https://NameEuresServers:8006 - dort angemeldet werdet ihr vom Dashboard begrüßt. Wechselt nun in den Unterpunkt Mail Proy, den ihr unter Configuration vorfindet.

Relaying

Der erste Reiter lauter Relaying. Wir tragen dort als Default Relay den vollen Hostnamen der mailcow-Installation ein, so wie dieser auch von euch aufgerufen wird.
Disable MX lookup (SMTP) stellt ihr auf Yes um, die restlichen Einstellungen verbleiben bei den Standardwerten.

Relay Domains

Wir wechseln in den nächsten Reiter, Relay Domains. Über Create könnt ihr nun sämtliche Domains anlegen, die ihr auch in mailcow konfiguriert habt und die über das Mail Gateway laufen sollen.

Options (optional)

Im Reiter Options könnt ihr bei Bedarf die Message Size (bytes) hochsetzen, standardmäßig sind hier 10 MB hinterlegt, die ich für mich leicht erhöht habe. Ebenfalls kann hier auf Wunsch Greylisting deaktiviert werden.

Network

Im Reiter Network hinterlegt ihr die IP-Adresse eures mailcow-Servers. Somit weiß Proxmox Mail Gateway, dass der Server eine vertraute Zone ist.

TLS
Enable TLS unter dem Reiter TLS und schon geht es weiter.

DKIM (optional)
Wollt ihr DKIM verwenden könnt ihr das entweder über mailcow direkt oder aber Proxmox machen, entscheidet euch jedoch für eine Lösung. Solltet ihr bisher mailcow verwendet haben, aber auch DKIM über Proxmox nutzen wollen, löscht im mailcow-Interface den DKIM-Key der Domain, so dass mailcow diese nicht länger signiert.

Im Proxmox Interface setzt die Option Enable DKIM Signing auf Yes, hinterlegt einen Selector, in meinem Fall z.B. "dkim" und hinterlegt unter dem Punkt Sign Domains alle Domains, die per DKIM signieren sollen.

Das war es auf Seiten Proxmox. Wir wechseln zu mailcow.

Einrichtung mailcow

Im mailcow-Interface angemeldet, wechseln wir unter dem Punkt Konfiguration zum Reiter Routing. Interessant hier ist direkt der Punkt Senderabhängige Transport Maps.
Fügt dort euren Server mit der Proxmox-Installation nach dem Schema <euerProxmoxHostname>:26 hinzu. Eine Authentifizierung ist nicht notwendig. Anschließend sollte dieser in der Übersicht auftauchen.

Anschließend geht es in die Eigenschaften einer Domain unter Konfiguration -> E-Mail-Setup. Klickt auf Bearbeiten, der Domain, die ihr mit dem Mail Gateway nutzten wollt.
Setzt dort in der Variable Senderabhängige Transport Maps den eben eingerichteten Server und speichert die Änderungen.

Wie schon im Punkt DKIM unter Proxmox erwähnt, solltet ihr euch dafür entscheiden, Proxmox zur DKIM Prüfung und Signierung zu verwenden, löscht den DKIM-Key der Domain unter  Konfiguration -> Konfiguration -> ARC/DKIM-Keys.

Abschließende Anpassungen

Damit auch eingehende Nachrichten nun auf Spam und Viren geprüft werden, müssen versendene Mail-Server natürlich wissen, dass Proxmox nun als Eingangstor fungiert. Dazu müsst ihr den MX-Record eurer jeweiligen Domain im DNS auf den Proxmox-Server umbiegen. Im gleichen Zuge könnt ihr sofern notwendig auch euren DKIM-TXT-Record anpassen. Bei Proxmox findet ihr diesen in den DKIM-Einstellungen unter View DNS Record. Solltet ihr das Ganze erst einmal testen wollen, empfiehlt es sich temporär mit einer niederigen TTL zu arbeiten um im Fehlerfall schnell wieder die DNS-Records zu ändern.

Das war's auch schon, ab sofort fungiert eur Proxmox Mail Gateway als zusätzlicher Schutz vor Spam. Admininistrieren könnt ihr diesen ab sofort unter dem Punkt Administration im Proxmox Interface.

Linux und die Idee der freien Software sind eng verwoben. Proprietäre Software kann zwar theoretisch für Linux vertrieben werden, das ideologische Umfeld und die geringe Verbreitung haben hier aber kein großes Ökosystem entstehen lassen. Drei prominente Ausnahmen möchte ich hier kurz vorstellen. Im zweiten Teil: moneyplex von Matrica.

Für mich ist die Möglichkeit, Onlinebanking über eine eigene Software und nicht im Browser zu erledigen einer der großen Vorteile der deutschen Bankenlandschaft (siehe auch: Onlinebanking – HBCI/FinTS einfordern). Der Zugriff via HBCI/FinTS ist  nicht nur komfortabel, weil man alle Konten in einer Software sammeln kann, sondern auch noch sehr gut für die Sicherheit. Man umgeht den Browser mit seinen notorischen zahlreichen Sicherheitslücken. Weiterhin erschwert man bei unbedarften Anwendern Phishing-Angriffe. Diese erfordern schließlich immer einen Aufruf einer gefakten Internetseite. Ist der Anwender jedoch so konditioniert, dass er Banking nie über den Browser macht, fällt er deutlich weniger auf solche Angriffe herein. Ich wechsle inzwischen eher die Bank, als auf HBCI zu verzichten.

moneyplex Homebanking

Wenige Alternativen

Im Homebanking Bereich gibt es nur wenige Alternativen. Die Ursache dafür dürfte in den vielen nationalen Spezifika in diesem Bereich liegen. Die mächtige HBCI-Schnittstelle gibt es nur in Deutschland, weshalb sich auch nur deutsche Nutzer und Entwickler dafür interessieren dürften. Die Schnittstelle soll zudem nicht ganz trivial in der Implementierung sein, weshalb das nichts für ein kleines GSoC Projekt oder eine Wochenendarbeit ist. Ständige Veränderungen erfordern trete Anpassungsleistungen. Unter Linux gibt es eigentlich nur zwei Möglichkeiten in drei Ausprägungen. KMyMoney und GnuCash greifen jeweils auf aqbanking zurück und daneben gibt es noch Hibiscus.

KMyMoney und GnuCash sind zwar mächtige Werkzeuge, aber die HBCI-Implementierung mittels aqbanking ist eine hakelige Geschichte. Die Synchronisation ist fehleranfällig, Überweisungen klappen nicht oder nicht zuverlässig und die Möglichkeit, nachträglich Buchungen im Verlauf zu manipulieren, disqualifiziert die Software im professionellen Einsatz. Um die Ausgaben für den Privatgebrauch im Blick zu behalten und ggf. automatisiert auszuwerten ist die aqbanking Implementierung ganz nett, da sie den manuellen Import des Zahlungsverkehrs erspart – mehr aber auch nicht.

Hibiscus hat seine Fanbasis. Ich persönlich bin mit dem Programm wegen der Java-Basis und der schwierigen Oberfläche nie warum geworden.

moneyplex von Matrica – kurz vorgestellt

Matrica gehört fast schon zu den Dinosauriern auf dem Markt. Die Firma gibt es seit 1998 – ein Umstand, den man Webauftritt und Softwaregestaltung deutlich anmerkt. Ich hatte das Programm nie wirklich auf dem Schirm, aber wurde in den Kommentaren unter einem Artikel (siehe: Wechselhürden zurück zu Linux) mal darauf aufmerksam gemacht. Als bei meiner Rückkehr zu Linux KMyMoney sich (nicht nur im Vergleich zu MoneyMoney) als extrem unzufriedenstellend herausstellte, fiel mir das wieder ein.

Monyplex gibt es gemessen an IT-Standards schon immer. Das ist ein nicht unwichtiger Aspekt bei Finanzverwaltung. Die Software gibt es in den Version Standard, Professional und Business. Die Standard-Version kostet 49,90 €, die Professional 59,90 € und die Business-Variante 139,90 €. Die meisten Anwender dürften mit der Standard-Version gut bedient sein, bei verstärktem Wertpapierhandel sollte man ggf. auf die Professional-Variante setzen. Alle paar Jahre kommen neue Hauptversionen, die dann eine Upgrade-Lizenz erfordern.

Die Installation erfolgt per Installationsroutine in einen Ort der Wahl, wo dann Programm und Daten zusammen liegen. Das ist nicht sonderlich schön, funktioniert aber dafür unter allen Distributionen gleich.

Die Oberfläche und Bedienlogik ist schwer gewöhnungsbedürftig und könnte eine Frischzellenkur vertragen. Lässt man sich auf die Oberfläche ein, kann man aber damit vernünftig arbeiten.

Warum moneyplex?

Schlicht und einfach, weil es funktioniert. Die Einrichtung meiner Banken klappte problemlos. Girokonten, Tagesgeldkonten, Kreditkarten und Depot wurden erkannt und reibungslos abgerufen. Insbesondere beim Depot versagten die anderen freien Lösungen kläglich, weil es sich die Nummer mit dem Girokonto teilt.

Wer bisher zufrieden mit KMyMoney, GnuCash oder Hibiscus arbeitet, braucht nicht wechseln, aber wer bisher um den Bereich unter Linux eher einen Bogen gemacht hat, sollte sich moneyplex mal angucken. Ich würde nicht mehr ohne arbeiten wollen.

Bilder:

Einleitungs- und Beitragsbild von Mudassar Iqbal via Pixabay 

Der Artikel Proprietäre Softwareperlen für Linux Teil II: moneyplex erschien zuerst auf [Mer]Curius

Linux und die Idee der freien Software sind eng verwoben. Proprietäre Software kann zwar theoretisch für Linux vertrieben werden, das ideologische Umfeld und die geringe Verbreitung haben hier aber kein großes Ökosystem entstehen lassen. Drei prominente Ausnahmen möchte ich hier kurz vorstellen. Im ersten Teil: SoftMaker Office.

Softmaker Office

Keine Alternativen

Linux auf dem Desktop ist die Welt der Alternativen. Es gibt für nahezu alles mindestens zwei Lösungen, vom Desktop bis zum Konsoleneditor. Nur für den Bereich Office gilt das nicht wirklich. Neben LibreOffice (und direkten und indirekten Vorgängern StarOffice und OpenOffice) gibt es keine vollwertige Office Suite. Konkurrierende Produkte wie Calligra (KOffice) sind über vielversprechende Ansätze nicht hinaus gekommen oder verfolgen wie Abiword/Gnumeric andere Ansätze.

LIbreOffice ist meiner Meinung nach in einer Sackgasse. In der Community wurde und wird oft gejammert, wenn große Projekte wie KDE oder GNOME ihre Softwareprodukte von Grund auf neu entwickeln und mit Altem brechen. Bei LibreOffice kann man sehen, dass das Unterlassen solcher Brüche auch nicht besser ist. Die Suite ist schwerfällig, inkonsistent, Teile der Suite sind funktional überholt und neue Versionen bringen in der Regel vor allem sehr viele neue Bugs. Ähnlich wie bei Debian finde ich die Community zudem sehr unsympathisch. Es gibt eine Firma, die den Löwenanteil der Entwicklungsleistung stemmt, aber deren Bedürfnisse mit Füßen getreten werden.

Das Argument, es ist halt freie Software und man muss nicht bezahlen, zieht meiner Meinung nach nicht. Erstens arbeiten fast 40 Entwickler bezahlt an LibreOffice. Dafür ist der Output erstaunlich bescheiden. Zweitens kann man z. B. über den Mac App Store bezahlte Varianten von LibreOffice kaufen, aber der Mehrwert ist überschaubar.

SoftMaker Office – kurz vorgestellt

Für mich war die Existenz einer funktionierenden, professionellen Office-Lösung Grundvoraussetzung für die Rückkehr zu Linux.

SoftMaker Office stammt von der kleinen Softwareschmiede SoftMaker Software GmbH. Neben der Software-Suite für alle drei verbreiteten Betriebssysteme vertreibt die Firma vor allem Schriftartenpakete. SoftMaker Office ist zwar keine freie Software, aber ich finde es durchaus unterstützenswert, wenn eine kleine mittelständische Firma ihre hervorragenden Produkte auch für Linux anbietet.

Optisch integriert es sich einigermaßen in jeden Linux-Desktop, leider gibt es keine nativen Dateidialoge. Die Suite steht als RPM und DEB Paket für alle großen Distributionen zur Verfügung und wird über entsprechende Paketquellen aktualisiert. Bei Manjaro Linux ist es sogar in den Paketquellen enthalten. Die Software wird entsprechend der Standards installiert und liegt nicht wie manche Drittanbieterlösung in /opt oder ähnlich.

Die Standardversion kostet 79,95 €, die Professional Version 99,95 €. Installiert werden kann auf 5 privaten Geräten und allen dreien unterstützen Betriebssystemen. Zusätzlich gibt es noch Abo-Versionen, aber so etwas empfehle ich grundsätzlich nicht.

Die Professional Variante bietet im Wesentlichen zusätzlich den Duden Korrektor und die Zotero-Unterstützung. Ich finde, beides ist den Aufpreis von 20 € wert.

Warum SoftMaker Office?

Eine ältere Version wurde bereits hier vorgestellt: Softmaker Office 2018 – Proprietäre Officelösung für Linux, macOS und Windows. Oberflächlich hat sich seitdem wenig getan. Anwender können weiterhin wählen zwischen klassischen Funktionsleisten und einem Ribbon-Menü.

Die Textverarbeitung unterstützt nun auch lesend und schreibend Open Document Formate, was für mich tatsächlich ein wichtigstes Kriterium war. Bei der Tabellenkalkulation PlanMaker fehlt diese Unterstützung noch.

Es sind im Grunde genommen zwei Faktoren, die für SoftMaker Office sprechen:

1. Interoperabilität: Die Unterstützung von OOXML Dateien ist herausragend. Selbst aufwendige Tabellen werden korrekt dargestellt und Dokumente mit zig Formatvorlagen sauber importiert. LO verspricht hier seit Jahren viel und hält wenig.
2. Performance: Dokumente mit 500 Seiten werden genau so reaktionsfreudig geöffnet wie Dokumente mit 2 Seiten. Keine Verzögerungen, keine Denkpausen. Die ganze Software „fühlt“ sich einfach performant an. Der RAM-Verbrauch lag selbst bei dem 500 Seiten Dokument nur bei 200MB. Ein Vergleich mit LO erübrigt sich hier.

Kurzum, ich kann SoftMaker Office wirklich jedem ans Herz legen, der privat oder beruflich mehr mit Office macht, als mal einen Brief zu schreiben oder die neue Wohnungseinrichtung durchzukalkulieren.

Bilder:
Einleitungs- und Beitragsbild von 200degrees via pixabay

Der Artikel Proprietäre Softwareperlen für Linux Teil I: SoftMaker Office erschien zuerst auf [Mer]Curius

Linux und die Idee der freien Software sind eng verwoben. Proprietäre Software kann zwar theoretisch für Linux vertrieben werden, das ideologische Umfeld und die geringe Verbreitung haben hier aber kein großes Ökosystem entstehen lassen. Drei prominente Ausnahmen möchte ich hier kurz vorstellen. Im zweiten Teil: moneyplex von Matrica.

Für mich ist die Möglichkeit, Onlinebanking über eine eigene Software und nicht im Browser zu erledigen einer der großen Vorteile der deutschen Bankenlandschaft (siehe auch: Onlinebanking - HBCI/FinTS einfordern). Der Zugriff via HBCI/FinTS ist  nicht nur komfortabel, weil man alle Konten in einer Software sammeln kann, sondern auch noch sehr gut für die Sicherheit. Man umgeht den Browser mit seinen notorischen zahlreichen Sicherheitslücken. Weiterhin erschwert man bei unbedarften Anwendern Phishing-Angriffe. Diese erfordern schließlich immer einen Aufruf einer gefakten Internetseite. Ist der Anwender jedoch so konditioniert, dass er Banking nie über den Browser macht, fällt er deutlich weniger auf solche Angriffe herein. Ich wechsle inzwischen eher die Bank, als auf HBCI zu verzichten.

moneyplex Homebanking

Wenige Alternativen

Im Homebanking Bereich gibt es nur wenige Alternativen. Die Ursache dafür dürfte in den vielen nationalen Spezifika in diesem Bereich liegen. Die mächtige HBCI-Schnittstelle gibt es nur in Deutschland, weshalb sich auch nur deutsche Nutzer und Entwickler dafür interessieren dürften. Die Schnittstelle soll zudem nicht ganz trivial in der Implementierung sein, weshalb das nichts für ein kleines GSoC Projekt oder eine Wochenendarbeit ist. Ständige Veränderungen erfordern trete Anpassungsleistungen. Unter Linux gibt es eigentlich nur zwei Möglichkeiten in drei Ausprägungen. KMyMoney und GnuCash greifen jeweils auf aqbanking zurück und daneben gibt es noch Hibiscus.

KMyMoney und GnuCash sind zwar mächtige Werkzeuge, aber die HBCI-Implementierung mittels aqbanking ist eine hakelige Geschichte. Die Synchronisation ist fehleranfällig, Überweisungen klappen nicht oder nicht zuverlässig und die Möglichkeit, nachträglich Buchungen im Verlauf zu manipulieren, disqualifiziert die Software im professionellen Einsatz. Um die Ausgaben für den Privatgebrauch im Blick zu behalten und ggf. automatisiert auszuwerten ist die aqbanking Implementierung ganz nett, da sie den manuellen Import des Zahlungsverkehrs erspart - mehr aber auch nicht.

Hibiscus hat seine Fanbasis. Ich persönlich bin mit dem Programm wegen der Java-Basis und der schwierigen Oberfläche nie warum geworden.

moneyplex von Matrica - kurz vorgestellt

Matrica gehört fast schon zu den Dinosauriern auf dem Markt. Die Firma gibt es seit 1998 - ein Umstand, den man Webauftritt und Softwaregestaltung deutlich anmerkt. Ich hatte das Programm nie wirklich auf dem Schirm, aber wurde in den Kommentaren unter einem Artikel (siehe: Wechselhürden zurück zu Linux) mal darauf aufmerksam gemacht. Als bei meiner Rückkehr zu Linux KMyMoney sich (nicht nur im Vergleich zu MoneyMoney) als extrem unzufriedenstellend herausstellte, fiel mir das wieder ein.

Monyplex gibt es gemessen an IT-Standards schon immer. Das ist ein nicht unwichtiger Aspekt bei Finanzverwaltung. Die Software gibt es in den Version Standard, Professional und Business. Die Standard-Version kostet 49,90 €, die Professional 59,90 € und die Business-Variante 139,90 €. Die meisten Anwender dürften mit der Standard-Version gut bedient sein, bei verstärktem Wertpapierhandel sollte man ggf. auf die Professional-Variante setzen. Alle paar Jahre kommen neue Hauptversionen, die dann eine Upgrade-Lizenz erfordern.

Die Installation erfolgt per Installationsroutine in einen Ort der Wahl, wo dann Programm und Daten zusammen liegen. Das ist nicht sonderlich schön, funktioniert aber dafür unter allen Distributionen gleich.

Die Oberfläche und Bedienlogik ist schwer gewöhnungsbedürftig und könnte eine Frischzellenkur vertragen. Lässt man sich auf die Oberfläche ein, kann man aber damit vernünftig arbeiten.

Warum moneyplex?

Schlicht und einfach, weil es funktioniert. Die Einrichtung meiner Banken klappte problemlos. Girokonten, Tagesgeldkonten, Kreditkarten und Depot wurden erkannt und reibungslos abgerufen. Insbesondere beim Depot versagten die anderen freien Lösungen kläglich, weil es sich die Nummer mit dem Girokonto teilt.

Wer bisher zufrieden mit KMyMoney, GnuCash oder Hibiscus arbeitet, braucht nicht wechseln, aber wer bisher um den Bereich unter Linux eher einen Bogen gemacht hat, sollte sich moneyplex mal angucken. Ich würde nicht mehr ohne arbeiten wollen.

Bilder:

Einleitungs- und Beitragsbild von Mudassar Iqbal via Pixabay 

Linux und die Idee der freien Software sind eng verwoben. Proprietäre Software kann zwar theoretisch für Linux vertrieben werden, das ideologische Umfeld und die geringe Verbreitung haben hier aber kein großes Ökosystem entstehen lassen. Drei prominente Ausnahmen möchte ich hier kurz vorstellen. Im ersten Teil: SoftMaker Office.

Softmaker Office

Keine Alternativen

Linux auf dem Desktop ist die Welt der Alternativen. Es gibt für nahezu alles mindestens zwei Lösungen, vom Desktop bis zum Konsoleneditor. Nur für den Bereich Office gilt das nicht wirklich. Neben LibreOffice (und direkten und indirekten Vorgängern StarOffice und OpenOffice) gibt es keine vollwertige Office Suite. Konkurrierende Produkte wie Calligra (KOffice) sind über vielversprechende Ansätze nicht hinaus gekommen oder verfolgen wie Abiword/Gnumeric andere Ansätze.

LIbreOffice ist meiner Meinung nach in einer Sackgasse. In der Community wurde und wird oft gejammert, wenn große Projekte wie KDE oder GNOME ihre Softwareprodukte von Grund auf neu entwickeln und mit Altem brechen. Bei LibreOffice kann man sehen, dass das Unterlassen solcher Brüche auch nicht besser ist. Die Suite ist schwerfällig, inkonsistent, Teile der Suite sind funktional überholt und neue Versionen bringen in der Regel vor allem sehr viele neue Bugs. Ähnlich wie bei Debian finde ich die Community zudem sehr unsympathisch. Es gibt eine Firma, die den Löwenanteil der Entwicklungsleistung stemmt, aber deren Bedürfnisse mit Füßen getreten werden.

Das Argument, es ist halt freie Software und man muss nicht bezahlen, zieht meiner Meinung nach nicht. Erstens arbeiten fast 40 Entwickler bezahlt an LibreOffice. Dafür ist der Output erstaunlich bescheiden. Zweitens kann man z. B. über den Mac App Store bezahlte Varianten von LibreOffice kaufen, aber der Mehrwert ist überschaubar.

SoftMaker Office - kurz vorgestellt

Für mich war die Existenz einer funktionierenden, professionellen Office-Lösung Grundvoraussetzung für die Rückkehr zu Linux.

SoftMaker Office stammt von der kleinen Softwareschmiede SoftMaker Software GmbH. Neben der Software-Suite für alle drei verbreiteten Betriebssysteme vertreibt die Firma vor allem Schriftartenpakete. SoftMaker Office ist zwar keine freie Software, aber ich finde es durchaus unterstützenswert, wenn eine kleine mittelständische Firma ihre hervorragenden Produkte auch für Linux anbietet.

Optisch integriert es sich einigermaßen in jeden Linux-Desktop, leider gibt es keine nativen Dateidialoge. Die Suite steht als RPM und DEB Paket für alle großen Distributionen zur Verfügung und wird über entsprechende Paketquellen aktualisiert. Bei Manjaro Linux ist es sogar in den Paketquellen enthalten. Die Software wird entsprechend der Standards installiert und liegt nicht wie manche Drittanbieterlösung in /opt oder ähnlich.

Die Standardversion kostet 79,95 €, die Professional Version 99,95 €. Installiert werden kann auf 5 privaten Geräten und allen dreien unterstützen Betriebssystemen. Zusätzlich gibt es noch Abo-Versionen, aber so etwas empfehle ich grundsätzlich nicht.

Die Professional Variante bietet im Wesentlichen zusätzlich den Duden Korrektor und die Zotero-Unterstützung. Ich finde, beides ist den Aufpreis von 20 € wert.

Warum SoftMaker Office?

Eine ältere Version wurde bereits hier vorgestellt: Softmaker Office 2018 - Proprietäre Officelösung für Linux, macOS und Windows. Oberflächlich hat sich seitdem wenig getan. Anwender können weiterhin wählen zwischen klassischen Funktionsleisten und einem Ribbon-Menü.

Die Textverarbeitung unterstützt nun auch lesend und schreibend Open Document Formate, was für mich tatsächlich ein wichtigstes Kriterium war. Bei der Tabellenkalkulation PlanMaker fehlt diese Unterstützung noch.

Es sind im Grunde genommen zwei Faktoren, die für SoftMaker Office sprechen:

1. Interoperabilität: Die Unterstützung von OOXML Dateien ist herausragend. Selbst aufwendige Tabellen werden korrekt dargestellt und Dokumente mit zig Formatvorlagen sauber importiert. LO verspricht hier seit Jahren viel und hält wenig.
2. Performance: Dokumente mit 500 Seiten werden genau so reaktionsfreudig geöffnet wie Dokumente mit 2 Seiten. Keine Verzögerungen, keine Denkpausen. Die ganze Software "fühlt" sich einfach performant an. Der RAM-Verbrauch lag selbst bei dem 500 Seiten Dokument nur bei 200MB. Ein Vergleich mit LO erübrigt sich hier.

Kurzum, ich kann SoftMaker Office wirklich jedem ans Herz legen, der privat oder beruflich mehr mit Office macht, als mal einen Brief zu schreiben oder die neue Wohnungseinrichtung durchzukalkulieren.

Bilder:
Einleitungs- und Beitragsbild von 200degrees via pixabay

Bei mir stand wegen defekten Festplatten ein Tausch im hauseigenen NAS an. Der letzte Tausch ist lange her und inzwischen haben Kürzel wie SMR und PMR oder CMR in Produktbeschreibungen Einzug gehalten.

Doch wo genau ist eigentlich der Unterschied und warum unterstützt Synology keine SMR Festplatten?

CMR/PMR Technologie

PMR (Perpendicular Magnetic Recording) auch bekannt als CMR (Conventional Magnetic Recording) stellt die momentan übliche Methode dar, um Daten auf eine Festplatte zu schreiben. Hier wird senkrecht auf die einzelne Platte geschrieben. Dadurch kann eine hohe Datendichte erreicht werden und die Daten landet sofort auf ihrem finalen Speicherplatz.

SMR Technolgie

SMR (Shingled Magnetic Recording) ist die neuere Technologie und schreibt Daten anders auf Festplatten. Die Schreibspuren überlappen teilweise und vorhandene Spuren müssen nach einem Schreibvorgang eventuell noch einmal neu geschrieben werden. Um einen Datenverlust zu verhindern, besitzen diese Platten einen PMR Cache auf den äußeren Spuren. Dieser dient dem Zwischenspeichern der Daten bis sie auf den finalen Platz gelegt werden können. Diese Technologie bietet noch größere Speicherdichte, allerdings kann es bei vollem Cache auch dazu kommen, dass die Datenraten einbrechen.

Seagate

Auf den Webseiten der Hersteller wird inzwischen klar dargestellt, welche Festplattentechnologie zum Einsatz kommt, das war nicht immer so.

(Bild: Seagate)

Western Digital

(Bild: Western Digital)

Toshiba

Information zu Toshiba Platten findet ihr hier.

Synology NAS

Im Netz ist immer wieder davon zu lesen, dass der Hersteller der bekannten NAS Systeme keine SMR Festplatten unterstützt und das ist Stand 12/2020 richtig so. Synology hat eine eigene Seite, in der die SMR/CMR Technologien noch einmal erklärt werden.

Zusätzlich wird eine Kompatibilitätsliste für alle Festplattenhersteller angeboten. Prüft vor einen Kauf, ob das Modell unterstützt wird.

Zusammenfassung

• CMR wird oft bei NAS Festplatten als Bezeichnung verwendet, damit ist PMR gemeint und die „normale“ Schreibart
• CMR Festplatten bieten hohe Übertragungsraten (Streaming vom NAS z.B.)
• SMR Festplatten haben eine geringere Leistungsaufnahme und benötigen weniger Scheiben bei mehr Speicherplatz
• SMR Festplatten können beim Schreibvorgang langsamer werden (Cache-Overflow)
• SMR Festplatten eigenen sich besser als Archiv, bei ständigen Schreibvorgängen kann ein Cache-Overflow drohen
• Neue Anwender Festplatten setzen oft auf die SMR Technologie, da diese günstiger ist. (BarraCuda oder teilweise Western Digital Red/Blue). Welche Technologie die Hersteller den einzelnen Festplatten mitgegeben haben könnt ihr in den Screenshots oder beim Hersteller einsehen (Seagate oder Western Digital oder Toshiba)
• NAS Festplatten verwenden meist CMR/PMR (Seagate IronWolf, Western Digital Red Plus)

Einmal zum Jahresende werfe ich einen Blick zurück und gebe Einblick in mein Nutzungsverhalten. Es soll einen Einblick geben in die alltäglichen Schwierigkeiten beim Versuch, digitale Privatsphäre und Benutzbarkeit unter einen Hut zu bekommen.

Der Blog auf [Mer]Curius spiegelt meine gegenwärtigen Interessen im Bereich Datenschutz/-sicherheit meist ziemlich gut wider. Für viele Leser dürften sich daher einiges Bekanntes wieder finden.

Hardware & Betriebssysteme

Im letzten Jahr (siehe: Wasser predigen, Wein trinken? - Mein Nutzungsverhalten 2019) hatte ich in dieser Rubrik großspurig angekündigt, dass Linux so schnell seinen Weg nicht zurück auf meinen Desktop finden würde. Kaum ein Jahr später ist es dann doch soweit. Mein mobiles Arbeitsgerät war bis dato ein MacBook Air von 2015, das inzwischen in vielen Bereichen an seine Grenzen stieß. SSD-Speicherplatz, RAM-Größe, CPU-Leistung - es klemmte an allen Ecken und Enden. Auch weil ich durch die für mich neue berufliche Pendelei viel mehr mit dem Notebook arbeite, als dies früher der Fall war.

Ich kann zwar immer noch hervorragend mit macOS arbeiten, aber so manche Entscheidung Apples in den letzten Wochen und Monaten löste bei mir Bauchschmerzen aus (siehe: Kritische Entwicklungen bei macOS in macOS 11 "Big Sur" & Ein paar Gedanken zu Apples M1). Das ist jetzt kein radikales Plädoyer gegen Apple, aber für mich Grund genug, mal wieder ein wenig technische Diversifizierung vorzunehmen und auf dem Notebook erneut Linux den Vorzug zu geben (siehe: Erfahrungen mit dem ASUS ZenBook 14 UM425IA).

Der Umstellungsprozess ist gerade noch im Gange. Weniger weil ich Probleme damit gehabt hätte die Daten zu Linux zu transferieren oder Linux in mein persönliches Ökosystem einzubinden (siehe: Erfahrungsbericht: Goldener Käfig macOS - Ein Mythos!), sondern mehr, weil Linux sich auf dem Desktop streckenweise in einem beklagenswerten Zustand befindet. Zwischen all den dahin siechenden Projekten die Softwareperlen des Jahres 2020 zu finden, wird mich sicherlich über den Jahreswechsel begleiten.

Im mobilen Bereich bleibt mein alltäglicher Wegbegleiter ein iPhone SE von 2020 (siehe: Kommentar: Das neue iPhone SE schlägt ein). Ich bin da ziemlich pragmatisch und will vor allem ein alltagstaugliches Gerät mit passabler Sicherheit und langer Lebensdauer. Das Preis-/Leistungsverhältnis für das SE 2020-Modell mit einem Straßenpreis zwischen 400 und 500 € und vermutlich mindestens 5 Jahren Support ist ungeschlagen. Daneben suche ich gerade ein Android Smartphone für den Arbeitsteil meiner Kommunikation (siehe: In eigener Sache: Android Smartphone mit Custom ROM). Hier bin ich aber noch unschlüssig. Mögliche Kandidaten wären ein Pixel 5, aber hier ist die Custom ROM Landschaft noch dünn oder ein Samsung Galaxy S10. Xiaomi, OnePlus etc. fallen wegen der völlig überdimensionierten Geräte weg.

Synchronisationszentrale meiner Geräte ist ein Synology NAS, über das ich im letzten Jahr schon kurz geschrieben hatte. Ich habe selten den Kauf einer Hardware so wenig bereut wie bei diesem NAS. Cloud, PIM, Mailarchiv, Notizen, automatisierte Backups - das Synology NAS verrichtet seinen Dienst nahezu wartungsfrei. Alle paar Wochen mal einen Klick auf Update - das war es dann auch schon.

Homeoffice

Corona hält auch Einzug in diesen Rückblick. 2020 war auch für mich das erste Jahr im Homeoffice. Natürlich fand auch das Studium und die Doktorarbeit viel am heimischen Schreibtisch statt, aber das ist noch mal eine andere Erfahrung. Homeoffice bedeutet schmerzhafte Kompromisse. Hier kommt viel zum Einsatz, das man privat nur mit spitzen Fingern anfassen würde. Dazu gehört das Dienstnotebook, das sich weitestgehend meiner Kontrolle entzieht und für das ich erstmals das Gast-WLAN meiner Fritz!Box in Betrieb nahm. Dazu gehören aber auch die vielen Kommunikationslösungen.

Die Open Source Community kam im Frühjahr schnell mit Big Blue Button (BBB) und Jitsi um die Ecke um dem ausufernden Trend zu Zoom etwas entgegenzusetzen. Netter Versuch, aber ich behaupte mal, wer ernsthaft Jitsi und BBB für konkurrenzfähig hält, kennt Videokonferenzen nur aus der Zeitung. Da muss man noch nicht mal mit großen Konferenzen mit Hunderten Teilnehmern anfangen (wo es teilweise auch mit WebEx und Zoom knackig werden kann), nein Jitsi oder BBB gehen schon bei 20-30 Teilnehmern gerne in die Knie. Dann kommen die Ratschläge: Bild runter skalieren oder besser gleich ganz ausschalten. Klar, warum nicht gleich wieder Morsen oder Rauchzeichen schicken. Der Witz an Videokonferenzen ist ja gerade, dass 30 Teilnehmer sich sehen und miteinander sprechen können.

Wirklich positiv war hingegen die erste intensive Berührung mit Rocket.Chat. Tolle Software mit tollen Funktionen und leidlich funktionierenden Clients. Hier kann man guten Gewissens Open Source Software empfehlen.

Kommunikation

Der ganze Bereich Kommunikation ist ein schwieriges Thema. Der komplette PIM-Bereich liegt inzwischen auf dem Synology NAS, die E-Mails lasse ich über einen Dienstleister laufen. Einen eigenen Mailserver zu betreiben finde ich viel zu aufwendig und der Mehrwert für die Sicherheit ist auch überschaubar. Für die E-Mail Verschlüsselung war leider auch 2020 kein gutes Jahr. S/MIME ist für den Privatgebrauch mangels vertrauenswürdiger preiswerter oder kostenloser Zertifizierungsstellen inzwischen unbrauchbar (siehe: S/MIME - Eine Verschlüsselungsoption weniger) und OpenPGP siecht auch nur noch vor sich hin (siehe: Nachteile dezentraler Lösungen am Beispiel OpenPGP).

Allerdings konnte ich in diesem Jahr den Eindruck gewinnen, dass steter Tropfen wirklich den Stein höhlt. Folgendes Szenario muss man sich dazu vorstellen. 60 Menschen, die sich überhaupt nicht kennen, aus allen Teilen Deutschlands kommen und als einzige Gemeinsamkeit einen Universitätsabschluss vorweisen können, müssen sich auf einen gemeinsamen Messenger einigen. Zur Wahl stehen WhatsApp, Telegram, Threema und Signal. Die Abstimmung gewinnt klar und deutlich Signal. Hätte ich so vor 1-2 Jahren niemals für möglich gehalten, aber ist natürlich absolut erfreulich.

Dienste

Bei den Diensten hat sich bei mir nur wenig getan. Ich versuche immer noch viel selbst zu betreiben und ansonsten auf kleine Dienstleister zu setzen. Als primäre Suchmaschine nutze ich immer noch DuckDuckGo und seit dem Wechsel zurück zu Linux verstärkt wieder OpenStreetMap. GNOME Maps bietet dafür eine hübsche und gut integrierte Oberfläche für den Desktop.

Sünden

Bei vielen Bloggern und Experten im Bereich Datenschutz und Privatsphäre entsteht immer der Eindruck, dass sie perfekte Lichtgestalten sind. Niemand schreibt halt gerne über die Flecken auf der weißen Weste.

Drei Dienste / Apps sind bei mir hinsichtlich Datenschutz und Privatsphäre wirklich problematisch. Ich nutze z. B. immer noch WhatsApp, weil die Mehrheit meiner Kontakte nicht auf alternativen Kanälen zu erreichen ist. Zudem habe ich einen Twitter-Account, weil Twitter in meinem Berufsfeld ein unverzichtbares Kommunikationsmedium ist. Als Berufspendler nutze ich zudem intensiv die Möglichkeiten der Deutschen Bahn. DB Navigator und BahnBonus inklusive. Eine DGSVO-Abfrage vor einiger Zeit ergab, dass die Bahn ein ziemlich exaktes Bewegungsprofil in den vorangegangenen Monaten speichert. Das ist für mich ein klassischer Fall, in dem man Datenschutz und Alltagstauglichkeit gegeneinander abwägen muss.

Bilder:
Einleitungsbild und Beitragsbild von von 200 Degrees via pixabay

In diesem Tutorial zeige ich euch, wie man den Jamulus Client auf deinem Kubuntu 20.04 anhand der Installationsbeschreibung von der Webseite mit git, statt wget, installierst und kompilierst.

Die entsprechenden Links, die du noch brauchst

1. Jamulus Installationsanleitung https://jamulus.io/de/wiki/Installation-for-Linux
2. Github Quellcode https://github.com/corrados/jamulus

Zum Installieren von git in deinem Kubuntu benutzt du folgenden Befehl

1. Erstelle dir ein Verzeichnis für dein Jamulus
2. Wechsel in das Verzeichnisse und gib folgenden Befehl ein git clone https://github.com/corrados/jamulus.git

Für ein Update deines deines Jamulus Clients musst du dann nur noch in das Jamulus/jamulus (gemäß dem Video) wechseln und den Befehl git pull eingeben

Die Audio Distributionen für K/Ubuntu sind

1. Ubuntu Studio (Distribution/PPA) - https://ubuntustudio.org/
2. KXStudio (PPA) - https://kx.studio/

WorldJam Youtube Kanal https://www.youtube.com/channel/UC1xWIPrhqOpftDXbs99w2Xg

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

Neuerungen von Thunderbird 78.6

Mit dem Update auf Thunderbird 78.6 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht. Die neue Version bringt einmal mehr eine verbesserte Unterstützung von MailExtensions, OpenPGP-Verbesserungen sowie zahlreiche Bugfixes und kleinere Verbesserungen, unter anderem beim Adressbuch und im Kalender. Auch diverse Sicherheitslücken wurden in Thunderbird 78.6 behoben. Eine vollständige Liste der Änderungen gibt es in den Release Notes (engl.).

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

Kurz nach der Veröffentlichung des neusten Major-Releases von Qt, Version 6.0, gibt es auch aus dem GTK/GNOME-Lager Neuigkeiten. Das Anwendungsframework GTK (früher als GIMP Toolkit bekannt) erscheint in Version 4.0. Dies hat das Entwicklungsteam gestern im GTK-Blog verkündet.

Für diesen Major-Release wurden viele Komponenten überarbeitet, darunter APIs für den Datentransfer (Clipboard, Drag-and-Drop), Layoutverwaltung, Eventhandling, Rendering, Medienwiedergabe, Listen, Shader oder Bedienungshilfen.

Bezogen werden kann GTK 4.0 aus den Quellen sowie über Flatpak (org.gtk.Demo4).

GTK bildet die Grundlage für das GNOME-Ökosystem und stellt eine Alternative zu Frameworks wie Qt (C++) dar. Hierbei greift GTK auf C als Programmiersprache zurück.

Erste GTK 4.0-Anwendungen sollen mit dem kommenden Release GNOME 40 präsentiert werden.

Quelle: GTK-Blog

Genau so wenig wie „ein bisschen schwanger“ gibt es „ein bisschen sicher“. Entweder Kommunikation ist durch sichere Verschlüsselung geschützt oder eben nicht. Getrieben von Sicherheitsbehörden und Geheimdiensten möchte die Politik nun eine Hintertür für verschlüsselte Kommunikation. Das ist ein Angriff auf die Bürgerrechte in beispiellosem Ausmaße.

Ich äußere mich normalerweise hier nicht zu tagespolitischen Fragen – nicht weil es uninteressant oder unwichtig wäre, sondern weil andere das besser können. Für den aktuellen Vorstoß des Europäischen Rates mache ich hier aber eine Ausnahme. Gegen den Rat aller Experten möchten die europäischen Regierungen den Sicherheitsbehörden per Hintertür Zugriff auf bisher verschlüsselte Kommunikationsinhalte verschaffen. Die Regierungen glaubten scheinbar im Windschatten von Corona schnell die schwerwiegendsten Eingriffe in unsere Grundrechte seit Jahren durchdrücken zu können. D

Die Resonanz auf diesen Vorstoß des Rates ist durchweg negativ – nicht nur in IT- und Fachkreisen (siehe Berichte bei heise, golem. netzpolitik.org), sondern auch bei reichweitenstärkeren Meiden (ZEIT ONLINE, SPIEGEL, tagesschau.de). Die ZEIT brachte es mit der Überschrift „Eine Tür ist eine Tür ist eine Tür“ sehr gut auf den Punkt. Alle gegenteiligen Beteuerungen dienen meiner Meinung nach nur dazu, die Bevölkerung einzulullen. Man sollte nicht dem Trugschluss aufsitzen, dass die Fachpolitiker nicht genau wüssten, was sie da beschließen. Die Innenminister sind längst nur noch verlängerte Arme ihrer eigenen Sicherheitsbehörden, ohne den Anspruch auf eine eigene Gestaltung in der Sicherheitspolitik!

Der EU-Vorstoß betrifft einfach alle. Viele von den hier auf [Mer]Curius diskutierten Themen sind nur für eine kleine Nische. Wer verschlüsselt schon Systeme mit LUKS oder nutzt PGP? Wir reden hier von verschwindend geringen Marktanteilen. Die weitverbreitete, sichere E2E Inhaltesverschlüsselung aller großen Messenger war hingegen der größte und breitenwirksamste Erfolg für die digitale Privatsphäre eines jeden Einzelnen (siehe auch: Digitale Privatsphäre – Was sich seit 2013 verbessert hat). Einfach jeder Anwender konnte mit Mainstream-Messengern sicher kommunizieren. Es kam kaum technische Barrieren, keine steilen Lernkurven, die es zu überwinden galt. Die bestehenden Probleme mit Metadaten usw. sind gemessen an den Implikationen aus dem Vorstoß der EU absolute Luxusprobleme.

Wer jetzt glaubt, dass ihn das nicht betreffe, weil er ja Open Source Software wie Signal oder XMPP nutzt, sollte sich nicht in falscher Sicherheit wiegen. Auch Open Source Software ist nicht staatenlos. Sehr schön kann man das im Kleingedruckten z. B. auf der Downloadseite von Fedora sehen. Wenn die EU und die Staaten der sogenannten „Five Eyes“ sichere Verschlüsselung verbieten (und genau darauf läuft es hinaus!) wird sich auch Open Source Software dem nicht entziehen können. Zumal andere „Heimathäfen“ wie China, Russland oder die arabischen Staaten hier keine bessere Option darstellen würden.

Noch ist es nicht final beschlossen, die Mühlen der EU bieten noch die Möglichkeit zur Korrektur aber man sollte dem Thema jetzt Aufmerksamkeit widmen!

Bilder:

Einleitungs- und Beitragsbild von mohamed Hassan via Pixabay 

Der Artikel Angriff auf die Verschlüsselung erschien zuerst auf [Mer]Curius

Genau so wenig wie "ein bisschen schwanger" gibt es "ein bisschen sicher". Entweder Kommunikation ist durch sichere Verschlüsselung geschützt oder eben nicht. Getrieben von Sicherheitsbehörden und Geheimdiensten möchte die Politik nun eine Hintertür für verschlüsselte Kommunikation. Das ist ein Angriff auf die Bürgerrechte in beispiellosem Ausmaße.

Ich äußere mich normalerweise hier nicht zu tagespolitischen Fragen - nicht weil es uninteressant oder unwichtig wäre, sondern weil andere das besser können. Für den aktuellen Vorstoß des Europäischen Rates mache ich hier aber eine Ausnahme. Gegen den Rat aller Experten möchten die europäischen Regierungen den Sicherheitsbehörden per Hintertür Zugriff auf bisher verschlüsselte Kommunikationsinhalte verschaffen. Die Regierungen glaubten scheinbar im Windschatten von Corona schnell die schwerwiegendsten Eingriffe in unsere Grundrechte seit Jahren durchdrücken zu können. D

Die Resonanz auf diesen Vorstoß des Rates ist durchweg negativ - nicht nur in IT- und Fachkreisen (siehe Berichte bei heise, golem. netzpolitik.org), sondern auch bei reichweitenstärkeren Meiden (ZEIT ONLINE, SPIEGEL, tagesschau.de). Die ZEIT brachte es mit der Überschrift "Eine Tür ist eine Tür ist eine Tür" sehr gut auf den Punkt. Alle gegenteiligen Beteuerungen dienen meiner Meinung nach nur dazu, die Bevölkerung einzulullen. Man sollte nicht dem Trugschluss aufsitzen, dass die Fachpolitiker nicht genau wüssten, was sie da beschließen. Die Innenminister sind längst nur noch verlängerte Arme ihrer eigenen Sicherheitsbehörden, ohne den Anspruch auf eine eigene Gestaltung in der Sicherheitspolitik!

Der EU-Vorstoß betrifft einfach alle. Viele von den hier auf [Mer]Curius diskutierten Themen sind nur für eine kleine Nische. Wer verschlüsselt schon Systeme mit LUKS oder nutzt PGP? Wir reden hier von verschwindend geringen Marktanteilen. Die weitverbreitete, sichere E2E Inhaltesverschlüsselung aller großen Messenger war hingegen der größte und breitenwirksamste Erfolg für die digitale Privatsphäre eines jeden Einzelnen (siehe auch: Digitale Privatsphäre - Was sich seit 2013 verbessert hat). Einfach jeder Anwender konnte mit Mainstream-Messengern sicher kommunizieren. Es kam kaum technische Barrieren, keine steilen Lernkurven, die es zu überwinden galt. Die bestehenden Probleme mit Metadaten usw. sind gemessen an den Implikationen aus dem Vorstoß der EU absolute Luxusprobleme.

Wer jetzt glaubt, dass ihn das nicht betreffe, weil er ja Open Source Software wie Signal oder XMPP nutzt, sollte sich nicht in falscher Sicherheit wiegen. Auch Open Source Software ist nicht staatenlos. Sehr schön kann man das im Kleingedruckten z. B. auf der Downloadseite von Fedora sehen. Wenn die EU und die Staaten der sogenannten "Five Eyes" sichere Verschlüsselung verbieten (und genau darauf läuft es hinaus!) wird sich auch Open Source Software dem nicht entziehen können. Zumal andere "Heimathäfen" wie China, Russland oder die arabischen Staaten hier keine bessere Option darstellen würden.

Noch ist es nicht final beschlossen, die Mühlen der EU bieten noch die Möglichkeit zur Korrektur aber man sollte dem Thema jetzt Aufmerksamkeit widmen!

Bilder:

Einleitungs- und Beitragsbild von mohamed Hassan via Pixabay 

Mozilla hat Firefox 84 für Windows, Apple macOS und Linux veröffentlicht, die letzte Hauptversion des Jahres 2020. 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

Mozilla hat Firefox 84 und damit die letzte Hauptversion im Jahr 2020 veröffentlicht. Das nächste geplante Update wird es erst in sechs Wochen, am 26. Januar 2021, geben.

Native Unterstützung von Apple Silicon M1 (ARM64)

Seit gut einem Monat 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. Die zu dem Zeitpunkt aktuelle Version 83 wurde über Apples Rosetta 2 für ARM64 emuliert und lief dementsprechend langsamer als gewohnt. Firefox 84 kommt mit nativer Unterstützung für Apple Silicon, was in drastischen Performance-Verbesserungen gegenüber Firefox 83 resultiert: Firefox 84 startet 2,5 Mal schneller und Webanwendungen sind laut SpeedoMeter 2.0-Benchmark doppelt so schnell wie mit Firefox 83.

Nutzer eines Computers mit dem neuen Apple-SoC müssen nach dem Update auf Firefox 84 den Browser einmal vollständig beenden und erneut starten, damit Firefox ab sofort mit der neuen Architektur ausgeführt wird. Außerdem sollte das Betriebssystem auf die kürzlich veröffentlichte Version macOS 11.1 aktualisiert werden, da Apple in macOS 11.1 diverse Fehler behoben hat, von denen einige auch Firefox betreffen. Außerdem sollte Rosetta 2 installiert sein, wenn Streaming-Plattformen wie Netflix, Amazon Prime oder Disney+ genutzt werden, da es ansonsten in Firefox 84 zu Wiedergabefehlern kommen kann.

WebRender für Apple macOS 11 und erste Linux-Nutzer

WebRender stammt wie die mit Firefox 57 eingeführte CSS-Engine Stylo ebenfalls aus der Next-Generation-Engine Servo und ist in der Programmiersprache Rust geschrieben. Es handelt sich bei WebRender um einen Renderer für Webseiten-Inhalte, welcher unter stärkerer Einbeziehung der Grafikkarte als bisher im Grunde wie eine Spiele-Engine arbeitet, aber für das Rendering von Web-Content optimiert ist und dadurch große Performance-Vorteile liefern soll.

In den letzten Monaten wurde WebRender für zahlreiche weitere Systeme ausgerollt und speziell mit Firefox 83 kamen viele weitere dazu, denn Firefox 83 war die erste Firefox-Version mit WebRender-Unterstützung für Windows 7, Windows 8 sowie sämtliche Versionen von Apple macOS bis einschließlich Version 10.15 – aber nicht macOS 11 (Big Sur).

Firefox 84 unterstützt WebRender auch auf Big Sur. Außerdem kommt WebRender erstmals auch für einen Teil der Linux-Nutzer zur Anwendung (Gnome, X11). Für Windows-Nutzer wurde die Unterstützung um Geräte mit Intel-Chips der fünften Generation erweitert sowie für Intel-Laptops mit Windows 7 und Windows 8.

Letzte Version mit Unterstützung für Adobe Flash Player

Wie bereits im Jahr 2017 angekündigt, stellt Adobe mit dem 12. Januar 2021 die Unterstützung des Adobe Flash Players ein. Sämtliche Browser-Entwickler folgen diesem Zeitplan und entfernen die Unterstützung des Adobe Flash Players aus ihren Browsern. Firefox bildet hierbei keine Ausnahme, womit Firefox 84 die letzte Version mit Unterstützung des Adobe Flash Players ist.

Übrigens wird der Adobe Flash Player selbständig das Laden von Flash-Inhalten über den 12. Januar 2021 verhindern. Das Support-Ende kann also weder durch einen Wechsel des Browsers noch durch die Verwendung einer älteren Browser-Version umgangen werden.

Optionale Erweiterungs-Berechtigungen verwalten

Firefox-Erweiterungen benötigen für die Ausführung diverser Funktionen Berechtigungen, welche der Nutzer explizit erteilen muss. Dabei unterscheidet Firefox zwischen erforderlichen Berechtigungen, ohne welche eine Erweiterung gar nicht erst installiert werden kann, sowie optionalen Berechtigungen, welche eine Erweiterung zur Laufzeit anfragen kann. Ab Firefox 84 kann der Nutzer optionale Berechtigungen in der Add-ons-Verwaltung verwalten.

Weitere Verbesserungen für Erweiterungen schließen die Möglichkeit ein, jetzt auch in Erweiterungs-Panels die Zoom-Funktion des Browsers nutzen zu können.

Prozessverwaltung

Unter about:processes findet der Nutzer ab sofort eine Prozessverwaltung, welche alle Firefox-Prozesse sowie deren Ressourcen-Verbrauch (CPU und RAM) anzeigt.

Verbesserungen der Entwicklerwerkzeuge

Das Werkzeug für Barrierefreiheit besitzt eine neue Option, um die Tabbing-Reihenfolge von Elementen anzuzeigen.

Verbesserungen gab es auch beim Umgang mit localhost-URLs, mit der Folge, dass Ressourcen, welche via localhost geladen werden, nun als sicher übertragen betrachtet werden und nicht länger Mixed Content-Warnungen erzeugen. Das macht insbesondere das lokale Testen von Web-Features einfacher, welche zwingend einen sicheren Kontext erfordern.

Verbesserungen der Webplattform

Die CSS Pseudo-Klasse :not() unterstützt ab Firefox 84 komplexe Selektoren sowie die Angabe mehrerer Selektoren.

Das PerformancePaintTiming-Interface der Paint Timing API liefert Informationen über den „first-paint“ sowie „first-contentful-paint“, was hilfreich ist, wenn man sein eigenes Performance-Tooling implementieren möchte.

Der sogenannte Application Cache-Standard, kurz: AppCache, gilt bereits seit Firefox 44 als deprecated und wird von Nightly- sowie frühen Beta-Versionen von Firefox seit Version 71 nicht mehr unterstützt. Webentwickler sollten stattdessen Service Workers verwenden. Die AppCache-Unterstützung wurde bereits seit mehreren Versionen schrittweise für die Nutzer abgeschaltet und ist nun vollständig entfernt.

Ausführliche Informationen zu Verbesserungen der Webplattform in Firefox 84 finden sich auf hacks.mozilla.org sowie in den MDN web docs.

Sonstige Neuerungen in Firefox 84

Firefox verwendet jetzt modernere Techniken für die Zuweisung von gemeinsam genutztem Speicher unter Linux, was die Leistung sowie die Kompatibilität mit Docker verbessert.

Das Bild-in-Bild-Feature für Videos merkt sich ab sofort sowohl Position als auch Größe für weitere Verwendungen. Wird über about:config der Schalter media.videocontrols.picture-in-picture.allow-multiple auf true gesetzt, können außerdem ab sofort mehrere Bild-in-Bild-Fenster parallel geöffnet werden.

Natürlich kam auch in Firefox 84 die Unterstützung weiterer Unternehmensrichtlinien sowie Fehlerbehebungen und Verbesserungen unter der Haube dazu.

Geschlossene Sicherheitslücken

Wie immer hat Mozilla auch in Firefox 84 wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 84 daher für alle Nutzer dringend empfohlen.

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

In den letzten Tagen dreht sich meine Internet-Blase zu einem großen Teil rund um das nahende Ende von CentOS-Linux. Um nicht in mehreren Blogs die gleichen oder ähnliche Kommentare zu hinterlassen, habe ich mich entschieden, in diesem einen Artikel meinen Senf dazu zugeben.

Aus Transparenzgründen weise ich ausdrücklich darauf hin, dass ich Mitglied der Red Hat Accelerators bin (siehe „Zu meiner Person„). Meine Meinung ist jedoch grundsätzlich meine eigene. Diese kann mit den Ansichten von Red Hat übereinstimmen, muss es aber nicht und tut es auch nicht immer.

Die Meldungen, dass das Ende von CentOS Linux naht, haben mich weder überrascht, noch enttäuscht. Überrascht bin ich nicht, da ich mich schon bei der Ankündigung von CentOS Stream gefragt habe, wie lange beide Projekte parallel existieren können bzw. wann Red Hat die Unterstützung des einen Projekts zu Gunsten des anderen beendet. Und um enttäuscht zu sein, habe ich CentOS nicht lange genug verwendet und mich nicht in der Gemeinschaft organisiert. Freuen tut es mich allerdings auch nicht, wenn ein so robustes Projekt ein Ende hat.

Ziemlich unglücklich fand ich die Kommunikation durch Red Hat. Dabei ist denke ich mehr Porzellan kaputt gegangen, als nötig war. So ist es wenig verwunderlich, dass die CentOS-Community aufgebracht ist und sich in den Kommentarspalten in Rage schreibt.

So ist die Rede davon, dass Red Hat auf Weisung von IBM bei CentOS das Licht ausgemacht hat; dass CentOS auf dem Altar der Kommerzialisierung geopfert wird, um die Profite von Red Hat und IBM zu steigern. Ja, man könnte fast meinen, die Welt geht unter. Ich finde, das ist alles Quatsch.

Zumal ich nicht glaube, dass Nutzer des kostenlosen CentOS jetzt alle RHEL-Subkriptionen kaufen werden. Für viel wahrscheinlicher halte ich es, dass sich diese Nutzer den zukünftigen kostenlosen RHEL-Klonen zuwenden oder zu anderen kostenlosen Linux-Distributionen wechseln werden.

In meiner Wahrnehmung hat Red Hat bisher seine Eigenständigkeit nach dem Kauf durch IBM behalten. Ob IBM etwas mit der Entscheidung zu tun hatte, weiß ich nicht. Glauben tue ich es jedenfalls nicht. Letztendlich hat das CentOS-Projekt im hauseigenen Blog bekannt gegeben, den Fokus auf CentOS Stream zu verlagern. Übrigens sind nur 4 von 10 Sitzen im CentOS Governing Board von Red Hattern besetzt.

Etliche Kommentare hinterlassen bei mir den Eindruck, die dazugehörigen Autoren würden glauben, sie hätten ein Recht auf kostenlose Software der Enterprise-Klasse. Dabei beinhaltet Open Source nach meinem Verständnis die Freiheit der Quelltexte und das Recht, aus diesen ausführbare Programme zu erstellen. Eine Pflicht, dass ein Unternehmen für den ganzen Spaß bezahlt und diese Aufgabe für mich übernimmt, kann ich hingegen nicht daraus ableiten. Von daher kann ich die Empörung nur teilweise nachvollziehen.

Dabei ist die Binärkompatibilität von CentOS, Oracle Linux, CloudLinux OS, Centos Stream und evtl. bald Rocky Linux zu RHEL doch auch ein Vorteil. Sollten sich Anwendungen, die auf einer dieser Distributionen laufen, sich doch selbst im Binärformat ohne großen Aufwand auf die jeweils anderen übertragen lassen. Ganz ehrlich, einen Wechsel von Debian zu OpenSUSE stelle ich mich schwieriger vor.

In meinen Augen stehen ausreichend gute und stabile Alternativen für Menschen zur Verfügung, die es sich nicht leisten können, für Enterprise-Software zu bezahlen.

Also CentOS, mach es gut. Es war schön mit dir. Mit deinen Nachfolgern wird es sicherlich auch wieder viel zu erleben geben.

Links und Quellen zum Thema

• https://blog.centos.org/2020/12/future-is-centos-stream/
• https://centos.org/distro-faq/
• https://www.redhat.com/en/blog/centos-stream-building-innovative-future-enterprise-linux
• https://kofler.info/nachruf-auf-centos/
• https://www.deimeke.net/dirk/blog/index.php?/archives/4049-Applikationen-unter-Linux-am-Beispiel-CentOS.html
• https://www.linux-magazin.de/news/centos-stirbt-aus-und-wird-zu-centos-stream/
• https://linuxnews.de/2020/12/centos-veroeffentlicht-8-3-und-schiebt-den-fokus-auf-centos-stream/
• https://www.bitblokes.de/rocky-linux-von-centos-gruender-antwort-auf-red-hats-dolchstoss/
• https://gnulinux.ch/rocky-linux-der-nachfolger-von-centos

Seit 1-2 Jahren benutze ich zim als Desktop Wiki aus dem Debian Repository. Mal mehr oder weniger intensiv.

Da ich nun alle Rechner zu Hause auf Bullseye umgestellt habe und ich bei fast allen eine Neuinstallation vorgenommen habe, fehlt mir nun ein Rechner übergreifendes Wiki.

Vor der Umstellung hatte ich es nur auf einem Rechner, dem Tuxedo. Ich habe es auf owncloud syncronisiert.

Da es damit momentan unter Bullseye noch Probleme gibt, habe ich mich nach einer Alternative umgesehen.

Da ich Kunde der Telekom bin, habe ich auch ein kleines Kontingent in der MagentaCloud.

Warum also nicht das mal nutzen?

Meine Idee ist, dass ich von allen Rechnern auf ein- und dasselbe Notizbuch zugreifen kann.

Die "echten" Collabrationstools wie z.B. QOwnNotes erschlagen mich mit den Features und sind in diesen Fall außerdem mit der QT Library, was ich ja eigentlich sonst nicht benötige, also weiterhin zim.

Nun denn, ans Werk.

MagentaCloud stellt einem den Dienst via WEBDAV zur Verfügung, man muß im account-manager

nur ein Password bei WebDAV-Passwort vergeben und sich den Benutzernamen dazu merken.

Nun gibt es mehrere Möglichkeiten, wie man WEBDAV in Linux einbindet, am rundesten finde ich, wenn man es mountet und allen Usern zur Verfügung stellt.  Aus der Beschreibung von davfs: "davfs2 ist so konzipiert, dass es sich vollständig in die Dateisystem-Semantik von  Unix-ähnlichen Systemen (mount, umount, etc.) einfügt. davfs2 macht Einhängen durch unprivilegierte Benutzer so einfach und sicher wie möglich. Das erschließt  die Möglichkeit, auf solche Ressourcen wie auf ein  typisches Dateisystem zuzugreifen, was die Verwendung durch Standardanwendungen ohne eingebaute Unterstützung für WebDAV erlaubt."

Auf seinem Rechner installiert man mit apt install davfs2 die Unterstützung.

Damit es als Drive im Verzeichnis der User auftaucht, muß folgende Zeile in der /etc/fstab hinzugefügt werden:

URL zum WEBDAV                  Mount Verzeichnis      Filesystem Optionen
https://webdav.magentacloud.de /home/bed/MagentaCloud/ davfs uid=1000,users,rw,_netdev 0 0

Für bed natürlich den eigenen Login Namen einsetzen, das Verzeichnis kann natürlich beliebig genannt werden, Hauptsache es ist vorhanden und man hat im Hinterkopf, dass es ein Remote Verzeichnis ist, deshalb finde ich den Namen ganz passend. Das _netdev sorgt dafür, dass das Verzeichnis nur gemountet wird, wenn das Netz aktiv ist und man keine Hänger beim booten oder im Flugzeugmode hat.  

Jetzt noch denselben Verzeichnisnamen im Home Directory anlegen: mkdir /home/bed/MagentaCloud/

Jetzt empfehle ich einen probe mount, um zu sehen ob Benutzername und password richtig sind.

# mount /home/bed/MagentaCloud/
Gib bitte den Benutzernamen für den Server https://webdav.magentacloud.de an; wenn du keinen angeben willst, drücke Return.
  Benutzername: xxx@xx.xx
Gib bitte das Passwort von xxx@xx.xx für den Server https://webdav.magentacloud.de
an; wenn du keines angeben willst, drücke Return.
  Passwort: 

Ist das erfolgreich, dann erscheint bei df -h

u.a. dieser Eintrag.# df

Dateisystem                     1K-Blöcke   Benutzt Verfügbar Verw% Eingehängt auf



https://webdav.magentacloud.de 1333333332 800000000 533333332   61% /home/bed/MagentaCloud

sieht gut aus? 

Ok, dann können die Einstellungen auch permanent gemacht werden, damit der unprivelegierte User das Password nicht mehr eingeben muß.

cat /etc/davfs2/secrets

https://webdav.magentacloud.de xx@xx.xx Geheimes_P@ssw0rd

Update: ab 2022 ist Magentacloud offenbar auf owncloud Instanzen. Deshalb:

https://magentacloud.de/remote.php/webdav xx@xx.xx passw-word-geheim-hihi-haha

Hinweis: WEBDAV und damit auch davfs ist kein vollwertiger Ersatz für ein anständiges Network Filesystem, wie NFS, sondern auf eine https aufbauende Krücke.

In der FAQ ist auch erläutert, warum man unter Umständen lange auf ein unmounten warten muß, z.B. auch beim Runterfahren des Rechners. Siehe  zless /usr/share/doc/davfs2/FAQ.gz 

Mit meinen Worten kurz zusammen gefasst: Beim hochladen von Dateien wird erst lokal eine Kopie angelegt und dann Häppchenweise die Datei hochgeladen. Das ist also lange noch nicht zu Ende, auch wenn der cp Befehl schon lange beendet ist.

Ein ls -l im Zielverzeichnis kommt auch dann erst zurück, wenn das kopieren wirklich beendet ist.

Das kann man schön verfolgen, wenn man parallel per Browser in der MagentaCloud verfolgt, was passiert. Erst nach vollständigem Transfer erscheint der Dateiname korrekt und mit richtigen Angaben zur Größe.

Mein Versuch zeigt bei mir (34Mit upload) doch knapp 6 Minuten für 720 MB. Also nix für Ungeduldige

Siehe hier

Dann ist die Geschwindigkeit erheblich besser.

Doch nun zum eigentlichen Thema. 

Zim

Ich hatte ja bereits eine weile zim benutzt, ich habe das einfach komplett an den neuen Ort kopiert und dann wie im Screenshot zu sehen, als neues Notizbuch hinzugefügt und das alte kann man dann entfernen.

Falls sich das plugin Quellcode Ansicht nicht aktivieren lässt, also nicht wie rechts GtkSourceView - OK steht. Dann bitte überprüfen, ob die Libbraries installiert sind.

ii  libgtksourceview-3.0-1:amd64           3.24.11-2                       amd64        shared libraries for the GTK+ syntax highlighting widget
ii  libgtksourceview-3.0-common            3.24.11-2                       all          common files for the GTK+ syntax highlighting widget
ii  libgtksourceview-4-0:amd64             4.8.0-1                         amd64        shared libraries for the GTK+ syntax highlighting widget
ii  libgtksourceview-4-common              4.8.0-1                         all          common files for the GTK+ syntax highlighting widget

Sollte nach einem Neustart von zim immer noch kein aktivieren möglich sein, dann hilft ein Reboot. Jedenfalls bei mir. Eigentlich peinlich, aber da ich wegen eines Kernelupdates eh booten mußte, hatte sich das gleich mit erledigt.

Im Handling ist es nun überhaupt kein Unterschied mehr, wo und was ich mit zim mache. Ich bin momentan mit dieser Lösung sehr zufrieden.

Aber bitt beachtet die Kommentare, man kann das natütlich auch anders lösen.

Denn diese Lösung ist nämlich von einer funktionierenden Internetverbindung und der MagentaCloud abhängig. Großer Mist, wenn man es eilig hat, aber man nicht an sein Wiki kommt

Apropos Netz und Zuverlässigkeit.

Ich habe mal unterschiedliche Sachen mit der MagentaCloud und dem davfs probiert. Es ist doch ziemlich robust, Gewaltsames unmounten, oder reboot richten so direkt keinen Schaden an. Ich habe ja bereits angemerkt, dass der davfs2 daemon mit einer lokalen Kopie arbeitet. Wenn die Transaktion, also das kopieren einer Datei fehl schlägt, dann bleibt die alte Kopie im cache erhalten. Wie man auf dem Screenshot sieht.

Wird der Kopiervorgang nun erneut angestoßen, wird mit einer neuen Kopie im Cache gearbeitet, zu erkennen am Timestamp und der zufälligen Extension am Namen.

Wie ich bereits schrieb, ist das zurück kehren des Prompts beim kopieren nicht das Signal, dass der Kopiervorgang abgeschlossen ist, was man hier auch schön verfolgen kann, wie lange das ls -ltr (mein Alias ltr) gebraucht hat.

Die runden 3 GIB habe knapp 60 Minuten benötigt. Da nun der Kopiervorgang erfolgreich war, befindet sich nun im Cache nur noch die Leiche des ersten durch reboot unterbrochenen Kopierversuchs.

Außerdem weiß ich nun auch, dass MagentaCloud mit 3 GB Dateien umgehen kann und das Protokoll nicht bei 2GB schlapp macht, wie es teilweise heißt. Die Grenze wird bei 4GB liegen, vermute ich. (Hinweise darauf fand ich bei der Telekom)

Um den Fass die Krone aufzusetzen:

Update: Mit owncloud geht es genauso Happy I am

... und da wird bei df -h auch der per quota mir zugeordnete Speicher korrekt angezeigt. Nicht wie bei MagentaCloud, wo nur merkwüdige Werte angezeigt werden.

Open Source und freie Software hört sich in der Theorie immer ganz toll an. Der kreative Schwarm schafft Software und teilt sie mir der Gemeinschaft. In der Realität stehen dahinter meistens Firmen mit knallharten Geschäftsinteressen. Bei Linux auf dem Desktop vor allem eine Firma: Red Hat.

Exakt diese Firma hat vergangene Woche quasi CentOS den Stecker gezogen. Alles was man dazu wissen muss, kann man bei Michael Kofler nachlesen. Die Übernahme von CentOS durch Red Hat war betriebswirtschaftlich schon immer Unsinn. Ich hatte mich ja schon beim Kauf Red Hats durch IBM gefragt, was wohl die Auswirkungen sein würden (siehe: Kommentar: IBM übernimmt Red Hat – Auswirkungen auf Linux). Ich mutmaße mal: Die Ersten sehen wir jetzt.

Das kann für Linux insgesamt wirklich gefährlich werden. Kürzlich hatte ich schon mal über die Abhängigkeit der Entwicklung im Bereich X11/Wayland von Red Hat gebloggt (siehe: Der Linux Desktop am Tropf einer einzigen Firma). Nun hat das Hans Petter Jansson interessante Zahlen zu den Beiträgen zu GNOME geteilt. Besonders interessant ist hier die Grafik weit unten im Abschnitt By affiliation. Der Löwenanteil der Commits zu GNOME stammt seit Jahren von Red Hat. Wenig überraschend, wie Jansson selbst schreibt, aber eben auch nicht wegzudiskutieren.

Für andere Projekte liegen solche Zahlen meines Wissens nach nicht vor. GNOME ist allerdings vor allem im Enterprise-Geschäft unangefochten. SLED und RHEL kommen nur mit einem einzigen Desktop und das ist die GNOME Shell und bei Ubuntu gibt es auch nur für die Shell main support.

Eine solch einseitige Abhängigkeit ist nicht ungefährlich. Ich behaupte mal, dass sich das Desktop-Geschäft für Red Hat nicht wirklich lohnt bzw. dieses keinen substanziellen Beitrag zum Umsatz beisteuert. Im besten Fall entwickelt die Firma den Desktop also noch für sich selbst bzw. für seine Entwickler – im schlimmsten Fall könnten die kalten Zahlen sprechen.

Bilder:

Einleitungs- und Beitragsbild von Megan_Rexazin via pixabay

Der Artikel Der Linux Desktop am Tropf einer einzigen Firma Teil II erschien zuerst auf [Mer]Curius

Open Source und freie Software hört sich in der Theorie immer ganz toll an. Der kreative Schwarm schafft Software und teilt sie mir der Gemeinschaft. In der Realität stehen dahinter meistens Firmen mit knallharten Geschäftsinteressen. Bei Linux auf dem Desktop vor allem eine Firma: Red Hat.

Exakt diese Firma hat vergangene Woche quasi CentOS den Stecker gezogen. Alles was man dazu wissen muss, kann man bei Michael Kofler nachlesen. Die Übernahme von CentOS durch Red Hat war betriebswirtschaftlich schon immer Unsinn. Ich hatte mich ja schon beim Kauf Red Hats durch IBM gefragt, was wohl die Auswirkungen sein würden (siehe: Kommentar: IBM übernimmt Red Hat - Auswirkungen auf Linux). Ich mutmaße mal: Die Ersten sehen wir jetzt.

Das kann für Linux insgesamt wirklich gefährlich werden. Kürzlich hatte ich schon mal über die Abhängigkeit der Entwicklung im Bereich X11/Wayland von Red Hat gebloggt (siehe: Der Linux Desktop am Tropf einer einzigen Firma). Nun hat das Hans Petter Jansson interessante Zahlen zu den Beiträgen zu GNOME geteilt. Besonders interessant ist hier die Grafik weit unten im Abschnitt By affiliation. Der Löwenanteil der Commits zu GNOME stammt seit Jahren von Red Hat. Wenig überraschend, wie Jansson selbst schreibt, aber eben auch nicht wegzudiskutieren.

Für andere Projekte liegen solche Zahlen meines Wissens nach nicht vor. GNOME ist allerdings vor allem im Enterprise-Geschäft unangefochten. SLED und RHEL kommen nur mit einem einzigen Desktop und das ist die GNOME Shell und bei Ubuntu gibt es auch nur für die Shell main support.

Eine solch einseitige Abhängigkeit ist nicht ungefährlich. Ich behaupte mal, dass sich das Desktop-Geschäft für Red Hat nicht wirklich lohnt bzw. dieses keinen substanziellen Beitrag zum Umsatz beisteuert. Im besten Fall entwickelt die Firma den Desktop also noch für sich selbst bzw. für seine Entwickler - im schlimmsten Fall könnten die kalten Zahlen sprechen.

Bilder:

Einleitungs- und Beitragsbild von Megan_Rexazin via pixabay

Bei Wallabag handelt es sich um ein Tool zum selbst hosten, mit dem man interessante Internetseiten abspeichern kann, um sie später zu lesen. Vor ein paar Tagen wurde Version 2.4.0 veröffentlicht auf die ich meine Instanz eben aktualisieren wollte.

Das Update ist leider mit der (gekürzten) Fehlermeldung “Syntax error or access violation: 1118 Row size too large.” abgebrochen und die Installation war nicht mehr nutzbar.

Die Ursache ist, dass in der Wallabag-Datenbank mindestens eine Tabelle das Zeilenformat “REDUNDANT” oder “COMPACT” hat. Die betroffenen Tabellen kann man sich mit folgender Datenbankabfrage anzeigen.

SELECT CONCAT(TABLE_SCHEMA, '.', TABLE_NAME) 
FROM information_schema.TABLES 
WHERE ENGINE = 'InnoDB' AND ROW_FORMAT IN('Redundant', 'Compact') 
AND TABLE_NAME NOT IN('SYS_DATAFILES', 'SYS_FOREIGN', 'SYS_FOREIGN_COLS', 'SYS_TABLESPACES', 'SYS_VIRTUAL', 'SYS_ZIP_DICT', 'SYS_ZIP_DICT_COLS');

Da sich die Ausgabe nur auf ein paar Tabellen beschränkt hat und ich gerade keine Lust auf eine komplexere Lösung habe, habe ich bei diesen kurzerhand das Zeilenformat manuell mit folgendem Befehl auf “DYNAMIC” geändert.

ALTER TABLE $TABLENAME ROW_FORMAT=DYNAMIC;

Anstelle von $TABLENAME trägt man eine der Tabellen ein, die man mit der Datenbankabfrage angezeigt bekommen hat.

Hat man die betreffenden Tabellen entsprechend geändert hat, sollte das Update ohne Fehler abschließen und die betreffende Wallabag-Instanz sollte danach nutzbar sein

Pantheon ist die Desktop-Shell von elementary OS. Als freie Software kann sie natürlich auch von anderen Distributionen angeboten werden und das geschieht auch zunehmend. Bei openSUSE bisher nur in Form eines OBS-Projekts aber die Qualität ist hervorragend.

Vorgeschichte

Nach meiner „Rückkehr“ zu Linux habe ich es erst mal wieder mit KDE versucht (siehe: Linux 2016 bis 2020 – Eine paar nicht ganz ernste Betrachtungen). Meine AMD Renoir Plattform wird durch den aktuellen elementary OS Kernel (bzw. faktisch natürlich Ubuntu 18.04) einfach nicht unterstützt. Ich dachte, ich wüsste, worauf ich mich bei KDE einlasse (siehe. Tschüß KDE) aber die Probleme kamen von gänzlich unerwarteter Stelle. Eigentlich vermutete ich das chronisch verbuggte KDEPIM oder die Plasma-Shell würden mich ärgern, vielleicht auch die völlige Abwesenheit von Design-Profis – zum Hauptproblem wurde aber ausgerechnet KWin. Dabei dachte ich mal, dass der Fenstermanager die Stärke von KDE wäre. Ich arbeite mit einem Setup bei dem ein Notebook per USB-C Dock an einen Monitor angeschlossen wird. Für KScreen und KWin wohl Raketentechnik. Fenster öffnen sich nach dem Zufallsprinzip auf den Monitoren, meistens in einer völlig unsinnigen Größe. Besonders beliebt: Firefox so groß auf dem Notebook-Screen, dass die Fensterelemente jenseits des Bildschirmrandes waren. Dadurch lernt man wenigstens, wozu es die Verschiebe-Funktion im Kontextmenü der Fensterleiste gibt.

Zweites großes Ärgernis. Die vollkommen unsinnige Spaltendarstellung beim Start. Ein Beispiel gefällig?

Welche Informationen sollen einer solchen Darstellung zu entnehmen sein? Und das ist bei allen Programmen so! Es ist mir völlig unverständlich, dass dieses Problem seit Jahren nicht behoben wurde. Aber vermutlich fällt das den KDE Entwicklern gar nicht auf. Wenn man nämlich das Problem mit KWin und der Fensterplatzierung recherchiert, stößt man auf Äußerungen im Stil von „Keine andere Desktopumgebung bekommt das besser hin, das geht technisch nicht“. Ich ziehe meinen Hut vor so viel Arroganz und Betriebsblindheit.

Wie schrieb ein Leser so nett „Ich verstehe gar nicht warum du dich so rumquälst.“ Ich auch nicht mehr, daher bin ich nun endgültig weg.

Mein Problem war nämlich die fehlende Unterstützung meiner Hardware durch elementary OS. Ich halte die Entwicklungen im Rahmen von elementary OS für mit das Beste, was gerade auf dem Linux Desktop passiert (siehe: elementaryOS – Wenigstens eine Vision für den Desktop) aber meiner Meinung nach haben die Entwickler mit Ubuntu die falsche Basis. Die LTS 20.04 ist seit April draußen und eOS 6 weit entfernt von Produktionsreife. Spender haben seit einiger Zeit Einblick in die aktuellen Build-Versionen, allerdings bitten die Entwickler auf ausführlichen Reviews zu verzichten, weshalb ich dazu noch nichts geschrieben habe. Im Sommer hatte ich schon mit Pantheon und Fedora gearbeitet (siehe: Fedora 32 mit Pantheon Shell) aber die Qualität hat hier mit Fedora 33 eher wieder nachgelassen.

Zum Glück erreichte mich eine E-Mail mit dem Hinweis auf ein OBS Projekt, das ich mal ausprobieren könnte. Da ich bekanntermaßen sowieso gerne mit openSUSE arbeite, musste das natürlich getestet werden.

Pantheon für openSUSE

Ein paar Entwickler haben die Pantheon Shell und zentrale Komponenten für openSUSE umgesetzt. Im Gegensatz zu Fedora wurden dabei die GNOME-Abhängigkeiten soweit möglich reduziert, weshalb man im Hintergrund keine GNOME Shell laufen lassen muss. Das ganze Projekt hat (aus welchen Gründen) auch immer keinen offiziellen Status, weshalb die Pantheon Shell nicht direkt in den openSUSE Quellen liegt. Das sollte einen aber nicht abschrecken, da die Umsetzungsqualität wirklich gut ist.

Es gibt Live-Images auf der Homepage, mit denen man sich einen ersten Eindruck verschaffen kann. Zur Installation möchte ich aber den Weg über die offizielle Installationsroutine empfehlen.

Installation

Die openSUSE Installationsroutine ist bekanntermaßen mächtig. Für eine saubere Neuinstallation empfiehlt es sich, einen minimalen Desktop zu installieren. Die Möglichkeit wird bei der Desktopauswahl in der Installationsroutine explizit angeboten. Bei openSUSE bedeutet dies IceWM, LightDM und eine X11-Umgebung. Das ist sowieso als Fallback ratsam, wenn man einen Desktop aus OBS Quellen bezieht.

Die Pantheon Shell steht sowohl aus Aufsatz für openSUSE Leap, als auch für Tumbleweed zur Verfügung. Getestet habe ich Tumbleweed (wegen der Hardware, siehe oben). Es gibt verschiedene Paketquellen, teils mit aktuellen Entwicklungsständen. Für den Produktiveinsatz empfiehlt sich der Stable-Zweig. Hierbei handelt es sich streng genommen um einen Fork mit Anpassungen für openSUSE.

Für die Desktopumgebung fügt man die Pantheon-Paketquelle hinzu und priorisiert sie anschließend höher als die Hauptquellen. Über YaST oder per Kommandozeile installiert man anschließend das Metapaket patterns-pantheon-pantheon. Dieses zieht alle notwendigen Abhängigkeiten nach sich. Hier wurde durch die Entwickler sehr sauber gearbeitet. Ich habe lediglich die Office-Abhängigkeiten abgewählt, weil ich LibreOffice nicht verwende, aber das ist persönliche Geschmackssache.

Es lohnt sich, die Nachinstallationshinweise bei einigen Paketen zu lesen. Die Entwickler weisen hier z. B. darauf hin, wenn Pakete eher experimentell sind oder man händisch nacharbeiten muss. So beispielsweise durch Hinzufügen des Benutzers zur lightdm-Benutzergruppe, damit die Hintergrundbildänderungen übernommen werden.

Nach einem Neustart kann man in LightDM die Pantheon Session auswählen.

Nacharbeiten

Die Qualität der Umsetzung ist wirklich beeindruckend. Für ein vollständiges Look & Feel sollte man aber noch den normalen LightDM-Greeter von openSUSE entfernen. Über YaST oder zypper einfach folgendes Paket mit seinen Abhängigkeiten deinstallieren: lightdm-gtk-greeter. Anschließend nutzt das System automatisch das elementary-Branding.

Das Pantheon-Repo ist schon sehr umfassend. Zur Nachinstallation empfiehlt sich noch elementary-tweaks mit einigen erweiterten Einstellungen und wingpanel-indicator-namarupa für Legacy-Tray-Icons. Beides übrigens Pakete, die bei einem normalen elementary OS nicht so ohne weiteres zur Verfügung stehen.

Zusätzlich gibt es noch eine weitere Paketequelle mit Apps für elementary OS. Bei Bedarf kann man diese zusätzlich ebenfalls einrichten.

Im Arbeitsalltag

Man hört immer wieder „elementary OS ist buggy“. Das hängt ganz von der Nutzung ab. Für mich ist die Pantheon Shell das bessere GNOME. Ich muss nahezu nichts an den Konfigurationsvoreinstellungen ändern, um meine präferierte Arbeitsweise abzubilden. Von den zugehörigen Programmen nutze ich aber nur die Basisbestandteile. Dateiverwaltung, Konsole, Bilderverwaltung und den Texteditor Code. Zusätzlich noch den Videoplayer, der als GStreamer Aufsatz solide Arbeit für meine geringen Ansprüche in diesem Bereich verrichtet. Die Programme sind stabil und funktional und nicht so kastriert wie ihre GNOME-Pendants.

Den Rest ergänze ich entweder mit unabhängigen Projekte (Firefox, FileZilla, KeePassXC), proprietärer Software (Softmaker Office, Moneyplex) oder GNOME-Software (Evolution, Déjà Dup, Lollypop). Das GTK-Toolkit sorgt hier für eine sehr gute optische Integration.

Vermisse ich etwas von KDE? Nur zwei Sachen: KDEConnect und Konversation. Ersteres gibt es nicht für die Pantheon Shell und letzteres kann man zwar funktional mit HexChat ersetzen aber schön ist was anderes.

Zusammengefasst

Die Pantheon-Umsetzung für openSUSE ist von sehr hoher Qualität. Es ist unverständlich, warum sie noch nicht in die Hauptquellen übernommen wurde. Durch das Zusammenspiel bekommt man eine hervorragende Basis mit allen Stärken von openSUSE Tumbleweed mit einem sehr guten Desktop. Zudem macht man sich etwas unabhängig von den Eigenlogiken der elementary-Entwicklung, wie z. B. die Fokussierung auf Flatpak oder die schleppenden Releases.

Der Artikel openSUSE Tumbleweed mit Pantheon Shell erschien zuerst auf [Mer]Curius

Pantheon ist die Desktop-Shell von elementary OS. Als freie Software kann sie natürlich auch von anderen Distributionen angeboten werden und das geschieht auch zunehmend. Bei openSUSE bisher nur in Form eines OBS-Projekts aber die Qualität ist hervorragend.

Vorgeschichte

Nach meiner "Rückkehr" zu Linux habe ich es erst mal wieder mit KDE versucht (siehe: Linux 2016 bis 2020 - Eine paar nicht ganz ernste Betrachtungen). Meine AMD Renoir Plattform wird durch den aktuellen elementary OS Kernel (bzw. faktisch natürlich Ubuntu 18.04) einfach nicht unterstützt. Ich dachte, ich wüsste, worauf ich mich bei KDE einlasse (siehe. Tschüß KDE) aber die Probleme kamen von gänzlich unerwarteter Stelle. Eigentlich vermutete ich das chronisch verbuggte KDEPIM oder die Plasma-Shell würden mich ärgern, vielleicht auch die völlige Abwesenheit von Design-Profis - zum Hauptproblem wurde aber ausgerechnet KWin. Dabei dachte ich mal, dass der Fenstermanager die Stärke von KDE wäre. Ich arbeite mit einem Setup bei dem ein Notebook per USB-C Dock an einen Monitor angeschlossen wird. Für KScreen und KWin wohl Raketentechnik. Fenster öffnen sich nach dem Zufallsprinzip auf den Monitoren, meistens in einer völlig unsinnigen Größe. Besonders beliebt: Firefox so groß auf dem Notebook-Screen, dass die Fensterelemente jenseits des Bildschirmrandes waren. Dadurch lernt man wenigstens, wozu es die Verschiebe-Funktion im Kontextmenü der Fensterleiste gibt.

Zweites großes Ärgernis. Die vollkommen unsinnige Spaltendarstellung beim Start. Ein Beispiel gefällig?

Welche Informationen sollen einer solchen Darstellung zu entnehmen sein? Und das ist bei allen Programmen so! Es ist mir völlig unverständlich, dass dieses Problem seit Jahren nicht behoben wurde. Aber vermutlich fällt das den KDE Entwicklern gar nicht auf. Wenn man nämlich das Problem mit KWin und der Fensterplatzierung recherchiert, stößt man auf Äußerungen im Stil von "Keine andere Desktopumgebung bekommt das besser hin, das geht technisch nicht". Ich ziehe meinen Hut vor so viel Arroganz und Betriebsblindheit.

Wie schrieb ein Leser so nett "Ich verstehe gar nicht warum du dich so rumquälst." Ich auch nicht mehr, daher bin ich nun endgültig weg.

Mein Problem war nämlich die fehlende Unterstützung meiner Hardware durch elementary OS. Ich halte die Entwicklungen im Rahmen von elementary OS für mit das Beste, was gerade auf dem Linux Desktop passiert (siehe: elementaryOS - Wenigstens eine Vision für den Desktop) aber meiner Meinung nach haben die Entwickler mit Ubuntu die falsche Basis. Die LTS 20.04 ist seit April draußen und eOS 6 weit entfernt von Produktionsreife. Spender haben seit einiger Zeit Einblick in die aktuellen Build-Versionen, allerdings bitten die Entwickler auf ausführlichen Reviews zu verzichten, weshalb ich dazu noch nichts geschrieben habe. Im Sommer hatte ich schon mit Pantheon und Fedora gearbeitet (siehe: Fedora 32 mit Pantheon Shell) aber die Qualität hat hier mit Fedora 33 eher wieder nachgelassen.

Zum Glück erreichte mich eine E-Mail mit dem Hinweis auf ein OBS Projekt, das ich mal ausprobieren könnte. Da ich bekanntermaßen sowieso gerne mit openSUSE arbeite, musste das natürlich getestet werden.

Pantheon für openSUSE

Ein paar Entwickler haben die Pantheon Shell und zentrale Komponenten für openSUSE umgesetzt. Im Gegensatz zu Fedora wurden dabei die GNOME-Abhängigkeiten soweit möglich reduziert, weshalb man im Hintergrund keine GNOME Shell laufen lassen muss. Das ganze Projekt hat (aus welchen Gründen) auch immer keinen offiziellen Status, weshalb die Pantheon Shell nicht direkt in den openSUSE Quellen liegt. Das sollte einen aber nicht abschrecken, da die Umsetzungsqualität wirklich gut ist.

Es gibt Live-Images auf der Homepage, mit denen man sich einen ersten Eindruck verschaffen kann. Zur Installation möchte ich aber den Weg über die offizielle Installationsroutine empfehlen.

Installation

Die openSUSE Installationsroutine ist bekanntermaßen mächtig. Für eine saubere Neuinstallation empfiehlt es sich, einen minimalen Desktop zu installieren. Die Möglichkeit wird bei der Desktopauswahl in der Installationsroutine explizit angeboten. Bei openSUSE bedeutet dies IceWM, LightDM und eine X11-Umgebung. Das ist sowieso als Fallback ratsam, wenn man einen Desktop aus OBS Quellen bezieht.

Die Pantheon Shell steht sowohl aus Aufsatz für openSUSE Leap, als auch für Tumbleweed zur Verfügung. Getestet habe ich Tumbleweed (wegen der Hardware, siehe oben). Es gibt verschiedene Paketquellen, teils mit aktuellen Entwicklungsständen. Für den Produktiveinsatz empfiehlt sich der Stable-Zweig. Hierbei handelt es sich streng genommen um einen Fork mit Anpassungen für openSUSE.

Für die Desktopumgebung fügt man die Pantheon-Paketquelle hinzu und priorisiert sie anschließend höher als die Hauptquellen. Über YaST oder per Kommandozeile installiert man anschließend das Metapaket patterns-pantheon-pantheon. Dieses zieht alle notwendigen Abhängigkeiten nach sich. Hier wurde durch die Entwickler sehr sauber gearbeitet. Ich habe lediglich die Office-Abhängigkeiten abgewählt, weil ich LibreOffice nicht verwende, aber das ist persönliche Geschmackssache.

Es lohnt sich, die Nachinstallationshinweise bei einigen Paketen zu lesen. Die Entwickler weisen hier z. B. darauf hin, wenn Pakete eher experimentell sind oder man händisch nacharbeiten muss. So beispielsweise durch Hinzufügen des Benutzers zur lightdm-Benutzergruppe, damit die Hintergrundbildänderungen übernommen werden.

Nach einem Neustart kann man in LightDM die Pantheon Session auswählen.

Nacharbeiten

Die Qualität der Umsetzung ist wirklich beeindruckend. Für ein vollständiges Look & Feel sollte man aber noch den normalen LightDM-Greeter von openSUSE entfernen. Über YaST oder zypper einfach folgendes Paket mit seinen Abhängigkeiten deinstallieren: lightdm-gtk-greeter. Anschließend nutzt das System automatisch das elementary-Branding.

Das Pantheon-Repo ist schon sehr umfassend. Zur Nachinstallation empfiehlt sich noch elementary-tweaks mit einigen erweiterten Einstellungen und wingpanel-indicator-namarupa für Legacy-Tray-Icons. Beides übrigens Pakete, die bei einem normalen elementary OS nicht so ohne weiteres zur Verfügung stehen.

Zusätzlich gibt es noch eine weitere Paketequelle mit Apps für elementary OS. Bei Bedarf kann man diese zusätzlich ebenfalls einrichten.

Im Arbeitsalltag

Man hört immer wieder "elementary OS ist buggy". Das hängt ganz von der Nutzung ab. Für mich ist die Pantheon Shell das bessere GNOME. Ich muss nahezu nichts an den Konfigurationsvoreinstellungen ändern, um meine präferierte Arbeitsweise abzubilden. Von den zugehörigen Programmen nutze ich aber nur die Basisbestandteile. Dateiverwaltung, Konsole, Bilderverwaltung und den Texteditor Code. Zusätzlich noch den Videoplayer, der als GStreamer Aufsatz solide Arbeit für meine geringen Ansprüche in diesem Bereich verrichtet. Die Programme sind stabil und funktional und nicht so kastriert wie ihre GNOME-Pendants.

Den Rest ergänze ich entweder mit unabhängigen Projekte (Firefox, FileZilla, KeePassXC), proprietärer Software (Softmaker Office, Moneyplex) oder GNOME-Software (Evolution, Déjà Dup, Lollypop). Das GTK-Toolkit sorgt hier für eine sehr gute optische Integration.

Vermisse ich etwas von KDE? Nur zwei Sachen: KDEConnect und Konversation. Ersteres gibt es nicht für die Pantheon Shell und letzteres kann man zwar funktional mit HexChat ersetzen aber schön ist was anderes.

Zusammengefasst

Die Pantheon-Umsetzung für openSUSE ist von sehr hoher Qualität. Es ist unverständlich, warum sie noch nicht in die Hauptquellen übernommen wurde. Durch das Zusammenspiel bekommt man eine hervorragende Basis mit allen Stärken von openSUSE Tumbleweed mit einem sehr guten Desktop. Zudem macht man sich etwas unabhängig von den Eigenlogiken der elementary-Entwicklung, wie z. B. die Fokussierung auf Flatpak oder die schleppenden Releases.

Sowohl CentOS als auch Oracle bieten Scripts an, um eine vorhandene CentOS-8-Installation wahlweise in CentOS Stream oder in Oracle Linux umzubauen. Ich habe also eine virtuelle Maschine mit einer ca. ein Jahr alten Installation von CentOS 8 zuerst aktualisiert und dann zweimal geklont. In der Ausgangs-VM waren ein MySQL-Server installiert, EPEL aktiviert und vereinzelte EPEL-Pakete installiert. Einen Klon habe ich anschließend in CentOS Stream umgewandelt, den anderen in Oracle Linux.

Warnung: Es sollte klar sein, dass dies ein sehr simpler Test ist, nicht mehr! Ich habe kein produktives System umgestellt, sondern nur eine einfache Testumgebung.

Umstieg auf CentOS Stream

Die Umstellung auf CentOS Stream erfolgt kurz und schmerzlos. CentOS ade …

yum install centos-release-stream
yum swap centos-{linux,stream}-repos
yum distro-sync
reboot

Dabei werden die Paketquellen von CentOS auf CentOS Stream umgestellt und eine Menge Pakete ersetzt. Der Vorgang ist in einigenMinuten abgeschlossen. Ein kurzer Test zeigt:

uname -a

  Linux c8stream 4.18.0-257.el8.x86_64 #1 SMP 
  Thu Dec 3 22:16:23 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/os-release 

  NAME="CentOS Stream"
  VERSION="8"
  ID="centos"
  ID_LIKE="rhel fedora"
  VERSION_ID="8"
  PLATFORM_ID="platform:el8"
  PRETTY_NAME="CentOS Stream 8"
  ANSI_COLOR="0;31"
  CPE_NAME="cpe:/o:centos:centos:8"
  HOME_URL="https://centos.org/"
  BUG_REPORT_URL="https://bugzilla.redhat.com/"
  REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux 8"
  REDHAT_SUPPORT_PRODUCT_VERSION="CentOS Stream"

ls /etc/yum.repos.d/

  CentOS-Stream-AppStream.repo  CentOS-Stream-HighAvailability.repo  epel-modular.repo          epel.repo
  CentOS-Stream-BaseOS.repo     CentOS-Stream-Media.repo             epel-playground.repo
  CentOS-Stream-Debuginfo.repo  CentOS-Stream-PowerTools.repo        epel-testing-modular.repo
  CentOS-Stream-Extras.repo     CentOS-Stream-RealTime.repo          epel-testing.repo

Umstieg auf Oracle Linux

Ähnlich unkompliziert gelingt der Umstieg auf Oracle Linux. Auf der GitHub-Seite des Scripts ist nachzulesen, dass zumindest 5 GB Platz im Verzeichnis /var/cache erforderlich sind. Außerdem sollten vor dem Wechsel sämtliche externe Paketquellen deaktiviert werden. (Ich habe EPEL belassen, Probleme haben sich dadurch — zumindest in meinem Fall — keine ergeben.)

yum install git
git clone https://github.com/oracle/centos2ol.git
bash centos2ol/centos2ol.sh
reboot

Nach einigen Minuten ist auch in diesem Fall der Spuk vorbei. Ein kurzer Test zeigt, dass ein anderer Kernel läuft und /etc/os-release aktualisiert ist. Beachten Sie, dass Oracle nicht wie CentOS 8 / RHEL 8 auf den relativ alten Kernel 4.18 setzt, sondern den vergleichsweise modernen Kernel 5.14.

uname -a

  Linux c8oracle 5.4.17-2036.100.6.1.el8uek.x86_64 #2 SMP 
  Thu Oct 29 17:06:00 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/os-release

  NAME="Oracle Linux Server"
  VERSION="8.3"
  ID="ol"
  ID_LIKE="fedora"
  VARIANT="Server"
  VARIANT_ID="server"
  VERSION_ID="8.3"
  PLATFORM_ID="platform:el8"
  PRETTY_NAME="Oracle Linux Server 8.3"
  ANSI_COLOR="0;31"
  CPE_NAME="cpe:/o:oracle:linux:8:3:server"
  HOME_URL="https://linux.oracle.com/"
  BUG_REPORT_URL="https://bugzilla.oracle.com/"
  ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
  ORACLE_BUGZILLA_PRODUCT_VERSION=8.3
  ORACLE_SUPPORT_PRODUCT="Oracle Linux"
  ORACLE_SUPPORT_PRODUCT_VERSION=8.3

ls /etc/yum.repos.d

  CentOS-Linux-AppStream.repo.disabled          CentOS-Linux-HighAvailability.repo.disabled  epel-testing-modular.repo
  CentOS-Linux-BaseOS.repo.disabled             CentOS-Linux-Media.repo.disabled             epel-testing.repo
  CentOS-Linux-ContinuousRelease.repo.disabled  CentOS-Linux-Plus.repo.disabled              epel.repo
  CentOS-Linux-Debuginfo.repo.disabled          CentOS-Linux-PowerTools.repo.disabled        oracle-linux-ol8.repo
  CentOS-Linux-Devel.repo.disabled              CentOS-Linux-Sources.repo.disabled           uek-ol8.repo
  CentOS-Linux-Extras.repo.disabled             epel-modular.repo
  CentOS-Linux-FastTrack.repo.disabled          epel-playground.repo

Vorsicht: Das Script centos2ol.sh funktioniert für CentOS 8, aber nicht für CentOS Stream 8! Ein CentOS-Installation, die Sie einmal auf CentOS Stream umgestellt haben, können Sie später nicht mehr auf Oracle Linux umstellen!

CentOS 8

Zum Vergleich die Kernel-Version und /etc/centos-release bei einer regulären CentOS-8-Installation (Stand 11.12.2020, Ablaufdatum 31.12.2021):

uname -a

  Linux centos8 4.18.0-240.1.1.el8_3.x86_64 #1 SMP 
  Thu Nov 19 17:20:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/os-release 

  NAME="CentOS Linux"
  VERSION="8"
  ID="centos"
  ID_LIKE="rhel fedora"
  VERSION_ID="8"
  PLATFORM_ID="platform:el8"
  PRETTY_NAME="CentOS Linux 8"
  ANSI_COLOR="0;31"
  CPE_NAME="cpe:/o:centos:centos:8"
  HOME_URL="https://centos.org/"
  BUG_REPORT_URL="https://bugs.centos.org/"
  CENTOS_MANTISBT_PROJECT="CentOS-8"
  CENTOS_MANTISBT_PROJECT_VERSION="8"

Erfahrungen

Ehrlicherweise muss ich zugeben, dass ich zur Stabilität der neuen Systeme momentan gar nichts sagen kann. Auf den ersten Blick funktioniert alles, alle drei Systeme (Original CentOS 8, CentOS 8 Stream und Oracle Linux) booten und tun dann, was sie sollen. Der Test beweist immerhin, dass ein Wechsel prinzipiell möglich ist. Ob er Wechsel auch bei realen Systemen, womöglich mit diversen Fremdpaketen, so mühelos ist, wird demnächst sicher im Internet nachzulesen sein.

Glücklicherweise bin ich selbst nicht in der Verlegenheit, dass ich ein »reales« CentOS-8-System umstellen muss. Der Start von CentOS 8 war — gelinde gesagt — holprig. Insofern habe ich zuerst einmal abgewartet; vor drei Monaten habe ich dann beschlossen, dass ich meinen Linux-Unterricht im kommenden Sommersemester mit Oracle Linux machen würde. Und jetzt ist CentOS ohnehin Geschichte.

Ich habe mir auf jeden Fall vorgenommen, in den nächsten Wochen hin und wieder einen Blick auf meine Klon-Babies zu werfen und speziell auf die Update-Versorgung zu achten :-)

Erfahrungen 2: Das sudo-Update für CVE-2021-3156

Am 26.1.2021 wurde ein gravierender Fehler in sudo bekannt (Details 1, Details 2). Am 21.1.2021 9:00 habe ich nachgesehen, für welche RHEL-ähnliche Distributionen es bereits Updates gibt.

• CentOS 8 Stream: ja
• CentOS 8: nein jetzt auch (27.1.)
• CentOS 7: ja
• Oracle Linux 8: ja

Fazit

Welche Konsequenzen der CentOS-Exit längerfristig haben wird, muss sich erst weisen.

• Ist das ehemals experimentelle CentOS Stream tatsächlich so stabil, wie es uns die Red-Hat-Leute plötzlich versprechen — quasi das bessere CentOS, von dem wir immer träumten? (Ich bin skeptisch, aber vielleicht bin ich zu pessimistisch. Aber mit einem EOL 2024 ist die Stabilität wahrscheinlich ziemlich egal.)

• Nimmt Oracle jetzt die Chance war, sich als Retter der CentOS-Welt zu etablieren? (Ehrlicherweise muss man ja sagen, dass von den Millionen aktiven CentOS-Servern die meisten noch immer CentOS 7 verwenden. Deren Administratoren haben noch Zeit mit ihren Zukunftsplänen.)

• Werden neue RHEL-Klone den Markt beleben?

• Wechseln Red-Hat-Fans jetzt in Scharen zu Debian und Ubuntu? (Glaube ich persönlich nicht, aber wer weiß?)

Nur eines ist sicher: Mit Linux wird es nie langweilig …

Quellen

• https://www.centos.org/centos-stream/#converting-from-centos-linux-to-centos-stream
• https://ostechnix.com/how-to-migrate-to-centos-stream-8-from-centos-linux-8/
• https://centos.org/distro-faq/#q7-how-do-i-migrate-my-centos-linux-8-installation-to-centos-stream
• https://github.com/oracle/centos2ol
• https://blogs.oracle.com/linux/need-a-stable,-rhel-compatible-alternative-to-centos-three-reasons-to-consider-oracle-linux

Mozilla hat seinen Finanzbericht für das Jahr 2019 veröffentlicht und überrascht mit diesem: Mozilla hat einen Umsatz in Rekordhöhe erzielt. Mit knapp 828 Millionen Dollar liegt der Umsatz fast doppelt so hoch wie im Vorjahr.

Wie jedes Jahr am Jahresende hat Mozilla auch in diesem Jahr seinen Finanzbericht für das Vorjahr veröffentlicht, welcher offenlegt, in welcher Höhe Mozilla Einnahmen und Ausgaben hatte.

Sehr hoher Umsatz in 2019

Im Jahr 2018 hatte Mozilla mit 450 Millionen Dollar erstmals weniger Umsatz als im Vorjahr gemacht – und das deutlich. Dies hing in erster Linie mit der Ablösung von Yahoo durch Google als Standard-Suchmaschine in den USA zusammen. Viele erwarteten nun für 2019 ein ähnliches Ergebnis. Tatsächlich weist Mozilla für das Jahr 2019 allerdings einen Rekord-Umsatz in Höhe von über 828 Millionen Dollar aus.

Der Grund dafür versteckt sich bereits im Finanzbericht 2018. Demnach sollte Ende September 2019 vor dem kalifornischen Staatsgerichtshof der Rechtsstreit mit Yahoo Holdings verhandelt werden, der sich um Mozillas vorzeitigen Ausstieg aus dem Suchmaschinen-Vertrag mit Yahoo Ende 2017 drehte. Yahoo Holdings verklagte Mozilla ob des vorzeitigen Ausstiegs, Mozilla reagierte mit einer Gegenklage und forderte 375 Millionen Dollar von Yahoo.

Siehe auch: Yahoo Holdings / Oath und Mozilla verklagen sich gegenseitig

In Finanzbericht 2018 wies Mozilla bereits darauf hin, keine nachteiligen finanziellen Auswirkungen als Folge dieses Rechtsstreits zu erwarten. Der Finanzbericht 2019 legt nun nahe, wieso sich Mozilla seiner Sache so sicher war. Denn dieser listet mit „Andere Einnahmen“ einen Punkt auf, den es im Vorjahresbericht nicht gab und der für 2019 Einnahmen in Höhe von 338 Millionen Dollar benennt, also annähernd die Summe, die Mozilla gefordert haben soll.

Demnach handelt es sich hierbei um einmalige Einnahmen im Jahr 2019. Allerdings hat Mozilla seinen Umsatz auch unabhängig davon verbessert. Zieht man die 338 Millionen Dollar ab, bleibt immer noch eine Umsatzsteigerung von knapp 40 Millionen Dollar gegenüber 2018, davon über 21 Millionen Dollar aus Suchmaschinen-Geschäften.

Neue Einnahmequellen

Aber auch Abonnement- und Werbeeinnahmen konnten deutlich gesteigert werden, von 5,3 auf 14 Millionen Dollar. Dafür verantwortlich ist in erster Linie das Premium-Angebot von Mozillas Read it Later-Dienst Pocket sowie bezahlte Platzierungen auf der Standard-Startseite von Firefox. Ende Oktober 2018 startete Mozilla außerdem einen kostenpflichtigen Test eines VPN-Produkts in den USA, welches in 2019 für ein paar Einnahmen gesorgt haben dürfte und in diesem Jahr als Mozilla VPN offiziell in mehreren Ländern gestartet ist.

Insgesamt ist Mozillas Abhängigkeit von Suchmaschinen weiter leicht gesunken. Waren es 2017 noch 93 Prozent und 2018 noch 91 Prozent, machten Suchmaschinen im Jahr 2019 nur noch 88 Prozent des Umsatzes aus. Konkret Google machte 2019 73 Prozent des Umsatzes aus, verglichen mit 75 Prozent im Vorjahr. Das ist immer noch eine sehr hohe Abhängigkeit, aber es dürfte nicht überraschen, dass eine Diversifizierung der Einnahmequellen Zeit benötigt und neue Einnahmequellen, die Mozilla erst neu erschlossen hat respektive noch erschließen wird, noch nicht annähernd die gleiche Dimension haben können wie die hohen Einnahmen, welche Mozilla durch Suchmaschinen-Verträge erzielt. Zumindest ein Trend ist allerdings erkennbar.

Die Ausgaben sind leicht gestiegen

Auf der Ausgaben-Seite stehen knapp über 495 Millionen Dollar, verglichen mit etwas mehr als 451 Millionen Dollar im Vorjahr. Davon fallen über 303 Millionen Dollar auf die Produktentwicklung. Im Jahr 2018 machte dieser Posten noch 278 Millionen Dollar aus. Für Marketing wurden etwas mehr als 43 Millionen Dollar ausgegeben und damit erneut einiges weniger als im Jahr zuvor (knapp 53 Millionen Dollar). Außerdem hat Mozilla im Jahr 2019 seine zehnprozentige Beteiligung an der deutschen Cliqz GmbH mit einem Wert von 1,8 Millionen Dollar aufgelöst und die Anteile zurück verkauft.

Das Netto-Vermögen von Mozilla

Das Netto-Vermögen von Mozilla ist im Vergleich zum Vorjahr von mehr als 523 Millionen Dollar auf knapp über 787 Millionen Dollar gestiegen.

Entwicklung von 2005 bis heute

Wie gehabt gibt es auf soeren-hentzschel.at eine Spezial-Seite, welche die Einnahmen, die Ausgaben sowie das Vermögen von Mozilla seit dem Jahr 2005 bis heute visualisiert und die Entwicklung anschaulich gestaltet.

Bildquelle: soeren-hentzschel.at/mozilla-umsatz

Ausblick auf 2020

Der Finanzbericht für das Jahr 2020 wird voraussichtlich Ende November bis Mitte Dezember 2021 veröffentlicht werden. Für das Jahr 2020 ist mit deutlich weniger Gewinn als in 2019 zu rechnen, da die hohe Summe, welche es 2019 von Yahoo gab, eine einmalige Zahlung war. Außerdem leidet auch Mozilla an den Folgen von COVID-19, was im August 2020 zu einer Kündigung von ungefähr 250 Mitarbeitern führte, nachdem bereits im Januar 2020 die Kündigung von mindestens 70 Mitarbeitern erfolgte, weil Mozilla mit den Gewinnerwartungen für neue Produkte hinter den eigenen Planungen zurückgeblieben war.

Für 2020 ist mit zusätzlichen Einnahmen durch das Mozilla VPN zu rechnen, welches offiziell als Produkt in mehreren Ländern gestartet ist. Außerdem hat Mozilla mit Firefox Better Web den Beta-Test eines weiteren kostenpflichtigen Angebots in den USA gestartet und die Hubs Cloud in Betrieb genommen.

Im August 2020 hat Mozilla seinen Suchmaschinen-Vertrag mit Google um weitere drei Jahre bis 2023 verlängert. Es war von schätzungsweise 400 bis 450 Millionen Dollar pro Jahr die Rede, welche Mozilla dafür erhalten soll, dass Google in den meisten Regionen die Standard-Suchmaschine in Firefox bleibt. Die genauen Vertragsmodalitäten sind aber natürlich nicht öffentlich, so dass die entsprechenden Finanzberichte abzuwarten bleiben. Die Auswirkungen des neuen Google-Deals dürften sich aber erst im Finanzbericht für 2021 vollständig zeigen.

Der Beitrag 828 Millionen Dollar – Mozilla erzielte 2019 einen Rekord-Umsatz erschien zuerst auf soeren-hentzschel.at.

BlackArch Linux 2020.12.01

Das auf Arch Linux basierende Sicherheitswerkzeug enthält nun den Linux-Kernel 5.9.11, aktualisierte Pakete, Konfigurationsdateien und Werkzeuge. Außerdem wurden mehr als 100 neue Hacking-Tools hinzugefügt, sodass sich die Gesamtzahl der Tools in BlackArch auf  über 2000 beläuft.

Weitere Information beinhaltet der Changelog

• added more than 100 new tools
• renamed 'live iso' to 'full iso'
• updated blackarch-installer to v1.2.16
• included linux kernel 5.9.11
• adapted ISO creation to the new archiso version (work in progress)
• removed unnecessary files from the ISO env
• QA'ed and fixed a lot of packages (runtime exec, missing dependencies...)
• updated all vim plugins and improved vim config options
• updated all blackarch tools and packages including config files
• updated all system packages
• updated all window manager menus (awesome, fluxbox, openbox)

Kali Linux 2020.4

Der Platzhirsch hat ebenfalls geliefert und bringt die ZSH Shell für alle, die das Schweizer Messer frisch installieren. Das BASH Terminal hat in diesem Zuge auch ein Makerover erhalten und sieht nun etwas mehr nach ZSH aus.

Wer mit ZSH so gar nicht auf einen grünen Zweig kommt, es gibt einen Weg zurück zu BASH:

chsh -s /bin/bash

Zusätzlich hat die Kommandozeile einen neuen Infobereich erhalten, welcher sich je nach Installationsart anders präsentiert.

Win-KeX 2.5, der Windows Modus für WSL2 bringt den neuen “Enhanced Session Mode”, was Win-KeX auf Windows on ARM Geräten ermöglicht.

Dieses Feature wird in Zukunft relevanter werden, da Microsoft nun mit Surface X auch ARM Geräte im Portfolio hat. Solange aber WSL2 nicht richtig zusammen mit VirtualBox und Co funktioniert, ist dies weiterhin experimentell. (Siehe ITrig Artikel)

Die Kali-Dokumentation wurde schon vor einiger Zeit von WordPress zu Hugo migriert und ist unter kali.org/docs zu finden. Das Design wurde hier weiter angepasst.

Bei den Tools haben sich ebenfalls einige Neuzugänge eingeschlichen: Apple bleee, CertGraph, dnscat2, FinalRecon, goDoH, hostapd-mana, Metasploit Framework v6 und Whatmask

Weitere Änderungen können dem Changelog entnommen werden.

Übersicht 12/2020

Am 08. Dezember 2020 wurde wie geplant zum Jahresende Qt 6.0 veröffentlicht. Unterstützung für C++17, eine neue Generation von QML, ein CMake Buildsystem sowie eine neue Grafikarchitektur sind die wichtigsten Änderungen.

Qt ist ein sehr verbreitetes plattformübergreifendes Anwendungsframework. Dabei steht klar die Entwicklung graphischer Benutzeroberflächen (GUIs) im Vordergrund, allerdings erweitert Qt generell die übliche Standardbibliothek um eine Vielzahl von Funktionen, die die Entwicklung vereinfachen sollen.

Nun wurde Version 6 des 25 Jahre alten Frameworks veröffentlicht, wie gestern im Qt-Blog angekündigt wurde. Dem Release vorausgegangen war die Vision aus August 2019.

Die Änderungen im Überblick

Qt 6.0 greift nun auf C++17 zurück, wodurch nun ein C++17-kompatibler Compiler Voraussetzung ist, um das Framework zu bauen.

Qt Core wurde an vielen Stellen verbessert: so ist nun das property und binding system neu, das direkt aus C++-Code angesprochen werden kann. Dabei lassen sich bestimmte Zusammenhänge festlegen, die dann vom Framework umgesetzt werden, wie bereits im dazugehörigen Blogartikel dazu umrissen wird:

class Rectangle {
public:
    Property<int> width;
    Property<int> height;
    Property<int> border;

    Rectangle() {
        height.setBinding(width);
        border.setBinding([this]() {
            return height / 10;
        });
    }
};

Mit diesem Code soll nun beispielsweise ermöglicht werden, dass ein Rechteck quadratisch ist (width == height) und ein Zehntel der Höhe die Rahmenbreite ist.

Die Integration von Unicode in Strings soll weitestgehend abgeschlossen sein.

QList und QVector werden vereinigt, wobei QVector als Grundlage nun dient und Elemente nun direkt im allokierten Speicher abgelegt werden, ohne nun mehr auf die komplexere Heap-Struktur zurückzugreifen.

Weitere Komponenten aus Qt Core wurden überarbeitet, darunter Qt Concurrent, Qt Network oder auch QMetaType und QVariant.

Während Qt 5 bisher auf OpenGL für die hardwareunterstütze Grafikbeschleunigung gesetzt hat, bekommt Qt Quick, ein Unterframework, das sich auf die schnelle deklarative Erstellung von Benutzeroberflächen fokussiert, mit dem neuen Major-Release einen Abstraktionslayer namens Rendering Hardware Interface (RHI). Dadurch kann auf die native Grafikarchitektur der Laufzeitumgebung zurückgegriffen werden, sodass auf Windows nun Direct3D und auf macOS Metal als Grafik-API genutzt wird.

Von der RHI profitieren auch Qt 3D sowie Qt Quick 3D, wobei letzteres die Qt Quick um 3D-Funktionalitäten erweitern und es ermöglicht, performant 2D-Inhalte in einer 3D-Szene zu platzieren.

Qt Quick Controls unterstützt darüber hinaus nun desktop styling.

Qt läuft auf einer Reihe von Plattformen, darunter die verbreiteten Desktopsysteme, aber auch mobile Plattformen und eingebettete Systeme. Um den spezifischen Anforderungen gerecht zu werden, wurden bisher Add-on-Module eingesetzt. Diese Funktionalität wurde nun in Qt integriert, wie im dazugehörigen Blogbeitrag beschrieben wird.

Beim Buildsystem stehen auch Änderungen an. Führen wir uns die bisherige Implementierung vor Augen, erkennen wir direkt die Bedeutung von qmake, welches aus .pro-Dateien Makefiles erzeugt. Qt 6.0 setzt nun allerdings auf CMake, wird in dieser Version allerdings noch qmake weiterhin unterstützen.

Portierung, Unterstützung, Ausblick

Das Qt-Team bietet eine Anleitung zur Umstellung auf Qt 6.0 an.

Unterstützut werden die verbreiteten Plattformen: Linux-Desktop, Windows 10, macOS ≥ 10.14, iOS ≥ 13, Android ≥ 6. Der Support von Embedded RTOS steht noch aus.

Zusammenfassung und IMHO

Der Major-Release setzt eine Vielzahl an Änderungen um, zum einen an der Oberfläche, zum anderen im Unterbau. Die Unterstützung von C++17 ist eine sinnvolle Neuerung. Eine vollständige Liste der Neuerungen ist hier im Qt Wiki verfügbar.

Wie bei Major-Releases von eng in Anwendungen verzahnten Frameworks üblich, wird wieder einige Zeit ins Land gehen, bis die Portierung erfolgt ist.

Mit keinem Wort im Blogpost wird allerdings die neue Lizenzpolitik erwähnt. Potentielle Änderungen hatten im April die KDE-Community bereits verunsichert. Diese würde Verzögerungen bei der FOSS-Veröffentlichung mit sich ziehen. Im Qt Wiki erklärt allerdings ein Artikel, wie Qt 6 weiterhin aus FOSS-Quellen bezogen werden kann. Dabei wird momentan noch auf das Qt5-Repo zurückgegriffen, welches auch Qt 6 beherbergt. Somit kann wohl vorerst noch Entwarnung gegeben werden, was die Quellen angeht.

Quelle: Blogartikel „Qt 6.0 Released“. Lars Knoll. 08. Dezember 2020.

Dieser Bitcoin wird ja gerade wieder durchs Dorf gejagt, somit lohnt sich auch wieder ein Blick ins Monero Wallet dachte ich mir, allerdings erhielt ich beim Öffnen diesen feinen Fehler:

Wallet konnte nicht geöffnet werden std::bad_alloc bzw. "Couldn't open wallet: std::bad_alloc"

„Alles weg?“, geht einem fix durch den Kopf, muss aber nicht. Denn die GUI, welche seit Jahren auf einer Platte schlummerte, war einfach total veraltet.

Mit einer aktuellen GUI Version (0.17.1.6) von getmonero lief dann alles wieder wie geschmiert.