Raspberry Pi OS 12 Bookworm ist da: Neuigkeiten & Änderungen

Als Video ansehen
Bereitgestellt über YouTube

Raspberry Pi OS 12 Bookworm ist da: Neuigkeiten & Änderungen

Raspberry Pi Betriebssysteme, Videobeitrag DMW007

Noch bevor der Raspberry Pi 5 in den Handel kam, wurde eine neue Version des offiziellen Betriebssystems Raspberry Pi OS veröffentlicht. Es heißt Bookworm und umfasst gleich mehrere größere Änderungen. Aber auch kleinere Dinge wurden verbessert.1 Ich fasse die wichtigsten Neuerungen sowie Änderungen zusammen und ordne diese ein. Außerdem klärt dieser Beitrag ein paar Fragen, die sich einige von euch sicher stellen – beispielsweise, ob sie aktualisieren können oder müssen bzw. wann dies der Fall sein wird.

Was ist neu in Debian 12 Bookworm?

Das Raspberry Pi OS basiert auf Debian 12, eine der ältesten aktiv gepflegten GNU/Linux-Distributionen. Dessen Neuerungen habe ich in einem eigenen Beitrag bereits ausführlich vorgestellt. Einige Monate später erscheint ein neues Raspberry Pi OS, welches jedoch nicht alle Änderungen von Debian übernimmt.

Unfreie Firmware

Zu den Highlights von Debian 12 gehört erstmals das Laden unfreier Firmware in offiziellen Installationsmedium. Das galt bisher als rote Linie, weil die Distribution sich stark zu freier Software bekennt. Für den Raspberry Pi ist dies wenig relevant: Mangels Bios/Uefi benötigt er ohnehin ein angepasstes Abbild. Der Pi ist nicht vollständig quelloffen, sodass hier schon immer proprietäre Treiber notwendig waren – in der Hinsicht ändert sich also nichts.

Das Raspberry Pi OS ist beim Kernel schneller als Debian

Beim Kernel geht der Einplatinencomputer einen ganz anderen Weg: Linux 6.1 ist neu in Debian 12, da die Distribution nach der Veröffentlichung einer Hauptversion nur noch Sicherheitsupdates und schwerwiegende Fehlerkorrekturen ausliefert. Debian 11 ist und bleibt daher auf Linux 5.10. Für neue Funktionen und damit auch größere Kernelsprünge muss man auf die nächste Debian Hauptversion warten, beim Linux-Kernel ist das Debian 12. Das sorgt einerseits für Stabilität – jedoch ebenfalls für Software, die mit der Zeit veraltet.

Das Raspberry Pi OS dagegen spielt neue Kernel-Hauptversionen auch in der Hauptversion eines Raspberry Pi OS aus: So wurde das Raspberry Pi OS 11 Bullseye mit Linux 5.4 ausgeliefert, bis es im Mai 2023 bereits auf Linux 6.1 aktualisiert wurde – noch bevor die stabile Version von Debian 12 erschienen ist. Linux 6.1 ist daher nur für Debian 12 neu, nicht aber für das Raspberry Pi OS 12. Dieser Unterschied ist auch dokumentiert: Es wird ein eigener Kernel verwendet und eigenständig auf Basis des Vanilla-Kernels stetig aktualisiert.2

Über 64.000 Softwarepakete

Am relevantesten dürfte für den Debian-Unterbau dessen umfangreiches Softwarearchiv sein: Über 43.000 haben eine Aktualisierung erhalten. Rund 6.000 mussten entfernt werden, wobei dadurch nicht zwingend Programme wegfallen. Teilweise enthalten Pakete die Hauptversion, z.B. php5*). Im Falle eines Upgrades würde man dieses alte Paket löschen und ein neues anlegen, das entweder die neue Hauptversion oder gar keine mehr im Name trägt. Wenngleich sicherlich auch ein paar aus anderen Gründen (etwa keine Pflege mehr) entfernt wurden, sind mehr als 11.000 gegenüber dem Vorgänger hinzu gekommen – das Angebot ist somit in jedem Falle gewachsen.

Insgesamt stehen mehr als 64.000 Pakete zur Verfügung.3 Dies ist nicht mit der Anzahl an direkt nutzbaren Programmen gleichzusetzen: Manche enthalten Bibliotheken, die wiederum als Abhängigkeit für Programme dienen. Trotzdem ist dies eine beachtliche Menge. Ich habe bereits mehrere andere Betriebssysteme für den Raspberry Pi getestet. Das auf Arch Linux aufbauende Manjaro kommt beispielsweise mit rund 11.600 Pakete nur auf einen Bruchteil des Softwareangebots.

Ein paar wenige Programme, die speziell den Raspberry Pi Treffen, mussten entfernt werden: Der SenseHAT Emulator ist noch nicht mit Bookworm kompatibel, bei BlueJ und Greenfoot (beides Java Entwicklungsumgebungen) mangelt es an Wayland-Unterstützung. Sie sollen wieder zurück kommen, wenn die Probleme von den zuständigen Entwicklern behoben wurden. Die Lupe wurde entfernt, weil sie unter Wayland nicht funktioniert. Dort ist jedoch bereits ein vergleichbares Werkzeug eingebaut, das sich mit [STRG] + [ALT] + [M] aktivieren lässt.

Die Geschichte hinter Wayland zusammengefasst

Eines der größten Migrationen in der Desktop-Welt von GNU/Linux dürfte die Migration des Displayservers sein: Mittlerweile fast vier Jahrzehnte lang wurde X11 als Protokoll eingesetzt, meist durch die Referenzimplementierung X.Org. Seit einiger Zeit wechseln viele Desktopumgebungen und damit auch Distributionen zu Wayland, welches als Nachfolger angesehen wird. Es soll das komplexe X11 schlanker machen, mehr Sicherheit bieten und zudem Anzeigefehler auf modernerer Hardware vermeiden. Was hinter X11 und Wayland steckt, habe ich zusammen mit den Unterschieden in diesem eigenen Beitrag ausführlicher dargestellt.

Während Debian bereits 2016 mit der Arbeit an Wayland begann und für die Desktopumgebung Gnome den Standard-Bildschirmserver 2019 dahin wechselte, war es beim Raspberry Pi OS lange Zeit ruhig. Wie beim Kernel geht die Distribution eigene Wege. Das überrascht wenig: Schließlich setzt man auf die 2016 vorgestellte hauseigene Desktopumgebung namens PIXEL, die wiederum auf LXDE aufbaut – allerdings mit starken Anpassungen.4 Mit einer Aktualisierung für Bullseye wurde 2022 experimentelle Unterstützung für Wayland in das Raspberry Pi OS eingebaut. Im Jahr zuvor hatte man den Fenstermanager von Openbox zu Mutter migriert, um dies vorzubereiten. Standardmäßig aktiv war aber weiterhin X11 und es wurde ausdrücklich davon abgeraten, Wayland zu nutzen. Es befand sich in einem frühen Stadium, in dem einiges noch nicht funktioniert wie z.B. Bildschirmfotos erstellen oder sämtliche Fernwartungslösungen. Außerdem war noch nicht alles portiert, weil die Unterstützung für bestimmte Funktionen in Wayland fehlte.5

Wayland statt X11 als Bildschirmserver

Etwa 1,5 Jahre später sieht die Lage schon ganz anders aus: Mit Bookworm wird Wayland nicht nur für Stabil erklärt. Man löst den Fenstermanager (compositor) Mutter ab, da er sich als zu langsam und schwerfällig erwies. Seine Aufgabe übernimmt Wayfire: Er hat sich als deutlich bessere Wahl erwiesen, weswegen man den standardmäßig aktivierten Bildschirmserver mit dem Raspberry Pi OS 12 zu Wayland wechselte. Dies greift jedoch derzeit nur auf dem Raspberry Pi 4 und 5. Auf älteren Modellen ist die Leistung wegen der deutlich schwächeren Hardware nicht zufriedenstellend. Als Übergangslösung kommt dort weiterhin X11 mit Openbox zum Einsatz, dieser soll jedoch in Zukunft ebenfalls migriert werden.

Obwohl dieser Wechsel umfangreiche Anpassungen erforderte, sieht man als Nutzer kaum einen Unterschied – das bekannte Design 1:1 wurde nachgebaut. Die standardmäßig oben platzierte Taskleiste heißt nun wf-panel-pi (wf für Wayfire) statt lxpanel. Den Unterschied kann man also bei den laufenden Prozessen erkennen. Für die Anwendungen des Nutzers sind aktualisierte Versionen von den verbreiteten Bibliotheken GTK & Qt installiert. Sie erkennen und unterstützen Wayland, sodass es automatisch genutzt werden sollte.

Da die Programme selbst entscheiden, wie sie ihre Oberflächen gestalten, können auch andere Technologien zum Einsatz kommen – diese sind möglicherweise (noch) auf X11 angewiesen. Hierfür ist XWayland als Kompatibilitätsschicht vorhanden: Es startet einen X11-Server, der wiederum als Übersetzer zu Wayland dient. Er ist nicht 100% abwärtskompatibel, wenngleich Teile der bekannten Probleme den Raspberry Pi gar nicht betreffen, da diese z.B. auf Treiber von Nvidia zurück zu führen sind.

Neuer VNC-Server und bekannte Wayland-Probleme

Fernzugriffslösungen wie VNC/RDP haben es unter Wayland schwerer: Bei X11 konnte jedes Fenster auf alle anderen zugreifen – bequem für Fernzugriff und das Teilen des Bildschirmes in z.B. Jitsi und anderen Videokonferenzlösungen. Doch dies kann u.u. ein Sicherheitsrisiko darstellen. Daher verbietet Wayland standardmäßig sowohl den Zugriff auf andere Fenster, als auch systemweit auf Tasteneingaben. Das Raspberry Pi OS wechselt daher mit dem offiziellen VNC-Server von RealVNC zu WayVNC. Dieser ist restriktiver und unterstützt nicht mehr alle VNC-Clients. TigerVNC ist die offizielle Empfehlung, er wurde erfolgreich getestet.

Auf den älteren Raspberry Pis (Zero und 1-3), die noch nicht mit Wayland kompatibel sind, kommt weiterhin RealVNC zum Einsatz. Die 32 Bit Version ist jedoch derzeit nicht mit dem Raspberry Pi OS 12 Bookworm kompatibel. Da RealVNC proprietär ist, wird auf ein Update vom Hersteller gewartet. Bis dahin sollten betroffene beim Vorgänger 11 (Bullseye) bleiben, der weiterhin unterstützt wird (siehe unten).

Overscan funktioniert mit Wayland nicht mehr und wurde vorerst entfernt, dies sei bei vielen Bildschirmen nicht mehr notwendig. Da der Tray (rechts oben, gefüllt von im Hintergrund laufenden Programmen) technisch neu entwickelt wurde, müssen Programme die ihn verwenden angepasst werden. Möglicherweise erscheinen deren Symbole dort vorerst nicht, bis sie auf die neue Technologie angepasst wurden.

Sichtbare Neuerungen am Raspberry Pi Desktop

Während der Wechsel zu Wayland im besten Falle vom Benutzer bewusst verborgen bleiben soll, gilt dies nicht für Erweiterungen des Raspberry Pi Desktops: Eine neue, standardmäßig aktive Erweiterung prüft, ob die Stromversorgung zu schwach ist – etwa durch angeschlossene USB-Geräte und/oder ein unterdimensioniertes Netzteil. In diesem Falle erscheint ein gelber Blitz im Bereich der Benachrichtigungen zusammen mit einer Benachrichtigung. Ich halte das für eine nützliche Idee, da viele Probleme durch eine unzureichende Spannungsversorgung verursacht werden. Beispielsweise die Verwendung von Ladegeräten statt Netzteilen oder anderen bekannten Gründen.

Weiter gibt es ein neues Widget für die Anzeige der GPU-Auslastung. Dies ergänzt das vorhandene, welches bisher nur anzeigen konnte, wie beschäftigt der Prozessor ist. Im Gegensatz zur Warnung bei der Spannungsversorgung ist es jedoch nicht standardmäßig aktiviert und muss erst manuell zur Startleiste hinzugefügt werden.

Wie Töne bisher abgespielt wurden

Für die Ausgabe von sämtlichen Tönen (angefangen bei Pieptönen bis hin zu Musik und Videos) wurde ursprünglich ALSA (Advanced Linux Sound Architecture) verwendet. Über Kernelmodule spricht es die Soundkarte an, um auf ihr Töne auszugeben – es ist also eine Low-Level Implementierung, die nah an der Hardware sitzt. Über ALSA werden diese Funktionen anderen Programmen zugänglich gemacht, z.B. einem Browser, der damit die Tonspur von Videos abspielt.

Es kann direkt angesprochen werden, seit einiger Zeit sitzt jedoch oft noch ein Soundserver dazwischen: Er kann weitere Funktionen zur Tonverarbeitung ermöglichen, die ALSA und Soundkarte so nicht bieten, etwa Effekte. Auch sind die Audioströme nicht an spezielle Hardware gebunden. Der Wechsel eines Notebooks an eine Docking-Station kann beispielsweise nahtlos erfolgen. Für Aufnahmen kann es hilfreich sein, logische Geräte zu erstellen, die mehrere Signale bündeln. Diese Abstraktionsschicht/Middleware bietet einige Vorteile bzw. hebt Einschränkungen auf, während sie die Reaktionszeiten im Vergleich zum direkten Zugriff leicht erhöht.67

PipeWire gibt nun den Ton an – warum?

Das Raspberry Pi OS setzte bisher PulseAudio als Zwischenschicht ein, nachdem sie anfangs direkt ALSA verwendet haben. Mit Version 12 wurde PulseAudio durch PipeWire ersetzt: Es ist deutlich jünger (2017) als PulseAudio (2004). Es gibt neben PulseAudio noch weitere bedeutenswerte Soundserver wie etwa JACK.8 Sie kamen beim Raspberry Pi OS jedoch nicht zum Einsatz, weswegen ich an dieser Stelle nicht weiter darauf eingehe.

PipeWire fokussiert sich nicht nur auf Audio, sondern bezieht ebenfalls die Videosignale mit ein. Daher soll es solche kombinierten Multimedia-Ausgaben besser verarbeiten können, das Paradebeispiel sind Videos/Filme mit Tonspur. Die Reaktionszeiten möchte es reduzieren. Ein Soundserver kann zwar nie so schnell sein, wie ein direkter Zugriff auf die Grafikkarte – schließlich stellt er technisch ja immer einen Umweg dar, über den die Tonsignale gehen müssen. Aber wie bei jeder Software kann man dies natürlich optimieren und dadurch mehr oder weniger effizient implementieren. PipeWire möchte zu ersteren gehören.

Darüber hinaus bietet es kleine Verbesserungen, die im Alltag für manche sicher nützlich sein können. Beispielsweise merkt es sich die verbundenen Bluetooth-Geräte und versucht beim Start, sich erneut mit diesen zu verbinden. Der wichtigste Grund für den Wechsel dürfte jedoch sein, dass PipeWire durch sein geringes Alter isolierte Anwendungen unterstützt. Hier kommt der zuvor bereits angesprochene Wechsel von X11 zu Wayland ins Spiel: Beispielsweise werden Screencasts unterstützt, die ohne weiteres mit Wayland aus Sicherheitsgründen nicht mehr möglich sind.9 Darüber hinaus gibt es noch weitere Anwendungsfälle in der GNU/Linux-Welt für isolierte Software, wie etwa Flatpack.10

Ähnlich wie beim Wayland/X11-Wechsel soll der Nutzer von dieser Änderung wenig mitbekommen: Das Aussehen von z.B. dem Lautstärkenregler in der Taskleiste ist gleich geblieben. Was sich ändert, ist die Technik dahinter. Spielt man beispielsweise einen Film oder eine Musikdatei ab, wird das Audiosignal unter Bookworm an PipeWire statt PulseAudio weitergereicht, um es über das Ausgabegerät (z.B. Kopfhörer, im Bildschirm integrierter Lautsprecher, usw) abzuspielen.

Mehr Funktionen dank NetworkManager

Bisher setzt das Raspberry Pi OS auf dhcpcd, ein DHCP-Client. Er ist hauptsächlich dafür verantwortlich, dass der Raspberry Pi eine IP-Adresse bekommt, wenn er sich in einem (Heim-) Netzwerk verbindet.11 Üblicherweise haben alle (WLAN)-Router einen DHCP-Server. Dieser vergibt eine freie IP-Adresse an Computer, die einen DHCP-Client (hier dhcpcd) besitzen. Somit funktioniert die Netzwerk (und damit meist auch Internetverbindung), ohne dass händisch eine freie IP-Adresse vergeben werden muss. Für WLAN-Netzwerke greift dhcpcd auf wpa_supplicant zurück.12

Grundlegend hat das funktioniert, aber der Funktionsumfang von dhcpcd ist beschränkt. NetworkManager entstand 2004 bei Red Hat und möchte als zentrale Anlaufstelle für alle Netzwerkeinstellungen dienen.13 Er kann alles was dhcpcd bisher tat und noch mehr: Beispielsweise unterstützt er versteckte WLAN-Netzwerke, VPN-Verbindungen sowie die Möglich, einen WLAN-Zugriffspunkt (Hotspot) einzurichten. Bisher konnte man all dies technisch auch auf anderem Wege umsetzen. Allerdings erforderte dies die Installation & Einrichtung von zusätzlicher Software, was für weniger versierte Nutzer eine Herausforderung darstellen kann. Zudem war die Integration in die Desktopumgebung des Raspberry Pi OS nur eingeschränkt oder gar nicht gegeben.

Mit dem Wechsel zum NetworkManager ändert sich das: Über das Netzwerk-Symbol rechts oben finden sich in den Erweiterten Optionen nun Menüeinträge für diese Funktionen. Nutzer können mit Bookworm über die grafische Oberfläche etwa eine VPN-Verbindung herstellen, ohne externe Software selbstständig installieren und einrichten zu müssen.

Warum es Firefox auf dem Raspberry Pi braucht

Um im Web zu surfen, bot das Raspberry Pi OS bislang lediglich Chromium – das quelloffene Projekt von Google, welches die Grundlage für Google Chrome darstellt. Entgegen des Namens & vermittelten Eindrucks ist es jedoch keinesfalls frei von sämtlichen der zahlreichen Diensten des Konzernes, sondern sammelt trotzdem viele Daten. So viele, dass ein eigenes Projekt namens Ungoogled Chromium notwendig ist, um sie alle zu entfernen. Neben der exzessiven Datensammlung gibt es noch weitere Gründe, warum die Verwendung von Googles Browser keine gute Idee ist: So hat der Konzern längst um die 50% Marktanteile in Deutschland, international sogar deutlich mehr.14 Diese Macht kann missbraucht werden. Beispielsweise konnte Google damit neue Standards schaffen, die nicht unbedingt im Sinne der Nutzer sind – die Web Environment Integrity API (WEI) ist ein aktuelles Beispiel dafür. So etwas kann der Konzern problemlos in seinen eigenen Browser einbauen und erreicht damit sehr viele Nutzer – ohne großartige Diskussionen zu führen, wie es alle anderen tun müssten, um von ihrem Vorhaben zu überzeugen.

Mozilla Firefox ist der letzte alternative (OS) Browser mit nennenswertem Marktanteil, der eine eigene Engine besitzt und plattformübergreifend verfügbar ist. Ansonsten ist mittlerweile nur noch Apples Safari übrig, auf den 2/3 dieser Eigenschaften nicht (mehr) zutreffen. Wer GNU/Linux oder Windows nutzt, hat effektiv bloß noch die Wahl zwischen Chromium (direkt oder über Forks) und Firefox. Sollte Firefox verschwinden, gibt es überhaupt niemanden mehr, der Google irgend etwas entgegen setzen könnte.

Ein neuer alter Browser ist da: Willkommen Firefox!

Das zeigt, wie wichtig Firefox ist. Anscheinend hat das auch das Raspberry Pi Team erkannt und unterstützt mit Version 12 ihres Betriebssystems den freien Browser offiziell. Zwar konnte man ihn zuvor schon installieren, da er in den Paketquellen von Debian enthalten ist, auf denen das RPIOS basiert. Dies hatte jedoch mehrere: Die dort bereitgestellte Version war schnell veraltet, da Hauptversionen von Debian erst in der nächsten Debian-Hauptversion verfügbar sind. Noch problematischer im Alltag ist jedoch die fehlende Hardwarebeschleunigung. Schaute man beispielsweise Videos an, lief das komplett über den Prozessor, während der Grafikprozessor Däumchen drehte. In der alltäglichen Nutzung lief Chromium daher deutlich besser und es blieb daher leider bislang gar keine andere Wahl, als zu Googles Browser zu raten.

Durch die offizielle Unterstützung entfallen diese Nachteile, welche Firefox bisher auf dem Raspberry Pi hatte. Er kann für den V4L2 Codec beispielsweise den Hardware-Decoder für die verbreitete h.264 Kompression verwenden. Dies soll die CPU-Last reduzieren und damit die Leistung verbessern. Darüber hinaus ist nun auch der bekannte und berüchtigte Widevine Kopierschutz eingebaut. So umstritten DRM v.a. in der GNU/Linux-Welt auch ist: Viele Streamingdienste wie z.B. Netflix sind durch ihre Marktmacht in der Lage, ihn zu erzwingen. Wer solche Anbieten nutzen möchte, kommt um einen Browser, der ihn eingebaut hat, nicht herum.

Wer die Voreinstellungen nicht nutzt, wird beim ersten Start durch den Einrichtungsassistent gefragt, welcher der beiden Browser verwendet werden soll. Zusätzlich bietet sich die Möglichkeit, den anderen, nicht ausgewählten zu entfernen. Ohne diesen Haken hat man beide Browser auf dem System und kann sie über das Programm-Menü je nach Wunsch starten.

Was passiert mit den Vorgängern? Wer muss Handeln?

Bis 2021 wurde die Unterstützung des Vorgängers eingestellt, sobald eine neue Hauptversion des Raspberry Pi erschien. Das war ziemlich kurzfristig, um bestehende Software zu testen und falls nötig Anpassungen vorzunehmen. Seit dem wird immer die aktuellste und vorherige Version unterstützt, letztere mit dem Namenszusatz Legacy. Die Legacy-Version erhält Updates, wird aber auf keine neuen Pis mehr portiert, die nach dem Veröffentlichungsdatum des Betriebssysteme erscheinen.

Konkret bedeutet dies: Das Raspberry Pi OS 12 Bookworm ist die neueste Version, während 11 Bullseye zu Legacy wird. Version 11 wird so lange unterstützt, bis 13 erscheint. Allerdings nur auf dem Raspberry Pi 4 und älter, weil der Pi5 ja später erschienen ist. Auf dem neuesten Raspberry Pi 5 läuft daher ausschließlich Bookworm. Das Raspberry Pi OS 10 (bisher Legacy) fällt komplett aus der Unterstützung heraus – wer es verwendet, sollte zeitnah auf 11 oder 12 aktualisieren bzw. neu installieren.

Kann ich von Raspberry Pi 11 auf 12 upgraden, ohne Neuinstallation?

Von den Entwicklern selbst wurde schon immer empfohlen, neu zu installieren. Das In-Place Upgrade von z.B. 10 auf 11 ohne Neuinstallation haben sie nicht unterstützt. Wenngleich dies möglich war, denn die Debian-Basis tut dies: Im wesentlichen aktualisiert man die Paketquellen auf das neue Release, aktualisiert sämtliche Pakete und ist dann auf einer neuen Hauptversion. Die Möglichkeit von kleineren oder größeren Problemen besteht grundsätzlich, da ein neues Debian-Release nicht zwingend abwärtskompatibel ist. Dies variiert aber stark, je nachdem was man einsetzt und wie viel am System angepasst wurde. Einige haben daher den Debian-Weg auch auf dem Raspberry Pi angewendet, mehr oder weniger erfolgreich. Meine Empfehlung war bisher: Wer nicht neu installieren möchte, soll eine Sicherung erstellen und es ausprobieren. Läuft alles gut, hat er sich den Aufwand gespart. Gibt es Probleme, kann er sie versuchen zu lösen. Wird der Aufwand zu groß, hat man durch die Sicherung eine funktionierende Installation und kann immer noch neu installieren.

Beim Raspberry Pi OS 12 wird ein Upgrade von offizieller Seite nicht nur nicht unterstützt: Man rät ausdrücklich davon ab, weil durch die massiven Änderungen der Pi mit 12 in vielen Fällen den Start verweigern soll. Dies ist berechtigt und ein Vergleich mit Debian greift hier zu kurz: Wie dieser Artikel gezeigt hat, enthält das RPIOS12 viele Veränderungen/Neuerungen, die in Debian so nicht existieren. Vor allem auf dem Desktop sehe ich das größte Risiko, weil sich dort die meisten getan hat. Technisch Möglich ist ein Upgrade von 11 auf 12 grundsätzlich nach wie vor. Wer es dennoch damit versuchen möchte, sollte unbedingt vorher eine Sicherung anlegen, diese prüfen und im Falle eines erfolgreichen Upgrades das System gründlich testen!

Fazit

Im Raspberry Pi OS 12 hat sich vieles verändert, um alte Software und Protokolle zu ersetzen, die nach Jahrzehnten zunehmend an Grenzen stoßen. Alle für den Raspberry Pi spezifischen Änderungen, die in Debian nicht enthalten sind, betreffen den Desktop. Vieles davon wird man (außer im Falle möglicher Probleme) gar nicht bemerken, weil das Aussehen gleich geblieben ist und optisch eher Kleinigkeiten dazu gekommen sind. Durch den Wechsel zu Wayland rechne ich jedoch damit, dass einzelne Programme nicht (richtig) funktionieren – vor allem jene, die von den neuen Sicherheitsfunktionen betroffen sind, etwa zur Aufnahme des Bildschirms. Hier wird der eine oder andere U-Labs Beitrag überarbeitet oder gar neu erstellt werden müssen.

Wer den Raspberry Pi als Micro-Server oder anderweitig ohne grafische Oberfläche verwendet, ist davon nicht betroffen. Doch auch in diesem Fall profitiert er von aktualisierten sowie neuen Paketen, die durch Debian 12 als Unterbau den Weg auf den Raspberry Pi finden. Vor allem wenn Container-Technologien wie Docker verwendet werden, mag das wenig Anreiz für ein Upgrade sein – dort bekommt man aktuelle Software unabhängig von der GNU/Linux-Distribution.

In solchen Fällen kann man mit dem Wechsel ruhig noch eine Weile warten: Das RPIOS11 wird bis zum Erscheinen von Version 13 unterstützt. Ein konkretes Datum ist dafür zwar nicht bekannt. Anhand Erfahrungen aus der Vergangenheit sollte das noch ca. 2 Jahre bis etwa zum Herbst 2025 dauern. Notwendig ist das RPIOS12 nur in Verbindung mit dem ebenfalls neuen Raspberry Pi 5, alle anderen haben noch Zeit.

Quellen

  1. https://www.raspberrypi.com/news/bookworm-the-new-version-of-raspberry-pi-os/ ↩︎
  2. https://www.raspberrypi.com/documentation/computers/linux_kernel.html ↩︎
  3. https://www.debian.org/releases/bookworm/amd64/release-notes/ch-whats-new.de.html ↩︎
  4. https://www.raspberrypi.com/news/introducing-pixel/ ↩︎
  5. https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/ ↩︎
  6. https://wiki.ubuntuusers.de/ALSA/ ↩︎
  7. https://runmodule.com/2021/12/11/linux-sound-servers/ ↩︎
  8. https://wiki.ubuntuusers.de/JACK/ ↩︎
  9. https://blogs.gnome.org/uraeus/2018/01/26/an-update-on-pipewire-the-multimedia-revolution-an-update/ ↩︎
  10. https://pipewire.org/ ↩︎
  11. https://wiki.archlinux.org/title/Dhcpcd ↩︎
  12. https://wiki.archlinux.org/title/Wpa_supplicant ↩︎
  13. https://networkmanager.dev/ ↩︎
  14. https://gs.statcounter.com/browser-market-share/all/ ↩︎

Leave a Reply