David had purchased a number of upgrades for his 3D printer: a new motherboard, an extruder which can cope with higher temperatures, a new display and a filament runout sensor. He commented that he had lots of wiring to do to add these upgrades!
John briefly summarised a presentation about SUSE’s Aeon:
SUSE has always been a commercial organisation and it was one of their engineers who, as a Linux maintainer, started the LTS kernels because they needed them for their customers. They went into containers and then decided to develop a server in a container, using Podman rather than Docker. This is available as MicroOS. Aeon is an attempt to develop a desktop on the same principles using Gnome because this is the desktop SUSE uses for its commercial offerings.
At the bottom of the stack is the basic Linux system together with the software needed to run Gnome in a container. Graphical applications will come from Flatpak — Flatpaks run in a container — while the distrobox will allow users to run any other program, including graphical applications not available from Flatpack, from the command line. Distrobox is a sandboxed container and so will be able to run programs which are not supported by openSUSE/SUSE without interfering with the rest of the system.
David queried how it would handle security updates and John [wrongly] said by installing a new container and David wondered how many times that would happen. [John checked this later and found that security updates rely on a feature of Btrfs which allows transactional updates without interfering with the running of the system.]
John said that, whatever happened, Tumbleweed, openSUSE’s rolling distro, would not be affected and nothing will change until 2025 at the earliest.
Bernard had previously mentioned the Instrument Neutral Distributed Interface (INDI) server which can control the properties of instruments by sending an XML specification to a general purpose client so that it can pick up how to display things. However, everything is written in C and so development is limited to a small community.
If drivers could be written more easily, INDI could be used, for example, on Raspberry Pis if someone could write a driver using Python functions and convert that to an XML file.
The problem is that you need to do a lot and to do it simultaneously when there are multiple drivers and multiple clients; the difficulty lies doing things simultaneously — individual tasks are straightforward unlike simultaneous ones.
In Python you can use forks, but these are just duplicates, and threads, but these cannot handle a change in a variable.
So he has been exploring cooperative multi-tasking in Python; normally you define functions that do things and have a main that calls the other functions all sequentially.
Co-routines are functions which can pause, pass control back and resume; so in Python you can run an event loop which runs round running, pausing and resuming which appears to be simultaneous; the only problem is if a program carries on running and stops the others running.
You import the asyncio library; as each function is run, it may call other functions and put them on the loop.
The problem is passing data from one function to another; however, the
asyncio library has queues which allows data to be added when there is space on the queues — if there is no data in the queue, the loop carries on running.
He then demonstrated running two routines involving ‘Hello world’ (based on the example on the asyncio page) which each have a 2s wait; consecutively, they take 4s. As co-routines they take 2s; using
asyncio.gather() you get the same result when the queue is limited to one item because routine A can only put one item in the queue and must await routine B getting the first item from the queue after which routine B awaits routine A putting another item in the queue. If you remove the 2s wait from the routines, they appear to run simultaneously.
He has also started exploring an INDI driver for a thermostat.