It has less value now with arm64 as a common arch, but for the old armv6, a lot a packages are optimized and compiled for this old platform

The blog post offers some clues: e.g. they're using Wayland on the Pi 4 and 5 but still X11 on lower devices. It's a tight coupling of hardware and software that means they can best tailor the experience to specific devices. Not everyone needs it but it's nice for newbies (and the Pi is intended to be very approachable) to get sensible defaults out of the box.

You can do this with pre-built images. They can just install different packages on the rbpi3.img and the rbpi4.img, one with wayland one with x11.

If you don't want to use pre-built images you can also do this with metapackages.

Debian does package Raspberry Pi software [1] (firmware, kernel) and maintains images for each Pi [2] although it is an unofficial effort.

[1]: https://packages.debian.org/bookworm/raspi-firmware

[2]: https://raspi.debian.net/tested-images/

I've being running Debian on my Pi's since buster, and it's being without issues, the only downside would be the lack of support for devicetree overlays.

raspi-firmware is semi-officially maintained. But Raspberry Pi OS also has scripts to set flags on the eeprom like "vcgencmd" and "rpi-eeprom-update"

What I was saying these could be maintained in Debian.

I believe one of the biggest reasons is that because the boot process is very different from the way debian does things, it ends up needing significant changes from the starting tasks to do things. Along with that I think the original 32bit RPIs didn't support some version of the compiled binaries in the debian arm repos which meant that they weren't necessarily compatible.

These days on the 64bit version, I'm not sure why it needs that much either. I'd think that having a few new task-* metapackages that setup the boot and raspberry pi specific boot management stuff should be doable and then they could use the main debian packages I would think. There's probably something that's not obvious that makes things just incompatible enough that it isn't simpler to manage that way.

> I believe one of the biggest reasons is that because the boot process is very different from the way debian does things, it ends up needing significant changes from the starting tasks to do things. Along with that I think the original 32bit RPIs didn't support some version of the compiled binaries in the debian arm repos which meant that they weren't necessarily compatible.

No longer correct. Debian on new rPi "just installs" and boots. I think that also worked fine on rPi3

https://wiki.debian.org/RaspberryPi

The problem is that many things have not been upstreamed into kernel so some stuff doesn't work or work badly. Like trying to get video just made the video device return random block of memory instead of an image last time I tried

> These days on the 64bit version, I'm not sure why it needs that much either. I'd think that having a few new task-* metapackages that setup the boot and raspberry pi specific boot management stuff should be doable and then they could use the main debian packages I would think. There's probably something that's not obvious that makes things just incompatible enough that it isn't simpler to manage that way.

I'd imagine the answer is "iteration time". Far quicker to apply a patch fixing some rPi-specific issue if you have your own repo with everything.

Pushing it to upstream of Debian might take few days and might come back with "well that code isn't great, fix it".

Even more if Debian maintainer says to take it up with original project, which is the right way to do it, just slower one.

I think they have bundled non-free software with the OS in the past. Debian isn't very cool with that.

They've been getting far more pragmatic in recent years. e.g non-free wifi drivers are now bundled on the installation images.

Before this it was necessary to do a silly dance, manually downloading drivers and either modifying the installation media or using multiple usb sticks. They understood that this was more than a mere inconvenience, some users are just going to be blocked and move on to a Debian derivative.

You can even use OpenZFS on Debian now, although it forces you to compile it for license compatibility, but it's all automated through apt to ensure it affects the user minimally.

> silly dance, manually downloading drivers and either modifying the installation media or using multiple usb sticks

Or just use USB tethering with your smartphone as the initial network connection

Hard agree and I too am curious as to why it is not like this.

Like so many distributions, Raspberry Pi OS seeks to use a lot of Debian's stuff while offering more and sheltering users from the less pleasant parts of the Debian user experience. It was not even close to being the first distro to take this approach.

(as someone else alluded to, Debian abandoned the specific ARM chip architecture the original Raspberry Pi used shortly before the board came out, since it was not popular enough to maintain. I have no idea whether they brought it back.)

The original Raspberry Pi SoC (BCM2835) is ARMv6 with VFP2 Hard Float support.

Debian's "arm" architecture is ARMv7 with VFP3. It doesn't support BCM2835.

Debian's "armel" architecture is ARMv4. It doesn't use BCM2835 to its full potential.

So the BCM2835 is awkwardly positioned in-between Debian's two stock ARM 32-bit architectures, which motivated the decision to recompile all packages for a BCM2835-specific "armhf" distribution.

In a sense, it's a historic artifact.

Interesting.

For my "canned mainframe" (https://github.com/rbanffy/vm370) ARM images, I'm using Debian as a base, since it has the armv6 architecture listed and I didn't notice any adverse effects.

I wonder if I should have used an RPi-specific base image.

OTOH, that'd render the container image incompatible with other 32-bit ARM boards.

I've always said the same thing about Ubuntu.

At the end of the day, it's just how they decided to do it.

in addition to the existing answers, they waited to upstream all of the drivers for the new video hardware until after the announcement. So having their own distribution allows them secrecy while developing the hardware

32-bit raspberry pi os is based on raspian instead of debian for the architecture reasons explained by a sibling comment. But 64-bit raspberry pi OS is based on actual Debian, with extra repos added for rpi-specific software and patched versions of some Debian software

Maybe quality control?

If it relied on upstream entirely and Debian breaks something, people would think Rpi is an unstable hardware.