While working on my blog as described in my recent post Blog internals, I came across the possibility to include a search engine into the blog directly. The Nikola documentation gives examples for DuckDuckGo and Google, and as I am skeptical of the data collection of Google, of course I tried DuckDuckGo first. The experiment returned no results whatsoever, so I was not sure if the integration into the website failed or if DuckDuckGo really did not return any results for my website.

Entering the search term site:lazy-evaluation.net into the search input field on the regular DuckDuckGo website showed that indeed there are no results whatsoever for my website. Ouch.

Trying the same search term with Google search reassured me that at least Google is still indexing my site.

As the other things regarding my blog were solved successfully, I returned to research the situation today.

Read more… (2 min remaining to read)

Recently I was made aware of a consequential GDPR ruling in Germany. The summary of the ruling is that a website owner was sentenced to pay a €100 fine to a visitor of his website because the website used Google hosted fonts. The visitor claimed that by loading the Google fonts, his IP address was exposed to the Google servers and this violates the GDPR.

Effectively this exposes every website in Germany using Google hosted web fonts to become the target of an €100 fine. At first, it seemed like a theoretic problem, but more recently it seems that people have turned this into a business-model (link is in German) and there now seem to be a wave of incidents based on this ruling. So it has become pretty urgent to fix this for web site owners in Germany.

Checking my Nikola generated site, I found that the zen theme that I use not only uses Google hosted fonts but also the Fontawesome icon set hosted on its own server. So I quickly decided that I need to switch those over to self-hosting before I get one of these lawyer mails. This blog post documents the things I learned on this journey which is still not over.

And I apologize in advance that this post has become rather large and very technical, but the things are really connected together so I decided not to split them out into smaller posts. I sincerely hope this was the right thing to do.

Read more… (17 min remaining to read)

In a recent post, I described the basics to execute code on the Cortex M4 micro controller inside the i.MX8M Mini SoC. However there was no communication going on between Linux on the Cortex A cores and the application running on the M4. In this post, I will look at an example using the remoteproc and rpmsg (Remote Processor Messaging) frameworks for communication between the processors. The remoteproc subsystem implements basic house keeping for co-processors in Linux and the rpmsg framework implements the actual data channels.

Read more… (13 min remaining to read)

Over the last few years, SoCs targeted at embedded GNU/Linux applications became heterogenous architectures. Instead of adding more identical copies of CPU cores (Cortex-A class), a small companion micro controller core (Cortex-M class) was added. Compared to the complex architecture of Cortex-A systems, including their multi-layer caches, those cores are usually deterministic and thus predestined for low-latency "real time" jobs. NXP's first such SoC is the i.MX6 Solo X device featuring an Cortex-M4 next to an Cortex-A9 core. The i.MX8 family moved the Cortex-A cores into the 64 bit world and there are different combinations of Cortex-M companion micro controllers, but all of them do feature them as they are pretty "cheap" in terms of die space and transistor count.

From what I can see, it is still uncommon to use those micro controllers in actual projects though. Today I want to take a short look on how to run simple programs on the Cortex-M4 of the i.MX8M Mini SoC, especially we will use the official i.MX8M Mini EVK.

Read more… (21 min remaining to read)

Looking at the kernel sources for NXP's i.MX8M SoCs, I noticed branch names like "lf-5.10.72-rt-2.2.0" and I wondered if NXP finally was going to offer RT preempt support within their BSP. Some other vendors have started supporting the patch set already a while ago but for NXP this is new.

In this post we are going to run this real-time enabled kernel on the i.MX8M-Mini evaluation board from NXP to get a first hand impression of what is required on the kernel level. We will not use the Yocto build system as this is only a wrapper around the distribution agnostic kernel development.

Read more… (8 min remaining to read)

The Yocto project has become a de-facto standard for Embedded GNU/Linux Systems and on many embedded systems the final image will be written to an SD card to be tested on the target board. Those images are meant to be written in one go and thus contain a partition table and multiple file systems. In preparing them, one usually chooses a suitable maximum size for the file system partitions and this will be the lower limit of the final image size no matter how much of this space is actually used. So without further tooling we will always be writing a lot of zeros not relevant for the system itself to the target medium.

Luckily enough there exists tooling for this use case and in this blog post I will show how easy it is to use bmaptool from the bmap-tools project to save time and wear on the SD card. On Debian systems installing the package is as easy as sudo apt install bmap-tools.

Read more… (4 min remaining to read)

Although e-mail has lost some of its importance by the advent of secure messaging platforms like Signal, from time to time I still get the itch to improve my existing setup. Recently I wondered why I am still using a single file mbox instead of the more Unixy maildir format on my Debian desktop and how difficult it would to be switch. As we will see, the transition is pretty straight forward.

Read more… (3 min remaining to read)

As I like to live on the bleeding edge by using Debian testing (currently Bookworm), from time to time I run into situations that are not ease to solve from within the distribution. For example currently its impossible to install the yarn package manager:

dzu@krikkit:~$ sudo apt install yarnpkg
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 node-esprima : Depends: nodejs:any
E: Unable to correct problems, you have held broken packages.
dzu@krikkit:~$ 

As I do not see an easy way to fix this and as I am pretty sure that this will work in Debian stable, let's try spinning up an LXC Debian Bullseye container and work from there instead. The ultimate goal for today is to locally build and view the GNOME Javascript guide from a git clone to locally test modifications.

Read more… (9 min remaining to read)