Raspberry Pi's Raspbian OS Finally Spins 64-bit Version

[rclark]

...would have experienced a soft brick

I missed that misstep... I only update when I get into an RPI which sometimes can be weeks if not months between checking.

[DrYak]

{...} nor were they designed to be (outside of exposing tinkerers to Python and electronics). {...} I love my Pis, I replaced a proper VM host with a few Pis, each handling tasks that fit within the constraints of the CPU and RAM (domain controllers, file servers, Docker running Minecraft server, and a low-throughput VPN concentrator for remote admin sessions),. Now things use a LOT less power and have much simpler upkeep,

Same here: Pi and other similar SBC are nice tools to play with and do some semi serious development/hosting of tiny services.
One of the biohackathon I took part in, we ran the demo server on a Pi.
And I user one for some home server+remote access purposes.

but I wouldn't use a Pi as a daily driver, even for browsing and email.

One of my daily driver while I am on the road is a roughly-similar hardware-class: Pine64's PineBook Pro (RK3399-based with 4GiB RAM).
But my use case need is very unusual:
Most of my work happens on the command-line (so technically even a 3 decade old 386 could do), with me only editing files locally and dispatching most of the command to a (very large and very powerful) HPC at my University (ETHZ).
The only tasks running on the local graphical interface are the browser and the editor (mostly using KDE's Kate with the sftp KIO plugin for remote access) and such machines are adequate for that and the absolute tiny power requirement is a big bonus (netbook's battery lasts forever, and I can top it up with the same 5V powerbank that I use for my phone).

So I could use a Raspberr Pi 400 as a daily driver, but that's because I don't do what 99% of regular computer users do.

(At some point in the past, my "while on the move" setup has been a Palm OS powered PDA running with an SSH client, docked into a foldable keyboard (serial, then Bluetooth), and using a dumbphone as a wireless access point (IrDA then later over Bluetooth) and that used to be enough)

Nothing will be thin enough to give a Pi a better experience than a low-end smartphone or a fifteen year-old laptop.

Smartphone have the draw back of tiny screens and poor input devices. (even psion-like keyboard limits a bit for long coding sessions)
One could compensate by lugging around a combo of a good foldable keyboard (I actually still have my 4-segment stowaway from back in the PalmOS days) and one of these tablet-sized screen with USB-C or microHDMI inputs.

But you're going to lug stuff around, you might as well go for a netbook.

(Another solution I've seen people use: lug a tablet/keyboard combo around, and SSH into a USB-C connected Pi4. GUI and editor run on the tablet, linux dev env on the Pi)

3
I run Manjaro 64 bit on my rpi4 8GB. I use it as an adblocking DNS for my lan.
Manjato ARM is great!

I second that opinion: Manrajo RAM on my Pinebook Pro.

But now the GPU bits (OpenGL and Vulkan) are getting more mature in mesa, shouldn't they put their focus on getting accelerated video decoding working in upstream Linux kernels as well?
I mean they can't just keep relying on these blobs with a fixed kernel version forever?

As others have pointed out, the Pi's CPU has a weird architecture where the GPU has an entire own 32bit real-time OS running on it. This also contributes to making opensource acceleration GPU a bit more complex.

[jaxa]

I mean, it has the horsepower of a fifteen year-old mid-range mobile chip (Core 2 Duo P8400), and half the single-thread performance. People seem to think these things are powerhouses held back by software limitations or bloat, but they're just not adequate for desktop use, nor were they designed to be (outside of exposing tinkerers to Python and electronics).

The MT8173 outperforms the Pi 4 even when the Pi is overclocked. Software limitations or the weird Broadcom VideoCore GPU are probably to blame.

Pi 5 will probably be considered adequate for desktop use unless something like the GPU holds it back.

[Jabberwocky]

I've been using the beta PI OS 64 since it came out. For me it has been very solid, but then I wasn't really 'testing' it. I run it headless on a RPI4 4G booting off a USB 3.0 SSD . I've been using it as a way to learn 64Bit Arm Assembly for the most part. So my usage has been SSH, SFTP and nano. I'll be using it only on my RPI4s and CM4s. Glad to see it finally officially released. If only you could find a RPI4 or CM4 in the wild. Seem really scarce right now.

Note that in the 32 bit PI OS, an application 'only' could get 3GB (1GB of the 4GB potential is reserved) of memory to use, whereas the 64bit, it is all available. Not that there are many applications that need that much memory! Another advantage of the 64bit, is more CPU registers available to use, so potentially more efficient.

If you frequently ran apt full-upgrade you would have experienced a soft brick and the controversial Microsoft repo & gpg keys: https://github.com/RPi-Distro/raspbe...f3c1104ccb4351

I hope these "mistakes" are a thing of the past. I'll be reinstalling some of my devices.

[brent]

But now the GPU bits (OpenGL and Vulkan) are getting more mature in mesa, shouldn't they put their focus on getting accelerated video decoding working in upstream Linux kernels as well?
I mean they can't just keep relying on these blobs with a fixed kernel version forever?

That's not how it works. There is Linux-side open-source accelerated video support nowadays. It's just not mainline. Some parts of the actual accelerator run on the VIdeoCore CPU, but they have a rather stable interface so you aren't bound to specific kernel versions.

[direc85]

Speaking of a fixed kernel, that Sagemcom cable modem I got - new, in the box, "the latest model" - from my ISP last year had a Linux kernel 2.6.xx in it. RPi using an older five-series isn't that awful...

[MastaG]

That's a very different scenario to what OP is asking, which was "s video decoding in hardware (h.264 & h.265) working now?", and the answer to that is a solid "no", the same way it's always been, other than when running an extremely-hacked version of VLC, and only on raspbian's very-modded 32-bit kernels.

The fact that you can use a pi4 to *transcode* video, provided you DON'T have a DRM client running, isn't of any use to anyone attempting to e.g. watch YouTube on it inside a desktop session. I'm pretty sure that's the context the OP was asking about.

But now the GPU bits (OpenGL and Vulkan) are getting more mature in mesa, shouldn't they put their focus on getting accelerated video decoding working in upstream Linux kernels as well?
I mean they can't just keep relying on these blobs with a fixed kernel version forever?

[Etherman]

3

Raspbian has to be the worst OS for Raspberry Pi, although in all fairness Ubuntu and Fedora are also pretty bad. Despite being averse to Arch Linux, I must admit that Manjaro is by far the best if you want to run something graphical, Raspbian is a lag-fest no matter how lightweight your desktop environment.

I run Manjaro 64 bit on my rpi4 8GB. I use it as an adblocking DNS for my lan.
Manjato ARM is great!

[mangeek]

Raspbian has to be the worst OS for Raspberry Pi, although in all fairness Ubuntu and Fedora are also pretty bad. Despite being averse to Arch Linux, I must admit that Manjaro is by far the best if you want to run something graphical, Raspbian is a lag-fest no matter how lightweight your desktop environment.

I mean, it has the horsepower of a fifteen year-old mid-range mobile chip (Core 2 Duo P8400), and half the single-thread performance. People seem to think these things are powerhouses held back by software limitations or bloat, but they're just not adequate for desktop use, nor were they designed to be (outside of exposing tinkerers to Python and electronics).

I love my Pis, I replaced a proper VM host with a few Pis, each handling tasks that fit within the constraints of the CPU and RAM (domain controllers, file servers, Docker running Minecraft server, and a low-throughput VPN concentrator for remote admin sessions),. Now things use a LOT less power and have much simpler upkeep, but I wouldn't use a Pi as a daily driver, even for browsing and email.

I am hoping that GTK4's Vulkan GSK back-end opens some options for very lightweight modern desktop development, but it's still going to be inadequate for day-to-day use. Nothing will be thin enough to give a Pi a better experience than a low-end smartphone or a fifteen year-old laptop.

[caligula]

That's a very different scenario to what OP is asking, which was "s video decoding in hardware (h.264 & h.265) working now?", and the answer to that is a solid "no", the same way it's always been, other than when running an extremely-hacked version of VLC, and only on raspbian's very-modded 32-bit kernels.

The fact that you can use a pi4 to *transcode* video, provided you DON'T have a DRM client running, isn't of any use to anyone attempting to e.g. watch YouTube on it inside a desktop session. I'm pretty sure that's the context the OP was asking about.

Don't know about h265, but I've used Void Linux & Kodi on the original Pi. Works just fine. Are they using Raspbian kernels?