Decisions to adapt to changing technology

abstract: The technology is constantly changing. Changes in the state of the technicology induce adaptation of the environment.

Decisions to adapt to changing technology

The technology is constantly changing. Changes in the state of the technicology induce adaptation of the environment.

What changes the technology environment currently?

I have embraced the Single Board Computer technology sind 1980; the first was a SWT computer based on an 6809 chip with an unix-like OS.

footnote: The computer cost about sFr. 20,000 - with a 20 MB hard disk and 2 floppy disk drives (each another sFR. 10,000). The setup weighted about 40 kg and was carried up to my second floor apartment in the Bolleystrasse in Zurich. Probably the first computer I had at home (on loan from ETH).

The past years saw a series of SBC, from the original RaspberryPi to cubieborad and cubietruck to finally Odroid XU4. These were all ARM processor based, 32bit machines with some Debian derived Linux OS. The most relevant use was the system of keeping data in sync between Pressgasse (in town) and Geras (in the countryside), plus laptops, plus backup.

footnote: The effort in terms of work hours to have the sync service running has been large; I can understand why people go to cloud based services bought - if they are painless. Are they? Dropbox was not, even when I paid for it.

With the RaspberryPi 4, based on a 64bit ARM processor, a more potent SBC became available and I use it as a secondary desktop machine (just nice for editing files, browsing etc.) and a new base for the sync server (plus wiki, caldav etc.). The Raspi4 will replace eventually all the other SBC - to reduce complexity.

Conclusion: Focus hardware on ARM 64bit SBC and AMD64 Desktop hardware, plus some Laptops (AMD64) and phones (ARM64).

Decisions necessary:

With a change in the hardware base the decicions about the software must be revisited:


The experience with linux and Debian has served well. Experiences with companies to improve on Debian has not been positive; the interest of the company is often in conflict with my interests as a user (e.g. lock-in effects, the improvements assume a specific use which does not correspond to our actual use).

footnote: - The desaster of forced to be switching from Apple to Microsoft when Apple replacde the 68000 processor to the PowerPC (?) and could not deliver working new hardware. - The slow increase in lock-in effects in ubuntu and addition of services, software etc. which was of no interest to us.

The bare base of Debian - doing one thing and do it well - has allowed us to have the same Desktop (XFCE and now MATE) for years. No disasters is quite an achievement for an organisation of volonteers!

footnote: Debian exists sine 1993!


I recently switched from XFCE to MATE - which is a very small change; the more uniform way of storing preferences convinced me. Later I found, that it is not encompassing enough and a separate method to maintain a uniform GUI is still a challenge; just a bit less.


The past month I have built a method to provision new hardware with the required software setup using Ansible. It is based on a simple and clean idea, unfortuantely the implementation is not flawless and bugs consume time to iron out.

Text processing, Mail

The preference is for markdown, pandoc and LaTeX; Lyx or LibreOffice for special cases.

Thunderbird is still easier and more reliable than anything else I have tried. We need more robust solutions for long term storage. When should stuff be given up?


I will stay with Haskell after having considered Rust or Python briefly. Python seems to do standard things easily, but whenever something non-standard is expected, the effort to undo the conveinence is back. Rust has different goals, but is perhaps somewhat more uniform than Haskell - but for this I have my uniform project.

For working with Haskell I embraced stack to avoid Cabal-hell and achieve predictable builds; Stack does this, at a cost. At the moment, I seem to have difficulties to build on the arm64 plattform (Raspi4); before I observed that complex build processes (lasting for hours on AMD64 plattforms) are repeated.

Options for change

Debian for ARM64

A reliable working Debian base has just become available. It is due to the Raspi-Firmware project on git hub and the Raspi Debian webpage, which produces automatically images for the ARM64 Raspi4. I can reconstruct images using their work (not completely tested) and adapt better to my needs, but the same goals can be achieved with the images available and installation with ansible.

Haskell tools

I could switch to Cabal or Nix with cabal replacing Stack.

Produced with SGG on with master5.dtpl.