It feels kind of backward to ask this now while it should probably have been a defining point and should be written clearly on the README. Let's discuss it then.
It is understood that:
- Core platform/target is the Raspberry Pi.
- BSF is using Pi4 only for this project. Other non-Pi hardware wont be updated.
- We don't want to support any generic computer (as does IIAB).
- Kiwix hotspot has been working on all standard Pi models (Zero, 1, 2, 3, 4, 400).
Raspberry Pi has gotten quite diverse over the years. Here's a matrix of Pi models that are of interest to us (so no Pico nor Compute Module).
Given the service we provide, two characteristics are of interest to be discussed:
- CPU architecture
- WiFi capability
WiFi capability
- Do we want to support models without integrated Wireless?
- If so, to what extent ? Do we want to provide a list of WiFi chipsets (or makers) we'd support?
It is understood that we want, at some point, to clearly state the performance capabilities of the solution (“supports users on a Pi 4”) which would not be possible with those.
We could still support other chipset in a “best effort” manner: try it and let us know if that works. That's kind of the current state as we do include (specifically we don't remove) a number of WiFi chipsets and should those support AP mode and the options we use (very limited at the moment offspot/offspot-config#2), it should work.
Impact: we currently don't support no WiFi so we'd need to at least introduce a graceful fallback.
CPU architecture
Pi models can be split over three different architectures:
armv6, also called armel is 32b for Pi Zero and Pi 1. Those were released in 2012-2014 and feature at most 512MB RAMarmv7 also called armhf is 32b for Pi 2 only, released in 2015 with 1GB RAM.armv8 also called aarch64 or arm64 is 64b and powers all the other (newer) models.
Important note
armhf means armv7 in Debian lingo but armhf means armv6+vfp2 in raspbian one (All armv6 Pi have a VFPv2).- A Debian system running an
armv7l Kernel with armhf dpkg architecture is thus different from a Raspbian (or base-image) running an armv6l kernel on an armhf dpkg-architecture.
- Debian supports
armv6 but calls it armel in dpkg.
- ⚠️ adding debian source list must be done carefully, forcing the architecture.
https://eloydegen.com/blog/posts/arm-linux-distribtions/
RaspiOS support
Obviously, raspiOS supports all three platforms. Its armhf image includes four kernels (armv6-32, armv7-32, armv8-32 and armv8-64) but the binaries are all armv6-compatible.
RaspiOS also offers a second image named arm64 with binaries for armv8.
We currently offer similar choice.
If RaspiOS does it and we're based off raspiOS, why are we even discussing this?
Drawbacks of keeping armv6 and armv7
armv6 and armv7 have very different statuses and support and the latter is a lot more common but regarding our table above, keeping it would be only to support Pi2 which was release in 2015 without integrated WiFi.
Docker
- Docker works on
armv6 via raspbian and/or debian package but included version is close to 2yo. Not much of a problem now but sill limiting.
- Docker has a repository with latest version that is the recommended way to install but this works only for
armhf (debian) so it doesn't work on armv6.
- Docker has static builds for armv6 but those are broken and doesn't work.
- It's almost impossible to test armv6 image as docker uses qemu for that and we don't control exactly how it's called.
- Docker image for
library/debian (base image for most language-specific images) doesn't even provide an arm/v6 variant but an arm/v5 variant. Not sure how the (undocumented) behavior is when requesting v6.
$ docker run --platform linux/arm/v5 -it debian bash -c 'uname -m && dpkg --print-architecture && file /lib/arm-linux-gnueabi/ld-2.31.so
armv7l
armel
/lib/arm-linux-gnueabi/ld-2.31.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=261b75978776d17373d9f528db8cd5d50ecf528f, stripped
$ docker run --platform linux/arm/v6 -it debian bash -c 'uname -m && dpkg --print-architecture && file /lib/arm-linux-gnueabi/ld-2.31.so
armv7l
armel
/lib/arm-linux-gnueabi/ld-2.31.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=261b75978776d17373d9f528db8cd5d50ecf528f, stripped
$ docker run --platform linux/arm/v7 -it debian bash -c 'uname -m && dpkg --print-architecture && file /lib/arm-linux-gnueabi/ld-2.31.so
armv7l
armel
/lib/arm-linux-gnueabi/ld-2.31.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=261b75978776d17373d9f528db8cd5d50ecf528f, stripped
Node
Python
- Most python libraries are pure-python and don't matter the architecture (python works on all of them)
- A few important ones do matter (like Pillow which is ultra-dominant for image processing)
- Important projects do provide binary packages (wheels) but those are specific to a platform (interpreter, system, architecture)
- Architecture is taken from kernel so in-docker (or docker buildx to be more specific), it's either seen as aarch64 or armv7l. This happens both when finding package and when building package. Given not many people care about arm 32b, it may lead either to improper package or not finding the package.
- Not found package means building from source which is very very long in qemu-arm and requires compilation tools, and libraries and all (if it's working)
In conclusion, armv6 support has lost most interest for people and has thus became exotic. armv7 has better support but is still 32b and supporting it wouldn't make much sense.
I suggest we agree on dropping support for armv6 and armv7 and thus only publish an arm64 image that will work on all the newer Pi which are all ARMv8 (including the Pi Zero 2 W).
This will keep us (for now) in a hack-free, up-to-date platform that we can safely build-upon. Images will be easier to build and maintain as well.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent