Dear readers,

Before our regularly scheduled program, it is time for a little service announcement.

I will be taking some vacations for the coming three weeks. I’ll try to disconnect as much as possible for once. I thus won’t post another review in the next three weeks. It also means that I’ll try to not read as much as usual on the web either, so I probably won’t collect many URLs during that period. Don’t expect a mega-compilation when I come back!

That being said, let’s go for my web review for the week 2025-26.

Everyone should copy Thunderbird

Tags: tech, foss, fundraising

This is a model which seems to work for donation campaigns for FOSS projects. I wonder how much this scales though… if everyone does that, is there a point where users will be fed up with it?

https://blog.cyrneko.eu/everyone-should-copy-thunderbird

Matrix.org - Dispelling myths and misinformation

Tags: tech, matrix, community, foss

It’s indeed difficult to separate FUD from the real community issues around Matrix right now. We’ll have to keep an eye on how things evolve.

https://matrix.org/blog/2025/06/dispelling-myths/

A family of forks

Tags: tech, ssl, security, foss

The situation around OpenSSL and its fork is rather confusing… And there’s no indication this would improve.

https://daniel.haxx.se/blog/2025/06/23/a-family-of-forks/

Are LLMs ‘useful’?

Tags: tech, ai, machine-learning, gpt, criticism

Interesting comparison, indeed would a clock like this be useful?

https://azhdarchid.com/are-llms-useful/

Why computational reproducibility matters

Tags: tech, reproducibility, science, research

There are indeed fields where this matters a lot. It is far from being an easy problem to solve though.

https://blog.khinsen.net/posts/2025/06/20/computational-reproducibility.html

Introduction to the A* Algorithm

Tags: tech, algorithm, graph

Nice explanation of how graph search algorithms work. If you need to build some path finding feature this is for you.

https://www.redblobgames.com/pathfinding/a-star/introduction.html

Deep Down the Rabbit Hole: Bash, OverlayFS, and a 30-Year-Old Surprise

Tags: tech, linux, kernel, system, filesystem, shell, debugging

You like weird bugs involving shell implementations, syscalls and filesystems? Somehow I do, this was an interesting one.

https://sigma-star.at/blog/2025/06/deep-down-the-rabbit-hole-bash-overlayfs-and-a-30-year-old-surprise/

mbake is a Makefile formatter and linter. It only took 50 years!

Tags: tech, make, linting, tools

Nice! At last a Makefile linter. It has some interesting features, I especially like the automated .PHONY target management.

https://github.com/EbodShojaei/bake

Fun with uv and PEP 723

Tags: tech, python, scripting

uv really opens the door to nice features for Python. Now with a standardized PEP to help the configuration it’s getting even better.

https://www.cottongeeks.com/articles/2025-06-24-fun-with-uv-and-pep-723

Basic facts about GPUs

Tags: tech, gpu, computation, hardware, performance

A good reminder that “push it to the GPU and it’ll be faster” isn’t true. If you move a workload to the GPU you likely have to rethink quite a bit how it’s done.

https://damek.github.io/random/basic-facts-about-gpus/

Passing Functions to Other Functions in C++

Tags: tech, programming, metaprogramming, c++

A bit old perhaps, but shows quite well the various options to pass a function around in C++.

https://vittorioromeo.info/index/blog/passing_functions_to_functions.html

std::shared_ptr’s secret constructor

Tags: tech, c++, memory

I think this is indeed something still easily overlooked. You can deal with this kind of intertwined lifetime issues using shared_ptr.

https://www.justsoftwaresolutions.co.uk/cplusplus/shared-ptr-secret-constructor.html

Reflecting JSON into C++ Objects

Tags: tech, c++, metaprogramming

More details one how the new C++ reflection features can be used. This is a really nice feat here to parse a JSON at compile time to make an object.

https://brevzin.github.io/c++/2025/06/26/json-reflection/

Weird expressions in rust

Tags: tech, rust, type-systems, funny

I like this kind of oddities in languages. This is nice to see such a list for Rust at a single place.

https://www.wakunguma.com/blog/rust-weird-expr

“Why is the Rust compiler so slow?”

Tags: tech, rust, compiler, performance

Nice exploration which shows the many levers one can use to impact Rust compilation times. They all have their own tradeoffs of course, so don’t use this just for the sake of reducing time.

https://sharnoff.io/blog/why-rust-compiler-slow#putting-it-together

How much code does that proc macro generate?

Tags: tech, rust, metaprogramming, compiler, performance

Nice new tool to investigate code generated by macros in Rust. Indeed you can quickly add lots of lines to the compiled code without even realizing, in large code bases it’s worth keeping in check.

https://nnethercote.github.io/2025/06/26/how-much-code-does-that-proc-macro-generate.html

Rust: A programming language that grows with you, your career and your projects

Tags: tech, rust, learning, expertise

This piece is a bit too much written as Rust zealotry for my taste. That being said, there’s in my opinion an interesting core truth hidden in there: for now it seems to better foster “expert generalists” when investing in it. Now it might be just for now and might stop later… time will tell.

https://kerkour.com/rust-grows-with-you

No Time To Learn (Web) Framework X

Tags: tech, web, framework, learning, career

Good followup to a similar piece from someone else about React. Frameworks with a short half-life are not worth the hassle to learn, focus on more fundamental skills instead.

https://brainbaking.com/post/2025/06/no-time-to-learn-web-framework-x/

Classes vs. Data Structures

Tags: tech, programming, type-systems, object-oriented

This is a difference which needs to be reminded. Using precise language obviously helps.

https://blog.cleancoder.com/uncle-bob/2019/06/16/ObjectsAndDataStructures.html

TDD Antipatterns

Tags: tech, tdd, tests, pattern

Yes, tests can follow patterns as well… and antipatterns too. It’s good to name those antipatterns, let’s avoid them shall we?

https://agileinaflash.blogspot.com/2009/06/tdd-antipatterns.html

Pairing vs. Code Review: Comparing Developer Cultures

Tags: tech, quality, pairing, codereview, culture, team

Both approaches have their pros and cons of course. Whatever you pick, it has to start with a care for quality shared within the team.

https://phinze.com/writing/pairing-vs-code-review

Don’t get locked up into avoiding lock-in

Tags: tech, foss, vendor-lockin

Interesting framework to reason about lock-ins. It’s not only about depending on a vendor, there are other factors to keep in mind. Now obviously I’d see the risks around cloud hosting in particular in a different way than the author… but I guess we’re biased differently there.

https://martinfowler.com/articles/oss-lockin.html

In Praise of “Normal” Engineers

Tags: tech, productivity, organization, team, engineering, culture

I like this article. Indeed, focus on building organisations and teams where it’s easy to do the right thing bit hard to fail. This is much better than obsessing over mythical 10x engineers.

https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/

The Case for Scrum Dying in a Fire

Tags: tech, scrum, agile, criticism

The whole Scrum training and certification industry has a problem… and it’s been going on for a long time.

https://ronjeffries.com/articles/2015-02-23-die-in-a-fire/

Ticket-Driven Development: The Fastest Way to Go Nowhere

Tags: tech, agile, project-management, craftsmanship, team

If your team is solely in “pushing tickets out” mode, there’s indeed a problem. Teams needs more agency and care for the output to actually strive long term.

https://thecynical.dev/posts/ticket-driven-development/

Dependencies, Scrum of Scrums, and SAFe

Tags: tech, scrum, safe, project-management, dependencies, organization, agile

Definitely this, as projects scale, keeping an eye on dependencies between teams is key to efficient allocation. This will happen by trying to eliminate said dependencies, reallocating between teams.

https://ronjeffries.com/articles/2015-02-08-dependencies/

Visualizing Progress with Agile Storymapping

Tags: tech, agile, project-management

A bit of a forgotten approach I think. A good way to quickly gauge projects, show the amount of work and spot the dependencies.

https://uxmag.com/articles/visualizing-progress-with-agile-storymapping

What accomplishments sound like on software engineering resumes

Tags: tech, hr, hiring, interviews

Good advice. Since I got to review quite a few… I’d like to see them more like that. The worst part is when one also fails to point his accomplishments during the interview. I ask specific questions about this and most time get nothing meaningful in return.

https://jacobian.org/2020/may/8/engineering-resume-accomplishments/

The Tyranny of Stuctureless

Tags: organization, community, politics, decision-making

An old paper which is still very relevant today. It’s very much written in the context of the early women’s liberation movement, and yet the lessons a much more broadly applicable.

https://www.jofreeman.com/joreen/tyranny.htm

Bye for now!

If you are a developer and your KDE project is still based on Qt5 you should really really start porting to Qt6 now. 

https://mail.kde.org/pipermail/kde-devel/2025-June/003742.html

Dear fans of music & open source music players,
in preparation of the upcoming Amarok 3.3 release, a second beta release (3.2.82) has been prepared.

This time, the most important change is the new GStreamer-based audio backend. This enables a number of features that weren't available on Qt6 Phonon backends, and likely also provides a more reliable audio experience in general. In addition to audio system work, e.g. more safeguards have been set up around collection scanning code to prevent some potential database issues. More details on changes are listed in the ChangeLog.

These come in addition to the previous beta 1 changes (Qt6 only, database update). Please note that due to the database update in beta 1, downgrading from 3.3 betas is not directly possible, and returning to pre-3.3 versions requires the database (at ~/.local/share/amarok/mysqle/) to be manually backed up beforehand.

Additionally, there isn't an official release with Qt6 support of liblastfm available yet (needed for last.fm support). To enable last.fm functionalities, one needs to use a library version built from e.g. sources at https://github.com/Mazhoon/liblastfm/tree/81e8f9dc16a0a18fe9a066d51c2071086326670b

The Amarok 3.3 beta 2 source tarball is available on download.kde.org and it has been signed with Tuomas Nurmi's GPG key. In addition to the source code, it is likely that some distributions will provide beta packages. The various nightly git builds provided by various splendid packagers should also provide a way of using the beta changes and participating in the testing.

Happy listening!

Those of you upgrading to Plasma 6.4.1 (released yesterday) may notice a more substantive change than the type we typically make in bug-fix releases: The “highlight window” effect for Task Manager thumbnails is now off by default. This is the effect that makes other windows fade out when you hover over a window’s thumbnail.

Why did we turn it off? Because we discovered that with certain window arrangements and mouse movements, the current implementation could potentially cause full-screen flickering at greater than 3 Hz, which is potentially capable of triggering seizures in sensitive people.

Now, this is very unlikely. You’d need to open multiple full-screen windows of the same app, hover over their task to show thumbnails for them, move the pointer over one of the thumbnails, and then move it rapidly across all the others.

…Unlikely, but not impossible! And until and unless we can fix the effect to not be so flickery with this specific usage, it’s safer to keep it off. Furthermore, even for people who aren’t photosensitive, it’s currently a really unpleasant visual effect.

This work was done as a part of KDE’s recent accessibility push, and specifically the focused effort to make Plasma fully compliant with new EU accessibility regulations. Work is currently going on at all levels of the software stack, with multiple people involved and multiple sponsors funding it — both KDE e.V. itself, and also outside firms and institutions. If you’d like to see more of this kind of thing, donating to KDE e.V. is always a great idea, as it allows KDE e.V. itself to support an even larger amount and proportion of it.

There seems to be a bit of a doom-and-gloom vibe about accessibility in our community lately, but hopefully it’s clear that not only does KDE care, but it puts its money where its mouth is on this topic! Maybe we’re not 100% there yet, but we’re pointed in the right direction and motivated to continue accelerating towards it.

At Qt, we often say it's not just about building software—it's about building something that matters. And when you talk to people who’ve spent years in the craft, you realize it's also about finding the right tools, the right community, and the freedom to create. In this Qt Journey series, we highlight stories from developers, designers, and engineers around the world who have made Qt part of their professional lives. 

The latest updates to qmlformat, Qt's own tool for formatting of QML files, bring two practical improvements: configurable line breaking and automatic import sorting. These features enhance code readability and maintainability, making them valuable additions worth highlighting.

Plasma's upcoming first-run experience is coming along nicely.

After a bunch of research and discussions we settled on continuing / fixing up the KISS project (KDE Initial System Setup) for the new First Run Experience (FRE) / Out-Of-Box Experience (OOBE). It was in a sort of half finished state.

Since then has been a bunch of work on it such as:

• Getting it to compile and run
• Whole bunch of fixes, cleanup, and polish to the UI, UX, and code/developer experience
• Implemented the ability to actually create the new user (you could enter a name and password, but it was all basically placeholder GUI previously)
• Added language selection front/back ends
• Added basic build / run instructions to the README
• Added ECM logging
• Cleaned up the debug output which made changes more difficult
• Added basic CI (thanks Nico!)
• Added keyboard layout selection front/back ends

That last one was more difficult than expected.. turns out keyboard layouts can be quite complex!

First came some refactoring of the keyboard layouts KCM from plasma-desktop so we could reuse some of the existing, complex functionality. Then adapting a UI/UX appropriate for the FRE. Investigating things like keyboard models, detecting defaults, mapping language to keyboard layout, etc..

Then taking the results of the user choice and figuring out how to apply that both to the system as a default (systemd-localed dbus call) as well as to the running Plasma session (setting the value manually in the kxkbrc keyboard settings file).

As is often the case with software development, that succinct summary belies the massive amount of work it took to get there! 😅 💪

With that work completed, we have most of what is needed for a minimum viable product!

Next up:

• Granting authentication without a user prompt
  • Plan: special user with sysusers.d and a polkit rule
• Running automatically on first boot & in live sessions
  • Plan: systemd unit seems promising, but more research is needed
• Improve documentation
  • Especially related to building & running without kde-builder
• Think about the name
  • I am not thrilled with the KISS acronym personally 🤷‍♀️

There is also obviously a lot of improvements and polish that can be made, but for now here is a preview of the FRE:

These past few week’s my focus was on exploring input device detection and event handling mechanisms in Linux, with a particular emphasis on game controllers and their potential integration into KWin. I also spent time reading through KWin’s input-related source code to understand how it currently manages devices, and began reviewing documentation for various Linux input subsystems—including evdev, HID, and /dev/input/jsX in order to evaluate which layer would provide the most reliable and straight forward support for integrating controller recognition. The time was mostly spent learning how to use different libraries, tools and creating virtual controller prototype.

Tools, Libraries, and Concepts Used

libevdev

libevdev is a library for handling evdev devices. It provides a higher-level interface over /dev/input/event* and abstracts much of the complexity of input event parsing.

evdev is the generic input event interface. This is the preferred interface for userspace to consume user input, and all clients are encouraged to use it.

-The kernel development community.

libevdev can be used to:

• Detect physical game controllers.
• Read input events (e.g., joystick, buttons).
• Create virtual input device and write/forward events to it from physical game controller.

Useful functions:

• libevdev_new(), libevdev_set_fd(int fd, struct libevdev **dev): for opening physical devices.
• libevdev_next_event(struct libevdev *dev, unsigned int flags, struct input_event *ev): for polling events.
• libevdev_get_id_*(const struct libevdev *dev): to query device meta data.

uinput (User Input Subsystem)

I used the Linux uinput subsystem to create a virtual input device that mirrors a physical controller input. uinput is what allows us to make a virtual controller out of any evdev device by:

• Opening a file discriptor for the input device that will be emulate (i.e. have it input event forwarded).
• Forwarding the inputs from a evdev interface device to /dev/uinput (or /dev/input/uinput).
• uinput then creates a new node to expose the virtual device as a evdev interface device in /dev/input/event*

From here the idea is that KWin or any other system component can treat the virtual controller as if it were an ordinary HID device.

uinput is a kernel module that makes it possible to emulate input devices from userspace. By writing to /dev/uinput (or /dev/input/uinput) device, a process can create a virtual input device with specific capabilities. Once this virtual device is created, the process can send events through it, that will be delivered to userspace and in-kernel consumers.

-The kernel development community.

Useful functions:

• libevdev_uinput_create_from_device(const struct libevdev *dev, int uinput_fd, struct libevdev_uinput **uinput_dev):
  For creating a uinput device based on the given libevdev device.
• libevdev_uinput_get_devnode (struct libevdev_uinput *uinput_dev):
  Return the device node representing this uinput device.
• libevdev_uinput_write_event (const struct libevdev_uinput *uinput_dev, unsigned int type, unsigned int code, int value): Post an event through the uinput device.

Tools used:

• libevdev-uinput.h for management of uinput devices via libevdev.
• /dev/uinput opened with correct permissions.
  • Ensuring the current user is in the input group.
  • Verifying that the uinput kernel module is loaded (using modprobe uinput). Some distros (Ubuntu/Kubuntu) have it built in, not loaded as module, thus modprobe uinput command won't log anything.
  • Opening /dev/uinput with O_WRONLY | O_NONBLOCK flags using open(), and ensuring no EPERM or EACCES errors were returned.
  • Optional: Run program as sudo user.

force feedback detection/support

Using ioctl(fd, EVIOCGBIT(EV_FF, ...)) and tools like fftest, I examined:

• How to query a device’s force feedback (FF) capabilities to figure out which effects are supported (e.g., rumble, sine wave).
• How to upload ff effects to physical game controller and test rumble motors.
  • This was key to understanding haptic capability support on physical devices.

To enable force feedback, you have to:

have your kernel configured with evdev and a driver that supports your device.

make sure evdev module is loaded and /dev/input/event* device files are created.

Testing & Validation

• Used evtest and fftestto test evdev devices and understand their capabilities - sudo evtest /dev/input/eventX.
• Used those same tools to test virtual devices creating using uinput -
  sudo fftest dev/input/eventX. uinput creates a node device in dev/input/eventX for the virtual input.
• Prototype logs validate that a virtual device can be created and events can properly be written to a that virtual device using libevdev.

Takeaways

• Using libevdev and libevdev-uinput we can access physical controllers, create virtual controller and read/write low-level input events.
• Understanding of the permission requirements to open /dev/input/* and /dev/uinput (use udev rules or run as root).
• Tools to test:
  • evtest and fftest (from input-utils)
  • udevadm info --name=/dev/input/eventX --attribute-walk
    • Shows the device hierarchy - how the device is connected to PC and any parent device it connects to.
• Built a minimal proof-of-concept C++ program that routes an evdev devices input 1:1 to a virtual controller (via uinput).
• Not all controllers support all force feedback types; some failed with EINVAL during upload.
• libevdev does not handle FF upload directly — this remains kernel-level and typically involves ioctl().

References and Documentation

• Linux Input Subsystem Documentation (kernel-level overview of evdev, HID, uinput, etc.)
• evdev interface documentation (from the kernel source)
• uinput: User-level input device emulation
• Force Feedback programming on Linux (FF effect types and ioctl usage)
• libevdev (Userspace abstraction for evdev devices)

This is a recipe post. For an event I needed to make brownies for 100 people, so this time I decided to write down what I was doing, so that they would be sort-of-consistent. I even weighed things.

Melt (e.g. in the microwave):

• 200g pure chocolate (Jumbo store brand is acceptable in the Netherlands)
• 130g margarine (Blue Band)

Stir in:

• 150g sugar (e.g. brown basterd sugar for extra flavor)
• pinch of salt (this is one I often forget)

Mix in:

• 4 eggs (one by one, and use an electric mixer; run it long, so that the batter becomes glossy)
• 70g cocoa powder
• 60g flour

In the oven at 180℃ for 35 minutes or so. Optionally, add pecans.

This recipe is based on my interpretation of “Jamie Oliver Brownies”, which are all over the net – the original version is kind of picky, and what I do here works repeatedly in my kitchen.