So I don't want to rag on something that had a huge amount of effort put into it, but... (and these buts apply to other systems as well as the C.H.I.P.)
1. The Allwinner chipset was a bad choice. It's non-free, flaky, underpowered (performs worse than a Pi Zero in my non-scientific tests so far).
2. The use of full fat Debian may contribute to 1. I think the AllWinner SBC is more suited to Android phones than general purpose SBC use, and using full fat Debian as a primary OS is potentially throwing away resources on things like a full fat libc. Yes there's Angstrom Linux as an option, but Angstrom's not really well maintained. Again, not limited to CHIP but definitely including it.
3. The PocketCHIP as interesting as it is, is a ballache compared to using a Pi Zero. For a Pi Zero I can install retropie and be up and running in under 10 mins. For PocketCHIP I have to hand configure each emulator, not all the debian packages work (weird segfaults and errors ahoy) and so on. Again, the PocketCHIP is not the only thing that experiences this, but once you've played Pico-8 for a bit, you start to realise that this is the only game in town for this platform unless you're willing to expend serious effort on work already done elsewhere.
4. The flash mechanism. Good god, where do I begin. Firmware flash updates require Chrome to be installed. That's right, the flash updater is a Chrome extension - a web browser extension. This is a ludicrous choice. A web browser is for browsing the web, not flashing firmware onto devices. There is an alternative route buried deep in the docs, but this is pretty convoluted. To flash the firmware in order to get hardware accelerated CPU support, I had to install chrome on my mac, fail several times thanks to the GUI interface clearing errors after they appear, try again with different combinations of USB hub, swear at the damned thing, then repeat the entire process on Windows.
5. I've alluded to this elsewhere, but the Debian build is broken in places. Various packages break because they don't take the architecture into account. Again, this isn't limited to the CHIP, but includes it.
The bottom line is that a $9 computer has a lot of competition depending on target use. Against a Pi Zero it loses to the incredible Pi Ecosystem. Against a Beaglebone it loses to a completely open design. Against a ZSun Wifi reader or plenty of cheap WRT devices, it loses on performance because of the full fat libc and the tightly specialised nature of the underlying distro.
At best (and without some serious work) the CHIP is destined to be a footnote amongst closed and partially broken Pi clones. At worst the PocketCHIP will be forgotten about in a couple of years. It's a shame, from a hardware perspective PocketCHIP has a lot of potential, being pretty hackable. Sure, the keyboard is terrible, the screen's pretty crappy and the peeling plastic is a nightmare, but it's got huge potential. I just don't see the resources there to bring it up to the same level as the Pi ecosystem.
Again, this isn't just limited to the CHIP - we'll see the same thing with the Onion Omega2, we've seen this with the Pine64 and various Pi type devices.
The fact that this post is about a port of a Pi-specific device sadly says more about CHIP's future than anything else.
2. I think you're right but I don't know what the better answer is -- I don't like the idea of raspbian being the only answer. Maybe they'll motivate Debian to improve in this regard?
3. This is a strange comparison. The PocketCHIP is a bit of a unique offering -- I'm not aware of a self-contained anything based on the pi zero that I can order off the shelf and use out of the box. I'd be delighted to see a counterexample!
5. Please report these problems! If not to debbugs, at least make a blog post or a gist or something. Get the information out there!
I agree with most of your conclusions, with the caveat that the Pocket CHIP is a unique device, in a world of years-long any-day-now products. It is very refreshing to see someone accomplish what they set out to do, warts and all.
For point 3, there are options like Adafruit's PiGrrl series, some of which I believe need 3d printing (but you can order that done for you from elsewhere). The downside of the PiGrrl is the lack of keyboard. The upside are the controls are better.
On point 4, yes there are, but this is rather convoluted too. Web browsers are supposed to be used to browse web pages. If they wanted to use javascript to create a cross-platform app, they should've used something like electron.
Point 5 I'll get round to when I have time, but I'm very time poor. I've already started seeing if I can improve mednafen support for Atari Lynx and get the GLES in 4.4 working better with mednafen.
I'm totally with you on the idea of raspbian being the only answer - I really don't like that. Unfortunately many of the problems come from the fact that the Allwinner chip used is so poorly supported and that people don't write code for multiple architectures, so packages build but then you get segfaults over stupid things like endianness when you run binaries.
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. 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.
1. You can boot and use virtually all the hardware, H.265 hardware video decoding included with a fully libre stack. The Raspberry Pi is unlikely to ever be able to do that. Never tried the Allwinner Android builds, mainly cause they are unmaintained.
2. You've got space to work with, you are not limited in terms of space. Feature wise I and many others don't want to make the sacrifices [1] to use a smaller libc, I did it when developing an application on Angstrom using a BBB and I never ever want to do it again.
4. How would you get secure, verifiable images to people by default across every major platform? We all know 99% of the people who both the C.H.I.P. are NOT going to be bothered to verify the signatures by hand, and even then how do you ensure the signatures are from Next Thing Co? A Chrome Extension solves this.
1. The Allwinner chipset was a bad choice. It's non-free, flaky, underpowered (performs worse than a Pi Zero in my non-scientific tests so far).
2. The use of full fat Debian may contribute to 1. I think the AllWinner SBC is more suited to Android phones than general purpose SBC use, and using full fat Debian as a primary OS is potentially throwing away resources on things like a full fat libc. Yes there's Angstrom Linux as an option, but Angstrom's not really well maintained. Again, not limited to CHIP but definitely including it.
3. The PocketCHIP as interesting as it is, is a ballache compared to using a Pi Zero. For a Pi Zero I can install retropie and be up and running in under 10 mins. For PocketCHIP I have to hand configure each emulator, not all the debian packages work (weird segfaults and errors ahoy) and so on. Again, the PocketCHIP is not the only thing that experiences this, but once you've played Pico-8 for a bit, you start to realise that this is the only game in town for this platform unless you're willing to expend serious effort on work already done elsewhere.
4. The flash mechanism. Good god, where do I begin. Firmware flash updates require Chrome to be installed. That's right, the flash updater is a Chrome extension - a web browser extension. This is a ludicrous choice. A web browser is for browsing the web, not flashing firmware onto devices. There is an alternative route buried deep in the docs, but this is pretty convoluted. To flash the firmware in order to get hardware accelerated CPU support, I had to install chrome on my mac, fail several times thanks to the GUI interface clearing errors after they appear, try again with different combinations of USB hub, swear at the damned thing, then repeat the entire process on Windows.
5. I've alluded to this elsewhere, but the Debian build is broken in places. Various packages break because they don't take the architecture into account. Again, this isn't limited to the CHIP, but includes it.
The bottom line is that a $9 computer has a lot of competition depending on target use. Against a Pi Zero it loses to the incredible Pi Ecosystem. Against a Beaglebone it loses to a completely open design. Against a ZSun Wifi reader or plenty of cheap WRT devices, it loses on performance because of the full fat libc and the tightly specialised nature of the underlying distro.
At best (and without some serious work) the CHIP is destined to be a footnote amongst closed and partially broken Pi clones. At worst the PocketCHIP will be forgotten about in a couple of years. It's a shame, from a hardware perspective PocketCHIP has a lot of potential, being pretty hackable. Sure, the keyboard is terrible, the screen's pretty crappy and the peeling plastic is a nightmare, but it's got huge potential. I just don't see the resources there to bring it up to the same level as the Pi ecosystem.
Again, this isn't just limited to the CHIP - we'll see the same thing with the Onion Omega2, we've seen this with the Pine64 and various Pi type devices.
The fact that this post is about a port of a Pi-specific device sadly says more about CHIP's future than anything else.