staging.inyokaproject.org

20. Dezember 2020

  1. Proprietäre Softwareperlen für Linux Teil I: SoftMaker Office
  2. Proprietäre Softwareperlen für Linux Teil II: moneyplex
  3. Proprietäre Softwareperlen für Linux Teil III: Master PDF Editor

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.

Dieser Artikel ist Teil einer Serie:

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.

Dieser Artikel ist Teil einer Serie:

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

"

19. Dezember 2020

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

"

18. Dezember 2020

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

 

 

 

 

17. Dezember 2020

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 

"

16. Dezember 2020

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.

Firefox 84

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.

Firefox 84

Verbesserungen der Entwicklerwerkzeuge

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

Firefox 84

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

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 ;-)

Hier habe ich inzwischen gelernt, dass man tunlichst die Größe des Buffers im Auge behalten sollte.

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

"

15. Dezember 2020

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.

"

9. Dezember 2020

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.

Mozilla Umsatz 2019
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.

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.

8. Dezember 2020

Kurz notiert: das Team hinter CentOS, der Red Hat Enterprise Linux-baiserten Distribution, das sich Januar 2014 mit dem RHEL-Herausgeber Red Hat zusammengeschlossen hat, hat heute eine folgenschwere Ankündigung (CentOS, Red Hat) gemacht. Das Projekt wird sich zukünftig auf CentOS Stream konzentrieren. CentOS 8, die aktuelle Version, wird Ende 2021 aufgegeben – und damit drei Jahre vor dem Vorgänger CentOS 7. Die Nachfolge soll CentOS Stream antreten.

Das ist keine simple Namensänderung, sondern eine fundamentale Neuausrichtung: wurde bisher CentOS als RHEL-Nachbau (d. h. downstream) entwickelt, so ist CentOS Stream upstream, d. h. näher an der Softwarequelle, angelegt.

IMHO ist CentOS zukünftig wohl nicht mehr attraktiv für Produktivumgebungen, die eine stabile Umgebung und eine lange Supportzeit (bisher ca. 10 Jahre) erwarten. Kunden, die so etwas wünschen, werden nun zur Kasse gebeten, entweder mit RHEL selbst oder mit Alternativen wie Oracle Linux. Überraschend ist aus meiner Sicht, dass CentOS nun im upstream-Umfeld herumwildert, da dies eigentlich schon das Gebiet von Fedora ist.

Ebenfalls lesenswert ist hierzu der Kommentar von Michael Kofler.

KDE neon ist die KDE Distribution. Das will man nicht ganz offiziell so sagen, weil man die Partner bei den Distributionen nicht verprellen will, aber eigentlich sieht man das so. Hinsichtlich der Sicherheit ist das aber bestenfalls Amateurliga.

KDE neon ist primär ein Produkt der ehemaligen Kubuntu Maintainer (siehe: Kommentar: KDE neon ist kein Ersatz für Kubuntu). Mit dem Wechsel auf die 20.04 Basis hat man den Ubuntu Installer durch Calamares ersetzt. Soweit so gut, Calamares wird auch von vielen anderen Distributionen in Teilen eingesetzt. Aber wehe, man weicht von den Vorgaben ab, dann bekommt man schlimmstenfalls ein komplett unsicheres System.

Wenn man vor ein paar Jahren ein vollverschlüsseltes LUKS-System aufsetzte, blieb die /boot-Partition unverschlüsselt für den Systemstart (siehe: LUKS – Betriebssystem verschlüsseln). Das ist hinsichtlich der Sicherheit nicht komplett optimal, die Angriffsszenarien sind aber speziell und eher für Leute interessant, die befürchten, ihre Geräte könnten im Interesse eines Geheimdienstes stehen. Seit Kurzem unterstützt GRUB2 jetzt auch den Start direkt in eine verschlüsselte Boot-Partition. Das ist theoretisch total super, hat praktisch aber eine Reihe von Nachteilen. Erstens ist es je nach Konfiguration und Hardware furchtbar langsam. Bei meinem Gerät dauerte es 25 Sekunden, bis der Startvorgang begann. Zudem funktioniert nur ein englisches Tastaturlayout und bei einer fehlerhaften Eingabe landet man sofort im Fehlermodus von Grub und muss hart abschalten und neu einschalten. Diese Nachteile überwiegen bei mir die eher theoretischen Sicherheitszugewinne bei Weitem.

Aus diesem Grund habe ich mich für eine weitgehend klassische Partitionierung entschieden. Eine kleine EFI-Partition, eine separate /boot-Partition und dann einen verschlüsseltes LVM mit meinen System und Home-Partitionen. Das funktioniert bei jeder mir bekannten Distribution und ließ sich auch in KDE neon / Calamares problemlos konfigurieren. Beim Abschluss gibt es eine Warnung wegen der unverschlüsselten Boot-Partition, aber ich konnte zu dem Zeitpunkt nicht ahnen, wie ernst es die Entwickler meinen.

Kleine Ironie am Rande: Während die Routine durchlief, zeigt die Installationsroutine von KDE neon eine nette Slideshow, unter anderem mit einem Schloss und dem Verweis, wie sicher die Distribution sei. Zum Schluss kam der obligatorische Neustart. Bei Single-User-Systemen mit LUKS Verschlüsselung wähle ich – soweit möglich – in der Installationsroutine meist den Autologin des Benutzers, weil die Authentifizierung bereits beim Systemstart erfolgt. Dachte ich jedenfalls.

KDE neon startet und ich finde mich auf dem Desktop wieder. Es gibt reproduzierbar keine Passwortabfrage, wenn der LUKS Container eingebunden wird. Ich vermute, dass irgendwo ein Keyfile hinterlegt ist, weil Calamares von einer verschlüsselten /boot-Partition ausgeht. Fakt ist aber ebenso, dass alle anderen Distributionen mit dieser Legacy-Partitionierung korrekt umgehen können. Ich hatte keine wirkliche Lust die Problemursache zu suchen, weil ein solcher Fauxpas bei mir ein grundsätzliches Misstrauen schürt.

Es ist für mich ein Beispiel für „Schuster bleib bei deinen Leisten“. Die KDE-Macher sollten sich auf die Entwicklung der Desktopumgebung und Programme konzentrieren und die Distribution den Profis dort überlassen, als selbst eine Distribution mit eklatanten Mängeln zusammen zu stümpern. Dass es anscheinend genau gegenteilige Überlegungen gibt, lässt mich nur den Kopf schütteln. Natürlich gibt es bei KDE neon durch die Kubuntu-Vorgeschichte einen gehörigen Erfahrungsschatz, aber es ist eben was anderes eine komplette Distribution herauszugeben, als „nur“ eine Desktopumgebung zu paketieren.


Bilder:

Einleitungs- und Beitragsbild von Gerd Altmann via pixabay

Der Artikel Kommentar: KDE neon – Wirklich so sicher? erschien zuerst auf [Mer]Curius

KDE neon ist die KDE Distribution. Das will man nicht ganz offiziell so sagen, weil man die Partner bei den Distributionen nicht verprellen will, aber eigentlich sieht man das so. Hinsichtlich der Sicherheit ist das aber bestenfalls Amateurliga.

KDE neon ist primär ein Produkt der ehemaligen Kubuntu Maintainer (siehe: Kommentar: KDE neon ist kein Ersatz für Kubuntu). Mit dem Wechsel auf die 20.04 Basis hat man den Ubuntu Installer durch Calamares ersetzt. Soweit so gut, Calamares wird auch von vielen anderen Distributionen in Teilen eingesetzt. Aber wehe, man weicht von den Vorgaben ab, dann bekommt man schlimmstenfalls ein komplett unsicheres System.

Wenn man vor ein paar Jahren ein vollverschlüsseltes LUKS-System aufsetzte, blieb die /boot-Partition unverschlüsselt für den Systemstart (siehe: LUKS - Betriebssystem verschlüsseln). Das ist hinsichtlich der Sicherheit nicht komplett optimal, die Angriffsszenarien sind aber speziell und eher für Leute interessant, die befürchten, ihre Geräte könnten im Interesse eines Geheimdienstes stehen. Seit Kurzem unterstützt GRUB2 jetzt auch den Start direkt in eine verschlüsselte Boot-Partition. Das ist theoretisch total super, hat praktisch aber eine Reihe von Nachteilen. Erstens ist es je nach Konfiguration und Hardware furchtbar langsam. Bei meinem Gerät dauerte es 25 Sekunden, bis der Startvorgang begann. Zudem funktioniert nur ein englisches Tastaturlayout und bei einer fehlerhaften Eingabe landet man sofort im Fehlermodus von Grub und muss hart abschalten und neu einschalten. Diese Nachteile überwiegen bei mir die eher theoretischen Sicherheitszugewinne bei Weitem.

Aus diesem Grund habe ich mich für eine weitgehend klassische Partitionierung entschieden. Eine kleine EFI-Partition, eine separate /boot-Partition und dann einen verschlüsseltes LVM mit meinen System und Home-Partitionen. Das funktioniert bei jeder mir bekannten Distribution und ließ sich auch in KDE neon / Calamares problemlos konfigurieren. Beim Abschluss gibt es eine Warnung wegen der unverschlüsselten Boot-Partition, aber ich konnte zu dem Zeitpunkt nicht ahnen, wie ernst es die Entwickler meinen.

Kleine Ironie am Rande: Während die Routine durchlief, zeigt die Installationsroutine von KDE neon eine nette Slideshow, unter anderem mit einem Schloss und dem Verweis, wie sicher die Distribution sei. Zum Schluss kam der obligatorische Neustart. Bei Single-User-Systemen mit LUKS Verschlüsselung wähle ich - soweit möglich - in der Installationsroutine meist den Autologin des Benutzers, weil die Authentifizierung bereits beim Systemstart erfolgt. Dachte ich jedenfalls.

KDE neon startet und ich finde mich auf dem Desktop wieder. Es gibt reproduzierbar keine Passwortabfrage, wenn der LUKS Container eingebunden wird. Ich vermute, dass irgendwo ein Keyfile hinterlegt ist, weil Calamares von einer verschlüsselten /boot-Partition ausgeht. Fakt ist aber ebenso, dass alle anderen Distributionen mit dieser Legacy-Partitionierung korrekt umgehen können. Ich hatte keine wirkliche Lust die Problemursache zu suchen, weil ein solcher Fauxpas bei mir ein grundsätzliches Misstrauen schürt.

Es ist für mich ein Beispiel für "Schuster bleib bei deinen Leisten". Die KDE-Macher sollten sich auf die Entwicklung der Desktopumgebung und Programme konzentrieren und die Distribution den Profis dort überlassen, als selbst eine Distribution mit eklatanten Mängeln zusammen zu stümpern. Dass es anscheinend genau gegenteilige Überlegungen gibt, lässt mich nur den Kopf schütteln. Natürlich gibt es bei KDE neon durch die Kubuntu-Vorgeschichte einen gehörigen Erfahrungsschatz, aber es ist eben was anderes eine komplette Distribution herauszugeben, als "nur" eine Desktopumgebung zu paketieren.


Bilder:

Einleitungs- und Beitragsbild von Gerd Altmann via pixabay

"

4. Dezember 2020

Wir sind mittlerweile im Jahr 2020 angekommen. Podcasts haben sich mehr oder weniger durchgesetzt und sehr viele Leute hören nicht nur Podcasts, sondern produzieren auch selbst welche. Vor allem im Tech-Bereich gibts es gefühlt schon fast mehr als genug…

Nichtsdestotrotz – oder gerade deswegen? – dachten sich Dirk Deimeke und ich: Es wird Zeit, dass wir auch mal einen Podcast starten. Den Gedanken und die Pläne dazu hatten wir eigentlich schon vor zwei Jahren. Aber aus diversen Gründen wurde daraus erstmal nichts und wir haben es aufgeschoben. Jetzt ist aber endlich so weit.

Mittlerweile haben wir auch schon die nullte und die erste Folge veröffentlicht. In der nullten Episode erzählen wir von unseren Plänen für den Podcast. Darunter was das Konzept des Podcasts ist und welche Themen wir behandeln wollen. Außerdem gibt es einen Rückblick wie und wann Dirk und ich uns kennen gelernt haben.

Spoiler: In diesem Podcast geht es nicht (ausschließlich) um Open Source, sondern vor allem um Tech, aber auch um Produktivitäts- und IT-Karriere-Themen. Es wird also hoffentlich ein gesunder Mix aus den verschiedenen Themen sein.

Die erste reguläre Episode behandelt das Thema „GitOps“ und „Keine Zeit haben“. Wie ihr aus dem Titel dieses Blogposts erkennen könnt, lautet der Name des Podcasts „TILpod“ und dieser ist unter TILpod.net erreichbar. „TIL“ steht dabei für „Today I learned“, es geht also um Themen die neu für uns beide waren.

Bevorzugt lässt sich der Podcast natürlich überall da hören, wo es Podcasts gibt. Die nächste, und somit zweite Episode, erscheint am 1. Januar 2021. Wir peilen also mindestens ein monatliches Release an. Je nach Lust und Laune kann da durchaus noch eine zusätzliche Folge pro Monat entstehen.

Hört gerne rein! Und sehr cool wäre es, wenn ihr uns fleißig Feedback da lässt. Für den Beginn müssen wir uns wohl erstmal ein wenig einspielen, bis es dann hoffentlich über die Zeit besser wird – sowohl inhaltlich als auch von der Technik.

Links

3. Dezember 2020

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

Neuerungen von Thunderbird 78.5.1

Die MZLA Technologies Corporation hat Thunderbird 78.5.1 veröffentlicht und bringt damit wieder eine ganze Reihe von Fehlerbehebungen sowie kleineren Verbesserungen, die sich im Detail in den Release Notes (engl.) nachlesen lassen. Auch eine Sicherheitslücke wurde in Thunderbird 78.5.1 behoben.

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

Werbeblocker zu nutzen ist heutzutage reine Selbstverteidigung. Schließlich geht es nicht nur um optische Nervereien oder Popup-Bomben wie vor 20 Jahren, sondern um Tracking und Profilbildung. Problematisch wird es, sobald man den Browser verlässt. Hier schließt KDE mit einem Adblocker für KDEPIM eine Lücke.

Tracking tritt schließlich nicht nur beim „freien“ surfen im Internet auf, sondern kann überall erfolgen. Im Heimnetz mag da ein Pi-Hole helfen, aber unterwegs sieht das schon wieder anders aus. Unter Linux gibt es kaum Werbung in Programmen und massenhaftes Abgreifen von Telemetriedaten ist auch kein großes Problem. Wobei es durchaus prominente Gegenbeispiele wie z. B. Firefox gibt aber das sei nur am Rande erwähnt. Zwei relevante Baustellen sind aber E-Mails und RSS-Feeds. Erstere können bei HTML Mails und etwaigen nachgeladenen Bildern ausgewertet werden und Letztere enthalten inzwischen oftmals rudimentäre Browser, da viele Feeds nur noch gekürzt ausgeliefert werden. Hier bietet KDE mit dem integrierten Adblocker einen Basisschutz gegen Werbung und Tracking.

Bei den meisten Distributionen dürfte es mit KDEPIM automatisch mitinstalliert werden, ansonsten empfiehlt es sich nach einem Paket mit dem Namen kdepim-addons oder ähnlich zu suchen.

Die Einstellungen finden sich etwas versteckt in KMail unter Einstellungen / Module ganz unten.

Es wäre natürlich nicht KDE, wenn es alles fehlerfrei funktionieren würde. Der kleine Fallstrick ist erst die Option zu aktivieren und anschließend per OK zu bestätigen. Anschließend öffnet man das Modul wieder und fügt Filterlisten hinzu. Unterlässt man diesen Zwischenschritt, lassen sich keine Filterlisten hinzufügen. Bei den Listen hat man eine recht große Auswahl, ich persönliche habe jetzt mal EasyList und die Extraliste für Deutschland ausgewählt.

Dieses Modul ist schon für KMail sehr nett, aber da es sich auf die Webengine bezieht, steht es auch in Akregator zur Verfügung. Hier befreit es wirkungsvoll von den ganzen Werbebannern und Trackern, die zunehmend sogar in Volltextfeeds eingebunden werden.


Bilder:
Einleitungsbild und Beitragsbild von von 200 Degrees via pixabay 

Der Artikel Adblocker in KDEPIM – Ein sinnvolles Puzzlestück erschien zuerst auf [Mer]Curius

Werbeblocker zu nutzen ist heutzutage reine Selbstverteidigung. Schließlich geht es nicht nur um optische Nervereien oder Popup-Bomben wie vor 20 Jahren, sondern um Tracking und Profilbildung. Problematisch wird es, sobald man den Browser verlässt. Hier schließt KDE mit einem Adblocker für KDEPIM eine Lücke.

Tracking tritt schließlich nicht nur beim "freien" surfen im Internet auf, sondern kann überall erfolgen. Im Heimnetz mag da ein Pi-Hole helfen, aber unterwegs sieht das schon wieder anders aus. Unter Linux gibt es kaum Werbung in Programmen und massenhaftes Abgreifen von Telemetriedaten ist auch kein großes Problem. Wobei es durchaus prominente Gegenbeispiele wie z. B. Firefox gibt aber das sei nur am Rande erwähnt. Zwei relevante Baustellen sind aber E-Mails und RSS-Feeds. Erstere können bei HTML Mails und etwaigen nachgeladenen Bildern ausgewertet werden und Letztere enthalten inzwischen oftmals rudimentäre Browser, da viele Feeds nur noch gekürzt ausgeliefert werden. Hier bietet KDE mit dem integrierten Adblocker einen Basisschutz gegen Werbung und Tracking.

Bei den meisten Distributionen dürfte es mit KDEPIM automatisch mitinstalliert werden, ansonsten empfiehlt es sich nach einem Paket mit dem Namen kdepim-addons oder ähnlich zu suchen.

Die Einstellungen finden sich etwas versteckt in KMail unter Einstellungen / Module ganz unten.

Es wäre natürlich nicht KDE, wenn es alles fehlerfrei funktionieren würde. Der kleine Fallstrick ist erst die Option zu aktivieren und anschließend per OK zu bestätigen. Anschließend öffnet man das Modul wieder und fügt Filterlisten hinzu. Unterlässt man diesen Zwischenschritt, lassen sich keine Filterlisten hinzufügen. Bei den Listen hat man eine recht große Auswahl, ich persönliche habe jetzt mal EasyList und die Extraliste für Deutschland ausgewählt.

Dieses Modul ist schon für KMail sehr nett, aber da es sich auf die Webengine bezieht, steht es auch in Akregator zur Verfügung. Hier befreit es wirkungsvoll von den ganzen Werbebannern und Trackern, die zunehmend sogar in Volltextfeeds eingebunden werden.


Bilder:
Einleitungsbild und Beitragsbild von von 200 Degrees via pixabay 

"