Ubuntu 19.04 ist ein Release ohne dramatische Neuerungen. Optisch springen neue Icons in Auge, die dem Desktop mehr Frische geben. Gnome 3.32 unterstützt fractional scaling, was die Arbeit auf hochauflösenden Displays verbessern sollte. Das Feature gilt aber noch als experimentell und muss explizit aktiviert werden. Generell verspricht Gnome etwas mehr Performance. Die lässt sich in Benchmarktests messen, gefühlt hat sich aber nicht viel geändert.

Fractional Scaling

In der Vergangenheit mussten Sie sich in Gnome zwischen 100% oder 200% Skalierung entscheiden. Auf hochauflösenden Displays führt die erste Einstellung zu einer winzigen Textdarstellung, während die zweite meist schon zu viel des Guten ist und wertvollen Platz verschwendet. Gnome 3.32 unterstützt nun auch 125%, 150% und 175%. Allerdings stehen diese Einstellungen nur zur Verfügung, wenn Sie das experimentelle Feature vorher aktivieren.

• X: gsettings set org.gnome.mutter experimental-features "['x11-randr-fractional-scaling']"
• Wayland: gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

Bei meinen Tests haben die neuen Skalierungsstufen gut funktioniert. Manche Programme werden anscheinend nicht komplett scharf dargestellt. Mir sind allerdings optisch keine Probleme aufgefallen. Wünschen würde ich mir allerdings eine vollkommen freie Einstellung der Skalierungsstufe.

Intern sind die Skalierungsstufen unter Wayland und X unterschiedlich implementiert. Wayland-Programme werden wirklich skaliert, während die Skalierung unter X mittels xrandr erfolgt. (Im Prinzip wird ein virtueller Bildschirm in höherer Auflösung für das Rendering verwendet. Danach wird die Ausgabe auf die tatsächliche Auflösung herunterskaliert. Das ist naturgemäß relativ aufwendig und optisch nicht perfekt.)

Icons auf dem Desktop

Im Unterschied zum originalen Gnome ist es unter Ubuntu möglich, Dateien auf dem Desktop abzulegen. Canonical hat dazu standardmäßig die Gnome Extension Desktop Icons aktiviert. Von dieser Extension profitieren auch alle, die nicht vor haben, den Desktop mit Icons zu übersäen: Dank dieser Extension enthält Ubuntu zur Abwechslung wieder einmal eine aktuelle Nautilus-Version.

Versionsnummern

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel      5.0   Gnome        3.32   bash       5.0   Apache     2.4
glibc      2.29   Firefox        66   gcc        8.3   CUPS       2.2
X-Server   1.20   Gimp         2.10   Java        11   MySQL      5.7
Wayland    1.16   LibreOffice   6.2   PHP        7.2   OpenSSH    7.9
Mesa       19.0   Thunderbird    60   Python     3.7   qemu/KVM   3.1
Systemd     240                                        Postfix    3.3
NetworkMan 1.16                                        Samba     4.10
GRUB       2.02 

Quellen

• Download
• Release Notes
• Ubuntu auf DistroWatch
• heise.de
• omgubuntu
• derstandard.at
• Details zu Fractional Scaling
• Noch mehr Details zu Fractional Scaling
• Desktop Icons Extension

Einige Desktop-Umgebungen integrieren den Audioplayer ihrer Wahl in das Panel. Da ich vor kurzem zu Manjaro mit Gnome 3 gewechselt habe, fehlte mir bislang diese Funktion. Im Standard bietet mir der Audioplayer meiner Wahl, Clementine, diese Möglichkeit leider nicht. Doch dafür gibt es Abhilfe über die Gnome Shell Erweiterung mpris-indicator-button.

Diese Erweiterung sollte mit allen gängigen Audioplayern unter Linux die „MPRIS v2“ oder „D-Bus“ unterstützen funktionieren. Unter anderem Amarok, GMusicBrowser, GNOME Music, Guayadeque, Rhythmbox, Tomahawk, Lollypop, etc.

Installationsanleitung

Methode 1

Über die GNOME Extensions site

Methode 2

Für Ubuntu Systeme

1. Git Klonen
2. In das Verzeichnis wechseln
3. Datei in das Verzeichnis für Gnome Erweiterungen kopieren

git clone https://github.com/JasonLG1979/gnome-shell-extension-mpris-indicator-button.git
cd gnome-shell-extension-mpris-indicator-button
cp -a mprisindicatorbutton@JasonLG1979.github.io ~/.local/share/gnome-shell/extension

Soll die Erweiterung allen Benutzer eures System zur Verfügung stehen, müsst Ihr diese mit Root Berechtigungen in das Verzeichnis „/usr/share/gnome-shell/extensions“ kopieren.

Finale Aktivierung

Zum Schluss müsst Ihr Gnome Neu starten und die Erweiterung aktivieren. Dies erledigt Ihr am schnellsten über die Tastenkombination „ALT+F2“, danach „r“ eintippen und mit Enter bestätigen. Alternativ meldet Ihr euch vom System ab und wieder an.

Über gnome-shell-extension-prefsbzw. über „Gnome Tweaks“ wird dann die Erweiterung aktiviert.

Danach verbindet sich die Erweiterung mit eurem Audioplayer. Dort wird euch dann angezeigt welcher Titel aktuell gespielten wird. Außerdem habt Ihr ein paar Optionen zur Steuerung.
Pro-Tipp: Mittels Rechtsklick auf das Icon, wird euch der Audioplayer geöffnet :)

Zum Schluss

Mir konnte die kleine Erweiterung mpris-indicator-button bereits weiterhelfen. Wer es ausführlicher und mit mehr Optionen mag, der sollte sich einmal vom gleichen Entwickler gnome-shell-extensions-mediaplayer anschauen. Dies bietet mehr Optionen und Bedienkomfort. Aktivieren könnt Ihr diese Erweiterung genauso wie oben beschrieben.

MPRIS-Indicator-Button: Audioplayer im Gnome Panel integrieren ist zuerst erschienen auf André Hemkes.

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 start languagetool

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)

Seit ca. einem Monat besitze ich ein Lenovo Thinkpad P1 Notebook. In diesem Beitrag fasse ich meine bisherigen Erfahrungen mit dem Gerät unter Linux zusammen.

Konkret habe ich mich für ein Modell mit der CPU i7 8750H und einem FHD-Display entschieden; RAM auf 32 GByte erweitert, zwei SSDs (256 GB mit Windows, 2 TB mit Linux). Vorweg ein paar Links, um Wiederholungen zu vermeiden:

• Warum gerade dieses Notebook?
• Installation von Pop!_OS
• Produktpräsentation bei lenovo.com
• Test eines wesentlich teureren Modells bei notebookcheck.com
• Eckdaten meines Modells bei lapstars.de

Das BIOS habe ich unter Windows auf die aktuelle Version 1.19 aktualisiert. Das BIOS-Update hat die Geräuschentwicklung des Geräts spürbar verbessert — für einen lautlosen Betrieb bei meinen Arbeitsbedingungen reicht es aber leider nicht.

Leben mit NVIDIA

Der größte Nachteil des Geräts war mir vor dem Kauf schon klar. Es ist mit einer NVIDIA-Grafikkarte ausgestattet (P1000). Zwar kann der Bildschirm des Geräts auch von der Intel-CPU angesteuert werden; externe Bildschirme erfordern aber zwingend die Aktivierung der NVIDIA-GPU.

Meinen Befürchtungen zum Trotz bereitet die NVIDIA-GPU im Alltag erstaunlich wenig Probleme: Dank vorheriger Recherche habe ich mich gleich für die Ubuntu-Variante Pop!_OS entschieden, die meinen Zwecken genügt. Installation und Betrieb verliefen bzw. verlaufen problemlos.

Anfänglich hatte ich einige Male das Problem, dass der externe Monitor nach dem Aufwachen aus dem Ruhezustand schwarz blieb. Abhilfe schuf in solchen Fällen nur ein Neustart. Seit ich das HDMI-Kabel nicht an den Thunderbolt-Dock sondern direkt an die HDMI-Buchs anschließe, ist dieser Fehler nicht mehr aufgetaucht.

Frei von Nachteilen ist die NVIDIA-GPU aber dennoch nicht. Erstens führt der nicht GPL-konforme Treiber dazu, dass mein Kernel tainted ist. Kein erfreulicher Zustand für einen Linux-Fan:

dmesg | grep taint

nvidia: loading out-of-tree module taints kernel.
nvidia: module license 'NVIDIA' taints kernel.
Disabling lock debugging due to kernel taint
nvidia: module verification failed: signature and/or required key missing - tainting kernel

Zweitens scheidet Wayland als Grafiksystem aktuell aus. (Diesbezüglich ist Besserung in Sicht. Und grundsätzlich kann ich mit X.org gut leben.)

Drittens muss ich auf UEFI Secure Boot verzichten. (Auch das bereitet mir wenig Kummer.)

Viertens (siehe auch Fazit) ist ein lüfterloser Betrieb bei aktiver NVIDIA-Karte unmöglich, nur mit Intel-GPU hingegen schon. Ich habe es nicht erwartet, aber dieser Punkt irritiert mich nach einem Monat mehr als die anderen drei zusammen.

Undervolting

Eine beliebte Maßnahme zur Reduktion der CPU-Temperatur, zur Verlängerung der Akku-Laufzeit sowie zur Verbesserung der Performance (weil die CPU unter Last erst später gedrosselt wird) ist Undervolting. Die CPU wird also mit weniger Spannung versorgt als eigentlich vorgesehen wäre. Einen sehr ausführlichen Bericht über die Konzepte von Undervolting finden Sie auf notebookcheck.com.

Unter Linux bietet sich zum Undervolting das Programm intel-undervolt an (GitHub). Ich verwende nun seit zwei Wochen absturzfrei diese Einstellungen:

# Datei /etc/intel-undervolt.conf
undervolt 0 'CPU'        -130
undervolt 1 'GPU'        -100
undervolt 2 'CPU Cache'  -100
undervolt 3 'System Agent'  0
undervolt 4 'Analog I/O'    0
interval 5000

Beachten Sie, dass jede CPU andere Toleranzen hat! Bei meinen (eher bescheidenen) Benchmark-Tests hat sich daraus ein kleiner Geschwindigkeitsunterschied ergeben (getestet mit GeekBench). Der Stromverbrauch ist ebenfalls nur minimal gesunken (gemessen mit einem billigen Strommessgerät vor dem Netzteil). Meine eigentlicher Wunsch, den Lüfter damit zum Schweigen zu bringen, hat sich nicht erfüllt.

Lüftersteuerung

Ich habe natürlich versucht, den Lüfter mit thinkfan selbst zu steuern, bin aber gescheitert. So weit ich es verstanden habe, hat das Notebook die Steuerungsanweisungen des Programms ganz einfach ignoriert.

CPU-Steuerung

Die meiste Zeit habe ich keinen Bedarf für maximale CPU-Leistung und ziehe einen minimalen Stromverbrauch und möglichst große Ruhe vor. Gelegentlich will ich aber alles an Leistung haben, was die CPU hergibt. Zwar stellt Pop!_OS über das Gnome-Menü drei Leistungsstufen zur Wahl, letztlich habe ich mich aber für die Gnome-Extension cpufreq entschieden, die eine angenehme Oberfläche und mehr Optionen bietet. Empfehlenswert!

Thunderbolt

Das Notebook hat zwei Thunderbolt-Anschlüsse — Neuland für mich. Ich habe mir bei amazon einen Billig-Hub besorgt und daran ein Netzwerkkabel, Tastatur und Maus, einen Lautsprecher (mit diesem USB-Adapter) und anfänglich auch meinen Monitor angeschlossen. Alles funktionierte auf Anhieb, ohne irgendwelche Einstellungen, Treiberinstallationen etc.! Faszinierend. (Achtung, dieser USB-Hub unterstützt Ethernet nur mit 100 MBit!)

Seit ich an den Hub ein 65W-USB-C-Netzteil angeschlossen habe, lädt dieses das Notebook. Über einen Anschluss (bzw. zwei, seit ich den Monitor wieder direkt mit dem Notebook verbinde) ist die gesamte Büroverkabelung erledigt.

Benchmarks

Ich habe mich nicht besonders lange mit Benchmarktests aufgehalten und nur ein paar wenige Messungen mit dem (ohnedies nicht übermäßig aussagekräftigen) Programm GeekBench 4 durchgeführt. Die Ergebnisse unter Pop!_OS 18.10:

• Mit Stromversorgung, mit TurboBoost, mit Undervolting: 5175 (Singlecore) / 23366 (Multicore)
• Akkubetrieb ohne TurboBoost, mit Undervolting: 3054 / 15275

Andere Linux-Distributionen

Aktuell bin ich mit Pop!_OS zufrieden. Tests mit Ubuntu 19.04 und Fedora 30 sind geplant, werden aber noch ein paar Wochen dauern.

Sonstige Anmerkungen

• Der eingebaute Bildschirm ist gut und ausreichend hell — aber natürlich nicht hochauflösend, sondern nur FHD. Matte, nicht spiegelnde Oberfläche.

• Der Klang der eingebauten Lautsprecher ist erbärmlich. (Es gibt eine 3,5 mm Buchse für Kopfhörer.)

• Die Tastatur ist gut, aber die Tastaturen älterer Thinkpads waren besser (deutlich mehr Hub). Immerhin sind, anders als bei Apple, aktuell keine Funktionsstörungen wegen mikroskopisch kleiner Krümel bekannt …

• Das originale Netzteil ist beachtliche 0,45 kg schwer. Es ist für meine Zwecke mit 135 W total überdimensioniert. Ich habe mir ein 65W-USB-C-Netzteil besorgt, das kaum mehr als die Hälfte wiegt.

Fazit

Grundsätzlich erfüllt das Gerät meine Anforderungen: 15-Zoll-Bildschirm, qualitativ gute mittige Tastatur, hohe CPU-Leistung, RAM und SSD in Hülle und Fülle, relativ niedriges Gewicht. Zum ersten Mal besitze ich ein Notebook, das meinem Arbeitsalltag entspricht. (Bisher habe ich auf Desktop-PCs gearbeitet und ein Notebook nur als Notlösung für unterwegs verwendet.)

Enttäuscht bin ich, dass das Gerät in meiner Hauptkonfiguration (zuhause im Büro, ohne starke CPU-Belastung und ohne TurboBoost, aber mit externem Monitor + Tastatur + Maus) nicht lautlos ist. Der Lüfter säuselt unter diesen Bedingungen zwar nur, aber das ständige Ein- und Ausschalten (ca. zwei bis drei Minuten Ruhe, dann ca. 30 Sekunden Lüfter) nervt dennoch. Die Temperatur pendelt entsprechend zwischen 48 und 58° C, d.h. sie steigt in den lüfterlosen Phasen langsam an und wird dann durch den Lüfter relativ schnell wieder reduziert. Die Leistungsaufnahme variiert zwischen ca. 16 und 30 W, Mittelwert ca. bei 25 W. Klar, dass das zu viel Wärme in dem kleinen Gehäuse verursacht.

Mag sein, dass ich diesbezüglich verwöhnt bin, aber meine beiden Desktop-PCs (ein selbst zusammengestellter Linux-PC und ein iMac) laufen bei gleichen Arbeitsbedingungen komplett lautlos.

Ich gebe die Schuld an der Geräuschentwicklung (ganz objektiv natürlich ;-) ) NVIDIA. Unterwegs, also nur mit Intel-Grafik, läuft das Notebook nämlich lautlos. Im Büro kann ich aber nicht auf die NVIDIA-GPU verzichten, weil ich dann keinen externen Monitor anschließen kann. Offensichtlich ist der Zusatzstromverbrauch der GPU gerade so hoch, dass ein lüfterloser Betrieb selbst im Leerlauf unmöglich ist.

Liebe Notebook-Hersteller, ein Highend-Notebook ohne dezidierte GPU wäre vielleicht eine Marktlücke …

LibreELEC oder auch OpenELEC dürfte Fans von freien Medienplayern ein Begriff sein. Ich selbst habe LibreELEC im Einsatz und bin recht zufrieden damit.

Da ich LibreELEC direkt am Fernseher betreibe und lediglich über die Fernbedienung steuere, vermisse ich manchmal Funktionen die über die Tastatur kein Problem darstellen. Allerdings führen viele Wege nach Rom. Dieses gilt zum Beispiel für das Erstellen eines Bildschirm Fotos.

Screenshot via SSH erstellen

Normalerweise kann ein Screenshot mit Strg+s über die Tastatur erstellt werden. Ist allerdings keine vorhanden, geht dies auch fix via SSH.

Dazu muss der Dienst natürlich aktiv sein.

Sobald SSH aktiv ist, kann auf der Konsole gearbeitet werden. Kodi bringt dazu den Befehl kodi-send mit. Dieser erlaubt es verschiedene Befehle an das System zu senden unter anderem auch den Bildschirm abzufotografieren:

kodi-send --host=127.0.0.1 -a "TakeScreenshot"

Der Host muss auf dem lokalen Prompt nicht zwingend angegeben werden. Ich habe es der Vollständigkeit mit angegeben.

Kodi via SSH steuern

Dieser wird erst relevant, wenn der Befehl über Netzwerk versendet wird, Beispiel:

ssh root@192.168.10.19 'kodi-send --action="PlayerControl(Stop)"'

SSH sollte somit zwingend mit einem neuen Passwort versehen werden, wenn es aktiv ist. Das Default Passwort wäre übrigens "libreelec"

Das Kommando erlaubt weitere Funktionen. Die Hilfe kann mit --help aufgerufen werden.

Weitere Kommandos wären beispielsweise:

Laufende Wiedergabe anhalten

kodi-send --action="PlayerControl(Start)"

System ausschalten

kodi-send --action="Quit"

Plugin installieren (Zuständiges Repository sollte aktiv sein)

kodi-send --action="InstallAddon(plugin.video.kikamediathek)"

Eine Liste aller möglichen Befehle findet ihr hier.

Viel Spaß beim Probieren

Mozilla hat mit Firefox 66.0.3 ein Update außer der Reihe für Firefox 66 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 66.0.3

Mozilla hat Firefox 66.0.3 veröffentlicht und behebt damit ein mögliches durch das Windows-Update 1809 ausgelöstes Problem mit der Adressleiste auf Tablets mit Windows 10.

Außerdem wurden wie schon in Firefox 66.0.2 Kompatibilitätsprobleme mit Cloud-Anwendungen von Microsoft und IBM behoben. Die Probleme haben ihre Ursache in einer Änderung des Event-Handlings von Firefox. Mozilla umgeht hier Probleme Dritter, indem für die genannten Webseiten temporär das alte Verhalten wiederhergestellt wird, bis diese ihren Code korrekt implementiert haben.

Außerdem wurde ein Performance-Problem mit JavaScript auf Windows behoben, von welchem unter anderem die Spiele auf pogo.com betroffen waren, und für chinesische Nutzer das Such-Plugin von Baidu aktualisiert.

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

Thunderbird ist für viele Anwender der E-Mail Client schlechthin. Das gilt natürlich auch unter Linux. Obwohl Thunderbird Open Source ist, unterstützt es freie Schnittstellen erstaunlich schlecht, weshalb einige Nacharbeiten notwendig sind um das Programm mit CalDAV und CardDAV Diensten wie der Nextcloud zu verbinden.

Dieser Beitrag ist ein Exkurs der Serie Cloud in Eigenregie (siehe: Cloud in Eigenregie I: Vorbemerkungen). Dort konnte auf Thunderbird keine Rücksicht genommen werden, da die einfache Integration in den Linux-Standard Ubuntu und GNOME demonstriert werden sollte. Die Einbindung von Nextcloud in Thunderbird ist aber weder ganz einfach, noch unbedingt selbsterklärend. Dieser Artikel hier ist somit ein kleiner Exkurs.

Thunderbird gibt es seit gut 15 Jahren und es ist für Anwender aller großen Desktop-Betriebssysteme ein viel genutztes Mittel um E-Mails zu verwalten. Das Programm spiegelte in der Vergangenheit die Irrwege der Mozilla Foundation. 2012 wollte man Thunderbird aufgeben um sich auf Projekte wie Firefox OS (wer erinnert sich noch...) zu konzentrieren. 2015 wollte man dann Thunderbird komplett loswerden und aus Mozilla ausgliedern. Nachdem man noch eine Reihe anderer Rohrkrepierer losgelassen hatte entschloss man sich die Verbindungen zu Thunderbird doch nicht komplett zu kappen.

Thunderbird ist quelloffen und ein Vorzeigeprojekte wenn es um Open Source Software unter allen Betriebssystemen geht. Trotzdem unterstützt Thunderbird freie Standards erstaunlich schlecht. Weder kann man von Haus aus mit GPG umgehen, noch unterstützt man alle DAV-Schnittstellen. Selbst Apple ist da offener für freie Protokolle.

Kontakte

Zum Abgleich der Kontakte mittel der CardDAV-Schnittstelle benötigt man das Addon CardBook. Nach Installation und Neustart von Thunderbird erscheint ein Menüpunkt CardBook. Das Addon ersetzt faktisch das bisherige integrierte Adressbuch.

Über diesen Menüpunkt könnt ihr ein Netzwerk-Adressbuch einrichten. Im Einrichtungsdialog kann die CardDAV URL, sowie die Zugangsdaten hinterlegt werden.

Nach der Ersteinrichtung lässt sich die Synchronisierung über den entsprechenden Menüpunkt anstoßen.

Kalender

Thunderbird verfügt von Haus aus unter Linux über gar keinen Kalender. Dazu benötigt man zuerst das Addon Lightning. Für Windows ist dieses Addon inzwischen in das normale Thunderbird integriert worden, die Linux-Varianten kommen noch ohne Addon. Dieses ist zwar in den Ubuntu Paketquellen enthalten, aber ohne deutsche Lokalisierung. Daher installiert man es am besten über die integrierte Addon-Funktionalität. Bei anderen Distributionen sieht dies teilweise anders aus.

Über einen Rechtsklick in die Kalenderliste wählt man anschließend die Option einen neuen Kalender einzurichten. Hier wählt man dann die Variante "Im Netzwerk" und im folgenden Dialog CalDAV. Anschließend kann noch Name und Farbe festgelegt werden.

Nun kann man den CalDAV Kalender auch in Thunderbird/Lightning nutzen)

Bewertung

Mit Thunderbird erhält man E-Mail Program, das an Anciennität kaum zu überbieten ist und von der tragenden Organisation mehrmals abgekündigt wurde. Obwohl das Programm relativ schwerfällig daher kommt benötigt man für grundlegende Funktionen weitere Addons. Beispiele sind hier die Kontaktsynchronisation, sowie der Kalender. Kompatibilitätsbrüche bei Aktualisierungen sind da Vorprogrammiert und die Supportforen sind regelmäßig voll davon. Gerade Lightning ist eine ziemlich wackelige Angelegenheit. Thunderbird integriert sich weiterhin in keinen Linux-Desktop wirklich gut, sondern benötigt hierzu weitere Addons.

Ich persönlich würde daher auf jeder Plattform einem anderen E-Mail Programm den Vorzug geben. Unter Linux wären dies Evolution oder Kontact, unter Windows natürlich Outlook und unter macOS die Kombination aus Apple Mail und Apple Kalender.

Wer trotzdem an Thunderbird festhalten möchte kann aber trotzdem eine Integration mit DAV-Schnittstellen erreichen.

Bilder:
Einleitungs- und Beitragsbild von ribkhan via pixaybay

SeaMonkey ist eine auf Mozilla-Code basierende Suite, bestehend aus Browser, E-Mail-Client und mehr. In diesem Kommentar führe ich aus, wieso es aus meiner Sicht endgültig Zeit ist, Abschied zu nehmen.

Achtung: Dieser Artikel beschreibt ausschließlich die Meinung und persönliche Interpretation des Verfassers. SeaMonkey ist offiziell nach wie vor ein aktives Projekt.

Was ist SeaMonkey?

Bevor es Firefox und Thunderbird gab, gab es die Mozilla Application Suite. Ursprünglich waren Browser, E-Mail-Client und noch mehr unter einer gemeinsamen Oberfläche vereint. Seit die Mozilla Foundation Ende 2005 die Entwicklung der Mozilla Application Suite zugunsten der Einzelprogramme Firefox und Thunderbird einstellte, wird diese als Community-Projekt unter dem Namen SeaMonkey weitergeführt. Neben dem Browser und E-Mail-Client beinhaltet SeaMonkey auch einen Chat-Client sowie einen WYSIWYG-HTML-Editor.

Man kann nicht sagen, dass SeaMonkey eine extrem große Nutzergemeinde hätte, dafür aber eine umso treuere. Für die Nutzung von SeaMonkey kann es dabei ganz unterschiedliche Gründe geben, wie beispielsweise den angesprochenen Fakt, mit einem Programm alles unter einer Haube zu haben, die Nutzung von Legacy-Erweiterungen, welche in Firefox nicht mehr unterstützt werden, oder ganz einfach, weil einem SeaMonkey so gut gefällt – optisch tut sich bei SeaMonkey nämlich bewusst so gut wie gar nichts.

Was hat sich geändert? Wieso sollte SeaMonkey nicht länger verwendet werden?

Die Anzahl der Probleme und die Anzahl der Nutzer, die von diesen betroffen sind, wächst immer weiter, da das Projekt schon lange nicht mehr mit den steigenden Anforderungen der Zeit Schritt halten kann. Beispiele hierfür werden weiter unten im Artikel genannt. Diese Probleme müssen aber nicht jeden Nutzer betreffen oder zumindest nicht jeden Nutzer stören, so dass diese Probleme nicht ausschlaggebend sind. Jedoch hat sich eine Sache in den letzten Monaten geändert, die von ganz entscheidender Bedeutung ist.

SeaMonkey hat ein ernsthaftes Sicherheits-Problem

SeaMonkey kann nicht länger als sicheres Produkt erachtet werden und das ist ein Problem, welches ausnahmslos jeden Nutzer von SeaMonkey betrifft. Denn SeaMonkey basiert auf der Gecko-Plattform von Mozilla. Genauer gesagt auf Gecko 52. Zumindest alle Sicherheits-Fixes der Gecko-Plattform hat SeaMonkey durch Updates automatisch erhalten, wenn Mozilla die Sicherheitslücken geschlossen hat. Nun erschien im Juni 2018 das letzte Sicherheits-Update für Firefox ESR 52 und damit auch das letzte Update für Gecko 52. Alle danach entdeckten Sicherheitslücken müssen vom SeaMonkey-Projekt selbst behoben werden, ebenso wie sämtliche entdeckten Sicherheitslücken, welche nicht in Gecko, sondern in SeaMonkey selbst stecken.

Zwar hat das SeaMonkey-Projekt im Februar angekündigt, an SeaMonkey 2.49.5 zu arbeiten. Fakt ist aber, dass dieses Update weiter auf sich warten lässt und SeaMonkey nun schon seit SeaMonkey 2.49.4 im Juli 2018 – also seit neun Monaten – kein einziges Update mehr erhalten hat. Wer SeaMonkey von seamonkey.at herunterlädt, erhält sogar nur SeaMonkey 2.49.2 als neueste Version, da diese Webseite seit dem nicht mehr aktualisiert worden ist. Zwar handelt es sich dabei um keine offizielle Webseite des Projekts, dennoch dürfte dies für deutschsprachige SeaMonkey-Nutzer eine beliebte Downloadquelle für SeaMonkey sein. Nicht nur, weil diese Seite im Gegensatz zur offiziellen Webseite in deutscher Sprache existiert, sondern vor allem, weil Google diese Seite an erster Stelle noch vor der offiziellen Webseite anzeigt.

Nutzer von SeaMonkey sitzen teilweise aber wahrscheinlich bei noch älteren Versionen fest, da automatische Updates darüber hinaus auch noch deaktiviert sind und neue Versionen manuell heruntergeladen und installiert werden müssen. Ein Umstand, der ganz sicher nicht jedem SeaMonkey-Nutzer klar ist.

Diese Situation ist, bei aller Liebe zum Projekt und vollstem Verständnis für die Ressourcen-Probleme eines Community-Projekts, nicht akzeptabel. Denn Browser und E-Mail-Client als „Tor zum Internet“ müssen ohne Wenn und Aber sicher sein. Auch wenn vielleicht keine Sicherheitslücken offiziell bekannt sind, so ist es doch nur sehr schwer vorstellbar, dass die Notwendigkeit, Sicherheits-Updates auszuliefern, mit einem Mal verschwunden ist.

Es ist müßig zu erwähnen, dass Sicherheit nicht beim Schließen von Sicherheitslücken aufhört und sämtliche grundsätzlichen Verbesserungen der Sicherheits-Architektur, die Firefox in den letzten zwei Jahren erhalten hat, in SeaMonkey alleine schon aufgrund der Tatsache fehlen, dass man noch Gecko 52 einsetzt, was auf dem Feature-Stand von März 2017 ist und wir mittlerweile April 2019 schreiben.

Das fängt damit an, dass SeaMonkey die Multiprozess-Architektur von Firefox nicht besitzt und damit auch kein Sandboxing. Während dies zumindest auch für Thunderbird zutreffend ist, soll sich das bei Thunderbird noch in diesem Jahr ändern.

Ein weiteres Beispiel ist Quantum CSS, auch Stylo genannt, die in Rust geschriebene CSS-Engine, welche in Firefox 57 eingeführt wurde. Welche Bedeutung dies alleine für die Sicherheit hat, wird durch Zahlen schnell klar: Laut Mozilla hat es in Firefox seit dem Jahr 2002 69 Sicherheitslücken in der Style-Komponente gegeben, also der Komponente, welche für das CSS von Webseiten verantwortlich ist. Von den 69 Sicherheitslücken wären 51 gar nicht erst möglich gewesen, wäre von Anfang an Rust verwendet worden. Das unterstreicht, wie wichtig die zugrunde liegende Technologie ist, wenn es um Sicherheit geht.

In den letzten zwei Jahren wurden aber noch einige weitere Verbesserungen der Sicherheits-Architektur vorgenommen. Hier ließe sich eine ziemlich lange Liste anführen. Dazu muss man nur einmal alle Artikel zu sämtlichen Major-Releases seit Firefox 53 auf diesem Blog lesen. Und aktuell sind wir bei Firefox 66. Zwei Hände reichen zum Zählen aller Sicherheits-Verbesserungen in dem Zeitraum nicht aus. Das führt direkt zum nächsten Grund, wieso die Zeit von SeaMonkey vorbei ist.

Kein aktueller Unterbau auf absehbare Zeit und vielleicht auch keine Zukunft

Im Dezember 2018 hat das SeaMonkey-Projekt ein längst überfälliges Status-Update gegeben. Darin hat man versichert, dass das SeaMonkey-Projekt noch am Leben ist, allerdings auch eingestanden, dass die Zukunft von SeaMonkey ungewiss ist. SeaMonkey auf Firefox ESR 60 basieren zu lassen, wurde in diesem Status-Update praktisch ausgeschlossen. Und für die weitere Zukunft wurde ein noch dunkleres Bild gezeichnet. Denn SeaMonkey hängt noch sehr stark von Teilen der XUL-Architektur ab, welche von Mozilla längst entfernt worden sind.

Die Frage, die für das SeaMonkey-Projekt also naheliegenderweise in dem Raum gestellt wurde, ist die Frage, ob man SeaMonkey auf Firefox Quantum basieren lassen sollte, während man eine Ähnlichkeit zum jetzigen SeaMonkey behält, ob man alles so belassen sollte, wie es ist, bis überhaupt nichts mehr geht, oder man den Gecko-XUL-Code nicht forken sollte. Letzteres dürfte ein praktisch unmögliches Unterfangen sein, da hierfür sowohl Expertise als auch Ressourcen fehlen. Und so blieb diese Frage auch letztlich unbeantwortet, welchen Weg das SeaMonkey-Projekt in Zukunft gehen wird und ob es überhaupt eine Zukunft gibt.

Momentan sieht es nicht einmal so aus, als wäre man überhaupt in der Lage, selbst bei gleichbleibendem Unterbau, auf absehbare Zeit eine neue Version von SeaMonkey zu veröffentlichen.

Langjährige Probleme von SeaMonkey

Während dies nur der aktuelle Auslöser für mein Fazit ist, dass jetzt endgültig die Zeit gekommen ist, von SeaMonkey Abschied zu nehmen, gibt es eine ganze Reihe von Problemen, welche nicht neu sind und SeaMonkey schon eine ganze Weile begleiten.

Dies ist auch nicht weiter verwunderlich. SeaMonkey besitzt eine extrem kleine und nur ehrenamtlich daran arbeitende Entwickler-Gemeinde, was letztlich dazu führt, dass das Projekt nicht Schritt halten kann – weder mit dem Unterbau, auf welchem SeaMonkey basiert, noch mit den Anforderungen der Zeit. Nur dem Nutzer hilft der Grund dafür nicht.

Nicht verifizierter Entwickler

Für Nutzer von Apple macOS fangen die Probleme schon direkt nach der Installation an. Selbst nach Jahren hat man es nicht geschafft, ein verifizierter Entwickler zu sein, was zur Folge hat, dass SeaMonkey mit den Standard-Einstellungen des Betriebssystems ohne Umweg über das Kontextmenü überhaupt nicht gestartet werden kann. Abgesehen vom schlechten ersten Eindruck ist dieser Umweg auch längst nicht jedem Nutzer bekannt.

Verpixelte Schrift und Grafiken auf modernen Bildschirmen

Eine weit größere Zielgruppe ist von der immer noch nicht vorhandenen Unterstützung hochauflösender Bildschirme betroffen, was SeaMonkey für all jene Nutzer de facto unbenutzbar, da ungenießbar macht. Während man von Apple schon so gut wie gar keine Geräte mit nicht hochauflösenden Bildschirmen mehr erhält, rüsten längst auch andere Hersteller immer mehr ihrer Geräte mit solchen aus. Die Nicht-Unterstützung in SeaMonkey bedeutet nicht nur, dass die Oberfläche von SeaMonkey eine Pixelbrühe darstellt, auch sämtliche Webseiten werden mit nur sehr schlecht lesbarem Text dargestellt – für einen Browser ein KO-Kriterium.

Keine aktuellen Erweiterungen

Die Erweiterungs-Unterstützung mag für manche Nutzer ein Grund sein, SeaMonkey zu nutzen, immerhin unterstützt SeaMonkey noch die veralteten XUL-Erweiterungen. SeaMonkey hat aber bereits das Add-on SDK für Firefox nicht unterstützt und unterstützt jetzt ebenso keine WebExtensions. Das heißt, sämtliche Firefox-Erweiterungen der letzten Jahre sind nicht mit SeaMonkey kompatibel. Und da es zwischen Firefox und SeaMoney keine gemeinsame Erweiterungs-Schnittstelle gibt, müssten Erweiterungs-Entwickler für Firefox und SeaMonkey zwei voneinander vollkommen unabhängige Erweiterungen auf Basis völlig unterschiedlicher Architekturen entwickeln, um beide Produkte zu bedienen. Die Zahl der Entwickler, die das tun, dürfte überschaubar sein – falls es überhaupt auch nur einen einzigen gibt.

Daraus folgt nicht nur, dass viele tolle Erweiterungen, die in der Zwischenzeit entstanden sind, in SeaMonkey nicht genutzt werden können, auch für bestehende Erweiterungen sind kaum noch Kompatibilitäts-Anpassungen zu erwarten.

Und nachdem selbst Thunderbird längst fleißig dabei ist, die unterschiedlichsten WebExtension-APIs zu implementieren, sieht es auch für Erweiterungen der Mail-Komponente von SeaMonkey düster aus, wenn man in die Zukunft schaut. Denn auch hier werden Entwickler kaum zwei völlig verschiedene Erweiterungen für eine Sache entwickeln und anbieten.

… und noch viele Baustellen mehr

Eine Synchronisation von Lesezeichen, Chronik und Zugangsdaten gibt es mittlerweile wieder – dies war eine Weile nicht der Fall -, allerdings noch basierend auf dem alten, von Mozilla seit Jahren nicht mehr verwendeten Sync-Protokoll und ohne Firefox Account. Das heißt, eine Synchronisation von Daten mit einem Desktop-Firefox, Firefox auf dem Smartphone oder dem Passwort-Manager Firefox Lockbox ist nicht möglich.

Solange SeaMonkey auf Gecko 52 basiert, fehlt natürlich auch die Unterstützung für sämtliche Webstandards, welche erst danach implementiert worden sind. Es ist kein seltener Irrglaube, dass einen das als Nutzer nicht betreffen würde. Dabei ist das exakte Gegenteil der Fall: Webstandards betreffen sämtliche Nutzer und das ganz direkt: nämlich dann, wenn es um die Darstellung von Webseiten geht, was wohl ohne jeden Zweifel die eine Kernaufgabe eines jeden Browsers ist. In der Regel schauen Webentwickler bei der Entwicklung von Webseiten nämlich nicht auf ältere Firefox-Versionen, schon gar nicht auf Versionen, die über zwei Jahre alt sind. Je weiter die Zeit voranschreitet, desto mehr Webseiten werden von SeaMonkey also nicht mehr korrekt dargestellt, was dem natürlichen Lauf der Dinge entspricht, wenn man einen veralteten Browser nutzt – was SeaMonkey nun einmal ist, selbst wenn es Updates geben würde, solange in SeaMonkey noch Gecko 52 steckt.

Ähnlich wie die Darstellung von Webseiten hängt natürlich auch die Performance ganz maßgeblich von der Gecko-Engine ab und die Geschwindigkeitsunterschiede zwischen Gecko 52 und der aktuellen Version 66 sind signifikant und nicht von der Hand zu weisen.

Fazit

Letztlich muss jeder Nutzer für sich selbst entscheiden, ob er SeaMonkey Stand 2019 noch für eine geeignete Wahl hält. Was für den einen das beste ist, muss für den nächsten nicht zwangsläufig auch das beste sein.

Wenn es um den Funktionsumfang und das Design geht, ist das eine höchst individuelle Frage, welcher Browser für einen persönlich der beste ist. Die Wahrnehmung von Geschwindigkeit unterscheidet sich von Mensch zu Mensch und nicht jeder misst dem eine gleich hohe Bedeutung bei. Von den offensichtlichen Schwächen ist nicht jeder Nutzer in der gleichen Weise betroffen. Und so kann SeaMonkey trotz allem für den einen oder anderen Nutzer noch immer eine brauchbare Wahl sein.

Allerdings ist meine persönliche Empfehlung als Experte im Browser-Bereich, das Thema Sicherheit nicht auf die leichte Schulter zu nehmen. Beim derzeitigen Stand der Dinge könnte ich SeaMonkey daher nicht guten Gewissens weiterempfehlen. Im Gegenteil müsste ich von der Verwendung von SeaMonkey sogar abraten, weil Sicherheit beim Browser einfach über allem anderen steht und ich das aus den genannten Gründen überhaupt nicht mehr gewährleistet sehe.

Achtung: Dieser Artikel beschreibt ausschließlich die Meinung und persönliche Interpretation des Verfassers. SeaMonkey ist offiziell nach wie vor ein aktives Projekt.

Der Beitrag Kommentar: Wieso die Zeit von SeaMonkey endgültig abgelaufen ist erschien zuerst auf soeren-hentzschel.at.

Systemd wird häufig kritisiert, weil es größer und komplexer als bisherige Init-Systeme ist. Dafür bringt Systemd aber auch eine ganze Reihe an Tools zur Fehlerbehebung und Systemanalyse mit.

Eines davon ist systemd-analyze, mit dem sich der Bootvorgang des Systems darstellen und analysieren lässt. Die Ausgabe kann dabei textbasiert auf der Kommandozeile erfolgen, oder auch als svg-Grafik exportiert werden.

Bootvorgang mit systemd-analyze untersuchen

Ein simpler Aufruf von

systemd-analyze

zeigt eine Übersicht, welche Systembestandteile wie lange zum booten benötigen. Damit erhält man folgende Ausgabe.

Sofern das Betriebssystem auf einem Computer mit UEFI installiert ist, bekommt man auch die Startzeit des UEFI (firmware) präsentiert. Anschließend wird die Startzeit des Bootloaders ausgegeben (loader). Dass diese bei mir mit knapp 32 Sekunden angegeben ist, liegt (denke ich) an der Wartezeit im Grub Auswahlbildschirm. Anschließend werden die Startzeiten der systemnahen Komponenten (kernel) und der Benutzerumgebung (userland) angegeben.

Eine genauere Ausgabe erhält man mit dem Befehl

systemd-analyze blame

Damit erhält man eine Auflistung aller beim booten gestarteten Dienste, sortiert nach ihrer Startzeit. Damit lassen sich Dienste, die das starten verzögern schnell identifizieren.

Außerdem lässt sich die Ausgabe auch als SVG-Grafik exportieren. Damit erhält man noch detailliertere Ergebnisse. der Export erfolgt mit

systemd-analyze plot > boot.svg

Allerdings ist die exportierte Grafik ziemlich groß, so dass man viel scrollen muss um diese zu analysieren. Horizontal wird dabei die Startzeit in Sekunden angegeben. Vertikal werden die einzelnen Dienste aufgelistet.

Die Ausgaben von systemd-analyze sind nicht nur interessant, sondern ermöglichen auch, auf den ersten Blick zu erkennen, warum der Bootvorgang so lange dauert. Dienste, die den Bootvorgang verlangsamen lassen sich damit direkt identifizieren, wo ansonsten möglicherweise eine langwierige Fehlersuche oder Analyse notwendig wäre.

Bootzeit mit Systemd analysieren ist ein Beitrag von techgrube.de.

Ich wollte mich in nächster Zeit ein wenig mit mongodb und nodejs beschäftigen. Hierfür habe ich Mongodb von der Seite https://www.mongodb.com/download-center/community heruntergeladen.

Die tgz Datei wurde mit tar -zxvf mongodb-osx-ssl-x86_64-<version>.tgz entpackt und unter /usr/local/bin abgelegt. Für den Speicherort der Daten habe ich mich für das Standardverzeichnis /data/db entschieden. Das Verzeichnis wurde unter dem root Benutzer angelegt und der Besitzer der Verzeichnisse wurde auf meinen Benutzer mit dem ich auf dem Mac arbeite geändert.

Zum starten der mongodb muss folgendes auf der Kommandozeile ausgeführt werden

export PATH=/usr/local/bin/mongodb-osx-x86_64-4.0.6/bin:$PATH mongod

Um sich die Eingabe des Export Befehls zu sparen, wurde dieser in der .bash_profile hinterlegt

Auf vielen Mail-Servern läuft SpamAssassin, um Spam-verdächtige Mails mit einer Header-Zeile zu markieren. Ordentliche Mail-Client wie Thunderbird können dann mit einer simplen Filter-Regel derartige Mails aussortieren.

Noch besser wäre es aber, wenn die Mails bereits auf dem Server in einen eigenen Junk-Folder verschoben würden. Das ist insbesondere dann praktisch, wenn zum Lesen von Mails auch diverse Mail-Clients auf Smartphones, iPads etc. verwendet werden, die keine Filtermöglichkeiten bieten.

Voraussetzungen

Die folgende Anleitung setzt voraus, dass Sie

• unter Debian/Ubuntu arbeiten (ich habe zuletzt zwei Systeme unter Ubuntu 16.04 + 18.04 entsprechend konfiguriert)

• Postfix, Dovecot und SpamAssassin bereits installiert sind und so weit funktionieren, dass eintreffende Spam-Mails gekennzeichnet werden. Werfen Sie einen Blick in den Quellcode einer Spam-Mail; dort sollte X-Spam-Status-Zeile enthalten sein. Ich habe zur SpamAssassin-Konfiguration Milter verwendet, also im Prinzip apt install spamassassin spamass-milter sowie smtpd_milters = unix:spamass/spamass.sock in /etc/postfix/main.cf.

• die Mail-Accounts lokal konfiguriert sind (also nicht ISP-Style über eine Datenbank)

Die Anleitung funktioniert prinzipiell natürlich auch, wenn bei Ihnen eine andere Konfiguration vorliegt. Aber dann kann es sein, dass irgendwelche Details anders zu lösen sind.

Zusatzpakete installieren

Alle Arbeiten sind mit root-Rechten zu erledigen.

apt install dovecot-lmtpd dovecot-managedsieved swaks

• LMTPD ist ein Zusatzdienst für Dovecot, der bei der lokalen Zustellung von Mails hilft.

• Sieve ist eine Sprache für E-Mail-Filterregeln

• SWAKS ist der Swiss Army Knife SMTP, the all-purpose smtp transaction tester

Sieve-Konfiguration einrichten

Mails, die als Spam erkannt wurden, sollen in den Junk-Folder verschoben werden. Die entsprechenden Anweisungen in der Sieve-Syntax müssen in einer *.sieve-Datei gespeichert werden. Ich habe dazu das Verzeichnis /etc/dovecot/sieve-after eingerichtet und dort die folgende Textdatei gespeichert:

# neue Datei /etc/dovecot/sieve-after/spam-to-folder.sieve
require ["fileinto","mailbox"];
if header :contains "X-Spam-Flag" "YES" {
 fileinto :create "Junk";
 stop;
}

Diese Datei muss kompiliert werden:

cd /etc/dovecot/sieve-after
sievec spam-to-folder.sieve

Dovecot-Konfiguration

Damit Dovecot sowohl LMTP als auch Sieve verwendet, sind eine Menge Änderungen erforderlich. Alle im folgenden erwähnten Dateien befinden sich in /etc/dovecot/conf.d.

10-auth.conf: LMTP erwartet Mail-Usernamen in der Form ’name@host.com. Wenn Sie hingegen einfach name verwenden, müssen Sie dasauth_username_format` wie folgt einstellen:

# Datei /etc/dovecot/conf.d/10-auth.conf
...
# https://serverfault.com/questions/658703
auth_username_format = %Ln
...

10-master.conf: Damit die Kommunikation zwischen Dovecot und LMTP funktioniert, kommentieren Sie in 10-master.conf den Block service lmtp aus und ersetzen ihn durch die folgenden Zeilen:

# Datei /etc/dovecot/conf.d/10-master.conf
...
#  https://serverfault.com/questions/512219/dovecot-lmtp-does-not-exist
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}
...

15-mailboxes.conf: Damit die Mail-Clients den Junk-Folder standardmäßig anzeigen, fügen Sie im schon vorhandenen Abschnitt mailbox Junk die Einstellung auto = subscribe hinzu:

# Datei /etc/dovecot/conf.d/15-mailbox.conf
...
mailbox Junk {
    special_use = \Junk
    auto = subscribe
  }

20-lmtp.conf: Damit Dovecot sowohl LMTP als auch Sieve verwendet, muss im Block protocol lmtp eine gültige Postmaster-Adresse eingestellt sein und das sieve-Plugin aktiviert werden.

# Datei /etc/dovecot/conf.d/20-lmtp.conf
...
protocol lmtp {
  postmaster_address = postmaster@ihr-hostname.bla
  mail_plugins = $mail_plugins sieve
}

90-sieve.conf: Zu guter Letzt muss die zuvor eingerichtete Sieve-Regel aktiviert werden. Dazu ist die folgenden sieve-after-Einstellung erforderlich. Damit werden alle kompilierten Sieve-Dateien in /etc/dovecot/sieve-after berücksichtigt.

# Datei /etc/dovecot/conf.d/90-sieve.conf
...
sieve_after = /etc/dovecot/sieve-after

Postfix-Konfiguration

Weniger aufwendig sind die Änderungen an main.cf. Die erste Zeile aktiviert LMTP für den Transport von Mails in lokale Verzeichnisse. Die zweite Regel ist anscheinend notwendig, damit SpamAssassin mit Postfix als Milter (Mailbox-Filter) funktioniert (Quelle). Ich gestehe, dass sich mir der Sinn dieser Zeile nicht erschlossen hat.

# Datei /etc/postfix/main.cf
...
mailbox_transport = lmtp:unix:private/dovecot-lmtp
milter_connect_macros = i j {daemon_name} v {if_name} _

Test

Um sicherzugehen, dass Postfix und Dovecot alle Änderungen erkannt haben, starten Sie die Programme neu:

systemctl restart postfix
systemctl restart dovecot

Danach senden Sie sich (idealerweise von einem anderen Rechner) mit swaks eine Spam-Test-Mail zu, die von jedem Spam-Tester zuverlässig als Spam erkannt wird:

swaks --to eine-adresse@ihr-host.bla --server localhost --data /usr/share/doc/spamassassin/examples/sample-spam.txt

Im Idealfall taucht die Mail nun im Junk-Folder Ihres Mail-Accounts auf. Wenn nicht, beginnt die Fehlersuche in der Logging-Datei /var/log/mail.log.

Quellen

• https://workaround.org/ispmail/jessie/spamassassin
• https://workaround.org/ispmail/stretch
• https://thomas-leister.de/mailserver-unter-ubuntu-16.04
• https://thomas-leister.de/mailserver-debian-stretch
• https://serverfault.com/questions/512219/dovecot-lmtp-does-not-exist
• https://serverfault.com/questions/658703/postfix-%E2%86%92-dovecot-lmtp-user-does-not-exist-uiddomain
• https://serverfault.com/questions/783401/how-to-get-spamassassin-working-with-postfix-as-a-milter
• https://wiki.dovecot.org/LMTP
• https://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration
• http://sieve.info
• https://linux.die.net/man/1/swaks

Am 22.05.2019 möchte das openSUSE Projekt die nächste Minor-Version seiner stabilen Variante Leap veröffentlichen. Durch Leap hat openSUSE wieder einen festen Platz in meinem persönlichen Distributions-Repertoire gewonnen, weshalb es dringend Zeit wird einen Blick auf die Änderungen der kommenden Version zu werfen.

Leap und Tumbleweed sind die komplementären Veröffentlichungen von openSUSE. Während Tumbleweed als Rolling-Release Distribution konzipiert ist und die fortlaufenden Entwicklungen in der Linux-Communty widerspiegelt, ist Leap auf Stabilität ausgerichtet. Jede Hauptversion von Leap wird ca. 3 Jahre mit Updates versorgt. Die aktuell veröffentlichte Minorversion mindestens 18 Monate lang. Das System von Haupt- und Minorversionen kennt man von anderen Enterprise-Distributionen wie RHEL/CentOS.

Große Veränderungen erfolgen immer nur mit den Hauptversionen, während die Minorversionen lediglich der Produktpflege dienen und selektive Updates einspielen. Es sind daher keine systemumstürzenden Änderungen für diese Version zu erwarten.

Versionen

Basisversionen

OpenSUSE Leap übernimmt, wie auch die Vorgängerversion, einen großen Kernbestand an Paketen von SUSE Linux Enterprise 15. Hier integriert man nun die SP1 der Enterprise-Variante. Die neue Version basiert daher auf dem bereits recht abgehangenen Kernel 4.12. Hier nutzt man die gleiche Version wie in Leap 15.0. Hinzu kommt allerdings das neue Mesa 18.3.

Desktop

Im Desktopbereich bleibt man ebenfalls bei KDE Plasma 5.12, was aber der aktuelle LTS-Desktop des KDE Projekts ist. Bei GNOME bleibt man mit Version 3.26 ebenfalls bei der vorherigen Version. Einzug hält hingegen MATE 1.20. Nichts neues gibt es bei Xfce und LXDE, beide Projekte sind jedoch auch Upstream fast tot. OpenSUSE Leap folgt also dem bewährten Prinzip aktuelle Desktopversionen mit einer LTS-Basis zu verknüpfen.

Programme

Das Paket wird komplettiert durch KDE Applications in der aktuellen Version 18.12, LibreOffice 6 und viele weitere Programme. Die Paketquellen sind nicht so umfangreich wie bei Debian und Ubuntu, aber es gammeln durch den Releaseprozes von openSUSE auch deutlich weniger ungepflegte Programmleichen in diesem herum.

Neuerungen

Die Versionen deuten bereits an, dass es mit openSUSE Leap 15.1 keine Überraschungen gibt. Von zaghaften Versionsaktualisierungen abgesehen gibt es lediglich kosmetische Neuerungen.

Die Installationsroutine zeigt nun auf der linken Seite, wo man sich im Prozess befindet. Das ist ziemlich praktisch.

YaST hat zudem ein neues Icon-Set spendiert bekommen, dass sich an Breeze anlehnt.

Programmauswahl

Frühere Versionen von openSUSE zeichneten sich durch eine teils widersprüchliche Standard-Programmauswahl aus. Teilweise auch unabsichtlich durch zirkuläre Abhängigkeiten der Pakete. Hier hat man deutlich aufgeräumt! OpenSUSE liefert zwar noch immer einen umfangreichen Desktop aus, aber z. B. digiKam und GIMP sind nicht mehr im Standardumfang. Im Unterschied zu Debian oder Ubuntu kann man hier aber in der Installationsroutine bereits eine individuelle Auswahl treffen.

Fazit

OpenSUSE Leap läuft sehr stabil, tendiert aber zunehmend dazu Neuerungen im Linux-Umfeld erst nach einiger Zeit zu integrieren. Letzte Unstimmigkeiten werden in der Betaphase sicher noch beseitigt. Leap bietet weiterhin einen konventionellen Linux-Desktop ohne ideologischen Überhang wie bei den puristischen KDE oder GNOME-Implementierungen, die z. B. KaOS oder Fedora ausliefern.

Trotz der abgehangenen Basis liefert man einen funktionalen Desktop ohne Überraschungen für den Anwender. Viele werden genau dies an openSUSE Leap schätzen.

OpenSUSE Leap hat bei mir sowohl als Server, wie auch für Desktopsysteme und virtuellem Maschinen einen festen Platz - Leap 15.1 wird daran nichts ändern, aber die Neuerungen sind so gering, dass es auch nicht sofort im Mai oder Juni auf alle Geräte muss. 

Bilder:
Einleitungs- und Beitragsbild von stevepb via pixabay

Nicht alles lässt sich mit Kalendereinträgen und Aufgabenlisten verwalten. Manche Inhalte werden auch einfach in Notizen fest gehalten. Diese möchte man natürlich möglichst immer dabei haben, daher bietet sich hier eine Synchronisation an. Nextcloud und QOwnNotes machen es möglich.

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

Für Nextcloud existiert die offizielle App Notes. Diese lässt sich via App Store aus der Kategorie Büro & Text installieren. Die Oberfläche ist so minimalistisch gehalten, dass sich hier nicht mal ein Screenshot lohnt. Man kann lediglich einzelne textbasierte Notizen in unterschiedlichen Ordner einsortieren.

Als Desktop-Anwendung bietet sich hier QOwnNotes an. Für Ubuntu kann man wahlweise ein Snap installieren oder ein PPA einrichten. Der Einfachheit halber wird hier die Installation via Snap gezeigt:

$ sudo snap install qownnotes

Die Synchronisation erfolgt über einen Ordner Notes im Nextcloud-Verzeichnis. Aus diesem Grund ist es wichtig den Client zu nutzen und nicht die WebDAV-Anbindung (siehe auch: Cloud in Eigenregie IV: Dateien über die Cloud verwalten). Dies lässt sich auch an einem anderen Ort ablegen, weshalb QOwnNotes beim ersten Start fragt, wo die Notizen gespeichert werden soll. Änderungen hier müssen natürlich auch in der Nextcloud-App vorgenommen werden.

QOwnNotes basiert auf Qt5 und integriert sich dadurch eher mittelmäßig in einen GTK-basierrten Desktop wie GNOME. Hier sind KDE Plasma-Anwender optisch deutlich im Vorteil. QOwnNotes hat verschiedene Layout-Optionen. Es gibt ein minimales Layout, das nur eine Übersicht der Notizen und ihrer Inhalte bietet und ein vollständiges Layout mit allen möglichen Inhalten. Standardmäßig ist das minimale Layout aktiviert.

Das vollständige Layout bietet hier deutlich mehr Informationen, ist aber auch weniger Übersichtlich.

Mit QOwnNotes lassen sich auch Medien wie z. B. Bilder in Notizen einfügen. Diese werden dann in einem Medienordner abgelegt und synchronisiert. Für Android und iOS existieren Apps, damit man die Notizen auch mobil dabei hat. Diese sind funktional allerdings etwas beschränkter, weshalb in QOwnNotes erstellte Notizen vielleicht nicht vollständig angezeigt werden können.

Trotzdem bietet die Kombination aus Nextcloud Notes und QOwnNotes eine mächtige Kombination um Notizen über die eigene Cloud für verschiedene Systeme zu synchronisieren.

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

Podcasts sind längst im Mainstream des Internets angekommen. Die wenigsten Anwender sitzen allerdings am heimischen Rechner wenn sie die neueste Folge eines Kanals hören. Ähnlich wie bei RSS Feeds möchte man den aktuellen Hörstand der eigenen Bibliothek über die verschiedenen Endgeräte synchronisieren.

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

Podcasts funktionieren faktisch einen Feed, der einzelne Audiodateien bereit stellt. Die meisten Betreiber von Podcasts hosten diese selbst und verteilen die aktuellen Folgen an ihre Hörer. In Deutschland werden Podcasts meist über drei große Plattformen bekannt gemacht (wobei diese teilweise auch nur Frontends für die Streams der Betreiber sind): iTunes (Apple), Audible (Amazon) und Spotify.

Das einzige gute Programm für Podcasts unter Linux ist eigentlich Vocal. Alle anderen Programme haben die Anmutung der 90er oder sind lieblos an einen Multimedia-Player angedockt. Vocal integriert die iTunes Bibliothek, wodurch sich eigentlich fast jeder Podcasts leicht finden und abonnieren lässt. Die Oberfläche ist ansprechend und beinhaltet alle relevanten Funktionen.

Eigentlich ist Vocal somit eine sehr gute Podcast-App für den Linux-Desktop. Leider bietet Vocal keine Synchronisationsfunktion. Man kann lediglich die Feed-URLs als OPML-Datei exportieren. Der Abgleich muss daher mit einem Feed Reader erfolgen (siehe auch den vorherigen Teil: Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren). Das ist weder besonders praktisch, noch wirklich intuitiv, da die meisten Feed Reader einen textbasierten Fokus haben.

Podcasts und Linux sind somit eine offene Baustelle.

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

RSS Feeds haben einen altmodischen Ruf, sind aber das einzige Medium über das man selbstbestimmt und ohne Überwachung Nachrichten konsumieren kann (siehe auch: RSS Feeds - Keine Fremdsteuerung, keine Auswertung). Nachrichten liest man heute auf dem Smartphone, Tablet oder am PC. Es ist daher unumgänglich die Sammlung und den Lesestatus über die Geräte hinweg zu synchronisieren.

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

Die Synchronisation von Feeds mit lokalen Geräten setzt einen Serverdienst und ein installiertes Programm voraus. Die bekannteste Serverlösung für RSS Feeds ist Tiny Tiny RSS für das zahllose Programme auf allen möglichen Plattformen existieren. Gegen TTRSS spricht eigentlich gar nichts, aber die Prämisse dieser Artikelserie ist ein möglichst niedrigschwelliger Einstieg in eine umfassende Cloudintegration für den Linux Desktop. Die vorherigen Artikel bauten alle auf eine Nextcloud-Lösung auf und dies soll hier weiterverfolgt werden. Daher geht der folgende Artikel nicht auf TT RSS ein.

Für Nextcloud gibt es lediglich eine Lösung für RSS-Feeds: News. Diese lässt sich über den integrierten App Store in der Rubrik Multimedia suchen und installieren. Beim ersten öffnen der App zeigt diese unter dem Menüpunkt entdecken einige Empfehlungen aus dem Technikbereich. Man kann aber auch eine bestehende Sammlung im OPML Format importieren. Die Oberfläche ist recht spartanisch gehalten und zeigt im wesentlichen einen Feed an ohne zusätzliche Funktionen oder die Möglichkeit direkt zwischen Artikeln zu springen.

Daher empfiehlt es sich auf ein Programm auszuweichen, das mehr funktionen bietet und die Daten mit der Nextcloud-Instanz abgleicht. Für den Linux-Desktop gibt es hier nur eine einzige Lösung, weshalb die Wahl nicht schwer fällt: FeedReader

FeedReader gehört zu jenen tollen Apps, die aus dem Umfeld von elementaryOS stammen. Daher ist er für GTK-basierte Desktops optimiert und integriert sich optisch auch sehr gute in GNOME. Leider hat es die Software bisher in wenige Distributionen geschafft. Debian und Ubuntu haben sie zwar inzwischen im Testing bzw. STS Bereich, aber noch nicht in den stabilen Veröffentlichungen. Für andere Distributionen wie openSUSE gibt es nicht mal das. Die Entwickler empfehlen offiziell Flatpak-Pakete für diese Distributionen. 

Dies steht unter Ubuntu nicht standardmäßig zur Verfügung, weshalb wir dieses nach installieren müssen. Die Version in den Paketquellen ist zudem so veraltet, dass damit Feed Reader nicht funktioniert. Daher benötigen wir die Flatpak-Version aus dem PPA.

$ sudo add-apt-repository ppa:alexlarsson/flatpak

$ sudo apt update

$ sudo apt-get install flatpak

Anschließend benötigt man noch das FlatHub Repo.

$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Anschließend installiert man Feed Reader aus dem eben eingerichteten Repo.

$ flatpak install flathub org.gnome.FeedReader

Sofern dies das erste Flatpak auf dme System ist muss erst noch die entsprechende Laufzeitumgebung eingerichtet werden. Dies geschieht automatisch, nimmt aber Zeit und Speicherplatz in Anspruch.

Weil die Flatpak Integration bei Ubuntu nicht immer gut funktioniert muss man das Programm ggf. über die Kommandozeile starten.

$ flatpak run org.gnome.FeedReader

Wenn also der Launcher-Eintrag fehlt, kann man diesen bei Bedarf aber generieren.

Beim ersten Start fragt das Programm ob es lediglich lokal arbeiten oder die Daten mit einem Dienst synchronisieren soll. Hier gibt es einige Dienste zur Auswahl, unter anderem auch das eingangs erwähnte TT RSS, aber in diesem Fall wählt man natürlich Nextcloud News.

Anschließend gibt man die URL und Zugangsdaten der Nextcloud-Instanz ein. Bei TOTP ist wieder ein individuelles Passwort für FeedReader zu generieren. FeedReader präsentiert sich anschließend als aufgeräumtes Programm, das sich hervorragend in den Desktop integriert.

In den Einstellungen lässt sich der Synchronisations-Intervall festlegen und einige andere Einstellungen. Der Content Grabber ist hier besonders interessant, weil damit ein vollständiger Feed von Seiten mit gekürztem Feed abgeholt werden kann.

Mit Nextcloud und FeedReader erhält man eine Möglichkeit Nachrichten selbstbestimmt zu konsumieren und über die Endgeräte zu synchronisieren. Für alle verbreiteten und weniger verbreiteten mobilen Betriebssysteme existieren ebenfalls Sync-Clients.

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

Nachdem wir im dritten Teil unsere Demoanwendung fertiggestellt haben, werden wir nun installierbare Pakete für die unterschiedlichen Plattformen bauen.

Stellvertretend für Linux-Systeme werden wir ein Debian Paket bauen. Für Windows werden wir ein Squirrel-Paket bauen und für Mac OS eine ZIP-Paket.

Wer seine App in die App Stores der jeweiligen Plattform bringen will, kann dies auch mit electron-forge machen.

Die Dokumentation gibt ausführlich Auskunft über die Möglichkeiten, wie man seine Pakete bauen kann und man sie auch gleichzeitig veröffentlichen kann.

Vorbereitung

In der package.json geben wir unserer Demo-App eine ordentliche Beschreibung und legen fest, dass wir für Linux nur ein Debian-Paket erstellen möchten.

Darüber hinaus geben wir Anwendungsdatei einen Namen und definieren den Pfad zum App-Icon.

"description": "Rebuild of the gtk3-demo-application with electron",
...
 "linux": [
    "deb
]
...
"electronPackagerConfig": {
  "packageManager": "yarn",
        "executableName": "electron-react-example",
        "icon": "./icon.svg"
}
...

Da unser Anwendungsname electron im Namen hat müssen wir die Abfrage für den Entwicklungsmodus ein ganz wenig anpassen. In der index.js fragen wir deswegen nicht nur, ob der Fahrt zur Anwendungsdatei electron enthält, sondern das electron ein Unterverzeichnis ist.

const isDevMode = process.execPath.match(/[\\/]electron[\\/]/);

Nun können wir mit unserem Linux-Build anfangen.

Linux-Build

Als Icon für die Anwendung habe ich mir von openclipart.org ein einfaches Icon heruntergeladen. Grundsätzlich reicht uns hierfür jegliche SVG- oder PNG-Datei.

Für den Linux-Build legen wir in der package.json dann unter electronInstallerDebian Werte für das Icon und die Kategorie fest.

...
"electronInstallerDebian": {
        "icon": "./icon.svg",
        "categories": [
          "Utility"
        ],
        "homepage": "https://foo.com"
      },
...

Nun können wir in der Kommandozeile mit electron-forge make unsere Anwendungen bauen. Wenn alles gut gegangen ist findet man unter out/make das Debian-Paket.

Mac OS-Build

Für den Mac-Build habe ich mir in einer virtuellen Maschine das Repo geklont und unser Icon in das icns-format konvertiert.

In der Kommandozeile habe ich dann mit NPM alle Abhängigkeiten installiert und dann wieder mit electron-forge make den Build angestoßen. Mehr war nicht notwendig.

Am Ende sollte eine ZIP-Datei stehen, die eine ausführbare Anwendung enthält.

electron-forge bietet auch die Möglichkeit DMGs für den Mac zu erstellen.

Windows-Build

Als Vorbereitung für den Windows-Build habe ich unser Icon diesmal in eine ico-Datei konvertiert. Dann habe ich wieder mit electron-forge den-Build in einer virtuellen Maschine angestoßen. Mehr ist auch hier nicht nötig.

Grundsätzlich ist es auch möglich electron-Pakete mit Wine zu bauen. Allerdings ist in der aktuellen Version von electron-forge diese Funktionalitäten nicht eingebaut. Wer trotzdem unter Linux Windows-Pakete bauen will, sollte sich das Paket electron-packager einmal anschauen.

Wir haben jetzt mit geringem Aufwand Pakete für alle bekannten Plattformen gebaut. Damit endet unser Tutorial. Ich hoffe ich konnte zeigen, dass Electron mit React eine interessante Alternative ist, wenn man plattformübergreifende Desktop-Applikation bauen möchte. 

electron-react-example für Ubuntu

electron-react-example für Mac OS

electron-react-example für Window

Unsere Anwendung passt sich gut in allen Umgebungen ein, ist mit Web-Technologien umgesetzt und hat keine externen Abhängigkeiten.

Du findest den Source-Code für dieses Tutorial auf Github: https://github.com/rockiger/electron-react-example

Created with Dictandu

The post Cross-plattform Apps mit Electron und React Teil 4 appeared first on Rockiger.

In einem bei heise online veröffentlichten Artikel ist zu lesen, dass das Verzeichnis „/.well-known/“ ein beliebtes Malware-Versteck auf gehackten Webservern ist. Der heise-Artikel empfiehlt Admins, den Inhalt von „/.well-known/“ und ggf. weiterer Unterverzeichnisse von Zeit zu Zeit zu prüfen. Um dies nicht manuell tun zu müssen, biete ich mit diesem Artikel ein Tutorial, das beschreibt, wie man diese Aufgabe mit Hilfe von systemd.path-Units automatisieren kann.

Ziel ist es, dass das System in dem Fall, dass sich der Verzeichnisinhalt von „/.well-known/“ oder eines darin enthaltenen Unterverzeichnisses ändert, eine E-Mail mit einem aktuellen Verzeichnis-Listing an eine konfigurierte E-Mail-Adresse sendet.

Voraussetzungen

Um diesem Tutorial folgen zu können, muss das betrachtete System

• systemd als Init-System verwenden und
• in der Lage sein, E-Mails zu versenden.

Darüber hinaus werden Kenntnisse in der Bearbeitung von Dateien mit einem Texteditor im Terminal vorausgesetzt.

Hinweis: Das Tutorial wurde mehrfach erfolgreich unter Ubuntu Bionic getestet. Der Leser Daniel hat versucht es unter Ubuntu Xenial nachzuvollziehen, was jedoch nicht geglückt ist. Details dazu finden sich in den Kommentaren zum Artikel.

Erstellung der Path-Unit

Im Verzeichnis /etc/systemd/system/ wird die Datei beispiel.path mit folgendem Inhalt erstellt. Der Dateiname kann selbstverständlich frei gewählt werden. Er muss lediglich auf .path enden.

[Unit]
Description="Meine '/.well-known/' Verzeichnisse auf Änderungen hin überwachen"

[Path]
PathModified=/var/www/site1/public/.well-known/
PathModified=/var/www/site1/public/.well-known/acme-challenge/
PathModified=/var/www/site2/public/.well-known/
PathModified=/var/www/site2/.well-known/acme-challenge/
PathModified=/var/www/site3/public/.well-known/
PathModified=/var/www/site3/public/.well-known/acme-challenge/
Unit=beispiel.service

[Install]
WantedBy=multi-user.target

In obigem Beispiel wird davon ausgegangen, dass der Webserver drei verschiedene Seiten ausliefert, die jeweils über ein eigenes „/.well-known/“-Verzeichnis mit jeweils einem Unterverzeichnis verfügen.

In der Sektion [Path] wird mit PathModified= der absolute Pfad zu den zu überwachenden Verzeichnissen spezifiziert, während Unit= angibt, welche Service-Unit ausgeführt werden soll, wenn sich der Inhalt eines der spezifizierten Verzeichnisse ändert. Diese Unit soll gestartet werden, wenn sich das System im Multi-User-Mode befindet.

Erstellung der Service-Unit

Als nächstes wird die auszuführende Service-Unit erstellt. Diese sollte den gleichen Namen wie die Path-Unit haben, im Unterschied zu dieser jedoch auf .service enden. Die Datei beispiel.service wird ebenfalls im Verzeichnis /etc/systemd/system/ erstellt.

[Unit]
Description="Führt Skript aus, wenn eine Datei sich geändert hat."

[Service]
Type=simple
ExecStart=/home/oglattermann/skript.sh

[Install]
WantedBy=multi-user.target

In der Service-Unit wird definiert, was getan werden soll, wenn die dazugehörige Path-Unit ausgelöst wird. In diesem Beispiel soll das hinter ExecStart= angegebene Skript ausgeführt werden.

Erstellung des auszuführenden Skripts

Findet eine Änderung in einem der überwachten Verzeichnisse statt, wird folgendes Skript ausgeführt:

#!/bin/bash
MAIL_TEXT="/tmp/well-known"
MAIL_RCP="foo@example.com"
create_mail() {
cat >"${MAIL_TEXT}" <<EOF
Achtung, der Inhalt der '/.well-known/'-Verzeichnisse wurde verändert. Die Verzeichnisse haben aktuell folgenden Inhalt:

$(find /var/www/ -type d -name ".well-known" -exec ls -lRa {} \;)
EOF
}

send_mail() {
    /usr/bin/mailx -s 'Achtung: Inhalt von /.well-known/ geändert' ${MAIL_RCP} <"${MAIL_TEXT}"
}

create_mail
send_mail

Das obige Skript ist abends auf dem Sofa entstanden und erhebt nicht den Anspruch schön oder perfekt zu sein. Es erfüllt jedoch seinen Zweck und sendet eine E-Mail an eine angegebe Empfangsadresse. In der Mail werden alle „/.well-known/“-Verzeichnisse inkl. enthaltener Dateien und Unterverzeichnisse aufgelistet, welche sich innerhalb des Suchpfads /var/www befinden.

Die Überwachung scharf schalten

Um die Überwachung zu aktivieren, sind noch die folgenden Schritte mit root-Rechten auszuführen:

1. Die Units zu aktivieren
2. Die Path-Unit zu starten

sudo systemctl enable beispiel.path beispiel.service
sudo systemctl start beispiel.path

Zum Test kann man nun eine neue Datei oder ein Verzeichnis in einem der überwachten Pfade erstellen. Daraufhin, sollte man eine E-Mail erhalten, welche über die Änderung informiert.

Ein Hinweis zum Schluss

Erwähnt werden muss, dass nur Änderungen signalisiert werden können, die vom Kernel ausgeführt werden. Führen andere Maschinen auf per Netzwerk eingebundenen Pfaden Änderungen durch, wird das nicht signalisiert.

https://www.my-it-brain.de/wordpress/unit-typ-systemd-path-kurz-vorgestellt/#comment-1624

Quellen und weiterführende Links

• https://www.my-it-brain.de/wordpress/unit-typ-systemd-path-kurz-vorgestellt/
• systemd.unit(5)
• systemd.path(5)
• systemd.service(5)

Mozilla hat eine neue Schaltfläche zur Oberfläche von Firefox 67 hinzugefügt. Neue Nutzer werden darüber auf die Synchronisations-Funktion von Firefox aufmerksam gemacht, bestehende Sync-Nutzer erhalten über diesen Button Zugriff auf alle wichtigen Synchronisations-Funktionen.

Beim Start von Firefox 67 fällt in der Navigations-Symbolleiste von Firefox eine neue Schaltfläche auf. Wer noch nicht Lesezeichen, Chronik und Zugangsdaten synchronisieren lässt, wird hierüber auf das Synchronisations-Feature von Firefox aufmerksam gemacht und gelangt direkt zur Anmeldung.

Wird bereits Firefox Sync genutzt, dann erscheint anstelle des allgemeinen Icons das Avatar des Nutzers als Schaltfläche. Darüber stehen dem Nutzer verschiedene Funktionen in Zusammenhang mit Firefox Sync zur Verfügung.

Konkret kann der Nutzer hierüber Tabs an ander Geräte senden, Tabs von anderen Geräten öffnen, die Sidebar mit den Tabs von anderen Geräten anzeigen, ein weiteres Gerät mit Firefox Sync verbinden, die Einstellungen des Firefox Accounts öffnen, die Synchronisations-Einstellungen von Firefox öffnen sowie die Synchronisation der Daten manuell anstoßen.

Wer die neue Schaltfläche nicht braucht, kann diese natürlich wie jede andere Schaltfläche auch von der Firefox-Oberfläche entfernen, entweder über Menü > Anpassen oder per Rechtsklick auf die Schaltfläche und Auswahl des entsprechenden Menü-Eintrags.

Der Beitrag Firefox 67 bekommt neuen Sync-Button erschien zuerst auf soeren-hentzschel.at.

Digital Signage oder „Digitale Beschilderung“ bietet auch für Schulen neue Möglichkeiten. Was früher mit Aushängen an sogenannten „schwarzen Brettern“ oder Informationstafeln gelöst wurde, wird zunehmend von Monitoren übernommen. Egal ob Hinweise zu kommenden Veranstaltungen, Vertretungspläne, Raumbeschilderung oder sonstige wichtige Informationen – vieles lässt sich flexibler auf Monitoren darstellen. Aktualisierungen kann man von zentraler Stelle aus vornehmen bzw. auch automatisieren (z.B. beim Vertretungsplan). Welche Open Source Digital Signage Lösungen gibt es? Was könnten Anforderungen sein, die man als Schule hat? Ich möchte heute einige Lösungen auflisten, die in späteren Artikeln noch einmal genauer beleuchtet werden sollen.

Was sollte ein Digital Signage System können?

Die Anforderungen werden sicher von Schule zu Schule verschieden sein, aber es gibt doch ein paar wesentliche Eigenschaften, die von einer Open Source Digital Signage Lösung erfüllt sein sollten:

• einfach zu benutzen (z.B. Editor zum Erstellen von Folien / Slides)
• einfache und schnelle Darstellung von Bilder, Videos und anderen Dokumenten
• zentrale Verwaltung mehrerer Monitore (am besten mit verschiedenen Gruppen / Kanälen, um verschiedene Informationen auf verschiedenen Monitoren anzeigen zu können)
• Möglichkeiten zur Automatisierung / Zeitplan
• möglichst kostenfrei (Lizenzen oder monatliche Gebühren)

Welche Open Source Digital Signage Lösungen gibt es?

Wenn man sich nach Open Source Digital Signage Lösungen umschaut, wird man schnell fündig. Allerdings sind viele von den sogenannten „Open Source“ Lösungen eher Freemium – Lösungen bzw. nur teilweise Open Source. Ich habe keine dieser Lösungen bisher selbst im Einsatz gehabt. In den kommenden Monaten werde ich mir aber einige dieser Lösungen anschauen, da wir als Schule noch auf der Suche nach einem passenden Digital Signage System sind.

Screenly OSE

Wenn auf Github nach Digital Signage schaut, ist Screenly OSE mit Abstand das populärste System. Screenly OSE ist für den Raspberry Pi konzipiert. Es bietet grundlegende Features, allerdings muss beim Einsatz mehrerer Geräte, jeder Raspberry Pi einzeln verwaltet werden. Die Unterschiede zur Bezahlversion sind hier aufgelistet.auch

Xibo

Direkt hinter Screenly OSE folgt Xibo, wenn man nach der Anzahl der Sterne auf Github geht. Xibo gibt es schon eine ganze Weile. Im Gegensatz zu Screenly gibt es keine Pro vs. Open Source Version, sondern alle Features sind für alle verfügbar. Xibo besteht aus einem CMS, welches man auch in einem Docker-Container installieren kann und den zugehörigen Player, die auf den Anzeigegeräten selbst installiert werden. Der Player für Windows ist kostenfrei und Open Source, für alle anderen Player müssen Lizenzgebühren bezahlt werden. Es gibt den Xibo Player für Windows, Android und webOS. Ein Player für Linux ist wohl geplant, aber noch nicht verfügbar.

Concerto

Ebenfalls schon länger am Markt ist Concerto. Concerto bietet viele Features und kann selbst gehostet werden. Technisch basiert es auf Ruby. Wenn man sich in dem Projekt auf Github etwas umschaut, scheint die Entwicklung etwas zu stocken. Dem Webinterface sieht man sein Alter auch schon etwas an. Insgesamt aber eine 100% Open Source Lösung.

LibreSignage

LibreSignage ist noch recht neue Open Source Lösung und zu 100%, Browser basiert. Es braucht also keine speziellen „Player“, sondern kann über den Browser benutzt werden. Grundlegende Features und auch Mehrbenutzerbetrieb sind vorhanden.

Foyer

Foyer ist ein WordPress-Plugin. Man kann damit verschiedene Seiten erstellen, Kanäle und verschiedene Displays diesen Kanälen zuweisen. Es ist wie LibreSignage Browser basiert und braucht deshalb keinen besonderen Player.

tabula.info

Tabula.info ist die einzige Lösung, die ich gefunden habe, die speziell für Schulen entwickelt wurde. Es bietet viele nette Features, die in man in einer Schule braucht und ist auf die Anzeige von Vertretungsplänen, HTML-Seiten und zusätzlichen Infos spezialisiert.

Weitere Lösungen

Infobeamer

Infobeamer ist nur für den privaten, nicht öffentlichen Gebrauch kostenfrei. Sonst ist wohl eine der leistungsstärksten und flexibelsten Lösungen. Die Hardware eines Raspberry Pi’s wird maximal ausgenutzt (z.B. Hardwarebeschleunigung – ein Nachteil, den alle Browser basierten Lösungen haben).

Display Monkey

Display Monkey ist ebenfalls eine Open Source Lösung, die allerdings einen Windows Server voraussetzt. Die einzelnen Displays brauchen nur einen Browser.

piSignage

Eine weitere Lösung für Digital Signage ist piSignage. Der Server ist OpenSource und kann auch selbst gehostet werden. Für die einzelnen Displays / Players müssen aber Lizenzen gekauft werden (einmalig). Wie der Name vermuten lässt, verwendet piSignage Raspberry Pi’s als Player. Der Code dafür ist nicht Open Source.

Fazit

Auf den ersten Blick gibt es scheinbar viele Open Source Lösungen. Welche kennst du noch, die hier fehlen? Mit welchem Systemen hast du gute Erfahrungen gemacht? Der Praxistest wird zeigen, welche Lösung für unsere Situation am besten geeignet ist.

Kommentar hinzufügen

Der Beitrag Open Source Digital Signage für Schulen erschien zuerst auf .:zefanjas:..