Ubuntu und Kubuntu 16.04 LTS

Hans-Joachim Baader

Youtube in Firefox in Kubuntu

Multimedia im Browser und auf dem Desktop

Nicht viel Neues gibt es im Multimedia-Bereich. OpenH264 ist in Firefox als Plugin vorinstalliert und aktiviert, um WebRTC zu ermöglichen. Der eigentliche Plugin-Code wird offenbar beim ersten Start heruntergeladen. Diese Vorgehensweise hat ihre Ursache darin, dass Cisco, von dem der Code stammt, nur für das binäre Plugin die angefallenen Patentlizenzen bezahlt hat. Der Quellcode des Moduls ist unter der BSD-Lizenz verfügbar, allerdings von der Patentlizenz nicht abgedeckt. Die vorinstallierte Firefox-Erweiterung Ubuntu Firefox Modifications ist bei Version 3.2 geblieben. Es ist die einzige vorinstallierte Erweiterung.

Wie immer muss man zum Abspielen der meisten Video-Formate (und diverser Audio-Formate wie MP3) zuerst das passende Plugin installieren. Die Software-Verwaltung weist jetzt darauf hin, dass einige dieser Plugins von Softwarepatenten belastet sein könnten, was aber zumindest Privatnutzern völlig egal sein kann.

Wenn man ein zusätzliches Plugin benötigt, wird dies unter Unity und Gnome von den jeweiligen Anwendungen in einer Dialogbox angezeigt. Diese sucht nach passenden GStreamer-Plugins, schlägt sie zur Installation vor und kann sie anschließend installieren. Das funktioniert korrekt, nach der Plugin-Installation muss man allerdings die Player-Software neu starten.

Auch Web-Videos funktionieren weitgehend. Die Ubuntu-Version von Firefox kann über GStreamer alles abspielen, wofür Plugins installiert sind, also auch Flash. Lediglich Webseiten, die explizit das Adobe-Flash-Plugin verlangen, funktionieren so nicht. Das Flash-Plugin gibt es für Firefox bzw. Iceweasel zwar noch, es wird aber bis auf Korrekturen von Sicherheitslücken nicht mehr gepflegt. Das größte Problem ist jedoch, dass Mozilla den Benutzern viele lästige Hürden in den Weg legt, wenn sie das Plugin weiter nutzen wollen. Workarounds sind die Verwendung eines anderen Browsers wie Google Chrome oder Chromium mit dem von Google stammenden proprietären Pepperflash-Plugin. Andere Workarounds sind das Herunterladen der Videos, um sie in einem Player offline oder als Stream anzusehen, oder die Installation von Gnash, das jedoch keinen Erfolg garantiert.

Unter KDE sieht es im Prinzip genauso aus, nur dass die Geschwindigkeit auch ohne 3D-Hardware akzeptabel ist. Amarok ist der Standard-Audioplayer. Früher wurden auch unter KDE fehlende Plugins korrekt nachinstalliert oder waren bereits vorhanden. Das ist in 16.04 LTS wie schon in 15.10 nicht der Fall. Amarok und Dragonplayer funktionieren schlicht nicht, wenn die Plugins fehlen. Leider scheint auch jegliche Unterstützung für die Nachinstallation zu fehlen. Es bleibt nur die Installation von Hand, im Wesentlichen die Pakete gstreamer1.0-plugins-ugly, gstreamer1.0-plugins-bad-videoparsers und gstreamer1.0-libav.

Fazit

Canonical hat gut daran getan, in 16.04 LTS auf alles zu verzichten, was nicht stabil oder ausgereift ist. Das Resultat ist eine sehr stabile Distribution, die als Grundlage für das langfristige Arbeiten dienen kann. Sogar kontroverse Einstellungen wie die Online-Suche wurden zurückgenommen und einstellbar gemacht. Dafür sorgte Canonical gleich für neue Kontroversen, indem es Binärmodule von ZFS mitliefert. Diese Entscheidung dürfte noch Folgen haben. Im günstigsten Fall würde Oracle die Lizenzierung von ZFS auf die GPLv2 erweitern. Aber das steht noch in den Sternen.

Die Desktopumgebungen Unity und KDE machen einen guten Eindruck, was besonders bei KDE erwähnenswert ist, das in der letzten Version noch geradezu desaströs war. Bei beiden getesteten Umgebungen sowie auch bei Gnome ist der Speicherverbrauch exorbitant, aber ob man damit leben kann, entscheidet letztlich jeder selbst.

Verbessern könnte Canonical die Sicherheits-Updates des Systems. Denn erst kürzlich wurde wieder darauf hingewiesen, dass nur das »main«-Repositorium volle Sicherheitsunterstützung für fünf Jahre erhält. Das Gros der Bibliotheken und Anwendungen liegt aber im »universe«-Repositorium vor, und hier ist die Unterstützung lückenhaft. Das ist allerdings nichts Neues und auch keineswegs ein Geheimnis.

Man kann Canonical gewiss nicht vorwerfen, bei der Sicherheit nichts zu tun - beispielsweise arbeiten Canonical-Entwickler daran, mehr Sicherheitsfunktionalität in den Kernel zu bekommen. Es wäre auch einmal interessant, zu sehen, wieviele Sicherheitslücken durch das aktivierte AppArmor bereits abgefangen werden, so dass sie nicht ausnutzbar sind. Auf lange Sicht sind solche proaktiven Maßnahmen sogar sinnvoller als die Korrektur jedes einzelnen Fehlers in Anwendungen. Denn wenn eine Lücke in einer Anwendung erkannt und geschlossen wird, kann der Schaden bereits angerichtet sein, während andere Schutzmaßnahmen wie AppArmor bereits im Vorfeld wirken.