Die zweite Auflage von »Python — Der Grundkurs« ist erschienen. Für die Neuauflage habe ich dieses äußerst erfolgreiche Buch im Hinblick auf die aktuelle Python-Version 3.10 vollständig aktualisiert und in vielen Details verbessert:
Assignment Expressions (Zuweisung und Vergleich kombinieren)
Neue Formatierungssyntax `f'{varname}‘
Vereinigung von Dictionaries
Pattern Matching (Tupel, Listen und Sets mit Mustern auswerten)
Stärkere Berücksichtigung von VSCode als Python-Editor
Am Grundkonzept des Buchs hat sich nicht geändert: Der kostengünstige Grundkurs richtet sich an Einsteiger, die parallel zum Buch Python in der Schule, im Studium oder in der Arbeit lernen, sowie an Umsteiger von anderen Programmiersprachen, die rasch die Eigenheiten von Python erlernen wollen.
Viele Beispiele aus der Praxis sowie Übungsaufgaben helfen dabei, Python ohne allzu viel Theorie kennenzulernen. Im handlichen Taschenbuchformat ist das Buch auch unterwegs ein idealer Begleiter. Mehr Details zum Buch gibt es hier:
Seit einigen Tagen ist Kotlin 1.6 verfügbar. Dieser Beitrag geht auf die wichtigsten Neuerungen im Vergleich zu Version 1.5 ein. Die Kurzfassung: Kotlin 1.6 ist ein »kleines« Release, für die meisten Entwickler gibt es keine wirklich dramatische Änderungen. Auch die Verbesserungen in der Standardbibliothek sind eher Kleinigkeiten.
Dieser Text bezieht sich auf die folgenden Versionsnummern:
IntelliJ: 2021.2.3
Kotlin: 1.6.0
JDK: 17
Weitere Kotlin-Update-Artikel auf meiner Website finden Sie hier:
In Kotlin 1.6 beklagt sich der Compiler, wenn eine when-Konstruktion für Enumerationen, boolesche Werte oder für Datentypen nicht alle möglichen Fälle erfasst, also nicht »exhaustive« ist. Aktuell können Sie diese Warnung noch ignorieren, aber in Kotlin 1.7 wird daraus ein Fehler. Spätestens dann müssen Sie die when-Konstruktion so formulieren, dass sämtliche Fälle erfasst werden (am einfachsten durch einen else-Block).
enum class Days {
Monday, Tuesday, Wednesday, Thursday,
Friday, Saturday, Sunday
}
val day = Days.Friday
when(day) {
Days.Monday, Days.Tuesday -> println("Wochenanfang")
Days.Wednesday, Days.Thursday -> println("Wochenmitte")
Days.Friday -> println("Fast geschafft")
// Warnung: Non exhaustive 'when' statements on enum will be prohibited
// in 1.7, add 'Saturday', 'Sunday' branches or 'else' branch instead
}
Standardbibliothek
readln: Wenn Sie mit readLine() eine Datei zeilenweise auslesen, liefert die Funktion entweder die nächste Zeile oder null. Nunmehr gibt es zwei Varianten zu readline, die die ursprüngliche Form längerfristig ablösen sollen:
readlnOrNull() verhält sich wie ehemals readLine(), ist aber klarer benannt und hat mehr Ähnlichkeiten mit println.
readln() löst dagegen einen Fehler aus, wenn das Ende der Datei erreicht ist, und kann statt dem wenig eleganten readLine()!! verwendet werden.
readLine() bleibt uns vorerst erhalten, soll aber in kommenden Kotlin-Versionen deprecated werden.
typeOf:typeOf<Typ> liefert ein KClass-Objekt, das Typ beschreibt. Die Funktion stand zwar schon seit Kotlin 1.3.40 zur Verfügung, ursprünglich aber nur für die JVM-Variante. Nunmehr kann typeOf in allen drei Kotlin-Varianten (also auch JS und Native) verwendet werden.
Duration-API: Die Duration API (beschrieben in Abschnitt 7.3 meines Kotlin-Buchs) gilt nun als stabil. Das gilt allerdings nicht für andere kotlin.time-Klassen zur Zeitmessung. Die in Kotlin 1.5 abgeschaffte Notation
val myDur = 2.minutes + 3.seconds - 10.milliseconds * 0.66
ist erfreulicherweise wieder eingeführt worden, erfordert nun aber Importe der betreffenden Companion-Eigenschaften, hier also:
Meine ersten Tests mit Kotlin scheiterten an Java 17. Auf meinem Rechner ist auch die JDK 17 installiert. Anscheinend ist das Build-System dazu nicht kompatibel. IntelliJ war nicht in der Lage, das minimalistische Console Template zu kompilieren und zeigte eine wenig hilfreiche Fehlermeldung an:
Could not open init generic class cache for initialization script '/tmp/wrapper_init4.gradle' (/crypt/home/kofler/.gradle/caches/7.1/scripts/954mesz5ux7usmane6uzpuni1).
> BUG! exception in phase 'semantic analysis' in source
> unit '_BuildScript_' Unsupported class file major version 61
Eine kurze Suche in stackoverflow ergab, dass Kompatiblitätsprobleme zwischen Gradle und der JDK 17 die Ursache sein könnten. Ich habe dann die JDK-Version für das Build-System auf 11 zurückgesetzt, und alles funktionierte. Merkwürdig. (Es geht hier nicht um die JDK für das eigentliche Projekt, die darf sehr wohl 17 sein.)
Die von JVM eingesetzte JVM sollte nicht allzu aktuell sein …
Die Raspberry Pi Foundation hat eine neue Raspberry-Pi-OS-Version auf der Basis von Debian Bullseye freigegeben. Damit ändert sich Einiges: Zum einen natürlich eine Menge Versionsnummern dank des modernisierten Debian-Unterbaus, zum anderen aber auch durchaus wichtige technische Details. Z.B. verwendet Rasbperry Pi OS nun standardmäßig GTK3 und den Displaymanager Mutter — zumindest auf Rechnern mit 2 GByte. Aber der Reihe nach …
Update 7.12.2021: Die alte Raspberry-Pi-OS-Version (Buster) wird bis auf Weiteres mit Updates versorgt und erhält die Bezeichnung Legacy. Damit wird niemand zum Update auf die neue Version (Bullseye) gezwungen. Mehr Details können Sie im Blog von raspberrypi.com nachlesen.
Der PIXEL-Desktop von Raspberry Pi OS
Desktop
Auf dem Desktop gibt es nur wenige optische Änderungen:
Hinweise (Notifications) werden jetzt am rechten Bildschirmrand angezeigt. Diese Funktion kann bei Bedarf deaktiviert werden. Dazu öffnen Sie im Panel das Kontextmenü und führen Leisten-Einstellungen / Erscheinungsbild aus.
Zu den neuen Notifications zählt auch der Hinweis auf anstehende Updates. Ein Klick auf den Hinweis öffnet einen neuen, grafischen Update-Manager.
Im Dateimanager gibt es nur mehr zwei Darstellungsmodis: die Icon- und die Listenansicht.
Raspberry Pi OS hat jetzt einen grafischen Update-Dialog
Grafiksystem und Gtk
Der erste Eindruck täuscht aber. Hinter den Kulissen hat sich wesentlich mehr verändert als an der Oberfläche:
Für die Aktivierung des richtigen Grafikmodus ist jetzt der Kernel zuständig (Kernel Mode Setting, KMS). Dabei kommen offizielle Funktionen des Kernels zum Einsatz, nicht mehr wie bisher Raspberry-Pi-spezifische Funktionen, deren Code nicht öffentlich war (Quelle raspberrypi.com).
Raspberry Pi OS verwendet nun standardmäßig GTK3-Bibliotheken (bisher GTK2). Das vereinfacht die Realisierung optischer Effekte (z.B. abgerundeter Fensterecken). Viel wichtiger ist aber: GTK2 ist eine veraltete, nicht mehr aktiv gewartete Bibliothek. Immer mehr moderne Programme setzen GTK3 voraus. Insofern war der Umstieg auf GTK3 überfällig.
Auf Raspberry Pis mit zumindest 2 GByte RAM kommt der Fenstermanager Mutter zum Einsatz (bisher openbox). Auch hier gilt: Mutter ist moderner, zukunftssicherer. Bie Raspberry Pi Organisation bezeichnet den Umstieg auf Mutter als den ersten Schritt hin zur Ablöse von X durch Wayland. Einen konkreten Zeitplan für den Wechsel zu Wayland gibt es allerdings noch nicht, und es ist unklar, ob dieser überhaupt möglich ist. Selbst Mutter braucht so viel RAM, dass es nur auf großzügig mit RAM ausgestatteten Geräten zum Einsatz kommt.
RDP zickt: In der Vergangenheit reichte es aus, xrdp zu installieren, damit man sich mit Remotedesktopverbindung oder einem anderen RDP-Client am Raspberry Pi anzumelden. Gleich aus mehreren Gründen funktioniert das mittlerweile nicht mehr. Abhilfe: Richten Sie einen weiteren Benutzer ein und melden Sie sich damit an (statt mit pi). Mehr Details: https://pi-buch.info/aerger-mit-rdp
Kamera-Software
In bisherigen Raspberry-Pi-OS-Versionen waren proprietäre Software-Treiber und die Programme raspistill und raspivid zuständig, um Fotos bzw. Videos von der Kamera aufzunehmen. Mit dem neuen Raspberry Pi OS wird die Kamera dagegen über die libcamera-Treiber des Kernels angesprochen. Dass im Zuge dieser Umstellung raspistill und raspivid einfach eliminiert wurden, wird viele Scripts vor Kompatibilitätsprobleme stellen. Ja, es gibt mit libcamera-still und libcamera-vid neue Kommandos, diese haben aber komplett andere Optionen. Dokumentation dazu finden Sie hier:
Aus dem Konfigurationsprogramm ist die Option zur Kamerakonfiguration verschwunden. Dafür enthält /boot/config.txt jetzt den Parameter camera_auto_detect=1, der sich um die automatische Treiberkonfiguration kümmern soll. Tests zur Nutzung der Kamerafunktionen reiche ich später in einem eigenen Artikel nach, sobald ein neues Kameramodul bei mir eintrifft. Das alte hat überraschend seinen Geist aufgegeben.
Update 11.11.2021: Mittlerweile habe ich auch die neuen libcamera-Tools kurz dokumentiert:
Viel getan hat sich bei den Versionsnummern des Software-Stacks. Die wichtigste Änderung für viele Raspberry-Pi-Anwender betrifft Python: Erstmals steht die veraltete Version 2 nicht mehr zur Verfügung. Das Kommando python startet nun Python 3.9 statt Python 2.7. Es ist zu befürchten, dass das bei vielen alten Programmen/Bibliotheken zu Problemen führt. Wirklich überrascht sollte aber keiner sein — vor dem Ende von Python 2 wurde ein Jahrzehnt lange gewarnt.
Ich hatte bei meinen Tests massive Probleme mit meinen Monitoren. Immer wieder passierte es, dass meine Monitore nach einer kurzen Darstellung des Raspberry-Pi-Logos einfach schwarz blieben. In allen Fällen lief der Raspberry Pi, d.h. eine SSH-Verbindung war möglich. Die Monitore erhielten offenbar auch ein Signal, d.h. sie wechselten nicht wie sonst automatisch in den Stand-by-Modus oder schalteten sich aus.
Für meine Tests habe ich einen Pi 4B der ersten Generation (1 GB RAM) sowie ein Modell 400 verwendet. Als Monitore kamen ein moderner LG-4k-Monitor (Modell 27UL850-W) sowie ein uralter Benq-Monitor (G2400-WT) zum Einsatz.
Dass während des Bootprozesses keine Meldungen des Kernels bzw. von systemd angezeigt werden, ist beabsichtigt, auch wenn ich mir nicht sicher bin, dass das eine gute Idee ist. Abhilfe: Entfernen Sie quiet splash aus der Datei /boot/cmdline.txt. Eine echte Lösung des Problems ist dies aber nicht: Während der ersten Sekunden sind nun diverse Meldungen sichtbar. Danach wird der Monitor schwarz. Eine Weile später (nach ca. 10 bis 15 Sekunden) erscheint der Desktop — oder auch nicht.
Manchmal half es, den Monitor einfach kurz aus und wieder ein zu schalten.
Sicher ist, dass die Probleme mit dem neuen Raspberry Pi OS zu tun haben; ich habe die gleiche Hardware auch schon mit der vorigen Version des Betriebssystems verwendet und hatte nie derartige Probleme. Trotzdem bleibt unklar, ob die Fehler nur spezifisch bei meiner Hardware auftreten oder ob auch andere Raspberry-Pi-Anwender betroffen sind. Ein diesbezüglicher Twitter-Post erhielt kaum Resonanz.
Problematisch ist in diesem Zusammenhang auch die Veränderung der Bildschirmauflösung: Bei Systemen mit 2 GB RAM oder mehr (also Gtk3) wird die Änderung erst nach einem Reboot wirksam. Das ist nicht nur unpraktisch, sondern auch äußerst problematisch, wenn die gewählte Auflösung am Bildschirm nicht angezeigt werden kann. Mit Pech bleibt der Bildschirm dann ganz einfach schwarz — ohne eine einfache Möglichkeit, die Änderung der Auflösung rückgängig zu machen. Definitiv nicht benutzerfreundlich!
Wenn »Mutter« als Window Manager läuft (auf allen Pis mit 2 GByte RAM oder mehr), erfordert der Wechsel der Bildschirmauflösung einen Neustart mit ungewissem Ausgang
Abhilfe schafft dann nur die Veränderung der Datei /home/pi/.config/monitors.xml via SSH oder auf einem zweiten Linux-Rechner. (Unter macOS oder Windows können Sie auf direkt auf der SD-Karte auf die Partition mit dem Linux-Dateisystem ja gar nicht zugreifen.)
Ich kann mich nicht erinnern, wann ich zuletzt so viel Zeit damit vergeudet habe, um einfach nur ein Bild am Monitor zu sehen. Meine Vermutung ist, dass der ganze Ärger mit dem neuen Kernel Mode Switching (KMS) zu tun hat, das in Raspberry Pi OS Bullseye erstmals aktiv ist und möglicherweise noch nicht in allen Fällen perfekt funktioniert. (Grundsätzlich ist KMS natürlich eine gute Sache: Es ermöglicht einen flicker-freien Bootprozess und erleichtert die Nutzung der Grafikfunktionen ohne Closed-Source-Treiber.)
Sonstiges
Bei RP-Modellen ab 2 GByte RAM ist eine Drehung der Bildschirmdarstellung nicht mehr möglich (z.B. für einen Monitor in Portrait-Modus). Laut der Diskussion auf raspberrypi.com liegt das Problem beim Window Manager Mutter.
Auch die neue Raspberry-Pi-OS-Version verbleibt in der 32-Bit-Welt. Eine 64-Bit-Version wäre möglich, aber die Entwickler sehen keine großen Performance-Vorteile. Außerdem würde eine 64-Bit-Version zwei unterschiedliche Betriebssystemversionen je nach CPU erfordern. (Nur die aktuellen Raspberry-Pi-Modelle haben eine 64-Bit-CPU.) Wer also Docker oder ähnliche Funktionen am Raspberry Pi mit einem 64-Bit-Stack ausführen muss, ist mit alternativen Betriebssystemen wie Ubuntu besser bedient.
Die CPUs auf aktuelle Raspberry-Pi-Modelle mit 2, 4 oder 8 GByte erreichen nun automatisch eine Taktfrequenz von 1,8 GHz. Voraussetzung dafür ist die auf den neuen Platinen integrierte Switch-mode Power Supply (Quelle: raspberrypi.com).
Die Raspberry Pi Foundation rät dringend davon ab, ein Update von Raspberry Pi OS Buster auf die neue Bullseye-Edition zu versuchen — und ich schließe mich diesem Ratschlag an. Grundsätzlich ist so ein Update relativ einfach möglich, in dem Sie in /etc/atp/sources.list jeweils buster durch bullseye ersetzen und dann ein Update aller Pakete durchführen. (So ein Update ist zeitaufwändig — rechnen Sie zumindest mit 30 Minuten, während der Sie immer wieder Rückfragen beantworten müssen.) Aufgrund der vielen grundlegenden Änderungen zwischen den beiden Versionen sind Kompatibilitätsprobleme zu erwarten. Deswegen ist es sicherlich vernünftig, ein Backup aller relevanten Dateien durchzuführen und dann (idealerweise auf eine zweite SD-Karte) die neue Version von Raspberry Pi OS zu installieren.
Fazit
Viele technische Änderungen, die zusammen mit dem Umstieg auf die neue Basis Debian Bullseye durchgeführt wurden, sind aus Open-Source-Sicht erfreulich: Es kommen mehr Open-Source-Treiber als bisher zum Einsatz, Raspberry Pi OS ist näher an Linux-Standards und es gibt sogar einen (vager) Ausblick Richtung Wayland.
Zumindest bei meinen Tests sind allerdings auch erhebliche Probleme aufgetreten. (Ich habe natürlich auch andere Tests gelesen. Deren Autoren hatten offenbar weniger Probleme. Vielleicht liegt es an mir oder an meiner Hardware?)
Wie auch immer: Sie machen vermutlich nichts verkehrt, wenn Sie noch ein, zwei Monate abwarten, bevor Sie auf das neue Raspberry Pi OS Bullseye umsteigen.
Die Fertigstellung der Herbst-Edition von Fedora hat zwar ein paar Wochen länger gedauert als bei Ubuntu, aber dafür ist der Software-Stack spürbar moderner: Kernel 5.14, Gnome 41 und Python 3.10 lassen grüßen. Auf technischer Ebene schreitet vor allem die PipeWire-Integration voran.
Die Workstation-Variante von Fedora 35 verwendet Gnome 41 als Desktop
Versionsnummern
Wie üblich konzentriere ich in dieser Kurzvorstellung auf die Workstation-Variante von Fedora. Die wichtigsten Versionsnummern des Software-Stacks sehen so aus:
Nicht in meiner Versionsnummernübersicht enthalten ist FirewallD. Dennoch ist dieses Paket diesmals erwähnenswert, weil es endlich den Sprung auf die Versionsnummer 1.0 geschafft hat. Dabei haben sich einige Defaulteinstellungen geändert, die im Projektblog dokumentiert sind.
WirePlumber
Bereits mit Version 34 ist Fedora auf das Audio-System PipeWire umgestiegen (siehe auch meinen Blogartikel zu Fedora 34). Neu in Fedora 35 ist der Session-Manager WirePlumber. An der Bedienung für Endanwender ändert sich dadurch wenig (außer dass alles noch besser funktionieren sollte), aber für Entwickler bietet PipeWire eine klare Schnittstelle zur Integration und Nutzung der Audio-Funktionen. WirePlumber läuft als systemd-Dienst auf User-Ebene:
systemctl --user status wireplumber
● wireplumber.service - Multimedia Service Session Manager
Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-11-03 19:13:26 CET; 34min ago
Main PID: 1667 (wireplumber)
Tasks: 4 (limit: 3352)
Memory: 8.5M
CPU: 367ms
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/wireplumber.service
└─1667 /usr/bin/wireplumber
Nov 03 19:13:26 fedora systemd[1422]: Started Multimedia Service Session Manager.
Wenig Änderungen hat es rund um das Dateisystem btrfs gegeben. Es kommt weiterhin standardmäßig zum Einsatz, die Defaulteinstellungen haben sich aber nicht geändert (zwei Subvolumes für /home und /, aktive Komprimierung mit zstd).
Als alternatives Paketsystem favorisiert Fedora FlatPak. Standardmäßig ist aber kein einziges Programm als FlatPak installiert. Gnome Software ist FlatPak-kompatibel und zeigt entsprechende Pakete an, sofern FlatPak-Quellen eingerichtet wurden. Das kann während der Inbetriebnahme von Fedora 35 erfolgen oder direkt im Menü von Software (Menüpunkt Softwarequellen).
Mit Ubuntu 21.10 »Impish Indri« hat Canonical das letzte Release vor der nächsten LTS-Version 22.04 fertiggestellt. Die wichtigsten Neuerungen lassen sich in zwei Punkten zusammenfassen: Ubuntu hat den Sprung auf Gnome 40 vollzogen (wenn auch nicht auf die aktuelle Version 41), und Firefox steht standardmäßig als Snap-Paket zur Verfügung. Das neue Installationsprogramm, an dem Canonical zur Zeit arbeitet, war noch nicht so weit gediehen, dass es für Version 21.10 zum Einsatz kommen konnte.
Ubuntu 21.10 verwendet Gnome 40 als Desktop — aber mit einem vertikalen Dock
Firefox und Snap
Leser meines Blogs wissen, dass ich kein ausgesprochener Fan der neuen Paketformate Snap und Flatpak bin. Ich verstehe natürlich den Nutzen distributions- und versionsunabhängiger Pakete, bin aber der Meinung, dass die Nachteile aufgrund des riesigen Overheads überwiegen. Unter Ubuntu 21.10 sind außer diversen Basispaketen nur der Paketmanager snap-store (das ist Canonicals Variante zu Gnome Software) sowie Firefox installiert:
snap list
Name Version Revision Tracking Herausgeber Hinweise
bare 1.0 5 latest/stable canonical✓ base
core 16-2.51.7 11743 latest/stable canonical✓ core
core20 20210928 1169 latest/stable canonical✓ base
firefox 93.0-1 631 latest/stable/… mozilla✓ -
gnome-3-38-2004 0+git.6ba6040 76 latest/stable/… canonical✓ -
gtk-common-themes 0.1-59-g7bca6ae 1519 latest/stable/… canonical✓ -
snap-store 3.38.0-66-gbd5b8f7 557 latest/stable/… canonical✓ -
Der Platzbedarf für diese Pakete beträgt 674 MByte:
ls -lh /var/lib/snapd/snaps/
insgesamt 674M
-rw------- 1 root root 4.0K Oct 10 09:58 bare_5.snap
-rw------- 1 root root 100M Oct 10 09:58 core_11743.snap
-rw------- 1 root root 62M Oct 10 09:57 core20_1169.snap
-rw------- 1 root root 151M Oct 10 09:57 firefox_631.snap
-rw------- 1 root root 243M Oct 10 09:58 gnome-3-38-2004_76.snap
-rw------- 1 root root 66M Oct 10 09:58 gtk-common-themes_1519.snap
-rw------- 1 root root 55M Oct 10 09:58 snap-store_557.snap
Der Vorteil des Firefox-Snap-Pakets besteht darin, dass Canonical dieses Paket in Zukunft für sämtliche Versionen von Ubuntu warten kann. Ein nicht unerheblicher Nachteil besteht darin, dass der erste Start von Firefox Snap-bedingt spürbar langsamer als bisher erfolgt. (Ab dem zweiten Start ist der Unterschied kaum mehr wahrnehmbar.)
Das nächste Ärgernis ist die Verwaltung der Gnome Shell Extensions: Obwohl chrome-gnome-shell in Ubuntu standardmäßig installiert ist und ich auch die Firefox-Erweiterung Gnome Shell-Integration beim ersten Besuch von https://extensions.gnome.org/ installiert habe, kann Firefox die Extensions nicht verwalten. Meine Vermutung ist, dass das Paket chrome-gnome-shell im Ubuntu-Dateisystem für Firefox unzugänglich ist, weil dieser — Snap sei dank — ja quasi in seinem eigenen Betriebssystem läuft.
Firefox zickt bei der Darstellung der Gnome Shell Extensions
Ich bin der Sache nicht auf den Grund gegangen, weil es eine bequeme Alternative gibt: Ich habe Google Chrome installiert. Das Programm gibt es von Google als »richtiges« Paket samt eigener Paketquelle. (Es gibt in den offiziellen Ubuntu-Paketquellen übrigens noch immer ein DEB-Paket für Firefox. Dieses Paket soll aber in Version 22.04 verschwinden.)
Insgesamt stellt sich die Frage, ob Canonical mit der Snap-Entscheidung Firefox unter Ubuntu nicht endgültig den Todesstoß versetzt. Ein wenig gewinnt man in den letzten Jahren den Eindruck, Firefox entwickelt sich zu einem Programm für Idealisten.
Gnome 40
Über Gnome 40 habe ich schon genug geschrieben. Den aus meiner Sicht größte Mangel — das horizontale Dock — hat Canonical mit dem vorinstallierten Ubuntu Dock behoben. Dabei handelt es sich um eine Variante zu Dash to Dock (siehe auch Gnome 40 mit einem vertikalen Dock). Über das merkwürdige Aussehen des Papierkorb-Icons, das im Dock angezeigt wird, kann man streiten, aber davon abgesehen funktionieren sowohl Gnome 40 als auch das Dock wunderbar.
Die standardmäßig installierten Gnome Shell Extensions, dargestellt in Google Chrome
In den Systemeinstellungen kann zwischen einem hellen und einem dunklen Erscheinungsbild ausgewählt werden. Hier können Sie auch die Icon-Größe im Dock sowie dessen Position einstellen.
Als Default-Java-Version gilt 11. Zur Auswahl stehen aber auch Java 16, 17 und sogar schon eine erste Testversion von Java 18. Der Umstieg auf PHP 8.0 ist willkommen; schade ist, dass Python 3.10 den Sprung in Ubuntu 21.10 nicht geschafft hat. (Zugegebenermaßen ist das Release gerade einmal vor 10 Tagen.)
Anmerkung
Für diesen Test habe ich Ubuntu 21.10 ausschließlich in einer virtuellen Maschine getestet. Grundsätzlich hat dabei alles wunschgemäß funktioniert. Einzig das Zusammenspiel mit Wayland hat Probleme verursacht (fallweise schwarzer Bildschirm, in Firefox kein Bild etc.). Ein neuerlicher Login mit X statt Wayland war die Lösung. Ob an den Problemen Wayland oder mein Virtualisierungssystem (KVM/QEMU) Schuld war, kann ich nicht sagen. Ähnliche Probleme hatte ich aber auch schon mit anderen Distributionen. Die Lösung hießt immer X.
Ich habe vor, mein Arbeits-Notebook nächste Woche auf Version 21.10 zu aktualisieren. Falls sich dabei neue Erkenntnisse ergeben (das ist anzunehmen), werde ich diesen Artikel noch einmal aktualisieren. Insbesondere möchte ich testen, wie gut Wayland mit den proprietären NVIDIA-Treibern harmoniert. (Die aktuelle Version der NVIDIA-Treiber ist erstmalig Wayland-kompatibel, aber zumindest laut Fedora-Berichten ist die Sache noch nicht richtig stabil.)
Praktische Erfahrungen (Update 4.11.2021)
Mittlerweile habe ich mein Notebook mit do-release-upgrade aktualisiert. Prinzipiell funktioniert das meiste. Anmerkungen:
Firefox (Snap) lässt sich bei mir nicht starten, weil ich — zugegebenermaßen non standard — eine eigene verschlüsselte Partition verwende, in dem sich mein Home-Verzeichnis befindet (daher der Pfad /crypt/home/kofler). Snap ist damit schon seit vielen Jahren überfordert (siehe hier). Diese Einschränkung lässt sich zur Not mit bind-Mounts umgehen. Wenig kundenfreundlich ist der Umstand, dass beim Start von Firefox auf dem Desktop nicht einmal eine Fehlermeldung erscheint. Klarheit schafft erst ein Start in einem Terminal. Na ja, für mich heißt die Lösung sudo snap remove firefox.
do-release-upgrade deaktiviert alle nicht-offiziellen Paketquellen. Dieses Verhalten ist zwar nicht neu, die manuelle Reaktivierung wird aber bei immer mehr eigenen Paketquellen für Chrome, Syncthing, Teams, VSCode usw. zunehmend mühsam.
Die neue Gnome-Version (na ja, so neu ist Version 40 gar nicht …) ist, wie üblich, zu einigen der von mir genutzten Shell Extensions inkompatibel. Das ist nicht immer ernst zu nehmen. In zwei Fällen hat es gereicht, in die Datei .local/share/gnome-shell/extensions/<extension-name>/metadata.json einfach eine neue Versionsnummer hinzuzufügen, also z.B. "40.0".
Die automatische Monitorabschaltung nach ein paar Minuten ohne Aktivität funktioniert nur noch sporadisch. Wenn ich den Rechner explizit in den Ruhemodus befördere, funktioniert aber alles, wie es soll (inklusive des Wiederaufwachens).
Fazit
Ich habe in den letzten Jahren Ubuntu als Standarddistribution auf meinem wichtigsten Arbeitsrechner verwendet (einem Lenovo-Notebook). Ja, ich habe mehr Rechner und noch viel mehr virtuelle Maschinen, auf denen ein buntes Sammelsurium von Distributionen läuft. Aber grundsätzlich hat sich Ubuntu in den letzten Jahren für mich gut bewährt; es läuft stabil, ich hatte selten ernsthafte Probleme (auch nicht mit Versionen außerhalb des LTS-Zyklus), selbst Microsoft Teams läuft (das brauche ich gelegentlich beruflich) und bin eigentlich zufrieden mit dem, was ich habe. Ganz pragmatisch: Es hat durchaus Vorteile, mit dem Linux-Mainstream mitzuschwimmen.
Bei Snap endet meine Liebe zu Ubuntu aber. Bisher war mein Ansatz, Snap samt allen dort mitgelieferten Paketen einfach zu deinstallieren. Noch ist das möglich: Ich kann Firefox durch ein APT-Paket oder gleich durch Google Chrome ersetzen, und statt dem snap-store verwende ich sowieso apt. Sollte ein Snap-freier Betrieb von Ubuntu irgendwann nicht mehr möglich sein, dann wird es mir sicher gelingen, mich mit einer anderen Linux-Distribution anzufreunden :-)
