Raspberry Pi OS Updated For Debian 11 Bullseye, Desktop Transitions To GTK3+Mutter

[willmore]

Their blog post still recommends this method but they also link to a forum post with an upgrade explanation

https://forums.raspberrypi.com/viewtopic.php?t=323279

Thanks, it looks like they still don't have their act together. Debian, Ubuntu, Fedora can all upgrade an existing system, but RPI can't manage it.

[GrayShade]

I doubt the ~80mb gnome-shell uses (Gnome 41, Fedora, tested on Pinebook Pro) currently would effect any of those board versions, but we do not talk about Gnome Shell, we talk about standalone mutter. I suspect a 10-20mb ram usage depending on what they put on top of it and that is neglect-able for any system.

430 MB for gnome-shell and on my x86-64 Wayland system, but I agree on principle regarding the memory usage. On the other hand, the performance of GNOME could be better, even on midrange hardware, which the Pi isn't.

[leo_sk]

I doubt the ~80mb gnome-shell uses (Gnome 41, Fedora, tested on Pinebook Pro) currently would effect any of those board versions, but we do not talk about Gnome Shell, we talk about standalone mutter. I suspect a 10-20mb ram usage depending on what they put on top of it and that is neglect-able for any system.

I doubt mutter will run in isolation though. Gnome-shell is a subprocess (a plugin more accurately) of mutter, not other way around

[Britoid]

I doubt mutter will run in isolation though. Gnome-shell is a subprocess (a plugin more accurately) of mutter, not other way around

It does...

Mutter itself is fairly lightweight, it just isn't really meant to be used by itself.

[hax0r]

One drawback of mutter is that, due to needing to draw the entire screen to memory before it can display it, it is quite demanding in terms of RAM, and can only run properly on a Raspberry Pi with 2GB or more.

This doesn't explain why you need a hike in RAM requirement to 2GB to run the DE, a typical resolution, 1920 x 1080 x 4 = 2073600 pixels * 4 (32-bit ARGB depth) = 7.91MB, needs about 8MB of memory to hold the screen contents and send it to a framebuffer.

The reason behind outrageous 2GB requirement to run a DE is probably the overall bloat, not to mention gjs javascript engine being used in gnome-shell.

[Jabberwocky]

Great that they're aiming for Wayland support, but a bit unfortunate that the 64-bit version is not becoming standard. I've been using the 64-bit version without issues for a while now, and it makes sense since Raspberry Pi 4 has a popular 8GB model available.

If you are just booting up the Pi 4 and using it as a "server" not updating it too often then it will probably work for you. If you are using it for a desktop or running other distros on it and want to make use of low-level interfaces and advance power configs then I would advise to use 32bit.

I've been using the 64bit version for just over 2 years. There have been some issues like softbricking your device when you run apt full-upgrade. Smaller issues like the default web browsers not getting updates. I suspect it won't become the standard because it's too much work to support the glue that makes the entire SoC work: https://github.com/raspberrypi/userland perhaps in half a decade when there's greater demand for 64bit then they will focus more on it. For now get used to using old packages and segfaults in userland software interacting with the GPU "directly".

Raspberry Pi OS' chromium-browser has not been built since late 2018. AFAIK it defaults to bullseye now (hence the article) but that version is from April 2021. If you add sid manually you're still only getting the 2021-08-31 version. It's better than it was 2 years ago, but there's still a very long way to go IMO. I hope the demand for it increases, but I'm not holding my breath.

[Chugworth]

Standalone Mutter is a great choice for that. Its the only stable and well working x11 and Wayland compositor, wlroots based compositors will only work for Wayland and Kwin is a joke as always.

As always people confuse Mutter with the most popular desktop using Mutter.

KWin/Wayland running here on three laptops and one desktop, and it's working very well.

[rclark]

At lunch, I updated one of my rpi4's, a 4G version, to the latest 'lite' Bullseye 64bit version. By update, I mean loaded a brand new image over the top of Buster on its external USB 3.0 SSD. At least none of the config files have changed names, nor locations for Ethernet setup which was nice to see. All reconfigured and running smooth. Loaded some missing compilers and then had to head back to work as ran out of time. Most all of my RPIs run headless, so not to concerned about GUI changes, although, tonight I 'may' update my RPI-400 to the full version as it, by design, doesn't run headless.

[willmore]

At lunch, I updated one of my rpi4's, a 4G version, to the latest 'lite' Bullseye 64bit version. By update, I mean loaded a brand new image over the top of Buster on its external USB 3.0 SSD. At least none of the config files have changed names, nor locations for Ethernet setup which was nice to see. All reconfigured and running smooth. Loaded some missing compilers and then had to head back to work as ran out of time. Most all of my RPIs run headless, so not to concerned about GUI changes, although, tonight I 'may' update my RPI-400 to the full version as it, by design, doesn't run headless.

Talk about picking the worst way to 'update' a system I've ever heard.

[dkasak]

This doesn't explain why you need a hike in RAM requirement to 2GB to run the DE,

You don't. Exaggeration doesn't help make your point - it destroys credibility. I've been in Gnome for 3 days now, and htop is reporting that gnome-shell is using 264MB of resident memory. That's a long way from 2GB. Perhaps you don't have a handle on interpreting memory usage in Linux?

a typical resolution, 1920 x 1080 x 4 = 2073600 pixels * 4 (32-bit ARGB depth) = 7.91MB, needs about 8MB of memory to hold the screen contents and send it to a framebuffer.

For a non-composited desktop, yes. That's over. It's been over for a long time. In a composited world, you need this amount of memory PER APPLICATION WINDOW. This is the theoretical minimum. Is your desktop environment using double or triple buffering? Obviously that will mean either 2x or 3x the memory usage. Then there's each desktop itself - and this is *not* just your theoretical min 8MB - the desktop is not just a static image. A lot more memory is needed for modern desktops. Deal with it. This is not bloat simply because you're having an anti-Gnome rant. It's just how a composited desktop works.

The reason behind outrageous 2GB requirement to run a DE is probably the overall bloat, not to mention gjs javascript engine being used in gnome-shell.

<yawn> ... Whatever buddy.