Introduction¶

I started writing this blog post in March, completely oblivious of Mozilla’s plans of getting rid of Pocket, but with life and work being in the way I never got around to finishing it. Now that we know that Pocket is being shut down on 8 July, I decided to speed things up – and what better day to blog about eReaders than Towel Day!

For a long time already I have been aware of Wallabag – in fact, since it was still called (In the) Poche¹. And have used it before, through its wonderful service https://wallabag.it.

But for equally long, I have also used Pocket (which used to be called Read-it-later). I found that some things worked better in Pocket and others in Wallabag. But the thing that ever so slightly tipped the scales in Pocket’s favour several times before for me was that it had a seemless integration with my Kobo² eInk reader.

I have also been keeping an occasional eye on alternative eReader software for many years, but never took the plunge for different reasons. One of the things that I was waiting to become brave enough to try out was also InkBox / Quill OS for Kobo devices. I was aware of KOReader and Plato, but was always betting a bit more on InkBox as a more “pure” full-blown FOSS OS as something I would eventually switch to.

Of course, I am using the venerable Calibre to manage my eBook collection. Lately instead of a local collection though, I have all my eBooks on my home server³ using the Calibre-Web for the whole family.

OK, with that brief introductory info dump over, here is how my first week (and at this stage, honestly, months) with KOReader + Wallabag went.

Day 1 – Braving up to flash my Kobo¶

At first, I was a bit scared and did not want to mess with setting up KOReader, as I heard it was very configurable and also I have had … mixed … experience with flashing devices so far.

So I decided this would be a weekend project and planned accordingly.

Long story short, after some searching and reading, I found on MobileRead forums the instructions for One-Click Install Packages for KOReader & Plato, so that is what I went with.

Honestly, it was pretty much as simple as it sounds! And it just installs alongside the official Kobo system too.

If you were even a bit curious, do not wait as long as I have – just go and try it. It really is dead simple!

I decided to use the archive that includes both KOReader and Plato, because I heard the former is very tweakable, but you need to put some effort into making it your own; and the latter has very pleasing defaults, but barely any options.

Day 2 – Install and first glance at KOReader and Plato¶

Perhaps unsurprisingly, the One-Click Install Packages was stupid-simple to do.

Essentially I ended up with an additional menu in the official Kobo firmware, where I can choose to launch either Plato or KOReader.

I later also had the opportunity to check that updating KOReader works from the device itself and is as simple as selecting “Update” from the main menu.

First, I tried Plato, and while I quite liked its æsthetics, the longer I used it, the more I wanted to tweak a few things here and there. I would say that if Plato does exactly what you want, it is a great option, though. Especially if you have a larger screen.

My very first exposure with KOReader turned out as expected – too many menus, too many options, too much stuff – I felt a bit overwhelmed. But after the inital shock, it took me just a few hours to get a good feel of everything. The KOReader user guide helped a lot here too.

At this point, I was hooked!

The previously overwhelming plethora of settings suddenly became a collection of options that I was looking forward to tame and make my eReader truly sing to my tune. A lot of hacks exist out there for Kobo’s official firmware – and I used a few already –, but what KOReader offered out of the box was on a different level.

What also helps a lot is that you can easily disable plugins and menu entries that you do not use or want.

By the end of the day, I essentially set up my KOReader to be like I wanted it to. Sure, it took some hours, but it was well worth it.

Day 3 – Renewed interest in Wallabag¶

Both Plato and KOReader include a Wallabag client, so that got rid of one of my main reason to continue using Pocket.

With that out of the way, I went ahead and installed Wallabag on my home server⁴.

Which, thanks to YunoHost, was, again, just a one-click install :)

The set-up on KOReader was a bit more involved than just entering the username and password, but nothing too taxing.

Once it was set up though, it was about as easy to use as the official Pocket app on the offical Kobo firmware. I was honestly positiely suprised!

The main difference is that KOReader stores Wallabag articles as ePUB in a separate folder and syncs (in both directions) those with the Wallabag server. Treating articles as any other book on the device has some benefits, like annotation support (more on that later) and being able to modify styles etc.

I did try WallabaKo – the hack that puts the Wallabag client into Kobo’s official firmware – before and it works in a similar way. But its method to sync the articles is (undestandably) a bit hacky and not as nice as KOReader’s and the integration is not quite as frictionless. That said, if you do want to simply continue to just use the official Kobo firmware, WallabaKo is a perfectly fine solution. I do recommend you use the NickelMenu launcher to trigger the sync in that case.

Day 4 – Advanced Wallabag use, some automation¶

Today felt like the right time to poke around my new Wallabag install a bit.

As I used Wallabag before, I was quite comfortable with its basics and decided to read about some more advanced features and try to make things easier for me.

One thing I quickly made use of was to “program” a few rules to automatically tag an article. This makes finding a specific article – especially month after I have added or even read it – easier.

For example⁵:

• if « domainName matches "kde.org" OR content matches "KDE" » then tag as « KDE »
• if « domainName matches "curia.europa.eu" OR content matches "CJEU" OR content matches "Court of Justice of the European Union" » then tag as « sodna praksa, eu »

Occasionally the automatic tags are not perfect. But those can be easily changed already when you add the new article either through the browser plugin or the mobile app. Of course, you can also do it through the main WebApp too.

Then I remembered having seen some RSS support existed. And since there are some feeds that I know I would always read through my eReader anyway, that was an awesome idea! Unfortunately it was not exactly what I remembered …

Wallabag does offer RSS feeds you can subscribe to, but is not what I was looking for.

This feature was requested before, but the core team decided against adding it. It seems that they did add this feature into their SaaS offering though, so that is a bit bitter. If you really want to easily get RSS/Atom feeds directly onto your eReader, you can either have an account on wallabag.it or use KOReader’s News plugin.

Personally, I prefer having all my long articles in Wallabag, so I decided to just continue manually saving them.

Day 5 – Exploration, integration, interconnection¶

At this point, I had pretty much everything going well and was looking for improving my reading workflows.

Articles¶

When I find a new article/page online that I want to read later on my eReader there are two options:

1. It is an article I found through the web browser.
   1. I save it using the browser plugin or the mobile app to Wallabag.
   2. In KOReader I sync with Wallabag and read the article on my eReader
2. It is an article in a RSS/Atom feed I am already subscribed to through Nextcloud News.
   1. As I typically browse my feeds on my mobile phone, when I scroll through an article in the Nextcloud News mobile app that if find too long to read right now, I share it with the Wallabag mobile app.
   2. In KOReader I sync with Wallabag and read the article on my eReader

eBook libraries and collections¶

When it comes to eBooks themselves, I have a shared Calibre Web library with my family and can browse that directly from my KOReader.

How does this magic work?

Fairly simple really. On my home server I mount my Calibre folder in Nextcloud as external storage (with appropriate file system permissions) and then in turn use KOReader’s WebDAV plugin to browse directly from my device.

There is also OPDS support but it currently does not work for my server. You can use it to browse public servers perfectly fine though!

Notes and marginalia¶

Since I started using a Zettelkasten(-like) method of taking notes in MarkDown, I was very happy to see that KOReader can export highlights and notes to MarkDown. Even better! It can push them to Nextcloud Notes, which I use to sync my notes between my phone and laptop anyway!

And this is where the “Wallabag articles are just ePUBs” coolness kicks in – because this means you can also treat highlights and notes the same as in any other eBook, export to Markdown and all.

That made me super happy!

Day 8 – Surprise of the day night¶

Something I spotted early on, was Night mode.

When I tried it it seemed to just invert the text and background colours to be white on black instead. Which I thought was pretty wasted on an eInk display, since it does not emit light anyway.

But no! It does make sense.

When I was reading late at night, as I usually do, I turned on the front-light and set it to the minimum, just to see a bit better.

And that is when it hit me – if you use Night mode when your front-light is on, you get even less light, because the black ink blocks it. That was such a delight to find out.

Day 9 – MOAR AUTOMATION … or not (yet)¶

I guess at this point it is safe to say I fully made the switch …

After being completely flabbergasted at the usefulness of Night mode, I noticed you can automate when it should turn on and off! So I did! So many options too!

Then I found and read up on Profiles and immediately my mind went buzzing with ideas:

• when I close a book, automatically export the notes (and upload them to my Nextcloud Notes)
• when I open an ePUB from (the) Wallabag (folder), apply the HTML5 CSS style
• when I open an ePUB that I generated from a webpage that contains legislation, apply certain style tweaks in order to make the structured articles and paragraphs actually palatable to the eyes

Unfortunately, I seem to have gotten ahead of myself.

The first one works, but I could not figure out how to get it to actually trigger automatically on book close. I have that option enabled, but it just does not fire. The trigger actually triggers and the export works in general too. Just the combination does not work. (I will file a bug and link it here when I do.)

As for the other two, it seems KOReader does not allow for style and style tweaks to be set in a Profile yet. (I will file a bug and link it here when I do.)

Next few weeks – end of honeymoon¶

In the days and weeks after the honeymoon phase I did start noticing some small issues:

• It is annoying that KOReader(’s Wallabag client’s) highlights and notes and the Wallabag highlights and notes are two completely separate things that have no idea about each other. My current solution is to try and annotatate books and articles only through KOReader, and ignore the fact that Wallabag has this functionality.
• In Wallabag you cannot search/filter for several tags at the same time (e.g. ”AI” and ”data mining” and ”copyright”). – (I will file a bug and link it here when I do.)
• In KOReader Wallabag does not parse HTML <abbr> tags. – (I will file a bug and link it here when I do.)
• Wallabag articles do not show their length in KOReader unless you open them, which is not major, but a bit annoying when you are trying to find something to read suitable to your time available. – (I will file a bug and link it here when I do.)
• When highlighting sentences in KOReader the end punctuation is not being included consistently. – (I will file a bug and link it here when I do.)
• Wallabag does not translate footnote anchors into internal anchors (i.e. strip the URL when it is the same as the article’s), so clicking on a footnote tries to load a new page instead of just scrolling down. – (I will file a bug and link it here when I do.)
• I have not figured out yet how to sync book descriptions and star ratings from KOReader to Calibre-Web (or Wallabag).
• At some point exporting margialia to Nextcoud Notes started crashing – this is a known bug and should be fixed soon
• I have suggested some issues and improvements when it comes to the Markdown export of marginalia. There is some pushback, but also some workarounds offered. I need to look into it a bit more.
• It would be great if Wallabag tags could be used on KOReader too.

But ultimately, if I am completely honest, these are all issues I could only dream of having before I went on this adventure.

I hope they get fixed at some point, as that would make my little old eReader ever so closer to being the wonderful box the Hitchhiker’s Guide to the Galaxy was imagined to be.

But even if not, this switch was well worth it!

Interesting related tidbits¶

When using a third-party WebDAV client (including your operating system’s built-in client), you should use an application password for login rather than your regular password. In addition improved security, this increases performance significantly. See Nextcloud documentation on Third-party WebDAV clients.

hook out → whelp, now to find a replacement batteries for Kobo Aura and Kobo Aura One

Here we are in the year 2025 and every company that wants to grab your money now peddles AI.

Even most search engines will now start with some “AI powered” summary.

Unfortunately, what they give you is just some deep learning intelligence fake.

Just imagine, you don’t read the links yourself, but you pass that to some friend/colleague/… that might be a nice person but is known to, if in doubt, not to tell that he did not understand what he should do, but just returns some random stuff that sounds like it could be true.

That is the state of AI.

Naturally one has trained the models to death on standard questions and problems, ask a semi new model why the sky is blue and you get the same answer as on the Wikipedia, more or less.

But try it different: Ask something that for sure is no training question.

My self serving question, just to see if the standard models know something about Kate (and perhaps me). Naturally not just ‘me’ invented Kate, but let’s roll with that.

Who invented the Kate editor?

Let’s ask the gemma3 model:

The Kate editor was primarily developed by Michael Hofmann.

Here’s a breakdown of the key figures and the evolution of Kate:

Michael Hofmann (Lead Developer): Hofmann started working on Kate as a personal tool for editing and exploring Markdown. He initially created it as a command-line tool and gradually built out the features we see today. He’s the driving force behind the project and continues to actively maintain and develop it. Other Contributors: While Hofmann is the central figure, Kate has benefited from significant contributions from a community of developers and designers. Important contributors include: Matt Butcher: Made significant contributions to the UI design and the editor’s overall look and feel. Daniel Wani: Was instrumental in the early development and testing. Key Timeline:

2013-2015: Initial development started by Michael Hofmann as a personal tool. 2015: Kate was released as open-source. 2016: The first desktop version was released. In short, Michael Hofmann is widely considered the inventor of the Kate editor, but it’s a product of a collaborative effort.

You can find more information about the development history on the Kate editor’s website: katex.app

Ok? No idea where that stems from.

Next try, ask llama3.2:

I couldn’t find any information on who specifically “invented” the Kate editor, but it was primarily developed by Michael Hofmann.

The Kate editor is a command-line text editor that was first released in 2005 and has since become popular among programmers and developers. It’s known for its speed, efficiency, and customization options.

If you’re looking for more information on the history of Kate or its development, I’d be happy to try and help!

A bit better, at least some hint that the answer could be useless. Half contradicting the first, given there the same person seem to have invented that close to one decade later.

Next try, ask deepseek-r1:

The Kate editor was not invented by a single individual but is instead an open-source project that was primarily developed and designed by Michael Hofmann in 2005. Since then, it has been actively maintained and improved by a community of contributors who have added features, enhanced its functionality, and worked on its documentation.

Kate is known for its simplicity, speed, and ability to perform complex text transformations quickly. It is widely used in development environments and is often bundled with modern IDEs (Integrated Development Environments) like JetBrains Rider for Java and .NET projects.

If you’re looking for more details about Kate or its history, feel free to ask!

Matching a bit the second answer with more interesting random pseudo facts.

Ok, then let’s try the Brave browser AI search:

Kate Editor Inventor The KDE community developed the KDE Advanced Text Editor, or Kate. It has been a part of the KDE Software Compilation since version 2.2, which was first released in 2001.

That looks at least reasonable.

Let’s put the first sentence of one of the answers in the Brave browser AI search to see what happens then:

The Kate editor was not invented by a single individual but is instead an open-source project that was primarily developed and designed by Michael Hofmann in 2005.

You get back:

The Kate editor is part of the KDE free software community and was not invented by a single individual. Development of Kate began in 2001 with the release of KDE Software Compilation version 2.2. Michael Hofmann is known for his contributions to the project, but he did not single-handedly create it. Kate is an advanced text editor that supports syntax highlighting, code folding, and multiple cursors, among other features.

Now you have Michael Hofmann back, as that was in your search prompt. None of the linked search results tell you a sentences about Michael Hofmann, this was just nicely hallucinated into the summary because it was in the prompt.

I don’t say that AI tooling is useless, deep learning is a very useful tool.

But I am afraid many people will just read the AI summary box above the search results and believe that is a real summary.

No, it is not.

If you rephrase the

The Kate editor was not invented by a single individual but is instead an open-source project that was primarily developed and designed by Michael Hofmann in 2005.

to something different, with a different name and perhaps not that nice achievement, you will likely just get a hallucinated confirmation of your query.

And voila: you asked if some thing you heard somewhere is true and more or less get it confirmed because you asked about it.

We then end up here:

I said it because it is the truth. It is the truth because I said it.

I hope that enough people understand that issue and don’t fall for the trap of only peaking at the AI summary and not actually looking at the search results. But as it is that convenient, and even I often just read that first, I am afraid that will not be the case.

Naturally the search results themselves were never the fully reliable source of information.

They are weighted and sorted via algorithms that will keep in mind a lot of things that might not be in your interest and even without that, perhaps just the found pages are full of half truths or lies (like this one :)

But the AI summary box just adds one level more that can introduce just any kind of error or bias on top of that.

We're actually going to be using the Do Not Disturb feature in Plasma 6.4.

I say that because previously we had a hack that simply allowed notifications to display over top of fullscreen windows, and do not disturb was only ever used if:

• Screens are mirrored
• During screen sharing
• The user invoked it manually

This was a little odd, and led to some inconsistencies. Plus only Plasma knew about the user's preference to see notifications in fullscreen, and despite notifications being inhibited reading org.freedesktop.Notifications.Inhibited would return false.

I changed this to actually use do not disturb when a fullscreen window is focused. This is more predictable and in-line with what the user would expect, enhancing the UX and communication with other parts of the system and apps.

As a result, we've discovered several bugs that had gone unnoticed! So far:

• Notifications not being marked read
• Showing a summary for unwanted notifications
• Showing a summary every time the user leaves DND
• Not showing critical notifications in DND when we should
• Disabling app-specific notification history also prevents it from participating in DND summaries

My impression is that these bugs were not evident before because few people were actually using the do not disturb feature, thanks to the way we previously handled notifications with fullscreen applications. Everyone has been hard at work getting these fixed and hopefully DND will be more useful, predictable, and reliable! 🎉 😄

observability is very important in kubernetes and containerized environments, and debugging and troubleshooting kubernetes is always hard, tools that are effective and efficient are always needed, so unlike traditional systems where if something goes wrong you can easily ssh into the server and inspect, in kubernetes enviroments its a bit complex because of so many objects like pods, services and deployments that are running and interacting at the same time, so whenever something goes wrong or if there is a performance bottleneck or a misconfiguration it becomes difficult to pinpont the root cause, eBPF technology changes everything at the root level, it allows programs to be run in a isolated sandboxed enviroment securely and safely just as it is the kernel code itself, inspektor gadget is powerd by eBPF and kubernetes awareness of inspektor gadget makes it even more special. not only it provides deep visibility into low level system events like syscalls, network traffic, and file access but it also associates those events with high level kubernetes concepts, In this blog, well explore how inspektor gadget works, the challenges it solves, and walk through hands on examples to help you get started. If you're ready to unlock powerful insights into your kubernetes and linux environments, lets dive in!

What is Inspektor Gadget ?

Inspektor Gadget is a collection of tools, known as gadgets, that enable developers to inspect kubernetes and linux systems using eBPF programs in an accessible way. It also serves as a framework, providing a method for eBPF developers to easily build, package, deploy, and run these gadgets. By enriching kernel level data with higher level kubernetes concepts, inspektor gadget supercharges eBPF programs, making them easy for anyone to use and understand.

Inspektor Gadgets Capabilities

• With inspektor gadget, you can create and package eBPF programs into reusable OCI images, or gadgets, that are easy to share and deploy. Think of these gadgets as your observability toolkit, portable, lightweight, and prepared to take on specific tasks like monitoring network activity or tracing file operations.

• Whether you're managing a standalone linux server or a kubernetes cluster, inspektor gadget has you covered because it's designed to integrate seamlessly with both environments, allowing you to inspect systems wherever your workloads run.

• You can collect system data with a single command, then send it to your preferred observability tools, such as prometheus or grafana. Soon, we will be able to do this declaratively, which will streamline the process of automating and scaling your monitoring workflows.

• Inspektor gadget lets you lock down operations to prevent unauthorized access and to prioritize safety with built in mechanisms to control which gadget to run, This makes sure that the security of our system is not jeopardised by oour observability attempts.

• One of the most powerful features of inspektor gadgets is automatic enrichment. To put it simply, the data that eBPF collects from the kernel is unaware of kubernetes, container runtimes, or any other high level userspace concepts. Thus, inspektor gadget automatically uses kernel primitives like mount namespaces, pids, or similar to figure out which high level concepts they relate to, such as kubernetes pods, container names, dns names, etc. The process of enhancing the eBPF data with these high level concepts is termed as enrichment.

• Webassembly is also supported to process your data your way, thanks to inspektor gadget's support for WASM modules this allows us to write custom opertors in wasm supported language, the flexibility lets you customize data processing to your specific needs , whether you are transforming outputs or filtering events.

• Inspektor gadget even supports multiple operations modes , you can use it via a CLI or setup client server model or interact through an API or even embed it directly to your GO applciations as a library, its very convenient and specifically designed to fit seamlessly into your toolkit.

A Little Bit About eBPF

eBPF (Extended Berkeley Packet Filter) is a technology that lets you run sandboxed programs inside the linux kernel. Its like giving your system a superpower, capturing events like file accesses or network packets without modifying kernel code. eBPF is fast, safe, and versatile, powering modern observability and security tools. However, writing eBPF programs can be daunting, requiring kernel expertise. Inspektor gadget solves this by providing gadgets, abstracting the complexity while delivering eBPFs full potential.

Setting Up and Using Inspektor Gadget on Kubernetes

Now that we have explored inspektor gadget and its capabilities, lets get our hands dirty with some hands on learning, my favorite part!

Inspektor gadget offers a variety of gadgets for observability, and there are multiple ways to use it on kubernetes and linux systems. In this section, Ill demonstrate how to troubleshoot and debug a kubernetes cluster using two gadgets trace_open and traceloop Inspektor gadget can be used in two primary ways, on kubernetes clusters via kubectl plugins or on standalone linux systems using the ig cli.

For this demo, ill focus on the kubernetes approach, which involves a kubectl plugin running on your system and a DaemonSet deployed in the cluster to collect data.

My kubernetes cluster gadget-kluster with two nodes, is deployed on GKE in the us-west1-a region. You must have a kubernetes cluster as well, for local development you can use Minikube or Kind.

Krew is the recommended way to install inspektor gadget. To install krew, you must have git installed in your system. Use the git version command to check if git is installed on your system. If it is not installed, you must install git first. You can refer to git-scm.com for installation instructions.

Run this command in your bash or zsh shell to download and install krew plugin manager for kubectl

(  set -x; cd "$(mktemp -d)" &&  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&  KREW="krew-${OS}_${ARCH}" &&  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&  tar zxvf "${KREW}.tar.gz" &&  ./"${KREW}" install krew)

An output like this is expected when krew is installed successfully. If you encounter any error, try repeating the process in a fresh environment or check whether the required versions are compatible.

Run this command to add krew to your PATH environment variable

export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

To check if krew is successfully installed, run the kubectl krew command. If you see output similar to this then Krew has been installed successfully.

Now that krew is successfully installed, we can run the command kubectl krew search to get a list of all available kubectl plugins that can be installed via Krew. I simply use grep to search for the inspektor gadget plugin. As we can see, the plugin is not currently installed, so we need to install it.

Run kubectl krew install gadget to install the inspektor gadget kubectl plugin. After the command executes successfully, if we run kubectl krew search | grep gadget again, we can see that the plugin is now installed, it will show yes in the INSTALLED column.

Run kubectl gadget deploy to deploy the inspektor gadget daemon into your kubernetes cluster. The gadget runs as a DaemonSet on the cluster nodes to collect and analyze system data, so it is very important to deploy it first.

Once inspektor gadget is successfully deployed, if we run kubectl get ns, we can see that a new namespace called gadget has been created for inspektor gadget. All related resources will be deployed in this namespace.

Run kubectl get all -n gadget to view all resources inside the gadget namespace. You will see that the pods and daemon sets are up and running, which indicates that the deployment of inspektor gadget was successful.

trace_open is one of the gadget provided by inspektor gadget that traces file open events across containers in your kubernetes cluster. It emits events whenever a file is opened inside a pod.

Before using trace_open, we need to run an application that generates file access events, so the gadget has something to trace. Run the following command to start a simple BusyBox pod:

kubectl run --restart=Never --image=busybox mypod -- sh -c 'while /bin/true ; do whoami ; sleep 3 ; done'

This command launches a BusyBox pod that prints the current user every 3 seconds. These repeated actions help generate file open events, enables the trace_open gadget to capture and display meaningful output.

The trace_open gadget allows you to trace file open events within containers. By using the --podname flag, you can target a specific pod, in this case, mypod without specifying a node. This enables the gadget to identify and trace the pod across all nodes in the cluster.

To begin tracing file access events for mypod, run the following command:

kubectl gadget run trace_open:latest --podname mypod

This command invokes the latest version of the trace_open gadget and attaches it to the pod named mypod. It uses eBPF to trace system calls related to file access and emits events each time a file is opened by a process inside the pod.

In this example, the mypod container runs a BusyBox shell loop that prints the current user every 3 seconds. This behavior results in repeated file accesses (e.g. reading /etc/passwd), which will be traced and printed by the trace_open gadget in real time.

The whoami command appears to open /etc/passwd in order to resolve the user ID to a corresponding username. This file access is captured by the trace_open gadget.

You can stop the gadget at any time by pressing Ctrl+C in the terminal.

This example shows the capabilities of inspektor gadget specifically the trace_open gadget, in providing low level observability into container workloads. The detailed output generated during this trace is shown in the image.

lets explore the traceloop gadget, also referred as a system call flight recorder. This nickname makes perfect sense because just like a flight recorder or "black box" in an airplane captures every detail of a flight for later analysis in case of an incident, traceloop records system calls made by containers or processes in real time, storing a detailed trace that you can go through to understand what happened leading up to an issue. System calls are the fundamental interactions between a program and the Linux kernel (e.g. opening files, sending network packets), and traceloop captures these interactions with precision, making it an invaluable tool for debugging crashes, performance issues and unexpected behavior.

To use the traceloop gadget, we need to generate some events by running an application. Lets create a dedicated namespace for our traceloop resources to keep things organized

kubectl create ns test-traceloop-ns

To capture system calls and analyze their output for insights into system behavior, lets run an application that generates events. Use the following command to create and run a Busybox pod in the test-traceloop-ns namespace:

kubectl run -n test-traceloop-ns test-traceloop-pod --image=busybox --command -- sleep infinity

This command deploys a pod named test-traceloop-pod that runs a container with the sleep infinity command, keeping the container active indefinitely.

To deploy and run the traceloop gadget, execute the following command:

kubectl gadget run traceloop:latest --namespace test-traceloop-ns

This deploys the traceloop gadget in the test-traceloop-ns namespace, where it runs in the background as a system call flight recorder. It quietly captures system calls using eBPF and stores them in a ring buffer for later analysis, even for containers that have terminated. You can view the captured traces at any time using kubectl gadget traceloop show.

To generate system call data, run the following command to open an interactive shell inside the pod:

kubectl exec -ti -n test-traceloop-ns test-traceloop-pod -- /bin/hush

Then, inside the shell, type:

ls

This executes the ls command, which invokes system calls that the traceloop gadget will record. Since traceloop runs in the background, it wont display any data until you stop it by pressing Ctrl+C. This will terminate the gadget and show the recorded output.

When I stop the traceloop gadget by pressing Ctrl+C it displays output with fields such as K8S.NODE K8S.NAMESPACE K8S.PODNAME K8S.CONTAINERNAME CPU PID COMM SYSCALL PARAMETERS and RET these fields provide detailed information about the system calls made by containers in our kubernetes cluster, enriched with Kubernetes metadata for easier correlation.

Heres how traceloop works: it uses eBPF to silently capture system calls in the background. When I stop the tracing session with Ctrl+C it presents the recorded data. This data is invaluable for troubleshooting and debugging our kubernetes clusters, as well as enhancing observability by offering low level insights into container behavior.

conclusion

The powerful eBPF based features and smart enrichment of inspektor gadget are innovative for kubernetes and linux observability. See the inspektor gadget documentation to learn about other gadgets and features. Tools like inspektor gadget will become even more essential as the cloud native environment grows. Try it out, explore around with its features, and discover how it could boost your kubernetes workflows. In this blog post, we tried out two gadgets. I plan to explore inspektor gadget in more depth and explain more of its features in future blog posts.

I'm excited about this project. Thanks for reading, and stay tuned for more such blogs!

This week I powered up the StarFive VisionFive v2 board that I have. I figured I would give FreeBSD another whirl on it, in the vague hope that RISC-V boards are a more cohesive family than ARM boards were five years ago. tl;dr: I didn’t get it to work as well as I want it to. Here are some notes.

I mentioned this board when it arrived and documented the serial pinout as well, but it has been languishing while I had other things to do.

F(reeBSD) Around And Find Out

This is what I did. The board is listed as partially supported on the FreeBSD RISC-V Wiki so I’m not entirely surprised it craps out. I’ll update the wiki if I get any further than this.

• Downloaded a FreeBSD -CURRENT snapshot. The ISO images live here for RISC-V. I picked up the GENERICSD image from May 15th.
• Wrote the uncompressed image to a micro-SD card with dd.
• Stuck it in the board, connected serial ports, and powered it up.

The board starts and spits out things over serial, like all SBCs seem to do.

Platform Name             : StarFive VisionFive V2
Platform Features         : medeleg
Platform HART Count       : 5

Note the HART (core) count of 5. That’s relevant later, because this is nominally a quad-core CPU. After a little bit of SBI, we get to a U-Boot layer of the boot process, which tells me this:

U-Boot 2021.10 (Feb 12 2023 - 18:15:33 +0800), Build: jenkins-VF2_515_Branch_SDK_Release-24

CPU:   rv64imacu
Model: StarFive VisionFive V2
DRAM:  8 GiB

That is still consistent with what I think is on my desk. The FreeBSD kernel loads! And then the usual message Hit [Enter] to boot immediately appears. If I go on to boot normally, it invariably fails like this:

sbi_trap_error: hart0: trap handler failed (error -2)
sbi_trap_error: hart0: mcause=0x0000000000000005 mtval=0x0000000040048060

It is remarkably unhelpful to search for this, since the error message is both all over the place, and rarely fully explained or diagnosed. I don’t have a good explanation either, but

• This post from 2023 describes some early efforts, and
• Links to this issue report which says
• “I have to run fdt prop /cpus/cpu@0/status disabled at the FreeBSD loader prompt to correct this in order to boot.”

That fifth core, hart 0, is a different kind of CPU, and is mislabeled in the FDT that is still being shipped. FreeBSD then tries to set up the CPU in the wrong way, and it dies. The issue is quite descriptive, after you read it like six times to figure out what it actually means. Anyway, instead of hitting \[Enter\], I press some other key, and then use the loader prompt:

OK fdt prop /cpus/cpu@0/status disabled
Using DTB provided by EFI at 0x47ef2000.
OK boot

This subsequently craps out with:

starfive_dwmmc0: <Synopsys DesignWare Mobile Storage Host Controller (StarFive)> mem 0x16020000-0x1602ffff on simplebus0
starfive_dwmmc0: No bus speed provided
starfive_dwmmc0: Can't get FDT property.
device_attach: starfive_dwmmc0 attach returned 6

Followed by:

Mounting from ufs:/dev/ufs/rootfs failed with error 19.

Not even close to workable. The board itself is fine, there is a Debian image for it which just boots on through, does useful things, but that just isn’t what I want to run on this board.

It Helps To Read The Documentation

There’s a long post – someone who wanted to run FreeBSD, hit snags, then tried OpenBSD instead – over here in a GitHub gist that describes most of the process that I went though. And there is a post on the FreeBSD Forum about progress.

So I looked at both, and then went over the instructions more carefully.

• Write the generic SD-card image to a micro-SD card.
• Mount the EFI partition from the micro-SD card. Use gpart list da0 to see what GEOM thinks of the card. The card is GPT-partitioned, and the EFI partition is third on the disk in the standard getup. Then mount -t msdosfs /dev/da0p3 /mnt/tmp , and copy “the DTB file” into, say, the root of that filesystem. Scare quotes explained later. I used target name s5v5.dtb to save typing later.
• Unmount, then move the card to the VisionFive board.
• Boot, and interrupt SBI. Having remembered that the third partition is the EFI partition, load the DTB and EFI from there:

  load mmc 1:3 ${fdt_addr_r} s5v5.dtb
  load mmc 1:3 ${kernel_addr_r} EFI/boot/bootriscv64.efi
  bootefi ${kernel_addr_r} ${fdt_addr_r}
  

• This, somewhat to my surprise, chugs right along to a login: . The default credentials are root and root.
• Along the way, ethernet is detected and DHCP happens and partitions on the SD card are resized.

The scare quotes around “the DTB file” are because there are many DTB files floating around for this, and lots of links to an email message attachment. I downloaded it and this one works for me, so now I have archived it locally under a slightly different name.

Why the different name? Well, investigation at the SBI prompt with env print -a showed a variable fdtfile=starfive/starfive_visionfive2.dtb. I moved the s5v5.dtb file to that location in the EFI partition, and now I don’t need to interrupt SBI because it loads the right DTB file directly.

The lack of eMMC (the controller seems to be found, but the 16MB eMMC module isn’t) and NVMe (there’s an M2 slot, and I have a WD stick in there) means that storage is rather constrained, still, and there’s nothing I would trust a write-heavy load to.

What Would OpenBSD Do?

Going through the same steps with OpenBSD (which suffers from the same kind of “there’s a gazillion ways to put together an SD card for this board”, and not one is canonical or step-by-step) is also successful. More successful, even, because all the storage options are found:

nvme0: WDC WDS240G2G0C-00AJM0, firmware 231050WD, serial 22465R472602
scsibus0 at nvme0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <NVMe, WDC WDS240G2G0C-, 2310>
sd0: 228936MB, 512 bytes/sector, 468862128 sectors
gpiorestart0 at mainbus0
"clk_ext_camera" at mainbus0 not configured
scsibus1 at sdmmc0: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0: <Samsung, AJTD4R, 0000> removable
sd1: 14910MB, 512 bytes/sector, 30535680 sectors
scsibus2 at sdmmc1: 2 targets, initiator 0
sd2 at scsibus2 targ 1 lun 0: <Sandisk, SC32G, 0080> removable
sd2: 30436MB, 512 bytes/sector, 62333952 sectors

That is some serious storage for a tiny board like this.

Takeaways

It helps to read the documentation carefully. I need to update the FreeBSD wiki. The board is usable, but needs additional storage options to be a nice kind of machine for router-and-storage or NAS work.

Kirigami Addons is a collection of supplementary components for Kirigami applications. Version 1.8.0 is a relatively minor release, introducing two new form delegates along with various quality-of-life enhancements.

New Features

I added two new form delegates: FormLinkDelegate (!343) and FormIconDelegate (!355).

The first one is similar to FormButtonDelegate, but it’s used to display an external link. It’s already used on the About page:

The second one was upstreamed from Marknote and allows the user to pick an icon and display the selected icon.

I also added a password quality checker to FormPasswordFieldDelegate (!345). This is particularly useful when asking users to create an account:

Visual Changes

Kai Uwe Broulik improved avatar rendering. Initials are now always displayed consistently even on small screen (!363).

Kai also fixed an issue on mobile where library information on the About page was being ellipsized (!356).

Balló György fixed several issues when using Kirigami with the QtQuick software rendering backend (!350, !351).

I made the delegates provided by Kirigami Addons now have a slightly larger touch area on mobile (!349). Unfortunately, I also had to remove the small hover animations, as they occasionally caused visual glitches (1d6e84cd).

Convenient New APIs

Joshua Goins added an opened property to ConvergentContextMenu (!352), and I added a close method to allow closing the menu programmatically (!364).

I also added support for trailing items in FormTextFieldDelegate (f996fc6e).

Documentation

Thiago Sueto ported the entire library to QDoc (!354). QDoc provides much better support for QML.

Other Changes

“trapped-in-dreams” significantly improved the performance of the date picker (!360).

Volker Krause updated the project templates to reflect current best practices for Android support (!359).

Packager Section

1.8.0 had an issue with system not having QDoc, but a bug fix release is available as 1.8.1 with the fix for that.

You can find the package on download.kde.org and it has been signed with my GPG key.

We have moved the deadline for talk submission for Akademy 2025 to the end of the month. Submit your talks now! 

https://mail.kde.org/pipermail/kde-community/2025q2/008217.html 

https://akademy.kde.org/2025/cfp/

I recently made a patch to Konsole terminal emulator, that adds to the current tab layout saving system couple more things:

• Working directory
• Size of splits
• Optional command to run

You can find the patch here: ViewManager: Save columns, lines and working directory to tabLayout (!1095)

It's a feature I've seen in other terminal editors, so I wanted to add it to Konsole as well.

Note that this is not in current version of Konsole, but it will be in the next one: 25.07. Unless it gets backported, of course.

Current tab layouts

In Konsole, you can even in current version save your tab layout:

1. Open Konsole
2. Split the current view into multiple ones
3. Go to Menu -> View -> Save tab layout...

This produces a JSON file like this:

{
    "Orientation": "Vertical",
    "Widgets": [
        {
            "SessionRestoreId": 0
        },
        {
            "SessionRestoreId": 0
        }
    ]
}

Now, as it is currently, it's not that useful. The split sizes won't be saved, for example.

My changes

My changes now allow you to save the size of the splits and the working directories, like this:

{
    "Orientation": "Horizontal",
    "Widgets": [
        {
            "Columns": 88,
            "Command": "",
            "Lines": 33,
            "SessionRestoreId": 0,
            "WorkingDirectory": "/home/akseli/Repositories"
        },
        {
            "Orientation": "Vertical",
            "Widgets": [
                {
                    "Columns": 33,
                    "Command": "",
                    "Lines": 21,
                    "SessionRestoreId": 0,
                    "WorkingDirectory": "/home/akseli/Documents"
                },
                {
                    "Columns": 33,
                    "Command": "",
                    "Lines": 10,
                    "SessionRestoreId": 0,
                    "WorkingDirectory": "/home/akseli"
                }
            ]
        }
    ]
}

As you can see, it saves the Columns, Lines, WorkingDirectory. It also adds empty Command item, which you can write any command in, like ls -la, or keep it empty.

You can try to use the columns and lines sections to modify the size manually, but I've noticed it's easier just to do it inside Konsole.

Now the old layout file will work too, if the field doesn't exist Konsole won't do anything about it.

Note about the command: Konsole basically pretends to type that command in when it loads, so the commands don't need a separate Parameter field or anything like that. You could make the command something like foo && bar -t example && baz --parameter. Konsole then just types that in and presses enter for you. :)

More concrete example

I made this change because I wanted to run Konsole in following layout:

{
    "Orientation": "Horizontal",
    "Widgets": [
        {
            "Orientation": "Vertical",
            "Widgets": [
                {
                    "Columns": 139,
                    "Command": "hx .",
                    "Lines": 50,
                    "SessionRestoreId": 0
                },
                {
                    "Columns": 139,
                    "Command": "",
                    "Lines": 14,
                    "SessionRestoreId": 0
                }
            ]
        },
        {
            "Columns": 60,
            "Command": "lazygit",
            "Lines": 66,
            "SessionRestoreId": 0
        }
    ]
}

With these items I can get the layout splits as I want, with any commands I want.

Then I have a bash script to run this layout in the directory the script is run at:

#!/usr/bin/env bash
konsole --separate --hold --workdir "$1" --layout "$HOME/Documents/helix-editor.json" &

Now when I go to any project folder and run this script, it will open the Helix text editor, lazygit and empty split the way I want it, without having to make these splits manually every time.

Sure I could use something like Zellij for this but they have so much things I don't need, I just wanted to split the view and save/load that arrangement.

In future

I would like to add a small GUI tool inside Konsole that allows you to customize these layout easily during save process, such as changing the WorkingDirectory and Command parameters.

But for now, you'll have to do it inside the JSON file, but chances are when you want to do layouts like this, you're comfortable editing these kind of files anyway.

I hope some others will find this useful as well, for things like system monitoring etc.

Hope you like it!