This is a effectively a guest blogpost where I, as usual, take the credit for the work someone else has done.

Last year ago set out making a home automation <--> Desktop Linux bridge over the Christmas holidays.

The idea is that if you're using home automation your PC that you're in front of has a lot of important information that can be used for adjusting automations; are you in a call, are your headphones on, and so on. I made a small daemon, named Kiot (derived from "KDE Internet of Things") that exposes this information about your PC to Home Automation software, like Home Assistant.

It worked well enough for all my use-cases, so after a bit of initial buzz and a few drive-by fixes it fell to the wayside whilst I worked on other things.

In the last month it got a new contributor, Odd Østlie (TheOddPirate) who has been like a rocket ship of new features; and a bit of a community with another member being active in testing and feedback.

We now track and expose:

• bluetooth

• audio devices, volume control and selection

• battery states for laptops and wireless peripherals

• gamepad detection

• active window information

• media player/mpris connection

With more integrations in pull requests.
There's also the start of a configuration UI, so there's no messing about with configuration files.

I'll do another post once we've made a 0.1 and a flatpak, but if you're interested in KDE + home automation, go check out his work at https://github.com/davidedmundson/kiot .

Last weekend I attended this year's edition of the KDE PIM Sprint which, this time, took place in Paris.

I arrived in Paris around 1 p.m. and first walked from Gare du Nord to the Île de la Cité to have a look at the reconstructed roof of Notre Dame. Then I checked in at my hotel and after a brief rest I went to the sprint venue, the office of enioka. There I was greeted by one of our hosts for the weekend and by a few KDE PIMsters who had already taken over the meeting room.

After firing up my computer, KMail complained that it couldn't access one of my IMAP accounts. The error said "authentication failed" and a second error message claimed that access to KWallet (which stores the passwords of the IMAP accounts) was denied. Using the website of the mail provider I verified that my credentials still work. Adding the IMAP account a second time didn't help. Still the same errors. And a look at KWallet also didn't give me a clue why it should deny access to the password of one of my IMAP accounts when two other IMAP accounts worked. Since access to this IMAP account wasn't that important during the KDE PIM sprint I decided not to waste more time on this problem. This proved to be a good decision because once I was back at home the account magically worked again. I blame weird security measures by the email provider.

In the meantime more people had arrived and we went for dinner. Afterward we went back to the venue and, now that most people were there, we went over the list of topics from last year's KDE PIM Sprint. Some progress has been made since the last sprint but many topics didn't see much work done. Any and all help is welcome!

Originally I planned to look into a bug that's been haunting me for some time: KMail shows seemingly random counts of unread messages in the folder list that have little to do with the actual number of unread messages in those folders. Because I'm using the latest stable versions of almost all KDE software (as provided by openSUSE Tumbleweed) I started to build the release/25.12 branch of KMail and its 30+ KDE PIM dependencies. This took the rest of Friday evening and part of Saturday morning. Shortly before midnight we called it a day.

On Saturday morning, after a joint breakfast in the office, we discussed a few more topics from our agenda. After that I decided to scratch my original plan and, instead, to help with making the KMime library fit for becoming a KDE Framework. I created a few MRs to replace the usage of bool parameters in the API with enums. Then I looked into adapting the users of KMime to the new API. Unfortunately, this proved more painful than expected because KDE PIM does not only depend on the master branch of everything else in KDE PIM (which I was very well aware of) but a lot of the KDE PIM projects also depend on the master branch of the ktextaddons library which is a kind of intermediate library between KDE Frameworks and KDE PIM with its own release schedule. For many of the KDE PIM projects I could simply lower the required version of ktextaddons to the latest stable release (as shipped by Tumbleweed), but for pimcommon this hack didn't work anymore because it used a new header from ktextaddons master. By then it was already Sunday afternoon and anyway time for me to pack my stuff.

On my way to Gare du Nord I passed by Sacré Cœur on Montmartre where to my surprise a choir of Santa Clauses and Santa Claudettes was performing French Christmas songs.

In conclusion, I got more useful work done during this sprint than during some other sprints, although the dependency requirements of KDE PIM annoy me a lot. I've been involved in KDE PIM for 25 years now although, admittedly, I rarely contribute to it in my spare time since I started to code for a living. To a large part the reason for this is that it would cost way too much of my spare time to build all of KDE PIM all of the time.

Thanks to enioka for hosting us and to Kevin for organizing the sprint. And many thanks to those of you donating to KDE which makes these sprints possible.

This weekend, I attended the KDE PIM 2025 Sprint (AKA meeting) in Paris.

First, what does PIM mean? Personal information management.

Second, what does Personal information management mean? It's the software for managing email, calendar, address book, etc.

Third, this is going to be long, so let me thank https://haute-couture.enioka.com/en/ for hosting us (their office  is in Rue du Mail which seems very fitting for a meeting improving e-mail software) and thanks to KDE e.V. for sponsoring travel and hotel for the meeting. If you can, please donate so that more meetings like this can happen. 

This was my first time attending a PIM sprint even though I have been a KDE developer for a long time and a KMail/KOrganizer user for possibly even longer. 

It is true that these softwares are not in the most polished state, but honestly I would not know how to handle my email without KMail.

Anyhow here's a list of things I did: 

We talked a bit about bugs handling and it turns out not a lot of people are having a look at bugs, so I volunteered to watch the pim-bugs-null@kde.org address in Bugzilla (where most/all related bugs are assigned to) so I can help a bit. Note that I only committed to quickly read over them to try to make sure "really bad things" don't get overlooked. "Normal" bugs will always exist in every software and those will be fixed when they are fixed :)

If you also want to help you can set yourself to watch that pim-bugs-null@kde.org address in https://bugs.kde.org/userprefs.cgi?tab=email. 

On the topic of bugs, I managed to fix "left-click does not work on links with target="_blank" in HTML e-mails" with an impressive 1-liner change. It should be available with KDE Gear 25.12.1.

On Friday night, I experienced "sending emails does not work". After a few hours of debugging and thanks to our sysadmins, we found out it was due to "Your SMTP configuration was wrong". It seems older KMail versions were a bit more gracious when your configuration was wrong, but now it fails (fair enoug, although ideally it could give a better error). Incidentally I was not the only one with this problem since a few hours later we got this bug https://bugs.kde.org/show_bug.cgi?id=513284 that was basically the same. (My watching of pim-bugs-null@kde.org was already fruitful!)

On Saturday morning, I continued scratching my own itch and fixed a rather obscure bug where some context menu actions when right clicking on emails in KMail were not properly updated when expanding/collapsing threads.

KMime is undergoing API modernization and is slated to become a KDE Framework soon (TM). I helped a bit adapting code that uses KMime to the new API. 

On Sunday, I worked a bit on polishing address suggestion blacklisting on KMail (i.e. when I search for Foo, I don't want to get a suggestion to send an email to their old employer's email address). You can do that right now by right clicking on the "To" text field and selecting Completion Configuration and then going to the third tab. But that is a bit cumbersome (to the degree I had no idea that feature existed until the very same day). To make it a bit easier to discover, i have proposed adding a right click menu on the suggestions themselves that let's you blacklist that particular email address.

And now, a short list of things we did: (many more were done and will be explained in detail by other folks)

• Talk about switching the default backend to SQLite instead of mysql MariaDB. In general dropping servers (MariaDB/postgres) support would help making the code more maintainable. There are some people using it without problems, but Nico volunteered to do a test run during the sprint and he ended up with some problems, so there's still some things to debug there.
• Talk about doing a survey/adding more KUserFeedback data. We kind of agreed that first we need to know what question we really want to know the answer to and what would be the consequences of a given answer before spending time in designing a survey. But anyway if you use the KDE PIM software, please enable User Feedback in the settings, we promise we won't spy on you.
• New online accounts system. It should replace the not very useful accounts system that we now have (that also has a quite complicated dependency chain). It showed quite some promise in making things much more user friendly.

All in all it was a very productive meeting and I am happy to have attended.

On a closing note, one day we will have to speak about potentially sponsoring food for sprint attendees. We got travel and hotel sponsored, but I spent around 100 € on breakfast/lunch/dinner for that sprint (not going to any fancy place at all). Yes, I can spare that amount of money, but maybe some others in the community can not, and for sure we want them to also attend. One could even argue that having to spend money on top of spending a weekend and 2 work-holidays for the travel is a bit too much, it won't be me because I ❤️ KDE but someone could argue it 😁

KDE Gear 25.12 got just released.

This includes my fixes (or workarounds) for Konsole & Kate window activation on Wayland.

If you now start Kate or Konsole inside Konsole, the new processes will properly activate their windows to come on top of Konsole.

This works both for just starting new instances and for re-using already running ones.

For more details, see my older post about the implementation.

At the moment that only works for Konsole & Kate.

If that works nicely for our users, perhaps somebody will come up with a more generic way for that or we can move that workaround to some lower level of the stack.

:) For me that is already a nice Christmas present, I disliked that this was broken for years :)

Btw., thanks again for the amazing end of the year fundraiser results! €280k and counting :)

Feedback

You can provide feedback on the matching Reddit post.

At this year’s Akademy (the yearly conference and gathering of KDE), there were several talks about immutable Linux distributions born inside KDE. The first, and more covered in the news was KDE Linux, the distro with an officially sounding name. And the second one was KDE Neon Core, which sounds like a continuation of KDE Neon, but is quite independent of it.

Things shouldn’t come in twos. There needs to be another immutable KDE distro, so I’m announcing the …

Now, this is a bit of a joke.

This is not really going to be a new distribution (for real, not like KDE Neon claimed not to be a distribution back in the day :) ). I don’t have the expertise nor the time to make a distribution from scratch.

But, while listening to the presentations about KDE Linux and KDE Neon Core, I had the idea to see how many of the planned features for those distributions I could implement based on an already existing and quite popular distribution called … if you have a keen eye, you might have guessed based on the image above … NixOS.

Step 1: Immutability

At the crux of it, immutability (along with other related buzzwords) means that you can not have an update break your system. There are no half-updates, no mixing incompatible versions of packages, etc. And if something gets broken with the new version, you can always roll back your system to a previous version.

This comes out of the box with NixOS. It just does it in a different way to other distributions. Its package manager allows installation of as many versions of a single package as needed, and the user or a running application “sees” only the versions they are compatible with.

When you update your system, the old packages are still installed, and you can reboot the computer into the pre-update state (previous versions are called generations).

Booting into an old state doesn’t really do anything special, it just makes you “see” the versions of the packages that were active in that version of your system. You don’t even need to reboot most of the time – if you see that a new version of LibreOffice doesn’t open your file correctly, and you want to try with the previous version, just ask Nix to launch the old version for you. The old version of LibreOffice is still on your system even if you’ve not booted into the system version (generation) it was installed on.

Steps 2..n

My main computer is (and always will be) Debian, but I’ve been using NixOS on my laptop for months now. And it works quite well.

As NixOS can be installed or replicated from a single configuration file, I plan to create a repository that will hold the definition of the system on my laptop (aka, the reference installation of KDE Ni! OS :) ) and to keep it updated while I go through each of the steps of simulating other distributions’ features.

This way, anyone who wants to have KDE Ni! OS on their computer will be able to install it by installing NixOS and using this file for system definition.

The next step will mainly be for developers – it will be about replacing a system package with a version you (or somebody else) developed. For example, if you want the Plasma Vault to behave a bit differently, or to test a fix for a bug you found, any sane distribution should allow you to do that easily, and without endangering the system integrity (no sudo make install). So, KDE Ni! OS will have to be able to do it as well.

I hate waiting for compilations. For day-to-day it may only be a minute or two, but once you start doing another task, the context switching distracts from what you were doing before and breaks everything up. Life is too short to be waiting for computers.

Obviously the first answer is to have a faster machine, but having a super fast laptop and a super fast PC all the time contributes to e-waste which I also hate. Some of my test devices for touch and tablet work are 5 year old Intel atom devices that I still sometimes need to compile on to fix things.

The solution is distributed compiling, using multiple computers to share the work.

Icecream or distcc used to be the tools back in the day, but they're both quite dated and have other issues.

There's a relatively new kid on the block, sccache. sccache primarily serves as a way of keeping your cached compiled assets around (think ccache), but also sharing them across users. Sharing cached assets requires exactly matching paths and dependencies and compilers so it's not that great for my needs; but it seems it would be perfect for flatpak and immutable cases.

But sccache also has another trick up it's sleeve; distributed compilation.

The documentation for sccache is a bit overwhelming packed with enterprise level features https://github.com/mozilla/sccache/blob/main/docs/Distributed.md.
It wasn't that clear how to do something simple, so I thought it might be useful to share how I got things working nicely for me.

Installation

Sccache is probably available in your distribution, note that not all distros include the shared compiler part.

If not you can download a version from https://github.com/mozilla/sccache/releases/download

The nice part is it's statically linked with no external dependencies so you can throw it on anything, even if it's immutable like KDE Linux or even a Steamdeck or two.

The parts

Scheduler

The scheduler is the key part of the operation; the client sends requests to the scheduler which in return replies with a list of schedulers that can recieve payloads distributing them accordingly.

Simple

Create a file as follows:

scheduler.conf

public_addr = "0.0.0.0:10600"
client_auth = { type = "token", token = "dave_is_great" }
server_auth = { type = "token", token = "dave_is_great" }

sccache-dist scheduler --config scheduler.conf

Docker

As I want the scheduler always on, I run it on a small home-server, where I prefer to docker-ise everything.

docker-compose:

version: '3.8'

services:
  sccache-scheduler:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        VERSION: "v0.10.0"
        SHASUM: bbf2e67d5e030967f31283236ea57f68892f0c7b56681ae7bfe80cd7f47e1acc
    image: sccache:latest
    container_name: sccache-scheduler
    ports:
      - "10600:10600"
    volumes:
      - ./scheduler.conf:/scheduler.conf:ro
    entrypoint: ["/usr/local/bin/sccache-dist", "scheduler", "--config", "/scheduler.conf"]
    restart: unless-stopped
    environment:
      - SCCACHE_NO_DAEMON=1

Dockerfile

FROM alpine:3.9.2

ARG VERSION
ARG SHASUM

RUN apk add clang
RUN apk add curl
RUN apk add --no-cache bubblewrap

RUN curl -L https://github.com/mozilla/sccache/releases/download/$VERSION/sccache-dist-$VERSION-x86_64-unknown-linux-musl.tar.gz > sccache-dist.tar.gz \
    && tar xf sccache-dist.tar.gz \
    && mv sccache-dist-$VERSION-x86_64-unknown-linux-musl/sccache-dist /usr/local/bin/sccache-dist \
    && rm -r sccache-dist.tar.gz sccache-dist-$VERSION-x86_64-unknown-linux-musl

RUN apk del curl

ENTRYPOINT ["/usr/local/bin/sccache"]

and the scheduler.conf as above.

Servers (build machines)

This is the part that does the building.
The config takes the address of the scheduler, but also the server's own IP address as a sort of "callback" address.

It needs to run as root in order to have capabilities to set up sandboxing and restrict it back down to something lower than where we started. The sitaution is a bit silly, but it is what it is.

server.conf

public_addr = "192.168.1.YOURIPADDRESS:10501"
scheduler_url = "http://192.168.1.SCHEDULERIPADDRESS:10600"
cache_dir = "/tmp/toolchains"
scheduler_auth = { type = "DANGEROUSLY_INSECURE" }

[builder]
type = "overlay"
# The directory under which a sandboxed filesystem will be created for builds.
build_dir = "/tmp/build"
# The path to the bubblewrap version 0.3.0+ `bwrap` binary.
bwrap_path = "/usr/bin/bwrap"

Then you can run sudo sccache-dist server --config server.conf

Systemd

As I want this running constantly on my desktop and laptop I use a systemd service.

/etc/systemd/system/sccache.service
[Unit]
Description=sccache scheduler
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/sccache-dist server --config /etc/sccache/server.conf
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Clients

The final part is relatively simple, making local builds use the other build servers.

First we need to set up a config as follows:

.config/sccache/config

[dist]
scheduler_url = "http://192.168.1.SCHEDULERIPADDRESS:10600"
toolchains = []
toolchain_cache_size = 5368709120
auth = { type = "token", token = "dave_is_great" }

Cmake

Enabling requires just telling cmake to use the relevant wrapper with -DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache

kde-builder

And/or it to your kde-builder as follows:

.config/kde-builder.yaml

global:
  cmake-options: -GNinja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON  -DCMAKE_CXX_COMPILER=clang++ \
    -DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache 

and reconfigure the project(s)

Quirks and workarounds

The most annoying quirk is servers need a consistent IP address within your network. Servers register to the scheduler with a fixed IP address. When clients queue jobs they are given the IP addresses back from the scheduler and are expected to then talk to the build server(s) directly. Using hostnames doesn't work.

Note also if you change your local .config/sccache you may need to run sccache --stop-server on the client to relaunch. Confusingly in this case 'server' refers to a process on the client that compile jobs are thrown at.

Debugging

sccache --dist-status will show the connected schedulers and how many total active jobs

Managing job count

By default ninja schedules the same number of jobs as you have local cores for. It's unaware of the many other cores you have.
I have this in my zshrc to set the number of jobs to the total number on the scheduler at that time.

function getSccacheCPUs() {
        sccache --dist-status  | jq '."SchedulerStatus"[1].num_cpus'
}
alias ks='MAKEFLAGS=-j${getSccacheCPUs} kde-builder'

Comparison to icecream

Cons:

• The setup process is a lot more laborious than icecream's magic turn-up-and-compile structure
• No cool UI to see how many tasks are being compiled.

Pros:

• It's very robust to network issues. If the scheduler is down or no servers are available things build locally extremely transparently
• It also has it's own equivalent of a local 'ccache' which means you don't need to worry about daisy-chaing compilers wrappers to still have cached output.
• It's actively maintained, the last meaningful commit in icecream is years ago

KDE’s 30th birthday is coming up next year. For this year’s holiday season I therefore decided to compile a list of 30 reasons why I love KDE Plasma. It makes me so much more productive and work a lot more fun. While some of the items listed below aren’t unique to Plasma, it’s the combination of all of those things that truly makes it the best desktop environment out there. Tell me, what are your top reasons?

1. When I suspend my laptop, any video or music stops playing
2. I can use three fingers on my touch pad to switch virtual desktops
3. I get a notification when my wireless mouse is about to run out of juice
4. I can middle-click a window on the task bar to close it
5. I can have a sticky note in my panel for use as a scratchpad
6. I can middle-click the notification icon to engage “do not disturb” mode
7. There’s a handy little color picker widget for my panel
8. I can throw my cursor into the corner of the screen to peek at my desktop
9. I can keep any window always on top when I need to
10. I can create a QR code of anything I copy to my clipboard
11. When I take a screenshot, I can then just drag it to where I need it
12. I can change the screen brightness by mouse wheeling the brightness icon
13. I can drag a window to the top of the screen to maximize it
14. I can send a window to different virtual desktops by using a global shortcut
15. There’s a little live volume meter in each slider in the volume popup
16. I can bring up a little magnifier window around my mouse cursor
17. I can draw red lines on the screen using a desktop effect
18. I can use the back/forward mouse buttons on the task bar to change music tracks
19. When I wiggle the mouse, the cursor gets bigger and bigger, and there’s no limit!
20. Night light comforts my eyes in the evening hours
21. KRunner finds browser tabs in the mess of hundreds of tabs I have
22. I can raise the speaker volume above 100% when needed
23. I can wheel a window’s title bar to change its opacity to quickly compare stuff
24. I can make the Copilot key on my keyboard actually do something useful
25. I can use window rules to force apps to open exactly how I want
26. I can add custom global shortcuts for almost anything
27. System Monitor displays a tonne of info, including from my solar installation
28. I can speed up playback of pretty much any video from Plasma’s Media Controller
29. I can use Meta left click to move and Meta right click to resize a window anytime
30. I can quickly access recent files opened in an app by right clicking its task bar entry

… and that is just Plasma, not even mentioning fantastic apps like the Dolphin file manager, Konsole, Kate editor, and of course KDE Connect. Another way to show your love for KDE is by donating to our Year End Fundraiser and maybe even adopt an app!

Akademy is a special event for most of KDE people, it is opportunity for KDE developers, designers, users etc to meet and greet each other face-to-face. I have been attending most Akademies since year 2014. So of-course this year also I attended Akademy 2025 in Berlin. Last time I was in Berlin was right before pandemic happened, attending KDE Plasma Mobile Sprint in KDAB offices. It’s always lovely to visit this beautiful city!

Naïvely, I ran freebsd-update -r 15.0-STABLE install in my regular FreeBSD desktop. That was a mistake.

In principle freebsd-update is the way to update the installed system. In principle it works really smoothly, from binary release to binary release: it has a good manpage which tells you you can go from release to release. My FreeBSD laptop (which also runs Fedora 42 as more of a daily-driver OS) was running 14.3, so:

• freebsd-update -r 15.0-RELEASE upgrade Fetch all the things.
• freebsd-update -r 15.0-RELEASE install Install the new stuff.
• reboot Smooth sailing.

That is the naive and optimistic thing to do.

If you spotted “make sure you read the announcement and release notes” in the manpage, good for you.

After the reboot, I was dropped into a shell where nearly every command I typed in resulted in

ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7"

Good Bug Reports Help

Fortunately, Graham Perrin had already reported this with basically-the-same steps to get into trouble.

And based on that Matthew and Colin made a fix so that other people could first update their packages (e.g. pkg update on the system before using freebsd-update) to get the fixes in to the package-manager.

Good Workarounds, Also

In the same PR (Problem Report), Craig describes a workaround which almost worked for me. Because it’s a laptop, I needed a few extra steps. As an aside, /rescue is a directory where statically-linked rescue binaries live, which don’t suffer from shared-library misery.

• /rescue/kldload if_ure Load the kernel driver for the USB-ethernet port.
• /rescue/dhclient ue0 DHCP to get some network.

I have root-on-ZFS, and in single-user mode this comes up read-only, so switch read-only off. This is different from other (e.g. UFS, ext4) filesystems where mount -o rw,remount would be the thing to do:

• /rescue/mount To check what the name is of the ZFS mounted on /
• /rescue/zfs set readonly=off zroot/ROOT/default Make it read-write.

Edit 2025-12-17: Fixed typo’s in the path of the commands

After that, basically Craig’s steps:

• cd /tmp
• /rescue/fetch https://download.freebsd.org/releases/amd64/15.0-BETA2/base.txz Fetch the installation tarball.
• cd /
• /rescue/tar xzf /tmp/base.txz lib/libsys.so.7 Extract the missing library.
• freebsd-update install This one is the “normal” dynamically-linked one, which works now the missing library is there.

Post-Upgrade Mucking About

Since there wasn’t anything especially configured or complicated on this machine, I reinstalled the package-manager with a hammer and then upgraded all the packages:

• pkg-static install pkg Reinstall with a known-good tool.
• pkg update Fetch all the things.
• pkg upgrade Install all the things.

Somehow I’ve also gotten myself stuck in a “graphics driver causes kernel panic”, state. Which kind of limits the graphics side of things this week. Amusingly AMD GPU stability is listed as a release feature, but #391 and #393 issues tell a slightly different story. I’m glad of bz@’s proposed fix, although I’ll need to rebuild the kernel to try it (which literally means make buildkernel installkernel on FreeBSD, it’s that simple).

After months of being completely consumed by my bachelor thesis and then giving myself some much needed rest, I finally have the time and headspace to sit down and write this post. And honestly, I have been waiting to write about this because Akademy 2025 was special.

This was my first in person Akademy after three years of attending remotely. Every year I would watch talks through a screen, imagining the energy in the room and the hallway conversations I was missing. This time, since my thesis brought me to Europe to work at CERN, I finally had the chance to join everyone in Berlin. KDE made it possible for me to attend in person, and I was also scheduled to give a talk on my Google Summer of Code project, KEcolab, which I currently maintain. So you can imagine how excited I was for this entire week. People say Akademy feels more like a KDE festival than a conference, and I was about to find out why.

I packed my bags in Switzerland and left for Berlin.

Arrival and Welcome Dinner

I reached Berlin on the fifth and went straight to the welcome dinner near Tiergarten. The restaurant had a relaxed vibe, and within minutes I was meeting people I had only ever known through Matrix usernames. Suddenly the names on my screen had real voices and real faces. We talked about everything from new KDE developments and the Banana release to personal side projects and long contribution journeys.

I finally met the KDE Eco team and the people working on the Endof10 campaign which is going amazingly well. We chatted over drinks, laughed a lot, and I might have invited half the table to visit CERN if they ever pass through Switzerland. Dinner was great. I had a pasta salad whose German name I still cannot pronounce, along with some very nice KDE drinks.

I returned late at night and realised that my slides were still not ready. My talk was scheduled for early morning on day one, so I stayed up finishing everything and managed only a few hours of sleep before the big day.

Day One

Day one opened with a keynote by Alexander Rosenthal on Open by Design. It set a very thoughtful tone for the conference. Right after that, I gave my talk titled KEcoLab: KDE’s Automation Tool for Energy Consumption Measurements. You can watch it here: https://youtu.be/ybduSygg2Ns?si=tZlXN7XuGcfyux-Q The audience asked some great questions about expanding energy measurements to more applications and tools and how the process of measurement works behind the scenes.

Presenting KEcoLab at Akademy 2025

My talk overlapped with the Plasma talk, so I unfortunately could not attend that one. I spent the rest of the day listening to some very inspiring sessions. The KDE annual recap was a highlight, showing how far we have come as a community. It covered improvements across many applications, developments in Kirigami and updates to the new language bindings for Rust and Python. There was also a small peek into what is coming next such as improvements to drawing tablet support and the Plasma keyboard.

If you are interested in contributing to KDE, trust me when I say there are endless ways to do so even if you are not a technical person. You can explore opportunities here: https://community.kde.org/Get_Involved

Day Two

Day Two was packed with talks that focused on being thoughtful developers and maintainers. The keynote by Paloma Oliveira, titled The Politics of the Pull Request, stood out to me. It explored open source from angles we often overlook and gave me a lot to think about.

Paloma Oliveira’s keynote on “The Politics of the Pull Request” - exploring the social and political dimensions of open source collaboration

I also enjoyed talks related to Wayland and Plasma Mobile, and in between sessions I helped volunteer at the welcome desk. At the end of the day, we all gathered at C Base for the social event. Great pizza, great people, great atmosphere.

Day Three

Day Three was dedicated to BoFs. I attended the KDE Goals BoF and then started preparing for the KEcolab BoF because we had to quickly fix a few last minute issues in the lab setup.

Our session was right after the Okular BoF, which turned out to be perfect timing. The Okular team gave us really helpful input since KEcolab and Okular are working on an ongoing integration. We talked about the possibility of running individual energy tests on different components and many other ideas. You can follow the issues we discussed here: https://invent.kde.org/sdk/kecolab/-/issues

Day Four

Day Four had more BoFs. I am sad I missed the You Can Dance BoF because it sounded like everyone had a lot of fun. I joined the KDE Out of Experience BoF and the KDE Flatpak BoF instead, both of which were genuinely interesting.

Day Five

Akademy day trip. This was incredibly fun. We were split into groups and had to complete different tasks around Berlin. We even had a bear themed challenge which led to some hilarious photos. We placed KDE stickers on poles, shared selfies and enjoyed the entire city.

Exploring Berlin with the KDE community - sticker missions, bear challenges, and unforgettable moments

Later we visited the Computer Museum which was heaven for anyone who loves old hardware. They had everything from retro consoles to the legendary 3dfx Voodoo chips. I spent way too long inside the museum and ended up missing the group that went to the dinner spot afterward.

Classic Macs - The originals that started it all

Day Six

The last official day included the Linux InstallFest. A few new contributors came in to install Fedora KDE on their laptops and it was a relaxing final day. People were packing, saying their goodbyes and heading home. I stayed for the after drinks event and spent the evening talking to more people before ending the day with bittersweet farewells.

But Akademy was not over for me yet.

Day Seven

I stayed an extra day to work on the KEcoLab lab with Joseph and Volker in KDAB, Berlin. Huge thanks to both of them. We switched the lab from KDE Neon to Fedora and set up Wayland. We are now testing ydotool so KEcoLab will run smoothly on Wayland as well. We did ran into few issues with the VNC but it was still productive, fun and a perfect ending to the week.

After lunch I said my final goodbye to Berlin and headed to the airport.

Final Thoughts

Akademy was one of the best conference experiences I have ever had. It was a week full of meeting incredible people, listening to inspiring talks, sharing ideas, social beers and feeling truly part of KDE.

KDE is one of the most welcoming open source communities and I am grateful to every single person who made my time there so special.

Thank you to KDE eV for sponsoring my attendance. Thank you to everyone I met for the warm conversations and kindness. I will not list names because I would definitely miss someone but you all made this Akademy unforgettable.

A special thanks to my KEcoLab team (Joseph, Volker, Kieryn (for the constant help throughout the event, Aakarsh and all past contributors). Also a big thank you to the KDE Eco Team, the EndOf10 team, KDE Promo and the entire KDE family. And of course thanks to the volunteers and organizers who made Akademy perfect from start to finish.

I already cannot wait for the next one.

The KDE community