Programming language generations

When I was young, I learned about a model of classifying programming language: the system of programming language generations.

In this model, first generation programming languages are, basically, where you program the computer in the language that is defined by its architecture. On a Von Neumann machine, with its load-and-store architecture, you do that by inputting a string of numbers. The first programmer in human history -- her name was Ada Lovelace -- wrote in a first-generation language. 1GLs aren't so much invented as they are a byproduct of the computers for which they're created.

Second-generation languages are the assembler languages. Because humans are not computers, and because decoding long lines of numbers to understand what the computer is doing, when programming became a full-time job, the programmers that did it decided that doing all this assembling manually is too complicated, so they quickly wrote assemblers to automate the process for them. They still could understand the 1GL output of the 2GL assembler, but most of them quickly forgot how to write software in a first-generation language. Not that anyone cared, as the translation from a 2GL to a 1GL is lossless and you can just revert it.

Third-generation languages are higher-level languages. When the first 3GLs were invented (such as COBOL and, more famously, FORTRAN) in the late 1950s and early 1960s, it was believed by some that the work of programming a computer so accessible to non-programmers that the job of programmer would eventually cease to exist, and people would just ask the computer what they needed by entering COBOL instructions. This of course was ridiculous and incorrect, because converting algorithms to computer instructions, whether at the 2GL or 3GL level, is a specialized skill that some automation can perhaps make simpler but never completely take away the need for. At the time, some people also felt to some extent that using 3GL wasn't the same thing as actually programming 3GLs, but eventually the world moved on and embraced things. The invention of 3GL environments reduced, but did not completely take away, the need for people to understand 2GLs, as compiler and operating system authors still need to understand them, and some highly optimized code still continues to be written in 2GLs to this day.

Fourth-generation languages abstract away some or all of the process of programming. For instance, a database-related 4GL will hide away the complexities of storing data in particular locations, how to fetch that data, how to index it such that you can fetch it efficiently, how to loop over the data to get you a summary of that data, and instead allows you to express the required information in an abstract way, expecing the computer to fill in the blanks. When SQL, an early 4GL, was invented, some people believed that the language made accessing databases so simple that the requirement to implement database applications would eventually cease to exist and we would just hand SQL prompts to users who need to access data. This of course was ridiculous and incorrect, because understanding data schemas and using that understanding to query data from a database is a specialized skill that perhaps a higher abstraction can help you make simpler, but that in the longer run it can never completely take away the need for. The invention of 4GLs also reduced, but did not completely take away, the need for people to understand how to do the things that the 4GLs automate for you manually, as the people who do write those things still need to understand them, and there are also environments where these particular 4GLs are rather not appropriate or just very slow.

The first definition of programming language generations that I read about in the 1980s simply stated that fifth-generation languages did not yet exist, but that they would in the future, and that in those, you would "tell the computer what to do, and it would then do that". Now that we have a way of doing so, it could be said that by some definition, we now actually do have a number of 5GLs. The existence of these LLM systems has caused some, especially the people who build and exploit these systems, to exclaim that programming as we know it today is going to cease to exist, and everyone will just ask an LLM to generate a program, which will then do so. That is of course ridiculous and incorrect, as no automaton can generate software from nothing; input is still required for the model to be able to produce something that approaches usability, and being able to word that input in a correct and productive fashion will be a skill that future programmers can benefit from. I ran some experiments a while back, and from that concluded that, if we look only at the technical side, LLM use can, in some niches, increase productivity for a programmer. There are certainly things that you shouldn't use an LLM for, but equally there can be cases where use of an LLM to perform some task that traditionally would have been done by a programmer would be a net positive.

But LLMs, as they exist today, are highly problematic.

They require vast amounts of data to build the model. The companies that build these models are disrespectful of people who run web services, and as a result, everyone now has to implement various types of application firewalls just to not make systems fall over from the overwhelming requests for data. They are also disregarding the licenses that are attached to these vast amounts of data, which makes me, as a person who believes in the tenets of free software, sad.

They require vast amounts of energy, causing an already-critical global warming crisis to, well, not improve.

They require vast amounts of coolant to dissipate the energy concentrated in their data centers, causing further environmental effects.

In this, they are problematic and to be avoided. But these are side states of the current state of affairs; I do not believe that they are inherently implied to be able to build and operate an LLM -- any LLM.

I guess it's fair to say that my feelings towards LLM usage are complex and many-faceted. I haven't been involved in many debates about the subject, debates that to me seem to be mostly focused on "LLM good" vs "LLM bad" arguments that aren't as nuanced as the position that I would believe is more accurate. This is not because I don't care, but partially because I've been busy in my personal life recently and partially because the whole thing seems somewhat disheartening.

But then Debian popped up GR 2026-002, meaning, I now have to come up with an opinion about various candidate statements in the context of the above, which is... not easy. But I did it anyway.

There are 8 choices on the ballot, and they all have some truth and some falsehood to them. My position about LLMs can be summarized as:

• The current state of affairs wrt LLMs is disastrous and we should not encourage them
• However, there's no technical reason why this must remain true for all time
• And so any statement should keep in mind what might happen in the future and that the current disastrousness of the whole thing isn't guaranteed to continue to exist for all eternity.

With that, let's go over them.

GR vote options

Proposal A

Its summary, from the GR text:

This proposal aims to expressly forbid any contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools.

This falls squarely in the "LLM bad" camp, outlawing all generative-AI contributions, disregarding potential future ones where the problematic situations that exist today are not present.

It makes a change to the social contract, which is especially difficult to reverse (on purpose), and which therefore also will require a 3:1 supermajority, but if we want to ban LLM-assisted contributions, this is probably the best way to do it.

Proposal B

This one tries to allow AI-assisted contributions under certain conditions. It's mostly an "LLM good" proposal, with some caveats that can be discribed as "make sure you know what you're doing".

Proposal C

This proposal is both a weaker (in some places) and stronger (in other places) version of Proposal A. It makes changes to the code of conduct instead of to the social contract, and it also wants to, at least, suggest policy to parties beyond the Debian project. By not changing the social contract, however, it is more likely to reach its simple majority requirement than proposal A.

I don't think the language that it wants to add to the code of conduct is particularly well phrased, however.

Proposal D

This is a weaker form of proposal B. The language is more compact and there are a few requirements that are spelled out in proposal B that are not spelled out in proposal D, but if you read between the lines you'll see that the requirement is still there really and I don't understand why proposals B and D were not merged into one.

Proposal E

This proposal tries to hold a middle ground between "LLM good" and "LLM bad". It appreciates that things are quite muddled at the present time, and that perhaps the situation might might change in the future. It acknowledges that certain questions remain unanswered and that perhaps future considerations might therefore be different. But it essentially refuses to take a stance on whether LLMs should be accepted by the project or not.

Proposal F

Similar to proposal E, this proposal tries to discourage Debian contributors from using LLMs, while still allowing people to use it should they want to, but with some requests and requirements to mark LLM-assisted contributions to account for those people who don't want to interact with LLM-generated software. As such, it is a proposal similar to proposal E that leans closer to the "LLM bad" camp.

Proposal G

This proposal aims to ensure that contributions directly to Debian are created by humans, while at the same time avoiding restrictions on the tools those humans may choose to use when contributing

Another "LLM bad" proposal, it however restricts the "bad" bits to only the direct output of the LLM. If you use an LLM to do something and then clean-room re-implement the same thing yourself, that's apparently fine.

Proposal H

This proposal condemns the use of LLM for its environmental and moral problems, but explicitly not for its technical considerations. I feel that it is closest to my position as explained above.

Voting

Expressing a vote on a ballot so convoluted and complicated like this one takes time. I have to read and understand every ballot option, and formulate an order of them.

And I shouldn't just state which option has my preference; Debian's voting process allows a rich expression of opinion on ballot options.

Anyway, I eventually ended up voting in a way that I think is consistent with my opinion. But it wasn't easy.

I’ve found my ideal format for shipping apps for personal & family use: PWAs, with an offline-first focus, rendering (mostly) entirely client-side. JavaScript is powerful enough to do pretty much anything these days - especially if you don’t have to write the code yourself.

If AI can generate an application from a description, is software still worth anything?

I have lived with a version of that question longer than most.

I released Drupal for free more than twenty-five years ago, and later co-founded Acquia, which has grown into a large enterprise software company built around Drupal.

Granted, Drupal is free in a different way than AI-generated applications are free, but I'm not sure that changes the basic question of how to build a successful business around either one.

Open Source made code abundant by giving people broad rights to use, modify, and redistribute it. AI is lowering the cost of producing code. One lets you copy the software; the other makes it cheaper to recreate software.

Free code changes what customers pay for

Because anyone could use Drupal for free, Acquia could never build a durable business around access to the code. From the start, we had to make money another way.

We built that business around helping enterprises build, run, and manage Drupal applications throughout their lifecycle. That includes hosting, but goes well beyond it: the tools and services needed to develop, deploy, secure, scale, monitor, and improve applications in production.

Proprietary SaaS typically bundles access to the application with the hosting and operations required to run it. With Open Source, organizations can run the software themselves or choose who hosts and operates it.

As AI makes applications cheaper to recreate, the traditional SaaS bundle of software and operations comes under pressure. Customers may become less willing to pay for access to application functionality without becoming any less willing to pay to run and manage applications in production. For Open Source businesses those economics are not new.

Dependability becomes the product

Software can be free, or nearly free, without becoming cheap to depend on. The more people and organizations depend on a system, the more of its value comes from operating it securely, reliably, and at scale.

Once people depend on an application, the cost of its failure has little to do with how much it cost to build. An application that costs $1,000 to build can still cause a $10 million failure.

As AI makes enterprise applications easier to create, adapt, and integrate, they still have to be deployed, secured, scaled, monitored, and run reliably over time. As software cost comes down, dependability becomes a differentiator.

Linux is abundant; dependable cloud infrastructure is a service worth paying for. Drupal is abundant; dependable digital experience infrastructure is a service worth paying for.

Acquia has lived with those economics for nearly 20 years. Drupal made the code abundant, so we built our business around helping organizations build, run, and improve what they created with it. As AI makes code cheaper to generate, that business model may start to look a lot less unusual.

Either way, more software companies will have to answer the same question: if code and capabilities are abundant, what are customers really paying you for?

L’onanisme des utilisateurs de chatbots

Quand bien même les chatbots ne seraient pas les produits de gigantesques entreprises centralisées qui cherchent à nous exploiter en pourrissant nos cerveaux et Internet tout en étant une catastrophe écologique et sociale, je ne les utiliserais pas.

Quand bien même l’outil serait éthique à tous les points de vue, je le détesterais !

Le guitariste et le joueur de Guitar Hero

John Scalzi explique enfin pourquoi je n’aime pas ça. Parce que ç’est littéralement une perte de temps, un jeu vidéo qui ne sert à rien.

• Generative “AI”: The Guitar Hero of Creativity (whatever.scalzi.com)

Il prend l’analogie de Guitar Hero : oui, c’est fun. Mais, fondamentalement, c’est inutile. Vous n’apprenez rien ! En demandant à un chatbot de répondre à une question, de produire un texte ou une image, vous n’avez littéralement rien appris. Les études le montrent : un étudiant qui répond à une question d’un prof en utilisant ChatGPT est incapable de répéter cette réponse quelques minutes plus tard. L’investissement intellectuel est nul. L’étudiant est comme une interface transparente entre le chatbot et le prof.

Je l’ai vécu lors d’un examen où j’avais autorisé l’usage de l’IA : un étudiant a été incapable de répondre à une question alors que la réponse était affichée sur son écran.

• Giving University Exams in the Age of Chatbots (ploum.net)

Mais, comme Guitar Hero, jouer avec un chatbot est amusant, voire addictif.

Je le comprends très bien. J’ai pris une demi-heure pour jouer avec la génération d’images de Lumo, le chatbot de Proton. Je lui ai demandé une couverture de Bikepunk et j’ai itéré en notant les défauts. J’avais plein de choses à dire sur l’output (notamment que, quoi qu’on fasse, une jeune femme à vélo doit obligatoirement porter un crop top). C’était très marrant de voir que quand j’ai précisé que je voulais que le personnage masculin ressemble à Thierry Crouzet, il a soudainement acquis une musculature impressionnante. Ce n’est pas que Thierry n’est pas musclé en vrai, mais, quand même, j’évite d’éternuer trop fort dans sa direction.

Et là, vous voyez le truc : c’était amusant. Ça me donnait envie de partager les différentes images.

Mais, en réalité, quand on n’est pas dans le délire, c’est juste nul. C’est comme regarder un pote jouer à Guitar Hero : il s’éclate, mais c’est un peu emmerdant pour le public. Voir c’est gênant. Un peu comme si vos amis vous racontaient à quel point leurs dernières séances masturbatoires étaient jouissives.

L’utilisation de l’IA est un plaisir solitaire. Je n’ai rien contre le fait que ça vous amuse, mais, par pitié, ne le partagez pas avec moi !

On ne gagne pas du temps en poussant sur un bouton

Les gens disent gagner du temps avec l’IA, mais ils n’améliorent pourtant pas leur productivité. Le paradoxe viendrait que le temps pris à utiliser l’IA lui-même ne serait, intuitivement, pas pris en compte.

• AI Isn’t Breaking Work. It’s Already Broken. (calnewport.com)

C’est un paradoxe bien connu des bons managers : le management prend du temps et de l’énergie. Souvent plus que faire les tâches soi-même. Si tu engages un jardinier pour tondre ta pelouse, tu dois trouver le jardinier, le contacter, convenir d’un rendez-vous, négocier un tarif puis, une fois qu’il est là, lui expliquer le travail, vérifier qu’il a bien compris et puis vérifier qu’il a fait tout correctement.

Outre l’argent que ça coûte, cela n’est clairement pas une tâche anodine. En fait, si c’est juste pour faire une seule fois un petit jardin, c’est beaucoup plus rentable de tondre ta pelouse toi-même. Le bénéfice ne se fait sentir que lorsque tu as confiance et que tu as un accord pour que le jardinier vienne une fois par mois tondre une grande pelouse, sans même avoir besoin de te prévenir.

Les jeunes parents connaissent tous cela : junior veut absolument aider au montage du meuble Ikea, mais, honnêtement, ça te prend cinq fois plus de temps que de le faire tout seul.

On en est là avec l’IA. Parfois on gagne un peu de temps (une vraiment grande pelouse à tondre), parfois on en perd (l’armoire Ikea), mais l’attrait de la nouveauté fait que c’est fun. Un peu comme le fait de regarder un jardinier travailler depuis son salon en lui donnant des ordres. Cela donne un sentiment de puissance. C’est littéralement masturbatoire.

Le problème c’est que la rentabilité à long terme de notre jardinier se base sur le fait de créer une confiance, un automatisme. Et là, on est face à une entreprise de jardinage qui a un monopole mondial, qui augmente ses tarifs arbitrairement et envoie, à chaque fois, un nouvel ouvrier qui ne connait pas votre jardin, mais fait semblant du contraire. En plus, il est sous ecstasy.

Vos outputs de chatbots sont de la pollution

Mon principal grief, c’est que les utilisateurs des chatbots sont persuadés d’avoir une compétence ou une valeur ajoutée quelconque. J’en ai été témoin de première main : les projets open source sont noyés de contributions générées. Souvent, les utilisateurs sont de bonne foi : ils ont réellement trouvé un bug et plutôt que de le rapporter, ils demandent à un LLM de générer un patch.

Parfois, ils poussent le vice jusqu’à faire écrire le rapport de bug par le LLM. Ils sont très fiers.

Fier de quoi ? D’avoir cliqué sur l’icône Claude ou ChatGPT ?

Et c’est une catastrophe : parce que le mainteneur doit désormais tenter de comprendre dans tout ce charabia et ce jargon quel est le problème de base. Au lieu d’avoir un utilisateur qui se plaint, parfois un peu maladroitement, nous sommes face à une machine qui réinterprète tout et il faut deviner ce que l’utilisateur avait en tête. En gros, il faut essayer de déduire le prompt.

Ce n’est déjà pas évident de se comprendre entre humains en communication directe alors si un chatbot sert d’intermédiaire…

Ou cette connaissance à qui je pose une question et qui m’envoie la réponse de ChatGPT. Comme si c’était d’une aide quelconque. Parce que si je demande quelque chose à quelqu’un, c’est vraisemblablement parce que je ne trouve pas de réponse facile et que je pense que cette personne a une expertise du domaine. Me renvoyer la réponse de ChatGPT est à la fois injurieux (tu n’en as rien à foutre de m’aider) et hautain (tu penses que je ne suis pas capable de faire une recherche Web).

Que ce soit clair : un output de chatbot n’est pas fait pour être partagé. Si vous souhaitez le faire, alors partagez juste le prompt, ce sera beaucoup plus efficace.

De plus en plus d’artistes professionnels se plaignent : plutôt que d’avoir des instructions claires, les clients leur envoient des « idées » générées par IA. Et les artistes doivent deviner ce que veulent leurs clients.

Le chatbot, c’est comme la masturbation : pratiquez-le seul ou dans un cercle restreint d’adultes consentants. Jamais en public. Jamais en présence de personnes non consentantes. Jamais dans un cadre professionnel.

Apprendre de ses expériences

Mais le principal problème, outre l’opacité de la communication, c’est ce que dit Scalzi avec Guitar Hero ou comme le montre l’analogie de la masturbation : vous n’apprenez rien.

Vous ne saurez pas jouer bon anniversaire à la guitare même après des centaines d’heures de Guitar Hero. Vous ne rencontrerez jamais un partenaire amoureux en vous masturbant. Ce n’est pas un jugement de valeur : c’est juste que ces activités n’ont pas le moindre rapport entre elles !

L’énorme majeure partie des patches que je reçois pour mes projets Open Source me prennent plus de temps à relire et à intégrer que si je le faisais moi-même. Pourtant, j’apprécie cela, car je sais que la personne a dû fournir un effort pour comprendre mon code. Elle a appris. Et, petit à petit, elle va être de plus en plus à l’aise pour faire des changements plus importants tandis que moi, j’aurais appris à lui faire confiance. Je peux également poser des questions sur les choix techniques qui ont été faits, en discuter, remettre en question mes propres perspectives, mes propres choix.

Accepter un patch n’est jamais un gain de temps, c’est un investissement sur le futur. C’est également une manière de faire grandir deux personnes.

Ce qui n’est pas le cas avec les patchs générés. C’est même exactement le contraire : accepter un patch généré va introduire dans le projet du code qui fonctionne peut‑être aujourd’hui, mais que personne ne comprend et, surtout, dont on ne peut même pas présupposer qu’il a une logique.

Si vous n’avez rien appris en utilisant un chatbot et si la personne qui reçoit l’output n’apprend rien, pourquoi le faire tout court ?

Un tas de débris aléatoire n’est pas une maison

Vous vous souvenez de l’expérience de pensée qui dit que si on assied assez de chimpanzés qui tapent aléatoirement sur des machines à écrire, on va finir par générer du Shakespeare ou du Proust ?

Et bien c’est exactement ce que font les chatbots avec le code : ils génèrent presque aléatoirement des morceaux de code jusqu’à ce que le code en question réponde superficiellement à la question. Ça fonctionne, parfois, ici et maintenant, mais, bien entendu, ça va craquer de partout dès qu’on bouge quelque chose.

Un peu comme si on construisait une maison en jetant aléatoirement des poutres et des briques jusqu’à ce que, ô miracle de la loi des grands nombres, l’édifice de matériau dégage un espace assez grand pour qu’on l’appelle "chambre" avec une ouverture appelée "porte". Ce serait cool.On prendrait des photos.

Mais pensez-vous sérieusement que cette "maison" tiendrait face à la première pluie, au premier souffle de vent ou à la première vibration d’un camion sur la route ?

De la même façon, communiquer par écrit est une compétence qui se travaille. C’est même plus important que cela : l’écrit permet de structurer ses propres pensées. Tant que vous n’avez pas écrit vos idées, elles ne sont pas réelles, pas claires.

Tant que vous n’avez pas fixé votre idée sur un support, elle ne vaut rien. Et si ce n’est pas vous qui la fixez, ce n’est pas votre idée.

• Votre idée ne vaut rien (ploum.net)

En déléguant l’écriture de vos emails et de vos rapports, non seulement vous perdez la compétence communicationnelle, mais, pire, vous perdez simplement vos idées.

Les singes bientôt remplacés ?

Dans le cliquetis des milliards de machines à écrire actionnées par les singes, une feuille tomba soudainement sur le sol. Un entrepreneur s’en saisit et lut : « Longtemps, je me suis couché de bonne heure… »

— Ça y est, hurla-t-il ! Nous avons réussi ! Ce singe écrit du Proust !

Le singe en question fut mis sur un piédestal, choyé, dorloté. Mais les entrepreneurs avaient beau faire, il n’écrivait plus que du charabia sans signification.

— Dommage, fit un entrepreneur. Peut-être n’est-ce pas la bonne approche.
— Et si nous remplacions les singes par des utilisateurs de ChatGPT ?
— Pas bête. Statistiquement, ça devrait fonctionner…
— Et puis, on ferait des économies de bananes !

L’arnaque du bilan carbone

Pourquoi nous nous sommes fait avoir dans notre soi-disant lutte contre le réchauffement climatique

Ne plus prendre l’avion, acheter des électroménagers de moindre consommation ou se déplacer en voiture électrique semblent être les mesures antiréchauffement climatique dont j’entends le plus parler. Ça et guillotiner les milliardaires qui voyagent en jet privé. D’ailleurs, les estimateurs de bilan carbone pullulent.

Mais je suis de plus en plus convaincu que c’est une grossière erreur. Nous sommes en train de compter nos grammes de CO₂ produits et cela a probablement autant d’impact que faire pipi sous la douche. Cela nous occupe pour nous donner l’impression de faire quelque chose tout en permettant aux politiciens de ne surtout rien changer.

Comprendre le réchauffement climatique.

Revenons à la base. Il existe sur la planète une quantité fixe de carbone qui est invariable (on peut oublier les très rares apports de météorites). De ce carbone, une grande quantité est prisonnière dans le centre de la terre dont elle s’échappe parfois lors des éruptions volcaniques. Mais simplifions et oublions cela.

Nous avons donc une quantité de carbone fixe pour la surface et l’atmosphère, que j’appelle « le système surface ».

Il y a des milliards d’années, il n’y avait pas d’oxygène dans l’atmosphère, mais énormément de gaz carbonique. L’abondance de CO₂ a permis une explosion de la vie, principalement le plancton, extrayant le carbone de l’atmosphère grâce à la photosynthèse. Mais la photosynthèse produit un déchet éminemment toxique pour beaucoup de formes de vies : l’oxygène !

Cette période porte le nome de « Grande Oxydation ».

• Grande Oxydation (fr.wikipedia.org)

Heureusement, ce processus ayant eu lieu sur des centaines de millions d’années, des formes aérobiques ont eu le temps d’évoluer, formes de vie qui survivaient grâce au processus inverse : consommer de l’oxygène et produire du CO₂ Nous faisons nous-mêmes partie de cette forme de vie. Nous devons donc ingérer du carbone, via l’alimentation, afin de le brûler avec de l’oxygène pour produire de l’énergie et expirer le déchet, le CO₂

Un point particulièrement important est que la somme du carbone de la surface et du carbone de l’atmosphère n’est jamais modifiée. S’il y a plus de plantes et de planctons, le carbone est fixé sur la surface et dans les océans. S’il y a plus d’humains et d’animaux, il y a un peu plus de carbone dans l’atmosphère. Mais la somme des deux reste constante.

Lorsqu’un être vivant meurt, quel qu’il soit, son carbone est soit rendu à l’atmosphère via la décomposition (qui est une forme de combustion), soit intégré à un autre être vivant via l’alimentation.

La fossilisation du carbone

Une troisième voie est cependant possible. Lorsqu’un « cadavre » s’enfonce dans le sol ou dans un fond marin, son carbone est comme capturé par la planète. Il ne peut plus rejoindre l’atmosphère ni être consommé. Avec le temps et les très hautes pressions, ce carbone se fossilise.

Les plantes fossilisées deviennent essentiellement du charbon tandis que les autres formes de vie, principalement les espèces de planctons, se transforment en hydrocarbures : pétrole et gaz fossile (aussi appelé « gaz naturel »).

Le point le plus important de cette fossilisation est qu’elle a retiré énormément de carbone de la surface. Au fil des milliards d’années, le taux de CO₂ de l’atmosphère a donc chuté de manière extrêmement importante, entraînant un refroidissement climatique. Le CO₂ a en effet la propriété de « capturer » la chaleur du soleil comme le ferait une serre. Cette particularité du CO₂ a été mainte fois observée et prouvée depuis la moitié du 19e siècle.

• Eunice Newton Foote (fr.wikipedia.org)

Avec moins de CO₂ dans l’atmosphère, la terre s’est lentement refroidie, au détriment de certaines espèces, mais au plus grand bonheur d’autres dont l’Homo Sapiens Sapiens. Le « lentement » est important. On parle de dizaines de millions d’années.

L’extraction du fossile

Le grand malheur de notre espèce est que, depuis la révolution industrielle, nous avons découvert que ce carbone fossile brûle très bien. C’est donc un formidable réservoir d’énergie, de joules, que chacun veut exploiter. En fait, on sait depuis longtemps qu’il brûle bien, mais les réserves étaient inaccessibles : il fallait plus de joules pour extraire du charbon que ce qu’il produisait en brûlant. L’invention du moteur à vapeur va changer la donne et permettre l’industrialisation des mines de charbon puis des puits de pétrole (relisez « À l’ombre des derricks »).

Comme me le disait Philippe Samyn, le Joule est l’unité qui fait tourner le monde. Et le carbone fossile en est une fameuse réserve.

• Qucocoma Philippe Samyn ? (ploum.net)

Mais, en brûlant ce fossile, nous remettons en circulation dans l’atmosphère du carbone qui était séquestré depuis des millions ou des milliards d’années.

Le changement climatique est bel et bien humain, la question ne devrait même pas se poser vu que chaque puits de pétrole, chaque mine de charbon et chaque gisement de gaz n’a, au fond, qu’une seule utilité : remettre dans l’atmosphère du carbone qui n’y était plus depuis des milliards d’années.

J’espère que cette explication cloue aussi définitivement le bec aux idées absurdes comme le fait que les cyclistes contribuent également au réchauffement climatique en respirant et en mangeant des côtelettes. Que vous mangiez un steak ou une salade de pois chiche, tout le carbone que vous consommez était encore dans l’atmosphère il y a quelques jours. Vous n’ajoutez aucun atome au système de la surface. Par contre, allumez la flamme d’un briquet et vous êtes littéralement en train d’envoyer dans l’atmosphère du carbone qui n’y était plus depuis des milliards d’années.

Ce billet est également la réponse à l’idée parfois entendue que cette recarbonisation serait « naturelle ». Il a fallu des milliards d’années pour capturer ce carbone que nous relâchons presque totalement en moins de 200 ans ! C’est 10 millions de fois plus vite ! Aucune adaptation du vivant ne peut se faire à cette vitesse !

Le renouvelable est-il la solution ?

Intuitivement, vous vous dites qu’il suffit de ne pas utiliser de briquet et de passer à une énergie dite « renouvelable », des joules propres produits sans carbone fossile. Qu’il faudrait consommer « intelligemment » pour savoir combien de grammes de CO₂ ont été produits pour tel ou tel objet.

Mais c’est à la fois très compliqué à calculer et complètement inutile.

Tout l’effort pour passer vers le renouvelable se base sur la théorie (essentiellement fausse dans le monde réel) de l’offre et la demande en se disant que « si le renouvelable devient moins cher, les gens n’achèteront plus de pétrole et les puits ne seront plus rentables et donc se fermeront ».

Cela permet aux néolibéraux de se déclarer écologistes, mais c’est évidemment complètement et dangereusement faux. À l’heure actuelle, la moitié du pétrole extrait sert à déplacer l’autre moitié jusqu’aux pompes ou aux centrales tout en restant l’un des produits les plus rentables du monde !

Tout le pétrole, charbon et gaz déjà extrait sera consommé, quoi que vous fassiez. Une fois extrait, le carbone fait littéralement partie du système de la surface. À moins d’arriver à convaincre 100% des humains de ne plus utiliser de pétrole ou de charbon et de laisser intactes les réserves mondiales, ce dont je doute fort, il sera brûlé. Même si le pétrole devenait soudain beaucoup trop cher, il serait revendu à perte (vu que déjà extrait). Et il restera toujours un atout stratégique essentiel des armées, ce qui lui confère une valeur intrinsèque importante (le jet supersonique, le missile balistique et le char d’assaut sont difficilement imaginables en version électrique).

La seule mesure réaliste et efficace pour lutter contre le réchauffement climatique est d’arrêter l’extraction de carbone fossile. Point à la ligne. Tout le reste n’est que poudre aux yeux malhonnête ou confondante naïveté.

Entendons-nous bien : toutes les mesures « écologiques » sont généralement positives et procurent bien des avantages (moins de particules fines, moins de pollution dans les océans ou les sols …). Je les encourage fortement. Mais, quand on parle du réchauffement climatique, elles nous distraient de l’essentiel.

Capturer le carbone

Planter des arbres, c’est pas mal. J’aime beaucoup les arbres. Cela permet de modifier l’équilibre sol/atmosphère, ce qui est toujours appréciable. Mais il faut en planter beaucoup et s’assurer qu’ils ne brûlent pas. Même avec beaucoup d’arbres, le carbone fait désormais partie de notre cycle de surface !

Prétendre que planter des arbres contrebalance l’extraction fossile est une escroquerie pure et simple, car, en pourrissant ou en brûlant, le carbone de l’arbre va bientôt revenir dans l’atmosphère. Et quand bien même c’est utile, le mécanisme économique des certificats de compensation carbone est une arnaque qui entraîne plus d’émissions !

• Les mécanismes de compensation carbone expliqués à mon hamster (ploum.net)

C’est également la raison pour laquelle les tentatives d’extraction industrielles du carbone de l’atmosphère sont vouées à l’échec. Il faudrait non seulement extraire plus de carbone qu’on en produit, mais aussi arriver à le fossiliser, à faire en sorte que celui-ci ne puisse plus jamais revenir dans l’atmosphère.

Certains imaginent capturer le carbone dans le béton de constructions, mais l’échelle est ridicule par rapport à la quantité de carbone fossile qui est extraite à chaque seconde. Et, au fond, mettre du carbone dans nos constructions, ça s’appelle des planches en bois. Mais comparez cela avec la quantité de barils de pétrole extrait à chaque instant.

De nouveau, on tente de se distraire, d’imaginer toutes les solutions les plus absurdes les unes que les autres. Toute sauf la seule réelle : arrêter l’extraction.

Parce que je ne vois pas d’autres solutions

Il suffira de quelques jours froids cet hiver pour faire oublier les canicules de 2026 et entendre les habituels poncifs sur le déni du réchauffement climatique. Et puis, quand bien même le sujet reviendrait dans l’actualité, les militants accuseront les jets privés et les politiques annonceront une prime pour l’installation de panneaux photovoltaïques. Les geeks se rassureront en achetant un smartphone « éthique » avec un chiffre arbitraire de grammes de CO₂ sur la boîte (qui est bien, car entouré en vert).

Il n’en reste pas moins que chaque litre de pétrole, chaque kilogramme de charbon extrait contribue au réchauffement climatique. Que les entreprises qui se livrent à cette activité sont criminelles, que leurs cadres devraient être traduits en justice pour tous les morts et toutes les catastrophes climatiques. Bref, pour crime contre l’humanité.

Les états devraient en prendre la mesure et interdire toute importation de produits issus de l’extraction du carbone fossile.

C’est la seule solution réelle si nous voulons efficacement ralentir puis stopper le réchauffement climatique. Il n’y a pas de demi-mesures possibles. Et, en plus, c’est techniquement assez simple. Il « suffirait » d’une résolution de l’ONU suivie d’un Nuremberg du climat.

Mais, franchement, vous y croyez vous ?

Vous connaissez un seul politicien qui pourrait être élu avec cette idée ?

Alors on va aller faire pipi sous la douche en tentant de se convaincre que la fameuse parabole du colibri n’est pas une pure intoxication néolibérale pour rejeter la culpabilité d’une catastrophe planétaire sur les choix de consommation de l’individu.

Je suis sans cesse tiraillé entre l’idée qu’il faut que je produise moins de CO₂ et la certitude que, de toute façon, cela ne sert à rien : tout carbone fossile extrait sera bientôt dans l’atmosphère, que ce soit demain ou dans dix ans.

Il n’y a pas de bilans carbone honnêtes. Il n’y a que le carbone de surface et le carbone fossile. Si nous ne condamnons pas rapidement et durement ceux qui extraient le carbone fossile, le trou qu’ils sont en train de creuser sera la tombe de l’humanité…

• Photo d’un puit de pétrole en feu au Koweit par Habib Hassan Kuwait

This is the third post in a series about making my site's search available to AI agents. First, I published an API Catalog, which helps agents that already know to check my site find its search API. Second, I added an Agentic Resource Discovery (ARD) entry so my search can be indexed by "AI registries" (think search engines for AI agents).

So far, no agent has found my search on its own. The API Catalog has been a published IETF standard for over a year but I found no evidence that either OpenAI or Anthropic checks for it. ARD is newer, still a v0.9 draft, and I found no evidence that OpenAI or Anthropic supports it either.

In the meantime, what does work is a custom Agent Skill that points my AI assistants to the API Catalog, which leads them to my OpenAPI description and from there to the search itself. If and when agents adopt one or more of these discovery standards, I might be able to drop the skill and have it all work automagically.

Until last week, I had decided Model Context Protocol (MCP) was not worth implementing for my search API endpoint. It required an initialization handshake and could involve protocol-level sessions. My search doesn't need either: every query is stateless and anonymous. MCP felt like overkill for my simple use case.

The 2026-07-28 revision changed my mind because both the protocol-level session and the initialization handshake are gone. Every request can now be self-contained, which means that, for a service like mine, an MCP server is basically a POST route that returns JSON.

So I went ahead and implemented MCP support for my search endpoint. The whole thing came to one route and three small RPC methods: fewer than 150 lines of code, excluding tests.

You can call it from any terminal

In my testing, adding my site as a custom MCP connector to Claude Desktop, Claude Code, or ChatGPT still fails. These clients don't support the new protocol yet, which is understandable because it is only a week old. Once they catch up, anyone will be able to add dri.es as a connector, not just me.

Until then, an easy way to talk to my site with an MCP client is Simon Willison's mcp-explorer. You can run it with uvx, which comes with uv:

uvx mcp-explorer list https://dri.es/mcp
uvx mcp-explorer call https://dri.es/mcp search -a q "open source"

The first command prints the tool's name, description, and arguments. The second runs a search across my posts and returns up to twenty results.

Alternatively, you can use the raw protocol by running this curl command from a terminal:

curl -s https://dri.es/mcp \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/call" \
  -H "Mcp-Name: search" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search","arguments":{"q":"open source"},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}' \
  | jq .result.structuredContent

Discovery and invocation are separate layers

Having implemented support for three new standards, the useful thing I learned is that they are not alternatives.

ARD handles discovery: it gives registries a standard way to index and search for services like mine. OpenAPI and MCP handle invocation by defining how agents can call and use those services.

So the choice is not ARD or MCP. It is ARD plus OpenAPI, or ARD plus MCP.

For an anonymous, read-only API like mine, I prefer OpenAPI. It was easier to implement and anything that can make an HTTP request can use it.

MCP becomes more attractive when you have services that involve multi-step interactions, authentication, or explicit application state.

Ultimately, agent and crawler adoption will decide. Time will tell, but my money is on ARD and MCP right now.

Un manifeste Offpunk

Ce texte est une traduction en français du Offpunk Manifesto rédigé par Arlon de Serra Grande et que j’ai co-signé

• An Offpunk Manifesto (English version)
• Versão em português

La révolution ne sera pas numérique

Alors que l’hyperconnexion apparait comme le symptôme d’un futur inéluctable, un timide mouvement semble prendre de l’ampleur : celui de la déconnexion volontaire et intentionnelle. L’adoption des « dumb phones » est en train de croître. Les appareils photo numériques font leur retour. Tout comme les cassettes audio et les machines à écrire… Il existe un mouvement pour se réabonner à la presse papier. Même le minidisc, vite oublié après le succès des lecteurs MP3, semble renaître de ses cendres.

Au début du siècle, Internet semblait être la dernière pièce pour mettre en place le fameux « village global » de Marshall McLuhan. Les ordinateurs, rares et chers (et donc parfois partagés) étaient des portails vers un autre monde. Les gouvernements consacraient beaucoup d’argent pour s’assurer que même les plus pauvres ne soient pas des exclus numériques.

Et nous y sommes arrivés ! Nous allons bientôt passer le cap de trois appareils connectés par humain, selon l’estimation du Cisco Visual Network 2020.

• Global_2020_Forecast_Highlights.pdf (www.cisco.com)

Le numérique est partout et considéré comme acquis. Que nous le voulions ou non, nous sommes tous connectés en permanence. Car nous ne nous connectons plus à Internet : nous y vivons sans plus jamais le quitter !

Comme si nous portions un uniforme, nous gardons toutes et tous notre téléphone dans notre poche pour travailler, pour vivre, pour aimer et sous l’oreiller pour dormir.

Le numérique a cessé d’être un outil pour devenir un environnement duquel on ne peut s’échapper. Autrement dit une prison.

« Préserver le non numérique n’est pas un retour vers le passé, c’est un devoir »
— Giulio Cavalli

Lorsque la connexion, même non nécessaire, devient obligatoire, la résistance ne consiste pas à détourner le système, mais bien à refuser tout simplement d’en faire partie.

Comme l’écrit l’auteur belge de science-fiction et développeur informatique Ploum, les punks de notre époque sont ceux qui osent vivre sans smartphone. Ce sont des « offpunks », comme je les appelle désormais.

• La complainte du technopunk ringard (ploum.net)

La connexion est une arme de guerre

La première conséquence de cette centralisation monopolistique de la technologie est que la fourniture d’un accès à Internet est devenue une arme de guerre. Lorsque les grandes puissances entrent dans un conflit, elles ne cherchent plus seulement à perturber l’approvisionnement en eau ou en énergie, mais également à couper l’accès à Internet ou à certains services en ligne. La Russie a utilisé plusieurs fois cette tactique contre l’Ukraine. Israël fait de même contre la Palestine.

Fin 2025, le juge français Nicolas Guillou de la Cour Pénale Internationale a perdu ses accès à plusieurs services en ligne américains, dont Airbnb, Amazon et Paypal. La justification de cette sanction prise par les États-Unis était que Nicolas Guillou avait signé un mandat d’arrêt contre le Premier ministre israélien Benjamin Netanyahu et son ministre de la défense Yoav Gallant, suite au caractère génocidaire des attaques israéliennes contre les territoires palestiniens. Les États-Unis sont pourtant l’un des seuls pays à soutenir les actions d’Israël au Proche-Orient.

La philosophie Offpunk est née de constatations simples, mais inconfortables : le monde numérique est fragile et notre vie sociale est intrinsèquement liée à notre environnement. Le corollaire évident est que nous ne devrions jamais dépendre entièrement de services propriétaires virtuels, car nous pouvons en être exclus sans préavis.

De nombreux exemples illustrent notre dépendance envers cette fragile infrastructure : le bug Microsoft qui a mis hors service des milliers de banques, de transports et de services critiques en 2024, le gouvernement brésilien qui a bloqué Twitter/X en 2024 ou la panne globale d’Amazon et Cloudfare qui a rendu une bonne partie des sites web injoignables fin 2025.

Lorsqu’un système est injoignable, que ce soit à cause d’une panne, d’une sanction politique ou d’une guerre, tout un univers virtuel disparaît purement et simplement. Vous n’avez aucun recours si le numérique connecté était votre seule option.

Après tout, une connexion permanente à haut débit n’est jamais garantie, spécialement dans les pays en voie de développement ou qui connaissent des troubles politiques. Même les pays riches et industrialisés ne sont pas à l’abri. À cause de sa politique de gestion de l’énergie, la ville de Sao Paulo, au Brésil, connait des coupures d’électricité fréquentes lorsqu’il pleut.

Dans ces pays, avoir un plan B « analogique » est une question de survie.

Le minimalisme numérique et l’Offpunk

Il ne faut pas confondre le mouvement « Offpunk » et le minimalisme numérique.

Le minimalisme numérique est une vision individuelle et autonome de la déconnexion, sans aucune remise en question des tendances sociétales et des structures de pouvoir.

Puisqu’une vie complètement déconnectée n’est plus possible, le minimalisme numérique tente de supprimer les aspects les plus addictifs et les plus envahissants de la connexion permanente.

Off, ma non troppo.

Mais ce dont nous avons réellement besoin c’est d’une possibilité de se déconnecter réellement, d’avoir le droit de vivre et de nous déplacer sans emporter avec soi un téléphone suffisamment récent, suffisamment chargé et avec un forfait suffisant pour être connecté 24h sur 24.

Dans "Digital Detox: The Politics of Disconnecting" (2020), Trine Syvertsen démontre comment la mouvance du minimalisme numérique contribue à un agenda néo-libéral qui fait endosser par les individus, comme l’utilisateur lambda d’un smartphone, la responsabilité de résoudre les problèmes structurels auparavant gérés par des institutions collectives. L’autrice identifie trois raisons principales qui motivent le minimalisme numérique, les 3 « P » : présence, productivité et vie privée. Les trois étant des motivations purement individuelles.

En d’autres termes, si vous avez l’impression de rater des moments importants de sociabilité, si vous n’êtes pas productifs dans votre travail ou vos projets à cause des notifications ou si vous n’aimez pas être espionné en permanence par les grands monopoles de la tech, c’est uniquement de votre faute, car vous n’avez pas assez d’autodiscipline. Ce n’est en rien lié à l’économie de l’attention, au capitalisme de surveillance et aux logiciels conçus pour être addictifs.

Ce déchargement de la responsabilité fait notamment partie de l’analyse de la société contemporaine par l’intellectuel germano-coréen Byung-CHul Han dans son livre « The Agony of Eros ». Il y dit notamment :

L’auto-exploitation est bien plus efficace que l’exploitation par d’autres, car elle donne une impression de liberté.

Un autre symptôme de ce déchargement des responsabilités sont les caisses automatiques et les distributeurs en libre-service dans les supermarchés, les banques voire les pharmacies. Le client doit désormais faire le travail des employés, le plus souvent sans aucune aide et pourtant sans payer moins cher. S’il y a une erreur dans le processus, c’est de toute façon le compte en banque du client qui sera débité, pas celui de l’entreprise.

Bien qu’initialement issue d’une tendance technophile, la mouvance Offpunk, au contraire du minimalisme numérique, promeut une déconnexion simple et sans prétention. Une déconnexion non excluante des activités sociales ou de l’exercice de ses droits de citoyen·ne·s.

Quand le minimalisme numérique voit la détox numérique comme un outil d’amélioration de la productivité, les offpunks envisagent la déconnexion comme une attitude anti-consumériste.

Définitions

Le mouvement Offpunk n’est pas un style de vie, c’est un positionnement par rapport à notre usage du numérique, une forme de quête de sevrage numérique collective qui explore les impacts sociaux et politiques de la déconnexion. Le mouvement tente de permettre aux individus de se réapproprier leurs loisirs, leur citoyenneté et leurs communications sans passer par un intermédiaire numérique incontournable. L’Offpunk ne s’oppose nullement à Internet ou à la technologie, il cherche juste à rendre possible une vie sans connexion permanente.

Dans son positionnement, Offpunk se rapproche plus des méthodes non dogmatiques comme la méditation ou les techniques de guérilla.

De plus, il est particulièrement remarquable que même les activités professionnelles traditionnellement analogiques, comme l’enseignement, soient de plus en plus envahies par le numérique. L’utilisation d’Internet est de plus en plus liée au travail et le terme même de « déconnexion » implique le loisir ou l’oisiveté.

En conséquence de quoi, la philosophie Offpunk défend le fait de vivre sa vie au sens large, au-delà de la séparation travail/vie privée.

Paradoxalement, toutes ces couches inutiles numériques dans notre vie quotidienne rendent l’interaction analogique et directe de plus en plus efficace ou confortable pour résoudre nos problèmes du quotidien (voir aussi la section « Instruments Offpunk »).

Offpunk embrasse autant l’adolescent qui achète un téléphone basique et rejoint un club luddite, un audiophile qui quitte Spotify pour se créer une collection de vinyles ou un lecteur MP3 hors-ligne, un expert qui utilise des systèmes de cybersécurité minimalistes. Le mouvement comprend également les militants qui luttent contre l’obsolescence programmée, qui installent Linux ou des ROMs dédiées sur des appareils normalement condamnés, un indépendant qui désactive Facebook et Instagram pour se concentrer sur ses clients directs voire une personne âgée qui refuse le smartphone pour effectuer ses démarches administratives.

Offpunk n’est pas de la nostalgie ! Ce n’est pas une technophobie naïve ou une idéalisation romantique d’un passé imaginaire. C’est, avant toute chose, la quête d’une indépendance et d’une souveraineté. Pour paraphraser Edouardo Fernandes :

La révolution technologique n’est pas révolutionnaire et se laisser dépasser n’est pas réactionnaire.

• Geriatria da tecnologia (textosobretela.com)

L’esthétique Offpunk

Offpunk n’a pas encore de visage, mais certains indices peuvent nous permettre de voir à quoi il va ressembler. La première vient d’une définition que donne Ploum de ses propres actions sur Internet : « Technopunk », un technophile antisystème.

• La complainte du technopunk ringard (ploum.net)

Comme mentionné plus haut, Offpunk est un positionnement envers la technologie contemporaine, pas une utopie/dystopie ou une esthétique visuelle culturelle, comme le sont les mouvements Solarpunk ou Cyberpunk.

Quelques exemples :

1) En informatique, le navigateur Offpunk, qui donne son nom à ce manifeste, et le protocole Gemini.

• Offpunk browser
• Project Gemini (geminiprotocol.net)

2) En design, le concept du « Forever Computer » ou le téléphone Mudita Kompakt.

• The computer built to last 50 years (ploum.net)
• Mudita Kompakt, a minimalist E Ink® phone. (mudita.com)

3) Dans la société, le New York Luddite Club

4) Dans la culture, le roman « Bikepunk » (2024) ou le film « One Battle After Another » (2025)

• Philosophie politique du bikepunk (distinguos.net)

Dans One Battle After Another, l’obsolescence, le « downgrade » est une stratégie pour conquérir sa liberté. Les personnages reviennent à des anciens appareils personnalisables pour créer un réseau de communication parallèle. Lorsque les nouvelles technologies apparaissent, comme le smartphone, elles ont pour objectif de mettre les personnages en danger, de les empêcher de réaliser leurs plans voire de les supprimer tout simplement.
— Edouardo Fernandes

Dans le film Germano-japonais « Perfect Days » (2023), on peut voir la routine idyllique de Hirayama, un nettoyeur de toilettes publiques à Tokyo, qui, dans son temps libre, prend des photographies, écoute des cassettes audio, se déplace à bicyclette et lit des livres avant de dormir. La particularité étant qu’il semble apprécier chaque moment de sa vie tout en étant totalement déconnecté.

Au Japon, un pays qui a toujours cherché l’équilibre entre la modernité et la tradition, on trouve encore partout des terminaux pour payer en espèce, des lignes téléphoniques fixes pour conduire la majorité des communications professionnelles et d’anciennes technologies encore utilisées par les plus grandes entreprises, comme le fax ou les disquettes.

En Inde, qui possède l’un des meilleurs réseaux téléphoniques du monde, un citoyen passe en moyenne 90 appels par jour !

Priorités du mouvement Offpunk

Offpunk s’inscrit dans les luttes sociétales plus larges telles que :

1) La lutte contre la surproduction

2) La lutte contre l’obsolescence programmée

3) La lutte contre « l’Internet of Things », qui veut que chaque objet, même le plus mondain, soit connecté, récolte des données envoyées à Big Data, nécessite des mises à jour et des applications externes.

4) La lutte contre l’économie de l’attention

5) La réduction des heures de travail qui sont de plus en plus virtuelles

6) Le droit au loisir, à la citoyenneté et au travail sans avoir besoin d’un appareil numérique connecté.

7) Le droit à l’inclusion des populations précarisées ou plus âgées qui dépendent non seulement d’un accès à un appareil numérique connecté, mais doivent également avoir les moyens de se former et de s’adapter pour le mettre à jour et continuer à l’utiliser en dépit des changements introduits.

L’éditorialiste italien Giulio Cavalli disait :

C’est vrai : la digitalisation simplifie, accélère et standardise les procédures. Mais seulement pour ceux qui ont les moyens d’en faire partie. Pour tous les autres, la porte du futur est en train de se fermer.

• Garantire il non-digitale è un diritto, non un ritorno al passato (www.lettera43.it)

Les outils Offunk

1) Le paiement en espèce. Pratique, ne nécessitant ni électricité ni Internet et garantissant que vos données personnelles ne sont pas stockées, agrégées, ni revendues.

2) Les médias analogues. Garantissant qu’une communication reste possible sans Internet et que les données vous appartiennent bel et bien. Disques, livres, journaux, radio…

3) Les médias numériques indépendants et décentralisés. Email, sites web « brutalistes » ou minimalistes, flux RSS, appareils photo numériques non connectés, lecteurs MP3, dumbphones…

4) Stockage et transfert physique des données. Disques durs, clés USB, cartes mémoires ou solutions en ligne indépendantes et contrôlées individuellement. Afin de garantir que nos données ne dépendent pas du bon vouloir d’un « cloud » propriétaire.

5) Des protocoles de communications décentralisés : messagerie via Bluetooth (Bitchat), protocole Gemini, emails chiffrés, Tor, XMPP…

Les challenges

1) La première difficulté est la commodité, la convénience des outils propriétaires : amusement, normes sociales, ubiquité.

2) L’accès aux espaces sociaux qui nécessitent de plus en plus un outil numérique : concerts, parking, cinémas, clubs de sport voire menus de restaurants.

3) Construire des réseaux de relations, y compris professionnelles, sans intermédiaire numérique.

Nous défendons le droit non négociable à un monde non numérique. Le droit de partager sans algorithmes, de nous organiser socialement sans plateformes centralisées. Le droit de ne pas être en permanence connecté ni espionné.

Tant qu’une poignée de sociétés maintiendra un monopole sur la technologie, tant qu’une surveillance de masse sera en place avec la complicité des États, sans la moindre transparence sur les moyens mis en œuvre ni l’utilisation de ces données, tant que l’économie de l’attention pourra monnayer nos temps libres contre de la publicité, tant que les infrastructures mettront à mal l’indépendance des pays du Sud, tant qu’il y aura une digitalisation forcée alors que les accès à Internet ne sont pas considérés comme un droit basique, alors la révolution ne sera pas numérique !

Ce texte a été initialement rédigé en Portugais par Arlon de Serra Grande et cosigné par Ploum (Lionel Dricot)

• Versão em português

An AI model does not decide what data it can access, which tools it can use, or whether it can act without approval. People make those decisions at different points. Upstream, a model developer trains and tests the model and decides whether and how to release it. Downstream, a developer builds the model into a system, connects that system to data and tools, and decides whether a person must review its proposed actions before they take effect.

Those choices determine whether harm is possible at all. So when harm occurs, responsibility should fall on those who controlled the relevant choices. That responsibility may be shared: model developers control training and release, product builders control permissions and deployment, and users control deliberate misuse.

Responsibility should follow meaningful control

That principle is missing from much of the debate over open-weight AI models, which often treats the decision to release a model as the only one that counts.

Axios recently reported that United States officials had considered measures that could restrict American companies from using Chinese open-weight models. Open-weight models make their trained parameters available for others to download, modify, and run on their own infrastructure, without going through the company that built them.

More than 230 companies and organizations have since signed an industry letter defending open weights. After critics accused Anthropic of supporting a ban on open-weight models, Anthropic CEO Dario Amodei published a statement denying that position. He described open-weight models that do not have dangerous capabilities as a public good and supported mandatory safety testing for sufficiently capable models, open or closed.

The disagreement is less about whether open weights can create risk than about when those risks justify restricting a release, and whether restrictions would improve safety or mainly concentrate power in the largest AI labs.

I am firmly in the open-weights camp. I have run and compared open-weight models, argued that digital sovereignty depends on who controls software, not where it comes from, and believe organizations should control their infrastructure and data instead of depending on a handful of providers.

I also believe consequential algorithms need oversight. More than a decade ago, I argued that we would eventually need something like an FDA for software. The harder question is where responsibility for that oversight should lie.

Open-weight models unbundle control

With hosted, closed-weight models from providers such as Anthropic and OpenAI, the provider typically keeps the weights private, controls how customers access the model, and decides when to update the hosted service.

Open weights can separate those roles. One organization creates and releases the model. A repository such as Hugging Face hosts and distributes the weights. Another team might fine-tune them. A product builder incorporates the model into a product and connects it to data, tools, and users.

Each team controls something different. Because open weights unbundle control, it becomes harder to say who is responsible when harm occurs.

A model developer controls the training process, capability testing, documentation, and release decisions. A repository controls what information it displays about a model's origin, which security checks it performs on uploaded files, and which access restrictions it provides or enforces. A product builder controls what data and tools the resulting system can reach, which actions require human approval, and what gets logged.

Control is not the only thing that matters, but it shows who could still have changed the outcome. When harm involves AI, several actors may bear responsibility for the same incident because each controlled a different opportunity to prevent it.

Open Source shows how responsibility follows control

Like open-weight models, Drupal's Open Source code can be copied and changed without asking anyone's permission. A site owner could use it to spread misinformation or operate a fraudulent website. The site owner controls the content and operation of the site and is responsible for those choices. The Drupal project is not responsible merely because someone used its code.

But the Drupal project controls other decisions. When someone privately reports a security vulnerability, the Drupal Security Team follows a coordinated disclosure policy. It keeps the issue private while a fix is prepared. Once a security release is available, the team publishes an advisory and tells site owners to upgrade. The timing of that disclosure can give site owners a fair chance to protect themselves.

The same distinction applies to AI. Responsibility should follow the decisions each actor controls.

Products turn capability into authority

A model generates outputs. An agent is a software system that uses a model to work toward a goal, often by calling tools and taking actions. The people who build and configure the agent decide what it can access, which actions it can take, and when it needs a person's approval.

In a coding agent such as Claude Code, a model can generate a database command. Whether that command can run depends on the tools and permissions the agent provides, as well as the access allowed by the computer, network, and database.

A content management agent can propose deleting an article. The content management system (CMS) determines whether the agent has permission to delete it, whether the deletion is reversible, and whether the action is recorded.

Permissions, isolation, audit logs, rate limits, human approval, and rollback are not merely engineering details. They determine who has control at the point where harm can still be prevented. That is why AI governance is becoming an essential part of product architecture.

Regulate AI at each point of control

Deciding who should answer after harm is easier, even when the answer is not obvious. The harder question is what government should require before any harm has happened.

If control and responsibility are distributed across several actors, government rules should be distributed across them too. This is not a new idea. We already regulate many technologies this way.

More than a decade ago, when I argued for something like an FDA for software, I had drug approval in mind. I no longer think that is the right model. The FDA approves a drug for one or more intended uses, while a general-purpose model may be used for many different purposes.

Cars are a better comparison. The government sets safety standards, and manufacturers certify that their vehicles meet them. Separately, drivers must pass a test defined by the government before they are licensed to drive.

The layers extend beyond cars and drivers. States set legal blood-alcohol limits for drivers and require bars to have licenses they can lose. In many states, a bar can also be held liable for serving a visibly intoxicated person who later causes harm.

Each rule targets the actor who controls a particular decision. Together, they reduce risk for everyone. I would take the same layered approach to AI.

Blocking a model's release is a much stronger step, and one that should rarely be used. For an open-weight model, that means preventing the developer from publishing the weights. For a closed model, it could mean preventing the provider from offering access.

I would support that only when safeguards in products and rules governing their use could not prevent a serious danger in time. The two-part test below applies only to this exceptional step, not to AI regulation in general.

Require extraordinary evidence to block a release

The strongest argument for restricting an open-weight release is that it is effectively irreversible. Once the weights are public, the developer cannot withdraw every copy, monitor how the model is used, or ensure that its safeguards remain in place.

If a model made catastrophic harm much easier, its release could be the last moment anyone had meaningful control. By catastrophic, I mean mass-casualty or comparably systemic harm, not ordinary product failure, fraud, or abuse.

As of July 2026, I have not seen public evidence that an open-weight model has crossed this threshold. That said, I believe it is just a matter of time, which is why I still think meaningful regulation is coming.

Before blocking a model's release, a government should have clear evidence that the answer to both questions is yes:

1. Would releasing this model make catastrophic harm much easier? Compare it with closed models and other tools people can already access.

2. Would blocking its release meaningfully reduce that danger? A restriction should not merely shift access to another country or distribution channel.

Default to openness with distributed responsibility

So where do I land today? I would default to allowing publication and place obligations where control already exists: on model creators for testing and release decisions, on distributors for provenance and file integrity, on product builders for permissions and deployment, and on users for deliberate misuse.

This approach also protects competition. A regulatory regime that only the largest labs can satisfy could protect them from competition without necessarily making anyone safer. It could also push organizations toward depending on a handful of providers for infrastructure they cannot inspect.

Open weights do not eliminate control. They distribute it, making it harder to say who is responsible when harm occurs. Regulation should follow that structure: place obligations on each actor at the point where harm can still be prevented, and block publication only when release would make catastrophic harm substantially easier and a restriction would materially reduce the danger.

In April 2025, I published Claude Code meets Drupal, my first public experiment with an AI coding agent. I have been experimenting with coding agents ever since, often by building tools to solve problems in my own work.

Last week, I joined the Drupal AI Learners Club to discuss several experiments I had already published. Angie Byron started the club and runs it with co-organizer Amber Himes Matz. It gives people in the Drupal community a place to show how they are using AI and talk honestly about what works and what does not.

I spent an hour walking through some of my AI experiments, starting with Drupal Digests, a tool that uses AI to summarize key developments across Drupal Core, Drupal CMS, Drupal Canvas, and the Drupal AI initiative.

Drupal Digests led to another experiment: AI-generated Rector rules. When a Drupal Core change deprecates an API, Drupal Digests analyzes the issue and code changes and generates a rule that can automate the corresponding upgrade in other Drupal projects.

I also showed my API Catalog that helps AI agents discover my website's search API.

These are only some of my AI experiments. Most begin as tools I build for myself, and many never go any further. When one seems useful beyond my own work, I publish it so others can benefit from it.

Once a tool is public, we can see whether people use it and want to help improve it. If they do, it may eventually become a proper community project. If not, that is useful to know too.

The recording goes into more detail, with demonstrations of the tools and questions from the group. You can watch it below.

A git worktree workflow eats a lot more disk than you’d expect. On the remote box I run my coding agents on , ten worktrees took a 28 GB volume down to 687 MB free in about a day. Here’s one way to limit that.

Yesterday I blogged about the API catalog that announces my site's search API to agents. In response, someone pointed me to the ARD specification, a draft announced last month by a working group that includes Google, Microsoft, GitHub, Hugging Face, Cisco, Nvidia, and Salesforce.

What ARD adds to yesterday's API catalog is discovery. If an agent has never heard of you, it does not know to look for your API catalog. Ask an agent what people have written about the future of Drupal, for example, and it will probably search Google. It may not think to check dri.es or drupal.org directly.

The web solved discovery decades ago. Search engines find the right site, so you do not have to know where the answer lives.

ARD brings search-engine-style discovery to AI agents. ARD registries crawl the web for catalogs published by sites and add their resources to a searchable index. An agent can then ask a registry a plain-language question, such as "Who can answer questions about the future of Drupal?". The registry returns a ranked list of relevant resources, perhaps pointing the agent to my site's search API.

You opt in by publishing a manifest at /.well-known/ai-catalog.json. Here is what my mine currently returns:

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Dries Buytaert"
  },
  "entries": [
    {
      "identifier": "urn:air:dri.es:search",
      "displayName": "Site search",
      "type": "application/openapi+json",
      "url": "https://dri.es/openapi.json",
      "description": "Full-text search across the site's content, ranked by relevance.",
      "representativeQueries": [
        "Find posts about the future of Drupal",
        "What has been written about open source sustainability?",
        "Find writing about digital sovereignty",
        "How is AI changing how we build websites?",
        "Search Dries Buytaert's blog and notes"
      ]
    }
  ]
}

Each entry describes a resource an agent can use. ARD deliberately defines "resource" broadly: it can be an API, an MCP server, another agent, a skill, or even a nested catalog containing more resources.

My site offers just one resource: a simple search API. The whole thing took less than an hour to implement because the ARD entry simply points to the existing OpenAPI document, https://dri.es/openapi.json, that I wrote about yesterday. In other words, it makes the same API description available through a second discovery mechanism.

The representativeQueries field is the interesting part. It lists example questions registries use to match an agent's intent. Mine are first guesses that I will revise once I can see how they get used.

Of the eleven companies listed as contributors, Hugging Face is the only one whose AI catalog I could find on its primary domain. It also runs an early registry. So I queried Hugging Face's registry. It responded correctly using the protocol defined by the specification, but for my queries, it returned only skills hosted by Hugging Face.

Broad adoption will depend on whether major agents begin searching ARD registries. Microsoft, Google, and GitHub are members of the working group, but OpenAI and Anthropic are not. Google has said its Agent Platform will connect to ARD registries in the coming months, but it remains to be seen how widely the specification will be adopted.

Does my blog need this? Probably not. Other sites have more to gain. An online store could announce its product search and checkout APIs, a restaurant its reservation system, and a city its appointment system for renewing a permit.

Many of these sites run on a content management system. A CMS that made its capabilities discoverable through ARD by default could therefore be interesting. Experiments like this help me understand whether Drupal should be that CMS.

For the last few months my laptop has been the bottleneck in my own workflow. Not the CPU, not the RAM – the fact that it’s a laptop.

I kept running into the same small frustration. My site has its own search, but when I ask an AI agent whether I have written about a topic before, it searches Google instead of using my site's search directly. As a result, it often misses relevant posts that Google has not indexed.

At the same time, the web is gaining a new audience. In addition to people visiting pages, AI agents increasingly access a site's knowledge and tools directly.

That combination led me to add support for /.well-known/api-catalog to my site. A request to https://dri.es/.well-known/api-catalog currently returns:

{
  "linkset": [
    {
      "anchor": "https://dri.es/search/json",
      "service-desc": [
        {
          "href": "https://dri.es/openapi.json",
          "type": "application/openapi+json"
        }
      ]
    }
  ]
}

RFC 9727, an IETF Proposed Standard, defines /.well-known/api-catalog as a predictable location for discovering a site's public APIs.

The catalog is a small JSON document written in the Linkset format. It advertises my search endpoint and, in turn, links to an OpenAPI document that tells software how to use it.

The JSON endpoint at /search/json predates the catalog and powers my site's search. However, it was not documented or easy for software to discover. The catalog now makes it explicit.

The OpenAPI document at https://dri.es/openapi.json tells AI agents exactly how to call the endpoint and interpret the results. It removes the guesswork, reducing the time and tokens agents would otherwise spend figuring out how the API works.

In short, the API catalog announces that my search API exists, while the OpenAPI document explains how to use it. An agent can start with just my domain, check /.well-known/api-catalog, follow the link to the OpenAPI document, and learn how to search dri.es directly.

The feature has been live for a few months, but I am only now writing about it. In the meantime, I have logged every request to /.well-known/api-catalog and /openapi.json. The result so far: zero AI agents have used it.

I found the same problem when I analyzed llms.txt usage: the AI crawlers it was meant for never use it, so I never bothered implementing it.

Unlike llms.txt, the API catalog solves a problem I have, and I do not need to wait for industry adoption. I recently created an Agent Skill, a SKILL.md file that directs my agents to check the catalog and use my site's search API whenever they need information from dri.es.

My agents now search dri.es directly and find posts that Google misses. And if any AI agent adopts API catalog discovery, my site is ready.

We are halfway 2026 already so it is time to think about what you will be doing next February.

Start with blocking your calendar for 1-3 February . As usual we’ll be meeting in Ghent for 3 days of Infrastructure Automation Geekery. It will be a fun mix of 2 days of conference with new and old communities, followed by a day of workshops hackathons and tutorials. You know you can’t mis this.

In recent months, a number of Acquia customers have independently made the same strategic decision: to migrate hundreds of websites from WordPress and other platforms to Drupal.

Some of these sites will move to Acquia Cloud, our Drupal PaaS, while others will move to Acquia Source, our Drupal SaaS. Drupal CMS played an important role in these decisions by making Drupal more approachable to marketers and site builders.

Why are different organizations making the same choice? One key reason is the cost of CMS fragmentation.

A few months ago, a CMO told me that her team had purchased a new digital asset management system (DAM). The estimate to connect it to the organization's websites came back at nearly $100,000 and three months of work.

Why so much? The organization ran three CMS platforms: Drupal, WordPress, and Contentful. The DAM had to be integrated with all three. That meant not only three integrations, but also three sets of expertise, three rollout plans, and three ongoing maintenance responsibilities. One new capability had become three separate projects.

Organizations are under pressure to move faster and reduce costs. CMS fragmentation creates a recurring tax through duplicated integrations, security practices, governance policies, infrastructure, technical expertise, and more. It also fragments attention and makes it harder to share improvements across teams and websites.

Organizations pay that tax every day through higher operating costs and slower execution, not only when they introduce new capabilities. When it consistently slows their ability to improve digital experiences, it can become a competitive disadvantage.

Some of this duplication can be reduced by standardizing hosting and portfolio governance across multiple CMS platforms. That is valuable, but it addresses only one layer of the problem. Each CMS still has its own extension model, editorial experience, security considerations, and required expertise.

This fragmentation usually happens for understandable reasons. Teams often make technology decisions independently, and different sites can have genuinely different requirements.

A marketing team may need to launch a campaign site in days without involving developers, making SaaS solutions attractive. A team responsible for a high-traffic enterprise application with custom integrations may need the flexibility and control of an Open Source solution running in a PaaS environment.

Each decision can make sense for the individual project while creating significant duplication across the organization.

More than 15 years ago, I argued in a post about Acquia's product strategy that organizations should standardize on a common CMS while choosing the right operating model for each site.

Today, the case is even stronger. Websites depend on more integrations, digital experiences are more complex, and AI is becoming another shared capability that organizations need to deploy across their portfolios. With multiple CMS platforms, every new capability becomes harder and more expensive to deploy safely.

Standardizing on a single CMS lets teams reuse more of their design systems, security practices, integrations, and expertise across sites. Marketers get a more consistent way to create and manage content, while developers spend less time implementing the same capabilities on unrelated platforms.

But standardizing on Drupal does not mean forcing every site into the same architecture or operating model. Organizations can share a common CMS foundation while choosing a different balance of convenience and control for each site.

That is where Acquia Source and Acquia Cloud fit together.

Acquia Source provides the SaaS operating model. It is designed for teams that value speed and simplicity. Acquia manages the underlying platform, while marketers and site builders customize experiences through the user interface, reusable components, and supported integrations. Developers can extend sites through custom components, APIs, webhooks, and other supported tools without managing the Drupal codebase or installing arbitrary modules.

Acquia Cloud provides the PaaS operating model. It is designed for sites that need deeper customization and more developer control. Teams can build custom Drupal modules, use contributed modules, manage code through Git, run CI/CD pipelines, and integrate Drupal more deeply with other systems.

Both are built on Drupal. This gives organizations a shared foundation for skills, content practices, design systems, security, and integrations, while allowing each site to choose the right balance of speed, simplicity, flexibility, and control.

A site can begin on Acquia Source when speed and simplicity matter most. If its requirements later grow to include custom modules, deeper integrations, or more developer control, the organization can export its source code, database, and files and move to Acquia Cloud or another Drupal environment without adopting a different CMS.

I have been calling this "Open SaaS": the convenience of SaaS combined with the ownership and portability of Open Source. Organizations can choose a different operating model without leaving Drupal or surrendering control of their sites.

When organizations standardize this way, the economics change dramatically. We have helped some customers save millions of dollars each year by reusing shared capabilities instead of rebuilding them for different platforms.

The goal is not to operate every website in the same way. A campaign site and a mission-critical application require different levels of speed, flexibility, and control, but they do not need unrelated CMS platforms.

The goal is to create operating leverage across an organization's digital portfolio. Each site can use the operating model that fits its needs, while teams reuse investments in content, design, integrations, security, and expertise.

Then, when the organization adds a DAM, a personalization engine, an analytics platform, or an AI capability, teams can build on shared work rather than start over for each CMS. The result is faster execution, greater returns on digital investments, lower costs, and less risk.

One CMS foundation with multiple operating models makes that possible.

Years ago, I wrote about hiking the Pemi Loop. To my surprise, many people still read that post. I imagine them sitting at a kitchen table with a map spread before them, trying to figure out what the hike will actually feel like.

This post is for that same reader, with a new map spread across the table: New Hampshire's Presidential Range.

My friend Chris and I just spent four days hiking through the Presidentials, a rugged chain of peaks named mostly after American presidents.

The classic Presidential Traverse covers roughly nineteen to twenty-three miles (31 to 37 kilometers) and involves about nine thousand feet (2,700 meters) of climbing, depending on the route and which summits you include.

We traveled from hut to hut rather than carrying a tent. Our four-day itinerary included two full days on the trail, with shorter days at the beginning and end so we could drive to and from the mountains.

On paper, the distance and elevation gain look manageable. The numbers didn't capture the effort. Much of our route followed the Appalachian Trail across loose rock and exposed ridgelines, where the weather can turn quickly.

The thru-hikers we met called the Presidentials one of their favorite sections and one of the hardest. A mile here can feel like two or three on an easier trail.

Unlike the Pemi Loop, this was a point-to-point hike. We traveled south to north, beginning near Crawford Notch and finishing at the Appalachia trailhead in Randolph.

Because the trailheads are about forty minutes apart by car, we left ours at the finish and arranged a ride to the start. Four days later, when we emerged from the woods and found the car waiting for us, it felt like a small miracle.

Day 1: Up to Mizpah Spring Hut

Our first day was short, which suited us because we had driven up from Boston and did not start hiking until two in the afternoon. From the parking lot, you climb and keep climbing until eventually there is a hut.

On the way up, we passed a steady stream of hikers heading down, all of them looking pleased to be traveling in that direction.

My left quad started complaining almost immediately. My pack was noticeably heavier than Chris', thanks in part to the unreasonable number of snacks I had brought.

We reached Mizpah Spring Hut a little more than two hours later. If a short afternoon hike could leave my quad complaining, the next two days were going to be much harder.

There was nothing to do about any of it but eat and sleep, and the hut is built for exactly that. The accommodations are rustic: no showers, no heat, and no electricity for guests. What you get is a bunk, cold well water, composting toilets, a pillow, and several wool blankets. Guests are encouraged to bring a sleeping bag or liner, so we did.

Dinner improved my outlook. The portions were absurdly generous, and the pulled pork was some of the best I had ever eaten, although two hours of climbing may deserve some of the credit.

After dinner we played chess, and I beat Chris three times in a row. To keep it interesting, I removed my own queen as a handicap and beat him anyway. I mention this only because he will read this post.

The huts pack you into bunkrooms with anywhere from six to a dozen strangers, and between Chris snoring and the general symphony of a shared room, I didn't sleep very well. The thin mattress left my shoulder and hip aching, and at one point my arm went numb. That is simply part of hut life, and it still beats sleeping in a tent.

Day 2: Pierce, Eisenhower, and the roof of the Northeast

Day two took us from Mizpah Spring Hut to Lakes of the Clouds Hut, following the high ridge of the Southern Presidentials. It was our first full day on the trail and our first sustained stretch above treeline.

We climbed Mount Pierce (4,310 ft) first, then continued toward the broad dome of Mount Eisenhower (4,780 ft). As we gained elevation, the trees thinned, shrank, and finally gave way to open rock. The trail rose into the wind, with the mountains unfolding around us in every direction.

Between Eisenhower and our destination, we crossed Mount Franklin, which looks like a summit and feels like a summit but does not officially count as one.

By early afternoon, we reached Lakes of the Clouds, the highest and best-known of the Appalachian Mountain Club's huts. We dropped our packs, claimed our bunks, and set out for the summit of Mount Washington (6,288 ft). The climb added two and a half hours to an already long day, but with the summit just above us, we kept going.

Mount Washington bills itself as the home of the world's worst weather. In 1934, observers at the summit recorded a wind gust of 231 miles per hour, a world record that stood until 1996. It remains the strongest gust ever measured at a staffed weather station. People die on and around Mount Washington nearly every year, often after the weather turns faster than they expect. We, somehow, got sunshine and crystal-clear air, with views that stretched for more than a hundred miles.

The trail down from Mount Washington is a long scramble over broken rock. The small white building below is Lakes of the Clouds Hut, tucked beneath Mount Monroe, with Mount Eisenhower and Mount Pierce in the distance.

The weather spared us, but the climbing did not. Three four-thousand-footers in one day left their mark. By evening, my hiking shirt had grown salt rings from all the sweating. It was impressive, disgusting, and, with no showers at the huts, a problem for another day.

At sunset, the mountains faded layer upon layer, from blue to gray, until the last ridges disappeared. Chris and I stood and watched, tired and happy, forgetting about our knees.

At sunset, everyone at Lakes of the Clouds Hut stepped outside and took the same photo.

The bunkroom brought me quickly back to earth. The moment I opened the door, a wall of sweaty feet and damp shoes met me, thick enough to taste. The bunks were narrow and packed close together. Sometime in the night Chris gave up entirely and moved out of the room to sleep somewhere he could breathe.

Day 3: The northern peaks

This was the hardest day of the trip, and the best. We spent about eight hours on the trail, most of it above treeline, hopping from rock to rock. I had to watch every step. Mile after mile, the terrain kept us moving slowly and deliberately.

We went over the top of Mount Clay (5,533 ft), then climbed Mount Jefferson (5,712 ft), and passed Thunderstorm Junction, a huge cairn near Mount Adams where several trails meet.

Somewhere along the ridge I developed a couple of blisters, which I patched before they could take over. The heat asked for the same kind of upkeep: I drank three liters of water and took two electrolyte tablets, and I was still craving salt by dinner, when I dumped extra on my pasta shells.

Leaving Lakes of the Clouds, we rejoined the Crawford Path, which carries the Appalachian Trail toward Mount Washington. I had to stop to treat my blisters before they got worse.

One of my favorite parts of the hike was meeting AT thru-hikers. Much of the ridge follows the Appalachian Trail, and many of them were already months into their journey from Georgia to Maine. They were friendly and much faster than we were. You could often recognize them by their strong legs, and sometimes by their strong smell, though after three days without a shower, I was hardly one to talk.

We reached Madison Spring Hut in the early evening. This time my bunk was at the top of a stack four beds high, which I started calling "the fourth floor." It was close enough to the ceiling that I learned not to sit up too fast. At my age, nature tends to call at least once a night. From the fourth floor, that meant logging extra vertical miles. By now, though, the snoring and thin mattresses barely registered.

Day 4: Down to the burger

The last day was a long walk down. We left Madison Spring Hut and followed the Valley Way Trail back into the trees and eventually to the car we had left days earlier.

On the way down, I realized I felt different from how I had at the end of the Pemi Loop. There, every mile had made me more tired and weaker. This time I was more tired but also stronger. Maybe it was the hut meals, the lighter pack, or the daily electrolytes. Whatever the reason, my legs were sore but moving better than they had on the first day.

Our timing was lucky. By evening, after we were safely off the trail, winds had reached gale force and hail was sweeping across the mountains.

We celebrated our escape the only sensible way: with burgers at Black Mountain Burger in Lincoln. Hut food is generous, but after four days it is not this. That burger tasted better than any summit we climbed.

The four-thousand-footers we climbed

New Hampshire hikers chase a famous list of forty-eight peaks over four thousand feet. In the years I have lived in New England, I have climbed quite a few of them.

To make the list, a mountain has to rise at least two hundred feet above the col, the saddle connecting it to its taller neighbor. That rule is why Mount Franklin and Mount Clay, both well over four thousand feet, do not count. They are really shoulders of bigger mountains.

Of the peaks we crossed, Franklin and Clay were also the only two not named for presidents. Benjamin Franklin and Henry Clay never reached the White House, and their mountains never reached the list. The two men who did not make it became the two mountains that did not count.

By the two-hundred-foot rule, we summited four: Pierce, Eisenhower, Washington, and Jefferson. We came up just short of Adams and walked past Monroe and Madison, which means the Presidentials still owe us a return trip.

When I think about the trip, I do not remember the blisters or the bunkrooms first. I remember standing next to Chris at sunset while the ridges faded from blue to gray, one behind another.

My legs are still sore, but I am already wondering where to hike next.

I’ve been busy doing some OpenSearch upgrades and migrations the past couple of months, and I was tired of running curl with different parameters to get the default health and other OpenSearch statuses. Apart from that my muscle memory failed to get the right variety of parameters once in a while so I figured I just write a wrapper around curl that would do a bunch of these things easier for me.

 Evolutie van twee bakken deze lente/zomer. Die kunnen goed tegen de hitte!

The Drupal Association is entering a new chapter. Tim Doyle is stepping down as CEO, and the Board has appointed Tiffany Farriss as interim CEO.

I am grateful to Tim for his leadership and his impact on the Drupal Association. He built a strong leadership team that helped guide Drupal through an ambitious period of innovation. That team is well positioned to continue supporting Drupal and its community.

Tiffany brings continuity and deep expertise to the Drupal Association. She has contributed to Drupal for many years and served on the Drupal Association Board for more than a decade, including serving on its Finance Committee. She helped organize DrupalCons and built a successful agency in the Drupal ecosystem. She understands our project, the Drupal Association's finances, and the realities our partners, contributors, and users face.

I have worked with Tiffany for many years. She is thoughtful, deeply committed to Drupal, and unafraid of hard questions. Although her title is interim CEO, she has the full authority and confidence of the Board, as well as my full support.

We expect Tiffany to serve for six to twelve months. During that time, she will focus on strengthening the Association's financial and operational foundation and preparing it for long-term leadership. Later in that period, the Board plans to launch a search for the next permanent CEO.

Turning innovation into momentum

Tiffany is stepping into the role at an important moment for Drupal.

Over the past few years, our community has done some of its most ambitious work. Contributors have continued to modernize Drupal Core. We launched Drupal CMS to make Drupal easier to adopt, introduced Drupal Canvas to rethink how people build, and rapidly advanced Drupal AI to change how people create and manage content.

We have also taken important steps toward marketing Drupal with the seriousness it deserves, so more organizations understand why it remains one of the most powerful and trusted platforms for building serious websites and web applications.

This progress was made possible by our contributors and the organizations that invest in Drupal every day. The Drupal Association's role is to support that work and help turn it into wider adoption, a stronger ecosystem, and more opportunity for Drupal businesses.

Sustaining Drupal's essential work

The Drupal Association operates much of the infrastructure the project depends on, from Drupal.org and our collaboration tools to the services that help keep Drupal secure.

Drupal's infrastructure alone costs roughly $3 million each year. Today, it is funded through DrupalCon revenue, partnerships, sponsorships, donations, donated services, and volunteer contributions. That model has supported Drupal for many years, but it is not durable enough for the scale of the work ahead.

This is a challenge shared by open-source stewards everywhere. The software may be free to download, but the infrastructure and stewardship that make it dependable are not free to provide.

Building a stronger Drupal Association

Our commitment to Drupal's infrastructure and community will not change. But supporting both well requires a stronger Drupal Association, and that may mean exploring new approaches. We will weigh the options carefully, guided by what is best for Drupal and the people who depend on it.

This work will not be easy, but our ambition is clear: make the Drupal Association more sustainable, help Drupal innovate faster, strengthen how we bring it to market, and better support Certified Partners.

As this work takes shape, we will be transparent about what we are learning, the choices we are considering, and what they could mean for the Drupal Association and the Drupal community.

Tiffany understands what makes Drupal special and what the community values most. She also has the experience and mandate to shape what comes next.

Every new chapter depends on people willing to step forward. I am thankful to Tim for all he has done, to the Association's staff for their dedication, and to Tiffany for taking this on. With their commitment, I am confident in Drupal's direction and excited about the work ahead.

Some weeks ago Matt Rechenburg posted about MattX , A Modern openMosix Re-Implementation for Linux 6.x
he tagged me in the post and obviously I was triggered, having spent years in the openMosix community , first writing the Howto, then later being the release manager , testing and getting rid of the openMosixFS , I wanted to see how things would work again today.

My first attempts at getting things to work were a quick failure, Matt had been bitten by the Works on My machine bug … it worked on his Debian setup, but not on my Fedora testbed, and while there is nothing wrong with Debian, that’s kinda a really small scope, so obviously I reached out , we’ve been chatting on and off. And I`m happy to see that I have now seen the first processes migrate in my Lab setup on my AlmaLinux boxen :)

Alex West wrote Not Business Advice , a free series of 13 short books about building profitable personal projects, compiled from the daily blog posts he’s written since 2018. It’s the story of how he made over $1M from his own side projects, and I’m reading it right now. It’s really good: honest about the failure, luck, and burnout, not just the wins. Go read it, it’s free.

I’ve been pondering whether to move away from Fastmail - not because it’s a bad service, but because of where the servers are hosted. I’ve weighed a bunch, but for now I’m staying with Fastmail. The beauty of email is that it’s based on open standards, and you can just move whenever you feel like it.

Mail-hosting history

Over the years I’ve used GMX.net, Hotmail and Gmail - the latter still exists but is not actively used. In addition to Gmail, I also used Google Calendar and Google Contacts.

Unknown (2000 - 2005)

I bought my first domain in 2000, but I forgot where I had that hosted. It came with email, that I remember, which I accessed through Eudora and later KMail.

Lunarpages (2005 - 2008)

In 2005 I moved to Lunar Pages, and took my mail with me there. Your run-of-the-mill shared webhosting mail service. Used via KMail. If my memory serves me right they offered Squirrelmail and IMP as webmail interfaces.

Google Apps for My Domain (2008 - 2015)

In 2008 I moved my mail to Google Apps for My Domain, which had a free plan at the time. I also moved my calendar and contacts there, removing them from the free Google services that I had been using up to then.

With Google Apps for My Domain (now known as Google Workspace), you could use your own domain. The Google interfaces were amongst the best that I had come across; the service was free, and Google did not put ads in the Google Apps variants (since they were geared towards paying customers).

Fastmail (2016)

As I was feeling less and less good about my over-reliance on Google products, I moved in 2016 to Fastmail for a year. I really enjoyed it, but the integration options into Android (my mobile platform of choice) weren’t that fantastic. 3rd party apps only got me so far.

Google Apps for My Domain (2017.. ish?)

2017 saw me moving back to Google Apps - as a paying customer this time since they had stopped their free plans - but that didn’t last long. After using Fastmail, the Gmail interface felt slow and clunky - and I was facing serious synchronisation issues with calendars from Microsoft O365. Often they would not sync at all.

I raised a ticket with support, but that did not end on a happy note:

As discussed I can confirm you’re affected by the known issue where Google Calendar experiences issues parsing a published ICS. Our engineering team are aware of this issue and have been working towards interoperability with Microsoft engineers but as of yet there is no ETA for a fix for this issue.

Under usual circumstances I would suggest installing Google Sync for Microsoft Outlook as a workaround to sync in real-time but I understand you’re unable to install applications on your machine. Please note I have added your domain to the list of affected users and will provide additional feedback to our engineering team regarding this issue.

Needless to say, I never heard back from them. I’m not sure if that issue even ever got fixed.

Fastmail (2017 - now)

That same year I migrated back to Fastmail, where I’ve been ever since.

About Fastmail

Fastmail is a fantastic email provider. They do great work in the open source world and are actively working with several international communities to make email better for everyone.

The web interface - which is the primary way I interact with their service - is functional, fast, beautiful, and gets out of the way. Keyboard navigation is a thing, and it works great.

Their support is amazing. Back in 2016, I had an issue syncing calendars from Microsoft O365 (duplicate entries would show up if individual items in a recurring meeting got modified), and I raised it with them. After some back and forth, this was the outcome:

As you can see, the “RECURRENCE-ID” field has a zero time component, but the DTSTART was T110000, so the RECURRENCE-ID doesn’t match any actual recurrence of the event. There’s been a ton of discussion about this case on the standards calls for CalConnect, and the conclusion was that we should be including any “unknown” recurrence as a separate instance - so you wind up with two instances of the event in our system.

It’s clearly a Microsoft bug, that recurrence ID should say T110000. I’m not even sure what we can do about it :(

Having said that - the behaviour when RECURRENCE-ID doesn’t match an expanded recurrence is undefined by the spec. We’re working on fixing that as part of the TC-API group at CalConnect - there will be a new standard which doesn’t have this problem. sigh

So meanwhile we’ve fixed our product to check for this particular case - where there’s no time on the RECURRENCE-ID field, but the recurrence must be at the same time each day - and it will modify the recurrences to be at the same time as the DTSTART of the first event.

You will notice that this has fixed the duplicates on display in your calendar. It will also modify the caldav events on next sync for synchronised calendars.

Regards,

Bron.

And it was fixed. At that time I wasn’t even aware who Bron was - he’s the CEO of Fastmail.

So why consider moving?

My current subscription ends in October, so this is a good moment to weigh things up. I would prefer staying with Fastmail - it works, and it works well, but there’s one thing that keeps nagging at me:

I am not a lawyer. This is my own interpretation. Make of it what you will.

Fastmail is an Australian company which hosts its servers in the US. Data that is physically there falls under US jurisdiction regardless of where the company is incorporated. FISA Section 702 gives US intelligence agencies the ability to collect communications of non-US persons from US-based servers without a warrant, and the CLOUD Act allows them to compel access through standard legal process.

Fastmail addressed this concern back in 2013 in which they stated that as an Australian company with no US incorporation or staff, they are not directly bound by US court orders. The CLOUD Act which has been passed since mitigates this though.

The above concerns are not specifically tied to Fastmail, but more to do with how I feel about US jurisdiction. They’ve behaved less like a trusted partner and more like an abusive spouse.

I know that there are international intelligence sharing agreements, so even moving to a purely European hosting service would not mitigate this.

Requirements

• The provider must use open standards - SMTP, IMAP, CalDAV and CardDAV. JMAP is a nice-to-have. POP3 is not required.
• Multiple custom domains need to be supported.
• Email, contacts and calendars should all be part of the offering.
• Catchall addresses are a requirement.
• Since I mostly (always?) access my mail through webmail and I have not found a client that I like, their webmail should check the boxes listed in the previous blog post. And it really needs to be pleasant to use. Perhaps a strange requirement, but it is one for me.
• The provider or its parent company must not be incorporated in the US.
• The servers of the provider should not be solely located in the US. Not having them there at all is even better.
• Encryption at rest is non-negotiable, but I believe all reputable providers do that these days.
• End-to-end encryption is not a requirement for me. While it’s nice from a privacy point of view, it negates the possibility of using the aforementioned standards, and being realistic, 90% of the mail I send out probably ends up on either Gmail or Outlook.

Hosting providers

I had a look at a bunch of alternative hosting providers, in no particular order.

Proton & Tuta

Proton is hosted (for now) in Switzerland, Tuta in Germany.

These two providers are end-to-end encrypted and have (in my view) a lock-in problem: it’s not easy to get your data in or out. They both have a means for importing and exporting, but it’s a far cry from using an IMAP copy between mailboxes. The main reason I don’t want to use them.

For a long time neither of them had the option to share calendar links to 3rd parties outside of their ecosystem, which also negated them for me. This seems to be possible now.

Additionally, Proton has no support for dark-themed mail content, and while Tuta does have that, it’s half baked.

My threat model also does not require end-to-end encryption.

Eclipso

Hosted in Germany. The web interface is clean, but unfortunately no dark mode to be seen anywhere. It also had me searching how to change the language from German (default) to English… I understand some German but not enough to use it daily.

Runbox

Hosted in Norway. The interface is better than the older version, but often it switches back and forth between versions. No dark mode support, and also no way to share or subscribe to calendars.

Posteo

Hosted in Germany. Does not support custom domains, which is a dealbreaker.

Mailbox.org

Hosted in Germany, supports all the standards. Web interface is not great, but works. Unfortunately no support for dark-themed mails, and I had issues getting a rather large shared calendar to sync.

I contacted support about this. After a really long round-trip (nearly a week), the final conclusion was that I just have to sync it in my client of choice. Heh.

Infomaniak

Hosted in Switzerland. No dark-themed emails, and the interface is confusing. They have so many things that I don’t need or want in the K-Suite that it’s off-putting to use.

Migadu

Also hosted in Switzerland. Mail and very limited calendaring support (only through CalDAV).

Startmail

Hosted in The Netherlands. No calendar support, which I do require.

Mailfence

Hosted in Belgium. Supports mail, contacts, calendars. No dark-themed emails, unfortunately. The interface needs to be improved to be really something I’d love to use on a daily basis.

Soverin

Hosted in The Netherlands. While they have all the parts, the interface feels old and not pleasant to use. Dark mode is wishy-washy, both for mails and the UI.

Grommunio

This is actually an Exchange replacement. I asked for a demo account on Grommunio to test it (since they don’t sell it themselves, only through partners). Dark mode works well (mail and UI), but there is no way to subscribe to calendars from outside Grommunio without relying on scripts. Finding a reseller that will deal with a customer (vs a business) might also be a challenge.

Update 2026/07/17: Businesswire: Fastmail will be adding email hosting in Amsterdam.

Update 2026/08/03: Fastmail blog: Fastmail offers EU data region

In a first phase, the secondary copy of the data (for resiliency in case the EU servers go down) will still live in the US. The blog post does open up the possibility that in a future phase data won’t be sent to the US anymore.

Fastmail is an Australian company and as such it is bound by Australian law. This, combined with international data sharing agreements, means that data can be subpoenaed regardless of where it is hosted. For me personally it feels like a step in the right direction though. Bron answered some questions in this Reddit thread - we’ll need to wait and see what happens.

Near the end of most Open Source licenses, usually in capital letters, sits a clause that disclaims almost everything: no warranty, no liability, use at your own risk.

For an organization that depends on that code, the clause is harsh. If the code fails and takes your data or revenue with it, the license owes you nothing. No fix, no refund, and no one to explain what went wrong.

That is the Open Source license doing its job. It makes the code available and protects the people who share it. Without that protection, sharing code could become a gift that backfires: a generous act turned into unlimited legal risk.

But the license can only answer the legal questions: who may use the code, on what terms, and what risk the authors are willing to accept. It cannot tell you what kind of Open Source project you are working with.

Some Open Source is "License-only Open Source": code released under an Open Source license, without active stewardship or any promise of ongoing care. There is no guarantee of updates, fixes, security response, or long-term support.

Other Open Source is "Stewarded Open Source": code cared for as shared infrastructure. Maintainers review contributions, fix bugs, respond to security issues, manage releases, provide long-term support, and much more. Organizations fund maintainers, support core development, donate infrastructure, and absorb costs end users never see.

Both types of projects are Open Source, but they are not the same. A weekend hobby project and business-critical software can ship under the exact same license. Legally, they look identical. Practically, they are worlds apart.

The difference is stewardship. The license makes code available; stewardship makes it dependable. And the more people or organizations depend on a project, the more stewardship it often requires.

Responsibility is the tax on relevance.

Distinguishing license-only from stewarded Open Source gives us the vocabulary to describe two very different realities that the words "Open Source" alone do not capture.

For example, the distinction becomes useful when we talk about contribution. If a company depends on Open Source, should it give back?

For license-only Open Source, the answer is simple: no one is required to contribute. The code was shared freely, without a promise of care or an expectation of return.

For stewarded Open Source, the answer is not so simple. The license may still say the software is provided as-is, used at your own risk. Legally, no one has to contribute back. But there is also an entire layer of stewardship on top of the code: security, release management, infrastructure, governance, marketing, long-term maintenance, and more. People and organizations take on responsibilities well beyond what the license requires so the software can be safer to adopt, easier to upgrade, and dependable in production.

For projects like Drupal, that layer costs millions of dollars a year, and someone pays for every piece of it. I explored this more concretely in Open Source infrastructure deserves a business model and what it costs to run Drupal's infrastructure.

When we call everything simply "Open Source", we hide the difference between code that was simply shared and infrastructure that is being cared for and de-risked. Better language will not solve the funding problem by itself, but it makes the responsibility visible. More honest conversations start there.

I’ve been searching for an email client. Well, more than an email client - a piece of software (or interconnected pieces) that can handle email, calendaring and contacts - often referred to as a Personal Information Manager (or PIM). Either natively on Linux, or as a web client.

The main reason for this search is that I’m considering moving away from my current mail hoster, Fastmail. Not because of the price (which is fair), not because of the service (which is stellar), not because of their webmail interface (which is one of the best PIM interfaces I’ve ever come across), but because their servers are hosted in the USA. Maybe a bit childish, but I’d prefer my stuff a bit farther away from that regime.

In my world email, calendaring and contacts go hand in hand. I send emails to contacts, I use multiple calendars to keep track of all I want to do, and I use email and contacts to share those calendar events. Having them separate doesn’t work.

Beyond having some form of integration, my list of ‘requirements’ isn’t that big:

• Supporting standards. For email we have SMTP, JMAP, IMAP and POP3, CalDAV for calendars and CardDAV for contacts. Since I use multiple platforms, it has to use these standards.
• Having full-text search. Attachment search is nice to have, but not a dealbreaker.
• Having a modern look, with support for dark mode - not only for the interface, but also for the content of emails.
• Supporting multiple identities easily.
• Having a notion of conversations, and properly visualising them.
• Supporting mail filtering rules. If it can interact with Sieve on the backend, even better.

There are some optional features that I’d like, but could do without:

• Showing contact images in the message list (or placeholders). Many modern clients do this these days.
• Snoozing of mails. Client side, not server side, I know, but it’s nice if it has it.

All these criteria make it really hard to find a client that I want to use on a daily basis.

Native clients

Kontact Suite

This is a part of KDE, my desktop environment of choice. It brings together KMail, KAddressBook and Korganizer.

While this suite of applications is technically very capable, the visual aspect of them is lacklustre. I originally started using KDE around 2000 (with KDE 2.0), and in many ways it feels like those applications haven’t had a UI refresh since. I stopped using KMail around 2009 and hadn’t looked at it since. I’m mindboggled by the fact that the HTML bar is still there in 2026.

Also, no support for dark mode mail content.

Thunderbird

Probably the most promising of them all. Has dark mode support for UI and mail, handles contacts and calendaring fairly well. Interface still looks extremely outdated. Doesn’t feel pleasant to use. Dark mode theme is “ok”, but conversation threading is unclear. Contact images can be added using an extension, but that same extension causes Thunderbird to become unbearably slow.

Mailspring

Beautiful client, handles mails well. Beta support for contacts (I managed to crash it a few times), no calendar support as of yet. Has AI bollocks, which fortunately you can ignore completely.

BlueMail

I read a lot of good things about it, but never managed to get it to work - neither with the RPM nor the flatpak image. I don’t do snaps. Also proprietary, and includes AI bollocks it seems.

Evolution

The PIM for the Gnome desktop environment. Doesn’t fit in well with KDE, is extremely opinionated (which is the Gnome way but not my way) and does not support dark mode mail content.

Web clients

MailFlow

I came across Mailflow in the weekly SelfH.st newsletter. It’s beautiful, has a good mix of features and it’s fast. Unfortunately, it has only barebones contact handling, and calendaring is still for the future. No support for dark mail content.

Definitely keeping an eye on it.

RoundCube

A venerable email webclient, which works well for mail. Calendar and contacts are handled through plugins, which need separate configuration - sometimes not even through the actual web interface but through editing config files. Contact handling is mediocre at best. No support for dark mode emails, unless through another plugin.

I tested version 1.7.2, which is the latest at the time of writing, but it felt so slow and old.

Bulwark

A mail webclient made for the JMAP standard, and (usually?) paired with Stalwart. I connected this to my current Fastmail account, and it is absolutely brilliant. Unfortunately, this would mean that I’d have to self-host Stalwart somewhere.

So far, no dice. If you have any other recommendations, I’d be glad to hear them.

This is the seventh installment of a series of posts about taking back control of my web presence. In Part 1 I tackle hosting, in Part 2 I do things with DNS. In Part 3 I rediscover Proxmox, in Part 4 I move Mastodon around. In Part 5 I Tunnel All The Things with Pangolin and in Part 6 I sort out where to store code.

As I detailed in my previous posts, I used Let’s Encrypt. But, as the astute reader can see, I’ve been wanting to reduce my dependency on non-European companies.

Let’s Encrypt was not high on the list of things to replace - it’s free, it works and it is a force for good. It being under US jurisdiction felt mildly annoying.

I recently came across Actalis, a company based in Italy that offers a free plan where you can get unlimited SSL certificates for domain validation via ACME.

Switching my stack over was as simple as registering an account and adding this to my Caddy configuration:

email my-email-address@domain.tld
acme_ca https://acme-api.actalis.com/acme/directory
acme_eab {
  key_id XxxxxxArihquYoJxxxxxx
  mac_key yyyyyyyyKPXMgkkxxxxxxLQaIuGhHQbbbbbb
}

(You’ll find both values in the Actalis console.)

After reloading Caddy, I got an error: “Obtain: base64-decoding MAC key: illegal base64 data at input byte 43”. A quick search taught me that I had to remove the padding (=) from mac_key.

I also had to update my Certificate Authority Authorization (CAA) DNS records to include issue "actalis.it".

A caddy reload later, my sites were serving Actalis certificates.

The most common question founders ask me is “What’s your opinion on rug-pulls and license changes?” My answer is that community backlash and controversy are often exaggerated, that license changes are not automatically bad, and that they should be used for the occasional harmonious re-calibration.

So let’s look at relicensing, why it makes sense, when it goes wrong, and how to do it gracefully. I will include some lessons learned from our relicensing projects at Grafana Labs, though this blog post represents only my own opinion and not those of my past employer, Grafana Labs.

What is relicensing?

Note that we are talking about enterprise software (B2B) only here. B2C is different, and I have little experience with it.

Let’s dig into this, but first we need to address some misconceptions and friction points:

• License changes are always “going forward”: any code released under some license can’t be taken back. A more practical way to think about relicensing is as a fork:
  • the company stops maintaining the code base. It’s practically abandoned. Because it was unsustainable.
  • a company sees a path to save the community and project (though under a different license), so they step up and fork the project to continue it. It just so happens that this company is the same as the previous one, so they can keep the name, the established commercial support system (though sometimes under a new pricing structure), the existing repo, build systems, issue tracker, etc. Which makes the fork more seamless.
• Any person or company is free to reduce or terminate their efforts in any open source project. By law, they only have to honor their commercial agreements.
• The only reason they can fork the project and apply a new license, is because it is their full legal right. Usually they’ve had that right for years, and have full discretion about when they apply it. If you are a consumer of open source and this comes as a sudden, shocking surprise, it should make you reflect on how well you understand the products and services you have chosen to depend on, above all.

Perhaps this makes it sound more palatable. In case it doesn’t, let’s consider some events that probably have happened to you:

• A commercial service/product you depend on becomes decommissioned, bankrupt, too expensive, or is no longer the best solution.
• An open source project you depend on becomes unmaintained, too expensive, or is no longer the best solution.

Anyone who’s been in technology for a while, will encounter these scenarios routinely. It’s the reality of using commercial products that live in an economic market or non-commercial projects that depend on the spare time and goodwill of individuals. Mature engineers or tech executives will deal with them without much fuss. Migrations can be annoying or painful, but usually don’t cause an outrage. They are considered part of the job. You will migrate to an alternative solution; supported by an existing vendor, a new vendor, a different community, your team, or a combination. Smart engineers and executives will build a tech stack specifically designed to handle these scenarios elegantly, with abstractions in place, to keep the door open for eventual migrations. Any mature team will thoroughly consider exactly these ramifications when building upon a technology that locks them in.

A relicensing event is like any of the above, but with some positive differences:

• renewed trust that your vendor will remain in business (unless they do something incredibly stupid)
• instead of being forced to find and implement an alternative, you are offered an additional solution, one which doesn’t require a migration, doesn’t impact your tech stack, your team’s planning and has minimal impact to your existing commercial and customer support relationship with your vendor.

When relicensing goes wrong (the “rug-pull”)

So, how is it that relicensing events cause controversies, when in fact they are easier to deal with than the more disruptive events which we somehow tolerate better?

I think there are multiple contributing factors, that become deadly when combined:

1) The community feels misled and betrayed

This is usually when they were asked to sign a CLA in which they had to hand over ownership or distribution rights of their contributions, especially so when they were led to believe “it’s fine because the license is permissive and we won’t change that”. Signing such a CLA is your clue that a license change will happen. Not a matter of “if”, but “when”. Note, I’m not unequivocally saying CLA’s are bad. I think empowering a vendor can be a good thing. As a contributor, you simply need to not be naive about the future. As a community, you need to be aware you can always fork. Whether before or after the CLA requirement, or before or after a relicensing event. But forking only works when you can put together a community of skilled engineers and can truly produce a better package. Those are the rules of the open source game.

2) The event comes with pricing increases or features moved from previously free/open to paid/closed.

Speaks for itself.

3) The new license is - or appears - too aggressive.

Different communities and individuals will tolerate different things dependent on what they’re used to. The OSI has a long legacy in maintaining and defending the most formal and widely accepted definition of “open source”. While it’s been disputed by myself and by many others, it is the most widely accepted one. Nowadays, using the words “open source” around a non-OSI approved license stirs up religious wars without clear winners. Businesses may avoid or proceed doing this depending on their appetite for media controversies.

Regardless:

• Many users swear by OSI-approved licenses (even if it’s only as an open core, wrapped by closed proprietary code). Part of the reason, I think, why our relicensing from apache to AGPL at Grafana was successful and generally pretty well received, is that we stuck with an OSI-approved license, even though we retained the open core model. Sometimes you just need to give people what they want.

• Personally I think there are a lot of interesting Source-Available options such as Fair Source which strike a better balance between the rights of both the vendor and its community than open core with an OSI-approved license in the center only. It seems some communities are slowly warming up to these solutions, though education around it is critical, and the progress is slow. But ultimately your community of users and customers is the final judge.

4) Intentionally vague or incorrect announcements

Some vendors actively try to mislead their users and customers. Throwing buzzwords like “open” around in a confusing soup of words is not good for your users, and therefore for your business.

5) The change feels all “take” and no “give”.

For example, Grafana Labs didn’t just fork the Apache licensed Cortex database into AGPL licensed Mimir, we also made sure to open up previously-proprietary functionality into the new open source project. As part of this relicensing we raised the bar for what we considered “enterprise only” and opened up everything that no longer met this new bar. I believe this shows respect to your community and is required for successful business long term. Relicensing should be more about “how can we improve the interests of both parties”. A company thinking of a relicensing as a one-way street undermines its own business.

Cynical observers may note that perhaps the trick is to always “juice up” a fat shell of proprietary features when using a permissive open core, just to have something to give to offset a relicensing, but I think it speaks to always seeking the right balance: if you use a permissive license, you need more proprietary features; when you make the license more protective, you can and should include some of those features.

6) Just the fact that there is a change.

I have also learned that sometimes it’s just the fact that something is changing, not the actual thing, that causes some uproar. When we started Grafana Labs in 2015, our first metrics database - Metrictank - was AGPL licensed from the start, which never caused an issue. Years later, when we forked the 2nd metrics database we worked on - Cortex - into Mimir and switched from Apache to AGPL for it, we forgot to mention that as part of this transition we were deprecating Metrictank, and merging its best already-AGPL features into (the easier to deploy) Mimir. That could have reduced the (already small) commotion a bit.

Relicensing is inevitable. But market forces dictate the only way to do it, is to do it right.

As a vendor who controls open source software projects, you don’t play in a vacuum. You are beholden to a lot of external forces. There’s constant changes in market conditions, sentiments and best practices, financing opportunities, competitors gaining or losing strength, cloud vendors giving you more credibility or threatening your business, shifts in available technology, M&A opportunities, talent, export controls etc.

Inevitably, you need to periodically re-assess and adjust every process in your business. E.g. your ICP (Ideal Customer Profile), GTM (Go-To-Market), your offering, support, team structure, partnerships, vendors, etc. The only constant is change. The more a change is externally facing / customer-impacting, the more deliberate and careful you should be - to minimize disruptions - but beyond that, relicensing is in principle not all that different from other inevitable changes you need to make.

Ultimately, everything you do, your reputation, the quality and pricing of your offering, the quality of your communication, the appeal of the open source project, etc boils down to an overall “score”:

• Are you too aggressive or expensive? Somebody will fork and/or lure your customers away with an alternative.
• Are you not aggressive or expensive enough? You won’t be able to defend your business, and will be overtaken by someone who can build something better (possibly a fork)

For vendors, this means you will only do well if you hit the sweet spot. You should always aim to provide a balanced offering and treat customers right. A relicensing event is not an opportunity to become more aggressive. The laws of business don’t change, you need to retain a compelling offering.

For customers, it means whichever vendor gives you the best overall experience will serve you. Hopefully, it remains the same vendor. That’s easiest for everyone. But if you are “mistreated” by a rug-pull (or by other moves the vendors make that you don’t like), there will be short term and medium term turbulences (e.g. due to lock-in, painful migrations, compliance constraints, procurement/legal friction, etc), but eventually, the market rebalances. There are strong market forces nudging vendors to treat customers right; if they don’t, another one will.

It also means that the only reason to do a relicensing is to make customers more happy on the long term. The happier you can make your customer, the better your business will be. If you upset your customers, the worse your business will be. Any badly received relicensing event is from vendors who think it’s OK to upset this balance because they have the lock-in or the market sentiment. Short term they may be right, but long term, they are wrong. Even if short term they are able to grow profits and re-invest into their projects and offerings, the burned trust is never worth it.

Relicensing can be good: from permissive to protective.

The playbook seen among many commercial open source vendors is to start with a permissive license (apache2/BSD/MIT) and later relicense to something more protective. It is often said that this is “bad” or a de-facto rug-pull. I think this is faulty thinking. Grafana - and a few other companies - show that it’s possible to relicense gracefully, though it’s a tricky maneuver. There are more examples of relicensing gone wrong, but those often also involved bad communication and overly aggressive changes such as non-OSI-approved licenses.

I would go further and say this can be a good model worth designing for.

Early on, you want to boost adoption and remove restrictions. This grows community, adoption, and helps with testing and validating a market. This is good for users, the vendor, and early customers. Later on, the code is relicensed (assuming CLA’s are in place, although now with AI things are changing). This allows the vendor to protect its business. Community members are often quick to complain about the “rights lost”, but here the bigger picture still matters. If the vendor can protect its business better, it can invest and grow the open source project better. We saw above how limited their ability is to abuse any “rights gained” over the long term. In many cases, users and community end up better off: either the original vendor serves them better, or they are better served by a fork or competitor.

How to relicense?

Relicensing can be done in a way that isn’t seen as a “rug-pull”, but instead as a “cleaning house”. A transformative make-over that leaves everybody happier.

Here are my tips:

• Try to avoid it by choosing a balanced license from the start, but better change something down the road than have analysis paralysis. Especially when getting started.
• Treat your community and customers with respect. Trust takes years to build, seconds to break, and forever to repair
• Never make promises you can’t keep. Don’t claim you will never relicense.
• Talk with your community. Figure out their licensing preferences. See how they react to license changes in neighboring projects.
• Communicate clearly. Whether it’s about CLA’s or new licenses, especially if they are novel or not OSI compliant. If going for Source-Available type licenses, truthfully educate your community about your real intentions and goals, and the implications of the chosen license. Anything less will backfire.
• If not using OSI-approved licenses, either steer clear of “open source” definition debates altogether, or leverage the inevitable debates between those who follow the OSD and those who don’t. Pick your poison here :-)
• Consider the “giving” part as much as the “taking” part. Happy customer == Good business.

Finally, and this is actually how I usually start my consulting engagements: ask yourself if you really want to be an open source company and why. Open Source businesses are about “growing the pie” (creating more value, growing a community around a sustainable project), and consuming a small or tiny portion of that pie (capturing some of the value). Restricting previously free features is not a long-term smart move. It undermines or reverses the growth of the pie, and you then need to consume ever-growing chunks of it. This is not an OSS business based on growth. It’s a proprietary business. Which by itself is not “wrong” (though I believe COSS leads to more successful businesses), but it is a very tough pivot and one worth avoiding. Especially as it relates to “cloud vendors eating our lunch”. You enabled them to legally do it, it’s literally how you built your business. Deal with it, gracefully, or someone else will.

We watch websites for a living at Oh Dear , which puts us in a unique position: we have data on a lot of different outages.

En plots was er de drang om iets te schrijven. Het is niet nagelezen, het is gewoon mijn gedachtenstroom vandaag, op mijn blog. Klinkt het niet, dan botst het, en dat is ook oké!



fertiliteit

Ik kwam daarnet deze video tegen van de Financial Times:
https://www.youtube.com/watch?v=6lFXmDk-tps

Het gaat over de correlatie tussen smartphonegebruik en het aantal kinderen dat geboren wordt. Hun theorie is dat het aantal vrouwen dat kinderen krijgt daalt, omdat ze meer in de smartphone-influencer wereld leven dan dat ze mensen in levende lijve ontmoeten. Ze maken ook direct de stap naar meer zelfmoordgedachten bij hevig smartphonegebruik.

De paper zelf is van april dit jaar en kan je hier vinden (wel 63 bladzijden):
https://homepages.uc.edu/~moscoshn/Personal_webpage/papers/Smartphone_web.pdf

Ik ga ervan uit dat de cijfers kloppen, dat er inderdaad een correlatie is tussen het invoeren van de smartphone in een land, en de problematiek om een partner te vinden om kinderen mee op de wereld te zetten. En het klopt uiteraard dat iemand die verslaafd is aan Instagram/Tiktok/... een ander beeld heeft van 'de gewone mens' dan iemand die nooit naar deze media kijkt. Maar er is meer aan de hand.



veiligheid

Er is veel angst vandaag, meer dan in de jaren 80 toen de criminaliteit veel hoger lag. (Noot: Er zijn nu meer aangiftes van misbruik, maar het gebeurde vroeger wel vaker denk ik.) De media, zowel de klassieke als de sociale media, lijken mensen uitsluitend in emoties te duwen: bang, bedroefd, boos en soms een keer blij. Wees bang voor mannen, voor terrorisme, voor hoge prijzen. Bedroefd voor ongevallen met kindjes. Boos op Poetin en China, en Israel. Cijfers en statistieken tellen niet meer, de anekdotes vol emotie krijgen alle aandacht. Waar in de jaren 80 de krant nog schreef: "Er zijn 700 bedrijven failliet gegaan deze maand, en 900 nieuwe opgericht!" wordt alles na de komma vandaag niet vermeld. Mensen bang maken levert immers meer 'clicks' en 'views' op.

Zie bijvoorbeeld vandaag op VRTNWS over 'Marie' en 'Katrien', ik durf het geeneens te lezen na 'Valerie' enkele dagen geleden. Ik was kapot na dat Valerie-verhaal, zucht. Die journalist had dat wel verdomd goed geschreven, de beste horror kan er niet tegenop!! Dat soort gruwel verhalen voor vrouwen, veroorzaakt door mannen, is de laatste twintig jaar schering en inslag. Alsof het in mannen-genetica zit.

Lezen op eigen risico:
https://www.vrt.be/vrtnws/nl/2026/06/22/getuigenis-stiekem-genomen-naaktbeelden-fora-en-justitie/

Het deed me denken aan het huidige onveiligheidsgevoel dat (vooral jonge?) mensen hebben. Ja er was ook criminilateit en wreedheden en misbruik in de jaren 80, maar we zagen dat maar eenmaal per dag op TV, tijdens het nieuws om 19u30. Als dat al in het nieuws kwam. Vandaag de dag is er minder criminaliteit in België(*), maar al wie vaak op een smartphone kijkt (incluis de vrtnws app), wordt er wel veel meer mee geconfronteerd. De TV had natuurlijk ook dat effect, maar dat was toch veel langzamer, veel gradueler en jarenlang enkel 's avonds in familiale kring. De smartphone is er als je wakker wordt, als je op de WC zit, als je op de bus wacht, als je niet kan slapen, kortom altijd, en zeker al die tijd die je *alleen* doorbrengt.


(*) Ik vind geen goeie cijfers over de evolutie van het aantal misdrijven per jaar sinds de jaren 50-60-70-80 tot nu.
https://www.vrt.be/vrtnws/nl/2023/06/21/studie-nicc-criminaliteit-in-belgie-daalt/



vertrouwen

Toen ik pas mijn rijbewijs had (1989), heb ik honderden lifters meegenomen. Zo goed als altijd tieners, de helft of meer waren meisjes. Zeker in mijn unief periode dat ik vanuit Leuven vrienden afzette in Zoersel, en dus vrijdagavond laat via Sint-Antonius, Westmalle, Oostmalle naar Wechelderzande reed. Ik heb die rit zelden alleen moeten doen, en vaak waren dat leuke gesprekken. Ik had zelf ook jaren gelift, honderden keren meegereden met vreemden, nooit was er enige spanning. Ik heb in vreemde auto's gezeten terwijl de eigenaar een winkel binnen ging, sleutels erop of zelfs met draaiende motor. Dat vertrouwen hadden de volwassenen toen in een onbekende zestienjarige. Logisch dus dat ik een 'pay it forward' mentaliteit had toen ik zelf een rijbewijs had. Gisteren was een vriendin hier heel de dag klimaatvluchteling, die rijdt nog rond met haar auto. Ze zei dat het al twintig jaar geleden was dat ze nog een lifter had meegenomen. Er zijn ook gewoon geen lifters meer.



cancelcultuur

Er zijn uiteraard veel alternatieven zoals Uber/deelwagens/deel-whatever, maar toch. Dat soort vertrouwen in elkaar is weg. Maar dat heeft evenveel te maken met mobiliteit als met de smartphone. Toen wij vroeger 'uit' gingen was dat vaak naar fuiven van 'Union Servet' in Pulderbos/Westmalle/Sint-Antonius. Daar was je dan, op een fuif met een paar honderd mensen, maar ook met je vrienden, je buren, je klasgenoten, de mensen van de harmonie, ... m.a.w. je was in een super veilige omgeving. Je kon als vrouw het 'risico' nemen om met een stoere/stoute man te dansen want je wist dat als die iets te ver ging, dat zowel jouw vrienden als zijn vrienden tussenbeide zouden komen. Je hield elkaar in 't oog, wie gaat met wie buiten, je kende van vele mensen de ouders en wist waar ze woonden. (En die ouders kenden ook uw punten van uw laatste test Frans of wiskunde!)

Un petit mot de nos sponsors…

Comme pour les stades ou les équipes cyclistes, il est important de nommer les vagues de chaleur et les canicules selon les sponsors qui ont rendu cela possible. C’est après tout la moindre des choses.

Ne dites plus « la vague de chaleur de mai 2026 » ou « la canicule de juin 2026 » mais « la canicule Bolloré 26 » et « la canicule TotalEnergies 26 ».

Avouez que « TotalEnergies 26 a déjà fait 115 morts » en gras dans la presse, ça fournit une belle visibilité médiatique au sponsor !

Du coup, Patlabar s’est improvisé public-reléchionne pour les sponsors et a fait de chouettes stickers à imprimer et à coller là où le rappel est le plus utile. J’espère qu’il va leur envoyer sa facture.

Il a également fait les stickers pour celle de mai :

Et il prévoit déjà celle de juillet :

En 2026, TotalEnergies a clairement écrasé Bolloré. Lafarge pourra-t-elle tenir le niveau ? Rien n’est moins sûr, les supporters lancent déjà les paris.

Pour les prochains stickers, vous pouvez suivre Patlabar sur Mastodon:

• @patlabar sur Mastodon

PS: À propos de sponsor, l’équipe cycliste Israël-Startup Nation avait, en 2025, subit les foudres du public sur la Vuelta, entraînant son retrait de l’épreuve et le changement de sponsor pour 2026. Je me demande si on verra un jour des protestations similaires pour des équipes comme TotalEnergie ou Uno-X, qui sponsorisent le vélo en vendant de l’essence.

Bekers van mijn vijf oudste Nepenthes.

Trompetten van enkele Sarracenia.

I’ve been moving our CI off GitHub-hosted runners onto our own arm64 hardware. The plan was straightforward: a pool of ephemeral runners on a dedicated CI box, and each test shard spins up its own MySQL, Redis, and ClickHouse as service containers, all under rootless Docker.

Laravel Octane promises a faster Laravel: keep your app booted in memory, skip the framework bootstrap on every request, do less work per request. We run a fleet of uptime-checker boxes at Oh Dear that do nothing but fire HTTP, TCP, and ping checks at the sites we monitor, so I figured they’d be a good, low-risk place to try it. We moved a handful of them from PHP-FPM to Octane on FrankenPHP , measured it properly, and then moved every one of them back.

You can already point an AI agent at your Filament admin panel and have it click around like a human. Take a screenshot, find the button, fill the form, submit, screenshot again to check it worked. With computer-use or a browser MCP, that works today. It’s also slow, brittle, and spends a small fortune in tokens describing pixels to figure out where the “Save” button is.

Through work, I have paid license to windsurf (recently renamed to "devin"), an application for LLM-based (aka, "Agentic") development.

I hadn't been using it that much, but in an effort to more clearly understand how this whole AI development thing works, I decided to give it a closer look recently.

My conclusions:

In its current form, this whole LLM wave is problematic for multiple reasons. But ignoring that, and looking at the technology only, I can say that:

• it is a paradigm shift;
• it is, at the technological level, a positive evolution;
• and it is a threat to free software.

Problems

Lest someone (incorrectly) assume that I am arguing in favour of the current state of affairs with regards to LLMs, let me state this first.

The way LLMs are built today is highly parasitic. Websites are downloaded in whole, at unsustainable rates, regardless of the consent of the people who made the original content. The result is predictable: servers get overloaded, server administrators attempt to implement various mitigations. Some of these mitigations work; some do, for a while; some are entirely useless. In actual fact, the mitigations are an arms race -- if too many people implement the same mitigation, then the people who try to build yet another LLM so they can extract rent will just try to work around the mitigation, eventually they will succeed, and you'll just have to come up with another mitigation. It's a bit like spam; you introduce regex-based spam filters, they introduce spelling mistakes, you introduce bayesian filters, they add a large batch of markov chain-generated semi-nonsense words made invisible by markup, you add filters to block emails with such markup, they move the text into an image. We have working mitigations today, but eventually we'll run out of ideas.

LLMs glob up everything they can while ignoring the license of the source material. The people who push those LLMs claim that pushing the source material through the machine learning algorithms makes the output of the algorithm distinct enough from the source material that the license no longer applies; I'm not so sure that this is true. I guess the New York Times v OpenAI lawsuit will teach us some of the answer to that question here, but even so the ethical questions about "is it OK to bring down another server just so we can download the internet for another for-pay LLM" are still open. And regardless of what the law states, my opinion on "you're using my copyleft code to generate code under a different license" is not something you might like if you agree with the rent seekers' opinion on the subject.

That all being said and true, the technology works. You can have a "conversation" with an LLM that resembles a human one. If you pass it some data, you can use plain english to ask it questions about that data, which is a lot easier than to ask it about that in a formal way. You can request it to generate some code, and it will generate something that looks like what you need and that will be mostly correct for like 95% of the time.

Now, yes, 95% of the time is not 100% of the time, and no, you can't ask it to "write me a piece of software that implements this 300-page requirements document and get back to me when you're done", because it will fail, and you won't know where it has failed, and you'll take it into production and expect everything to be fine because it won't and this one minor logic bug will cause half your servers to spin and consume credits with your infrastructure provider with nothing to show for it.

But that doesn't mean you can't use an LLM to build a large piece of software. It just means you have to understand the LLMs limitations and strenghts, and use them correctly.

Here's what an LLM is good at:

• Generating plausible text
• Interpreting text to figure out what a plausible meaning or summary of that text is
• Giving vague indications as to what the probable context of a given body of text is.

It turns out that that's enough to use the LLM to build a reliable piece of software, provided you do it right.

Paradigm shift

An LLM can generate text by the truckful. The generated text could be code. Given a good enough LLM, the generated text might even run and do something useful.

You can try to blindly run the code, and if it doesn't run correctly, you can paste the error message to the LLM, and it can tell you what went wrong and how you could possibly fix it. This creates a feedback loop: you ask it for an amount of code, you run the code, you receive an error, you tell it that the code is problematic and give it the error message, it makes changes to the code, now you have something that at least no longer fails at startup.

If you ask it to add tests to make sure that your code acts as per your specification, now you get an error if and when the code doesn't act as per your specification. Or, well, at least not as per the part of the specification that was correctly turned into a unit test by the LLM.

LLMs have a context window, so if the error message is pasted in the same conversation as where the code was generated, it is able to reuse the earlier prompts to refine how it should interpret the error message that you received.

You can't really paste the source code of an entire application into the prompt of your LLM, that would quickly overrun its context window. But LLMs also allow you to provide some form of background information -- a document, say -- on which you ask it to reason. It will interpret that document, but doing so uses less of the LLMs context window. So providing the LLM with your application's source code as background information can help it understand better how your code interacts. This is especially helpful if you only provide the LLM the background information relevant to the actual question.

So now if you are able to:

• Create background context with your application's source code
• Have the LLM generate a first draft of your requested change, plus the tests to make sure it works
• Compile (if applicable) the generated code (and tests) and run said tests
• Return any error messages to the LLM with a request to correct the error

Then the combination of "getting it 95% right off the bat" and the above feedback loop means you can generate syntactically correct code, that probably does what you need, in minutes.

I say "probably" for a reason. There are going to be cases where you specify a request without a number of details (because they are implied), and the LLM will get most of those details right but just not implement the one bit because it's an automaton and it doesn't think. Or you will ask it to make sure that two bits of the application look exactly the same, without specifying that they must act the same, now and in the future, and it will just generate the same block of code twice and then in a future change it will change one but not the other.

But if you review the changes, and you have experience as a programmer, you will be able to spot most cases where the LLM got it wrong. And so it's possible, if not necessarily easy at first, to use an LLM to generate mostly correct code.

There are certain places where "mostly correct" code is not desireable. But equally, there are also cases where, "mostly correct" is good enough.

After all, most of the software you run today -- the bits of it that weren't, yet, generated by an LLM -- is only "mostly correct", too, because to err is human and we all make mistakes. If not, there wouldn't be any CVEs and your software would never do anything wrong.

Now, doing the feedback loop described above is certainly something you could do manually. You could open an account on one of the LLM websites, upload the source code of your application, ask it to generate some new feature, download the newly generated feature, run it, and then copy/paste any error messages back into the LLM.

But that's a lot of manual work of the type that computers are pretty good at. So that's what the "windsurf" tool helps you with: you run it inside your IDE -- either a VSCode-based tool that you download from their website which comes with their product preinstalled, or a separate JetBrains plugin that you can install. You can then open your entire relevant codebase in a workspace in your IDE. You then ask the LLM, through the IDE, to generate a new feature in your codebase, and to also generate the test while it's at it. It will use a mixture of LLM interpretation and non-LLM functionality to scoop out the relevant bits of your codebase to send to the LLM as background information, will send it your prompt, will download the generated code and patch or create files, will compile (if required) and run the newly generated code and tests, and will refine the generated code if the tests produce any errors. All mostly automatic; by default, running anything requires explicit confirmation. You can turn that off completely (probably not a good idea), or you can give it a whitelist of things that you don't want to confirm (perhaps OK), and the tool also passes standing instructions to the LLM to never generate any command that deletes a file (which, like with any LLM, can be overridden, but it requires you to be very stubborn and to use more credits than you'd probably like).

All this put together means you can build something without writing any piece of code, provided you do it right.

A technically positive evolution

Don't go and say, "here's a 300-page document, read it and write whatever the document says". It will get it wrong, it will write a massive test suite that it will only run at the end, it will choke itself up trying to interpret the massive amount of failures it encounters, it will fill up its context window and it will start to forget some of the requirements. That won't work.

But what you can do -- what I did, in fact -- is this.

First, create an empty workspace. Don't put any code in it.

Then, tell the LLM to generate a backend framework using technology X and a frontend framework using technology Y that initially only says "hello, world". Also add tests to it, and run the tests.

It will do that. You'll not get much, but it will work.

Then, ask it to add some UI elements. A login page, perhaps. A navigation bar. Small things. Most of it doesn't have to be functional -- but tests must be there for the bits that are, and have it run the tests and evaluate the results.

Rinse, repeat, until you have a working application.

Importantly, in between the steps, you should also run the application yourself and see if the change was implemented correctly. Sometimes it won't be. Sometimes there will be a subtle bug -- I at one point had a the application hang after a few minutes. Sometimes you tell it that there's a subtle bug, and it will discover it more quickly than you could, and it will fix it, and in implementing the fix it will uncover another bug, and then you have to fix that one -- the fix it came up with for the hang was to move something to an async process on the server, which caused the application to start spinning while trying to create hundreds of async jobs (this is when I realized that the hang was a deadlock due to some part of the codebase doing something that indirectly triggered itself). Sometimes it will try to fix the bug you tell it about, and you'll see that it's going off on a tangent that has nothing to do with what you're seeing. It's important to keep an eye on what it's doing, so you can guide it back on track when that happens -- when I told it about the hang, it started investigating the part of the code which sends out emails, thinking that it could hang while waiting for sendmail to finish, but the hang was happening when the application was idle, not when it was sending out emails, and only when I told it about it happening when it was idle did it find the deadlock.

So it's not a fully automatic process, and it needs to be guided by someone who knows what they're doing. But if that is the case, you can come up with something that works. I spent evenings and breaks for about a week, and I managed to create a working application which, had I written it by hand, would have taken me a few months of full-time work to come up with. And I now have a side project, fully complete and working, that I had been thinking about doing for more than a decade, but never got around to actually doing, because of all the work that would be involved and I just didn't see myself having the time for.

It's not perfect code. But it's mostly good enough, and it will perform the job it needs to. And it looks far slicker than most of the side projects I've done in the past, because in the past I would prioritize between implementing new features or making something look slick, and I would decide that the new feature was more important because it's only for me and there's only me and nobody cares if it looks good or not and I don't have three weeks to come up with something that looks better. But here, I found myself sometimes spending 10 minutes writing a prompt with instructions on making things look better. Because what's 10 minutes when you just spent an hour writing down and refining specifications for functionality and tests?

There are a number of other things in which an LLM can help a programmer.

For instance.

I received a bug report recently in a project I'm paid to maintain that I couldn't make heads or tails of. I opened the source code in my windsurf IDE, pasted the bug report in the prompt, and then requested the tool to analyze the source code and the associated logs and tell me how the described behavior could be happening. It turned out that I had overlooked something, but with the help of the tool, I found the bug in minutes.

I was trying to understand a particular part of a large codebase that I didn't really grasp very well. I loaded the codebase in the tool, and asked it to explain to me how a particular action is performed by the code. I requested specific functions and line numbers. I now have a far better understanding of how the code works, and will be able to write that patch that I've been wanting to write for years -- without using the LLM.

I have been struggling for, literally, years with understanding why another tool that I maintain was misbehaving in a particular way but only in Firefox. I opened the codebase in Firefox, explained the buggy behavior in plain English, and asked it to explain how this could be happening. It picked up some obscure corner case behavior of ffmpeg and mp4 containers that I was not aware of and that perfectly explained why things were misbehaving in the way that they were.

At the same time, there are limitations. Giving an LLM a codebase that was originally generated by an LLM (either the same one or another one) seems to work well. Giving it a codebase that was written by a human and expecting it to correctly update it seems to be more error-prone. I did one or two of those as a trial, and it is more problematic than anything.

An LLM is also not intelligent, notwithstanding the popular term of "Artificial Intelligence". On multiple occasions, I've asked it to write a test case for some code that was not set up to do so; and rather than suggesting a refactor is required, it would instead copy the code that needed to be tested and then test the copy, rather than the original. The tool has made multiple similar errors. I have sometimes people describe agentic coding as "similar to interacting with junior programmers", but that is not the case. A junior programmer will either fill in the gaps in your specifications, or ask for clarification when something seems off. The LLM will not do that; it will do what you ask, exactly that and nothing more. If you missed a corner case in your specification, then all bets are off.

I remember learning about programming language generations in college. A first-generation language is "machine code", a second-generation language is "assembler", a third-generation language is any high-level language such as C, Perl, or Pascal. I've forgotten what set a 3rd-generation language apart from a 4th-generation language. But I remember the definition they gave me for a 5th-generation language: "you tell the computer what to do, and it will do it". At the time, I thought it was ridiculous. Nobody could ever write something like that.

But it's here.

And it's a threat to free software.

A threat to free software?

Yes.

There is the obvious part where most of the well-known LLMs are non-free software. I mean, there are some "open source" LLM models. The windsurf tool that I used doesn't allow you to use them (directly), but they're there. There are also open source applications that implement what the windsurf editor does. So it's definitely possible to work like this without resorting to non-free software and non-free services, even though the non-free LLMs might be a bit ahead of the curve of the free ones. But that's not what I mean.

And there is also the obvious thing which I mentioned earlier in this post, which is that the people who try to build LLMs are doing it in unethical, disgusting ways, causing downtimes and disregarding licenses for whatever they can get their grubby hands on. Ideally we wouldn't be in that situation, and ideally this wouldn't be a problem, but we are where we are.

And there's the obvious thing where the OSI sold itself out and declared that a machine learning program can be open source even when the very things it was built from -- the training data -- is not available. That's a major issue that the free software community needs to fight against, but there's not really anything that that is a threat to free software. You just build your own, free software, LLM, and you're done.

The actual threat is in funding and developer support.

Most large businesses do not care about free-as-in-freedom software. They like the free-as-in-beer part, and they appreciate that the free-as-in-freedom bits can make the software more customizable. They are (mostly) happy to do sponsorships of the free-as-in-freedom projects that they use if that means their free-as-in-beer usage of the software gets improved.

But why would you care about all that when you can just generate the code you need, rather than interacting with an open source community that may or may not care about your business's interests?

Where to go from here

Although I think the moral and environmental issues with LLMs are real and problematic, given the experiments I did I am not convinced that the concept of interacting with a computer system in natural language and to use it to generate code is necessarily deficient. There are pitfalls, but they can be managed. It is possible to use such a system to create throwaway, proof-of-concept type "good enough" code bases. It can be used to interpret code bases and to understand bug reports.

I believe that the major issue with LLMs has to do with that saying about hammers and nails:

If all you have is a hammer, then everything looks like a nail.

LLMs are an outgrowth of machine learning, pushed by large corporations. These large corporations have a lot of money. If all you have is money, then every problem can be fixed by throwing more money at it. The initial language models were promising but not (yet) good enough, and it seemed that one way in which they could be improved was to increase the scale of the statistics: throw more hardware (and thus money) at it, and rather than improving the efficiency of the models, just scale up.

Scaling up is something that megacorporations are very good at. It's only a money problem, after all. Does that mean that "scaling up" is the only way to improve the models, though? I'm not convinced.

Some hardware, such as most modern Apple and Samsung devices, ship with accelerator hardware for machine learning algorithms. There are some models that are small enough to be able to run on these devices. I don't see why it should not be possible to create a small(er) language model that can do some useful part of the above-described use cases; if not locally, then at least on a server that one can run on-prem rather than requiring that you pay rent to one of the LLM companies.

The Software Freedom Conservancy has published an aspirational statement on machine learning-assisted programming that, I think, gets a lot right. It's not quite a definition, but it's something to keep in mind.

Perhaps that's the way forward?

More questions than answers at this point, anyway.

We went on holiday to the Swiss Alps earlier this month, in Ausserbinn not far from the border with Italy. I won’t bore you with a description of what we did or saw, but I do want to share the souvenir we took home with us. While driving around we scanned the radio for nice music and we discovered “Open Broadcast”, a 24/7 non-stop radio station. They are non-commercial and have a very eclectic…

Source

Google PageSpeed flagged a stylesheet on ohdear.app the other day: front.css, the bundle for its public-facing pages. That surprised me, because Cloudflare sits in front of ohdear.app and Cloudflare does Brotli, and a Brotli’d copy of that file is around 40 KB. Browsers were downloading just over 50 KB of gzip instead. So why wasn’t Brotli kicking in?

Every server I run, including the fleet behind Oh Dear ’s uptime checks, has the same set of debugging tools installed before anything goes wrong. Not because the application needs them, but because the one time you reach for strace is at 2am, the box is misbehaving, and apt install is the last thing you want to be doing while you work out what broke.

I spent a chunk of the last few weeks upgrading a fleet of Ubuntu servers in place, one LTS to the next, with do-release-upgrade. Dozens of boxes, mostly stateless, mostly boring once you’ve done the first few.

Alex Hormozi has a solid definition of confidence:

You don’t become confident by shouting affirmations in the mirror, but by having a stack of undeniable proof that you are who you say you are.

Back in 2016 and 2017 I recorded a podcast called Syscast : interviews with people I admired in the Linux, open source and infrastructure world. Matt Holt about Caddy , Daniel Stenberg about curl , Seth Vargo about Vault , and a handful more. Ten episodes, roughly ten hours of audio, and then life got in the way and I put it on pause.

Back in 2015 I wrote about running Varnish 4.x on systemd , when the RedHat-family packages moved your startup options out of /etc/sysconfig/varnish and into a new /etc/varnish/varnish.params file that the unit sourced.

A long time ago I wrote a Varnish tip about seeing which cookies get stripped in your VCL . The idea is still one of the most useful things you can do with varnishlog: compare what the browser sent against what reached your backend, so you can confirm your cookie-stripping rules do what you think.

I wrote a piece over on the Oh Dear blog about a failure mode that most uptime monitoring gets wrong: a domain gets pulled from its registry’s zone, but its authoritative nameservers keep answering, and cached resolvers happily serve the stale delegation for days. Your monitoring says green. The domain is gone.

Years ago I posted a handful of Varnish 3.0 one-liners for varnishtop and varnishlog . They were all variations on the same idea: pick a log tag like RxURL or TxURL, then grep for what you wanted.

Back in 2016 I gave a talk called Varnish Explained and wrote it up slide by slide. It still gets traffic, which is nice, except the version numbers on those slides are now a decade old and the project doesn’t even go by the same name anymore.

When I wrote about running HTTP/3 with Caddy in 2020 , it was a ritual. You opted in with an experimental_http3 global option, the protocol was still draft h3-27, and to test it you needed a custom-compiled curl and a browser nightly with the right flags flipped. It worked, but it was clearly the bleeding edge.

Update: the fix described in this post has since been merged into Laravel and ships in the next 13.x release. From that release on, a child class’s plain $timeout property correctly overrides an attribute inherited from a parent, so the specific footgun below no longer bites. This post stays up as a historical write-up: how the bug behaved, the subtle PHP reflection edge case behind it, and the fix that closed it.

Ten years ago I wrote about Google’s QUIC protocol , back when it was an experiment you could realistically only test against Google’s own servers. I was excited about it, and I ended that post hoping the spec would get standardised and show up in other browsers and servers.

At Oh Dear , our status pages can run on a customer’s own domain, and we’ve always served on-demand ACME certificates for them: someone points their domain at us, and Caddy provisions a Let’s Encrypt certificate for it automatically. We’re now adding a second option, letting customers bring their own certificate. For that, Caddy doesn’t provision anything: it fetches the certificate from an HTTP backend in our app.