Ubuntu und Kubuntu 16.10

Allgemeines zum System

Hans-Joachim Baader

Display-Manager mit Login-Dialog

Ubuntu startet ziemlich schnell, wie schon in Version 16.04. Es setzt, anders als Kubuntu, eine Hardware-3D-Beschleunigung voraus, die bei Grafikkarten, die das nicht bieten, durch llvmpipe emuliert wird. Bei einer ausreichend schnellen CPU ist das Verfahren von der Geschwindigkeit immer noch gerade so erträglich, bei zwei oder mehr CPUs ist es mittlerweile ganz brauchbar, von sehr grafikintensiven Anwendungen abgesehen.

Das Grafiksystem ist bei X.org 7.7 geblieben, da es keine neue Version von X.org in der Zwischenzeit gab. Allerdings wurden einige Komponenten von X.org aktualisiert, darunter der X-Server 1.18.4, und Mesa 12.0.3. Unity 8 ist als Vorschau mit dabei. Auch mit den neuen Display-Servern Mir und Wayland kann man experimentieren, da entsprechende Sitzungen mit Mir und Unity 8 bzw. Wayland und KDE zur Auswahl stehen. Ansonsten bringt Ubuntu 16.10 auf dem Desktop in erster Linie Korrekturen. Viele Anwendungen erhielten mehr oder weniger große Verbesserungen durch neue Versionen. LibreOffice wird in Version 5.2.2 mitgeliefert. Chromium 53 und Firefox 49 sind unter den mitgelieferten Webbrowsern zu finden.

Wie gewohnt hat Root keinen direkten Zugang zum System, sondern die Benutzer der Gruppe sudo können über das Kommando sudo Befehle als Root ausführen. Der Speicherverbrauch von Unity ist gegenüber der Vorversion wieder gestiegen, was aber auch an der aufgebohrten virtuellen Maschine oder anderen Faktoren liegen könnte. Rund 680 MB benötigt die Umgebung allein, ohne dass irgendwelche produktive Software gestartet wurde. Über 240 MB davon entfallen auf Compiz. KDE benötigt in der Standardinstallation mit einem geöffneten Terminal-Fenster etwa 390 MB und damit deutlich weniger als zuvor. Grund dafür ist, dass die KDE-PIM-Suite und Akonadi nicht mehr automatisch, sondern erst bei Bedarf gestartet werden. Die Messung des Speicherverbrauchs der Desktops kann jeweils nur ungefähre Werte ermitteln, die zudem in Abhängigkeit von der Hardware und anderen Faktoren schwanken. Aber als Anhaltspunkt sollten sie allemal genügen.

Hans-Joachim Baader

Handbrake als Snap-Paket

Snap

Snap, das neue Paketformat, das Anwendungen in distributionsunabhängige Anwendungs-Container packt, hat inzwischen einen Reifegrad erreicht, der es möglich macht, fast alle Arten von Software zu paketieren. Der Aufwand für solche Pakete hält sich in Grenzen. Bis auf eine YAML-Datei, die das Paket und seine Erzeugung beschreibt, gibt es keine Vorschriften, was ein Snap-Paket zu enthalten hat. Daher ist der Aufwand für die Paketerstellung überschaubar und in der Regel geringer als bei DEB-Paketen. Umfangreiche Dokumentation und Beispiele findet man auf Snapcraft.io, im FAQ und im Github-Repositorium.

Snap-Pakete werden von Root installiert und stehen dann allen Benutzern zur Verfügung. Sie enthalten Anwendungen mitsamt dem größten Teil ihrer Abhängigkeiten, was ihre Aktualisierung unabhängig vom Rest des Systems ermöglicht. Um zu verhindern, dass jedes Snap-Paket eine große Menge duplizierten Codes (Bibliotheken usw.) mitbringt, gibt es Abhängigkeiten zwischen den Paketen (die automatisch aufgelöst werden), und auf der untersten Ebene gibt es definierte Laufzeitumgebungen, z.B. das 75 MB große Snap-Paket »ubuntu-core 16.04.1«.

Jedes Snap-Paket ist versioniert und kann aktualisiert werden. Eine Aktualisierung kann durch ein Zurücksetzen auf eine frühere Version rückgängig gemacht werden. Ein einmal erstelltes Snap-Paket sollte auf allen Systemen laufen, die Snap unterstützen. Anwendungen sind so weit wie möglich voneinander isoliert. Sie sind außerdem vor Änderungen geschützt - technisch ist das so realisiert, dass die Snap-Pakete per Loopback in ein Unterverzeichnis von /snap gemountet werden. Es gibt auch Verzeichnisse, in denen die Snap-Pakete Dateien ablegen dürfen, Konfigurationsdateien ebenso wie andere Daten.

Da Snaps fast immer mit anderen Anwendungen oder dem System kommunizieren müssen, gibt es eine laufend erweiterte Liste von Schnittstellen, die solche Verbindungen schaffen. Snap-Pakete müssen deklarieren, welche Schnittstellen sie benötigen oder anbieten, und das System lässt nur die deklarierten Zugriffe zu. Damit kann die Sicherheit des Systems garantiert werden, außer bei X11-Anwendungen. Der Grund ist der, dass X11 nicht darauf ausgelegt ist, Anwendungen voneinander zu isolieren, es bietet einfach nicht die Möglichkeiten dafür. Mit Wayland oder Mir wird das voraussichtlich ganz anders aussehen. Insgesamt erinnert Snap also schon stark an das App-Ökosystem von Android, das sicherlich in vielerlei Hinsicht Ideengeber war.

Werden Snaps installiert, dann steigt der Speicherbedarf aufgrund der verwendeten Loopback-Mounts weiter an. Diesen Punkt sollte Canonical noch optimieren, denn dass Programme, die gar nicht gestartet sind, bereits RAM belegen, darf nicht sein. Der Automounter könnte vielleicht Abhilfe schaffen.

Mittlerweile gibt es nach Angaben von Canonical über 500 Snap-Pakete. Wie Canonical auf diese Zahl kommt, ist mir schleierhaft. Aus den Suchen mit snap find lässt sich schließen, dass nur gut 100 Pakete verfügbar sind. Trotzdem ist Snap augenscheinlich schon sehr weit entwickelt. Auch wenn die Entwicklung noch nicht abgeschlossen ist, ist es viel weiter als das ähnlich ausgerichtete Flatpak. Es ist bedauerlich, dass es wieder einmal zwei oder mehr Formate gibt, die miteinander konkurrieren. Snap wird von vielen als Alleingang von Canonical gesehen, ist aber nicht auf Ubuntu beschränkt - Debian hat es (momentan nur in Sid), Gentoo, Opensuse, Arch und sogar Fedora sind mit dabei. Flatpak könnte genauso als Alleingang von Red Hat gesehen werden. Allerdings wurde es inzwischen in Gnome integriert. Wie es weitergeht, bleibt abzuwarten.