Lisp on ervin

Web Review, Week 2026-40

ervin@ipsquad.net (Kevin Ottens) — Fri, 02 Oct 2026 11:23:51 +0000

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

NVIDIA’s Greenwashing Tactics & Hidden Emissions

Tags: tech, nvidia, hardware, economics, ecology

Are we surprised? Unfortunately not, they almost increased their indirect emissions 8 folds in a few years. And it could get worse still.

https://www.aigreenwashing.org/news/new-ai-report-reveals-nvidias-greenwashing-tactics-and-hidden-emissions/

AI’s Unsustainable impacts to grow x7 by 2030

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

There’s clearly a major issue in terms of environmental impacts with the AI industrial complex. Yes it’s also about electricity consumption but not only. We have at last a comprehensive study on the matter. Without major changes it’s just unsustainable and something we can’t collectively afford.

https://www.greenit.fr/2026/09/30/ais-unsustainable-impacts-to-grow-x7-by-2030/

Micron CEO Says Memory Supply Will Be Much Tighter in 2027 and 2028 Than in 2026

Tags: tech, ai, machine-learning, gpt, hardware, memory, business, economics

Looks like the mess on hardware prices will continue for a while…

https://www.techpowerup.com/353296/micron-ceo-says-memory-supply-will-be-much-tighter-in-2027-and-2028-than-in-2026

The AI Pascal’s Wager

Tags: tech, ai, machine-learning, gpt, copilot, foss, community

It makes sense to me, it’s better to not fall prey to the marketing induced FOMO. Instead projects have a chance to do the right thing.

https://ploum.net/2026-10-01-pascal_wager.html

If we do not stop to help each other, what do we become?

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

Aren’t we loosing sense of community and our humanity indeed?

https://blog.codinghorror.com/if-we-do-not-stop-to-help-each-other-what-do-we-become/

The opposite of the apocalypse is a neighborhood

Tags: tech, ai, machine-learning, gpt, copilot, community, politics

Kind of an unusual read. But I think the message is powerful. We should definitely favor community over tools controlled by the new robber barons.

https://thewhitepages.net/p/the-opposite-of-the-apocalypse-is

One month without AI

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

The slippery slop seems clear… If you start generating a bit you’ll be pushed to loose full control in the end. Do you think you can learn this way? Improve? I doubt it.

https://blog.bustikiller.com/2026/09/25/one-month-without-ai.html

Tags: tech, automotive, privacy

The automakers still don’t care about privacy apparently…

https://arstechnica.com/cars/2026/09/connected-car-data-privacy-is-still-abysmal-study-finds/

File Notification Attacks

Tags: tech, security

Interesting new family of side channel attacks. Surprising it lingered for so long before being noticed.

https://inoti.fyi/

Don’t couple your Go code to GitHub

Tags: tech, go, supply-chain, vendor-lockin

This is clearly something which bugs me about the Go ecosystem. It’s way too coupled to a single Git provider. The approach to dependency management is neat otherwise but more care should be taken about avoiding this GitHub lock in.

https://iain.rocks/blog/dont-couple-your-go-code-to-github

Taking Out The Garbage In Postgres

Tags: tech, postgresql, databases, performance

Interesting issues around cascading deletes in Postgres and how the indices are managed.

https://www.dbos.dev/blog/scaling-deletions-in-postgres

DTAP - Text and Test Anything Protocol

Tags: tech, tests, infrastructure, shell

Looks like an interesting tool for black box testing. Seems especially suited for full system tests.

https://dtap.sparrowhub.io/doc/README

Reducing C++ template bloat by factoring out the type-dependent portions of the function

Tags: tech, c++

This is indeed a good way to reduce the code generated by templates.

https://devblogs.microsoft.com/oldnewthing/20260820-00/?p=112629/

We Have Named Arguments at Home

Tags: tech, rust, type-systems

It’s indeed not urgent to have this language feature in Rust. I’m less convinced about the case put forth regarding function overloading not being necessary though. Feels a bit like post-hoc justification in this case.

https://corrode.dev/blog/named-arguments-at-home/

Rusty thoughts on “Parse, don’t validate”

Tags: tech, type-systems, reliability, rust

This is indeed an important pattern to build reliable systems. It’s worth exploring in various languages. Here is the Rust perspective.

https://eli.thegreenplace.net/2026/rusty-thoughts-on-parse-dont-validate/

What makes Lisp difficult to read?

Tags: tech, lisp, vision

Interesting take and exploration for the reasons which might make Lisp harder to read than other languages.

https://paultm.nl/paren-thesis

Keep if clauses side-effect free

Tags: tech, programming, craftsmanship

You’re not paying for a couple more intermediate variables. For sure they make things more readable though.

https://www.teamten.com/lawrence/programming/keep-if-clauses-side-effect-free.html

Modern Motherfucking Website

Tags: tech, web, frontend, framework, complexity

Indeed web frameworks are not needed for everything.

https://modernmotherfuckingwebsite.dreamstation.systems/

A Staff Engineer’s Guide to Inventing Work

Tags: tech, ecosystem, product-management, project-management

Interesting points. If you’re making a platform you can’t really figure out what to do next in the same way than when usual product management is possible. There are signals to look for to feed your roadmap though.

https://sujithjay.com/inventing-work

Even at 100 meters, PV makes neighbours more likely to go green

Tags: tech, energy, ecology

This finding is kind of surprising to me. Time to install solar systems at home I guess?

https://www.pv-magazine.com/2026/08/20/even-at-100-meters-pv-makes-neighbours-more-likely-to-go-green/

Sodium-Ion Batteries May Be Close to Market Readiness

Tags: tech, energy, battery

Let’s see if it really takes off. It’d be a step in the right direction for sure.

https://en.reset.org/electric-cars-powered-by-salt-instead-of-lithium-sodium-ion-batteries-may-be-close-to-market-readiness/

Pirating the Pirates

Tags: movie, culture, copyright

Fascinating account of what people must go through for proper film preservation. It’s kind of weird that it is still illegal. You’d wish there’d be more recognition for such passion.

https://mubi.com/en/notebook/posts/pirating-the-pirates

Bye for now!

Web Review, Week 2026-39

ervin@ipsquad.net (Kevin Ottens) — Fri, 25 Sep 2026 21:13:27 +0000

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

The Test

Tags: tech, culture, business, politics

Yes, the preposterous statements from the tech moguls have a use. They allow them to gauge how obedient you are. This is thus a political function and a way to check their power. Maybe it’s time we collectively start to say the Emperor has no clothes?

https://tante.cc/2026/09/24/the-test/

I asked 100 companies for my data. Some deleted it instead.

Tags: tech, data, law, privacy

Don’t be like those companies! I wish there’d be more responsible handling of such requests.

https://arstechnica.com/tech-policy/2026/08/i-asked-100-companies-for-my-data-some-deleted-it-instead/

Why I Love AI

Tags: tech, ai, machine-learning, gpt, copilot, science, research

Since I’ve got my PhD in AI almost twenty years ago now, this piece strikes hard. This fellow kept doing research while I didn’t (the reasons to be told another time but it’s linked to this article). Clearly AI researchers who started around that time or before have a very different vision to what “AI” means as a field (although I’ve a few difference I’m fairly aligned with this article)… Clearly we’ve been robbed of the term by the industrial complex.

https://www.possibilityspace.org/blog/posts/i-love-ai/

Don’t be fooled by this summer of AI hype

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

The hype is very high right now indeed. This can lead only to misguided decisions. But really it’s mostly distraction from the massive ethical concerns this industry carries. It would require for policymakers to step up but I’m afraid it unfortunately won’t happen or they’ll come up with misguided attempts if they don’t first consult with field experts.

https://www.technologyreview.com/2026/09/22/1144867/dont-be-fooled-summer-ai-hype/

No Sloptober

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

Interesting initiative. I wish it’ll be popular and many people will follow it. Maybe it’ll cure some of them of their AI psychosis…

https://no-sloptober.com/

How to talk about “AI” without adding to the anthropomorphization

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

Goes maybe a tad too far in the opposite direction at times leading to clunky phrases. That said this effort of naming things properly is badly needed. I hope the media will seize it and report about those tools properly.

https://buttondown.com/maiht3k/archive/how-to-talk-about-ai-without-adding-to-the/

America is getting its AI race with China wrong

Tags: tech, ai, machine-learning, gpt, trust, business, law

So apparently the low adoption is due to the lack of trust in the systems and regulations could help? Who knew…

https://restofworld.org/2026/america-china-ai-race-trust/

ChatGPT now knows what you do on other websites via ad collector

Tags: tech, gpt, attention-economy, surveillance

It was only a matter of time I guess. Another vehicle of the attention economy. They’re trying to monetise through advertisements.

https://www.buchodi.com/chatgpt-now-knows-what-you-do-on-other-websites-via-ad-collector/

Laya — 33ms Multilingual System 1 Decision Engine with Calibrated Probabilities

Tags: tech, ai, machine-learning, decision-making

Now this look like a very interesting and useful model you can run locally. Definitely helps for classification tasks or assisting in decision making.

https://laya.convaiinnovations.com/

kev: tiny Jev-like family of decision models built on top of Qwen3.5 you can train and run on your own

Tags: tech, ai, machine-learning, decision-making

Looks like yet another interesting model to build decision assistance systems and classifiers.

https://github.com/jaredpalmer/kev

Linux programs look at things in /proc more than you’d expect

Tags: tech, linux, system

And most times as developers we don’t even realize it happens! It’s so conveniently hidden deep in most libraries or runtimes.

https://utcc.utoronto.ca/~cks/space/blog/linux/ProcGetsUsedByPrograms

About alignment, struct layout and the cache…

Tags: tech, c++, memory, caching, performance

Need to mind the memory layout of your structs to get good performance. Often overlooked but that also includes the padding.

https://meetingcpp.com/blog/items/About-alignment–struct-layout-and-the-cache—.html

How did AMD Ryzen get 50% faster in two years?

Tags: tech, hardware, cpu, amd, performance

There’s really something brewing at AMD. They’re on a roll performance wise.

https://lemire.me/blog/2026/09/18/how-did-amd-ryzen-get-50-faster-in-two-years/

How many strings can you create per second?

Tags: tech, memory, performance, c++, rust, go, python, javascript

Probably more than you think in this setup. And even more in C++ with the STL having years of smart tricks behind it.

https://lemire.me/blog/2026/09/25/how-many-strings-can-you-create-per-second/

Why CAFEBABE?

Tags: tech, java, funny

So many weird magic numbers to consider… Funny conversation around the one of Java class files.

https://www.artima.com/insidejvm/whyCAFEBABE.html

Union vs sum types

Tags: tech, type-systems

Wondering about the differences between union types and sum types? This gives a good idea about what they are.

https://viralinstruction.com/posts/uniontypes/

The Engineering Manager’s Guide to Emotional Tolerance

Tags: tech, management, emotions

This mostly fine advice. Managing requires acknowledging emotions otherwise you can’t lead effectively. Don’t get dragged too far into it though, you’re not a therapist.

https://thrivinginengineering.substack.com/p/the-engineering-managers-guide-to-emotional-tolerance

Bye for now!

KDE at 30: What Are the Colored Blobs Telling Us?

ervin@ipsquad.net (Kevin Ottens) — Sat, 19 Sep 2026 09:12:00 +0200

OK, it’s been a while since I blogged about community data analytics… I thought I’d do more posts on the matter but somehow never managed to get back to it. Now it’s a bit more than 6 years since my last post on the topic!

Worry not though I didn’t loose touch. Indeed I still hone this skill professionally since it’s an excellent source of information to better target audits or to give better advice when consulting on software architecture. This is by the way exactly what my last post on the topic was about. But this is not what we’re here for today!

Indeed, in a few weeks, KDE will turn 30 years old. This is impressive in terms of longevity for such a community. We’ve fostered a very diverse group, people are coming and going of course… So where does KDE stand? Are we looking at 30 more years or is it on a darker path?

It took a quick look at how KDE has been growing and shrinking as part of a post about communities size and activity. It was a quick peek only (I needed to look at other communities too) and 8 years ago. Time to revisit it all and with more details! Time to brace yourselves, it shall be a somewhat long read, we have 30 years to explore, but more importantly we’ll look at several subcommunities separately.

Choices, improvements, and caveats

For this article I made a couple of choices. I decided to give the current article the same angle than the 2018 one about communities size and activity. So I won’t show some of the more advanced diagrams I can produce and will stick only to the easy to read “team size” diagram and the “activity” diagram (the beloved “colored blobs” diagram).

For the latter, I also decided to anonymize the contributors, so no need to zoom to try to find your name, you won’t. I generally leave them when I’m doing more focused work since we mostly know who is working in a given team, but here I’ll be casting a very wide net and I don’t feel some people to feel uncomfortable because their name appears. Hopefully this should limit ego trips.

Note however, that behind the curtain I did produce “contributor network” diagrams (more advanced, more expensive, harder to read) without anonymization. They won’t be included in the article, but if I happen to mention some people, it’ll likely come from prior knowledge that I validated through those diagrams.

The last choice I made which deviates from previous explorations is how I map identities. I usually went for names and used manually curated rules to normalize such names. Some people are not really consistent there with sometimes three or more variations (looking at you Aleix 😉) hence those rules. Now doing this for all of KDE over 30 years… let’s say I didn’t have the time to update my rules this time around. Also, we’re having more company sponsored development nowadays so I decided to use emails. That means for instance that I represent two different contributors depending if I’m using my kde.org or my enioka.com email address. It doesn’t seem to skew too much the data, probably less than not having normalized names. For finer grained explorations it also helps figure out if a given contributor was doing something on company time or his own time (not everyone has that discipline but so be it).

Now let’s talk about improvements compared to previous related articles. Roughly speaking I tended to look only at repositories with C++ in them: libraries and applications. This time, I changed how I built my corpus of repositories (the switch to GitLab made things easier too) and I’m covering as wide as I could. It’s important because we’re doing more packaging work nowadays and also we can get a glimpse to the sysadmin activity.

But that’s also where lay the caveats…

I didn’t include the kdelibs repository this time, to reduce chances of counting some of the commits happening during the KDE Frameworks transition twice. This means we’ll have the very early history missing and the one we have will be underestimated a bit. But from previous explorations this shouldn’t distort things too much or change the trends we’re going to see anyway. I double checked this by also running experiments with kdelibs included on the side so I’m not worried. It’s worth keeping in mind though as if you use a fine enough comb you might spot tiny discrepancies.

Another problem to keep in mind is that I had to exclude the KDE Neon repositories. This is quite unfortunate but the majority of them started as forks coming from Debian or Ubuntu and so they pulled many commits unrelated to our community activity. The volume of those commits was unfortunately high enough that it’d completely skew the data at important points in time to have a readable history. Sadly I couldn’t figure a way to reliably sort between the commits to keep and the ones to reject hence why I left it completely out. Still it is something to keep in mind as well: later years are slightly underestimated. Hopefully not by much but I have no way to check.

However the Snap packaging and KDE Neon Core efforts are included as those were easy to split from the rest.

OK… with all those disclaimers out of the way time to look at the result.

30 years of KDE history

First let’s take a look at the teamsize plot for the whole community. It is an updated version from my 2018 post. Back then it was the only one we looked at. Of course, keep in mind I did things slightly differently as explained in the previous section.

[Full page version]

What can we see here? (I recommend looking at the full page version for all the plots) First striking thing is a similar profile to the plot I did in 2018 for the 1997 to 2018 period. Which is good news: what I wrote in 2018 isn’t invalidated by the adjusted and improved method I used for data collection.

Back then I noted that the active part of the community had been growing all the way to 2010 then started to shrink again. This is what we see, it peaks around 180 on average (and sometimes reaches towards around 200 people) then shrinks again hitting bottom around 110 persons on average in 2017.

We had no definite answer about why we’d seen this decline. The best shot we had is work done by Paul Adams and presented at Akademy 2014 pointing out that the community cohesion started to drop around the same time. This kind of pointed to the switch to git which could have demotivated some of the existing contributors. Also we didn’t have a really good forge on top, so it was harder to have a consolidated view of what was happening in all of the repositories IMHO.

Alright, but 2017 is almost ten years in the past… Since then, we had two major events happening. First, 2018 is the year where we had the first set of KDE Goals being picked by the community, one being “Streamlined onboarding of new contributors”. Second, we had the transition to GitLab which was fully delivered early in the second quarter of 2020.

Interestingly, we see the team size starts to pick up again towards the end of 2017. This is around the same time as the beginning of the KDE Goal process leading up to the first set of goals being selected in November 2017. It is also when we worked on the KDE Vision refresh. Around this period we don’t see the commit count pick up though (the entry count line), the new people probably joining at the time don’t quite compensate earlier losses.

Then later on, we see the team size growing again but this time the commit count is picking up too. It is between the end of 2019 all the way to mid-2020. Could it be helped by the GitLab switch? In any case, this is very good news, in my 2018 post I wonder if KDE would stabilize around the lower value of the time or pick up again… It definitely picked up again!

Now it seems like the team size if around 140 people on average, so closer to the all time high of 2010 but we didn’t fully close the gap yet. Interestingly though, the commit count is much closer to the one we had in 2010, with a bit less people. We even had an all time high commit count in 2023 which surpassed any other week since the creation of the project.

And to make things even brighter, the trends at the end of the plot point upwards. Looks like 2026 will be a very good year. Hopefully the growth will stay stable this time and then the community will be the biggest it’s ever been.

Now let’s take another point of view.

[Full page version]

This is our activity plot for the whole history of all of KDE. This is our colored blobs, I won’t focus much on the colors this time, it just says we have some contributors who are constant outliers in their activity. It’s not news and I’m not going to point them out.

Much more interesting is the shape of those blobs. The “bottom envelope” forms a curve and if we look at the angle it has, it is becoming more and more vertical. It’s not always the case we see some inflexion points if we zoom in, but on the whole history it definitely becomes steeper. Including towards the end of 2025 and through 2026 we see it changing again reinforcing the same trend.

This means we’re seeing more and more new contributors. KDE is recruiting new contributors and does so faster and faster. But is it only drive by contributions or people staying for longer?

This is were what’s on the other side of the curve, the actual blobs get interesting. If it’s not very dense and we see “lots of gray” it means people contribute a bit then stop. If it’s dense it means they’re staying around much longer or “forever”. To me, it started to get denser around 2019. So not only KDE is recruiting faster, but it’s retaining contributors for longer. It’s of course not at dense as in the early days but it’s likely the best you can do with such an old, large, and diverse community.

So altogether, I would say that KDE is a community which struggled between 2010 and 2017. It shrunk in the process but has been recovering since then. It feels very strong right now and could surpass the all time high it had in the past if the conditions are right. There are first signs of this: more commits per contributor, recruiting more, and better retention.

Looking a bit closer

At least we established that the forest (the whole KDE) is likely healthy. It doesn’t tell us much about individual trees though. Even healthy forests have diseased trees and that’s OK. Still for our exploration I think it’s good that we reduce the scope a bit and look at sub-communities within KDE to see how they fare.

KDE Frameworks

[Full page version]

Looking at KDE Frameworks the teamsize plot seems to tell a very different story than KDE as a whole. There are obvious similarities though. It’s mostly growth since the beginning and until 2010, the slope on that post is not as steep but remember the caveats. Since I didn’t include the kdelibs repository we miss some commits in the early history.

We find the same dip starting in 2010, but there’s a first big difference. It rebounds strongly and much earlier! Around 2012 it picks up already and reaches all times high in 2014. There I immediately know how to explain it because I was right in the middle of it.

We knew we were reaching the limits of the kdelibs model and in 2011 we had the Platform11 meeting. This is where we planned to turn kdelibs into KDE Frameworks. So for us a slow down in the kdelibs area was only natural we were busy making the necessary plans for the architectural transition. The transition itself began to be executed a bit later culminating in 2014 with the release of KDE Frameworks 5.0.

Hence the new dip we see just after. Everyone was tired and things were getting back to normal. By 2015/2016 the activity level was already back to the activity level of 2010.

This explains why I was kind of surprised by Paul’s talk in 2014… I was buried deep in KDE Frameworks and everything looked fine from there.

Which leave us now with the period of the GitLab transition. When it’s fully in effect (2020) KDE Frameworks also grows just like the whole KDE community. It’s oscillating a bit but it looks like it stabilized there.

[Full page version]

On the side of the activity plot, we see an overall acceleration in recruiting since the very beginning but it has clear periods of slowing down. Towards the end we find the same profile than for the whole of KDE: it looks like it’s accelerating further in 2026.

That being said in terms of retention, KDE Frameworks isn’t as good as KDE as a whole. But maybe it’s fine, it’s the base of all the projects and by its nature it likely attracts more drive by contributions than anywhere else in the community. We want to mutualize and that’s what people seem to be doing.

This product is not very noisy and just happily churns along it seems.

KDE PIM

[Full page version]

KDE PIM clearly has a more complicated history. It starts to mostly grow like the rest of KDE all the way to 2004 and then has a first clear dip in team size starting in 2004. It took three years to recover from it. I’m not sure what caused it… I wonder if it’s related to the great KMail maintainer war I hear about from time to time? It was before my time getting involved in KDE PIM.

Anyway, once the project recovered in 2007 things seem to be going along well with even a small spike in team size and larger spike in commits around 2009. If my memory serve this is when KDE PIM had seen some serious funding last. Then it dives like the whole of KDE around 2010.

It starts to pickup a bit again during the GitLab transition, but not as dramatically as the whole of KDE so something else must sustain that community wise increase. This is a common pattern for the whole of our applications by the way (I did plot it but didn’t include it here as this is already way too long).

One reason to rejoice is the increase of both team size and commits building up in 2026. With some of my colleagues, we might have something to do with this and I’m fairly happy about it. It’s likely not the only factor of course, as I mentioned earlier it looks like 2026 will be a particularly good year for KDE as a whole.

[Full page version]

In term or recruiting and retention, KDE PIM is a bit at risk I’d say. Clearly there’s been a slow down in recruiting new contributors starting in 2015. It looks like it’s slowly getting better catching up to earlier times but it took ten years to get there and it’s too early to see if it’ll sustain it.

In term of retention… let’s face it, it’s never been great nor improving. There’s a few individuals who stay around but not many. There’s clearly something pushing new contributors away preventing them to stay for long. For the nature of the product it raises questions. I have theories but no definitive answer so I won’t share them here.

What’s sure is that KDE PIM needs more involvement going forward to be sustainable.

Plasma

[Full page version]

Time to our flagship product: Plasma. The plots here include desktop, mobile, and big screen repositories. Note the very early history can’t be trusted, clearly it inherited commits from before Plasma was a thing.

Anyway, in terms of team size it’s been almost constantly growing. We find the 2010 dip but it’s much less dramatic than in all the other plots. It stabilized much quicker and managed to stay with an almost identical team size.

We also find the increase leading up to 2020. And clearly it’s one of the projects which benefitted the most of the GitLab transition. It’s average team size almost doubled during the transition!

Earlier I asked where the increase we could see on KDE as a whole but not on applications was coming from? Well, this is probably it.

Like the rest of KDE, 2026 will be a very good year for Plasma as well. I wonder… will it double in size again next year compared to 2020?

[Full page version]

Unsurprisingly recruiting is going well in Plasma if we look at the activity plot. Now the retention has been somewhat spotty, but clearly it’s improving: the density increases as we go down. Keep up the good work I’d say!

KDE Linux

[Full page version]

Time to look at the new kid on the block: KDE Linux. There’s been a lot of PR and expectations around this one but keep in mind it’s still young (history starts in 2023). We don’t have many data points yet so it’s a bit more difficult to draw conclusions.

Clearly so far it’s been growing in term of team size. This is good. That said, it is rather smaller than I’d expect from the exposure the project gets. This can be a good thing if it’s because we have a high impact team. But it can be a bad thing if it’s a sign of hyping things up before they’re truly ready to have a bigger team. Time will tell I guess.

What worries me a bit more is that the commit count doesn’t seem to pick up as fast as the team size. Again, we need more data and history to be sure there is a problem. But I’m wondering if we’re seeing early difficulties to synchronize within the team which is eating away at what could be produced. It might be a sign of some growing pains having a hard time to make newcomers truly productive.

[Full page version]

The activity plot seems to go in the same direction as my questioning above. The project has been recruiting faster towards the end of 2025 and this year. At the same time its retention rather diminished it seems. It could be again a sign of newcomers not finding their place or simply only motivated by drive by contributions.

Community wise it looks like KDE Linux is off to a good start but needs to strengthen its path on how to get involved.

Conclusion

This article turned rather longer than I anticipated, sorry about that!

We had a quick tour through 30 years of commit data. I would have liked to also process merge requests but at this scale it’s very time consuming so maybe I’ll do it another time on something more focused.

In any case, I’m rather happy that KDE as a whole seems very healthy. The last time I did such an exploration we left things undecided wondering if the community would ever recover from “the big 2010 dip in activity”. I would argue it did and with a few more years like 2026 we could expect to even go above the 2010 levels. We’re seeing early signs of it I think.

As for the projects we explored, flagship products (KDE Frameworks and Plasma) are doing rather well, for the other ones… your mileage may vary, it depends where you look. KDE PIM clearly has long term challenges it needs to overcome while KDE Linux raises questions but nothing unsurmountable. For both there’s likely some community work to be done, something need to be done to have a better retention of contributors.

I’d loved to also zoom in on Krita, Kdenlive, Elisa, etc. There are so many products in KDE!

So it looks like in almost 30 years KDE built a great community and many awesome products. We’re really forming a large and diverse family. Like any large families it can get sometimes ugly or messy but keeping the ties matter. Kudos to all the people involved for the past 30 years! Even if you’re not involved anymore you helped contribute something beautiful and precious to the world. We’re the living proof that large commons can be created and made sustainable thanks to passionate people.

Web Review, Week 2026-38 — The Graz Edition

ervin@ipsquad.net (Kevin Ottens) — Fri, 18 Sep 2026 12:50:37 +0000

Made it to Graz for Akademy 2026. Looking forward to meeting my fellow gearheads. In the meantime, let’s go for my web review for the week 2026-38.

25 Years of Mass Surveillance Is Enough

Tags: tech, surveillance, politics, democracy

This essay is fairly US centric but since other countries used the US surveillance apparatus as a blueprint for their own it’s widely applicable. It’s 25 years of failures and constitutional hazard, maybe it’s time to finally respect the right to privacy? Or are our governments too hooked to controlling the population and hunting dissent?

https://www.lawfaremedia.org/article/25-years-of-mass-surveillance-is-enough

What kind of Software should we fund?

Tags: tech, foss, fundraising, supply-chain, ethics, business

The article it refers to is interesting as well of course. Still it shines a crude light on the biases it has. We might have a way to fund libraries available via registries. That’s a good thing… But it ignores a lot of what Free Software is about. We need solutions for more software than just a specific family of libraries.

https://tante.cc/2026/09/17/what-kind-of-software-should-we-fund/

Inside ‘Project Lily’: The Humans Reading Your ChatGPT Chats

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

Of course unsurprising. Still it’s important to get the proofs out.

https://www.404media.co/inside-project-lily-the-humans-reading-your-chatgpt-chats/

‘Doom Loop’: OpenAI and Microsoft Admits LLMs Are Destroying the Web and Built on Theft

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

They claim fair use in public court but they know full well what they’ve been doing.

https://www.404media.co/doom-loop-openai-and-microsoft-admits-llms-are-destroying-the-web-and-built-on-theft/

Be alert: targeted attacks on prominent Rustaceans

Tags: tech, rust, supply-chain, security

Bad actors clearly want to compromise supply chains. Stay safe and keep your eyes open.

https://blog.rust-lang.org/2026/09/17/targeted-attacks/

what if my git host were a static site generator?

Tags: tech, tools, git, self-hosting

Looks like an interesting tool to expose git repositories read-only on the web.

https://char.lt/blog/2026/09/sorcery-repo-viewer/

A Design Space Exploration of Async/Await

Tags: tech, asynchronous, reliability

You think async/await works in the same way across languages? Think again! There are several choices of implementation behind it. You better know which choices your particular runtime did, otherwise you will get surprises. It also means it’s harder to reuse language from a given runtime and carry it over somewhere else.

Of course I recommend reading the full paper, but this short summary gives a good idea of the content.

https://cel.cs.brown.edu/blog/design-space-async-await/

How fast is C++23’s std::flat_map?

Tags: tech, c++, data, performance

Indeed it’s a very good new type of maps in many cases. Again a good illustration that nowadays memory layout is often more important than algorithmic complexity.

https://lemire.me/blog/2026/09/16/how-fast-is-c23s-stdflat_map/

C++26: Trivial infinite loops are no longer undefined behaviour

Tags: tech, c++, reliability, safety

It’s about time that it got fixed… This was really a language defect.

https://www.sandordargo.com/blog/2026/09/16/cpp26-trivial-infinite-loops

How to Recognize a Change in Capacity to Stop Pressure

Tags: management, productivity

Doesn’t feel too actionable on how to detect the change of capacity. That said the advice on how to deal with it is correct.

https://www.jrothman.com/mpd/2026/09/management-minute-how-to-recognize-a-change-in-capacity-to-stop-pressure/

Clear as Mud

Tags: management, delegation

A few things to keep in mind when delegating tasks. This seems trivial but it’s harder than it sounds.

https://managementblog.org/2026/08/28/clear-as-mud/

Proper English is a Myth: There’s No ‘Correct’ Way to Write

Tags: linguistics, writing

I’d say it goes a bit too far in its stance at times. That said it’s a good reminder that English like any other languages is in a constant state of flux.

https://brennan.day/proper-english-is-a-myth-theres-no-correct-way-to-write/

Bye for now!

Web Review, Week 2026-37

ervin@ipsquad.net (Kevin Ottens) — Fri, 11 Sep 2026 15:47:42 +0000

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

Tags: tech, fediverse, social-media, community

Interesting approach. When friction to subscription is a good way to really build community.

https://tante.cc/2026/09/10/making-social-media-social/

Automattic CEO Matt Mullenweg Put on ‘Leave of Absence’

Tags: tech, blog, wordpress, business

Looks like the drama continues. I wonder where this will land.

https://www.404media.co/wordpress-automattic-ceo-matt-mullenweg-put-on-leave-of-absence/

Doomscrolling ourselves to death

Tags: tech, book, reading, tv, social-media, attention-economy, politics, history

The argument presented is maybe a bit too mechanical for my taste. That said there’s indeed something to be said about the decline in literacy and its consequences on our societies.

https://www.edwest.co.uk/p/doomscrolling-ourselves-to-death

Tristan Buckmaster’s statement on the Navier-Stokes resolution

Tags: tech, ai, machine-learning, gpt, mathematics, ethics, science

Shows some insights into the kerfuffle around the Navier-Stokes recent resolution. The behavior of OpenAI in this affair is ludicrous. In my opinion this is showing research malpractice… Why care about the scientific method when you have a shot at good PR?

https://cims.nyu.edu/~tristanb/statement.pdf

The function of LLM-based math “proofs”

Tags: tech, ai, machine-learning, gpt, mathematics, research, science

Is it badly conducted research for PR purpose? Who would have expected anything different? I wish we’d fund real science instead…

https://tante.cc/2026/09/07/the-function-of-llm-based-math-proofs/

Soft-deprecating re.match()

Tags: tech, api, python

Interesting way to deal with deprecation in Python. Indeed sometimes it doesn’t hurt to keep the not so ideal old name… but you want to push user code to know they miss an opportunity in readability by using the old name.

https://hugovk.dev/blog/2026/soft-deprecating-re.match/

A quick overview of atomics in C

Tags: tech, c, multithreading, atomics

Still need to understand atomics and memory barrier? This is a neat primer.

https://lemire.me/blog/2026/09/09/a-quick-overview-of-atomics-in-c/

Visualizing Rust’s Vtables: How dyn Trait Works In Memory

Tags: tech, c++, rust, memory, type-systems

Interesting exploration of how static and dynamic dispatchs work behind the scene in Rust. The chosen tradeoffs are different than in C++ and that’s something to keep in mind.

https://sofiabelen.github.io/projects/visualizing-rusts-vtables-how-dyn-trait-works-in-memory/

My HTML Boilerplate

Tags: tech, web, html

There’s a lot of important metadata in HTML pages nowadays… and there could be more than proposed here.

https://vale.rocks/posts/html-boilerplate

There’s No Limit to How Bad Code Can Get

Tags: tech, software, engineering, quality

Good point. The metaphors we use have obviously some limits. In the case of the “sinking ship” when used for software it doesn’t quite work as there’s no bottom…

https://zachkehs.com/blog/theres_no_limit_to_how_bad_code_can_get/

On Quality: What It Is and Why Products Get Worse

Tags: production, quality, craftsmanship

Very nice read about quality in general and why it’s really hard to define. It also explores how it can degrade over time in existing products.

https://www.worseonpurpose.com/p/on-quality

Degeneracy is a Symptom

Tags: history, economics, politics

Or why it’s stupid to judge people on their non virtuous behavior while at the same time fostering the structures which ensure that virtue does not pay. So indeed, some people read the odds properly and act accordingly…

https://henryfudgeofficial.substack.com/p/degeneracy-is-a-symptom

The Last Person to Know the Dictator Is Screwed Is the Dictator

Tags: history, politics

Build a good enough echo chamber and you won’t know you’re toast before it’s too late.

https://thegrimhistorian.substack.com/p/the-last-person-to-know-the-dictator

When Death Was a Relief

Tags: history

Such a wonderful species we are… not. Things can get really nasty when someone starts exploiting beliefs and gains some sort of power. And then, the blame game begins. Unfortunately it regularly happens.

https://m.youtube.com/watch?v=205swuI0JlY

Bye for now!

Web Review, Week 2026-36

ervin@ipsquad.net (Kevin Ottens) — Fri, 04 Sep 2026 11:46:49 +0000

Back from vacations and I did some catch up late at night… So expect a larger selection than usual. Let’s go for my web review for the week 2026-36.

WEBMASTER@ a manifesto for everyone

Tags: tech, web, internet, culture, history

A very uplifting essay in my opinion. Starts with a historical perspective on the webmaster role to then evolve into a manifesto about creation on the web.

https://brennan.day/webmaster-a-manifesto-for-everyone/

There’s no such thing as Just a Tool

Tags: tech, tools, philosophy, framework, design

Indeed, it’s high time our industry leaves the “it’s just a tool” rhetoric behind. This claim is a way for us to not take our responsibilities in the design of the tools we make.

https://deadsimpletech.com/blog/no-such-thing-as-just-a-tool

Normalized Fascism in Open Source: $12 Million Given to DHH

Tags: tech, foss, politics

There’s no “apolitical” projects. Claiming the contrary is just trying to hide your agenda. While our engineer culture keeps falling for it, really bad actors are benefiting from it…

https://brennan.day/normalized-fascism-in-open-source-12-million-given-to-dhh/

Tags: tech, facebook, social-media, law, surveillance

This is not indeed the win you’d expect. More surveillance coming pushed by the settlement…

https://www.eff.org/deeplinks/2026/09/metas-17-billion-settlement-bad-deal-teens-and-all-social-media-users

The actual epistemic crisis

Tags: tech, ai, machine-learning, gpt, fake, fake-news, knowledge, politics

Very important opinion piece from Cory Doctorow again. The trend was clear of an epistemic crisis brewing and generative AI basically put it on steroids. This is a real blow to our civilisation.

https://pluralistic.net/2026/08/20/epistemic-void/#expert-agencies

The people vs the AI overlords

Tags: tech, ai, machine-learning, copilot, politics

Clearly there’s a political project behind the design of those tools. Clearly our industry is lacking enough class consciousness to push back against the “AI overlords” agenda.

https://anarc.at/blog/2026-08-18-people-vs-ai-overlords/

We Tracked a Shipment of Rare Books. It Ended at an Amazon AI Training Facility

Tags: tech, ai, machine-learning, gpt, ethics, book, knowledge

This truly makes me sad… The level of cynicism required to destroy rare books is just beyond me. All this to squeeze the last human made tokens available with no real gain in sight.

https://www.404media.co/we-tracked-a-shipment-of-rare-books-it-ended-at-an-amazon-ai-training-facility/

AI Software Development – What Does The Data Say?

Tags: tech, ai, machine-learning, copilot, engineering

The executive summary is good. This is also a nice source of reference papers and studies on the topic. It shows quite well why the work is moving to the harnesses rather than the models. Indeed models probably won’t improve much in terms of reliability. It all points once again towards a needed shift of people attention from the shiny toys and towards team practice instead.

https://codemanship.wordpress.com/2026/08/12/ai-software-development-what-does-the-data-say/

There Is Still No Silver Bullet

Tags: tech, ai, machine-learning, copilot, productivity, engineering, craftsmanship

Very good opinion piece going back to Naur’s and Brook’s important papers about software production. It’s a sobering take on how LLM can’t bring the promised productivity gains. This is not saying it can’t bring productivity gains of course but it’ll never be as dramatic as what the current hype cycle pushes people to believe.

https://cekrem.github.io/posts/there-is-still-no-silver-bullet/

Copyrightability of LLM-generated code: Can we license “vibe code” into Free Software?

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

Clearly the situation of copyright around LLM uses is complex. It’s easy to fall into code which can’t be copyrighted if there’s not enough human input to produce the work (and keep in mind that “prompting” is likely not enough input). This also raises questions about potential copyright violations. Looks like following the guidelines of the SFC for contributing to Free Software projects is getting especially important.

https://fsfe.org/news/2026/news-20260825-01.html

And then the men with guns tell you to do it anyway

Tags: tech, security, privacy, politics

Or a reminder that no system can be made to be completely safe and secure. When the political pressure or violence gets in the equation it’s hard to not simply falter and satisfy the demands.

https://shkspr.mobi/blog/2026/08/and-then-the-men-with-guns-tell-you-to-do-it-anyway/

hk - Git Hook Manager

Tags: tech, git, tools, linting

Might turn into a nice way to manage your git hooks.

https://hk.jdx.dev/

Easy Sandboxing on Linux with Bubblewrap

Tags: tech, linux containers, flatpak, security, sandbox

A nice and simple approach to sandbox a command. Of course with the system integration it’s a bit porous bit it might be a good base for quite a few uses.

https://bxt.rs/blog/easy-sandboxing-on-linux-with-bubblewrap/

Hister: Your Own Search Engine

Tags: tech, search, self-hosting

Looks like an interesting personal indexing system for your own files and slice of the web.

https://hister.org/

Monitoring SystemD services with Healthchecks.io

Tags: tech, systemd, monitoring

Neat trick to monitor systemd services.

https://passbe.com/2022/healthchecks-io-systemd-checks/

Python sets and dictionaries can have quadratic-time performance

Tags: tech, python, performance, algorithm, cpu, memory, complexity

Too often people mistake the algorithmic complexity theory for the real performances you would get. This can’t be further from the truth. The memory layout trumps all. As usual you need to measure.

https://lemire.me/blog/2026/09/03/python-sets-and-dictionaries-can-have-quadratic-time-performance/

Rewriting in Rust: Performance, Failures, 2026 Reality Check

Tags: tech, rust, porting, rewrite, safety

Unsurprisingly it’s not all unicorns and rainbows. This piece tries to highlight the right questions to ask yourself before aiming for a rewrite.

https://blog.jetbrains.com/rust/2026/08/10/rewriting-in-rust/

Rust concurrency vs Go concurrency: stackless vs stackfull coroutines

Tags: tech, go, rust, asynchronous, coroutine

Comparison of two concurrency models. This is a light read which shows quite well the differences.

https://kerkour.com/rust-vs-go-concurrency

Concurrency vs. Throughput: why more parallelism can make databases slower

Tags: tech, multithreading, databases, performance

When more concurrency might not help. Illustration with the case of database queries.

https://planetscale.com/blog/concurrency-vs-throughput-vitess-mysql

SQLite for Everything

Tags: tech, databases, sqlite, architecture, funny

Another love letter to SQLite. It’s meant to be funny but comes with plenty of good arguments and ideas as well.

https://joecode.com/2026-08-19-sqlite3/

The Browser’s Main Thread Is Expensive

Tags: tech, web, frontend, browser, performance

A reminder that web frontend work isn’t as easy as it sounds. It brings quite some caveats and his difficult to do well. Otherwise you wonder why things stutter or render badly.

https://kciter.so/posts/the-expensive-main-thread/en/

Ambient CSS — a physics-based lighting system for CSS

Tags: tech, css, graphics, physics

Really nice tricks you can pull with CSS nowadays. The result is fairly nice visually.

https://ambientcss.vercel.app/

HTML Can Do That

Tags: tech, html, javascript

More proofs that HTML is more and more capable by itself.

https://chrisburnell.com/html-can-do-that/#example-until-found

Solving copyright & licensing information in client-side JavaScript, CSS and similar

Tags: tech, web, frontend, javascript, licensing, foss, law

Finally a sensible approach to communicate license compliance for client side content delivered via a browser. It’s not too much of a bother so let’s hope it gets picked up.

https://matija.suklje.name/solving-copyright-licensing-information-in-client-side-javascript-css-and-similar-agreeing-on-a-useful-solution

Software That Must Not Be Wrong: Property Tests for a Pediatric Dosing Calculator

Tags: tech, property-based-testing, tests, rust, type-systems

Interesting case where you want to property test but without a specific property base test tool. Indeed, if you need to be exhaustive and the input space is small enough this is the better decision. This article also comes with interesting point on Rust type system but that’s less central to the main point.

https://rust-blog.github.io/post/favi-child-property-tests/

Let’s not call it “tech debt,” it’s just “mess”

Tags: tech, technical-debt, complexity, maintenance, craftsmanship

A good piece showing some of the problems with how the term technical debt is widely misused. There’s a problem with the metaphor itself, you rarely have the information level needed to call it debt.

https://www.simplermachines.com/lets-not-call-it-tech-debt-its-just-mess/

Guilt-Driven Development

Tags: tech, quality, engineering, craftsmanship

I like this article somehow. Indeed I’d like to see more guilt in the people shipping bugs in production (myself included probably). Also I’m very much aligned with the proposed approach to tame issues: thinking, types, tests, and telemetry.

https://markuseliasson.se/article/guilt-driven-development

Reviewing code is a skill

Tags: tech, engineering, codereview, learning, knowledge

Excellent piece about code reviews. But it goes further than that and shows how our skills could improve. By tackling this question it does a good job showing we don’t know where the ceiling is in terms of skills in our craft.

https://typesanitizer.com/blog/code-review.html

Coachability++

Tags: tech, coaching, management, mentoring

Interesting slide deck about coaching in tech circles. Clearly provides good inspiration both for coaches or if you’re the one requesting to be coached.

https://cate.blog/2021/02/22/coachability/

The Expertise Trap

Tags: expertise, problem-solving, cognition, bias

This is an easy trap to fall into unfortunately. Be mindful of your own biases. They might increase as you gain more expertise in a field unfortunately.

https://www.congruentchange.com/the-expertise-trap/

Has America Crossed the Asshole Threshold?

Tags: history, politics, mathematics

Don’t be fooled by the click-bait title. It’s a good piece looking at history and game theory. It gives some lessons about how civilizations collapse… or not.

https://thegrimhistorian.substack.com/p/has-america-crossed-the-asshole-threshold

Meet the 2026 Ig Nobel Prize winners

Tags: science, funny

Another good crop of Ig Nobel this year! I’m not sure which one is my favorite.

https://arstechnica.com/science/2026/09/meet-the-2026-ig-nobel-prize-winners/

Bye for now!

Web Review, Week 2026-32

ervin@ipsquad.net (Kevin Ottens) — Fri, 07 Aug 2026 12:22:09 +0000

Alright, this will be the last review of the Summer. I’ll take a break until September as I really need to unplug for a bit. The next edition will be at the end of the first week of September. See you then!

But first… let’s go for my web review for the week 2026-32.

Tags: tech, gdpr, web, europe, law

This campaign is definitely worth a try. Hammering people with cookie banners exhibiting dark patterns isn’t exactly a good way to seek people consent.

https://killthecookiebanner.eu/

Stop Sending Me Your Errors

Tags: tech, email

Yes please! The amount of email system which get it wrong nowaday is really kind of sad.

https://kramkow.ski/article/2026/08/05/stop_sending_me_your_errors.html

Offensive Internet Posture

Tags: tech, internet, security, self-hosting

Indeed, so many things to do to deter bottom feeders. Lots of good funny ideas in there.

https://bruceediger.com/posts/offensive-machine/

Atom is better than RSS, in ways that matter

Tags: tech, atom, rss, blog

Indeed Atom is a better standard than RSS for feeds.

https://chrismorgan.info/atom%3Erss

The DISTINCT in your COUNT

Tags: tech, databases, postgresql, performance, optimisation

Careful how you use DISTINCT or ORDER BY on very large tables. You might want to reevaluate (after checking if there’s a problem of course).

https://boringsql.com/posts/distinct-in-your-count/

C++26: #embed

Tags: tech, c++

Another nice addition to the standard for dealing with embedded assets.

https://www.sandordargo.com/blog/2026/08/05/cpp26-embed

Crubit: C++/Rust Bidirectional Interop Tool

Tags: tech, c++, rust, interoperability, bindings

Interesting tool. Maybe more chances for C++ and Rust hybrids?

https://crubit.rs/

rust-lang/rust is adopting an LLM policy

Tags: tech, ai, machine-learning, copilot, foss, codereview, rust

Interesting policy. I think it strikes a good balance.

https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/

A Guide to Watchdog Timers for Embedded Systems

Tags: tech, embedded, reliability

Long and nice guide about watchdogs in an embedded context.

https://interrupt.memfault.com/blog/firmware-watchdog-best-practices

Elevators

Tags: tech, algorithm, simulation, complexity

Nice little post with simulations about the algorithms behind elevators. It’s quickly more complex than it sounds.

https://john.fun/elevators

The Wheels We Keep Reinventing

Tags: tech, architecture, complexity, supply-chain, vendor-lockin

There is truth here that our profession reinvents the wheel way to often. Some problem are solved, they don’t need reinventing. Be careful on your dependencies though, this is where lies the tradeoff.

https://blainsmith.com/articles/reinventing-the-wheel/

The development pipeline is a production system

Tags: tech, developer-experience, production

And indeed that makes it as important as the final product.

https://sundry.jerryorr.com/2026/07/31/development-pipeline-is-a-production-system

Committing to creativity

Tags: creativity, motivation

Interesting take. It’s indeed mostly about committing to something on the long term and doing the grunt work which begets creativity. It’s not just motivation between grit teeth or waiting to be blessed by a muse. Those won’t get you as far in your craft.

https://herman.bearblog.dev/creativity/

Bye for now!

Web Review, Week 2026-31

ervin@ipsquad.net (Kevin Ottens) — Fri, 31 Jul 2026 16:17:16 +0000

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

Sovereignty is a substrate

Tags: tech, hardware, supply-chain, complexity

Interesting piece which shows very well the complexity of the hardware supply chain. The parts which matter the most are largely ignored by everyone.

https://negroniventurestudios.com/2026/07/28/sovereignty-is-a-substrate/

Do LLMs know how to make software? (No.)

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

Funny, I was using that exact same term recently: “brute-force driven development”. It describes fairly well how the harnesses work.

https://mir.aculo.us/do-llms-know-how-to-make-software-no/

Getting access to the /tmp of a systemd service with PrivateTmp=yes

Tags: tech, systemd

Don’t forget, it’s all namespaces!

https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdPrivateTmpWhere

The Hamburger Database Design Pattern

Tags: tech, databases, design, pattern

Interesting pattern for managing materialized views over a long time.

https://pagedout.institute/download/PagedOut_009.pdf#[{“num”:100,“gen”:0},{“name”:“XYZ”},null,null,null]

Memory-level parallelism: AMD is the king

Tags: tech, cpu, amd, performance

They’re definitely handling this part right, they seem well ahead everyone else.

https://lemire.me/blog/2026/07/25/memory-level-parallelism-amd-is-the-king/

C++26: Reducing undefined behaviour

Tags: tech, c++, standard, safety, reliability

More signs of C++26 being an important new standard for reliability and safety.

https://www.sandordargo.com/blog/2026/07/29/cpp26-reduces-undefined-behaviour

C++ float-to-int conversion can be undefined behavior

Tags: tech, c++, safety

This is a bigger trap than it sounds. It is very easy to fall into it.

https://kttnr.net/blog/cpp-float-to-int-conversion-undefined-behavior/

Learn WebGPU for C++ documentation

Tags: tech, web, webgpu, graphics

Curious about WebGPU? This looks like it’ll become a very good resource for that.

https://eliemichel.github.io/LearnWebGPU/

The Website Specification

Tags: tech, web, standard

This is very comprehensive! It is also overwhelming… So many things to think about when making a website nowadays.

https://specification.website/

What even are microservices?

Tags: tech, architecture, microservices

Since I still hear about “microservices” more often than I’d like to. Here is another piece which points the trade-offs and that really there’s no one size fits all.

https://var0.xyz/posts/what-even-are-microservices.html

Code Review Responses: Add Context When It Counts

Tags: tech, codereview

There are indeed cases where it’s important to provide more context on the code which changed following up a comment by the reviewer.

https://testing.googleblog.com/2026/05/code-review-responses-add-context-when.html?m=1

How I Find Problems to Solve as a Staff Engineer

Tags: tech, engineering, leadership, problem-solving

Good approach, you indeed need to immerse yourself in the context and see the recurring patterns. That’s the best way to figure out impactful solutions to recurring issues.

https://lalitm.com/post/find-problems-staff-engineer/

Your harddrive is probably full

Tags: tech, storage, resources, procrastination

Interesting take, it’s more than just about hard drives being full. Indeed, there are many things on which we tend to procrastinate. But on the other hand… so many budgets to track otherwise!

https://www.marginalia.nu/log/a_139_hdd/

The Crossover Project

Tags: tech, software, engineering, agile, craftsmanship

Very interesting series I previously missed. It explores if software engineering is really engineering, and the differences with other engineering fields. Quite a few nice lessons to draw from it.

https://www.hillelwayne.com/tags/crossover-project/

Kaizen Board: A Reply on Every Sheet

Tags: tech, quality, kaizen, japan

Wondering how that works when it runs properly? Here is an example of a Kaizen board in a japanese factory.

https://www.leanblog.org/2026/07/kaizen-board-manager-comments/

Bye for now!

Web Review, Week 2026-30

ervin@ipsquad.net (Kevin Ottens) — Fri, 24 Jul 2026 11:38:11 +0000

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

Online Friends Are Real Friends

Tags: tech, internet, culture, life, friendship

Indeed, friends we make online are no less real than the ones we see in the flesh first. I would know… guess how I made friends with KDE people?

https://blog.absurdpirate.com/online-friends-are-real-friends/

Europe’s digital sovereignty needs challenges

Tags: tech, europe, politics, foss, commons

Excellent piece. I’m feeling unease at this widespread confusion between european ownership and digital freedom. What we collectively need is the latter. There’s no sovereignty to be had in a proprietary ecosystem, be it owned by an European company or not.

https://hamishcampbell.com/europes-digital-sovereignty-needs-challenges/

Mullvad and Daniel Berntsson’s Failed Cleanup

Tags: tech, ethics, politics, vpn

No the technology we use isn’t neutral… In this case it directly funds fascists. Whatever the technical merits from the Mullvad VPN, such ties disqualify them to be used.

https://markwrites.io/mullvad-and-daniel-berntssons-failed-cleanup/

Leiden Declaration on Artificial Intelligence and Mathematics

Tags: tech, mathematics, science, research, ai, machine-learning, gpt

This is a very good declaration and call to actions from the mathematics field. I wish we’d have something well thought out like this for computer science and software engineering as well.

https://leidendeclaration.ai/

AI advice suppresses people’s willingness to say “I don’t know”

Tags: tech, ai, machine-learning, gpt, linguistics, cognition, bias

Interesting study which measures our propensity to be more confident while being more wrong when using LLMs to answer questions. Those models really tap into our cognitive bias to mistake linguistic fluency for competence.

https://osf.io/preprints/psyarxiv/5y6m4_v1

Not enough water for UK’s datacentre plans, trade body says

Tags: tech, ai, machine-learning, gpt, water, ecology, politics

If you still don’t think data centres have a water consumption problem, especially since the LLM weapon race… Think again.

https://www.theguardian.com/environment/2026/jul/21/not-enough-water-for-uks-datacentre-plans-trade-body-says

The Week of Sandbox Escapes

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

In other words: the security boundaries of coding agents are very porous and not where you expect. Handle with extreme care until they have a proper security model.

https://www.pillar.security/blog/the-week-of-sandbox-escapes

email encryption

Tags: tech, email, cryptography, history

Wondering about the landscape of email encryption? This gives a good historical tour.

https://computer.rip/2026-07-19-email-encryption.html

Minimal Git CI using hooks

Tags: tech, git, tools, ci, complexity

Little reminder that a got forge doesn’t and shouldn’t need much. Sprinkle gitolite if you need to manage rights, maybe gitweb and then you’re all set.

https://mccd.space/posts/26-06-29/simple-git-ci

The startup’s Postgres survival guide

Tags: tech, databases, postgresql

Quite a few nice Postgres tips. The first ones are rather basics the less common tips are toward the end. Could have a few more details at times, but that’s a good starting point.

https://hatchet.run/blog/postgres-survival-guide

When ‘if’ slows you down, avoid it

Tags: tech, programming, performance

This is too often forgotten. If you can avoid the “if” and your CPU will thank you for it.

https://easylang.online/blog/branchless

Everyone Should Know SIMD

Tags: tech, simd, cpu, performance, zig

Nice post on how to approach problems suitable for SIMD.

https://mitchellh.com/writing/everyone-should-know-simd

Static search trees: 40x faster than binary search

Tags: tech, cpu, simd, performance, optimisation

Excellent piece diving deep into the opportunities to optimise an algorithm. The final speed up is impressive.

https://curiouscoding.nl/posts/static-search-tree/

Rust service hardening and production checklist

Tags: tech, rust, containers, security

Good checklist to reduce your attack surface as much as possible when deploying your service.

https://kerkour.com/rust-service-hardening-and-production-checklist

Hardening Rust Code For Production

Tags: tech, rust, containers, security

More ideas of things to check to harden a service, goes beyond just what’s deployed. Many good points on how to handle errors and such.

https://corrode.dev/blog/hardening-rust/

The PImpl idiom and the C++26 std::indirect type

Tags: tech, c++, memory

Looks like a nice improvement over std::unique_ptr for managing pimpl indeed. Really interesting stuff coming in C++26.

https://mariusbancila.ro/blog/2026/07/23/the-pimpl-idiom-and-the-cpp26-stdindirect-type/

Software rendering in 500 lines of bare C++

Tags: tech, graphics, 3d, shader

Wondering how the graphics pipeline works for 3D rendering? This is a nice lecture on how to implement a purely software one. If gives a good idea of what needs to happen.

https://haqr.eu/tinyrenderer/

Prefactoring: Clear the Way for Your New Feature

Tags: tech, refactoring

Short and to the point to illustrate the use of refactoring at the beginning of the work on a feature.

https://testing.googleblog.com/2026/07/prefactoring-clear-way-for-your-new.html

The Value of Domain Knowledge in Software

Tags: tech, knowledge, craftsmanship

This is too often forgotten by developers. Our job isn’t only about the technical side of things, we must also understand the domain the users are working in. It’s a part of the craft.

https://www.gustavwengel.dk/value-of-domain-knowledge

The Most Ridiculous War Humans Ever Fought

Tags: history, funny

OK, didn’t know about this one. It was indeed ridiculous… we’re really a weird species.

https://www.youtube.com/watch?v=Qv5qQu0yMaU

The Deadliest Thing in Your Kitchen

Tags: biology, science, funny

You won’t look at your kitchen the same way after this.

https://www.youtube.com/watch?v=2cK8l5Yg5w8

Bye for now!

KDE for Enterprise Needs a Strong PIM Infrastructure

ervin@ipsquad.net (Kevin Ottens) — Tue, 21 Jul 2026 09:06:52 +0200

This post has been long overdue, but let’s say I’ve been busy and the reason will be obvious in this short piece. ☺

As you might have heard a couple of months ago, the Sovereign Tech Fund did a large investment in KDE software development. From the announcement the details can be a bit sparse on what it actually entails. Especially regarding the part which says “the frameworks underlying its communication services”. It turns out this is what enioka Haute Couture is contracted by KDE e.V. to work on. Let me bring a bit more details about it.

What? Why?

The overarching theme of the investment is to make the KDE ecosystem more desirable for enterprise and public institution uses. The desktop shell (Plasma) and having a strong base to distribute it (KDE Linux) obviously comes to mind, but it’s also about the Personal Information Management (PIM) space. Nowadays a good chunk of the institutional life (public or otherwise) is to deal with email, contacts and calendars. So we set sail to strengthen Kontact, KMail, Korganizer and friends. More specifically, we want to strengthen its underlying infrastructure: Akonadi and its resources.

So what exactly are we working on currently? Well, I propose you attend the Akademy 2026 talk of my colleagues which will cover what we do on KDE PIM!

The Work

OK, OK, you’re still here? So read on for a few more details even though I obviously don’t want to steal their thunder.

There are three axis we’re focusing on:

Quality
Protocol support and modernisation
Ease of use and deployment

Quality

Those who know me also know what it means: more tests!!!

To be fair on the Akonadi server and resources side, we’re not too bad in terms of unit tests. The underlying protocol libraries as well have some unit test. The DAV side is maybe a bit weak and we hope to fix that, but on the IMAP side things aren’t too shabby.

That being said, we didn’t really have a test suite which would cover all the components integrated together. Those are more expensive and less fun to develop, so we’d be working on that by adopting a proof of concept done by Dan Vratil a while ago. It changed quite a lot but is becoming stronger with a comprehensive test suite covering IMAP and DAV.

Unsurprisingly it uncovered quite a few bugs we didn’t know about before starting the work, and gave us a nice environment to reproduce long known bugs that we had a hard time to chase down previously.

Of course, we’re working through the list of failing tests to fix everything we can. Some of my long hated bugs are already gone! Well, I use the master branch… so I live in the future from you dear readers, and the future is definitely better here.

Protocol Support and Modernisation

Our PIM suite supports many protocols… but in the case of enterprise use in a sovereign context (so having some control on the server side, and using open protocols), IMAP4, CalDAV, and iTIP (for invitations) are kings. So we’re focusing on modernising our support for them.

In particular we’re aiming at better support of IMAP4rev2 enabled servers, but also QRESYNC. This should bring a better use of network resources and faster resync.

On the DAV side, we’re looking at supporting push notifications. This is currently not completely standardised but we’ll be ready as soon as it is. Everything will be in place to track the specification as it matures. Thanks to this work, we’ll also improve the syncing code of the DAV resource, again using less network bandwidth.

Obviously iTIP support benefits from both. It also highlights issues on the DAV support which we’re fixing as we find them.

Ease of Use and Deployment

The architecture of Akonadi means that a user setup of the solution has quite a few components to configure. This is not necessarily a problem in itself, but we could make things easier and at times it’s mostly about configuring each protocol manually and separately.

Of course, there’s a specification proposed to support autoconfiguration based on just an email and a password. We got some partial support for it in KMail, but we’ll work on completing this and bringing it closer to System Settings. Couple that to some device management facilities in say… KDE Linux and that starts to look like a strong proposal for enterprise.

Finally, we’ll look into the Flatpak version of our PIM suite and see how to make it easier to integrate in the desktop. The possibilities are fairly limited for now and we’d like to make it first class going forward.

What to Expect

Obviously for the time being we can expect more activity in KDE PIM which is good. We have quite a few patches in the PIM repositories at this point and some of the improvement will be released really soon as part of 26.08! Some more will come in the next release (26.12) of course but it still required too much QA and missed the freeze. No matter, it’s not a long wait.

Also, we hope that it’ll be easier to deploy and setup when we get to tackle the Flatpak related tasks. Really looking forward to this! We hope to deliver this by the end of the year or early 2027. Which would mark the end of the project for us.

Later on, I hope this infrastructure work will attract more users and contributors again. Indeed, there’s still interesting work needed on the application side of things, but if the protocol support and quality of the base system is stronger, it makes it easier to try new things with the applications, less pieces to fight with will make the whole endeavour more desirable.

Lisp on ervin

Web Review, Week 2026-40

NVIDIA’s Greenwashing Tactics & Hidden Emissions

AI’s Unsustainable impacts to grow x7 by 2030

Micron CEO Says Memory Supply Will Be Much Tighter in 2027 and 2028 Than in 2026

The AI Pascal’s Wager

If we do not stop to help each other, what do we become?

The opposite of the apocalypse is a neighborhood

One month without AI

This study looks at how and with whom connected cars share your data

File Notification Attacks

Don’t couple your Go code to GitHub

Taking Out The Garbage In Postgres

DTAP - Text and Test Anything Protocol

Reducing C++ template bloat by factoring out the type-dependent portions of the function

We Have Named Arguments at Home

Rusty thoughts on “Parse, don’t validate”

What makes Lisp difficult to read?

Keep if clauses side-effect free

Modern Motherfucking Website

A Staff Engineer’s Guide to Inventing Work

Even at 100 meters, PV makes neighbours more likely to go green

Sodium-Ion Batteries May Be Close to Market Readiness

Pirating the Pirates

Web Review, Week 2026-39

The Test

I asked 100 companies for my data. Some deleted it instead.

Why I Love AI

Don’t be fooled by this summer of AI hype

No Sloptober

How to talk about “AI” without adding to the anthropomorphization

America is getting its AI race with China wrong

ChatGPT now knows what you do on other websites via ad collector

Laya — 33ms Multilingual System 1 Decision Engine with Calibrated Probabilities

kev: tiny Jev-like family of decision models built on top of Qwen3.5 you can train and run on your own

Linux programs look at things in /proc more than you’d expect

About alignment, struct layout and the cache…

How did AMD Ryzen get 50% faster in two years?

How many strings can you create per second?

Why CAFEBABE?

Union vs sum types

The Engineering Manager’s Guide to Emotional Tolerance

KDE at 30: What Are the Colored Blobs Telling Us?

Choices, improvements, and caveats

30 years of KDE history

Looking a bit closer

KDE Frameworks

KDE PIM

Plasma

KDE Linux

Conclusion

Web Review, Week 2026-38 — The Graz Edition

25 Years of Mass Surveillance Is Enough

What kind of Software should we fund?

Inside ‘Project Lily’: The Humans Reading Your ChatGPT Chats

‘Doom Loop’: OpenAI and Microsoft Admits LLMs Are Destroying the Web and Built on Theft

Be alert: targeted attacks on prominent Rustaceans

what if my git host were a static site generator?

A Design Space Exploration of Async/Await

How fast is C++23’s std::flat_map?

C++26: Trivial infinite loops are no longer undefined behaviour

How to Recognize a Change in Capacity to Stop Pressure

Clear as Mud

Proper English is a Myth: There’s No ‘Correct’ Way to Write

Web Review, Week 2026-37

Making Social Media Social

Automattic CEO Matt Mullenweg Put on ‘Leave of Absence’

Doomscrolling ourselves to death

Tristan Buckmaster’s statement on the Navier-Stokes resolution

The function of LLM-based math “proofs”

Soft-deprecating re.match()

A quick overview of atomics in C

Visualizing Rust’s Vtables: How dyn Trait Works In Memory

My HTML Boilerplate

There’s No Limit to How Bad Code Can Get

On Quality: What It Is and Why Products Get Worse

Degeneracy is a Symptom

The Last Person to Know the Dictator Is Screwed Is the Dictator

When Death Was a Relief

Web Review, Week 2026-36