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

As hinted here before, in October this year there will be the first dedicated conference for the Open Transport community, and the Call for Participation for that has just been published.

Open Transport Community Conference

In 2024 the Railways and Open Transport track at FOSDEM kick-started Transitous, and it looks like its 2025 edition also got something rolling: A dedicated multi-day conference for the Open Transport community.

Given the interest in that subject at various other events demand for that seems to be high, and following a discussion at FOSDEM an offer for a venue came in a few weeks later.

That sorted the logistical part, leaving us with the task of getting interested people together and come up with content. (And yes, after successfully dodging event organization for many years I misclicked on a meeting invite and am now part of the team organizing this…)

Time and location

The Open Transport Community Conference will happen on October 17th and 18th at ÖBB’s Open Innovation Factory in the middle of Vienna, Austria.

Participation is free, but you have to register.

Who is this for?

We want to create an event that is useful for everyone interested in, contributing to or working on Free Software and Open Data around public transport and shared mobility.

And while I have little doubt that putting people involved with routing engines (MOTIS, OpenTripPlanner, OpenRouteService, etc), applications (GNOME’s Maps and Railways, KDE’s Itinerary and KTrip, Transportr and Öffi, Träwelling, etc) and public transport data and data formats (OSM, MobilityData, transport operators, etc) together in a room for two days will be valuable, a bit more of an agenda probably helps to convince more people of this.

The event will be organized as an Unconference, so somewhere between a conference with pre-planned talks and a Hack Weekend without any pre-defined structure. We felt that the main gap left by very packed events such as FOSDEM is time for people to talk to each other and exchange more in-depth on a subject, so that’s what we are trying to focus on.

We also want to provide a forum for regional Open Transport communities to network and connect. A lot of things are happening locally and somewhat separate from each other, while often facing similar challenges that would benefit from more exchange and collaboration.

Call for Participation

We deviate from a pure Unconference approach a bit by already collecting possible session topics ahead of time. Spontaneous suggestions of course remain possible, but the idea here is to give people a better understanding of what to expect, given we are running this event for the first time.

Possible topics include but are by no means limited to:

• Schedule data, including data formats, data quality, tooling, QA as well as uses and lobby/outreach work for getting more data published.
• Shared and on-demand mobility data.
• Routing for all kinds of modalities, including engines, algorithms and APIs.
• Accessibility in public transport, including routing profiles, indoor routing, data standards and modeling and elevator status data.
• Passenger-facing applications around public transport and mobility usecases.
• Transit data analysis and research supporting passenger-facing usecases.
• Operations of open source public transport routing services.
• Digital tickets beyond proprietary platforms.
• Open source solutions for community-run mobility services.
• Geocoding.
• OpenStreetMap (OSM), including tagging schemas, data importing and upstream collaboration.
• Collaboration between public transport operators/agencies and the Open Transport community.
• Community work, such as local events/meetups.

See the Call for Participation for more information.

See you in Vienna!

Register for the event, propose session topics, join the event Matrix channel and spread the word!

Welcome to a new issue of “This Week in Plasma”! Every week we cover the highlights of what’s happening in the world of KDE Plasma and its associated apps like Discover, System Monitor, and more.

This week we really ramped up the focus on bug-fixing in preparation for Plasma 6.4’s release in three weeks. But we also managed to squeeze in a huge feature for the next release too: time-of-day wallpapers! Plasma now supports automatically changing compatible wallpapers between their light and dark versions based on the day/night cycle, and also features some visual polish to make the previews of these dynamic wallpapers look better and be more clearly indicated as dynamic. This was done by Vlad Zahorodnii; thanks a lot Vlad!

As with last week, don’t worry too much about the high-priority bugs list gaining items, as we’re using this to prioritize fixes during the Plasma 6.4 beta period.

Notable UI Improvements

Plasma 6.4.0

Discover no longer includes wallpapers and other add-ons in its search results unless you initiate the search while on the “Add-Ons” page. This should make most search results much more relevant! (Ismael Asensio, link)

Did a few rounds of visual polish on the Audio Volume widget, which can get quite complicated-looking when multiple audio devices are present. (Christoph Wolk, link 1, link 2, link 3, and link 4)

Plasma 6.5.0

Made major UI improvements to the Sticky Note widget to support the use case of having it in your panel: now you can resize them to be much smaller; change the background color from the context menu; and when you choose the “Transparent” background color, the colored sticky note background disappears entirely, tightening up the outer margins significantly if you want to save space. (Kai Uwe Broulik, link)

If you choose a font with the text “Display” in its name as one of your global fonts, System Settings now warns you that this isn’t a good idea, because these fonts are not intended for display on digital screens. (Nate Graham, link)

The first time you launch Emoji Picker (launchable via to the Meta+. keyboard shortcut by default), it now opens to a page showing everything, rather than the “Recent” page which of course would be empty. (Kai Uwe Broulik, link)

In the Networks widget, the “Hotspot” button is now always visible, but disabled when not available, and hovering over it tells you why it can’t be used right now and what you can do to change that. (Nate Graham, link)

All the debugging effects on System Settings’ Desktop Effects page have been removed from there and moved to the KWin debug window instead. Not sure how to access it? Search for “kwin debug” in Kickoff or KRunner! (Oliver Beard, link)

Improved accessibility and general keyboard navigation in the Audio Volume widget, Flatpak page in System Settings, and Updates page in Discover. (Christoph Wolk, link 1, link 2, link 3, link 4, and link 5)

Frameworks 6.15

Opening the “Advanced Options” window from the properties dialog for an item on the Plasma desktop no longer freezes Plasma completely until it’s closed. (Akseli Lahtinen, link)

Improved accessibility and keyboard navigation throughout System Settings, particularly around the topics of passing focus between page content and the window’s sidebars and footers. (Christoph Wolk, link)

When navigating Kirigami-based apps and System Settings pages using a screen reader, it will no longer rather pointlessly announce “LAYERED PANE ZERO ITEMS” all the time. (Christoph Wolk, link)

Notable Bug Fixes

Plasma 6.3.6

Fixed a case where KWin could crash when you disconnect multiple KVM-connected screens. (Xaver Hugl, link)

Fixed a bug that could cause per-widget Edit Mode to not exit properly. (Yu Wang, link)

Opening the “Add Action” window from the clipboard configuration dialog no longer freezes Plasma completely until it’s closed. (Nate Graham, link)

Deleting (not trashing) files from Plasma notifications’ context menus now works. (Kai Uwe Broulik, link)

Changing the screen tearing settings now takes effect immediately, rather than requiring a restart. (Xaver Hugl, link)

Fixed a case where junky graphical glitches could briefly be seen on the screen after logging in but before Plasma’s splash screen or desktop loads. (Xaver Hugl, link)

When XWayland-using apps deliberately ask to open on a specific screen, the screen they open on now more reliably matches the one they wanted. (Xaver Hugl and Vlad Zahorodnii, link 1 and link 2)

Plasma 6.4.0

Fixed a rare but severe issue that could allow bypassing the lock screen’s password prompt and unlocking without a password under certain circumstances. (Marco Martin, link)

Fixed a case where System Settings could crash right after you change a screen’s refresh rate. (David Edmundson, link)

Fixed a case where Plasma could crash when dragging cells from LibreOffice onto the desktop. Now it lets you create a media frame or sticky note out of the contents, as intended. (David Edmundson, link)

Fixed a bug that could cause WINE apps with custom window decorations to freeze when de-maximized. (Rémi Bernon, link)

Now the “Remote control requested” dialog will always tell you what is requesting remote control; at the very minimum, it will now give you the technical ID of the thing making the request if it can’t display a pretty name — rather than displaying nothing. (Stephan Seitz, link)

Fixed several cases where using a color picker to pick a screen color could return a very subtly wrong result when using certain combinations of Night Light, ICC profiles, HDR, 10-bit color, or any other features that globally change all colors on the screen. (Xaver Hugl, link)

Fixed a bug where the resize handles of a custom length panel could go off-screen when there was another panel on an adjacent screen edge. (Marco Martin, link)

In the System monitor app aid widgets, sorting by network speed no longer incorrectly puts processes with no network activity first, and now the “read/write” speeds are correctly displayed once more (Arjen Hiemstra, link 1, link 2)

Using the “Process Table” visualization for blank System Monitor sensor widgets no longer incorrectly makes them think they’re in need of configuration the next time you restart Plasma or the system. (Christoph Wolk, link)

Fixed a bug that caused the colors of the “Horizontal Bars” graph type in System Monitor Widgets to not be set properly the first time you added a widget using it to a panel or desktop. (Christoph Wolk, link)

Fixed a regression that caused the list of file types in a dialog on System Settings’ Default Applications page to overflow when it’s really really really long. (Nate Graham, link)

Row heights in System Monitor table views are once again perfectly identical, after a Qt issue caused this to stop being the case. (David Redondo, link)

When clicking the “Global Theme” Button on System Settings’ Quick Settings page, after it takes you to the Global Themes page as you asked, it also expands the sidebar to show all the child pages, just as if you had navigated there manually. (Marco Martin, link)

Previews in the wallpaper grid view now adjust their aspect ratio in real time if the screen’s own aspect ratio changes — for example due to a change in rotation or resolution. (Vlad Zahorodnii, link)

Frameworks 6.15

Fixed a regression in the new Kirigami icon shader code that caused app-provided system tray icons to sometimes look visually squished. (Vlad Zahorodnii, link)

Other bug information of note:

• 3 very high priority Plasma bugs (down from 4 last week). Current list of bugs
• 27 15-minute Plasma bugs (up from 22 last week). Current list of bugs

Notable in Performance & Technical

Plasma 6.3.6

Adaptive Sync is now disabled by default for new installations (not existing ones), because it exposes too many bugs in graphics drivers to offer a good enough experience for everyone. (Xaver Hugl, link)

Plasma 6.4.0

Made the clipboard popup window you can access using Meta+V faster to appear. (Fushan Wen, link)

Choosing a screen resolution that wasn’t one of the display’s native resolutions no longer incurs a steep performance penalty. (Xaver Hugl, link)

Plasma 6.5.0

Massively improved scrolling performance in Plasma’s wallpaper grid views. (Vlad Zahorodnii, link)

Qt 6.9.2

Implemented delegate recycling for Qt grid views, which offers the potential for improved performance in grid views throughout Plasma and QtQuick-based KDE apps. (Vlad Zahorodnii, link)

How You Can Help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

You can help KDE by becoming an active community member and getting involved somehow. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine!

You don’t have to be a programmer, either. Many other opportunities exist:

• Triage and confirm bug reports, maybe even identify their root cause
• Contribute designs for wallpapers, icons, and app interfaces
• Design and maintain websites
• Translate user interface text items into your own language
• Promote KDE in your local community
• …And a ton more things!

You can also help us by making a donation! Any monetary contribution — however small — will help us cover operational costs, salaries, travel expenses for contributors, and in general just keep KDE bringing Free Software to the world.

To get a new Plasma feature or a bugfix mentioned here, feel free to push a commit to the relevant merge request on invent.kde.org.

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.