Embedded Software Meetup Zürich ist zurück!

Nach längerer Pause des "Embedded GNU/Linux Developer Meetup" führen wir es als "Embedded Software Meetup" wieder durch. Es geht um:

und vieles mehr. Im Fokus steht der Austausch zwischen Entwicklern und anderen gleichgesinnten.

Den Anfang macht Urs Fässler mit seinem Erfahrungsbericht zu moderner Applikationsentwicklung für Embedded Linux.

Clean Code und Software Craftsmanship helfen, Embedded Systeme sicher zu machen (safety und security). Diese Botschaft hat uns Simon Künzli im aktuellen Kurs Security in Embedded Systems an der ZHAW School of Engineering vermittelt, und ich stimme absolut zu.

Es sind Methoden, Prinzipen und Praktiken welche ich seit bereits 10 Jahren anwende und sehr zu schätzen gelernt habe. Vielleicht tönt TDD, BDD, CI/CD, Review und was es alles gibt abschreckend. Persönlich gebe ich es nicht mehr her. Es gibt so viel Sicherheit das man das richtige entwickelt und die Qualität stimmt. Auch reduziert es die Bugs - dadurch ist der initial etwas höhere Aufwand nach kurzer Zeit amortisiert.

Public Money? Public Code! Wie have it in Switzerland.

See the talk from Matthias Stürmer at OpenSource at Siemens how he did it.

Very happy to announce that I founded my own company:

The go to place when you need - Quality Software - Embedded Linux Software and Systems - Open Source Specialists - Software Architecture - Shorter delivery and feedback cycles and any combination of it.

Investigating Yocto issues can be challenging. Yocto employs Bitbake, which heavily relies on variables (lists) that are set, appended, prepended, and modified across several recipes. Other recipes reference these variables to make decisions and modify additional variables.

One particularly troublesome variable is DISTRO_FEATURES. Numerous recipes manipulate this variable, and any change typically triggers a rebuild of most packages. In our case a colleague was missing systemd within DISTRO_FEATURES, although it was present in my configuration.

Have you ever struggled with finding the right place to store your service’s configuration files on a Embedded Linux system?

I’ve observed numerous file storage and System Configuration practices, such as placing everything under /data, utilizing /opt/…​, or keeping operational data under /etc/…​, among others. While these methods are feasible, I would advise against them. The Filesystem Hierarchy Standard (FHS) specifies the appropriate locations for different types of files.

If you’re developing services for Embedded Linux, adhering to the FHS can significantly simplify software deployment and management. By following these standards, developers ensure their applications are more portable and easier to maintain. For instance, tools like Yocto automatically locate files expected in standard directories. Runtime behavior is as expected when you choose the correct location for temporary and log files.

Um in der heutigen schnelllebigen Technologiewelt Embedded Systeme Nachhaltig zu gestalten ist es unerlässlich, dass Software fortlaufend aktualisiert wird. Es ist nicht mehr zeitgemäss, Embedded Software einmalig zu entwickeln und dann über Jahre unverändert zu lassen. Verschiedene Faktoren treiben diese Notwendigkeit an:

What to do with third party hardware components in your machine wrt. Cyber Resilience Act?

When working towards CRA compliance the focus is usually on the software you write. Especially devices based on Embedded Linux often have other hardware they control or interact with. In this context, one question came up from multiple customers: how do we work with third party hardware that contains software?

I thought about this and came to a quite simple solution with the realization of two key ideas:

Heute starte ich in die Selbstständigkeit. Mein Angebot umfasst: