Mit den Fritzbox-Kabelroutern von AVM oder alternativ auch dem Fritz!WLAN Repeater DVB‑C als Zusatzgerät zu einem anderen WLAN-Router kann man recht einfach das Fernsehsignal in sein heimisches Netzwerk streamen. Als „Empfänger“ dienen Android- oder iOS-Geräte per App oder alternativ ein Desktop-PC oder Notebook. Auf Computern braucht es keine besondere Software, der Medienplayer VLC genügt. Der Vorteil: VLC gibt es für Linux, MacOS X sowie Windows. Der Nachteil: Die Bedienung (beispielsweise das Zappen von Sender zu Sender) ist ein wenig umständlich.

Ich für meinen Teil wünsche mir hingegen ein absolut simples TV-Programm: Ein Hauptfenster mit dem Fernsehbild. Eine Seitenleiste mit allen Kanälen. Per Doppelklick in das Bild wechselt man zwischen dem Fenstermodus und Vollbild — Mehr braucht es in der Regel nicht. VLC erfüllt diese Anforderung mehr oder weniger, bietet aber auch zig Funktionen, die beim Fernsehen brach liegen. Der Medienplayer Gnome MPV lässt sich hingegen mit wenigen Tricks in eine eigenständige TV-App für die Fritzbox verwandeln, die eben jene Anforderungen perfekt umsetzt.

Installation von Gnome MPV

Ein fertig gebautes Gnome MPV findet man inzwischen eigentlich immer in den Paketquellen, sofern man eine halbwegs aktuelle Linux-Distribution am Laufen hat. Alternativ liefert die Homepage des Projekts auch Hinweise für optionale Paketquellen für die gerade neueste Version, zudem gibt es auch ein Flatpak-Paket. In der Regel sollte es allerdings genügen die Version aus den Paketquellen der eingesetzten Distribution zu installieren.

### Installation unter Arch Linux
$ pacman -Ss gnome mpv
community/gnome-mpv 0.14-2
    Simple GTK+ frontend for mpv
$ sudo pacman -S gnome-mpv
### Installation unter Ubuntu
$ sudo apt search gnome mpv
Sortierung... Fertig
Volltextsuche... Fertig
gnome-mpv/testing 0.13-1 amd64
  simple GTK+ frontend for mpv
$ sudo apt install gnome-mpv

Nach der Installation kann man das Programm über den Eintrag Gnome MPV aus dem Anwendungsmenü heraus laden. Alternativ startet man das MPV-Backend des Players über das Kommando mpv einfach über ein Terminal. Diese Trennung zwischen GUI und Player kommt uns nachher gelegen, um Probleme beim Empfang des TV-Video-Streams der Fritzbox zu analyiseren.

MPV zum Fritzbox-Empfang überreden

Um das Fernsehsignal der Fritzbox aufzugreifen, braucht man die Senderliste im M3U-Format einer Playlist. Im Menü der Fritzbox öffnet man dazu DVB-C | Senderliste und lädt sich die Datei mit einem Klick auf Senderliste erzeugen auf die Festplatte. In VLC geöffnet, kann man über die Datei nun sofort die Sender streamen. Gnome MPV hingegen meldet beim Öffnen der M3U-Datei für jeden Sender einmal: Playback was terminated abnormally. Reason: unrecognized file format. was zu ein wenig Chaos auf dem Desktop führt.

Holt man sich die URL zu einem der Sender aus der M3U-Datei und versucht ihn mit der Kommandozeilenvariante des MPV-Players zu öffnen, erhält man eine ähnliche Nachricht (Ihr müsst diesen Schritt hier nicht nachvollziehen, er soll nur erklären, wie man auf die Lösung des Problems kommt.)

$ mpv "rtsp://192.168.188.82:554/?freq=314&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=0,16,17,18,20,100,101,84,102,103,104,105,106,1176,2070,2171"
Playing: rtsp://192.168.188.82:554/?freq=314&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=0,16,17,18,20,100,101,84,102,103,104,105,106,1176,2070,2171
[ffmpeg/demuxer] rtsp: CSeq 3 expected, 0 received.
[ffmpeg/demuxer] rtsp: method SETUP failed: 461 Unkown
[lavf] avformat_open_input() failed
Failed to recognize file format.

Mit dieser Ausgabe kann man nun allerdings ein wenig mehr anfangen, sodass man im Github-Forum des Players auf den Eintrag rtsp error 461 with freebox stream stößt. Die Lösung: Hängt man dem Aufruf die Option --rtsp-transport=udp an, öffnet MPV brav den Fernseh-Stream der Fritzbox.

$ mpv "rtsp://192.168.188.82:554/?freq=314&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=0,16,17,18,20,100,101,84,102,103,104,105,106,1176,2070,2171" --rtsp-transport=udp
Playing: rtsp://192.168.188.82:554/?freq=314&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=0,16,17,18,20,100,101,84,102,103,104,105,106,1176,2070,2171
[ffmpeg/video] mpeg2video: Invalid frame dimensions 0x0.
[...]
[ffmpeg/video] mpeg2video: Invalid frame dimensions 0x0.
[ffmpeg/demuxer] rtsp: Could not find codec parameters for stream 7 (Unknown: none ([12][0][0][0] / 0x000C)): unknown codec
[...]
AO: [pulse] 48000Hz stereo 2ch s16
VO: [gpu] 720x576 => 1024x576 yuv420p
AV: 00:00:08 / 00:00:13 (64%) A-V:  0.000 Cache:  4s+3MB

Gnome MPV als TV-App auf dem Desktop

Die Option kann man nun auch Gnome MPV mit auf dem Weg geben. Für noch mehr Komfort würde ich jedoch den Medienplayer gleich als TV-App im System fest verankern. Dazu lädt man sich von Google Play das Icon der Fritz-TV-App herunter und schiebt die Bilddatei nach ~/.local/share/icons ins eigene Home-Verzeichnis. Anschließend erstellt man die Datei ~/.local/share/applications/fritztv.desktop mit dem Inhalt aus dem folgenden Listing (aus der zweiten Listing-Box).

$ wget https://lh3.googleusercontent.com/P1hF9zUmQCU2JKtDu62at59m5Mgzdm03T_IhMovYemy43a0zQdso5J5Dfm2opHpN7w=s800 -O ~/.local/share/icons/avm-fritz-tv.png
$ gedit ~/.local/share/applications/fritztv.desktop

[Desktop Entry]
Type=Application
Name=Fritz TV
GenericName=TV Player for Fritz.Repeater
Comment=Play tv over network
Icon=avm-fritz-tv.png
Exec=gnome-mpv /home/benutzername/TV/tvsd.m3u --rtsp-transport=udp --deinterlace
Terminal=false
Categories=AudioVideo;Audio;Video;Player;TV;
X-KDE-Protocols=ftp,http,https,mms,rtmp,rtsp,sftp,smb

Beachtet bitte, dass in der Zeile Exec=[...] der vollständige Pfad zur M3U-Datei und der korrekte Dateiname stehen muss, passt die Zeile daher noch an eure Situation an. Ich persönlich hab die M3U-Dateien in einem Unterordner in meinen Home-Verzeichnis liegen. Der Zusatz --deinterlace sorgt neben der schon erklärten Option --rtsp-transport=udp für ein besseres Bild. Nach dem Speichern sollte nun ein zusätzlicher Eintrag mit dem Namen Fritz TV in eurem Anwendungsmenü auftauchen. Ein Klick auf das Icon lädt Gnome MPV mit allen von der Fritzbox angebotenen TV-Sendern und den passenden Einstellungen.

Alternativ könnt ihr die Einstellungen auch direkt in Gnome MPV eintragen. Öffnet dazu die Einstellungen und tragt im Reiter Allgemein ganz unten im Feld Weitere Optionen für MPV die Zeile --rtsp-transport=udp --deinterlace ein. So startet Gnome MPV automatisch immer mit den richtigen Eintellungen — allerdings auch dann, wenn ihr mit dem Programm „normale“ Videos abspielen wollt. Nutzt mal Gnome MPV nur als TV-Anwendung geht das klar, andernfalls würde ich den Weg über einen eigenen Eintrag im Anwendungsmenü gehen.

Wer mit einen Monitor oder ein Laptop mit einem HiDPI-Display anschafft, merkt schnell, dass man mit dem Gerät nicht mehr „wie gewohnt“ arbeiten kann. Schaltflächen, Icons und auch Texte erscheinen deutlich kleiner auf dem Schirm als bisher. Ist ja auch logisch: Wo vorher beispielsweise in Full-HD-Auflösung 1920 x 1080 Pixel auf den Bildschirm passten, entsteht das Bild bei QFHD, also 4K-Auflösung, aus 3840 x 2160 Pixeln. In beiden Richtungen finden sich also doppelt so viele Pixel wie bei einem klassischen Full-HD-Display. Dadurch schrumpft jedes Element auf dem Bildschirm (bei gleichbleibender Größe des Displays) auf die Hälfte seiner gewohnten Größe.

Damit man nun ohne Lupe mit so einem hochauflösenden Display noch unter Linux arbeiten kann, skaliert das Betriebssystem alle Inhalte einfach auf die doppelte Größe. Bei Schriften ist das kein Problem: Intern verrechnet das System eine 6-Punkt-Schrift einfach auf 12 Punkte hoch. Aber Bedienelemente und Icons müssen in einem Vektorformat vorliegen, das sich ohne hässliche Artefakte skalieren lässt. Klassische Bitmap-Icons würden vergrößert einfach nur schwammig und unscharf auf den 4K-Bildschirm aussehen. In der Regel sind die großen Desktops inzwischen auch soweit: Bei Gnome etwa lässt sich die Skalierung für jedes Display einzeln einstellen.

Unter Gnome gibt es allerdings ein Einschränkung zu beachten: Bislang kennt der Gnome-Desktop nur Stufen von 100 und 200 Prozent. Also „normal“ und doppelt so groß. Somit lässt sich der Desktop gut an „echte“ 4K-Displays anpassen, allerdings gibt es auch hochauflösende Monitore, die nicht mit einer 4K-Auflösung arbeiten oder ungewöhnliche Bildschirmgrößen nutzen. Ich hatte zum Beispiel einen Dell Precision M3800 mit QHD+ (also einer Auflösung von 3200 x 1880 Pixeln) oder einen ViewSonic VP2780-4K (der Monitor besitzt zwar ein 4K-Display, ist mit 27 Zoll aber deutlich größer als „normal“) im Test, bei denen die doppelte Größe einfach nicht zu einer befriedigen Darstellungsgröße auf dem Bildschirm führte.

Gnome mit krumme Skalierung für HiDPI-Displays

Gnome bräuchte daher dringend die Möglichkeit Texte und Bedienelemente um krumme Faktoren skalieren zu können. Anstatt also lediglich die Faktoren 1x oder 2x anzubieten, müsste auch alle Bildschirminhalte um 1,25 oder 1,5 und so weiter vergrößern können. Nun die good, die bad und die geht-doch-news: Daran wird bereits gearbeitet, allerdings hat es das Ergebnis noch nicht komplett in Gnome 3.26 geschafft. Die Funktion lässt sich allerdings von Hand in den Gnome-Settings freischalten. Dazu muss man lediglich ein Terminal öffnen und das folgende Kommando absetzen.

### Skalierungsfaktoren aktivieren
$ gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"
### Skalierungsfaktoren deaktivieren
$ gsettings set org.gnome.mutter experimental-features "[]"

Anschließend erscheinen unter Einstellungen | Geräte | Bildschirme mehr Skalierungsstufen. Dabei muss man allerdings beachten: Nur der Wayland-Fenstermanager Mutter unterstützt diese Funktion. Wer also Gnome unter X.org verwendet, muss auf diese Skalierungsstufen verzichten. Schlimmer noch: Bei mir auf einem aktuellen Arch Linux wollte Gnome unter X.org gar nicht mehr erst laden, nachdem ich den Schlüssel gesetzt habe. Nach dem Login hängte sich das System komplett auf. Merkt euch also, wie ihr diesen Schlüssel wieder aus den Gnome-Settings entfernen könnt. Die Funktion ist nicht ohne Grund noch nicht aktiviert.

Als Alternative habe ich die Gnome-Erweiterung Text-Scaler entdeckt. Mit diesem Add-On lässt sich der auf dem Bildschirm angezeigte Text in beliebigen Schritten skalieren. Zudem funktioniert die Erweiterung nicht nur mit Wayland, sondern auch auf dem klassischen X.org-Server. Allerdings kann man bei Multi-Monitorbetrieb nicht für jeden Bildschirm einen anderen Skalierungsfaktor wählen. Die Erweiterung ist also nach wie vor nicht für alle Situationen die optimale Lösung. Bleibt zu hoffen, dass die Gnome-Entwickler 4K- und HiDPI-Displays in Version 3.28 endlich optimal unterstützen.

Mit Firefox 57 ist Mozilla in meinen Augen mal wieder ein wirklich großer Wurf gelungen. Es erinnert irgendwie an die guten alten Zeiten, zu denen Firefox (damals noch unter dem Namen Phoenix) aus der Mozilla Suite aka Netscape Communicator abgespalten wurde. Auf einmal funktioniert das Surfen durchs Netz wieder wieselflink. Nach Jahren mit Chrome als Standardbrowser ist Firefox bei mir wieder der Browser der Wahl. Endlich mal wieder ein freier Browser, der richtig Spaß macht und nicht durch mangelnde Geschwindigkeit oder fehlende Funktionen stört.

Besonders gut finde ich, dass der Browser endlich das GTK-Theme der Desktopumgebung aufgreift. Schalter, Menüs oder Tabs sehen so aus, wie beispielsweise bei Gedit oder Nautilus. So ergibt sich ein schön stimmiges Bild auf dem Desktop — Chrome schafft das nicht. Das Erscheinungsbild lässt sich allerdings noch weiter verbessern: Gnome unterstützt „Client Side Decorations“ oder kurz CSD. Der Desktop kombiniert also Fenster- und Menüleiste zu einem Element. Bei einem aktuellen Gnome-Desktop sieht man das am besten bei aktuellen Gnome-Anwendungen wie beispielsweise Files (aka Nautilus) oder Gedit.

Client Side Decorations für Firefox

Firefox 57 unterstützt CSD ebenfalls, eventuell muss man die Funktion jedoch erstmal aktivieren. Dazu öffnet man about:config und sucht dann nach dem Schlüssel widget.allow-client-side-decoration, den man auf True ändert. Danach muss man den Browser einmal schließen und wieder neu starten. Eine Einschränkung gibt es allerdings: Nicht jede Linux-Distribution baut Firefox so, dass es diesen Schlüssel in der Firefox-Konfiguration gibt. Laut diesem Reddit-Thread funktioniert es nur unter Fedora oder OpenSUSE. Auf meinem System mit einem aktuellen Arch Linux taucht der Schlüssel nicht in der Firefox-Konfiguration auf.

Das wird sich in Zukunft mit Sicherheit ändern, wer unbedingt jetzt schon Clide Side Decorations bei Firefox sehen möchte und eine Distribution nutzt, deren Firefox die Funktion nicht unterstützt, kann sich alternativ die Firefox Nightly Build als Flatpak auf den Rechner holen. Am Beispiel von Arch Linux demonstriere ich das mal: Dazu installiert man den Flatpac-Paketmanager und spielt aus diesem das Firefox-Build ein. Beim ersten mal muss Flatpak wahrscheinlich noch eine Reihe von Abhängigkeiten installieren.

### Firefox Nightly als Flatpak installieren 
$ sudo pacman  -S flatpak
$ flatpak install --from https://firefox-flatpak.mojefedora.cz/org.mozilla.FirefoxNightlyCSD.flatpakref
### Firefox Nightly als Flatpak aktualisieren
$ flatpak update
### Flatpak-Pakete wieder deinstallieren
$ flatpak list
Ref Options 
org.mozilla.FirefoxNightlyCSD/x86_64/master system,current
org.gnome.Platform/x86_64/3.24 system,runtime
org.gtk.Gtk3theme.Adapta/x86_64/3.22 system,runtime
$ flatpack uninstall org.mozilla.FirefoxNightlyCSD/x86_64/master [...]

Anschließend erscheint Firefox im Anwendungsmenü doppelt: Einmal als klassischer Firefox und einmal als Firefox Nightly-Build — Gleichzeitig starten lassen sich die beiden Browser jedoch nicht. Allerdings ist es damit noch nicht ganz getan. Die Flatpak-Anwendungen greifen nicht das im System eingestellte Theme auf — da sie ja aufgrund der Sandbox nicht direkt auf das System zugreifen dürfen. Man muss sich daher erst einmal das passende Theme auch noch via Flathub organisieren. Eine Reihe von Gnome-Themes sind dort schon fertig paketiert. Für das Adapta-Theme lasse ich das mal im folgenden Beispiel durchlaufen. Das Theme steht nicht nur Firefox, sondern allen per Flatpak installierten Anwendungen zur Verfügung.

### Themes für Flatpak-Anwendungen installieren
$ flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
$ flatpak remote-ls flathub | grep org.gtk.Gtk3theme
org.gtk.Gtk3theme.Adapta                    
org.gtk.Gtk3theme.Adapta-Eta                
[...]
org.gtk.Gtk3theme.Pop                       
org.gtk.Gtk3theme.Pop-light                 
$ flatpak install flathub org.gtk.Gtk3theme.Adapta

Viele Linux-User nutzen ein Android-Handy, da sich das Google-System in der Regel ganz gut mit einem Linux-Desktop verträgt. Es gab auch immer wieder Projekte, die über einen einfachen Dateiaustausch hinausgehen. Viele von diesen werden jedoch nicht mehr wirklich aktiv weiterentwickelt. Gut unterstützt und nach wie vor mit Engagement ist jedoch nach wie vor das KDEConnect-Projekt. Dieses bindet Android so in das System ein, dass man vom Desktop aus auf die Daten des Handy zugreifen kann, sich SMS versenden lassen und die Benachrichtungen des Handys auf dem Desktop des PCs erscheinen.

Dank dem AppIndicator für KDE Connect funktioniert dies nicht nur mit KDE als Desktopumgebung, sondern auch mit anderen Desktops wie Xfce, LXDE oder natürlich auch Gnome. Allerdings gefällt mit persönlich besonders unter Gnome die AppIndicator-Krücke nicht wirklich. Von daher freut es mich besonders gestern Abend auf Reddit über die brandneue Shell-Erweiterung mit dem etwas sperrigen Namen KDE Connect/MConnect integration for Gnome Shell gestolpert zu sein. Sie bindet KDEConnect nahtlos in Gnome, sodass man direkt aus dem Desktop heraus auf sein Handy zugreifen kann.

Installation unter Arch

Aktuell gibt es die KDEConnect-Erweiterung noch nicht im „Shop“ für die Gnome Shell Extensions. Man muss die Erweiterung daher bislang noch selber bauen und von Hand einspielen. Auf einem Arch-System gelingt dies wie im folgenden Listing: Wobei ich von einem System mit installiertem Gnome als Desktopumgebung und den Gnome-Extras ausgehe. Die Installation erfolgt nach ~/.local/share/gnome-shell/extensions/mconnect@andyholmes.github.io in das eigene Homeverzeichnis, man benötigt also keine Root-Rechte und das System wird durch die Gnome-Erweiterung nicht verändert.

### Abhängigkeiten installieren (von Gnome als Desktop gehe ich mal aus)
$ sudo pacman -S kdeconnect meson
### KDE Connect/MConnect integration for Gnome Shell bauen und installieren
$ git clone https://github.com/andyholmes/gnome-shell-extension-mconnect.git
$ meson gnome-shell-extension-mconnect/ build
$ cd build
$ ninja install-zip

Anschließend müsste man die Erweiterung in den Gnome Tweak Tools aktivieren können. Zum Koppeln des Android-Handys muss man weiter jedoch auch noch die KDE Connect-App aus dem Google Play Store installieren. Über die Seitenleiste der Handy-App lässt sich dann das Verkuppeln von Desktop und Handy anwerfen, wobei eine Benachrichtigung auf dem Computer-Desktop erscheinen sollte über die man die Verbindung bestätigt. Die Shell zeigt dann in einem zusätzlichen Menü den Akkuzustand und weitere Funktionen an.

Über die Buttons lässt sich etwa eine SMS schreiben. Damit man die Namensvorschläge angezeigt bekommt, muss man seinen Google-Account in den Gnome Online Accounts eintragen. Zum Auffinden des Handys in denen eigenen vier Wänden gibt es eine Alarmfunktion, die das Handy klingeln lässt. Weiter lässt sich der Files-Dateimanager mit Daten des Handys öffnen, ohne dass man ein Kabel anstecken muss. Bei Bedarf kann man auch Daten auf das Android-Handy laden. Auch sollten die Benachrichtigungen des Android-Systems auf dem Desktop erscheinen.

KDE Connect für Gnome

Die Verknüpfung funktioniert jedoch auch in die andere Richtung. Über die App lässt sich die Maus bewegen oder die Tastatur übernehmen, zudem gibt es ein Modul mit dem man die Kommandos von Medientasten (also Play, Pause, Vorwärts oder Zurück) vom Android-Handy aus absetzen kann. Die Kommunikation zwischen Handy und Computer geschieht dabei verschlüsselt über das eigene Netzwerk, man muss also keine Angst haben, dass Fremde die Kontrolle über einen eigenen Rechner erlangen können.

KDE Connect für Android

1 of 4

Die Erweiterung unterstützt neben KDE Connect auch MConnect, eine Implementation des KDE-Connect-Protokolls in Vala/C — was für Gnome typischer wäre, sodass man sich die Installation der KDE-Bibliotheken und Abhängigkeiten von KDE Connect schenken könnte. Über MConnect stehen jedoch noch nicht alle Funktionen zur Verfügung, zudem geht die Entwicklung des Projekts laut Aussage des Entwicklers auf Reddit etwas träge voran. Aktuell ist man daher wohl mit KDE Connect besser bedient.

Vor ein paar Tagen sollte bei euch eigentlich Google Chrome 59 (beziehungsweise Chromium 59) über die Paketquellen auf eurem System eingetrudelt sein. Neben den üblichen Sicherheitsupdates steckt in der neusten Ausgabe von Chrome ein neuer Look: Die Einstellungen, die Adresszeile, der Verlauf und viele andere Elemente des Browsers nutzen nun Googles Material Design. Wer mit einem halbwegs aktuellen Android-Handy unterwegs ist, kennt das Aussehen schon von seinem Handy — Nicht jedem gefällt der neue Look, ich finde ihn persönlich ganz gelungen.

Für Linux-User sind allerdings zwei andere Neuerungen besonders relevant, die nicht direkt in der Ankündigung des Browser stehen: Zum einen nutzt Chrome/Chromium 59 nun endlich auch die native Funktion des Systems zur Darstellung von Benachrichtigungen. Zum anderen kommt die neuste Ausgabe des Browsers jetzt besser mit dunklen Desktop-Themes zurecht, sodass man in der Regel auf die Installation eines eigenen Chrome-Themes verzichten kann. Beide Neuerungen helfen von daher den Browser besser in den Linux-Desktop zu integrieren.

Die nativen Benachrichtigungen sind ab Chrome/Chromium 59 im Programm enthalten, allerdings noch nicht von Haus aus aktiv. Man muss daher von Hand via chrome://flags/#enable-native-notifications die Chrome-Flags aufrufen und die Option Enable native notifications auf Enabled umstellen. Danach verlangt der Browser einen Neustart. Anschließend könnt ihr die Funktion beispielsweise über diese Seite austesten: Über Authorize erlaubt ihr der Seite erstmal überhaupt Benachrichtigungen anzuzeigen, über Show blendet ihr dann eine Nachricht ein.

Chrome/Chromium 59 baut nun erstmals komplett auf GTK3. Die alten Bindungs zu GTK2 sind Geschichte, somit läuft die neuste Chrome-Ausgabe nicht mehr auf älteren Linux-Distributionen wie RHEL 6 oder CentOS 6, die durchaus aber noch vom Distributor mit Sicherheitsupdates versorgt werden und somit auch noch auf vielen Rechner in Betrieb sind. Mit der Build-Option use_gtk3=false gibt es jedoch nach wie vor einen Weg zumindest Chromium mit GTK2-Bindings zu bauen. Im Arch-Linux AUR gibt es bereits entsprechende Einträge. Ich vermute, dass es entsprechende Pakete auch für andere Linux-Distributionen geben wird oder schon gibt.

$ pacaur -Ss chromium gtk2
 [...]
 aur/chromium-gtk2 59.0.3071.86-1 (0, 0,00)
 A web browser built for speed, simplicity, and security (GTK2 version)

Mit dem Umstieg auf GTK3 kommt Chrome nun aber in meinen Augen auch besser mit dunklen Themes zurecht. Egal ob man nun die Option Titelleiste und Ränder des Systems verwenden in den Einstellungen des Browsers aktiviert oder nicht, Chrome fügt sich nun wieder ein kleines bisschen besser in den Linux-Desktop ein. Es gibt allerdings auch Regressionen: So funktioniert mit Chrome 59 das HiDpi-Scaling nicht mehr ordentlich. Aus Ermangelung eines entsprechend hochauflösenden Displays kann ich das hier gerade nicht selber nachvollziehen, an dem Bug wird allerdings bereits eifrig gearbeitet.

Kodi und ein Raspberry Pi genügen, um viele Ansprüche eines modernen Mediacenters abzudecken: Das Abspielen von HD-Inhalten, das Streamen von Inhalten aus Mediatheken und sogar ein PVR-Videorekorder mit EPG-Programmführer ist ohne große Probleme möglich. Wo es noch hängt, ist die Unterstützung von Videostreaming-Diensten wie Netflix, Amazone Prime oder Maxdome und Co. Hier hat zwar der Siegeszug von HTML5 für Linux-Kompatibilität gesorgt, allerdings nur in Browsern, die das Widevine-DRM dieser Dienste unterstützen. Das macht besonders dem Raspberry Pi Probleme, da unter Linux eigentlich nur Chrome die entsprechende Unterstützung enthält… und Chrome gibt es (theoretisch) nur für klassische PCs auf x86-Basis. Der Raspberry Pi mit seiner ARM-Architektur bleibt außen vor.

Nun gibt es aber Chromebooks, die ebenfalls auf einer ARM-CPU aufsetzen und unter Linux laufen. Google hat demzufolge Widevine-Binarys für ARM am Start, man muss Sie „nur“ aus dem System angeln und auf den Raspberry Pi portieren. Das klappt mehr oder minder gut: So funktionierte es beispielsweise schon einmal recht zuverlässig Amazon Prime Video unter LibreELEC auf dem Raspberry Pi zu nutzen, doch das DRM macht dem Ganzen immer wieder einen Strich durch die Rechnung — aktuell funktioniert diese Lösung nicht. Nun gibt es aber bei Phoronix gute Nachrichten, das Magazin berichtet, dass das LibreELEC-Team an einem Netflix-Plugin für Kodi arbeitet. Den Quellcode gibt es bereits bei Github, allerdings braucht es ein sehr aktuelles „agile build“ der Mediacenter-Software. LibreELEC-Entwickler Milhouse bestätigt in den Kommentaren zum Beitrag aber, dass das neue Netflix-Plugin auf einem Raspberry Pi 3 funktioniert.

The Netflix plugin works fine on Raspberry Pi3 with an early version of LibreELEC 9.0, however for Netflix to work it requires an (as yet) unreleased version of Kodi 18 (or build it yourself, from the „agile“ branch).

Man kann sich auch schon selbst ein Bild von dem neuen Netflix-Plugin für Kodu machen: Raybuntu hat bereits Images von LibreELEC 9.0 als Agile-Build für den Odroid C2, den Wetek Hub sowie die Play 2-Box von Wetek veröffentlicht, auf denen das Plugin funktioniert. Es gibt bereits auch schon ein Video, das die neue Funktion demonstriert, allerdings auf einer Wetek Play 2 (anscheinend unter Android) und nicht auf einem Raspberry Pi. Das Video zeigt allerdings eine Einschränkung, die wohl aber nach wie vor besteht: Der User spielt am Ende ein Netflix-Video ab, das in 1080p vorliegt. Kodi spielt es dann aber nur mit 720p ab. Die volle Auflösung lässt sich Netflix anscheinend nach wie vor nur mit einem „richtigen“ System entlocken. Die Nachricht zeigt aber, dass das mit Kodi 17 aka Krypton eingeführte InputStream-Backend Früchte trägt. Was mit Netflix tut, wird früher oder später (hoffentlich) auch mit Amazon Prime und anderen Streaming-Anbietern funktionieren.

UPDATE 22.3.2017: Ich nutze Kodi gerne und viel, doch ich bin auch kein Kodi-Entwickler und stecke auch nicht genau Inputstream, Widevine und Co. drinnen. Daher hatten sich in meinen Beitrag ein paar Unklarheiten sowie Fehler eingeschlichen. Raybuntu und asciidisco haben diese in den Kommentaren richtiggestellt, von daher möchte ich die zwei hier noch kurz zu Wort kommen lassen:

a) Es gibt keine Einschränkung auf 720p, 1080 mit 5.1 Sound sind Möglich, aber abhängig von der Leistungsfähigkeit der CPU, da man mit Widevine nur Software Decoding machen kann. Mit entsprechender Hardware also möglich. Eventuell sogar mal auf dem Raspberry Pi (3), aber da fehlen noch die Erfahrungswerte, dafür ist die Kiste noch zu „bleeding edge“.

b) Mit den Änderungen an dem Inputstream Plugin und dem, was in Kodi Agile implementiert ist, wird auch das Amazon Plugin wieder funktionieren. Das Problem mit Prime war, das ursprünglich die Widevine Bibliothek nur als Decrypter genutzt wurde, dann sich aber die Politik von Seitens Amazon änderte & Widevine nicht nur das decrypten, sondern auch das dekodieren übernommen hat. Damit konnte das Inputstream Plugin (und die Kodi Architektur),bis Dato, nicht umgehen. Das hat sich nun geändert, Kodi Agile hat die Nötigen Architektur Änderungen gebracht & das Inputstream Plugin wurde auch angepasst. Dort wo das Netflix Plugin läuft, läuft auch Amazon wieder.

c) Das Video wurde zwar wirklich auf einer Wetek aufgenommen, allerdings läuft diese nicht mit Android, sondern mit den Libreelec Agile Community Builds von Raybuntu (https://github.com/Raybuntu/LibreELEC.tv/releases). Das Plugin wurde schon lauffähig auf Windows, OSX, 64bit Linux & 32bit Userpace ARM Systemen (wie der Wetek oder dem Odroic C2) getestet. Für den Raspberry fehlen noch merges in Kodi Agile, das ist aber mehr eine Code Style Geschichte, als eine funktionale.

Wer unter Linux mit Terminix arbeitet, der hat ein leistungsfähiges Terminalprogramm an der Hand, das ein Fenster in mehrere Panel unterteilen kann, die sich per Drag&Drop arrangieren lassen. Das den Benutzer benachrichtigt, sobald länger laufende Prozesse enden und sich User mit etwas anderen beschäftigt und vieles mehr. Nun beschreiben normalerweise Einträge in einen Bugtracker ja Fehler im Programm. Bug 815 im Bugtracker von Terminix ist nun etwas außergewöhnlich: Das auf Schädlingsbekämpfung spezialisisierte Unternehmen Terminix befürchtet aufgrund der Namensgleichheit Probleme und forderte die Terminix-Entwickler auf den Namen zu ändern.

Von daher nennt sich Terminix in Zukunft Tilix. Die Homepage sowie das Github-Repository wurden bereits angepasst. Und auch im AUR, als dem Arch User Repository, gibt es bereits mit tilix und tilix-git zwei neue Einträge. Arch-User deinstallieren daher am besten die Terminix-Pakete und spielen dann Tilix via pacaur -S tilix neu ein (selbstverständlich kann man auch einen anderen AUR-Helper verwenden). Unter Ubuntu lässt sich Tilix aus dem PPA des WebUpd8-Blogs installieren. Auch hier heißt es daher Terminix deinstallieren und Tilix neu installieren. Nur so bekommt man in Zukunft das Programm dann auch aktualisiert, die Terminix-Pakete bekommen keine Updates mehr spendiert.

Terminix (oder besser nun Tilix) ist noch eine recht junge Anwendung, die sich aktuell auch noch ziemlich schnell verändert. Jede neue Version bringt eigentlich so gut wie immer neue und interessante Funktionen mit. Von daher findet man das Programm jedoch in der Regel auch noch nicht in den regulären Paketquellen seiner Lieblingsdistribution und wenn doch, dann nur in einer älteren Version. Von daher muss man das Programm meist über eine zusätzliche Paketquelle installieren, entsprechende Installationshinweise zu Tilix gibt es für diverse Distributionen auf der Homepage.

### Tilix unter Arch Linux installieren:
$ pacaur -S tilix
### Tilix unter Ubuntu installieren:
$ sudo add-apt-repository ppa:webupd8team/terminix
$ sudo apt update
$ sudo apt install tilix

Der Firefox-Browser verwendet bekanntlich mit XUL ein eigenes Toolkit, um die Oberfläche auf dem Bildschirm darzustellen. Aus diesen Grund passt sich Firefox auch nicht an das Theme der Desktopumgebung an. Für Gnome-User gibt es jedoch schon länger ein Adwaita-/Gnome-Theme, das den Browser gut in den Gnome-Desktop integriert. Das Problem: Das Theme wird schon seit einer ganzen Weile nicht mehr aktiv gepflegt. Es ist zu Firefox 45.0 bis 48.0a1 kompatibel, der Versionszähler von Firefox steht aktuell jedoch bereits bei Firefox 51. Im Github des Gnome Integration Team schlagen immer wieder User mit Fehlerberichten auf, dass das Theme nicht mehr funktioniert, eine Reaktion gab es bisher jedoch nicht.

Nun hat sich mit Nicholas Reis ein unabhängiger Entwickler der Sache angenommen. Sein Fork des Gnome 3 Theme für Firefox ist zur aktuellen Firefox-Version wieder kompatibel, zudem hat er eine Reihe von Bugs ausgebügelt. Zusammen mit den bereits etablierten Add-Ons Gnome Theme Tweak und HTitle (das trotz des Hinweises, dass das Add-On aufgegeben wurde, nach wie vor funktioniert) lässt sich somit Firefox wieder sehr gut an das offizielle Gnome-Theme anpassen. Aufgrund des Toolkits passt sich Firefox zwar weiterhin nicht an andere Gnome-Themes an, doch im Großen und Ganzen sieht der Mozilla-Browser so wieder unter Gnome deutlich besser aus.

Firefox-Theme für Gnome 3

Die Installation des Theme ist nicht weiter schwer: Installiert die folgenden 3 Add-ons beziehungsweise Themes. Anschließend ruft ihr über das Hamburger-Menü (der Button mit den drei übereinander gestapelten Strichen in der Toolbar) die Add-ons auf. In den Einstellungen zum Gnome Theme Tweak und HTitle lassen sich dann noch ein paar Konfigurationen ändern. So kann man beispielsweise die Ausdehnung der Tabs anpassen oder den Dropdown-Pfeil in der Adressleiste abschalten. Zudem lassen sich die Buttons „flach“ darstellen, also ohne einen Knopf um den Schalter herum.

• Gnome 3 Theme für Firefox
• Gnome Theme Tweak
• HTitle

Über HTiltle lässt sich sich die Fensterleiste deaktivieren, sodass möglichst viel Platz auf dem Bildschirm bleibt. In der Grundeinstellung passiert dies nur, wenn man das Fenster auf dem Desktop maximiert. HTitle lässt sich jedoch auch so einstellen, dass es die Fensterleiste komplett ausblendet. In diesem Fall lässt sich das Firefox-Fenster jedoch nur noch sehr schwer per Mausklick verschieben: Entweder muss man  nun immer eine der wenigen freien Stellen in der Toolbar finden oder das Fenster zukünftig mit [Super]+[Linke Maustaste] an einer beliebigen Stelle anpacken und dann auf dem Bildschirm verschieben.

Ein Bild sagt mehr als Tausend Worte, das Sprichwort dürfte wohl jeder kennen. Aber was sagt denn dann ein Video aus? Tausend Worte im Quadrat? Egal: In vielen Situationen erklärt ein kurzer Screencast (also das Abfilmen des Geschehens auf dem Desktop) ein Problem oder eine durchzuführende Aktion deutlich besser, als ein länger Text mitsamt Bildern. Von daher gibt es auch eine große Palette an Screencast-Apps: Von Simeple Screen Recorder bis Record My Desktop. Gegenüber diesen besitzt Peek kaum Funktionen, doch das kleine Programm will sich mit den „großen“ gar nicht messen. Es nimmt den Desktop als GIF auf und prodoziert so Videos, die sich leicht in Webseiten einbetten lassen.

Bei der Oberfläche hat sich Peek ganz bewusst am Screencast-Tool LICEcap für Windows orientiert: Das Programm blendet ein skalierbares transparentes Fenster ein, alles was in dessen Rahmen liegt, wird bei einem Klick auf Record beziehungsweise Aufnahme als Video erfasst. Nach einem Klick auf Stop sichert Peek das Ergebnis dann umgehend als animiertes GIF-Bild auf die Festplatte. „Richtige“ Videoformate unterstützt Peek bislang noch nicht, Support für WebM steht jedoch nicht nur auf der To-Do-Liste, der Code dafür ist bereits fertig und landet in der nächsten Version (aktuell steht der Zähler bei Peek 0.9.1).

Peek erstellte Screencasts als GIF

Die ersten Commits von Peek stammen aus dem Dezember 2015, seitdem wurde recht aktiv am Programm entwickelt. In den letzten zwei Monaten nahm die Entwicklung jedoch besonders viel Fahrt auf, über die Mailing-Funktion von Github kommen täglich News rein. Als noch recht junges Programm findet sich Peek noch nicht in den Paketquellen der großen Distributionen. Für Ubuntu gibt es jedoch eine PPA-Paketquelle, unter Arch Linux lässt sich die Anwendung recht einfach aus dem AUR installieren. Für andere Distributionen liefert Peek die entsprechenden Installationshinweise auf der Github-Seite.

### Peek unter Ubuntu installieren:
$ sudo add-apt-repository ppa:peek-developers/stable
$ sudo apt update
$ sudo apt install peek

### Peek unter Arch Linux installieren, natürlich
### könnt ihr einen anderen AUR-Helper verwenden:
$ pacaur -Ss peek
aur/peek 0.9.1-1 (20, 1,19)
$ pacaur -S peek

Aktuell funktioniert Peek nur mit X11: Wer also bereits ein aktuelles System mit Wayland einsetzen sollte, muss bei Start des Systems auf X11 umstellen. Ist diese Voraussetzung erfüllt, arbeitet es sich mit Peek sehr einfach. Programm starten, Rahmen ausrichten und den Screencast aufnehmen. Dabei sollte man beachten, dass animiertes GIFs natürlich für längere Aufnahmen nicht das perfekte Format sind. Um die Dateigröße im Rahmen zu halten, sollte man daher nur das aufnehmen, was es abzubilden gilt. Auch sehr viele Änderungen im Bild blähen die Dateigröße schnell enorm auf. Schon während Peek den Dateidialog zum Speichern des Screencasts anzeigt, baut das Programm im Hintergrund das animierte GIF zusammen, was die auf der CPU liegende Last nach oben jagt. Je nach Größe der Aufnahme dauert dieser Vorgang schnell bis zu ein paar Minuten.

Demnächst Support für Screencasts als WebM-Video

In Zukunft stehen für Peek noch eine ganze Reihe von Neuerungen an, die Enhancement-Liste auf Github listet noch viele Ideen auf. Die wichtigste Neuerung ist mit dem Support eines „richtigen“ Video-Formats wie WebM bereits umgesetzt (wie gesagt, sollte die Funktion mit der nächsten Version kommen), doch andere nützliche Funktionen wie die Möglichkeit die Aufnahme zu pausieren, einen Fensterpicker zur Auswahl des Aufnahmebereichs oder eine Fortschrittsanzeige beim Rendern der Aufnahme stehen noch auf der To-Do-Liste. Für die Zukunft wäre noch Wayland-Support wichtig, allerdings sieht es in dieser Richtung eher schlecht aus, da Wayland die dafür nötigen Funktionen nicht bietet. Die entsprechenden Bugs wurden in den letzten Tagen auf Wontfix gesetzt.

Eine der Stärken von Linux liegt in allgemeinem daran, dass das System seit Urzeiten als Mehrbenutzersystem konzipiert ist. User starten Anwendungen im Rahmen ihrer Benutzerrechte, sodass diese in der Regel nichts am System ändern können. Malware beeinträchtigt somit höchstens den Datenbestand des Users, der diese ausführt. Dennoch machen wir Linuxer immer wieder gerne ein Türchen auf: Sobald wir beispielsweise einen Editor mit Root-Rechten starten, etwa um eine Konfigurationsdatei zu bearbeiten, führen wir diesen mitsamt dem kompletten Toolkit (also GTK oder Qt) mit administrativen Rechten aus. Dadurch läuft mehr Code mit administrativen Rechten, als eigentlich nötig, daran ändert auch der Aufruf des Programms mit gksu oder gksudo nichts.

Sudoedit, das bessere sudo $editor

Das gilt nicht nur in einer grafischen Desktopumgebung, sondern auch für Editoren im Terminal. Wir rufen üblicherweise nano, vi, emacs und Co. mittels sudo nano /was/auch/immer komplett mit Root-Rechten auf. Dadurch müssen wir darauf vertrauen, dass sich der Editor nicht auf irgendeine Art und Weise missbrauchen lässt. Wenn man bedenkt, welche Funktionsfülle Vi oder Emacs mitbringen, birgt das Vorgehen durchaus ein Gefahrenpotential. Daher gibt es bereits seit 2004 mit sudoedit bzw. sudo -e ein Kommando, das dieses Problem umschifft.

$ sudo -e /etc/hosts
$ sudoedit /etc/hosts

Dabei kopiert Sudo die zu bearbeitende Datei erst einmal in ein temporäres Verzeichnis (unter Arch Linux nach /var/tmp), öffnet die Kopie dann im Kontext des Benutzers in den Editor und schiebt die temporäre Datei dann nach dem Schließen des Editors wieder an die ursprüngliche Stelle. Auf diesem Weg muss man den Editor selbst und damit alle mit angezogenen Bibliotheken nicht mehr mit Root-Rechten ausführen. Nur für das Kopieren der Dateien braucht es die administrativen Rechten.

$ VISUAL=gedit sudoedit /etc/hosts
$ EDITOR=nano sudoedit /etc/hosts

Mit den Umgebungsvariablen $VISUAL und $EDITOR lässt sich dem Kommando der gewünschte Editor mit auf den Weg geben, wobei $EDITOR für einen einfachen Editor wie etwa Nano oder Joe steht und $VISUAL mit einem Brocken wie Emacs oder Vi (oder grafischen Editoren wie Gedit oder Kate) belegt werden sollte — Sind beide Variablen definiert, zieht Sudo $VISUAL dem einfachen $EDITOR vor. Ich definiere „meine“ Editoren daher in der ~/.bashrc (den einfachen Editor) sowie in der ~/.xprofile (mit Gedit einen Editor in der GUI). Somit muss ich dann zum Bearbeiten einer Systemdatei nur noch sudoedit /foo/bar eingeben und öffne die Datei dann automatisch im „passenden“ Editor.

### Die Umgebungsvariablen $EDITOR und $Visual kann man beispielsweise
### über die ~/.bashrc oder 
$ grep EDITOR ~/.bashrc
export EDITOR=/usr/bin/joe
$ grep VISUAL ~/.xprofile
export VISUAL=/usr/bin/gedit
### Je nachdem ob man sich in einer grafischen Umgebung befindet, oder
### in einem virtuellen Terminal, startet sudoedit den Terminal-Editor
### Joe oder Gedit.
$ sudoedit /etc/hosts

Sudoedit gibt es nun schon seit 2004, aber kaum jemand nutzt diese Methode: Das Wiki der Ubuntuusers erwähnt das Kommando zum Beispiel mit keinem einzigen Wort und auch im Arch Wiki findet sich Sudoedit nur auf einer einzigen Unterseite — Damit ignorieren die in meinen Augen zwei besten Dokumentationen rund um Linux Sudoedit bisher fast komplett. In Sachen Root-Rechte in der grafischen Desktopumgebung hat mich allerdings ein aktueller Blogbeitrag von KDE-Entwickler Martin Grässlin auf etwas neues gebracht: Der Files-Dateimanager (aka Nautilus) beherrscht seit der Version 3.22 dank einer Neuerung in Gvfs (dem Gnome virtual file system) einen Administrator-Modus, der ähnlich wie Sudoeditor funktioniert.

Root-Rechte für Files aka Nautilus

Im Gnome-Dateimanager kann man ja mit [Strg]+[L] eine Adresszeile öffnen, über die sich Pfade eintippen lassen oder über die man durch Eingabe von smb://server/freigabe oder ssh://username@example.com Daten von entfernten Rechner direkt in den Dateimanger einbinden kann. Mithilfe von aktuellen Entwicklungen in Gvfs-admin und Polit gibt es nun aber auch eine Art Admin-Modus, diesen erreicht ihr über die Eingabe von admin:///pfad/zu/verzeichnis oder einfach nur admin:// ohne eine Pfadangabe. Über eine Maske fordert der Dateimanager danach eure Root-Rechte an und leitet euch entweder in das Wurzelverzeichnis des Systems oder den angegebenen Ordner weiter.

In diesem Modus könnt ihr beispielsweise nach /etc navigieren und dann die Hosts-Datei /etc/hosts in Gedit öffnen, bearbeiten und wieder abspeichern (mit abermaligen Eingabe eures Passworts). Dasselbe funktioniert mit allen anderen Konfigurationsdateien, die man mal schnell an die eigenen Wünsche anpassen möchte. Ihr könnt auch Verzeichnisse oder Dateien in geschützten Ordnern wie /, /etc oder /usr/local/bin anlegen, diese dann verschieben, wieder löschen oder die Benutzerrechte ändern. Sinnlos walten und schalten lässt euch Files jedoch in der Regel nicht: Dateien und Ordner, die dem Root-User gehören, die User der Root-Gruppe aber nur lesen und/oder ausführen dürfen (also Dateien und Ordner mit der Zuordnung root:root und den Rechten 644 oder 755) erscheinen mit einem Schloss-Symbol. Diese lassen sich dann beispielsweise nicht löschen oder ausschneiden.

In Sachen Root-Rechte in KDE wird sich demnächst einiges ändern: Martin hat in seinem Posting angekündigt, dass die KDE-Editoren Kate und Kwrite sich in Zukunft nicht mehr direkt mit Root-Rechten öffnen lassen. Stattdessen informieren die Programme, wie der User die gewünschte Datei mittels sudoedit in den ohne Root-Rechte gestarteten Browser bekommt. Dies wird mit Sicherheit den Workflow zahlreicher User beeinträchtigen (und wie die Kommentare schon zeigen, für Unmut in der KDE-Community sorgen), allerdings ist dieser Schritt zum Beispiel in Bezug auf Wayland sowieso überfällig.

Today I pushed a change for Kate and KWrite which does no longer allow to be run as root. Instead it educates the user about how to do the same with sudoedit.

Now I understand that this will break the workflow for some users. But with a minor adjustment to your workflow you get the same. In fact it will be better, because the Kate you start is able to pick up your configured styling. And it will also work on Wayland. And most importantly it will be secure.

Langfristig wäre dann das Ziel, dass KIO und PolicyKit die eigentliche Arbeit übernehmen. So könnte man die gewünschten Dateien in den Editor öffnen, dann über Polkit „beweisen“, dass man Root-Rechte auf dem System hat, und dann die gewünschten Aktionen direkt über den Dateimanager oder den Editor durchführen. Das Ganze würde transparent im Hintergrund funktionieren, ohne dass man sich verrenken müsste. Wie das Ganze am Ende aussieht, gibt der Blog-Artikel von Martin noch nicht her. Im KDE-Bugtracker gibt es jedoch bereits schon einen entsprechenden Eintrag. Dieser stammt allerdings bereits von 2009 und bekommt hoffentlich durch die aktuelle Entwicklung ein wenig Leben eingehaucht.