staging.inyokaproject.org

Telefon und SMS sind nur noch ein Kommunikationsmittel unter vielen. Die Messenger-Vielfalt hat zur parallelen Nutzung zahlloser Dienste geführt, die wir unter verschiedenen Endgeräten nutzen. Die Inhalte der einzelnen Kommunikationsstränge gleichzeitig auf allen Geräten verfügbar zu haben ist aber nach wie vor eine Herausforderung.

Linux bietet in einer vernetzten Welt keinen Komfort - wohl aber verschiedene Werkzeuge um einen hohen Grad an Vernetzung zu erreichen. In der Serie "Cloud unter Kontrolle" wird genau diese Vernetzung Thema sein. Das Ziel ist eine Lösung, die in etwa dem umfassenden Angebot entspricht, wie es Apple mit den iCloud-Diensten oder Google mit seinen Lösungen bietet. Allerdings unter Kontrolle des Nutzers.

 Serie:

1. Cloud in Eigenregie I: Vorbemerkungen
2. Cloud in Eigenregie II: Basis für Nextcloud wählen
3. Cloud in Eigenregie III: Nextcloud einrichten
4. Cloud in Eigenregie IV: Dateien über die Cloud verwalten
5. Cloud in Eigenregie V: Integration in GNOME
6. Cloud in Eigenregie VI: Kontakte synchronisieren
7. Cloud in Eigenregie VII: Kalender und Aufgaben verwalten
8. Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren
9. Cloud in Eigenregie IX: Baustelle Podcasts
10. Cloud in Eigenregie X: Notizen
11. Cloud in Eigenregie XI: Gedanken zu E-Mails
12. Cloud in Eigenregie XII: Messenger Nachrichten
13. Cloud in Eigenregie XIII: Passwörter synchronisieren
14. Cloud in Eigenregie XIV: Browserverlauf und Favoriten synchronisieren
15. Cloud in Eigenregie XV: Zusammenfassung

Apple hat vergangenes Jahr hierfür den iCloud-Sync für iMessages und SMS eingeführt (siehe auch: iMessage - Sichere Kommunikation mit Schwachstellen). Alle Nachrichten werden auf alle Geräte verteilt und lassen sich von dort aus schreiben. Dadurch kann man am Desktop auch mal eine SMS schreiben, die dann über das iPhone verschickt wird. Die Speicherung in der iCloud erfolgt ähnlich wie beim Schlüsselund Ende-zu-Ende verschlüsselt. Vorausgesetzt man vertraut der Apple-Implementierung, da diese natürlich nicht transparent einsehbar ist.

Für Linux ist das ganze Thema deutlich schwieriger. Erstens fehlt der eine präferierte Messenger mit direktem Systembezug, wie iMessage bei Apple. Zweitens mangelt es an kohärenten Synchronisationslösungen für die meisten Messenger.

Populäre Lösungen wie WhatsApp, Signal, Threema & Co bieten für den Desktop lediglich Webclients an. Dadurch kann man zwar am Desktop Nachrichten lesen und schreiben, aber es gibt keine Integration in das System. Die so genanten Desktop-Apps sind meist Electron-basierte Webapps und setzten eine direkte Verbindung mit dem Smartphone voraus. Dies ist bei Apples iMessage-Lösung beispielsweise nicht der Fall. Die einzige Ausnahme bildet hier Telegram. Die Desktop App von Telegram beherrscht aber keine verschlüsselten Nachrichten, da diese sich nicht über die Cloud synchronisieren lassen. Bei allen Diensten ist eine Synchronisation über eine eigene Cloud-Instanz wie z. B. die Nextcloud nicht möglich.

Kaum besser sieht es hier im Bereich der SMS Synchronisation aus. Hier gibt es lediglich eine experimentelle App für die Nextcloud mit Anbindung an Android. Dadurch ist zumindest Lesezugriff auf die Nachrichten vom Desktop aus möglich, zum Verfassen einer Nachricht benötigt man aber wieder das Smartphone.

Eine Lösung ist der Verzicht auf eine Cloud-Zwischeninstanz. Das famose KDEConnect bietet seit einiger Zeit die Möglichkeit SMS Nachrichten vom Desktop aus zu verschicken - sofern Smartphone und Desktop sich im gleichen WLAN befinden. KDEConnect ist sowieso ein fast schon unverichtbares Hilfsmittel und Android-Smartphones mit Linux zu verbinden.

Insgesamt ist die Situation bei den Messenger sehr unbefriedigend. Allerdings gilt dies für eigentlich alle Betriebssysteme, abgesehen von Apples Ökosystem. Eine Synchronisation über ein eigene Cloud-Instanz ist unmöglich. Die meisten Lösungen bieten lediglich WebApps mit direkter Smartphone-Verbindung. Oder habe ich hier etwas übersehen? Ergänzungen daher bitte gerne unter diesen Artikel.

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay

Telefon und SMS sind nur noch ein Kommunikationsmittel unter vielen. Die Messenger-Vielfalt hat zur parallelen Nutzung zahlloser Dienste geführt, die wir unter verschiedenen Endgeräten nutzen. Die Inhalte der einzelnen Kommunikationsstränge gleichzeitig auf allen Geräten verfügbar zu haben ist aber nach wie vor eine Herausforderung.

Linux bietet in einer vernetzten Welt keinen Komfort - wohl aber verschiedene Werkzeuge um einen hohen Grad an Vernetzung zu erreichen. In der Serie "Cloud unter Kontrolle" wird genau diese Vernetzung Thema sein. Das Ziel ist eine Lösung, die in etwa dem umfassenden Angebot entspricht, wie es Apple mit den iCloud-Diensten oder Google mit seinen Lösungen bietet. Allerdings unter Kontrolle des Nutzers.

 Serie:

1. Cloud in Eigenregie I: Vorbemerkungen
2. Cloud in Eigenregie II: Basis für Nextcloud wählen
3. Cloud in Eigenregie III: Nextcloud einrichten
4. Cloud in Eigenregie IV: Dateien über die Cloud verwalten
5. Cloud in Eigenregie V: Integration in GNOME
6. Cloud in Eigenregie VI: Kontakte synchronisieren
7. Cloud in Eigenregie VII: Kalender und Aufgaben verwalten
8. Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren
9. Cloud in Eigenregie IX: Baustelle Podcasts
10. Cloud in Eigenregie X: Notizen
11. Cloud in Eigenregie XI: Gedanken zu E-Mails
12. Cloud in Eigenregie XII: Messenger Nachrichten
13. Cloud in Eigenregie XIII: Passwörter synchronisieren
14. Cloud in Eigenregie XIV: Browserverlauf und Favoriten synchronisieren
15. Cloud in Eigenregie XV: Zusammenfassung

Apple hat vergangenes Jahr hierfür den iCloud-Sync für iMessages und SMS eingeführt (siehe auch: iMessage - Sichere Kommunikation mit Schwachstellen). Alle Nachrichten werden auf alle Geräte verteilt und lassen sich von dort aus schreiben. Dadurch kann man am Desktop auch mal eine SMS schreiben, die dann über das iPhone verschickt wird. Die Speicherung in der iCloud erfolgt ähnlich wie beim Schlüsselund Ende-zu-Ende verschlüsselt. Vorausgesetzt man vertraut der Apple-Implementierung, da diese natürlich nicht transparent einsehbar ist.

Für Linux ist das ganze Thema deutlich schwieriger. Erstens fehlt der eine präferierte Messenger mit direktem Systembezug, wie iMessage bei Apple. Zweitens mangelt es an kohärenten Synchronisationslösungen für die meisten Messenger.

Populäre Lösungen wie WhatsApp, Signal, Threema & Co bieten für den Desktop lediglich Webclients an. Dadurch kann man zwar am Desktop Nachrichten lesen und schreiben, aber es gibt keine Integration in das System. Die so genanten Desktop-Apps sind meist Electron-basierte Webapps und setzten eine direkte Verbindung mit dem Smartphone voraus. Dies ist bei Apples iMessage-Lösung beispielsweise nicht der Fall. Die einzige Ausnahme bildet hier Telegram. Die Desktop App von Telegram beherrscht aber keine verschlüsselten Nachrichten, da diese sich nicht über die Cloud synchronisieren lassen. Bei allen Diensten ist eine Synchronisation über eine eigene Cloud-Instanz wie z. B. die Nextcloud nicht möglich.

Kaum besser sieht es hier im Bereich der SMS Synchronisation aus. Hier gibt es lediglich eine experimentelle App für die Nextcloud mit Anbindung an Android. Dadurch ist zumindest Lesezugriff auf die Nachrichten vom Desktop aus möglich, zum Verfassen einer Nachricht benötigt man aber wieder das Smartphone.

Eine Lösung ist der Verzicht auf eine Cloud-Zwischeninstanz. Das famose KDEConnect bietet seit einiger Zeit die Möglichkeit SMS Nachrichten vom Desktop aus zu verschicken - sofern Smartphone und Desktop sich im gleichen WLAN befinden. KDEConnect ist sowieso ein fast schon unverichtbares Hilfsmittel und Android-Smartphones mit Linux zu verbinden.

Insgesamt ist die Situation bei den Messenger sehr unbefriedigend. Allerdings gilt dies für eigentlich alle Betriebssysteme, abgesehen von Apples Ökosystem. Eine Synchronisation über ein eigene Cloud-Instanz ist unmöglich. Die meisten Lösungen bieten lediglich WebApps mit direkter Smartphone-Verbindung. Oder habe ich hier etwas übersehen? Ergänzungen daher bitte gerne unter diesen Artikel.

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay

Kurz angemerkt: seit dem heutigen Morgen gibt es in der Infrastruktur für Mozilla Firefox-Addons Störungen. Grund ist ein abgelaufenes Intermediate-Zertifikat. Das hat zur Folge, dass die Addons keine gültige Signatur mehr haben, als Legacy und somit als Sicherheitsrisiko eingestuft und deaktviert werden.

In dem Zusammenhang hier einige Verweise:

• Thread im Mozilla Discourse (Zeitweise nicht mehr erreichbar)
• das Ticket in Bugzilla
• Workarounds (beide meinerseits unconfirmed): einer auf Hacker News, ein anderer auf Reddit

Update: momentan ist die Discourse-Seite wieder schlecht erreichbar, aber folgendes Update konnte ich erhaschen:

(Post von Caitlin Neiman)

12:50 p.m. UTC / 03:50 a.m. PDT: We rolled-out a fix for release, beta and nightly users on Desktop. The fix will be automatically applied in the background within the next few hours, you don’t need to take active steps.

In order to be able to provide this fix on short notice, we are using the Studies system. You can check if you have studies enabled by going to Firefox Preferences -> Privacy & Security -> Allow Firefox to install and run studies.

You can disable studies again after your add-ons have been re-enabled.

We are working on a general fix that doesn’t need to rely on this and will keep you updated.

See the latest updates here >

E-Mails sind immer noch ein wichtiges Kommunikationsmedium - allen Unkenrufen zum Trotz. Als dezentrales Protokoll, das weitestgehend auf freier Software basiert kann man theoretisch den kompletten Dienst selber betreiben. Doch macht das Sinn? Ein paar Überlegungen zu diesem Thema.

Linux bietet in einer vernetzten Welt keinen Komfort - wohl aber verschiedene Werkzeuge um einen hohen Grad an Vernetzung zu erreichen. In der Serie "Cloud unter Kontrolle" wird genau diese Vernetzung Thema sein. Das Ziel ist eine Lösung, die in etwa dem umfassenden Angebot entspricht, wie es Apple mit den iCloud-Diensten oder Google mit seinen Lösungen bietet. Allerdings unter Kontrolle des Nutzers.

 Serie:

1. Cloud in Eigenregie I: Vorbemerkungen
2. Cloud in Eigenregie II: Basis für Nextcloud wählen
3. Cloud in Eigenregie III: Nextcloud einrichten
4. Cloud in Eigenregie IV: Dateien über die Cloud verwalten
5. Cloud in Eigenregie V: Integration in GNOME
6. Cloud in Eigenregie VI: Kontakte synchronisieren
7. Cloud in Eigenregie VII: Kalender und Aufgaben verwalten
8. Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren
9. Cloud in Eigenregie IX: Baustelle Podcasts
10. Cloud in Eigenregie X: Notizen
11. Cloud in Eigenregie XI: Gedanken zu E-Mails
12. Cloud in Eigenregie XII: Messenger Nachrichten
13. Cloud in Eigenregie XIII: Passwörter synchronisieren
14. Cloud in Eigenregie XIV: Browserverlauf und Favoriten synchronisieren
15. Cloud in Eigenregie XV: Zusammenfassung

Die meisten nutzen für E-Mail Kommunikation einen externen Dienstleister. Seien es die zig kostenlosen Angebote oder ein kostenpflichtiger Premium-Dienst. Grundsätzlich lässt sich ein E-Mail Dienst allerdings auch selbst betreiben. Die dafür notwendige Software ist durchweg Open Source und auch die großen Betreiber greifen meist auf nichts anderes zurück. Vor einigen Jahren gab es auf Golem.de eine kleine Reihe zum eigenen Mail-Server. 

Das ganze Unterfangen setzt aber ein gehöriges Maß an Expertise voraus. Deshalb beschränken sich die meisten Anleitungen auch auf einen reinen Abholdienst. Der Homeserver holt die Mails vom Dienstleister ab, speichert sie und verteilt sie per IMAP an die Endgeräte. Viele proprietäre NAS-Systeme bieten heute ebenfalls derartige Funktionen. Der Versand erfolgt weiterhin über den Dienstleister. Die Abwicklung des Versandes über einen eigenen Service setzt derart viel Knowhow voraus, dass es die Kenntnisse der allermeisten Anwender übersteigen dürfte. Weniger aufgrund technischer Limitationen, sondern eher weil man als Mikro-Provider schnell auf der Blacklist der großen Dienste landet.

Der Aufwand lohnt meiner Meinung nach nicht. E-Mails sind vergleichsweise kleine Datenmengen. In dem Moment, in dem man eine E-Mail unverschlüsselt verschickt hat und sie - bestenfalls trasportverschlüsselt - von einem E-Mail Provider zum nächsten gewandert ist, waren die Metadaten und Inhalte bereits vielfältigen Zugriffsmöglichkeiten ausgesetzt. Das können Geheimdienste sein, die an den zentralen Knoten des Internets sitzen und den Datenverkehr mitschneiden, oder auch die großen IT-Konzerne. Dank Diensten wie die G Suite garantiert eine Firmen-E-Mail Adresse schließlich nicht mehr, dass Google nicht die Finger im Spiel hat.

Wenn man also mit einem eigenen Mailserver die E-Mails bei seinem Provider abholt ist eine mögliche Auswertung der eigenen Kommunikation bereits erfolgt - sowohl die Metadaten betreffend, als auch die Kommunikationsinhalte. Letztere kann man natürlich per Ende-zu-Ende Verschlüsselung schützen (siehe auch: E-Mail Kommunikation absichern).

Der Arbeitsaufwand durch den Betrieb eines eigenen Mailserver, inklusive der Folgearbeiten wie eine gute Backupstrategie, steht also keinem nennenswerten Gewinn an Privatsphäre gegenüber. Lieber sollte man sich einen guten - d. h. zuverlässigen und Privatsphäre-orienterten - Mailprovider suchen und dafür ein paar Euro im Jahr in die Hand nehmen.

Einen eigenen Mailserver sollte man nur betreiben, wenn man Spaß am Erkenntnisgewinn hat oder sehr große E-Mail Mengen archivieren möchte. Die meisten Provider bieten nämlich einen begrenzten Speicherplatz an. Privatsphäre und Datenschutz lassen sich mit E-Mails eh kaum vereinen, da auch die Inhaltsverschlüsselung die Metadaten nicht schützt. Hier sollte man dann auf moderne Messenger ausweichen (siehe auch: Die E-Mail wird niemals sicher sein!).

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay

E-Mails sind immer noch ein wichtiges Kommunikationsmedium - allen Unkenrufen zum Trotz. Als dezentrales Protokoll, das weitestgehend auf freier Software basiert kann man theoretisch den kompletten Dienst selber betreiben. Doch macht das Sinn? Ein paar Überlegungen zu diesem Thema.

Linux bietet in einer vernetzten Welt keinen Komfort - wohl aber verschiedene Werkzeuge um einen hohen Grad an Vernetzung zu erreichen. In der Serie "Cloud unter Kontrolle" wird genau diese Vernetzung Thema sein. Das Ziel ist eine Lösung, die in etwa dem umfassenden Angebot entspricht, wie es Apple mit den iCloud-Diensten oder Google mit seinen Lösungen bietet. Allerdings unter Kontrolle des Nutzers.

 Serie:

1. Cloud in Eigenregie I: Vorbemerkungen
2. Cloud in Eigenregie II: Basis für Nextcloud wählen
3. Cloud in Eigenregie III: Nextcloud einrichten
4. Cloud in Eigenregie IV: Dateien über die Cloud verwalten
5. Cloud in Eigenregie V: Integration in GNOME
6. Cloud in Eigenregie VI: Kontakte synchronisieren
7. Cloud in Eigenregie VII: Kalender und Aufgaben verwalten
8. Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren
9. Cloud in Eigenregie IX: Baustelle Podcasts
10. Cloud in Eigenregie X: Notizen
11. Cloud in Eigenregie XI: Gedanken zu E-Mails
12. Cloud in Eigenregie XII: Messenger Nachrichten
13. Cloud in Eigenregie XIII: Passwörter synchronisieren
14. Cloud in Eigenregie XIV: Browserverlauf und Favoriten synchronisieren
15. Cloud in Eigenregie XV: Zusammenfassung

Die meisten nutzen für E-Mail Kommunikation einen externen Dienstleister. Seien es die zig kostenlosen Angebote oder ein kostenpflichtiger Premium-Dienst. Grundsätzlich lässt sich ein E-Mail Dienst allerdings auch selbst betreiben. Die dafür notwendige Software ist durchweg Open Source und auch die großen Betreiber greifen meist auf nichts anderes zurück. Vor einigen Jahren gab es auf Golem.de eine kleine Reihe zum eigenen Mail-Server. 

Das ganze Unterfangen setzt aber ein gehöriges Maß an Expertise voraus. Deshalb beschränken sich die meisten Anleitungen auch auf einen reinen Abholdienst. Der Homeserver holt die Mails vom Dienstleister ab, speichert sie und verteilt sie per IMAP an die Endgeräte. Viele proprietäre NAS-Systeme bieten heute ebenfalls derartige Funktionen. Der Versand erfolgt weiterhin über den Dienstleister. Die Abwicklung des Versandes über einen eigenen Service setzt derart viel Knowhow voraus, dass es die Kenntnisse der allermeisten Anwender übersteigen dürfte. Weniger aufgrund technischer Limitationen, sondern eher weil man als Mikro-Provider schnell auf der Blacklist der großen Dienste landet.

Der Aufwand lohnt meiner Meinung nach nicht. E-Mails sind vergleichsweise kleine Datenmengen. In dem Moment, in dem man eine E-Mail unverschlüsselt verschickt hat und sie - bestenfalls trasportverschlüsselt - von einem E-Mail Provider zum nächsten gewandert ist, waren die Metadaten und Inhalte bereits vielfältigen Zugriffsmöglichkeiten ausgesetzt. Das können Geheimdienste sein, die an den zentralen Knoten des Internets sitzen und den Datenverkehr mitschneiden, oder auch die großen IT-Konzerne. Dank Diensten wie die G Suite garantiert eine Firmen-E-Mail Adresse schließlich nicht mehr, dass Google nicht die Finger im Spiel hat.

Wenn man also mit einem eigenen Mailserver die E-Mails bei seinem Provider abholt ist eine mögliche Auswertung der eigenen Kommunikation bereits erfolgt - sowohl die Metadaten betreffend, als auch die Kommunikationsinhalte. Letztere kann man natürlich per Ende-zu-Ende Verschlüsselung schützen (siehe auch: E-Mail Kommunikation absichern).

Der Arbeitsaufwand durch den Betrieb eines eigenen Mailserver, inklusive der Folgearbeiten wie eine gute Backupstrategie, steht also keinem nennenswerten Gewinn an Privatsphäre gegenüber. Lieber sollte man sich einen guten - d. h. zuverlässigen und Privatsphäre-orienterten - Mailprovider suchen und dafür ein paar Euro im Jahr in die Hand nehmen.

Einen eigenen Mailserver sollte man nur betreiben, wenn man Spaß am Erkenntnisgewinn hat oder sehr große E-Mail Mengen archivieren möchte. Die meisten Provider bieten nämlich einen begrenzten Speicherplatz an. Privatsphäre und Datenschutz lassen sich mit E-Mails eh kaum vereinen, da auch die Inhaltsverschlüsselung die Metadaten nicht schützt. Hier sollte man dann auf moderne Messenger ausweichen (siehe auch: Die E-Mail wird niemals sicher sein!).

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay

Der Anbieter Purism, bekannt durch seine Endgeräte für eine besonders Sicherheits-affine Zielgruppe und das ambitionierte Projekt Librem 5, hat nun den Start eines Dienste-Portfolios namens Librem One bekannt gegeben. Eine Crownfunding-Kampagne soll die Basis für ein ambitioniertes Dienste-Angebot legen.

Librem One besteht momentan aus 4 Bestandteilen:

1. Librem Chat: Ein Matrix-basierter Messenger, der VoIP und Videochats untersützt und Ende-zu-Ende Verschlüsselt ist.
2. Librem Mail: Eine E-Mail Angebot mit Ende-zu-Ende-verschlüsselung.
3. Librem Tunnel: Ein VPN Dienst mit Privacy-Fokus
4. Librem Social: Eine Mastodon Instanz

Hinzu kommen planmäßig ein Cloud-Service, sowie ein Speicherort für Backups. Mit Librem Pay und Librem Dial sind weiterhin zwei Produkte angekündigt, deren genaue Ausgestaltung interessant werden dürfte.

Das Komplettangebot kostet 7,99$ im Monat. Der Preis ist gemessen an der Konkurrenz gerechtfertigt, da bei den meisten anderen Anbietern bereits ein VPN-Angebot in ähnlicher Höhe veranschlagt ist.

Purism scheint mit diesem Dienste-Portfolio den Start von Librem 5 vorbereiten zu wollen. Das Smartphone basiert nach vorliegenden Informationen auf einer herkömmlichen Linux-Basis mit GNOME-, Plasma oder Unity-Oberfläche. GNOME wird dabei wohl der Standard sein. Da alle bekannten Lösungen ausschließlich für Android und iOS vorliegen, sah man sich scheinbar genötigt ein eigenes Angebot zu entwickeln um den Kunde wenigstens etwas bieten zu können.

Nichts desto weniger ist dieses Angebot zu begrüßen. Probleme beim Start muss man verzeihen. Im Januar hatte ich hier noch beklagt, dass kein Distributor versucht die vorhandenen Dienste zu einem Paket zusammen zu schnüren und seinen Anwendern durch eine niedrige Einstiegshürde schmackhaft zu machen (siehe auch: Warum Linux in einer vernetzten Welt einfach keinen Komfort bietet!). Purism macht nun genau das.

Leider ist Purism selbst innerhalb der Linux-Gemeinschaft ein sehr kleiner Distributor mit einem sehr speziellen Angebot. Hoffnung macht da vor allem, dass man bei den Bestandteilen, die Interaktion voraussetzen (Mail, Sozial, Chat) auf offene Protokolle setzt, die Insellösungen verhindern.

Es lohnt sich das weiter im Blick zu behalten!

Bilder:
Einleitungs- und Beitragsbild von bsdrouin via pixabay

Der Anbieter Purism, bekannt durch seine Endgeräte für eine besonders Sicherheits-affine Zielgruppe und das ambitionierte Projekt Librem 5, hat nun den Start eines Dienste-Portfolios namens Librem One bekannt gegeben. Eine Crownfunding-Kampagne soll die Basis für ein ambitioniertes Dienste-Angebot legen.

Librem One besteht momentan aus 4 Bestandteilen:

1. Librem Chat: Ein Matrix-basierter Messenger, der VoIP und Videochats untersützt und Ende-zu-Ende Verschlüsselt ist.
2. Librem Mail: Eine E-Mail Angebot mit Ende-zu-Ende-verschlüsselung.
3. Librem Tunnel: Ein VPN Dienst mit Privacy-Fokus
4. Librem Social: Eine Mastodon Instanz

Hinzu kommen planmäßig ein Cloud-Service, sowie ein Speicherort für Backups. Mit Librem Pay und Librem Dial sind weiterhin zwei Produkte angekündigt, deren genaue Ausgestaltung interessant werden dürfte.

Das Komplettangebot kostet 7,99$ im Monat. Der Preis ist gemessen an der Konkurrenz gerechtfertigt, da bei den meisten anderen Anbietern bereits ein VPN-Angebot in ähnlicher Höhe veranschlagt ist.

Purism scheint mit diesem Dienste-Portfolio den Start von Librem 5 vorbereiten zu wollen. Das Smartphone basiert nach vorliegenden Informationen auf einer herkömmlichen Linux-Basis mit GNOME-, Plasma oder Unity-Oberfläche. GNOME wird dabei wohl der Standard sein. Da alle bekannten Lösungen ausschließlich für Android und iOS vorliegen, sah man sich scheinbar genötigt ein eigenes Angebot zu entwickeln um den Kunde wenigstens etwas bieten zu können.

Nichts desto weniger ist dieses Angebot zu begrüßen. Probleme beim Start muss man verzeihen. Im Januar hatte ich hier noch beklagt, dass kein Distributor versucht die vorhandenen Dienste zu einem Paket zusammen zu schnüren und seinen Anwendern durch eine niedrige Einstiegshürde schmackhaft zu machen (siehe auch: Warum Linux in einer vernetzten Welt einfach keinen Komfort bietet!). Purism macht nun genau das.

Leider ist Purism selbst innerhalb der Linux-Gemeinschaft ein sehr kleiner Distributor mit einem sehr speziellen Angebot. Hoffnung macht da vor allem, dass man bei den Bestandteilen, die Interaktion voraussetzen (Mail, Sozial, Chat) auf offene Protokolle setzt, die Insellösungen verhindern.

Es lohnt sich das weiter im Blick zu behalten!

Bilder:
Einleitungs- und Beitragsbild von bsdrouin via pixabay

Die volatile Entwicklung im Open Source Bereich führt immer wieder zu Umbenennungen. Sei es durch einen Fork, der ein neuen Namen notwendig macht oder weil den Entwicklern der alte Name nicht mehr gefallen hat. Sie alle unterschätzen dabei welche Bedeutung eine etablierte Marke für breite Anwenderschichten hat und wie hartnäckig sich alte Produkte halten können.

Kürzlich fand ich mich vor einem Rechner wieder, der für ein neues Warenwirtschaftssystem mit neu mit Windows 10 eingerichtet worden war und mich strahlte der Startscreen von Apache OpenOffice an. Eine lange nicht gesehenes Bild, da OpenOffice bei einigermaßen versierten Anwender und allen Linux-Distributionen bereits seit langem LibreOffice gewichen ist. Nun ist Apache OpenOffice noch nicht vollständig tot, immerhin bringt man circa einmal jährlich ein kleines Release heraus, aber die Sicherheit lässt zunehmend zu wünschen übrig.

Wie kann es also sein, dass ein schlechter gepflegtes Programm, hinter der neueren, besseren und ebenfalls kostenlosen Konkurrenz nicht vollständig verschwindet? Gewohnheit und der Name sind die zwei Antworten. OpenOffice ist eine über viele Jahre etablierte Alternative zu MS Office und wird von vielen Anwender synonym für eine kostenlose Office-Suite verwendet.

Ein guter Indikator hierfür ist Google Trends. Man muss Google nicht mögen, aber kein Konzern weiß so zuverlässig wofür sich die Menschen interessieren. Vergleicht man die Schlagwörter OpenOffice und LibreOffice miteinander, sieht man z. B. im 5-Jährigen Verlauf zwar eine sinkende Bedeutung von OpenOffice, aber LibreOffice kann den Suchbegriff OpenOffice nicht marginalisieren. Interessanterweise verlieren sogar beide Schlagworte an Aufmerksamkeit, selbst wenn man sie zusammen rechnet, aber das kann auch der Erhebung durch Google geschuldet sein. Ein ähnliches Bild ergibt sich beim Vergleich von TrueCrypt und VeraCrypt.

Gibt ein Anwender OpenOffice bei Google ein landet er nur bei Seiten, die diesen Suchbegriff widerspiegeln. In meinem Test hat es LibreOffice nicht mal geschafft auf die erste Seite der Suchergebnisse zu kommen. Der Anwender wird daher mit hoher Wahrscheinlich Apache OpenOffice installieren und nie etwas von LibreOffice erfahren. Im besten Fall ist er zufrieden, im schlechtesten ärgert er sich über die mangelnden Fortschritte bei OpenOffice, die schlechter werdende Kompatibilität zu Microsoft Office und kehrt Open Source vollständig den Rücken.

Nicht jede Umbenennung ist unumgänglich. Hat man kein Recht am Markennamen wie im Fall OpenOffice bleibt einem Fork-Projekt keine andere Möglichkeit, als eine Umbennenung vorzunehmen. Man sollte jedoch nicht unterschätzen wie hartnäckig sich etablierte Namen halten können - mit weitreichenden Folgen für die Sicherheit (siehe: TrueCrypt sollte ersetzt werden!). Mutmaßlich grundlose Umbenennungen sind daher keine gute Idee.

Bilder:
Einleitungs- und Beitragsbild von 3dman_eu via pixabay 

Die volatile Entwicklung im Open Source Bereich führt immer wieder zu Umbenennungen. Sei es durch einen Fork, der ein neuen Namen notwendig macht oder weil den Entwicklern der alte Name nicht mehr gefallen hat. Sie alle unterschätzen dabei welche Bedeutung eine etablierte Marke für breite Anwenderschichten hat und wie hartnäckig sich alte Produkte halten können.

Kürzlich fand ich mich vor einem Rechner wieder, der für ein neues Warenwirtschaftssystem mit neu mit Windows 10 eingerichtet worden war und mich strahlte der Startscreen von Apache OpenOffice an. Eine lange nicht gesehenes Bild, da OpenOffice bei einigermaßen versierten Anwender und allen Linux-Distributionen bereits seit langem LibreOffice gewichen ist. Nun ist Apache OpenOffice noch nicht vollständig tot, immerhin bringt man circa einmal jährlich ein kleines Release heraus, aber die Sicherheit lässt zunehmend zu wünschen übrig.

Wie kann es also sein, dass ein schlechter gepflegtes Programm, hinter der neueren, besseren und ebenfalls kostenlosen Konkurrenz nicht vollständig verschwindet? Gewohnheit und der Name sind die zwei Antworten. OpenOffice ist eine über viele Jahre etablierte Alternative zu MS Office und wird von vielen Anwender synonym für eine kostenlose Office-Suite verwendet.

Ein guter Indikator hierfür ist Google Trends. Man muss Google nicht mögen, aber kein Konzern weiß so zuverlässig wofür sich die Menschen interessieren. Vergleicht man die Schlagwörter OpenOffice und LibreOffice miteinander, sieht man z. B. im 5-Jährigen Verlauf zwar eine sinkende Bedeutung von OpenOffice, aber LibreOffice kann den Suchbegriff OpenOffice nicht marginalisieren. Interessanterweise verlieren sogar beide Schlagworte an Aufmerksamkeit, selbst wenn man sie zusammen rechnet, aber das kann auch der Erhebung durch Google geschuldet sein. Ein ähnliches Bild ergibt sich beim Vergleich von TrueCrypt und VeraCrypt.

Gibt ein Anwender OpenOffice bei Google ein landet er nur bei Seiten, die diesen Suchbegriff widerspiegeln. In meinem Test hat es LibreOffice nicht mal geschafft auf die erste Seite der Suchergebnisse zu kommen. Der Anwender wird daher mit hoher Wahrscheinlich Apache OpenOffice installieren und nie etwas von LibreOffice erfahren. Im besten Fall ist er zufrieden, im schlechtesten ärgert er sich über die mangelnden Fortschritte bei OpenOffice, die schlechter werdende Kompatibilität zu Microsoft Office und kehrt Open Source vollständig den Rücken.

Nicht jede Umbenennung ist unumgänglich. Hat man kein Recht am Markennamen wie im Fall OpenOffice bleibt einem Fork-Projekt keine andere Möglichkeit, als eine Umbennenung vorzunehmen. Man sollte jedoch nicht unterschätzen wie hartnäckig sich etablierte Namen halten können - mit weitreichenden Folgen für die Sicherheit (siehe: TrueCrypt sollte ersetzt werden!). Mutmaßlich grundlose Umbenennungen sind daher keine gute Idee.

Bilder:
Einleitungs- und Beitragsbild von 3dman_eu via pixabay 

Im Internet kursieren zahllose Hinweise und Tutorials wie man seinen Browser absichert. Geheime Einstellungen, Addons wie NoScript und Adblocker. Die Liste kann man beliebig fortsetzen. Beim Schutz vor Tracking sind sie aber kontraproduktiv, weil sie den individuellen Fingerabdruck des Anwenders schärfen.

Die Werbe- und Datensammlungswirtschaft erfindet permanent neue Wege um dem Anwender durch das Netz (und auch außerhalb) zu folgen. Ist eine Möglichkeit hinreichend bekannt und beginnen genug Nutzer sich dagegen zu wehren - wie beispielsweise in der Vergangenheit bei Cookies - ersinnt "Big Data" neue Mittel und Wege.

Der einzige langfristig wirksame Schutz besteht daher im Untertauchen in der Masse. Genau das ist - neben der Umleitung des Traffics durch da Zwiebelnetz - die Methode von Tor. Das Tor Browser Bundle simuliert ein Allerweltssystem zu sein: Windows 7, Firefox, 1280x1024 Auflösung. Einen Werbeblocker gibt es gar nicht und NoScript ist standardmäßig auf eine sehr schwache Stufe eingestellt. Hinzu kommen natürlich Härtungsmaßnahmen an der Firefox-Basis. Der einzelne Tor-Anwender geht dadurch in der Masse der Tor-Nutzer unter und bei vielen Merkmalen sogar in der Masse der Internetnutzer. Die einzelne Tor-Session versucht gar nicht tracking zu verhindern, sondern lässt diese ins leere laufen, da sie so beliebig ist.

Wenn man also einen Browser mit allerlei Addons anreichert, betätigt man sich also zuerst einmal als Dienstleister für die Trackingindustrie. Ein abgeschaltete JavaScript ist eben beispielsweise nicht sonderlich häufig und steigert den Wiedererkennungswert. Gleiches gilt für einen Werbeblocker und die Do-Not-Track-Einstellung. Abgeschaltetes JavaScript minimiert zwar die technischen Möglichkeiten der Tracking-Wirtschaft, verhindert sie aber nicht vollständig und reichert sie zugleich um einen weiteren Faktor an.

Manche Addons sind natürlich unumgänglich, trotzdem sollte man immer mal wieder den Sinn hinterfragen. Surfen ohne Werbeblocker ist auf vielen Seiten eine Zumutung und je nach Hardware auch eine Herausforderung für den Rechner. Hier ist auch berücksichtigen, ob nicht der Verzicht auf einen Werbeblocker inzwischen schon besonders ist und den eigenen Fingerabdruck schärft. Anders sieht das beispielsweise bei NoScript aus. Die Befürworter wollen sich vor Schadsoftware schützen (die es unter Linux und macOS ja bekanntermaßen sehr reichhaltig gibt...) und Trackingmethoden vorbeugen. Gleichzeitig erzeugen sie einen sehr individuelles Identifikationsmerkmal.

Nicht jede Sicherheitsmaßnahme verbessert also nur und ausschließlich die Sicherheit.

Bilder:

Einleitungs- und Beitragsbild von pixelcreatures via pixabay

Vorwarnung: Dieser Artikel wird euch vermutlich nicht interessieren, wenn ihr nicht zufällig die gleichen Anforderungen an eine Linux-Distribution für den Desktop stellt wie ich. Mir selbst dient dieser Beitrag als Sammlung von Informationen und zum Vergleich von Distributionen, um schlussendlich eine neue Distribution für meinen Desktop-PC und meine beiden Notebooks auszuwählen. Falls euch langweilig ist oder ihr neugierig seid, dürft ihr natürlich gerne weiter lesen. ;-)

Umfeld

Auf meinen privaten Geräten läuft seit 2006 Ubuntu. Die Geräte haben dabei selten eine Neuinstallation erlebt, sondern wurden meist per Distribution-Upgrade auf eine neue Release aktualisiert. Leider klappt letzteres in jüngerer Vergangenheit zunehmend schlechter und unzuverlässiger. Eine Neuinstallation ist inzwischen einem Upgrade vorzuziehen, da sie meist schneller durchgeführt ist und weniger Nacharbeiten nach sich zieht.

Neben den zunehmenden Problemen mit dem Distribution-Upgrade hat mir Canonical in der jüngeren Vergangenheit ein wenig zu viel an meiner Lieblingsdistribution herumgepfuscht bzw. sie ver(schlimm)bessert. Dies ist der Auslöser, mir mal eine Alternative für den Desktop-Einsatz zu suchen.

Bei meinen Geräten handelt es sich um einen älteren Desktop-PC und zwei ThinkPads (T410 und X201). Dazu gesellt sich in der Peripherie noch ein Brother DCP-540CN, ein Synology DS213air. Alle Komponenten sind in das WLAN-Heimnetzwerk eingebunden. Die Hardware ist alt, doch funktioniert sie noch tadellos und erfüllt ihren Zweck. Daher möchte ich sie gerne noch einige Jahre weiter nutzen.

Anforderungen

Beruflich bin ich im BITS, dem Hochschulrechenzentrum der Uni Bielefeld, tätig und betreue dort diverse IT-Dienste und Themen. Da ich also bereits einen sehr großen Teil des Tages mit der Wartung, Pflege, Entstörung und (sofern noch Zeit ist) der Weiterentwicklung dieser Dienste verbringe, möchte ich mich daheim so wenig wie möglich mit diesen Tätigkeiten aufhalten. Die regelmäßige Installation von Sicherheits-Aktualisierungen ist obligatorisch, doch auf lange Fehlersuche und Behebung möchte ich daheim gerne verzichten.

Bei mir gilt Stabilität vor Bleeding Edge. Ich benötige nicht ständig neue Funktionen und die aktuellste Upstream-Version. Wenn eine Anwendung meine Anforderungen erfüllt und mit Sicherheits-Aktualisierungen versorgt wird, reicht mir das völlig aus.

Aktuell bieten mir die unter Ubuntu 16.04 LTS verfügbaren Anwendungen die Funktionalität, die ich benötige. Die auszuwählende Distribution sollte die entsprechenden Versionen in gleicher oder aktuellerer Version bereitstellen können. Sollte nur eine ältere Version einer Anwendung verfügbar sein, ist dies nicht automatisch ein Ausschlusskriterium. In diesem Fall ist die Anwendung zu testen, ob sie meinen Anforderungen genügt.

Ich wünsche mir einen möglichst großen Unterstützungszeitraum. Ubuntu bietet in den Versionen mit Long Term Support eine Unterstützung für 5 Jahre an. Damit bin ich bisher ganz gut gefahren und möchte mich deshalb in diesem Punkt nur ungern verschlechtern.

Bewertungskriterien

Wie ihr oben gelesen habt, habe ich keine knallharten und messbaren Anforderungen definiert, sondern lediglich Punkte genannt, die mir wichtig sind. In den folgenden Abschnitten werde ich mir eine Auswahl von Linux-Distributionen etwas näher ansehen und diese zuerst auf dem Papier und anhand meiner Erfahrungen miteinander vergleichen. Dabei bewerte ich folgende Kriterien:

• Release-Zyklus
• Support-/Life-Cycle
• Paketverfügbarkeit und Versionsstand
• Community

Für vorstehend genannte Kriterien vergebe ich Punkte nach folgender Tabelle. Dabei gehen alle Kriterien mit gleicher Gewichtung in das Endergebnis ein, sodass die Distribution mit den meisten Punkten am besten zu mir passen sollte.

Als Referenz dient mir Xenial, für welches meine Bewertungstabelle wie folgt aussieht:

Anmerkung: Bitte beachtet, dass dies hier eine sehr vereinfachte Form einer Bewertungstabelle für meinen privaten Zeitvertreib ist. Als Entscheidungstabelle für die Arbeit ist dieses Format ganz sicher nicht geeignet.

Ausgewählte Distributionen im Vergleich

Für den hier stattfindenden Vergleich habe ich mir folgende Distributionen angesehen (alphabetisch sortiert). Warum genau diese? Nun, entweder kenne ich sie schon oder sie wurden mir von Arbeitskollegen empfohlen.

• Antergos
• Arch Linux
• CentOS
• Debian
• Fedora
• Ubuntu

Antergos

Antergos basiert auf Arch Linux und folgt dem Rolling-Release-Prinzip. Ich möchte kein Rolling Release nutzen. Daher hört die Bewertung hier schon auf, da Antergos für mich nicht in Frage kommt.

Arch Linux

Arch Linux folgt ebenfalls dem Rolling-Release-Prinzip und scheidet daher ebenfalls von vornherein aus.

CentOS 7

CentOS wird aus den Quellen von Red Hat Enterprise Linux gebaut, zu welchem es binärkompatibel ist. CentOS ist nach eigenen Angaben ein Enterprise-Betriebssystem, welches mit langen Wartungszyklen aufwartet. So kann ein Release bis zu zehn Jahre genutzt werden, ohne dass Softwareversionen migriert werden müssen.

Zehn Jahre lang Ruhe. Das klingt verlockend. Grund genug, sich das aktuelle CentOS 7 auf dem Papier anzuschauen.

Debian

Debian ist ein von der Gemeinschaft entwickeltes freies Betriebssystem und mein heimlicher Favorit. Mir gefällt die Idee, mich neben einer RPM-basierten Distribution auf der Arbeit,Ubuntu importiert den Großteil seiner Pakete aus Debian Unstable. Für einen Teil dieser Pakete übernimmt nach dem Debian Import Freeze die Firma Canonical die Pflege. Der größte Teil landet hingegen in der Komponente universe, wo er von den MOTU betreut wird (oder gar nicht). Die Folge dieses Vorgehens: Wenn Pakete in Debian Unstable während des Debian Import Freeze kaputt und unbenutzbar sind, werden sie in die Ubuntu-Paketquellen importiert und bleiben mit großer Wahrscheinlichkeit für die Lebensdauer des jeweiligen Releases daheim mit einer DEB-basierten Distribution zu beschäftigen, um in beiden Paketformatwelten auf dem Laufenden zu bleiben.

Debian Stable steht in dem Ruf rock solid zu sein, was meinem Wunsch nach einer sehr stabilen Distribution entgegen kommt. Die Softwarepakete in Debian Stable gelten gemeinhin als sehr gut abgehangen. Kritiker bezeichnen sie auch als hoffnungslos veraltet. So lange sie die von mir gewünschte Funktionalität bieten, ist mir das Alter egal. Falls ich mich für Debian entscheide, werde ich auf die Veröffentlichung von Buster warten, welche mit folgenden Werten aufwartet.

Fedora

Bei Fedora handelt es sich wiederum um eine RPM-basierte Distribution. Diese wartet mit recht aktuellen Softwarepaketen auf und gibt sich selbst als für Desktops, Workstations, Laptops und Server geeignet. Fedora wird auch gern als Testlabor für RHEL bezeichnet, da viele Entwicklungen, die sich hier etablieren konnten, später in RHEL übernommen werden.

Die Aktualität hat ihren Preis. So kommt Fedora mit recht kurzen Releasezyklen daher, was für mich ganz klar Punktabzug bedeutet.

Ubuntu LTS

Basierend auf Debian laufen die Ubuntu LTS Releases seit Jahren auf meinen Rechnern. Da ich mit dieser Distribution die meiste Erfahrung habe und dadurch auch einige ihrer Macken kenne, fällt es mir schwer, bei einer Bewertung neutral zu bleiben. Doch werde ich mir Mühe geben.

Ubuntu importiert den Großteil seiner Pakete aus Debian Unstable. Für einen Teil dieser Pakete übernimmt nach dem Debian Import Freeze die Firma Canonical die Pflege. Der größte Teil landet hingegen in der Komponente universe, wo er von den MOTU betreut wird (oder gar nicht). Die Folge dieses Vorgehens: Wenn Pakete in Debian Unstable während des Debian Import Freeze kaputt und unbenutzbar sind, werden sie in die Ubuntu-Paketquellen importiert und bleiben mit großer Wahrscheinlichkeit für die Lebensdauer des jeweiligen Release kaputt und unbenutzbar. Dieses Vorgehen halte ich persönlich für ganz großen Schwachsinn.

Als einzigartig hingegen empfinde ich die deutschsprachige Community ubuntuusers.de. Auch wenn hier in einigen Themen auch mal die Fetzen fliegen, ist der Umgangston doch überwiegend freundlich. Hier fand ich in der Vergangenheit stets wertvolle Hilfe bei kleinen und auch großen Problemen

Schlussfolgerung und selbstkritische Reflexion des Distributions-Vergleichs

Sieg nach Punkten für das hoffentlich bald erscheinende Debian Buster!

Dass mein heimlicher Favorit das Rennen gemacht hat, verwundert nicht. Nüchtern und bei Licht betrachtet muss ich gestehen, dass der oben stehende Vergleich Makulatur und nicht objektiv ist. So ist der Vergleich und die Bewertung von Software-/Paket-Versionen nicht geeignet, um zu bestimmen, wie gut meine funktionalen Anforderungen erfüllt werden. Dazu hätte es eines praktischen Tests der einzelnen Versionen bedurft.

So offenbarte ein praktischer Vergleich von kile in Version 2.9.91, dass mir dieses in der Benutzung deutlich schlechter gefällt, als die ältere Version 2.1.3. Und was für kile gilt, mag selbstverständlich auch für andere Anwendungen gelten.

Ein weiterer großer Schwachpunkt des Vergleichs ist der Punkt ‚Community‘. Aus persönlicher Erfahrung kenne ich nur die ubuntuusers.de wirklich gut, weil ich nur hier seit vielen Jahren selbst aktiv bin. Die Bewertung aller anderen Communities und Unterstützungsmöglichkeiten basiert auf deutlich weniger Erfahrungen und Teils sogar nur auf Hörensagen. Eine objektive Bewertung ist so natürlich nicht möglich.

Streng genommen handelt es sich bei dem angestellten Vergleich um Humbug und Mumpitz. Bitte nicht nachmachen!

Mir selbst reicht er jedoch als Indikator, dass das kommende Debian Buster meine Anforderungen daheim gut erfüllen könnte. Es wird daher nach der Veröffentlichung auf einem meiner Geräte installiert und in der Praxis erprobt.

Tja, wenn ich ehrlich bin, ist dieser Artikel wenig hilfreich. Zum Trost sei gesagt, dass er mir half, ein wenig die Zeit bis zum Release von Buster zu überbrücken.

Das Init-System systemd ist mittlerweile in vielen Linux-Distributionen angekommen. Auch unter Ubuntu ist es seit Version 15.04 integriert. Ein Vorteil des neuen Systems ist, das Services, im Gegensatz zum alten Init-System, relativ unkompliziert erstellt werden können. Dazu muss eine sogenannte Unit erstellt werden. Bei einer Unit handelt es sich um eine Textdatei mit einer entsprechenden Konfiguration. Neben den Units für die Konfiguration eines Services existieren weitere Unit-Typen wie z.B. die Typen mit der Endung .path oder .network. In diesem Artikel soll es allerdings nur um die Units vom Typ Service gehen.

Die Units liegen in unterschiedlichen Orten im Dateisystem. Die vom System vorinstallierten Units sind im Ordner /lib/systemd/system/ zu finden. Eigene Services werden im Ordner /etc/systemd/system/ hinterlegt. Hier können allerdings nur Nutzer mit administrativen Rechten entsprechende Service hinterlegen. Soll ein nicht privilegierter Nutzer eine Unit angelegen, so muss er diese im Verzeichnis ~/.config/systemd/user/ hinterlegen. In den meisten Fällen werden Units für Services im Dateisystem unter dem Pfad /etc/systemd/system/ angelegt. In diesem Ordner soll nun eine Datei für die Unit angelegt werden:

nano languagetool.service

Beispielhaft könnte eine solche Unit wie folgt aussehen:

[Unit]
Description=LanguageTool
After=syslog.target
After=network.target

[Service]
Type=simple
User=languagetool
Group=languagetool
WorkingDirectory=/home/languagetool/server
ExecStart=/usr/bin/java -cp /home/languagetool/server/languagetool-server.jar org.languagetool.server.HTTPServer --config languagetool.cfg --port 3001 --allow-origin "*"
Restart=always
Environment=USER=git HOME=/home/languagetool

[Install]
WantedBy=multi-user.target

Die Unit unterteilt sich in unterschiedliche Bereiche, in diesem Beispiel sind dies Unit, Service und Install. Der Bereich Service ist hierbei nur in Units vom Typ Service zu finden. Im Bereich Unit sind eine kurze Beschreibung des Services und die Abhängigkeiten der Unit hinterlegt. Dabei wird definiert, welche Systeme bereits gestartet sein müssen, bevor der Service gestartet wird. Ein Target entspricht dabei einer Gruppe von Diensten, meist mit einer bestimmten Bedeutung, wie z.B. das Target für die Herstellung der Netzwerkkonnektivität (network-online.target).

In der Service-Gruppe wird der Typ des Services und der Nutzer und die Gruppe definiert, mit welchem bzw. welcher er starten soll. Daneben wird das Arbeitsverzeichnis und die Kommandozeile zur Ausführung des Services definiert. Weiterhin kann das Verhalten des Service, über den Parameter Restart, weiter definiert werden. So kann angegeben werden, dass der Service nach seiner Beendigung wieder neugestartet wird.

In der Install-Sektion wird angeben, wann der Service gestartet werden soll. Das multi-user.target entspricht dem klassischen Start eines normalen Linux-Systems. Ist die Unit definiert, kann sie aktiviert und der Service gestartet werden:

systemctl enable languagetool
systemctl start languagetool

Die Option enable sorgt dafür das die entsprechende Unit aktiviert wird. Dies führt dazu das sie je nach Konfiguration z.B. automatisch beim Systemstart oder bei dem Anschluss bestimmter Hardware gestartet wird. Unter bestimmten Systemen wie Ubuntu, kann der Service auch über das service-Kommando gestartet werden:

service languagetool start

Neben den Optionen enable und start für systemctl, existieren weitere Optionen zur Steuerung der Units. Dies sind unter anderem stop, zum Stoppen des Services und disable zur Deaktivierung der Unit. Mit der Option status, kann der Status eines Service erfragt werden:

systemctl status languagetool

Anschließend erhält der Nutzer den aktuellen Status des Service. Eine weitere wichtige Option ist restart um einen Service manuell neuzustarten. Mithilfe der systemd-Units lassen sich somit schnell Services in ein Linux-System einbinden.

Nach dem Einlesen einer Eingabe vom stdin / Terminal muss man oft mit dem Zeilenvorschub / newline (\n) im eingelesenen String umgehen. Um diesen zu entfernen, kann man unter Rust einfach auf die .pop()-Funktion zurückgreifen, die das letzte Zeichen eines Strings löscht:

use std::io::{Write, stdin, stdout};

fn main() {
    // Intro
    println!("-- INPUT Demo --");
    print!("Please enter something: ");
    stdout().flush().unwrap();

    // Input
    let mut inputvar: String = String::new();                                  
    stdin().read_line(&mut inputvar).expect("Error while data input");         
    inputvar.pop(); // remove trailing newline

    // Output
    println!("Eingabe: {}", inputvar);
}

Mittlerweile habe ich sogar eine bessere plattformunabhängigere Lösung gefunden, die mit den unterschiedlichen Typen von Zeilenvorschüben wie \r (Mac pre Version 10) und \r\n (Windows) umgehen kann:

fn trim_newline(s: &mut String) {
    if s.ends_with('\n') || s.ends_with('\r') {
        s.pop();
        if s.ends_with('\r') {
            s.pop();
        }
    }
}

# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    600    0        0 wlp2s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp2s0
192.168.178.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0

Ich hatte häufig Probleme mich bei captive portals von öffentlichen WLANs, z.B. in Flughäfen, einzuloggen da ich per /etc/resolv.conf einen eigenen DNS-Server, in meinem Fall dnscrypt, einsetze. Durch das Nutzen eines fest vorgegebenen DNS-Servers, statt der automatischen Nutzung des DNS des WLANs, kommt man nicht auf die Vorschaltseite auf der man sich für das WiFi freischalten kann.
Mit folgendem Vorgehen konnte ich aber bei meinen letzten Versuchen in öffentlichen WiFis immer die Vorschaltseite öffnen:

# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    600    0        0 wlp2s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp2s0
192.168.178.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0

In der Zeile startend mit 0.0.0.0 findet man in der zweiten Spalte die IP des Netzwerkrouters, gibt man diese mit vorangestelltem http:// in den Browser ein sollte man das captive portal zu sehen bekommen. Bei mir hat das bisher zuverlässig funktioniert. Ich würde mich über Feedback freuen ob das bei anderen auch funktioniert, da ich nicht so häufig in fremden Netzwerken unterwegs bin.

Update 2019-05-19

Mir ist aufgefallen, dass es besser funktioniert wenn man die IP als DNS-Server in die /etc/resolv.conf einträgt (zumindest temporär) und danach im Browser z.B. google.de aufruft. Dann wird man automatisch zum captive portal weitergeleitet.

Wie schon in den vergangenen zwei Jahren hat Mozilla auch dieses Jahr seinen „Statusbericht zur Internetgesundheit“ veröffentlicht. In diesem setzt sich Mozilla mit den positiven sowie negativen Entwicklungen des Webs auseinander.

Nach den Berichten für 2017 und 2018 hat Mozilla nun seinen Statusbericht zur Internetgesundheit für das Jahr 2019 fertiggestellt. Kernthemen dabei sind Datenschutz und Sicherheit, Dezentralisierung, Offenheit, Digitale Teilhabe sowie Digitale Bildung.

Statusbericht zur Internetgesundheit 2019

Mozillas Jahresbericht zur Internetgesundheit sieht voreingenommene künstliche Intelligenz, Missbrauch biometrischer Daten und erhöhte staatliche Zensur als kritische Faktoren.

Mehr Informationen gibt es in der offiziellen Presseankündigung zum Thema.

Der Beitrag Mozilla veröffentlicht Statusbericht zur Internetgesundheit 2019 erschien zuerst auf soeren-hentzschel.at.

Kaufberatungen im Linux-Bereich enden oft bei ThinkPads. Bisher habe ich mich dagegen immer gesträubt, da ich die klobigen Boliden von Lenovo optisch einfach nicht ansprechend fand. Nun habe ich aber doch im Refurbished-Bereich zugegriffen und muss gestehen: ThinkPad und Linux sind einfach eine gut harmonierende Kombination.

Die Anforderungen waren ziemlich schwierig. Es sollte ein möglich preiswertes Notebook bis maximal 400 € sein. In der Preisklasse gibt es im Consumer-Bereich nur richtig schlechte Hardware, die unter hübschen Marketingnamen verkauft wird. Interessant sind daher die gebrauchten Notebook-Angebote von Businessherstellern, die man bei einigen Anbietern erwerben kann. Die Geräte sind getestet, gesäubert und aufbereitet und kommen mit einer Gewährleistung von meist einem Jahr (Fachjargon "Refurbished"). Dafür bekommt man dann ein solides Businessmodell, das meist 1-2 Jahre irgendwo im Einsatz zwar. Der Neupreis für aktuelle Modelle der Serien liegt meist jenseits der tausend Euro. Angeboten werden in diesem Zusammenhang meist Lenovo, HP und Dell-Notebooks. Das Alter variiert und hängt vom angestrebten Preis ab.

Im konkreten Fall fiel die Wahl nun auf ein Lenovo Thinkpad T440. Die technischen Rahmendaten können sich für das Alter (Markteinführung der Serie 2014) noch sehen lassen:

• Intel Core i5 "Haswell"
• 8 GB RAM
• 180 GB SSD
• 14" Display mit einer Auflösung von 1600 x 900 Pixel

Letzteres ist eine schöne Zwischengröße. Man hat relativ viel Platz, muss aber - normale Sehkraft vorausgesetzt - nicht skalieren und erspart sich daher die HiDPI-Verrenkungen. Letztere funktionieren bei Linux desktop- und programmübergreifend noch nicht perfekt.

Das Notebook selbst kam in einem optisch sehr guten Zustand. Lediglich am Touchpad sah man leichte Abriebspuren. Die Tastatur wurde im Vorfeld augenscheinlich neu lackiert oder ersetzt und sah optisch neuwertig aus. Die beiden Akkus haben jeweils noch mehr als 90% Kapazität.

Vorinstalliert war Windows 10 Pro, das auf Anforderung des Anwenders sofort durch Linux ersetzt wurde. Das vorinstallierte Windows war aber ganz praktisch, weil man mit den Lenovo Tools noch schnell die Firmware (BIOS/UEFI und SSD) auf den aktuellen Stand bringen konnte. Die Wahl der Distribution fiel anschließend auf Kubuntu 18.04 (siehe: Kubuntu 18.04 LTS - Ein Ausblick). Es sollte wieder eine LTS-Distribution mit KDE Plasma werden, das Datum der Neuanschaffung harmonierte überhaupt nicht mit der Roadmap von openSUSE (siehe: openSUSE Leap 15.1 - Ein Ausblick) und Debian ist ebenfalls noch im Freeze und auch nicht mein persönlicher Favorit (siehe: Debian - Eine Kritik).

Die Installation von Kubuntu verlief absolut reibungslos. Die neue minimale Installation ist dabei sehr hilfreich, weil man anschließend die benötigten Programme nachinstallieren kann. Gröbere Fehler und Unstimmigkeiten sind mir innerhalb der letzten Tage auch nicht aufgefallen, aber das System dient auch nur zum bewährten Office-Einsatz, plus ein bisschen Medienkonsum. Also nichts was Linux im Jahr 2019 noch vor Herausforderungen stellt.

Allerdings muss man konstatieren, dass ThinkPads hervorragend unterstützt werden. Akkulaufzeit, Tastaturbeleuchtung, gedimmter Bildschirm, Treiber für die Funkmodule - alles funktioniert direkt nach der Installation. Es waren überhaupt keine Nacharbeiten notwendig!

Da versteht man, weshalb so viele Linux-Fans auf ThinkPads schwören. Hübsch finde ich sie trotzdem nicht.

Bilder:
Einleitungs- und Beitragsbild von 3844328 via pixabay

Eine interessante Frage zum Thema “Alltagstauglichkeit von Ubuntu” ist ob man mit Amazon Prime auch Filme gucken kann. Bei Ubuntu 16.04 hatte ich mit dem mitgelieferten Firefox da meine Probleme, aber der Chrome Browser den ich nachinstalliert habe konnte diese tadellos wiedergeben.

Nach dem Einstecken von HDMI konnte ich das Bild auf den Fernseher umleiten.
Anfänglich hatte ich noch Probleme mit der Ton-Ausgabe. Hier musste ich dann manuell
im Terminal einmal folgenden Befehl eingeben:

pulseaudio -k

Dazu waren keine root Rechte notwendig. Nun wurde auch der Ton mittels HDMI korrekt wiedergegeben.

Selbst ein einfaches, mehrere Jahre alte Notebook mit AMD E1 CPU ist in der Lage den Film problemlos anzuzeigen.

Für die freie Grammatik- und Rechtschreibprüfung LanguageTool existieren eine Reihe von Add-ons, unter anderem für den Browser Firefox.

Grammatik- und Rechtschreibprüfung - LanguageTool (Kostenlos, Firefox Add-ons) →

Standardmäßig nutzen diese Add-ons den vom Projekt bereitgestellten Server unter languagetool.org. Nicht jeder möchte seine Daten zur Korrektur an Dritte schicken und so besteht die Möglichkeit einen eigenen Server aufzusetzen. Dieser kann lokal betrieben oder auf einem eigenen Server installiert werden. In diesem Artikel soll die Installation unter Ubuntu beschrieben werden. Im ersten Schritt muss sich auf dem Server eingeloggt und dort ein neuer Nutzer angelegt werden:

adduser languagetool
su languagetool
cd

Nachdem der Nutzer angelegt wurde und in das entsprechende Home-Verzeichnis des Nutzers gewechselt wurde, kann das LanguageTool heruntergeladen und entpackt werden:

wget https://languagetool.org/download/LanguageTool-4.5.zip
unzip LanguageTool-4.5.zip
mv LanguageTool-4.5 server
rm LanguageTool-4.5.zip

Neben dem LanguageTool, werden noch sogenannte N-Gramme heruntergeladen. Diese dienen der Verbesserung der Erkennungsleistung des LanguageTool. Sie belegen knapp 27 GiB auf der Festplatte, müssen aber nicht zwingend installiert werden:

mkdir ngrams

wget https://languagetool.org/download/ngram-data/ngrams-de-20150819.zip
wget https://languagetool.org/download/ngram-data/ngrams-en-20150817.zip
wget https://languagetool.org/download/ngram-data/ngrams-es-20150915.zip
wget https://languagetool.org/download/ngram-data/ngrams-fr-20150913.zip
wget https://languagetool.org/download/ngram-data/ngrams-nl-20181229.zip

unzip ngrams-de-20150819.zip
unzip ngrams-en-20150817.zip
unzip ngrams-es-20150915.zip
unzip ngrams-fr-20150913.zip
unzip ngrams-nl-20181229.zip

rm ngrams-de-20150819.zip
rm ngrams-en-20150817.zip
rm ngrams-es-20150915.zip
rm ngrams-fr-20150913.zip
rm ngrams-nl-20181229.zip

Damit ist das LanguageTool installiert. Ein erster Test kann erfolgen, indem der Server mittels:

java -cp languagetool-server.jar org.languagetool.server.HTTPServer --port 8081

gestartet wird. Über Curl können erste Testdaten an den Server gesendet werden:

curl --data "language=en-US&text=a first test" http://localhost:8081/v2/check

In meinem Setup wird der Server auf dem Port 8081 (oder einem beliebigen anderen Port betrieben) und ist über einen Reverse Proxy, in diesem Fall Nginx, erreichbar. Dazu muss die Konfiguration angepasst werden:

nano /etc/nginx/sites-available/example

In der Nginx-Konfigurationsdatei wird nun folgende Konfiguration hinterlegt:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/api.example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/api.example.org/privkey.pem;

        root /var/www/example/api;
        index index.php index.html index.htm;

        server_name api.example.org;

        # proxy for languagetool
        location /languagetool/ {
                proxy_pass http://localhost:8081/v2/;
        }
}

Nachdem die Konfiguration für Nginx hinterlegt wurde, wird Nginx neugestartet:

nginx restart

Über den Browser kann die API nun getestet werden:

https://api.example.org/languagetool/check?language=en-US&text=Wong wong wong

Damit ist die Konfiguration des LanguageTool allerdings noch nicht abgeschlossen. Für den produktiven Betrieb wird eine Konfigurationsdatei unter /home/languagetool/server/ erstellt:

nano languagetool.cfg

Diese Datei wird mit folgendem Inhalt befüllt:

languageModel=/home/languagetool/ngrams

Damit der Service automatisch startet, wird eine systemd-Unit angelegt:

nano /etc/systemd/system/languagetool.service

Diese Datei wird mit folgendem Inhalt befüllt:

[Unit]
Description=LanguageTool
After=syslog.target
After=network.target

[Service]
Type=simple
User=languagetool
Group=languagetool
WorkingDirectory=/home/languagetool/server
ExecStart=/usr/bin/java -cp /home/languagetool/server/languagetool-server.jar org.languagetool.server.HTTPServer --config languagetool.cfg --port 3001 --allow-origin "*"
Restart=always
Environment=USER=git HOME=/home/languagetool

[Install]
WantedBy=multi-user.target

Nachdem die Datei angelegt wurde, wird sie aktiviert und anschließend der Service gestartet:

systemctl enable languagetool
service languagetool start

Zum Test der N-Gramme kann folgende URL aufgerufen:

https://api.example.org/languagetool/check?language=en-US&text=I%20want%20to%20go%20their.

werden. Wenn keine N-Gramme installiert oder konfiguriert sind, kommt ein relativ kurzes JSON als Antwort zurück:

{“software”:{“name”:”LanguageTool”,”version”:”4.5″,”buildDate”:”2019-03-26 11:37″,”apiVersion”:1,”premium”:false,”premiumHint”:”You might be missing errors only the Premium version can find. Contact us at supportlanguagetoolplus.com.”,”status”:””},”warnings”:{“incompleteResults”:false},”language”:{“name”:”English (US)”,”code”:”en-US”,”detectedLanguage”:{“name”:”English (US)”,”code”:”en-US”,”confidence”:0.9999997}},”matches”:[]}

Sind die N-Gramme erfolgreich installiert und konfiguriert, wird das LanguageTool mit einem längeren Response antworten:

{“software”:{“name”:”LanguageTool”,”version”:”4.5″,”buildDate”:”2019-03-26 11:37″,”apiVersion”:1,”premium”:false,”premiumHint”:”You might be missing errors only the Premium version can find. Contact us at supportlanguagetoolplus.com.”,”status”:””},”warnings”:{“incompleteResults”:false},”language”:{“name”:”English (US)”,”code”:”en-US”,”detectedLanguage”:{“name”:”English (US)”,”code”:”en-US”,”confidence”:0.9999997}},”matches”:[{“message”:”Statistics suggests that ‘there’ (as in ‘Is there an answer?’) might be the correct word here, not ‘their’ (as in ‘It’s not their fault.’). Please check.”,”shortMessage”:””,”replacements”:[{“value”:”there”,”shortDescription”:”as in ‘Is there an answer?'”}],”offset”:13,”length”:5,”context”:{“text”:”I want to go their.”,”offset”:13,”length”:5},”sentence”:”I want to go their.”,”type”:{“typeName”:”Other”},”rule”:{“id”:”CONFUSION_RULE”,”description”:”Statistically detect wrong use of words that are easily confused”,”issueType”:”non-conformance”,”category”:{“id”:”TYPOS”,”name”:”Possible Typo”}},”ignoreForIncompleteSentence”:false,”contextForSureMatch”:3}]}

Damit ist der Server komplett eingerichtet. Nun kann der eigene Server bei entsprechenden Add-ons eingerichtet und genutzt werden.

Nachdem der Server aufgesetzt wurde, können entsprechende Add-ons umgestellt werden

Das gleiche Setup kann natürlich genutzt werden, einen solchen Server lokal auf dem eigenen Ubuntu-Rechner zu installieren.

Der aus dem Servo-Projekt stammende WebRender soll die Grafikkarte stärker als bisher einbeziehen und so für eine deutlich verbesserte Firefox-Performance sorgen. Bisher war WebRender in Vorabversionen von Firefox lediglich für Nutzer von Windows 10 standardmäßig aktiviert. Jetzt sind die ersten Linux-Nutzer an der Reihe.

WebRender stammt wie die mit Firefox 57 eingeführte CSS-Engine Stylo ebenfalls aus Mozillas 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 der Nightly-Version von Firefox ist WebRender bereits für einen Teil der Nutzer aktiviert. Die anfängliche Zielgruppe setzt sich aus Nutzern zusammen, welche Windows 10 als Betriebssystem sowie eine halbwegs moderne Grafikkarte von Nvidia einsetzen. Für eben jene Zielgruppe wird WebRender erstmals mit Firefox 67 offiziell in einer finalen Version von Firefox ausgeliefert werden.

Für Nutzer einer Nightly-Version von Firefox wurde die WebRender-Unterstützung bereits auf erste Grafikchips von AMD und Intel ausgeweitet. Nun kommen erstmals auch Nutzer des Betriebssystems Linux in den Genuss, allerdings noch mit Einschränkungen. Voraussetzung hierfür ist zunächst ein Grafikchip von Intel mit Mesa-Treiber Version 18.2.8.0 oder höher, außerdem darf kein 4K-Bildschirm verwendet werden. Mozilla hat sich für diese Konfiguration als Start für Linux entschieden, da dies eine gängige Konfiguration unter Mozilla-Entwicklern ist, welche dementsprechend schon gut getestet ist.

Der Beitrag Firefox Nightly: WebRender jetzt auch für erste Nutzer von Linux aktiviert erschien zuerst auf soeren-hentzschel.at.

Die Einrichtung und Pflege einer Nextcloud und eines gesamten LAMP-Stacks ist für viele Anwender eine abschreckende Herausforderung. Leichter ist dies mit einem fertigen Snap Paket, das direkt von der Nextcloud-Community bereit gestellt wird und eine komplette Nextcloud-Umgebung mitbringt.

Dieser Beitrag ist ein Exkurs der Serie Cloud in Eigenregie (siehe: Cloud in Eigenregie I: Vorbemerkungen). Dort wurde lediglich abstrakt auf die Installationsmöglichkeiten einer Cloud Bezug genommen. 

Die Snap-Variante von Nextcloud läuft auf jeder Distribution, die Snap-Pakete unterstützt. Als Zusatzmodule steht dies bereits für die meisten Distributionen bereit. Direkt in den Paketquellen hat dies neben Ubuntu auch Debian 10 "Buster". Die anderen unterstützten Distributionen dürften kaum Relevanz für Server besitzen.

Nextcloud installieren

Zuerst muss Snap für Debian erst einmal installiert werden.

# apt-get install snapd

Anschließend installiert man das Snap-Paket. Zuerst lädt die Routine dann noch die fehlende Core-Umgebung für Snap-Pakete um anschließend das Nextcloud Paket einzurichten.

# snap install nextcloud

Das Snap-Paket bringt neben der Nextcloud auch noch einen kompletten LAMP-Stack mit: Apache, MySQL PHP und Redis. Dies benötigt natürlich ein wenig Speicherplatz.

Exkurs: Ports

Wichtig ist, dass kein anderer Apache-Server auf die Standardports lauscht, da diese sich ansonsten in die Quere kommen. Das dürfte aber kaum ein Problem sein, denn wer bereits einen kompletten LAMP-Stack pflegt wird sich nicht zusätzlich noch das Snap-Paket einrichten und dadurch doppelten Ressourcenverbrauch riskieren. Wer dennoch bereits einen LAMP-Stack nutzt muss die Ports des Snap-Pakets ändern. Beispielsweise auf folgende Konfiguration:

# snap set nextcloud ports.http=81

# snap set nextcloud ports.https=444

Snap-Pakete haben nur limitierte Zugriffsrechte auf das System. Nextcloud bietet bei der Einrichtung die Möglichkeit einen spezifischen Speicherort für die Daten außerhalb der Nextcloud-Umgebung festzulegen. Das sollte man auch unbedingt machen (unabhängig ob Snap-Variante oder nicht!). Damit das Nextcloud-Snap dies allerdings darf muss noch folgender Befehl eingegeben werden:

# snap connect nextcloud:removable-media

Bevor man die Initialisierung startet legt man nun noch den Speicherpfad für die Daten fest. Dazu bearbeitet man die folgende Datei:

# nano /var/snap/nextcloud/current/nextcloud/config/autoconfig.php

In folgender zeile sollte der anvisierte Speicherpfad stehen:

'directory' => '/media/Daten/nextcloud',

Dieser muss natürlich dem Apache-Nutzer gehören:

# chown www-data:www-data /media/Daten/nextcloud

Anschließend muss man noch den PHP Service neustarten:

# snap restart nextcloud.php-fpm

Abschließend ruft man die Instanz im internen Netz über die interne IP-Adresse oder den Hostname des Servers auf. Wenn alles funktioniert erscheint die übliche Initialisierungsroutine von Nextcloud. Hier legt man dann noch die Zugangsdaten für das Konto fest.

Sofern man die Nextcloud lediglich im internen Heimnetz nutzen möchte war es das bereits. Das Snap-Variante reagiert nicht so performant wie eine normale Installation, bedeutet aber deutlich weniger Wartungsaufwand und erfordert viel werniger Kenntnisse in der Server-Administration. Insbesondere was die Einrichtung eines Redis-Cache und ähnliches betrifft.

Let's Encrypt Zertifikat einrichten

Sollte eine Erreichbarkeit außerhalb des Heimnetzes erforderlich sein, muss man für eine verschlüsselte Verbindung zusätzlich ein Zertifikat anfordern und einbinden. Seit einigen Jahren nutzt man dafür eigentlich ausschließlich Let's Encrypt. Eine Erreichbarkeit via DynDNS und Port-Freigabe ist hierfür erforderlich, siehe: Externer Zugriff auf den Server).

Die Einrichtung ist dann bei der Snap-Variante sehr einfach. Folgender Befehl startet die Routine:

# nextcloud.enable-https lets-encrypt

Hier bestätigt man die Anforderungen und trägt eine Mail-Adresse und die Domain, unter der die Nextcloud-Instanz zu erreichen ist, ein. Anschließend kann man die Nextcloud-Instanz via HTTPS Verbindung aufrufen. 

Bilder:
Einleitungs- und Beitragsbild von harshahars via pixabay

Heute möchte ich mal darüber schreiben wie sich Ubuntu so im Einsatz anfühlt… passend zum Blogtitel “Erfahrungen mit Ubuntu” und auch der erste Artikel im neuen Blogdesign. Ich hoffe es gefällt euch.

Komplett umgestiegen bin ich 2014 auf Ubuntu, damals weg von Debian weil dieses mein Notebook nicht korrekt unterstützt hat. Und da der Sprung nach Unity ein bisschen wie ins kalte Wasser war, habe ich mir gesagt…. ganz oder gar nicht. Also direkt alle Rechner im Haushalt auf Ubuntu umgestellt. Die Version 14.04 war die erste die ich eingesetzt habe. (Abgesehen von ein paar Experimenten mit 8.04 und 10.04)

Es hat etwas gedauert bis ich mich an Unity gewohnt habe, aber jetzt nach einigen Jahren ist die Akzeptanz bei mir und auch dem Rest der Familie durchweg hoch und jeder kommt intuitiv sofort damit klar. Obwohl ich zunächst sehr skeptisch war muss ich sagen das ich der Oberfläche Unity jetzt sogar etwas hinterher trauer. Aber noch ist sie in 16.04 enthalten.

Ubuntu 16.04 ist auch die Version die ich im Moment auf jedem Rechner in privaten wie auch beruflichen Umfeld einsetzte. Mit gefällt diese sehr homogene Umgebung und ich habe mich sehr daran gewöhnt. Es gibt keine Aufgabe die ich damit nicht lösen könnte. Egal ob der eigene Mail und Webserver, ein Streamingserver auf DLNA oder nur die Arbeit im Internet. Selbst das mitgelieferte Office Paket ist allen Anforderungen gewachsen.

Den Schritt zu Linux im allgemeinen und zu Ubuntu im besonderen habe ich nie bereut.
Ich könnte mir die Arbeit mit den ganzen Gängelungen der anderen Systeme gar nicht mehr vorstellen.

In der Open Source Szene kann man sich seit einigen Monaten vor Matrix gar nicht mehr retten. Der Dienst sollte alles besser machen und die Messenger-Misere überwinden. Nun wurden die Matrix.org-Server gehackt und damit alle Nutzer des meist genutzten Servers kompromittiert.

Matrix und Riot sind momentan die am meisten gehypte Kommunikationslösung in der Open Source Szene. Die Neuentwicklung soll die Fehler von XMPP vermeiden und endlich eine leistungsstarke freie Alternative zu den verbreiteten proprietären Messengers bieten (siehe auch: Freie Messenger - viele Lösungen, keine Zusammenarbeit). Erst im Februar gab KDE bekannt auf Matrix zu wechseln.

Der Angriff erfolgte nicht über die Matrix-Software selbst - diese gilt vorerst als sicher - sondern über eine Sicherheitslücke in Jenkins. Der Angreifer weist aber auf zahlreiche Sicherheitsmängel hin und scheinbar haben die Betreiber hinter Matrix.org einige grundlegende Sicherheitsstandards missachtet.

Alle Nutzer werden aufgefordert ihre Passwörter zu ändern, da vor allem bei leichten Passwörter die Hashes geknacht werden könnten. Die Betreiber von Matrix.org haben zudem aus Sicherheitsgründen alle Nutzer ausgeloggt. Wer kein Backup hat, verliert dadurch laut Golem den Zugriff auf seinen kompletten Nachrichtenverlauf. Insbesondere letzteres ist eigentlich eine ziemliche Katastrophe.

Das Problem bei dezentralen Lösungen ist halt leider auch, dass man - sofern man nicht imstande oder willens ist einen eigenen Server zu betreiben - trotzdem wieder auf Dienste Dritter angewiesen ist. Diese agieren teilweise halt nicht professionell, auch weil sie die Dienste oft nur nebenbei betreiben.

Die Episode zeigt man wieder, dass man nicht auf jeden Hype aufspringen sollte und etablierte Messenger wie Signal für sichere Kommunikation, sowie XMPP und IRC für die Community nicht so schnell beerdigt werden sollten. 

Das ist ein ziemliches Debakel. Natürlich kann so etwas passieren, Opfer von Hacker-Angriffen wurden schon deutlich größere und professionellere Anbieter. Aber wäre dies WhatsApp oder einem vergleichbaren Dienst passiert, hätte sich das Unternehmen vor einem Shitstorm kaum retten können. Nach dem Golem-Artikel hatte ich die vergangenen Tage gespannt auf Reaktionen in der Open Source Szene gewartet. Insbesondere von jenen, die seit einiger Zeit die Werbetrommel für Matrix gerührt haben. Aber da kam gar nichts! Das Thema wird geradezu tot geschwiegen.

Bilder:
Einleitungs- und Beitragsbild von Tumisu via pixaybay

Um während der Kompilierung in GCC die Zwischenschritte, d.h. die Ausgabe des Präprozessors, den Assembler-Code sowie die Object-Files, permanent (statt lediglich temporär) zu speichern, kann während des Kompilierungsvorgangs die Option -save-temps gesetzt.

Die Kompilierung einer Datei "helloworld.c" würde dann folgendermaßen aussehen:

gcc -save-temps -o helloworld helloworld.c

Es werden folgende Dateien hierbei erstellt:

• helloworld ist die ausführbare Datei
• helloworld.c enthält den Source, der vom Entwickler geschrieben wurde
• helloworld.i enthält die Ausgabe des Präprozessors, hier sind z.B. alle defines, includes, etc. bereits aufgelöst
• helloworld.o ist die Objektdatei
• helloworld.s enthält den Assembler-Code

Eine sinnvolle Option für alle, die den Kompilierungsprozess genauer verstehen möchten oder Entwickler, die bestimmte Fehler finden wollen, die z.B. beim Präprozessoroutput auffallen würden. (z.B. warum genau ein Include-Guard benötigt wird)