Mit Verspätung

Mit zwei Monaten Verspätung hat das OpenSuse-Projekt [1] nun endlich die Version 12.2 der beliebten Distribution vorgelegt. Zumindest was die Qualitätssicherung angeht, hat die Wartezeit der Distribution gut getan. Dass die OpenSuse-Macher darüber nachdenken, künftig auf ein Rolling-Release-Modell zu wechseln (siehe Kasten "Tumbleweed"), zeigt, wie sehr der durch vorab festgesetzte Release-Zyklen selbst auferlegte Druck die Entwicklung belastet – Nutzer von OpenSuse 12.1 wissen davon ein Lied zu singen.

Echte technische Neuerungen bringt OpenSuse 12.2 nur wenige [2], darunter etwa den Wechsel des Grub-Bootloaders auf die finale Version 2.0, das Ersetzen des angestaubten SysV-Init durch das moderne Init-System Systemd und das Verschieben sämtlicher Binaries gemäß Fedora-Vorbild nach /usr. Die von den Red-Hat-Entwicklern für Fedora ersonnene, salopp als Usr-Merge [3] bezeichnete Umstrukturierung macht es einfacher, /usr komplett in ein eigenes Dateisystem auszulagern oder schreibgeschützt über das Netz einzubinden, sodass es sich von mehreren Systemen gleichzeitig nutzen lässt.

Die OpenSuse-Entwickler haben allerdings laut eigenen Angaben gerade erst damit begonnen, die System-Verzeichnisse /bin, /sbin und /lib in gleichnamige Unterverzeichnisse unterhalb von /usr zu verlagern. Der Merge-Prozess soll mit OpenSuse 12.3 fortgesetzt werden, vorrangig mit um dem künftigen Standard kompatibel zu bleiben. Allerdings ist /usr-Merge nicht FHS-konform.

Im Test ließen sich die Installationsmedien von OpenSuse trotz Grub 2 nicht im EFI-Modus starten. Eine Installation auf EFI-Boards funktioniert also nur dann, wenn dessen EFI kompatibel zu einem herkömmlichen BIOS ist. Ubuntu 12.04 und Fedora 17 unterstützen EFI bereits jetzt deutlich besser. Eine echte Verbesserung für den Umgang mit (U)EFI bei OpenSuse steht erst mit Version 12.3 an, die dann auch UEFI Secure Boot unterstützt soll. Die dazu vom Suse-Entwickler Vojtech Pavlik [4] vorgeschlagene Vorgehensweise, das für Windows 8 vorgesehene, mittels signierter Schlüssel abgesicherte Bootverfahren zwecks Parallelinstallation von Linux und Windows zu implementieren, liegt funktional zwischen den Verfahren von Fedora und Ubuntu.

Fundamentales

OpenSuse verwendet als Standard-Kernel Linux 3.4 vom Mai dieses Jahres. Als Standard-C-Shared-Library verwendet OpenSuse 12.2 die Glibc 2.15. Die GCC-Version 4.7.1 vervollständigt die Toolchain als Standard-Compiler, während als Java-Laufzeitumgebung OpenJDK 7 zum Einsatz kommt.

OpenSuse nutzt nun den von anderen Distributionen schon verwendeten Plymouth-Bootscreen [5], der technische Details des Startprozesses hinter einer Boot-Animation versteckt. Als Standard-Dateisystem fungiert nach wie vor Ext4. Btrfs gilt bei OpenSuse weiterhin als experimentell, lässt sich jedoch bei Bedarf bereits bei der Installation (Abbildung 1) einfach per Mausklick aktivieren. Obendrein legen die OpenSuse-Entwickler Werkzeuge zum Prüfen und Reparieren von Btrfs-Partitionen bei.

Abbildung 1: Der OpenSuse-Installer schafft es vorbildlich, Komfort (möglichst wenige Benutzerinteraktion und gut gewählte Vorgaben) und Funktionalität (Detail-Infos, Eingriffsmöglichkeiten) zu kombinieren.

OpenSuse schlägt bei der Installation vor, eine separate Home-Partition zu verwenden. Als Alternative offeriert es eine LVM-basierte Partitionierung. Auch ein zuvor gesicherter beziehungsweise exportierten Partitionsaufbau lässt sich während der Installation importieren. In der Vorgabe-Einstellung meldet das System den bei der Installation angelegten Standard-Benutzer, der auch als Administrator fungiert, automatisch an – diese Optionen sollten Sie deaktivieren.

Sysinit und X-Server

Das Initialisieren der elementaren Systemdienste erledigt jetzt anstelle von SysV-Init der neue Systemd. Dass OpenSuse 12.2 schneller bootet als die Vorgänger liegt unter anderen an dessen Readahead-Funktion.

Als Fundament der grafischen Oberfläche dient der X.org-Server in der Version 1.12. Für flotte Grafik sorgen Mesa 3D 8.0 und der Llvmpipe-Treiber [6], der die zur Darstellung von GL-Effekten erforderlichen 3D-Berechnungen auf der CPU ausführt, wenn der verwendete Linux-Grafik-Treiber keine 3D-Beschleunigung mit GPU-Unterstützung ermöglicht. Dadurch funktionieren KDE SC 4 mit Composite-Effekten und die Gnome-3-Oberfläche auch auf älteren beziehungsweise exotischen Grafikkarten oder in virtuellen Maschinen (Abbildung 2).

Abbildung 2: Dank Mesa 3D 8.0 und Llvmpipe stehen Desktop-Effekte sogar in virtuellen Maschinen zur Verfügung.