5 ms·

I'm always confused by Raspberry Pi OS. It feels like Debian with a pre-set of packages, and a few additional software to control the board and bootloader. Why

I'm always confused by Raspberry Pi OS. It feels like Debian with a pre-set of packages, and a few additional software to control the board and bootloader. Why not maintain these additional pieces of software packaged in debian, and provide a prebuilt image for the Raspberry Pi? Why maintain an entire different apt repository? Why publish new version months after the upstream debian is already released?

whalesalad 3y ago
Hard agree and I too am curious as to why it is not like this.
afavour 3y ago
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.
- acatton 3y ago
  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.
simcop2387 3y ago
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.
- adql 3y ago
  > 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 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.
extraduder_ire 3y ago
I think they have bundled non-free software with the OS in the past. Debian isn't very cool with that.
- tomxor 3y ago
  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.
  - stragies 3y ago
    > 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
e2le 3y ago
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 https://packages.debian.org/bookworm/raspi-firmware [2]: https://raspi.debian.net/tested-images/ 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.
- acatton 3y ago
  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.
olabyne 3y ago
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
justin66 3y ago
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.)
l1k 3y ago
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.
- rbanffy 3y ago
  Interesting. For my "canned mainframe" (https://github.com/rbanffy/vm370 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.
jlarocco 3y ago
I've always said the same thing about Ubuntu. At the end of the day, it's just how they decided to do it.
asddubs 3y ago
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
cillian64 3y ago
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
mekster 3y ago
Maybe quality control? If it relied on upstream entirely and Debian breaks something, people would think Rpi is an unstable hardware.

whalesalad 3y ago

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

afavour 3y ago

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.

acatton 3y ago
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.

simcop2387 3y ago

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.

adql 3y ago
> 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 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.

extraduder_ire 3y ago

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

tomxor 3y ago
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.
- stragies 3y ago
  > 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

e2le 3y ago

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 https://packages.debian.org/bookworm/raspi-firmware [2]: https://raspi.debian.net/tested-images/ 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.

acatton 3y ago
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.

olabyne 3y ago

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

justin66 3y ago

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.)

l1k 3y ago

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.

rbanffy 3y ago
Interesting. For my "canned mainframe" (https://github.com/rbanffy/vm370 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.

jlarocco 3y ago

I've always said the same thing about Ubuntu. At the end of the day, it's just how they decided to do it.

asddubs 3y ago

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

cillian64 3y ago

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

mekster 3y ago

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