Adventures with Single Board Computers 2020

abstract: Single Board Computers have evolved a lot, but it is still an adventure. Running a server for synchronizing files (like a cloud) or for a desktop? What are the current restrictions.

Taking stock 2020

I have used single board computers for nearly 8 years:

the original raspberry pi (announced in 2012) :for experiments as servers for printer and music; I learned a lot about arm cpu. Performance was not sufficient to run syncthing consistently.

the cubies : the cubieboard and the cubietrueck, with disks connected via SATA interface, because raspberry pi could not swiftly deal with large collections of files for my file syncronisation application. The cubies (cubieboard, cubietruck) had SATA connectors and run on 2.5" disks well.

the odroids (xu4) : connected a large disk through USB 3 interface. Worked reliably for a long time as server for syncthing (3 servers). Many experiments to use haskell and rust. Learning how the boot process worked. The performance was improved, but the hard drives where connected by USB 3.0, expecting a chip in the enclosure to convert from SATA to USB.

It was a constant catching up with my demand: first, only a cheap computer which was usable with a desktop (while learning more and more about the command line interface of linus); raspberry showed it possible, but slow and limited. Improve the speed and disk capacity: Cubies and eventually odroids.

Desktop running on a SSD gives complete system in parts for today (2020) for

Still around 300 E - but usually much less, as parts are lying around from old projects. One piece gets replace and older ones are recycled which is probably using less resources over longer periods. If the form factor --- small boxes and cables --- is more usable than a laptop (with a fixed position relative to the screen and the keyboard which is definitely not ergonomical) remains to be seen.

What can it do now:

  1. Desktop - plenty fast for editing a text (using VScode, which recently became available for the armhf architecture, because Microsoft sells a tablet on armhf base) even if something else is running in the backgroudn. Web browser ok, youtube is just ok.

  2. Code development - Limited (by cpu power), but most programs are available as armhf code, which is usable for most single board computers which run on cpus mass produced for smart phones.

What it still cannot do (at least the single boards I have tried):

I will try a combination of odroid xu4, ssd, wlan dongle and powersupply for the garden this summer (laptops are not an alternative - I need bigger displays at the right distance for my eyesight).

The early beginning started with Linux Debian on Raspi - it was close to regular Debian and quite restricted. There was a desktop which impressed everybody - but not really usable, not responsive enough.


With the hardware started the quest for OS and programming language tools:

The Raspi came with its debian (raspian). For the cubies I used the debian implementation armbian, it installed mostly, but unreliable SD cars, problems with powersupplies caused errors which typically required days to fix them or work around them. It improved with the OS images which meveric prepared and which I used for year on the odroid xu4, till finally I switched over to armbian for odroid xu4 for the installation of buster (deb10). Armbian uses the u-boot installer which is closer to the original debian installer (wich is available, but I had no luck with its installation),

The limitation were originally the availability of software for the armhf architecture and is still a limitation. Progress is made: initially GHC was not available, then it was partially available (all except templates) and it seems GHC is now complete. Not

Produced with SGG on with master5.dtpl.