Skip to content

Welcome to Planet KDE

This is a feed aggregator that collects what the contributors to the KDE community are writing on their respective blogs, in different languages

Friday, 16 January 2026

Let’s go for my web review for the week 2026-03.


European Commission issues call for evidence on open source

Tags: tech, foss, politics, europe

Go and get your voice heard! This is important matter, especially if you’re interested in Free Software.

https://lwn.net/Articles/1053107/


US tech giants allying with European far-right to strip back EU rules

Tags: tech, gafam, business, politics, europe

They’ll do anything to further their grip on tech. The European Union is sleep walking on this one.

https://www.brusselstimes.com/belgium/1916422/us-tech-giants-allying-with-european-far-right-to-strip-back-eu-rules


So, You’ve Hit an Age Gate. What Now?

Tags: tech, politics, law, surveillance, privacy

Clearly the regulators don’t really understand the level of intrusiveness they’re unleashing with mandating age gates. This is one more layer of surveillance for large parts of the population.

https://www.eff.org/deeplinks/2026/01/so-youve-hit-age-gate-what-now


The Next Thing Will Not Be Big

Tags: tech, innovation, foss, business, community

This is a very rich article. There’s indeed more and more a rift between Open Source projects used by hyperscalers and the ones used by smaller businesses and individuals. You likely want to aim for the latter.

https://blog.glyph.im/2026/01/the-next-thing-will-not-be-big.html


Four More Tech Bloggers Are Switching to Linux

Tags: tech, linux, foss, desktop

Looks like the trend continues. Let’s hope the Linux desktop user base will keep growing this year.

https://m.slashdot.org/story/451196


How Markdown took over the world

Tags: tech, markdown, history, blog, commons

Wondering where Markdown is coming from and how it became such a success? The piece helps answer those questions.

https://www.anildash.com/2026/01/09/how-markdown-took-over-the-world/


Mailing lists vs Discourse forums: open source communities or commodities?

Tags: tech, foss, community, email

Interesting points. Forums are clearly not good replacements for mailing lists. They might be a good complementary to mailing lists but both have very different affordances.

https://danielpocock.com/en/mailing-lists-vs-discourse-forums-open-source-community-or-commodity/


WhatsApp is untrustable

Tags: tech, messaging, foss, security, privacy, foss

If you needed a reminder about why you can’t trust WhatsApp, this is a good explanation.

https://toki.la/posts/whatsapp


I’m The Captain Now: Hijacking a global ocean supply chain network

Tags: tech, security, api, secrets

Friendly reminder that securing APIs and secrets is a must. Not doing so can have really bad consequences.

https://eaton-works.com/2026/01/14/bluspark-bluvoyix-hack/


New Social Web Working Group at W3C

Tags: tech, web, standard, fediverse, social-media

This is a welcome development at the W3C. Let’s hope this working group will bring good things and stewardship for the related standards.

https://socialwebfoundation.org/2026/01/15/new-social-web-working-group-at-w3c/


HTTP RateLimit headers

Tags: tech, http, failure, standard

Maybe we can expect improvements in how HTTP rate limiting is handled?

https://dotat.at/@/2026-01-13-http-ratelimit.html


Why We Don’t Use AI

Tags: tech, ai, machine-learning, gpt, copilot, ethics

I agree with this so much. It’s another one of those I feel I could have written. I have a hard time thinking I could use the current crop of “inference as a service” while they carry so many ethical issues.

https://yarnspinner.dev/blog/why-we-dont-use-ai/


AI Coding Degrades: Silent Failures Emerge

Tags: tech, ai, machine-learning, copilot, quality, ethics

There is a real question about the training data used for the coding assistant models. It’s been a problem from the start raising ethical concerns, now it shows up with a different symptom.

https://spectrum.ieee.org/ai-coding-degrades


On FLOSS and training LLMs

Tags: tech, ai, machine-learning, gpt, copilot, foss, law, ethics, copyright

I’m not sure the legal case is completely lost even though chances are slim. The arguments here are worth mulling over though. There’s really an ethical factor to consider.

https://chronicles.mad-scientist.club/tales/on-floss-and-training-llms/


Be Wary of Digital Deskilling

Tags: tech, ai, machine-learning, copilot, business, economics, work, quality

Is this really to improve your work? Or make you dependent? In the end it might be the users who loose.

https://calnewport.com/be-wary-of-digital-deskilling/


The coolest feature in Python 3.14

Tags: tech, python, debugging, containers

OK, this is definitely a very cool hack. It can definitely help to debug locally.

https://savannah.dev/posts/the-coolest-feature-in-314/


How to parametrize exception testing in PyTest?

Tags: tech, python, tests, exceptions

Neat little Python trick for testing exceptions.

https://borutzki.github.io/2026/01/15/how-to-parametrize-exception-testing-in-pytest.html


Handling secrets (somewhat) securely in shells

Tags: tech, security, secrets, shell

What’s the right way to manipulate secrets in your shell to avoid leakage? The answer definitely varies, here is the paranoid version.

https://linus.schreibt.jetzt/posts/shell-secrets.html


How Safe is the Rust Ecosystem? A Deep Dive into crates.io

Tags: tech, rust, supply-chain, security

There are growing concerns regarding the Rust supply chain. It’s still time to address them but it’s became important to tackle this area.

https://mr-leshiy-blog.web.app/blog/crates_io_analysis/


Volumetric Cloud Rendering

Tags: tech, graphics, 3d, shader, physics

Long and good walkthrough on how to render nice clouds in real time.

https://www.jacktollenaar.top/articles/clouds.html


permission to begin learning

Tags: tech, programming, language, learning, craftsmanship

There’s a lot to this. Learning different languages to get out of your habits definitely brings compound benefits.

https://ficd.sh/blog/permission-to-begin-learning/


The PERFECT Code Review: How to Reduce Cognitive Load While Improving Quality

Tags: tech, codereview

This is an interesting way to frame where the effort should be spent in code reviews.

https://bastrich.tech/perfect-code-review/


One bottleneck at a time

Tags: tech, engineering, management, productivity, kanban

This is good advice. To improve your organisation, focus only on the biggest constraint. Otherwise you’ll quickly be spread thin.

https://www.theengineeringmanager.com/growth/one-bottleneck-at-a-time/


Toyota Culture 20 Years Later: Why Jeffrey Liker’s Lessons Still Matter

Tags: management, agile, lean, culture, trust, leadership, problem-solving

This has been documented for a long while. Of course, it’s been followed by an unhealthy fascination for the “Toyota way”. This kind of cargo cult of course lead you nowhere to doing things properly. And yet, now that the dust settled, there are good lessons to learn from Toyota management back then.

https://www.leanblog.org/2026/01/toyota-culture-jeffrey-liker-20-years-later/



Bye for now!

Thursday, 15 January 2026

Happy New Year! The first maintenance release of the 25.12 series is with the usual batch of stability fixes and workflow improvements. Highlights of this release include further polishing of the new welcome screen, added AMF encoding profile for Windows, fixes to audio capture and effects alongside numerous smaller improvements throughout the interface. See changelog for more details.

For the full changelog continue reading on kdenlive.org.

Wednesday, 14 January 2026

This post describes an experiment using Qt 6.7’s REST APIs to explore Stripe’s payment model, and what I learned building a small desktop developer tool.

Recent Qt releases have included several conveniences for developing clients of remote REST APIs. I recently tried it out with the Stripe payments REST API to get to grips with the Qt REST API in the real world. The overloading of the term API is unhelpful, I find, but hopefully not too confusing here.

As with almost everything I try out, I created Qt desktop tooling as a developer aid to exploring the Stripe API and its behavior. Naming things is hard, but given that I want to put a “Q” in the name, googling “cute stripes” gives lots of hits about fashion, and the other too-obvious-to-say pun, I’ve pushed it to GitHub as “Qashmere“:

Image

setAlternatingRowColors(true);

Developers using REST APIs will generally be familiar with existing tooling such as Postman and Bruno, for synthesizing calls to collections of REST APIs. Indeed, Qashmere uses the Stripe Postman JSON definition to present the collection of APIs and parameters. Such tools have scripting interfaces and state to create workflows that a client of the REST API needs to support, like “create a payment, get the id of the payment back from the REST API and then cancel the payment with the id”, or “create a payment, get the id of the payment back from the REST API and then confirm it by id with a given credit card”.

So why create Qashmere? In addition to REST APIs, Stripe maintains objects which change state over time. The objects remain at REST until acted on by an external force, and when such an action happens a notification is sent to clients about those state changes, giving them a chance to react. I wanted to be able to collect the REST requests/responses and the notified events and present them as they relate to the Stripe objects. Postman doesn’t know about events or about Stripe objects in particular, except that it is possible to write a script in Postman to extract the object which is part of a JSON payload. Postman also doesn’t know that if a Payment Intent is created, there are a subset of next steps which could be in a workflow, such as cancel, capture or confirm payment etc.

Something that I discovered in the course of trying this out is that when I confirm a Payment Intent, a new Charge object is created and sent to me with the event notification system. Experimental experiences like that help build intuition.

Image

Stripe operates with real money, but it also provides for sandboxes where synthetic payments, customers etc can be created and processed with synthetic payment methods and cards. As Qashmere is only useful as a developer tool or learning aid, it only works with Stripe sandboxes.

Events from Stripe are sent to pre-configured web servers owned by the client. The web servers need to have a public IP address, which is obviously not appropriate for a desktop application. A WebSocket API would be more suitable and indeed the stripe cli tool uses a WebSocket to receive events, but the WebSocket protocol is not documented or stable. Luckily the stripe cli tool can be used to relay events to another HTTP server, so Qashmere runs a QHttpServer for that purpose.

Image

Implementation with Qt REST API

The QRestReply wraps a QNetworkReply pointer and provides convenience API for accessing the HTTP return code and for creating a QJsonDocument from the body of the response. It must be created manually if using QNetworkAccessManager directly. However the new QRestAccessManager wraps a QNetworkAccessManager pointer, again to provide convenience APIs and overloads for making requests that are needed in REST APIs (though some less common verbs like OPTIONS and TRACE are not built-in). The QRestAccessManager has conveniences like overloads that provide a way to supply callbacks which already take the QRestReply wrapper object as a parameter. If using a QJsonDocument request overload, the “application/jsonContent-Type is automatically set in the header.

One of the inconveniences of QRestAccessManager is that in Qashmere I use an external definition of the REST API from the Postman definition which includes the HTTP method. Because the QRestAccessManager provides strongly typed API for making requests I need to do something like:

if (method == "POST") {
rest.post(request, requestData, this, replyHandler);
} else if (method == "GET") {
rest.get(request, this, replyHandler);
} else if (method == "DELETE") {
rest.deleteResource(request, this, replyHandler);
}

There is a sendCustomRequest class API which can be used with a string, but it does not have an overload for QJsonDocument, so the convenience of having the Content-Type header set is lost. This may be an oversight in the QRestAccessManager API.

Another missing feature is URL parameter interpolation. Many REST APIs are described as something like /v1/object/:object_id/cancel, and it would be convenient to have a safe way to interpolate the parameters into the URL, such as:

QUrl result = QRestAccessManager::interpolatePathParameters(
"/v1/accounts/:account_id/object/:object_id/cancel", {
{"account_id", "acc_1234"},
{"object_id", "obj_5678"}
}
);

This is needed to avoid bugs such as a user-supplied parameter containing a slash for example.

Coding Con Currency

In recent years I’ve been writing and reading more Typescript/Angular code which consumes REST services, and less C++. I’ve enjoyed the way Promises work in that environment, allowing sequences of REST requests, for example, to be easy to write and read. A test of a pseudo API could await on requests to complete and invoke the next one with something like:

requestFactory.setBaseURL("http://some_service.com");
async testWorkflow(username: string, password: string) {
const loginRequest = requestFactory.makeRequest("/login");
const loginRequestData = new Map();
loginRequestData.setParam("username", username);
loginRequestData.setParam("password", password);
const loginResponse = await requestAPI.post(
loginRequest, loginRequestData);
const bearerToken = loginResponse.getData();
requestAPI.setBearerToken(bearerToken);
const listingRequest = requestFactory.makeRequest("/list_items");
const listingResponse = await requestAPI.get(listingRequest);
const listing = JSON.parse(listingResponse.getData());
const firstItemRequest = requestFactory.makeRequest(
"/retrieve_item/:item_id",
{
item_id: listing[0].item_id
}
);
const firstItem = await requestAPI.get(firstItemRequest);
}

The availability of async functions and the Promise to await on make a test like this quite easy to write, and the in-application use of the API uses the same Promises, so there is little friction between application code and test code.

I wanted to see if I can recreate something like that based on the Qt networking APIs. I briefly tried using C++20 coroutines because they would allow a style closer to async/await, but the integration friction with existing Qt types was higher than I wanted for an experiment.

Using the methods in QtFuture however, we already have a way to create objects representing the response from a REST API. The result is similar to the Typescript example, but with different ergonomics, using .then instead of the async and await keywords.

struct RestRequest
{
QString method;
QString requestUrl;
QHttpHeaders headers;
QHash<QString, QString> urlParams;
QUrlQuery queryParams;
std::variant<QUrlQuery, QJsonDocument> requestData;
};
struct RestResponse
{
QJsonDocument jsonDoc;
QHttpHeaders headers;
QNetworkReply::NetworkError error;
QUrl url;
int statusCode;
};
QFuture<RestResponse> makeRequest(RestRequest restRequest)
{
auto url = interpolatePathParameters(
restRequest.requestUrl,
restRequest.urlParams);
auto request = requestFactory.createRequest(url);
auto requestBodyDoc = extractRequestContent(restRequest.requestData);
auto requestBody = requestBodyDoc.toJson(QJsonDocument::Compact);
auto reply = qRestManager.sendCustomRequest(request,
restRequest.method.toUtf8(),
requestBody,
&qnam,
[](QRestReply &) {});
return QtFuture::connect(reply, &QNetworkReply::finished).then(
[reply]() {
QRestReply restReply(reply);
auto responseDoc = restReply.readJson();
if (!responseDoc) {
throw std::runtime_error("Failed to read response");
}
RestResponse response;
response.jsonDoc = *responseDoc;
response.statusCode = restReply.httpStatus();
response.error = restReply.error();
response.headers = reply->headers();
response.url = reply->url();
return response;
}
);
}

The QRestAccessManager API requires the creation of a dummy response function when creating a custom request because it is not really designed to be used this way. The result is an API accepting a request and returning a QFuture with the QJsonDocument content. While it is possible for a REST endpoint to return something else, we can follow the Qt philosophy of making the most expected case as easy as possible, while leaving most of the rest possible another way. This utility makes writing unit tests relatively straightforward too:

RemoteAPI remoteApi;
remoteApi.setBaseUrl(QUrl("https://dog.ceo"));
auto responseFuture = remoteApi.makeRequest(
{"GET",
"api/breed/:breed/:sub_breed/images/random",
{},
{
{"breed", "wolfhound"},
{"sub_breed", "irish"}
}});
QFutureWatcher<RestResponse> watcher;
QSignalSpy spy(&watcher, &QFutureWatcherBase::finished);
watcher.setFuture(responseFuture);
QVERIFY(spy.wait(10000));
auto jsonObject = responseFuture.result().jsonDoc.object();
QCOMPARE(jsonObject["status"], "success");
QRegularExpression regex(
R"(https://images\.dog\.ceo/breeds/wolfhound-irish/[^.]+.jpg)");
QVERIFY(regex.match(jsonObject["message"].toString()).hasMatch());

The result is quite similar to the Typescript above, but only because we can use spy.wait. In application code, we still need to use .then with a callback, but we can additionally use .onFailed and .onCanceled instead of making multiple signal/slot connections.

With the addition of QtFuture::whenAll, it is easy to make multiple REST requests at once and react when they are all finished, so perhaps something else has been gained too, compared to a signal/slot model:

RemoteAPI remoteApi;
remoteApi.setBaseUrl(QUrl("https://dog.ceo"));
auto responseFuture = remoteApi.requestMultiple({
{
"GET",
"api/breeds/list/all",
},
{"GET",
"api/breed/:breed/:sub_breed/images/random",
{},
{{"breed", "german"}, {"sub_breed", "shepherd"}}},
{"GET",
"api/breed/:breed/:sub_breed/images/random/:num_results",
{},
{{"breed", "wolfhound"},
{"sub_breed", "irish"},
{"num_results", "3"}}},
{"GET", "api/breed/:breed/list", {}, {{"breed", "hound"}}},
});
QFutureWatcher<QList<RestResponse>> watcher;
QSignalSpy spy(&watcher, &QFutureWatcherBase::finished);
watcher.setFuture(responseFuture);
QVERIFY(spy.wait(10000));
auto four_responses = responseFuture.result();
QCOMPARE(four_responses.size(), 4);
QCOMPARE(four_responses[0].jsonDoc.object()["status"], "success");
QVERIFY(four_responses[0].jsonDoc.object()["message"].
toObject()["greyhound"].isArray());
QRegularExpression germanShepherdRegex(
R"(https://images.dog.ceo/breeds/german-shepherd/[^.]+.jpg)");
QCOMPARE(four_responses[1].jsonDoc.object()["status"], "success");
QVERIFY(germanShepherdRegex.match(
four_responses[1].jsonDoc.object()["message"].toString()).hasMatch());
QRegularExpression irishWolfhoundRegex(
R"(https://images.dog.ceo/breeds/wolfhound-irish/[^.]+.jpg)");
QCOMPARE(four_responses[2].jsonDoc.object()["status"], "success");
auto irishWolfhoundList =
four_responses[2].jsonDoc.object()["message"].toArray();
QCOMPARE(irishWolfhoundList.size(), 3);
QVERIFY(irishWolfhoundRegex.match(irishWolfhoundList[0].toString()).
hasMatch());
QVERIFY(irishWolfhoundRegex.match(irishWolfhoundList[1].toString()).
hasMatch());
QVERIFY(irishWolfhoundRegex.match(irishWolfhoundList[2].toString()).
hasMatch());
QCOMPARE(four_responses[3].jsonDoc.object()["status"], "success");
auto houndList = four_responses[3].jsonDoc.object()["message"].toArray();
QCOMPARE_GE(houndList.size(), 7);
QVERIFY(houndList.contains("afghan"));
QVERIFY(houndList.contains("basset"));
QVERIFY(houndList.contains("blood"));
QVERIFY(houndList.contains("english"));
QVERIFY(houndList.contains("ibizan"));
QVERIFY(houndList.contains("plott"));
QVERIFY(houndList.contains("walker"));

setAutoDeleteReplies(false);

I attempted to use new API additions in recent Qt 6 versions to interact with a few real-world REST services. The additions are valuable, but it seems that there are a few places where improvements might be possible. My attempt to make the API feel closer to what developers in other environments might be accustomed to had some success, but I’m not sure QFuture is really intended to be used this way.
Do readers have any feedback? Would using QCoro improve the coroutine experience? Is it very unusual to create an application with QWidgets instead of QML these days? Should I have used PyQt and the python networking APIs?







Haruna version 1.7.1 is released.

playlist advanced sorting and grouping showcase
playlist advanced sorting and grouping

flathub logo

Windows version:

Availability of other package formats depends on your distro and the people who package Haruna.

If you like Haruna then support its development: GitHub Sponsors | Liberapay | PayPal

Feature requests and bugs should be posted on bugs.kde.org, ignoring the bug report template can result in your report being ignored.


Known issues

The animation for the playlist can be stuttery/slow when playback is active. You can improve it by creating two custom commands that run on startup set override-display-fps 75 (replace 75 with your monitor's refresh rate) and set video-sync display-resample.

These don't work for variable refresh rate monitors.

Changelog

1.7.1

Bugfixes

  • fixed searching playlist
  • fixed tooltip background being same color as its text

1.7.0

Features

Playlist

  • added advanced sorting and grouping (Muhammet Sadık Uğursoy)
  • added context menu to open file in Hana (thumbnail generator, only if it's installed). Get it from flathub
  • the last active playlist will be set as visible when starting the app

Other

  • added replay gain settings (Muhammet Sadık Uğursoy)
  • mpris thumbnail is only set for audio files, this allows the os taskbar preview to show the actual live window
  • decreased the size of the play icon in the compact playlist

Bugfixes

  • fixed database folder not being created
  • fixed seekbar tooltip not updating when file changes and the mouse is not moved
  • fixed deleting custom commands
  • fixed saving last opened url

Tuesday, 13 January 2026

This is the release schedule the release team agreed on

  https://community.kde.org/Schedules/KDE_Gear_26.04_Schedule

Dependency freeze is in around 7 weeks (March 5) and feature freeze one 
after that. Get your stuff ready!

For other-$WORK I am doing a bit of Debian packaging (prep-work) and upstream wrangling to bring some projects into a more-modern world. So now I have a Debian 13 workstation and need to build things for Debian Unstable without breaking my host system. On FreeBSD, this is a job for Poudriere. Here’s my notes on how I do something half-assedly similar on Debian (as usual, mostly documentation for “future me”).

As an example of something I’m updating, libaccounts is one. KDE is moving away from it, but there are other consumers.

The “Poudriere-alike” for Debian seems to be SBuild, and the instructions are quite extensive. For my rinky-dink use, though, the setup section is mostly-enough.

Start with a plain Debian 13 (Trixie) installation. I have one with KDE Plasma 6 Wayland on it, which is quite nice.

Creating a Tarball

These commands verbatim from the SBuild instructions, as my own local user:

sudo apt install sbuild mmdebstrap uidmap
mkdir -p ~/.cache/sbuild
mmdebstrap \
  --include=ca-certificates,cmake,git,gnupg,libqt6widgets6,libqt5widgets5 \
  --skip=output/dev \
  --variant=buildd \
  unstable \
  ~/.cache/sbuild/unstable-amd64.tar.zst \
  https://deb.debian.org/debian

This creates a tarball. The tarball includes whatever you tell it to install additionally – so I have a couple of typical-Qt-developer things listed.

This list isn’t nearly complete for anything like “Qt5 and Qt6 parallel-development”, because it is missing -dev packages and qmake and many other things. Debian packaging naming is an exercise in inconsistency, IMO, so it is always an adventure to figure out what I need.

The steps above are sort-of like creating a “base jail” in Poudriere. The tarball is a basic Debian Unstable that can be unpacked anywhere (creating a “jail”) and then used for whatever development work is needed. Unlike a jail, the unpacked tarball is just a chroot(1), so it doesn’t have special networking or other restrictions.

The chroot, once unpacked, is persistent. That means that stuff that is installed in it remains there and is available later. I don’t need to care about disk space, so it’s fine to litter my filesystem with multiple chroots, one for each project.

Extracting Tarball

Create a place for the chroot of a project, and extract the tarball there:

mkdir -p ~/src/chroot-libaccounts
sudo tar x --zstd -f ~/.cache/sbuild/unstable-amd64.tar.zst -C ~/src/chroot-libaccounts

GNU tar doesn’t have the advanced features of BSD tar which automatically understands the compression, so it needs to be specified by hand.

To enter the chroot, use sudo chroot ~/src/chroot-libaccounts. Since it’s persistent, it is probably worthwhile to update and upgrade it and maybe install additional packages, or whatever else one does with a Debian system.

Using a chroot with external sources

Inside the chroot is where builds happen. Outside the chroot is where the source lives, so I need to mount the source directory of whatever I’m working on, in the chroot. I do so before entering the chroot.

sudo mkdir ~/src/chroot-libaccounts/home/src
sudo mount --bind ~/src/libaccounts-qt/ ~/src/chroot-libaccounts/home/src
sudo chroot ~/src/chroot-libaccounts

Why not Docker?

Now that I’ve written this down in this detail, I realize that a suitable Docker image and container might have been what I was looking for. Well, almost: persistence is a thing. It’s a feature of Docker that the container re-starts in a pristine state every time. It’s an anti-feature for what I’m doing here. There’s ways of dealing with that, and I do so at $WORK. But not for this project.

Just a teaser this time.

I’ve read somewhere that Fedora will be the first distribution to replace SDDM with Dave’s brand new Plasma Login Manager.

Will Ni! OS be the first non-distribution to do the same?

And if it does, will it become a distribution as it distributes yet another package not available in vanilla NixOS? :)

Plasma Login Manager on Ni! OS
Plasma Login Manager on Ni! OS

Tuesday, 13 January 2026. Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.5.5.

Plasma 6.5 was released in October 2025 with many feature refinements and new modules to complete the desktop experience.

This release adds a month’s worth of new translations and fixes from KDE’s contributors. The bugfixes are typically small but important and include:

View full changelog

Here are the new modules available in the Plasma 6.6 beta:

  • plasma-login-manager
  • plasma-keyboard
  • plasma-setup

Some important features and changes included in 6.6 beta are highlighted on KDE community wiki page.

View full changelog

Monday, 12 January 2026

I have a paper calendar. It hangs on the wall. I draw things on it, like 🎜 Kladderadatch, to remind me where to go of an evening (or this afternoon). At the end of the year, with that calendar and my ticket history from Doornroosje (a music podium in Nijmegen) I can reconstruct my concert visits of the year. Here’s my year wrapped.

  • Roos Rebergen & SunSun Orchestra Roos is always really peculiar, and did not fail to deliver. The classical string quintet as band worked well. It’s quite different from her pop recordings. I saw Roos in 2006 or so when she played in a local school, and it’s always stayed with me.
  • Politie Warnsveld + Misprint POPO! It’s like Doe Maar has reincarnated. Happy ska, although now they have a bigger setlist it is a little less wild. This was also a sad concert because of the death of a concert-friend – she was a big POPO fan – in an accident a few months earlier.
  • De Kift “Ik heb rood haar, en lees wel eens gedichten” It’s a punk-jazz-improv group. Live they’re weird, but I did miss listening to the actual words.
  • Parker Millsap Blues country, now as a solo show instead of with a band.
  • Stippenlift Dutch-language electro-pop about his depression.
  • ELUCID Rap, old-school.
  • Dorpsstraat 3 Dutch indie.
  • The Vices I’m pretty sure that during this concert I ended up thinking about the font-kerning in their logo, more than the music. Meh.
  • Rats on Rafts I have no real recollection, it might have been boring.
  • Ghost Funk Orchestra Jazz. If you asked me beforehand about a trombone solo, I would have said “probably boring”. Afterwards, fuck yeah! Trombone solo! They were amazing on stage.
  • Girls to the Front A triple show with L.A. Sagne, Death Sells and C’est Qui? I’ve seen Death Sells a couple times after, they’re fun and personable.
  • De Roos van Nijmegen is a yearly battle-of-the-bands, and I go with the kids, and we Have Opinions about things. It’s spread across 3 nights and the finals. I voted for PORTRAY. I thought Grandad was pretty good in the first round, and boring in the finals. The peeps from Pomme Grenade are the ones I run into around town most often. Liz Beekman was, as singer-songwriter, the odd-one-out in the first round, but I quite liked both her music and relaxed podium presence.
  • The Ex + Brader Mûsikî More punk-jazz. Brader was a totally new Kurdish-language experience for me. The Ex was weird and experimental and the broad grin on the drummer’s face as she puts in more cowbell in The Apartment was magical.
  • Tramhaus had a lot of social message that I agree with, but not amazing.
  • Place to Bury Strangers I saw them in “old” Doornroosje, with my friend Armijn who described them as “ear-bleedingly loud”. Regulations prevent that now, but they were great and the round-through-the-crowd is a lot of fun to be part of.
  • Elephant is a big-ish name and had a lot of radio play, so that’s why got tickets. I have no real recollection, it might have been boring.
  • KNIVES Absolutely wild live-show, amazing energy. I told them I thought they were “amazeballs” after the show, they called me “old”. Love you too! I was here also because of Death Sells opening.
  • Crash Fest Organized by Outahead – an indie band that don’t do it for me – but I went because Lodyne and Death Sells were playing and I’m into naked bass players.
  • Alice Faye The first of a week of singers-songwriters. I don’t remember anything particular, but I do know I liked it for being a relaxed night out instead of sweaty and loud.
  • Tara Nome Doyle Second one of singers-songwriters. I remember her being very chatty and open about the songwriting process and what things were about. That’s one of the nice things in a really small venue, the artists are there and all themselves.
  • Stereolab The crowd was all fans, who could sing along with every song. I could tell they were having a ball, but it did not land at all for me.
  • Heather Nova in the park, in the rain, with a rainbow, with ducks waddling across the stage, and a spider that dropped onto her hand during Like a Hurricane. As a consummate performer, she put the spider away and picked up the chorus again.
  • The Hard Quartet This is a supergroup, I guess you could call it. I saw Pavement back in the day, and when Stephen is at the mike, it’s like a Pavement song. And when someone else takes over, it’s a different band. This was good to see for being a bunch of really experienced and work-well-together musicians.
  • Bassolino Italian funk. It was funky, but the funk did not reach my hips. I’m way too much a white boy for that – put me in a mosh pit instead.
  • Magic Bullet I have no recollections of again. It was possibly boring.
  • Rosalie Cunningham I did not expect a ’70s hardrock revival on stage. It was amazing. She has wonderful eyes. Roscoe can sing that one song pretty good. And it was a party for all.
  • Dick Move More punk bands should sell hot pink T-shirts. This was a blast.
  • Preoccupations I figured “band from Calgary”. There was a Flames T-shirt on-stage. They did their thing. They left. Very little interaction with the audience.
  • Misprint They were with POPO earlier this year, and I kept bumping into their bass player at other concerts, so it was the least I could do get tickets for their own show. Kind of middle-of-the-road, good enough.
  • Early James Blues from Alabama. He did a nice closing number with his girlfriend, it worked pretty well as a duet.
  • Gill Landry Blues from Louisiana. This was very personal, and you can tell Gill was a street performer before moving on to the stage. One to re-visit if he comes back.
  • Joachim Cooder Son-of-Ry, playing an electric thumb piano. This was very much not what I expected. It was interesting, and I told him “peculiar” after the show, but I’m afraid it did not get my feet a-tappin’.
  • Frazey Ford Was she drunk? It took forever before the show gelled a little, but it never really moved.
  • Leith Singer-songwriter. Blue eyes that stare right through your soul. I really enjoyed this show, and the openers, Robinson Kirby, were fun as well.
  • DITZ Fucking well tore the house down. Her with the boots has an amazing command of the audience, the pit was wild, the communion weird and disconcerting. KNIVES opened here, but did not get nearly the same response as earlier in the year (in a different venue, must be said).
  • zZz These guys I saw when they – and I – had no grey hairs and I remember them jumping up and down on the organ and it was loud and chaotic. They still are, although with a bad back climbing on stuff is no longer an option.
  • Vals Alarm Punk with too much backing track. Gotta hand it to them, though, with your parents in the audience belting out “I wanna fuck some new boys / I need a new dick / new dick” takes some courage.
  • De Niemanders This is a collective that brings singers from refugee centers in the Netherlands to the stage. With a gospel couple, and a good backing band, we can see what talent we’re squandering. I don’t know the names of the individual performers though. Ahm has amazing sustain. Habibi from Yemen, I think, is such a cute boy with an excellent delivery.
  • Black Bottle Riot Does a end-of-year show every year in Nijmegen. Packed house, almost all fans. Random people come up to talk with you. Sabine from Zeeland, it was good to meet you. This show was almost three hours, and one big party. It’s good to have something to plan again in 360 days or so.

Not in Nijmegen:

  • Black Country New Road In Paradiso, Amsterdam. I’m clearly spoiled by easy-going Nijmegen, because I thought the venue was annoying. And every song was .. not quite it. Nothing landed, and the feels-like-American-film-music makes me unhappy. Where there was a neat idea (five recorders? sure, woodwind quintet) it was executed in a too-limited way. Bit of a disappointment, but the openers, Westside Cowboy, were fun.
  • West Side Story in Rome. Man, the story is paper-thin, even if the singers were excellent. The only fun I had here was realizing that “having problems with the PRs” is not a GitHub thing.
  • Opera school in Arezzo. There’s an opera school, students come from the United States to learn to sing an Italian opera, and execute it in the square. Stories still paper-thin, but such is operetta as an art form. I learned that “learn to sing” means “make the right sounds”, because the students could not actually speak Italian.

Ones I missed (but did have tickets):

  • Spinvis I was doing drywall and at 10pm remembered I had tickets to a one-off special show in Kleve. I had bought them a couple of days previous and hadn’t written it down.
  • Felipe Baldomir Singer-songwriter week, but I was sick.
  • Hackensaw Boys Bluegrass, but I was sick.

That’s 46 concerts this year. I do try to see something every week. In principle I don’t listen to stuff in advance, I just go and find out what it is once the band starts. I have a strong preference for Merleyn, the smallest of the Doornroosje venues, because everything is close-by and personal. The beer is better there, also. Punk has the best odds of making me happy on an evening, but I’m glad I go to random other stuff to broaden my horizons. I have punk, jazz, ska and rap lined up for the next three months, and also Green Milk from the Planet Orange, whatever genre that is.