| I take issue with quite a bit of what you are saying, as; 1. The Allwinner chipset is 100% libre at this point [1], and they chose a cheap chip (the R8) so they could not have to subsidize their board unlike the Rpi Zero. If you want a more powerful board, buy an OrangePi PC Plus for $20. 2. "Full Fat" Debian is not very heavy, and you can easily disable what you don't need. The only "fat" is used disk space, which you can easily free up with a quick apt remove. 3. Can't comment much on the PocketCHIP, as I don't own one. 4. You want a secure way to get your OS onto your device, right? Even Signal for Desktop relies on Chrome, its virtually the only universally installable, secure way to distribute an application. 5. I have other A13 based boards and I've yet to encounter package breakage. The architecture is plain jane ARMv7, nothing specifically needs to be changed from the main Debian repos unlike the Raspberry Pi. >At best (and without some serious work) the CHIP is destined to be a footnote amongst closed and partially broken Pi clones. Its definitely far from closed, and it has decent software support unlike Pine64 and other failed boards, with the people behind the board writing eMMC drivers and working to build a better BBB. Compared to the BBB it is basically all there at this point. Whether or not other cheaper boards like the OrangePi Zero wipe it out is yet to be seen though. The Pi ecosystem seems very caustic from what little I've seen with my Pi 3, reminds me of the Android modding community, hence why I've yet to build anything useful with my Pi 3. [1] - http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix |
1. No it isn't. AFAICT The on-board Mali chipset needs a binary driver for full functionality. Lima's not there yet. I had a quick look at the mali package for 4.4 and it's shipping a binary, not source as part of the debian source package. There are also still issues with crypto acceleration and other areas that aren't accessible through F/LOSS.
2. Full fat Debian is heavy because it uses a full libc instead of uclibc. If you want to see what non-full-fat looks like check out LEDE or Angstrom. Running uclibc will result in lower memory usage and higher speeds. If I had the time I'd port LEDE as a target, but I don't.
4. Browsers browse the web. Firmware update tools update firmware. The two do not need to and should not mix. A secure way to get an OS on my device is to have a tool (for which I can download, verify and compile the source) that connects over a secure protocol to a site where I can download the OS and relevant signatures, verify these signatures, install the OS and verify the installation. Please don't conflate network crypto with hardware. The two are completely different things.
5. It's great that you don't have problems with completely different boards running packages on completely different Operating System implementations, but I'm talking about the CHIP, which runs it's own build of Debian and Debian packages.
As for your comments about software support and whether it'll be wiped out, I feel like you're at least partially missing my point - the Pi ecosystem is a monoculture. It works extremely well from a community support perspective because of that monoculture but (as you highlighted) it's not without it's problems. For long term success, the CHIP needs to puncture that monoculture. I don't believe that it will reach that point.