Welcome to the 11th issue of TMPDIR Weekly, a newsletter covering Embedded Linux, IoT systems, and technology in general. Please pass it on to anyone else you think might be interested and send any tips or feedback to our forum or news@tmpdir.org.
Starting with this edition, we will append our initials at the end of comments that are opinionated. We may not always agree on everything and opinions (especially strong ones) should always be owned.
Linux
Yocto Honister (3.4) release is planned for the end of this month. The upcoming Yoe 21.10 release will include these changes.
KDE Plasma 5.23 (KDE's 25th anniversay edition) has been released and is making steady progress with many small updates making the user experience better. These improvements include multi-screen, Wayland, and Breeze theme updates. I am excited to try this release! Check out Nate's post on this release. --kr
Python setup tools will now fail if there is dependency on a packages that requires Python 2.x. This caused us to discover stale packages in Yocto that have not been updated in 10 years.
We started adding support for the HiFive Unmatched RiscV board. This is a very capable board that contains the fastest RiscV SOC available now. More news to follow about Yoe/SIOT support for this board.
IoT
In the Simple IoT project, I have been experimenting with a new process for exploring and capturing architecture decisions. I first encountered this in the one of the NATs repos, which links back to this article.
The
first SIOT ADR
is an exploration of whether we should change the Point data structure type.
In the process of adding system metrics, there is some data we can’t easily
express in the current types. Some obserervations about the ADR process:
- you think better when you write
- fits with the Lead with Documentation approach to work
- every product feature or architectural change should start with the question: what real-world problem does this solve? The ADR process helps clarify this.
- one thing I’ve noticed in Kleppmann’s book is the extensive use of examples to discuss various concepts. I think examples are important to include in an ADR as it really helps clarify thinking.
- in the future, an ADR should be a useful reference to document and understand why something is they way it is.
I’m very pleased with how this first ADR is working out and hope to continue using them to think through difficult/major project decisions.
Still a bit torn whether ADR discussions should happen in Github issues or PRs. An issue has the benefit that it can span multiple PRs. A PR has the benefit that commends can be inlined with code. --cb
Other
Started a topic for Rust OS/hardware/embedded programming. There is a lot of activity in this space. In one sense, I am really interested in the use of Rust for embedded/system/hardware programming, but at the same time I'm wary of language complexity as expressed in this article. --cb
Quote for the week
I have made this letter longer than usual, only because I have not had the time to make it shorter. -- Blaise Pascal, Lettres provinciales no. 16 (1657)
Join our Discourse forum to discuss these or new topics. Listen to previous podcasts at https://tmpdir.org/.
Thanks for reading!
Khem and Cliff