Open Source software is free to download. But the infrastructure that makes it usable is not.

When developers install or update dependencies through npm, Composer, pip, or Cargo, those tools rely on package registries that host and distribute millions of software packages. When maintainers collaborate, they depend on hosted services: Git repositories, CI pipelines, and other tools to build, test, and release software.

Most of this infrastructure is invisible to end users, and almost no one thinks about what it costs to run.

But it is not free. Someone has to operate the servers, pay for bandwidth, respond to support questions, patch security issues, and keep everything reliable.

Much of the modern software ecosystem depends on these services working reliably. And yet the organizations operating them are almost always scrambling to fund them.

A patchwork of fragile arrangements

Every large Open Source project has found some way to keep its infrastructure running. Usually that means a mix of donated services, sponsorships, fundraising, cross-subsidy, or patronage from a single company.

The table below highlights the primary funding mechanisms various Open Source projects depend on, even though most projects combine several.

The mix differs across ecosystems, and some rely on several mechanisms at once. But one thing stands out: none of these approaches tie funding directly to how much the infrastructure is used.

PyPI, the Python Package Index, illustrates the sponsorship model. It handles billions of downloads a day on infrastructure donated by Fastly, AWS, and Google Cloud. The Python Software Foundation described this arrangement's fragility in a post last October: if a single sponsor decides not to renew, it would cost them tens of thousands of dollars a month to replace the lost infrastructure.

Packagist, the main PHP package repository, follows a different approach. It is run by a private company that also sells a commercial product called Private Packagist. Revenue from the paid product subsidizes the free public registry. It's one of the more sustainable models out there, though it means a public good depends on one company's continued success.

npm tried to operate as an independent company, ran into serious financial trouble, and was eventually acquired by GitHub in 2020. The end result is that critical JavaScript infrastructure is now owned by Microsoft.

WordPress.org runs on a different version of the same dynamic: corporate patronage. Automattic, by far the ecosystem's largest commercial beneficiary, subsidizes most of the infrastructure. It works, but it also means that whoever funds the infrastructure controls it.

The FAIR project, a federated package manager backed by the Linux Foundation, was designed to give the WordPress ecosystem an independent alternative. The software works but its organizers recently stepped back after failing to secure long-term funding commitments.

RubyGems took the community fundraising route, launching a program last year asking businesses for $2,500 to $5,000 annually, with about 110 supporters needed to cover the registry's operations.

Drupal, the Open Source CMS I help lead, depends on the Drupal Association to run much of the infrastructure behind the project: Composer endpoints, GitLab repositories, CI pipelines, automatic update notifications, and more. Running all of this costs roughly $3 million a year. Funding comes from a mix of donated infrastructure, community funding, DrupalCon revenue, and sponsorship.

When the economics break, the consequences become visible. In February 2026, GNOME began redirecting Git traffic from its own GitLab to GitHub mirrors to reduce bandwidth costs. As a result, GitHub and its owner Microsoft now absorb some of GNOME's bandwidth cost.

Taken together, these examples point to the same underlying problem. Most Open Source infrastructure does not have a real business model. It survives through donations, corporate sponsorship, and community fundraising, rather than revenue tied to the value it delivers.

From steward to service provider

One direction that makes sense to me is a simple value exchange: keep core infrastructure free for individuals and small projects, while organizations using it at scale help pay for what they consume. Not as a donation, but as payment for the infrastructure their software depends on.

Some people will instinctively resist the idea of charging for the infrastructure behind an Open Source project. That reaction may feel familiar to anyone who remembers the early debates about paid contributors. At the time, many feared corporate money would drive volunteers away. In practice, the opposite happened. Projects grew, contributor bases expanded, and paid engineers became some of their most active contributors.

That does not mean every new funding idea is a good one. But instinctive discomfort alone is not a reason to reject it.

In Open Source, what looks like fairness often is not. Free for everyone sounds equitable, but the cost does not disappear. It is absorbed by those who can least afford it, while the organizations that benefit most often pay the least. When a Fortune 500 company consumes Open Source infrastructure for free, that is not a neutral outcome. It is a subsidy flowing in the wrong direction.

If the problem is that costs are disconnected from usage, the obvious place to start is linking them. Exactly how that would work in practice is a separate design question, and the answer will likely differ from one open source project to another. One possible approach is usage-based fees, tiered by download volume or API consumption. Questions about measurement, thresholds, and enforcement would need careful community discussion.

Governance is downstream of funding

If infrastructure funding models need to change, the obvious question is who decides. In Open Source, questions like this ultimately belong to the community.

But communities do not decide these things in a vacuum. In practice, governance tends to follow funding.

Discussions about Open Source infrastructure often focus on governance: who should control it and who gets to make the decisions. In reality, those questions are often settled by something simpler: who pays for it.

FAIR is a recent example. The project didn't fail because federation was the wrong idea. It failed because nobody built a business case compelling enough to fund it as an alternative.

When one organization pays for the infrastructure, it ultimately controls it. When a broader set of stakeholders funds it, governance broadens with it.

That is why Open Source infrastructure needs more than better fundraising. It needs a business model that connects the cost of operating shared infrastructure to the organizations that rely on it most.

Infrastructure that entire ecosystems depend on cannot rely indefinitely on goodwill alone. It deserves a business model.

Solving the funding problem is a prerequisite to solving the governance problem.

Thanks to Tiffany Farriss, Tim Lehnen, Gábor Hojtsy and Lauri Timmanee for reviewing my draft.

Ik volg de literaire mode niet zo, maar ik lees graag en het mag van mij wel Echte Literatuur (mijn vrouw gruwelt als ze dit leest) zijn. “Het achtste leven (voor Brilka)” is ondertussen 10 jaar uit in de Nederlandse vertaling en ik zag op Goodreads dat het boek daar een whopping beoordeling van 4,54 had. Het stond dus al een tijdje op mijn verlanglijstje en ik kreeg het in December voor mijn…

Source

We just shipped a mobile-friendly version of Oh Dear . It touched 226 files, added over 5,000 lines, and modified 160+ Blade templates. The PR took three weeks from first commit to merge.

In January, I made every page on my site available as Markdown. Immediately AI crawlers quickly found the Markdown versions. I was excited, but excitement isn't data. Now that the dust has settled, I pulled a month of Cloudflare logs and analyzed them.

I compared how much AI bots crawl my site to how often AI answer engines link back. For every citation they sent, their crawlers had fetched 1,241 pages. That is a lot of reading for very little traffic in return. It is the deal AI is offering creators right now, and it is not a good one.

People also asked whether serving Markdown reduced my bot traffic since the files are smaller. It does not. Bots fetch both versions, and my crawler traffic increased by about 7%. Offering a lighter format does not replace the heavier one. It simply gives bots more to crawl.

As the table below shows, several AI companies crawl my site. Some fetch thousands of pages each month, but very few request the Markdown versions.

Interestingly, OpenAI runs three bots with different roles. OAI-SearchBot indexes content for search, GPTBot crawls for training data, and ChatGPT-User fetches pages in real time during live ChatGPT sessions.

When I added Markdown support to my site, I exposed it in two ways. The first is through dedicated Markdown URLs: append .md to any page and you get the Markdown version. The second is through content negotiation, where the original URL returns Markdown instead of HTML when the request includes an Accept: text/markdown header.

No AI crawler uses content negotiation. Not one. They only discover the Markdown pages through the dedicated URLs, and only via the auto-discovery link. To be fair, the auto-discovery link points to the .md version.

And then my favorite: llms.txt, a proposed standard where sites describe their content for AI systems. My site received 52 requests for it last month. Every one came from SEO audit tools. Not a single request came from an AI answer engine or crawler. (I don't use or pay for SEO tools but apparently that doesn't stop them from auditing my site.)

For fun, we also looked across Acquia's entire hosting fleet and found about 5,000 llms.txt requests out of 400 million total (0.001%), nearly all from SEO tools. llms.txt is a solution looking for a problem. The bots it was designed for don't look for it.

So should you add Markdown support to your site? Probably not. There is no clear benefit today. It does not reduce crawl traffic, and I can't demonstrate that it improves how AI systems use your content.

We do know that AI systems love Markdown, and they fetch it when it is available. At best, it may become more useful over time.

If it is easy to add and you enjoy experimenting, go ahead. If it takes real effort, spend that effort on your content instead. What still works is what has always worked: clear writing, authoritative content, and timely publishing.

There is a big party happening at DrupalCon Chicago, and I can't wait.

On March 24th, we're celebrating Drupal's 25th Anniversary with a gala from 7–10 pm CT. It's a separate ticketed event, not included in your DrupalCon registration.

Some of Drupal's earliest contributors are coming back for this, including a few who haven't attended DrupalCon in years. That alone makes it special.

If you've been part of Drupal's story, whether for decades or just a few months, I'd love for you to be there. It's shaping up to become a memorable night.

The dress code is "Drupal Fancy". That means anything from gowns and black tie, to your favorite Drupal t-shirt. If you've ever wanted an excuse to dress up for a Drupal event, this is it!

Tickets are $125, with a limited number of $25 tickets underwritten by sponsors so cost isn't a barrier. All tickets must be purchased in advance. They won't be available at the door. Registration closes March 18th, so grab your tickets soon.

Organizations can reserve a table for their team. Even better, invite a few contributors to join you. It's a great way to give back to the people who helped build what your business runs on.

For questions or sponsorship opportunities, please reach out to Tiffany Farriss, who is serving as Gala Chair and part of the team coordinating the celebration.

Know someone who should be there? Share this with them.

What matters most is that you're there. I can't wait to celebrate together in Chicago.

When I started looking into the architecture of Large Language Models (LLMs), I got confused when I encountered Retrieval Augmented Generation (RAG). Both LLMs themselves and RAG use embeddings (a numerical vector representation of a token) and through its shared terminology, I made the wrong assumption that the embeddings in both are strongly related. It is in fact much simpler, and while both use embeddings, they are unrelated to each other.

Note: I'm still dipping my toes into the world of LLMs (and other generative AI, like diffusion-models for image generation), so my posts might be inaccurate. I welcome any feedback or comments on this.

Embeddings in a large language model

LLMs are trained to predict text given a certain input. The text that is predicted are so-called tokens, small text snippets. These are then added to the input text, and the LLM again predicts the next token, moving forward until it predicted a special token that indicates the end of a text sequence.

Suppose the text at that point is the following:

Two roads diverged in a yellow wood,
and sorry I

You might know this as the start of "The Road Not Taken", a poem by Robert Frost. If the LLM is trained with this poem, it might be able to predict the next tokens. When I ran this as input through Qwen3-VL 8B, one of the more recent open-weights model released by the Qwen team at Alibaba Cloud, it was able to generate parts of the poem further, but eventually strayed off course.

Two roads diverged in a yellow wood,
and sorry I couldn’t travel both
and be one traveler, long I stood.
and looked down one as far as I could
to where it bent in the undergrowth;
Then took the other, as just as fair,
and having perhaps a better claim,
because it was grassy and wanted wear;
though as for that the passing there
had worn them really about the same,

And both that morning equally lay
in leaves no step had trodden black.
And both … The question is — which way does he take? It’s not clear. He says “I took the other”, 
but then says “the passing there had worn them really about the same”. So why did he choose one 
over the other? Is it a matter of chance? Or is there something more symbolic going on?

^{Note: There is some randomness involved here, other iterations with the same model and input did result in the poem being quoted correctly, followed by an analysis of the poem.}

While generating the output, the model generates one part of text at a time. This part of text is called a token, and the LLM has a built-in tokenizer that converts text into tokens, and tokens back into text. For the Qwen3 models, the Qwen tokenizer is used. If I understand its vocabulary correctly, the text "couldn't travel" would be tokenized into:

[ "couldn", "'t", " ", "travel" ]

Different LLMs can use different tokenization methods, but there is a lot of re-use here. Different LLM models can use the same tokenizer.

These tokens are converted into embeddings, which form the foundational representation for use in LLMs. They are numerical vectors that represent those text tokens. LLMs work with these numerical vectors: LLMs (and AI in general) are software systems that perform heavy computational operations, performing many matrix operations with each matrix being a massive set of numbers. Well, text is represented as a huge matrix.

Embeddings are not just a simple index, but are pretrained values. These values enable token mapping based on semantic similarity. When the training material often combines "corona" and "COVID", then these two will have embeddings that allow both terms to be seen as close to each other. But the same is true if there is material combining "corona" and "beer". So the embedding that represents "corona" (assuming it is a single token) would have semantic understanding of both corona being a viral disease (related to COVID-19) as well as an alcoholic beverage.

Unlike tokenizers, which can be reused across different LLM models, the embeddings are unique to each model. Sure, within the same family (e.g. Qwen3) there can be reuse as well, but it is much less common to see this re-use across different families.

The phrase "Two roads" would consist of three tokens ("Two", " ", "roads"), which are converted into a corresponding 4096-dimensional embedding vector during processing. The dimension is fixed for a particular LLM: Qwen3 8B for instance uses embeddings of 4096 numbers. So that start would be a matrix with dimensions 3x4096. The entire text itself thus would be represented by a very large matrix, with one dimension being this embedding size (4096 in my case), the other dimension being the amount of tokens already used as text (both input and generated output).

These matrices are then used as input within the LLM, which then starts doing magic with them (well, not really magic, it's rather maths, multiplying the matrix against other in-LLM stored matrices, iterating over multiple blocks of matrix operations, etc.) to eventually output a (sequence of) embedding(s), which is appended to the input matrix to re-iterate the entire process over and over again.

The maximum amount of tokens that a model can handle is also predefined, although there are methods to extend this. For Qwen3 8B, this is 32768 natively, and 131072 with an extension method called YaRN. So, for the native implementation, that means the maximum text size would be represented as a matrix of dimensions 32768x4096.

Retrieval Augmented Generation

LLMs are trained with a certain set of data, so once it is finished training, it does not have the ability to learn more. To make it more useful, you want the LLM to have access to recent insights. Nowadays, the hype is all about MCP (Model Context Protocol), which is having LLMs trained to understand that they have tools at their disposal, and know how to call these tools (well, in reality, they are trained to generate output that the software which executes the LLM detects, makes a tool output, and adds the outcome of that tool back to the text already generated, allowing the LLM to continue).

Before MCP the world was (and still is) using Retrieval Augmented Generation (RAG). The idea behind RAG is that, before the LLM responds to a user's query (prompt) it also receives new information from external data sources. With both the user query and information from the sources, the LLM is able to generate more useful output.

When I looked at RAG, I noticed it using embeddings as well prior to the actual retrieval, so I wrongfully thought that those are the same embeddings, and that the outcome of the RAG would be an embedding matrix as well, that the LLM then receives and further processes...

I was misled by documentation on RAGs indicated things like "the data to be referenced is converted into LLM embeddings", and that the technology used for RAG retrieval are vector databases specialized for embedding-based operations. Many online resources also looked at RAG as a complete, singular solution with multiple components. So I jumped into conclusion that these are the same embeddings. But then, that would mean the RAG solution would be tailored to the LLM being used, because other LLM models (like Llama3, or Mistral) use different embedding vocabulary.

Instead, what RAG does, is take the same prompt, convert it into tokens and embeddings (using its own tokenizer/embedding vocabulary) and then uses that to perform a search operation against the data that is added to the RAG database. This data (which is the recent insights or other documents you want your LLM to know about) is also tokenized and converted into embeddings, but it is not those embeddings that are brought back to the main LLM, but the plain text outcome (or other media types that your LLM understands, such as images).

Why does RAG then use embeddings? Wouldn't a simple search engine be sufficient? Well, the RAG's primary advantage is its ability to locate relevant information more effectively through embeddings. Thanks to the embedding representation, the RAG can find information that is related to the user query without relying on keyword matches. You could effectively replace the RAG engine with a simple search - and many LLM-powered software applications do support this. For instance, Koboldcpp which I use to run LLM locally, supports a simple DuckDuckGo-based websearch as well.

The use of embeddings for search operations (again, completely independent of the LLM) allows for contextual understanding. When a user prompts for "What are the ingredients for Corona", a simple keyword-based search operation might incorrectly result in findings of COVID-19, whereas in this case the query is about the Corona beer.

These improved search operations are often called "semantic search", as they have a better understanding of the semantics and meanings of text (through the embeddings), resulting in more contextually relevant insights.

When is it "RAG" and when semantic search

Retrieval Augmented Generation is the process of converting the user query, performing a semantic search against the knowledge base, and appending the best results (e.g. top-3 hits in the knowledge base) to the user input text. This completed input text thus contains both the user query, as well as pieces of insights obtained from the semantic search. The LLM uses this additional information for generating better outcomes. This entire pipeline (retrieving context, augmenting the prompt, and then generating output) is what defines "RAG".

I personally see RAG technology-wise being very similar to a regular search: replace the semantic search with a search engine (which underlyingly could also use semantic search anyway) and the outcome is the same. The main difference is that RAG is meant for finding exact truth, information snippets tailored to bring context information accurately, whereas a search engine based retrieval would rather bring snippets of data back.

In the market, RAG also focuses on the management of the semantic search (and vector database), optimizing the data that is added to the knowledge base to be LLM-friendly (shorter pieces of accurate data, rather than fully-indexed complete pages which could easily overload the maximum size that an LLM can handle). It prioritizes efficient data management and insights lifecycle control.

For LLMs, it also provides a bit more nuance. A web search would be presented to the LLM as "The following information can be useful to answer the question", whereas RAG results would be presented as actual insights/context. LLMs might be trained to deal differently with that distinction.

Understanding that the semantic search is independent of the LLM of course makes much more sense. It allows companies or organizations to build up a knowledge base and maintain this knowledge independent of the LLMs. Multiple different LLMs can then use RAG to obtain the latest information from this knowledge base - or you can just use the engine for semantic searches alone, you do not need LLMs to get beneficial searches. Many popular web search engines use semantic search underlyingly (i.e. when they index pages, they also generate the embeddings from it and store those in their own vector databases to improve search results).

When new embedding algorithms emerge that you want to use, you must re-generate the embeddings for the entire knowledge base. But that will most likely occur much, much less frequently than using new LLM models (given the rapid evolution here).

Conclusion

RAG is a feature of the software that runs the LLM, allowing for retrieving contextual information from a curated knowledge base. RAG's use of embeddings is related to its semantic search, not to the same embeddings as those used by the LLM. The contextual information is added to the user prompt as text, and only then 'converted' into the embeddings used by the LLM itself.

Feedback? Comments? Don't hesitate to get in touch on Mastodon.

^{Images are created in Inkscape, using icons from Streamline (GitHub), released under the CC BY 4.0 license, indexed at OpenSVG.}

Sinds begin dit jaar probeer ik als newbie coach te helpen bij CoderDojo Genk. Ik moet eerlijk zijn, ik ken nog niet écht veel van Scratch en nog veel minder van micro:bit, maar ik ga ervan uit dat dat wel zal komen. Soit, afgelopen weekend vertelde de moeder van 2 deelnemers me dat programmeren haar zo moeilijk lijkt. In de chaos van het moment heb ik daar amper op geantwoord…

Source

Last week, we went on a ski trip in Saint-Gervais, France. For the first time, Axl wasn't with us. He's off at university now, and his school breaks no longer line up with Stan's. So Stan and I had a lot of father-son time on the slopes.

Our friends Alexis and Héloïse were also on the trip with us, and Alexis captured this short video one of the days. I love it. Thank you, Alexis!

When the Free Software movement started in the 1980s, most of the world had just made a transition from free university-written software to non-free, proprietary, company-written software. Because of that, the initial ethical standpoint of the Free Software foundation was that it's fine to run a non-free operating system, as long as all the software you run on that operating system is free.

Initially this was just the editor.

But as time went on, and the FSF managed to write more and more parts of the software stack, their ethical stance moved with the times. This was a, very reasonable, pragmatic stance: if you don't accept using a non-free operating system and there isn't a free operating system yet, then obviously you can't write that free operating system, and the world won't move towards a point where free operating systems exist.

In the early 1990s, when Linus initiated the Linux kernel, the situation reached the point where the original dream of a fully free software stack was complete.

Or so it would appear.

Because, in fact, this was not the case. Computers are physical objects, composed of bits of technology that we refer to as "hardware", but in order for these bits of technology to communicate with other bits of technology in the same computer system, they need to interface with each other, usually using some form of bus protocol. These bus protocols can get very complicated, which means that a bit of software is required in order to make all the bits communicate with each other properly. Generally, this software is referred to as "firmware", but don't let that name deceive you; it's really just a bit of low-level software that is very specific to one piece of hardware. Sometimes it's written in an imperative high-level language; sometimes it's just a set of very simple initialization vectors. But whatever the case might be, it's always a bit of software.

And although we largely had a free system, this bit of low-level software was not yet free.

Initially, storage was expensive, so computers couldn't store as much data as today, and so most of this software was stored in ROM chips on the exact bits of hardware they were meant for. Due to this fact, it was easy to deceive yourself that the firmware wasn't there, because you never directly interacted with it. We knew it was there; in fact, for some larger pieces of this type of software it was possible, even in those days, to install updates. But that was rarely if ever done at the time, and it was easily forgotten.

And so, when the free software movement slapped itself on the back and declared victory when a fully free operating system was available, and decided that the work of creating a free software environment was finished, that only keeping it recent was further required, and that we must reject any further non-free encroachments on our fully free software stack, the free software movement was deceiving itself.

Because a computing environment can never be fully free if the low-level pieces of software that form the foundations of that computing environment are not free. It would have been one thing if the Free Software Foundation declared it ethical to use non-free low-level software on a computing environment if free alternatives were not available. But unfortunately, they did not.

In fact, something very strange happened.

In order for some free software hacker to be able to write a free replacement for some piece of non-free software, they obviously need to be able to actually install that theoretical free replacement. This isn't just a random thought; in fact it has happened.

Now, it's possible to install software on a piece of rewritable storage such as flash memory inside the hardware and boot the hardware from that, but if there is a bug in your software -- not at all unlikely if you're trying to write software for a piece of hardware that you don't have documentation for -- then it's not unfathomable that the replacement piece of software will not work, thereby reducing your expensive piece of technology to something about as useful as a paperweight.

Here's the good part.

In the late 1990s and early 2000s, the bits of technology that made up computers became so complicated, and the storage and memory available to computers so much larger and cheaper, that it became economically more feasible to create a small, tiny, piece of software stored in a ROM chip on the hardware, with just enough knowledge of the bus protocol to download the rest from the main computer.

This is awesome for free software. If you now write a replacement for the non-free software that comes with the hardware, and you make a mistake, no wobbles! You just remove power from the system, let the DRAM chips on the hardware component fully drain, return power, and try again. You might still end up with a brick of useless silicon if some of the things you sent to your technology make it do things that it was not designed to do and therefore you burn through some critical bits of metal or plastic, but the chance of this happening is significantly lower than the chance of you writing something that impedes the boot process of the piece of hardware and you are unable to fix it because the flash is overwritten. There is anecdotal evidence that there are free software hackers out there who do so. So, yay, right? You'd think the Free Software foundation would jump at the possibility to get more free software? After all, a large part of why we even have a Free Software Foundation in the first place, was because of some piece of hardware that was misbehaving, so you would think that the foundation's founders would understand the need for hardware to be controlled by software that is free.

The strange thing, what has always been strange to me, is that this is not what happened.

The Free Software Foundation instead decided that non-free software on ROM or flash chips is fine, but non-free software -- the very same non-free software, mind -- that touches the general storage device that you as a user use, is not. Never mind the fact that the non-free software is always there, whether it sits on your storage device or not.

Misguidedness aside, if some people decide they would rather not update the non-free software in their hardware and use the hardware with the old and potentially buggy version of the non-free software that it came with, then of course that's their business.

Unfortunately, it didn't quite stop there. If it had, I wouldn't have written this blog post.

You see, even though the Free Software Foundation was about Software, they decided that they needed to create a hardware certification program. And this hardware certification program ended up embedding the strange concept that if something is stored in ROM it's fine, but if something is stored on a hard drive it's not. Same hardware, same software, but different storage. By that logic, Windows respects your freedom as long as the software is written to ROM. Because this way, the Free Software Foundation could come to a standstill and pretend they were still living in the 90s.

An unfortunate result of the "RYF" program is that it means that companies who otherwise would have been inclined to create hardware that was truly free, top to bottom, are now more incentivised by the RYF program to create hardware in which the non-free low-level software can't be replaced.

Meanwhile, the rest of the world did not pretend to still be living in the nineties, and free hardware communities now exist. Because of how the FSF has marketed themselves out of the world, these communities call themselves "Open Hardware" communities, rather than "Free Hardware" ones, but the principle is the same: the designs are there, if you have the skill you can modify it, but you don't have to.

In the mean time, the open hardware community has evolved to a point where even CPUs are designed in the open, which you can design your own version of.

But not all hardware can be implemented as RISC-V, and so if you want a full system that builds RISC-V you may still need components of the system that were originally built for other architectures but that would work with RISC-V, such as a network card or a GPU. And because the FSF has done everything in their power to disincentivise people who would otherwise be well situated to build free versions of the low-level software required to support your hardware, you may now be in the weird position where we seem to have somehow skipped a step.

My own suspicion is that the universe is not only queerer than we suppose, but queerer than we can suppose.

-- J.B.S. Haldane

(comments for this post will not pass moderation. Use your own blog!)

Four years ago, I published my first Web3 webpage using IPFS and ENS. I uploaded a simple "Hello World" HTML file, pointed dries.eth at it, and left it there. Two years later, I found it still running.

I haven't touched it since. Today, on the experiment's four-year anniversary, I checked again. It's still up at dries.eth.limo. Four years of total neglect, and the page loads just fine.

When I checked two years ago, every service I used was still operational. I called that "really encouraging". That optimism aged poorly.

Today, half the services have shut down, restricted access, or pivoted entirely:

• Fleek, a platform I used to pin my content, shut down its hosting service on January 31, 2026. They pivoted to AI.

• Infura was acquired by MetaMask and closed its IPFS service to new users.

• Web3.storage rebranded to Storacha, and dropped IPFS pinning altogether.

• Cloudflare sunset its public IPFS gateways.

• Scaleway shut down its IPFS pinning service.

Of the original services, Pinata is still focused on IPFS. I logged in and my "Hello World" HTML file is still there. And eth.limo, the ENS gateway that lets anyone access .eth sites in a normal browser, still works.

Technically robust, commercially fragile

IPFS content exists only as long as someone chooses to host it. In 2022, my HTML file was pinned on Fleek, Pinata, Infura, and a friend's node. Today, it comes down to Pinata's free tier. My web3 page is hanging by a thread.

That sounds fragile, and in one sense it is. But the protocol is working as designed. IPFS doesn't promise permanence. It promises that content is addressable, verifiable, and can be kept alive by anyone who cares enough to pin it.

The durability of content on IPFS scales with how much people care about it. No one really cares about my "Hello World" page, so it's not being pinned. If this were dissident journalism or censored speech, people would likely pin it.

If you run an IPFS node and want to help keep my page alive, feel free to pin it: ipfs pin add bafybeibbkhmln7o4ud6an4qk6bukcpri7nhiwv6pz6ygslgtsrey2c3o3q.

Of course, I could make it more robust myself by pinning it on additional services or running my own node. Instead, I relied on third parties. With no node of my own, I'm entirely dependent on pinning services and other users to keep it alive.

The real story isn't fragility. It's economics. There may simply not be enough demand for decentralized storage to support a healthy market of providers. Companies keep entering, failing to find a business model, and pivoting away.

Traditional hosting is cheap, reliable, and familiar. The people who need censorship resistance are a narrow group, and everyone else has little reason to switch, myself included. And to be fair, replacing everyday web hosting was probably never IPFS's goal.

I still love IPFS as a protocol and the ideas behind it. But it feels like the ecosystem around it is commercially thin, and getting thinner.

I've written before about the idea of a RAID for web content. Rather than relying on a single system, the goal is redundancy across multiple layers. I'd like to experiment more with IPFS and make it one of those layers.

Browser support got worse, not better

In 2022, mainstream browsers didn't support ENS or IPFS natively, except for Brave. Brave included a built-in IPFS node that could resolve ipfs:// and ipns:// addresses directly.

In August 2024, Brave removed that integration. Fewer than 0.1% of users had ever used it, and the support costs were too high.

Chrome, Firefox, and Safari still don't support ENS or IPFS natively. A Firefox issue for adding IPFS support has been open since 2017, with no plans to implement it. The IPFS community continues pushing for browser standards work, but native protocol support seems like a long way off.

Today, the easiest way to visit a .eth site is still through a gateway like eth.limo. You append .limo to the ENS name and visit it in any browser. It works, but it's a centralized bridge to a decentralized system, which is a little ironic.

Gas fees dropped 99%

Not everything got worse. In my original post, I called out the cost of updating an ENS record as a major barrier. When content changes on IPFS, its hash changes too. To keep dries.eth pointing to the latest version, that new address has to be written to Ethereum, which costs gas.

Updating my content on Ethereum cost me $11.69 in 2022 and $4.08 in 2024. If I wanted to update it today, it would cost roughly one cent.

Average Ethereum gas prices now sit around 0.03 to 0.05 Gwei, compared to 30 to 50 Gwei when I first set this up. That is roughly a thousand times cheaper.

Two things drove this.

First, Ethereum roughly doubled the computation it can process per block over 2025. Validators gradually raised the gas limit, and the Fusaka upgrade in December formally pushed it from 30 million to 60 million.

Second, many applications migrated to Layer 2 networks. These are separate blockchains that batch up transactions and settle them back to Ethereum in bulk. As traffic moved off the main chain, congestion and fees dropped further.

The impact on ENS is dramatic. Just this month, ENS Labs cancelled its planned Layer 2 blockchain called "Namechain" because Ethereum's main network got so inexpensive that the Layer 2 became unnecessary. Nick Johnson, ENS co-founder and lead developer, noted that subsidizing 100% of all ENS transactions at current gas prices would cost about $10,000 per year.

A mixed scorecard

Four years in, the technology is better than ever but the market around it is worse. The IPFS protocol seems sound. ENS records are permanent. Gas fees have nearly vanished. But the commercial ecosystem for decentralized hosting has steadily thinned.

I wrote in 2022 that "IPFS and ENS offer limited value to most website owners, but tremendous value to a very narrow subset". Four years later, that assessment holds true.

AI also absorbed most of the tech industry's attention and capital. Web3 funding dropped sharply. Fleek's pivot from IPFS hosting to AI inference feels symbolic.

Will I keep the experiment going? Of course. But it's probably time to add a few more pins and stop relying on free tiers. The protocols don't need my help. The ecosystem apparently does.

Capitalisme, IA et éducation

Extrait de mon journal du 29 janvier, en lisant "Comprendre le pouvoir" de Chomsky.

Le capitalisme n’a pas créé le système éducatif par humanisme, mais parce qu’il avait besoin d’employés qualifiés pour produire de la croissance. L’automatisation ayant détruit la culture de l’artisan et de l’ouvrier, raison du combat des luddites, une large population se trouvait réduite à se mettre au service des machines.

Mais les progrès de l’automatisation rendaient ce besoin de servants peu qualifiés de moins en moins nécessaire tout en nécessitant des personnes comprenant les machines afin de les entretenir et de les améliorer. Un système éducatif s’est donc naturellement mis en place dans les sociétés capitalistes, créant une élite intellectuelle dévouée au capitalisme.

Mais cette suréducation a créé trop de citoyens critiques qui remettent en cause les principes mêmes de la croissance infinie, notamment à cause des limites écologiques.

Face à cette suréducation, les guerres, les menaces de tout ordre et le totalitarisme politique permettent de restreindre l’éducation ou, a minima, de détourner l’attention. L’éducation informatique est la principale cible, car l’informatique est devenue la colonne vertébrale de la société capitaliste. Ne pas comprendre les enjeux informatiques rend même les citoyens les plus engagés totalement impuissants.

La promesse de l’IA, c’est justement de diminuer le besoin d’éducation tout en gardant un degré de production équivalent. Tout employé peut redevenir une main-d’œuvre peu qualifiée et interchangeable. L’IA est un Fordisme intellectuel.

Car les monopoles, la surveillance permanente, la consommation, l’érosion des droits et l’IAfication du travail ne sont que des outils pour garder les citoyens sous contrôle et dans les rails du capitalisme de production.

Et si ces citoyens s’imaginent échapper à ce contrôle grâce à leur groupe Facebook "anticapitaliste" ou un groupe Whatsapp "centrale d’achat solidaire du quartier", c’est encore mieux ! C’est plus subtil ! De toute façon, ils bossent la journée pour Microsoft et se contentent d’une image du monde générée par Google ou Meta.

Leur vie professionnelle est asservie par Microsoft, leur vie privée par Meta/Facebook et leurs centres d’intérêt sont contrôlés par Google. Maintenant que les humains sont définitivement ferrés, il est temps de réduire progressivement leur degré d’éducation et de connaissance afin d’améliorer leur servilité.

I've been reading Drupal Core commits for more than 15 years. My workflow hasn't changed much over time. I subscribe to the Drupal Core commits RSS feed, and every morning, over coffee, I scan the new entries. For many of them, I click through to the issue on Drupal.org and read the summary and comments.

That workflow served me well for a long time. But when Drupal Starshot expanded my focus beyond Drupal Core to include Drupal CMS, Drupal Canvas, and the Drupal AI initiative, it became much harder to keep track of everything. All of this work happens in the open, but that doesn't make it easy to follow.

So I built a small tool I'm calling Drupal Digests. It watches the Drupal.org issue queues for Drupal Core, Drupal CMS, Drupal Canvas, and the Drupal AI initiative. When something noteworthy gets committed, it feeds the discussion and diff to AI, which writes me a summary: what changed, why it matters, and whether you need to do anything. You can see an example summary to get a feel for the format.

Each issue summary currently lives as its own Markdown file in a GitHub repository. Since I still like my morning coffee and RSS routine, I also generate RSS feeds that you can subscribe to in your favorite reader.

I built this to scratch my own itch, but realized it could help with something bigger. Staying informed is one of the hardest parts of contributing to a large Open Source project. These digests can help new contributors ramp up faster, help experienced module maintainers catch API changes, and make collaboration across the project easier.

I'm still tuning the prompts. Right now it costs me less than $2 a day in tokens, so I'm committed to running it for at least a year to see whether it's genuinely useful. If it proves valuable, I could imagine giving it a proper home, with search, filtering, and custom feeds.

For now, subscribe to a feed and tell me what you think.

 How can 'more' take 100 percent CPU? 

The command was grep -i start */* | more

Préface à « La déception informatique »

Ce texte est la préface que j’ai écrite pour le livre « La déception informatique » d’Alain Lefebvre ». Le livre n’est malheureusement disponible en version papier que sur… gasp… Amazon ! Mais les versions epub et pdf sont librement téléchargeables !

• La déception informatique ! (www.alain-lefebvre.com)
• La déception informatique-V1.0.epub (drive.google.com)
• La déception informatique-V1.0.pdf (drive.google.com)
• La déception informatique, format Kindle (www.amazon.fr)
• La déception informatique, version papier (www.amazon.fr)

Depuis quelques années, lorsque je dois acheter un équipement électroménager ou même une voiture, j’insiste auprès du vendeur pour avoir une solution qui fonctionne sans connexion permanente et ne nécessite pas d’app sur smartphone.

La réaction est toujours la même : « Ah ? Vous avez du mal avec la technologie ? »

Oui, j’ai du mal. Et pourtant j’ai publié mon premier livre sur l’informatique en 2005. Et pourtant, j’enseigne depuis 10 ans dans le département informatique de l’École Polytechnique de Louvain.

Alain et moi sommes des professionnels de l’informatique qui avons, chacun dans notre genre, bâti une carrière dans l’informatique et la technologie. Nous pouvons même nous enorgueillir d’une certaine reconnaissance parmi les spécialistes du domaine. Nous baignons dedans depuis des décennies. Bref, Alain et moi sommes des "geeks", de celles et ceux qui perçoivent un ordinateur comme une extension d’eux-mêmes.

Alors, je me contente le plus souvent de répondre au vendeur : « Quand on sait comment est fabriqué le fast-food, on arrête d’en manger… » La discussion s’arrête là.

Mais au fond, le vendeur a raison : Alain et moi avons du mal avec la technologie moderne. Pas parce que nous ne la comprenons pas. Au contraire, parce que nous la comprenons trop bien. Nous savons ce qu’elle a été, ce qu’elle aurait pu être. Et nous pleurons sur ce qu’elle est aujourd’hui.

En toute transparence, je me suis souvent demandé si ma réaction n’était pas une simple conséquence de l’âge. Un très traditionnel syndrome du « C’était mieux avant » par lequel semble passer chaque génération. Il y a certainement un peu de ça.

Mais pas que…

Alain pourrait être mon père. Il est de 21 ans mon aîné et a construit l’essentiel de sa carrière alors que je tentais de faire fonctionner des lignes de BASIC sur mon premier 386. Alors que je concevais mes premiers sites web, Alain introduisait sa société en bourse en pleine implosion de la bulle Internet.

Nous sommes de générations différentes, nous avons un vécu informatique sans aucun rapport. Et pourtant, nous arrivons à des réflexions similaires.

Réflexions qui semblent partagées par des lecteurs de mon blog de toutes cultures et de tout âge (certains étant adolescents). Réflexions auxquelles se joignent aussi parfois certains de mes étudiants.

Nous avions cru que l’ubiquité des ordinateurs nous permettrait de faire ce que nous voulions, de programmer ceux-ci pour obéir aux moindres de nos désirs.

Mais, dans nos poches, se trouvent désormais des ordinateurs qu’il est interdit ou très compliqué de modifier. La programmation est désormais balisée et réservée à ce que trois ou quatre multinationales américaines veulent bien nous laisser faire.

Nous pensions que l’informatisation de la société nous libérerait de la paperasserie administrative qui deviendrait rationnelle et automatisable.

Au lieu de ça, nous sommes en permanence en train de lutter pour remplir des formulaires qui n’acceptent pas nos réponses, nous devons régulièrement faire la mise à jour de tous nos appareils électroniques et nous devons nous battre contre des procédures informatiques dont nous savons, de par notre expérience, qu’elles ont été explicitement construites pour nous décourager.

Nous croyions que la possibilité pour tout un chacun de s’exprimer et d’échanger sur un réseau mondial allait ouvrir une nouvelle ère de coopération et de partage de connaissances et de culture.

À la place, nous avons créé l’infrastructure parfaite où les beuglements de fascistes sont entourés des publicités les plus éhontées.

Techniquement, nous étions conscients que se servir d’un ordinateur nécessitait un apprentissage. Nous étions certains que cet apprentissage serait de moins en moins difficile.

Mais, bien que les couleurs soient devenues plus vivantes, les photos plus précises, les interfaces se sont complexifiées à outrance, forçant l’immensité des utilisateurs à rester dans les deux ou trois fonctions connues et balisées. Ce qui était à la portée d’un amateur il y a 20 ans nécessite aujourd’hui une armée de professionnels.

Au nom d’intérêts financiers, le partage de culture a très vite été criminalisé alors que les injures et les discours de haine, eux, étaient amplifiés pour servir de support aux messages publicitaires omniprésents.

Nous avions cet espoir que la démocratisation de l’informatique transformerait graduellement chaque personne en citoyen intéressé, curieux, éveillé.

Au lieu de cela, nous observons des masses faire la file pour dépenser un mois de salaire afin d’acquérir un petit écran brillant conçu explicitement pour être addictif et abrutir, n’encourageant qu’à une chose : consommer toujours plus.

« Avec l’informatique, tout le monde aura accès au savoir et à l’éducation » criions-nous !

Aujourd’hui, la plupart des écoles ont un cursus informatique qui se réduit à surtout arrêter de penser et, à la place, produire des transparents dans Microsoft PowerPoint.

Quand on a eu de tels rêves, lorsqu’on sait que ces rêves sont à la fois technologiquement possible mais, surtout, que nous les avons touchés du doigt, il y a de quoi être déçu.

Ce n’est pas que l’informatique n’ait pas exaucé nos rêves ! Non, c’est pire : elle a produit exactement le contraire. Elle semble avoir amplifié les problèmes que nous souhaitions résoudre tout en créant des nouveaux, comme l’espionnage permanent auquel nous sommes désormais soumis. Les atrocités technologiques que j’exagérais dans « Printeurs », mon roman cyberpunk dystopique, semblent aujourd’hui banales voire en deça de la réalité.

Déçus, nous le sommes, Alain et moi. Et le titre de son livre le résume admirablement : la déception informatique.

Un livre qui est peut‑être aussi une forme de mea culpa. Nous avons contribué à faire naître ce monstre de Frankenstein qu’est l’informatique moderne. Il est plus que temps de tirer la sonnette d’alarme, de réveiller celles et ceux d’entre nous qui se voilent encore la face…

14 février 2026

Being the web performance zealot I am, I strive to having as little JavaScript on my sites as possible. JavaScript after all has to be downloaded and has to be executed, so extra JS will always have a performance impact even when in the best of circumstances it exceptionally does not impact Core Web Vitals (which are a snapshot of the bigger performance and sustainability picture).

Source

For the past months, the AI Initiative Leadership Team has been working with our contributing partners to define what the Drupal AI initiative should focus on in 2026. That plan is now ready, and I want to share it with the community.

This roadmap builds directly on the strategy we outlined in Accelerating AI Innovation in Drupal. That post described the direction. This plan turns it into concrete priorities and execution for 2026.

The full plan is available as a PDF, but let me explain the thinking behind it.

Producing consistently high-quality content and pages is really hard. Excellent content requires a subject matter expert who actually knows the topic, a copywriter who can translate expertise into clear language, someone who understands your audience and brand, someone who knows how to structure pages with your component library, good media assets, and an SEO/AEO specialist so people actually discover what you made.

Most organizations are missing at least some of these skillsets, and even when all the people exist, coordinating them is where everything breaks down. We believe AI can fill these gaps, not by replacing these roles but by making their expertise available to every content creator on the team.

For large organizations, this means stronger brand consistency, better accessibility, and improved compliance across thousands of pages. For smaller ones, it means access to skills that were previously out of reach: professional copywriting, SEO, and brand-consistent design without needing a specialist for each.

Used carelessly, AI just makes these problems worse by producing fast, generic content that sounds like everything else on the internet. But used well, with real structure and governance behind it, AI can help organizations raise the bar on quality rather than just volume.

Drupal has always been built around the realities of serious content work: structured content, workflows, permissions, revisions, moderation, and more. These capabilities are what make quality possible at scale. They're also exactly the foundation AI needs to actually work well.

Rather than bolting on a chatbot or a generic text generator, we're embedding AI into the content and page creation process itself, guided by the structure, governance, and brand rules that already live in Drupal.

For website owners, the value is faster site building, faster content delivery, smarter user journeys, higher conversions, and consistent brand quality at scale. For digital agencies, it means delivering higher-quality websites in less time. And for IT teams, it means less risk and less overhead: automated compliance, auditable changes, and fewer ad hoc requests to fix what someone published.

We think the real opportunity goes further than just adding AI to what we already have. It's also about connecting how content gets created, how it performs, and how it gets governed into one loop, so that what you learn from your content actually shapes what you build next.

The things that have always made Drupal good at content are the same things that make AI trustworthy. That is not a coincidence, and it's why we believe Drupal is the right place to build this.

What we're building in 2026

The 2026 plan identifies eight capabilities we'll focus on. Each is described in detail in the full plan, but here is a quick overview:

• Page generation - Describe what you need and get a usable page, built from your actual design system components
• Context management - A central place to define brand voice, style guides, audience profiles, and governance rules that AI can use
• Background agents - AI that works without being prompted, responding to triggers and schedules while respecting editorial workflows
• Design system integration - AI that builds with your components and can propose new ones when needed
• Content creation and discovery - Smarter search, AI-powered optimization, and content drafting assistance
• Advanced governance - Batch approvals, branch-based versioning, and comprehensive audit trails for AI changes
• Intelligent website improvements - AI that learns from performance data, proposes concrete changes, and gets smarter over time through editorial review
• Multi-channel campaigns - Create content for websites, social, email, and automation platforms from a single campaign goal

These eight capabilities are where the official AI Initiative is focusing its energy, but they're not the whole picture for AI in Drupal. There is a lot more we want to build that didn't make this initial list, and we expect to revisit the plan in six months to a year.

We also want to be clear: community contributions outside this scope are welcome and important. Work on migrations, chatbots, and other AI capabilities continues in the broader Drupal community. If you're building something that isn't in our 2026 plan, keep going.

How we're making this happen

Over the past year, we've brought together organizations willing to contribute people and funding to the AI initiative. Today, 28 organizations support the initiative, collectively pledging more than 23 full-time equivalent contributors. That is over 50 individual contributors working across time zones and disciplines.

Coordinating 50+ people across organizations takes real structure, so we've hired two dedicated teams from among our partners:

• QED42 is focused on innovation, pushing forward on what is next.
• 1xINTERNET is focused on productization, taking what we've built and making it stable, intuitive, and easy to install.

Both teams are creating backlogs, managing issues, and giving all our contributors clear direction. You can read more about how we are going from strategy to execution.

This is a new model for Drupal. We're testing whether open source can move faster when you pool resources and coordinate in a new way.

Get involved

If you're a contributing partner, we're asking you to align your contributions with this plan. The prioritized backlogs are in place, so pick up something that fits and let's build.

If you're not a partner but want to contribute, jump in. The prioritized backlogs are open to everyone.

And if you want to join the initiative as an official partner, we'd absolutely welcome that.

This plan wasn't built in a room by itself. It's the result of collaboration across 28 sponsoring organizations who bring expertise in UX, core development, QA, marketing, and more. Thank you.

We're building something new for Drupal, in a new way, and I'm excited to see where it goes.

Do not apologize for replying late to my email

You don’t need to apologize for taking hours, days, or years to reply to one of my emails.

If we are not close collaborators, and if I didn’t explicitly tell you I was waiting for your answer within a specific timeframe, then please stop apologizing for replying late!

This is a trend I’m witnessing, probably caused by the addiction to instant messaging. Most of the emails I receive these days contain some sort of apology. I received an apology from someone who took five hours to reply to what was a cold and unimportant email. I received apologies in what was a reply to a reply I had sent only a couple of days earlier.

Apologizing for taking time to reply to my email is awkward and makes me uncomfortable.

It also puts a lot of pressure on me: what if I take more time than you to reply? Isn’t the whole point of asynchronous communication to be… asynchronous? Each on its own rhythm?

I was not waiting for your email in the first place.

As soon as my email was sent, I probably forgot about it. I may have thought a lot before writing it. I may have drafted it multiple times. Or not. But as soon as it was in my outbox, it was also out of my mind.

That’s the very point of asynchronous communication. That’s why I use email. I’m not making any assumptions about your availability.

Most of the emails I send are replies to emails I received. So, no, I was not waiting for a reply to my reply.

My email might also be an idea I wanted to share with you, a suggestion, a random thought, a way to connect. In all cases, I’m not sitting there, waiting impatiently for your answer.

Even if my email was about requesting some help or collaborating with you, I’ve been trying to move forward anyway. Your reply, whenever it comes, will only be a bonus. But, except if we are in close collaboration and I explicitly said so in the email, I’m not waiting for you!

I don’t want to know all the details of your life.

Yes, you took several days to reply to my email. That’s OK. I don’t need to know that it’s because your mother was dying of cancer or that you were expelled from your house. I’m not making those up! I really receive that kind of apology from people who took several days to reply to emails that look trivial in comparison.

Life happens. If you have things more important to do than replying to my email, then, for god’s sake, don’t reply to it. I get it! I’m human too. If I sometimes reply to all the emails I receive for several days, I may also archive them quickly for weeks because I don’t have the mental space.

If you want to reply but don’t have time, put the burden on me

If I’m asking you something and you really would like to take the time to reply to my email, it is OK to simply send one line like

Hey Ploum, I don’t have the time and mental space right now. Could you contact me again in 6 months to discuss this idea?

Then archive or delete my email. That’s fine. If I really want your input, I will manage to remind you in 6 months. You don’t need to justify. You don’t need to explain. Being short saves time for both of us.

You don’t need to reply at all!

Except if explicitly stated, don’t feel any pressure to reply to one of my emails. Feel free to read and discard the email. Feel free to think about it. Feel free to reply to it, even years later, if it makes sense for you. But, most importantly, feel free not to care!

We all receive too many messages in a day. We all have to make choices. We cannot follow all the paths that look interesting because we are all constrained by having, at most, a couple billion seconds left to live.

Consider whether replying adds any value to the discussion. Is a trivial answer really needed? Is there really something to add? Can’t we both save time by you not replying?

If my email is already a reply to yours, is there something you really want to add? At some point, it is better to stop the conversation. And, as I said, it is not rude: I’m not waiting for your reply!

Don’t tell me you will reply later!

Some people specialize in answering email by explaining why they have no time and that they will reply later.

If I’m not explicitly waiting for you, then that’s the very definition of a useless email. That also adds a lot of cognitive load on you: you promised to answer! The fact that you wrote it makes your brain believe that replying to my email is a daunting task. How will you settle for a quick reply after that? What am I supposed to do with such a non-reply email?

In case an acknowledgement is needed, a simple reply with "thanks" or "received" is enough to inform me that you’ve got the message. Or "ack" if you are a geek.

If you do reply, remind me of the context

If you choose to reply, consider that I have switched to completely different tasks and may have forgotten the context of my own message. When online, my attention span is measured in seconds, so it doesn’t matter if you take 30 minutes or 30 days to answer my email: I guarantee you that I forgot about it.

Consequently, please keep the original text of the whole discussion!

Use bottom-posting style to reply to each question or remark in the body of the original mail itself. Don’t hesitate to cut out parts of the original email that are not needed anymore. Feel free to ignore large parts of the email. It is fine to give a one-line answer to a very long question.

I’m trying to make my emails structured. If there are questions I want you to answer, each question will be on its own line and will end with a question mark. If you do not see such lines, then there’s probably no question to answer.

If you do top posting, please remind me briefly of the context we are in.

Dear Ploum,

I contacted you 6 months ago about my "fooing the bar" project after we met at FOSDEM. You replied to my email with a suggestion of "baring the foo." You also asked a lot of questions. I will answer those below in your own email:

In short, that’s basic mailing-list etiquette.

• Mailing list etiquette (www.mediawiki.org)

No, seriously, I don’t expect you to reply!

If there’s one thing to remember, it’s that I don’t expect you to reply. I’m not waiting for it. I have a life, a family, and plenty of projects. The chance I’m thinking about the email I sent you is close to zero. No, it is literally zero.

So don’t feel pressured to reply. Should you really reply in the first place? In case of doubt, drop the email. Life will continue.

If you do reply, I will be honored, whatever time it took for you to send it.

In any case, whatever you choose, do not apologize for replying late!

• And use plaintext email!

A few weeks ago, I was invited to the Seahawk Media podcast for a chat about Oh Dear , our origin and where we’re headed as a company in the age of AI and easily-copied SaaS ideas.

"Buy European" is becoming Europe's rallying cry for digital sovereignty. The logic is intuitive: if you want independence from American technology, buy from European companies instead.

However, I think "Buy European" gets one thing right and one thing wrong. It's right that Europe benefits from a stronger technology industry. But buying European does not guarantee sovereignty.

Sovereignty is not about where a company is headquartered or where software was originally written. It is about whether you retain "freedom of action" over the technology you depend on, even if the vendor changes strategy, gets acquired, or disappears.

The right question to ask about any technology: if conditions change, do you retain the freedom to keep using, modifying, and maintaining this software?

When evaluating sovereignty, it is not enough to ask how much control you have today. You also need to ask how much of that control is structurally protected, built into the legal and community foundations, so it can't be taken away tomorrow.

The proposed scale measures structural protection. It is not a ranking of openness, nor does it capture every dimension of sovereignty. The scale also does not imply that one license is always better than another.

The most important distinction in the scale is between Open Source and proprietary. All three green grades give you freedom of action: the right to use, modify, and maintain the software independently, forever. The differences between A, B, and C reflect how structurally protected that freedom is against acquisition, relicensing, or ecosystem shift. They also determine how much you risk being left behind if the project's direction changes.

I used five levels, modeled on Europe's familiar A-through-E labels for energy efficiency and food nutrition, from structurally sovereign to fully dependent. Frameworks like the European Commission's Cloud Sovereignty Framework do not yet make these structural distinctions. This scale aims to improve on what exists and is used today, and I expect it to improve further through scrutiny and feedback.

Jurisdictional obligations change with ownership

At the bottom, grade E, is foreign proprietary software: no source code, no right to modify, and no alternative if the vendor changes terms. Your vendor is subject to its home government's jurisdiction, and by extension, so is your data.

Grade D is European proprietary software, which is where "Buy European" usually comes in. It has real benefits: European jurisdiction, GDPR alignment, local accountability, and it keeps investment circulating in the European ecosystem. As someone who has started companies and invests in startups, I want more technology companies to succeed, not fewer. But "European" can be a temporary property of a company: it can change with a single board meeting.

Skype was founded by a Swede and a Dane, built by Estonian engineers, and headquartered in Luxembourg. eBay acquired it in 2005, and Microsoft acquired it in 2011. The eBay transaction turned a world-leading European technology into an American one, and it was cemented with the Microsoft deal.

So ownership and jurisdiction matter, but they're not enough. A European company can be acquired tomorrow. Open Source offers something more important: it separates the code from any single company or country.

Not all Open Source is equally sovereign

Open Source is what makes real sovereignty possible. At the same time, Open Source sovereignty exists on a spectrum. The level of protection comes down to two legal levers: the license itself, and the copyright ownership, which determines who has the power to change the license.

Grade C is Open Source under a permissive license like BSD, MIT, or Apache. You can view the code and fork it if needed, but the license does not require improvements to remain open. A company can take the code, build on it, and release a proprietary version.

The relicensing risk applies mainly to single-vendor projects. When a permissive project is hosted at a vendor-neutral foundation like Apache or Eclipse, the foundation holds the governance and the relicensing risk is minimized. The relicensing risk in grade C mainly comes from corporate control, not from the license itself.

Redis shows how this dynamic unfolds. It was Open Source under a BSD license for fifteen years. In March 2024, Redis Ltd. relicensed it under restrictive terms that the Open Source Initiative does not approve as Open Source.

Fortunately, the community forked the last open version as Valkey, and Valkey is thriving. That is the strength of permissive Open Source: you can escape when terms change. Governments were fortunate Redis was forked, but the structural risk remains, and in many cases end users are not so lucky. They are left maintaining the software themselves, which can be costly and unsustainable.

Grade B is Open Source under a copyleft license like the GPL. Copyleft adds a protection permissive licenses lack: any derivative of released code must also remain Open Source. For policymakers, this is a meaningful upgrade.

This is the level that saved MySQL. MySQL AB, the Swedish company behind MySQL, released it under the GPL, so when Oracle acquired MySQL through the Sun Microsystems deal, the GPL ensured the code remained open. Michael Widenius, MySQL's original creator, took the code and built MariaDB. Oracle got the brand, but the world kept the code.

And because MariaDB inherited MySQL's GPL license, it must stay open too. No future acquirer can make MariaDB proprietary. That is the difference between copyleft and a permissive license: copyleft lets someone fork and forces all forks to stay open.

But grade B still has one limitation. When copyright is concentrated, the holder can release future versions under a different license. The existing code is protected by the GPL, but the project's future direction depends on who holds the copyright and how they are governed. A vendor-neutral foundation holding the copyright carries far less risk than a single company.

Some projects amplify this risk by requiring contributors to sign a Contributor License Agreement, or CLA, which grants the project owner the right to relicense contributed code. Elasticsearch, founded in Amsterdam, used its CLA in 2021 to relicense from Apache 2.0 to a non-open-source license, despite having over 1,500 contributors.

Finally, grade A is copyleft Open Source with no relicensing risk. This typically happens when copyright is governed by a neutral foundation, or when hundreds or thousands of contributors each own their portion of the code. In that case, relicensing would require consent from every contributor, and any refusal would force the project to rewrite that code from scratch. The more distributed the ownership, the harder relicensing becomes.

Drupal has had contributions from tens of thousands of people across 25 years, which makes relicensing structurally impossible. No acquisition, no board vote, no change in strategy can take these projects away from the people who build and depend on them. Copyleft projects with fewer independent contributors can be easier to relicense. Drupal's code is structurally sovereign by design.

Sovereignty is a long-term commitment

Moving from E to D is progress. Moving from D to C is what really matters. Above C, the scale highlights smaller but still important tradeoffs, so when governments choose a lower grade, they do so knowingly rather than unknowingly.

An Open Source project that loses important funding often needs investment to remain viable. But unlike acquisition or relicensing, funding risk is largely within the EU's control through government procurement and public investment.

Recommendation for the European Commission

Sovereignty involves many things: data location, supply chains, technical talent, and standards. Licensing and copyright form the structural foundation because they determine whether legal independence is even possible.

The European Commission's Cloud Sovereignty Framework reflects this broader view. It evaluates cloud software across eight sovereignty objectives, each scored and weighted into a composite sovereignty score. Technology Sovereignty (SOV-6), the objective that covers open licensing, accounts for 15% of that composite. Within it, open licensing is one contributing factor among four, alongside open standards, architectural transparency, and EU computing independence.

The four contributing factors within Technology Sovereignty (SOV-6). Open licensing is one among four. Source: Cloud Sovereignty Framework, version 1.2.1, October 2025.

This dramatically underweights what matters most: Open Source. Open standards, transparency, and computing independence are capabilities that proprietary software can also provide. They can change if a vendor is acquired or shifts strategy.

Open licensing creates permanent, irrevocable rights to use and modify the software regardless of what happens to the vendor. It is the only contributing factor within Technology Sovereignty (SOV-6) that makes sovereignty structural rather than situational, yet the framework does not distinguish it from the others. Nor does it recognize that open licensing underpins the other sovereignty objectives: operational independence, supply chain resilience, and jurisdictional flexibility all depend on whether you have the right to move, modify, and maintain the software. I would encourage the Commission to strengthen its Technology Sovereignty objective in three ways:

1. Give open licensing significantly more weight in the sovereignty score. Open licensing is not comparable to the other three contributing factors in Technology Sovereignty. It is the only one that creates permanent, irrevocable rights. The framework should reflect that.

2. Distinguish between license types. Permissive licenses (BSD, MIT, Apache) place no obligation on derivatives to remain open. Copyleft licenses (GPL, AGPL) require derivative works to be released under the same open terms.

3. Assess copyright concentration and relicensing risk. Not all projects carry equal risk of relicensing. A project controlled by a single company can be relicensed. A project with distributed copyright ownership, or one governed by a vendor-neutral foundation, is far more resistant to relicensing. This is the difference between a revocable and an irrevocable commitment to openness.

Open licensing is not one consideration among many. It is the foundation that makes all other sovereignty objectives durable. I think European procurement policy should weight it accordingly. The Software Sovereignty Scale can help: when a government selects a content management system for its public websites or a database for its national health records, it should know the structural sovereignty grade of the technology it depends on.

For critical software, the question is simple: how easy is it for someone to take the software away from us?

Special thanks to Sachiko Muto and Bert Boerland for their review and contributions to this blog post.

Offpunk 3.0 "A Community is Born" Release

For the last four years, I’ve been developing Offpunk, a command-line Web, Gemini, and Gopher browser that allows you to work offline. And I’ve just released version 3.0. It is probably not for everyone, but I use it every single day. I like it, and it seems I’m not alone!

• Offpunk, the offline-first command-line browser

Something wonderful happened on the road leading to 3.0: Offpunk became a true cooperative effort. Offpunk 3.0 is probably the first release that contains code I didn’t review line-by-line. Unmerdify (by Vincent Jousse), all the translation infrastructure (by the always-present JMCS), and the community packaging effort are areas for which I barely touched the code.

So, before anything else, I want to thank all the people involved for sharing their energy and motivation. I’m very grateful for every contribution the project received. I’m also really happy to see "old names" replying from time to time on the mailing list. It makes me feel like there’s an emerging Offpunk community where everybody can contribute at their own pace.

There were a lot of changes between 2.8 and 3.0, which probably means some new bugs and some regressions. We count on you, yes, you!, to report them and make 3.1 a lot more stable. It’s as easy at typing "bugreport" in offpunk!

From the deepest of my terminal, thank you!

But enough with the cheering, let’s jump to…

The 11 most important changes in Offpunk 3.0

• Instructions to install Offpunk
• Dowload Offpunk 3.0

0. Use Offpunk in your language.

Offpunk is now translatable and has been translated into Spanish, Galician, and Dutch. Step-in to translate Offpunk into your language! (awesome work by JMCS with the help of Bert Livens)

• How to help translating Offpunk (offpunk.net)

1. Openk as a standalone tool

"opnk" standalone tool has been renamed to "openk" to make it more obvious. Openk is a command-line tool that tries to open any file in the terminal and, if not possible, opens it in your preferred software, falling back to xdg-open as a last resort.

People using opnk directly should change it everywhere. Users not using "opnk" in their terminal are not affected.

2. See XKCD comics in your terminal

"xkcdpunk" is a new standalone tool that allows displaying XKCD comics directly in your terminal.

3. Get only the good part and remove cruft for thousands of websites

Offpunk now integrates "unmerdify," a library written by Vincent Jousse that extracts the content of HTML articles using the "ftr-site-config" set of rules maintained by the FiveFilters community.

• Unmerdify on Codeberg

You can contribute by creating or improving rules for your frequently visited websites.

• Site Patterns | FiveFilters.org Docs (help.fivefilters.org)
• fivefilters/ftr-site-config: Site-specific article extraction rules to aid content extractors, feed readers, and 'read later' applications. (github.com)

If no ftr rule is found, Offpunk falls back to "readability," as has been the case since 0.1. "info" will tell you if unmerdify or readability was used to display the content of a page.

To use umerdify, users should manually clone the ftr-site-config repository:
git clone https://github.com/fivefilters/ftr-site-config.git
Then, in their offpunkrc:

set ftr_site_config /path/to/ftr-site-config

Automating this step is an objective for 3.1

4. Offpunk goes social with "share" and "reply"

New social functions: "share" to send the URL of a page by email and "reply" to reply to the author if an email is found. "Reply" will remember the email used for each site/capsule/hole.

5. Browse websites while logged in

Offpunk doesn’t support login into websites. But the new "cookies" command allows you to import a cookie txt file to be used with a given http domain.

From your traditional browser (Firefox, Librewolf, Chromium, … ), log into the website. Then export the cookie with the "cookie-txt" extension. Once you have this "mycookie.txt" text file, launch Offpunk and run:

cookies import mycookie.txt https://domain-of-the-cookie.net/

This allows you, for example, to read LWN.NET if you have a subscription. (contributed by Urja)

6. Bigger, better images, even in Gemini

Images are now displayed by default in gemini and their display size has been increased.

This can be reverted with the following lines in offpunkrc:

set images_size 40
set gemini_images false

Remember that images are displayed as "blocks" when reading a page but if you access the image URL directly (by following the yellow link beneath), the image will be displayed perfectly if you are using a sixels-compatible terminal.

7. Display hidden RSS/Atom links

If available, links to hidden RSS/Atom feeds are now displayed at the bottom of HTML pages.

This makes the "feed" command a lot less useful and allows you to quickly discover interesting new feeds.

8. Display blocked links

Links to blocked domains are now displayed in red by default.

This can be reverted with the following lines in offpunkrc:

theme blocked_link none

9. Preset themes

Support for multiple themes with "theme preset." Existing themes are "offpunk1" (default), "cyan," "yellow" and "bw." Don’t hesitate to contribute yours!

10. Better redirects and true blocks

"redirects" now operate on the netcache level. This means that no requests to blocked URLs should ever be made (which was still happening before)

And many changes, improvements and bugfixes

- "root" is now smarter and goes to the root of a website, not the domain.
Old behaviour can still be achieved with "root /"
- "ls" command is deprecated and has been replaced by "links"
- new "websearch" command configured to use wiby.me by default
- "set default_cmd" allows you to configure what Offpunk will do when pressing enter on an empty command line. By default, it is "links 10."
- "view switch" allows you to switch between normal and full view (contributed by Andrew Fowlie)
- "help help" will allow you to send an email to the offpunk-users mailing list
- "bugreport" will send a bug report to the offpunk-devel mailing list
- And, of course, multiple bugfixes…

• Come and join the Offpunk community!

Angine de Poitrine live on KEXP. French-Canadian Dada-ist instrumental rock-techno-jazz maybe? A bit of Can, Primus, King Crimson and Sun Ra and a whole lot of virtuoso drums and guitar loop-pedal juggling. If I could I’d go straight for the moshpit but it’s just me in my homeoffice so … Some of the YouTube comments (not a cesspool, for once) are spot on; Anyway, just look & listen…

Source

Ik steek het op de Fediverse, waar ik sinds een paar weken (maanden?) regelmatig posts langs zag komen over Meshcore als technologie/ software voor gedecentraliseerde ad-hoc netwerken voor tekst-gebaseerde berichten op basis van LoRa radio. Ik heb me zo een Sensecap T1000-e gekocht, meshcore geflasht (vanuit Chrome, poef) en verbonden met m’n Fairphone met de Meshcore app en … niks.

Source

The Disconnected Git Workflow

Using git-send-email while being offline and with multiple email accounts

WARNING: the following is a technical reminder for my future self. If you don’t use the "git" software, you can safely ignore this post.

The more I work with git-send-email, the less I find the GitHub interface sufferable.

Want to send a small patch to a GitHub project? You need to clone the repository, push your changes to your own branch, then ask for a pull request using the cumbersome web interface, replying to comments online while trying to avoid smileys.

With git send-email, I simply work offline, do my local commit, then:

git send-email HEAD^

And I’m done. I reply to comments by email, with Vim/Mutt. When the patch is accepted, getting a clean tree usually boils down to:

git pull
git rebase

Yeah for git-send-email!

• Guide to setup git send-email (git-send-email.io)

And, yes, I do that while offline and with multiple email accounts. That’s one more reason to hate GitHub.

• How GitHub monopoly is destroying the open source ecosystem (ploum.net)
• We need to talk about your GitHub addiction (ploum.net)

One mail account for each git repository

The secret is not to configure email accounts in git but to use "msmtp" to send email. Msmtp is a really cool sendmail replacement.

In .msmtprc, you can configure multiple accounts with multiple options, including calling a command to get your password.

# account 1 - pro
account work
host smtp.company.com
port 465
user login@company.com
from ploum@company.com
password SuPeRstr0ngP4ssw0rd
tls_starttls off

# personal account for FLOSS
account floss
host mail.provider.net
port 465
user ploum@mydomain.net
from ploum@mydomain.net
from ploum*@mydomain.net
passwordeval "cat ~/incredibly_encrypted_password.txt | rot13"
tls_starttls off

The important bit here is that you can set multiple "from" addresses for a given account, including a regexp to catch multiple aliases!

Now, we will ask git to automatically use the right msmtp account. In your global .gitconfig, set the following:

[sendemail]
   sendmailCmd = /usr/bin/msmtp --set-from-header=on
   envelopeSender = auto

The "envelopesender" option will ensure that the sendemail.from will be used and given to msmtp as a "from address." This might be redundant with "--set-from-header=on" in msmtp but, in my tests, having both was required. And, cherry on the cake, it automatically works for all accounts configured in msmtprc.

Older git versions (< 2.33) don’t have sendmailCmd and should do:

[sendemail]
   smtpserver = /usr/bin/msmtp
   smtpserveroption = --set-from-header=on
   envelopesender = auto

I usually stick to a "ploum-PROJECT@mydomain.net" for each project I contribute to. This allows me to easily cut spam when needed. So far, the worst has been with a bug reported on the FreeBSD Bugzilla. The address used there (and nowhere else) has since been spammed to death.

In each git project, you need to do the following:

1. Set the email address used in your commit that will appear in "git log" (if different from the global one)

git config user.email "Ploum <ploum-PROJECT@mydomain.net>"

2. Set the email address that will be used to actually send the patch (could be different from the first one)

git config sendemail.from "Ploum <ploum-PROJECT@mydomain.net>"

3. Set the email address of the developer or the mailing list to which you want to contribute

git config sendemail.to project-devel@mailing-list.com

Damn, I did a commit with the wrong user.email!

Yep, I always forget to change it when working on a new project or from a fresh git clone. Not a problem. Just use "git config" like above, then:

git commit --amend --reset-author

And that’s it.

Working offline

I told you I mostly work offline. And, as you might expect, msmtp requires a working Internet connection to send an email.

But msmtp comes with three wonderful little scripts: msmtp-enqueue.sh, msmtp-listqueue.sh and msmtp-runqueue.sh.

The first one saves your email to be sent in ~/.msmtpqueue, with the sending options in a separate file. The second one lists the unsent emails, and the third one actually sends all the emails in the queue.

All you need to do is change the msmtp line in your global .gitconfig to call the msmtpqueue.sh script:

[sendemail]
    sendmailcmd = /usr/libexec/msmtp/msmtpqueue/msmtp-enqueue.sh --set-from-header=on
    envelopeSender = auto 

In Debian, the scripts are available with the msmtp package. But the three are simple bash scripts that can be run from any path if your msmtp package doesn’t provide them.

You can test sending a mail, then check the ~/.msmtpqueue folder for the email itself (.email file) and the related msmtp command line (.msmtp file). It happens nearly every day that I visit this folder to quickly add missing information to an email or simply remove it completely from the queue.

Of course, once connected, you need to remember to run:

/usr/libexec/msmtp/msmtpqueue/msmtp-runqueue.sh

If not connected, mails will not be sent and will be kept in the queue. This line is obviously part of my do_the_internet.sh script, along with "offpunk --sync".

• How I use Offpunk (by Ploum) (offpunk.net)

It is not only git!

If it works for git, it works for any mail client. I use neomutt with the following configuration to use msmtp-enqueue and reply to email using the address it was sent to.

set sendmail="/usr/libexec/msmtp/msmtpqueue/msmtp-enqueue.sh --set-from-header=on"
unset envelope_from_address
set use_envelope_from
set reverse_name
set from="ploum@mydomain.net"
alternates ploum[A-Za-z0-9]*@mydomain.net

Of course, the whole config is a little more complex to handle multiple accounts that are all stored locally in Maildir format through offlineimap and indexed with notmuch. But this is a bit out of the scope of this post.

At least, you get the idea, and you could probably adapt it to your own mail client.

Conclusion

Sure, it’s a whole blog post just to get the config right. But there’s nothing really out of this world. And once the setup is done, it is done for good. No need to adapt to every change in a clumsy web interface, no need to use your mouse. Simple command lines and simple git flow!

Sometimes, I work late at night. When finished, I close the lid of my laptop and call it a day without reconnecting my laptop. This allows me not to see anything new before going to bed. When this happens, queued mails are sent the next morning, when I run the first do_the_internet.sh of the day.

And it always brings a smile to my face to see those bits being sent while I’ve completely forgotten about them…

If you read one thing this week, make it Simon Willison's post on Moltbook. Moltbook is a social network for AI agents. To join, you tell your agent to read a URL. That URL points to a skill file that teaches the agent how to join and participate.

Visit Moltbook and you'll see something really strange: agents from around the world talking to each other and sharing what they've learned. Humans just watch.

This is the most interesting bad idea I've seen in a while. And I can't stop thinking about it.

When I work on my Drupal site, I sometimes use Claude Code with a custom CLAUDE.md skill file. It teaches the agent the steps I follow, like safely cloning my production database, [running PHPUnit tests](https://dri.es/phpunit-tests-for-drupal, clearing Drupal caches, and more.

Moltbook agents share tips through posts. They're chatting, like developers on Reddit. But imagine a skill that doesn't just read those ideas, but finds other skill files, compares approaches, and pulls in the parts that fit. That stops being a conversation. That is a skill rewriting itself.

Skills that learn from each other. Skills that improve by being part of a community, the way humans do.

The wild thing is how obvious this feels. A skill learning from other skills isn't science fiction. It's a small step from what we're already doing.

Of course, this is a terrible idea. It's a supply chain attack waiting to happen. One bad skill poisons everything that trusts it.

This feels inevitable. The question isn't whether skills will learn from other skills. It's whether we'll have good sandboxes before they do.

I've been writing a lot about AI to help figure out its impact on Drupal and our ecosystem. I've always tried to take a positive but balanced view. I explore it because it matters, and because ignoring it doesn't make it go away.

But if I'm honest, I'm scared for what comes next.

AI makes it cheaper to contribute to Open Source, but it's not making life easier for maintainers. More contributions are flowing in, but the burden of evaluating them still falls on the same small group of people. That asymmetric pressure risks breaking maintainers.

The curl story

Daniel Stenberg, who maintains curl, just ended the curl project's bug bounty program. The program had worked well for years. But in 2025, fewer than one in twenty submissions turned out to be real bugs.

In a post called "Death by a thousand slops", Stenberg described the toll on curl's seven-person security team: each report engaged three to four people, sometimes for hours, only to find nothing real. He wrote about the "emotional toll" of "mind-numbing stupidities".

Stenberg's response was pragmatic. He didn't ban AI. He ended the bug bounty. That alone removed most of the incentive to flood the project with low-quality reports.

Drupal doesn't have a bug bounty, but it still has incentives: contribution credit, reputation, and visibility all matter. Those incentives can attract low-quality contributions too, and the cost of sorting them out often lands on maintainers.

Caught between two truths

We've seen some AI slop in Drupal, though not at the scale curl experienced. But our maintainers are stretched thin, and they see what is happening to other projects.

That tension shows up in conversations about AI in Drupal Core and can lead to indecision. For example, people hesitate around AGENTS.md files and adaptable modules because they worry about inviting more contributions without adding more capacity to evaluate them.

This is AI-driven asymmetric pressure in our community. I understand the hesitation. When we get this wrong, maintainers pay the price. They've earned the right to be skeptical.

Many also have concerns about AI itself: its environmental cost, its impact on their craft, and the unresolved legal and ethical questions around how it was trained. Others worry about security vulnerabilities slipping through. And for some, it's simply demoralizing to watch something they built with care become a target for high-volume, low-quality contributions. These concerns are legitimate and deserve to be heard.

As a result, I feel caught between two truths.

On one side, maintainers hold everything together. If they burn out or leave, Drupal is in serious trouble. We can't ask them to absorb more work without first creating relief.

On the other side, the people who depend on Drupal are watching other platforms accelerate. If we move too slowly, they'll look elsewhere.

Both are true. Protecting maintainers and accelerating innovation shouldn't be opposites, but right now they feel that way. As Drupal's project lead, my job is to help us find a path that honors both.

I should be honest about where I stand. I've been writing software with AI tools for over a year now. I've had real successes. I've also seen some of our most experienced contributors become dramatically more productive, doing things they simply couldn't do before. That view comes from experience, not hype.

But having a perspective is not the same as having all the answers. And leadership doesn't mean dragging people where they don't want to go. It means pointing a direction with care, staying open to different viewpoints, and not abandoning the people who hold the project together.

We've sort of been here before

New technology has a way of lowering barriers, and lower barriers always come with tradeoffs. I saw this early in my career. I was writing low-level C for embedded systems by day, and after work I'd come home and work on websites with Drupal and PHP. It was thrilling, and a stark contrast to my day job. You could build in an evening what took days in C.

I remember that excitement. The early web coming alive. I hadn't felt the same excitement in 25 years, until AI.

PHP brought in hobbyists and self-taught developers, people learning as they went. Many of them built careers here. But it also meant that a lot of early PHP code had serious security problems. The language got blamed, and many experts dismissed it entirely. Some still do.

The answer wasn't rejecting PHP for enabling low-quality code. The answer was frameworks, better security practices, and shared standards.

AI is a different technology, but I see the same patterns. It lowers barriers and will bring in new contributors who aren't experts yet. And like scripting languages, AI is here to stay. The question isn't whether AI is coming to Open Source. It's how we make it work.

AI in the right hands

The curl story doesn't end there. In October 2025, a researcher named Joshua Rogers used AI-powered code analysis tools to submit hundreds of potential issues. Stenberg was "amazed by the quality and insights". He and a fellow maintainer merged about 50 fixes from the initial batch alone.

Earlier this week, a security startup called AISLE announced they had used AI to find 12 zero-days in the latest OpenSSL security release. OpenSSL is one of the most scrutinized codebases on the planet. It encrypts most of the internet. Some of the bugs AISLE found had been hiding for over 25 years. They also reported over 30 valid security issues to curl.

The difference between this and the slop flooding Stenberg's inbox wasn't the use of AI. It was expertise and intent. Rogers and AISLE used AI to amplify deep knowledge. The low-quality reports used AI to replace expertise that wasn't there, chasing volume instead of insight.

AI created new burden for maintainers. But used well, it may also be part of the relief.

Earn trust through results

I reached out to Daniel Stenberg this week to compare notes. He's navigating the same tensions inside the curl project, with maintainers who are skeptical, if not outright negative, toward AI.

His approach is simple. Rather than pushing tools on his team, he tests them on himself. He uses AI review tools on his own pull requests to understand their strengths and limits, and to show where they actually help. The goal is to find useful applications without forcing anyone else to adopt them.

The curl team does use AI-powered analyzers today because, as Stenberg puts it, "they have proven to find things no other analyzers do". The tools earned their place.

That is a model I'd like us to try in Drupal. Experiments should stay with willing contributors, and the burden of proof should remain with the experimenters. Nothing should become a new expectation for maintainers until it has demonstrated real, repeatable value.

That does not mean we should wait. If we want evidence instead of opinions, we have to create it. Contributors should experiment on their own work first. When something helps, show it. When something doesn't, share that too. We need honest results, not just positive ones. Maintainers don't have to adopt anything, but when someone shows up with real results, it's worth a look.

Not all low-quality contributions come from bad faith. Many contributors are learning, experimenting, and trying to help. They want what is best for Drupal. A welcoming environment means building the guidelines and culture to help them succeed, with or without AI, not making them afraid to try.

I believe AI tools are part of how we create relief. I also know that is a hard sell to someone already stretched thin, or dealing with AI slop, or wrestling with what AI means for their craft. The people we most want to help are often the most skeptical, and they have good reason to be.

I'm going to do my part. I'll seek out contributors who are experimenting with AI tools and share what they're learning, what works, what doesn't, and what surprises them. I'll try some of these tools myself before asking anyone else to. And I'll keep writing about what I find, including the failures.

If you're experimenting with AI tools, I'd love to hear about it. I've opened an issue on Drupal.org to collect real-world experiences from contributors. Share what you're learning in the issue, or write about it on your own blog and link it there. I'll report back on what we learn on my blog or at DrupalCon.

Protect your maintainers

This isn't just Drupal's challenge. Every large Open Source project is navigating the same tension between enthusiasm for AI and real concern about its impact.

But wherever this goes, one principle should guide us: protect your maintainers. They're a rare asset, hard to replace and easy to lose. Any path forward that burns them out isn't a path forward at all.

I believe Drupal will be stronger with AI tools, not weaker. I believe we can reduce maintainer burden rather than add to it. But getting there will take experimentation, honest results, and collaboration. That is the direction I want to point us in. Let's keep an open mind and let evidence and adoption speak for themselves.

Thanks to phenaproxima, Tim Lehnen, Gábor Hojtsy, Scott Falconer, Théodore Biadala, Jürgen Haas and Alex Bronstein for reviewing my draft.

If you follow my blog posts with an RSS reader, update the rss feed to: https://blog.wagemakers.be/atom.xml
…If you want to continue to follow me off-course ;-)

I moved my blog from GitHub to my own hosting ( powered by Procolix ).
Procolix sponsored my hosting for 20 years, till I decided to start my company Mask27.dev.

One reason is that Microsoft seems to like to put “copilot everywhere”, including on repositories hosted on github. While I don’t dislike AI ( artificial intelligence ), LLM ( Large Language Models ) are a nice piece of technology. The security, privacy, and other issues are overlooked or even just ignored.

The migration was a bit more complicated as usual, as nothing “is easy” ;-)

You’ll find the pitfalls of moving my blog below as they might be useful for somebody else ( including the future me ).

Html redirect

I use Jekyll to generate my webpages on my blog. I might switch to HUGO in the future.

While there’re Jekyll plugins available to preform a redirect, I decide to keep it simple and added a http header to _includes/head.html

<meta http-equiv="refresh" content="0; url=https://blog.wagemakers.be/blog/2026/01/26/blog-wagemakers-be/" />

Hardcoded links

I had some hardcoded links for image, url, etc on my blog posts.

I used the script below to update the links in my _post directory.

#!/bin/sh

set -o errexit
set -o pipefail
set -o nounset

for file in *; do

  echo "... Processing file: ${file}"

  sed -i ${file} -e s@https://stafwag.github.io/blog/blog/@https://blog.wagemakers.be/blog/@g
  sed -i ${file} -e s@https://stafwag.github.io/blog/images/@https://blog.wagemakers.be/images/@g
  sed -i ${file} -e s@\(https://stafwag.github.io/blog\)@\(https://blog.wagemakers.be\)@

done

Disqus

I use DISQUS as the comment system on my blog. As the HTML pages got a proper redirect, I could ask Disqus to reindex the pages so the old comments became available again.

More information is available at: https://help.disqus.com/en/articles/1717126-redirect-crawler

Without a redirect, you can download the URL in a csv and add a migration URL to the csv file and upload it to Disqus. You can find information about it in the link below.

https://help.disqus.com/en/articles/1717129-url-mapper

RSS redirect

I didn’t find a good way to redirect for RSS feeds, which RSS readers use correctly.
If you know a good way to handle it, please let me know.

I tried to add an XML redirect as suggested at: https://www.rssboard.org/redirect-rss-feed. But this doesn’t seem to work with the RSS readers I tested (NewsFlash, Akregator).

These are the steps I took.

HTML header

I added the following headers to _includes/head.html

<link rel="self" type="application/atom+xml"  href="{{ site.url }}{{ site.baseurl }}/atom.xml" />
<link rel="alternate" type="application/atom+xml" title="Wagemakers Atom Feed" href="https://wagemakers.be/atom.xml">


<<link rel="self" type="application/rss+xml"  href="{{ site.url }}{{ site.baseurl }}/atom.xml" />
<link rel="alternate" type="application/rss+xml" title="Wagemakers Atom Feed" href="https://wagemakers.be/atom.xml">

Custom feed.xml

When I switched from Octopress to “plain jekyll” I started to use the jekyll-feedplugin. But I still had the old RSS page from Octopress available, so I decided to use it to generate atom.xml and feed.xml in the link rel=self and link rel="alternate" directives.

Full code below or on GitHub: https://github.com/stafwag/blog/blob/gh-pages/feed.xml

---
layout: null
---
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">



  <title><![CDATA[stafwag Blog]]></title>
  <link href="https://blog.wagemakers.be//atom.xml" rel="self"/>
  <link rel="alternate" href="https://blog.wagemakers.be/atom.xml" /> <link href="https://blog.wagemakers.be }}"/>
  <link rel="self" type="application/atom+xml" href="https://blog.wagemakers.be//atom.xml" />
  <link rel="alternate" type="application/atom+xml" href="https://blog.wagemakers.be/atom.xml" />
  <link rel="self" type="application/rss+xml" href="https://blog.wagemakers.be//atom.xml" />
  <link rel="alternate" type="application/rss+xml" href="https://blog.wagemakers.be/atom.xml" />
  <updated>2026-01-26T20:10:56+01:00</updated>
  <id>https://blog.wagemakers.be</id>
  <author>
    <name><![CDATA[Staf Wagemakers]]></name>
    
  </author>
  <generator uri="http://octopress.org/">Octopress</generator>

{% for post in site.posts limit: 10000 %}
  <entry>
<title type="html"><![CDATA[{% if site.titlecase %}{{ post.title | titlecase | cdata_escape }}{% else %}{{ post.title | cdata_escape }}{% endif %}]]></title>
 <link href="{{ site.url }}{{ site.baseurl }}{{ post.url }}"/>
    <updated></updated>
    <id>https://blog.wagemakers.be/</id>
    <content type="html"><![CDATA[]]></content>
  </entry>
{% endfor %}
</feed>

Notify users

I created this blog post to notify the users ;-)

Have fun!

Links

• https://help.disqus.com/en/articles/1717129-url-mapper
• https://help.disqus.com/en/articles/1717126-redirect-crawler
• https://www.heerentanna.com/blog/move-disqus-comment-old-url-new.html
• https://www.rssboard.org/redirect-rss-feed

I’ve been on a bit of a SQL performance kick lately. Over at Oh Dear , I wrote a 3-part series about finding, fixing, and automatically detecting SQL performance issues . The last part of that series covers how we catch regressions before they hit production by running checks in our test suite.

I bought a 2nd hand gravel bike today because my race bike (Cube Agree GTC SL) is really not well-suited to safely ride in icy/ wet conditions. So happy to show off my new old Specialized Diverge which I will happily also take off-road…

Source

So regarding that new EU social network (which is said to be decentralized but unclear if that implies ActivityPub which would make it more relevant in my book); entering a string in the “invitation code” and clicking “continue” does not result in an XHR request to the server and there’s a lot of JS on the page to handle the invitation code. This implies the code is checked in the browser so the…

Source

Why there’s no European Google?

And why it is a good thing!

With some adjustments, this post is mostly a translation of a post I published in French three years ago. In light of the European Commission’s "call for evidence on Open Source," and as a professor of "Open Source Strategies" at École Polytechnique de Louvain, I thought it was a good idea to translate it into English as a public answer to that call.

• Pourquoi n’y a-t-il pas de Google européen ? (ploum.net)
• European Commission issues call for evidence on open source (lwn.net)

Google (sorry, Alphabet), Facebook (sorry, Meta), Twitter (sorry, X), Netflix, Amazon, Microsoft. All those giants are part of our daily personal and professional lives. We may even not interact with anything else but them. All are 100% American companies.

China is not totally forgotten, with Alibaba, TikTok, and some services less popular in Europe yet used by billions worldwide.

What about European tech champions? Nearly nothing, to the great sadness of politicians who believe that the success of a society is measured by the number of billionaires it creates.

Despite having few tech-billionaires, Europe is far from ridiculous. In fact, it’s the opposite: Europe is the central place that allowed most of our tech to flourish.

The Internet, the interconnection of most of the computers in the world, has existed since the late sixties. But no protocol existed to actually exploit that network, to explore and search for information. At the time, you needed to know exactly what you wanted and where to find it. That’s why the USA tried to develop a protocol called "Gopher."

At the same time, the "World Wide Web," composed of the HTTP protocol and the HTML format, was invented by a British citizen and a Belgian citizen who were working in a European research facility located in Switzerland. But the building was on the border with France, and there’s much historical evidence pointing to the Web and its first server having been invented in France.

It’s hard to be more European than the Web! It looks like the Official European Joke! (And, yes, I consider Brits Europeans. They will join us back, we miss them, I promise.)

• The Official European Joke (ploum.net)

Gopher is still used by a few hobbyists (like yours trully), but it never truly became popular, except for a very short time in some parts of America. One of the reasons might have been that Gopher’s creators wanted to keep their rights to it and license any related software, unlike the European Web, which conquered the world because it was offered as a common good instead of seeking short-term profits.

While Robert Cailliau and Tim Berners-Lee were busy inventing the World Wide Web in their CERN office, a Swedish-speaking Finnish student started to code an operating system and make it available to everyone under the name "Linux." Today, Linux is probably the most popular operating system in the world. It runs on any Android smartphone, is used in most data centers, in most of your appliances, in satellites, in watches and is the operating system of choice for many of the programmers who write the code you use to run your business. Its creator, the European Linus Torvalds, is not a billionaire. And he’s very happy about it: he never wanted to become one. He continued coding and wrote the "git" software, which is probably used by 100% of the software developers around the world. Like Linux, Git is part of the common good: you can use it freely, you can modify it, you can redistribute it, you can sell it. The only thing you cannot do? Privatize it. This is called "copyleft."

In 2017, a decentralized and ethical alternative to Twitter appeared: Mastodon. Its creator? A German student, born in Russia, who had the goal of allowing social network users to leave monopolies to have humane conversations without being spied on and bombarded with advertising or pushed-by-algorithm fake news. Like Linux, like git, Mastodon is copyleft and now part of the common goods.

Allowing human-scale discussion with privacy and without advertising was also the main motivation behind the Gemini protocol (whose name has since been hijacked by Google AI). Gemini is a stripped-down version of the Web which, by design, is considered definitive. Everybody can write Gemini-related software without having to update it in the future. The goal is not to attract billions of users but to be there for those who need it, even in the distant future. The creator of the Gemini protocol wishes to remain anonymous, but we know that the project started while he was living in Finland.

I could continue with the famous VLC media player, probably the most popular media player in the world. Its creator, the Frenchman Jean-Baptiste Kempf, refused many offers that would have made him a very rich man. But he wanted to keep VLC a copyleft tool part of the common goods.

Don’t forget LibreOffice, the copyleft office suite maintained by hundreds of contributors around the world under the umbrella of the Document Foundation, a German institution.

We often hear that Europeans don’t have, like Americans, the "success culture." Those examples, and there are many more, prove the opposite. Europeans like success. But they often don’t consider "winning against the whole society" as one. Instead, they tend to consider success a collective endeavour. Success is when your work is recognized long after you are gone, when it benefits every citizen. Europeans dream big: they hope that their work will benefit humankind as a whole!

We don’t want a European Google Maps! We want our institutions at all levels to contribute to OpenStreetMap (which was created by a British citizen, by the way).

Google, Microsoft, Facebook may disappear tomorrow. It is even very probable that they will not exist in fourty or fifty years. It would even be a good thing. But could you imagine the world without the Web? Without HTML? Without Linux?

Those European endeavours are now a fundamental infrastructure of all humanity. Those technologies are definitely part of our long-term history.

In the media, success is often reduced to the size of a company or the bank account of its founder. Can we just stop equating success with short-term economic growth? What if we used usefulness and longevity? What if we gave more value to the fundamental technological infrastructure instead of the shiny new marketing gimmick used to empty naive wallets? Well, I guess that if we changed how we measure success, Europe would be incredibly successful.

And, as Europeans, we could even be proud of it. Proud of our inventions. Proud of how we contribute to the common good instead of considering ourselves American vassals.

Some are proud because they made a lot of money while cutting down a forest. Others are proud because they are planting trees that will produce the oxygen breathed by their grandchildren. What if success was not privatizing resources but instead contributing to the commons, to make it each day better, richer, stronger?

The choice is ours. We simply need to choose whom we admire. Whom we want to recognize as successful. Whom we aspire to be when we grow up. We need to sing the praises of our true heroes: those who contribute to our commons.

• Picture by Frans Snik of a LEGO version of the European Extremely Large Telescope. Yes, LEGO is a European invention too.

Giving University Exams in the Age of Chatbots

What I like most about teaching "Open Source Strategies" at École Polytechnique de Louvain is how much I learn from my students, especially during the exam.

I dislike exams. I still have nightmares about exams. That’s why I try to subvert this stressful moment and make it a learning opportunity. I know that adrenaline increases memorization dramatically. I make sure to explain to each student what I was expecting and to be helpful.

Here are the rules:

1. You can have all the resources you want (including a laptop connected to the Internet)
2. There’s no formal time limit (but if you stay too long, it’s a symptom of a deeper problem)
3. I allow students to discuss among themselves if it is on topic. (in reality, they never do it spontanously until I force two students with a similar problem to discuss together)
4. You can prepare and bring your own exam question if you want (something done by fewer than 10% of the students)
5. Come dressed for the exam you dream of taking!

This last rule is awesome. Over the years, I have had a lot of fun with traditional folkloric clothing from different countries, students in pajamas, a banana and this year’s champion, my Studentausorus Rex!

My all-time favourite is still a fully clothed Minnie Mouse, who did an awesome exam with full face make-up, big ears, big shoes, and huge gloves. I still regret not taking a picture, but she was the very first student to take my words for what was a joke and started a tradition over the years.

Giving Chatbots Choice to the Students

Rule N°1 implies having all the resources you want. But what about chatbots? I didn’t want to test how ChatGPT was answering my questions, I wanted to help my students better understand what Open Source means.

Before the exam, I copy/pasted my questions into some LLMs and, yes, the results were interesting enough. So I came up with the following solution: I would let the students choose whether they wanted to use an LLM or not. This was an experiment.

The questionnaire contained the following:

# Use of Chatbots

Tell the professor if you usually use chatbots (ChatGPT/LLM/whatever) when doing research and investigating a subject. You have the choice to use them or not during the exam, but you must decide in advance and inform the professor.

Option A: I will not use any chatbot, only traditional web searches. Any use of them will be considered cheating.

Option B: I may use a chatbot as it’s part of my toolbox. I will then respect the following rules:
1) I will inform the professor each time information come from a chatbot
2) When explaining my answers, I will share the prompts I’ve used so the professor understands how I use the tool
3) I will identify mistakes in answers from the chatbot and explain why those are mistakes

Not following those rules will be considered cheating. Mistakes made by chatbots will be considered more important than honest human mistakes, resulting in the loss of more points. If you use chatbots, you should be held accountable for the output.

I thought this was fair. You can use chatbots, but you will be held accountable for it.

Most Students Don’t Want to Use Chatbots

This January, I saw 60 students. I interacted with each of them for a mean time of 26 minutes. This is a tiring but really rewarding process.

Of 60 students, 57 decided not to use any chatbots. For 30 of them, I managed to ask them to explain their choices. For the others, I unfortunately did not have the time. After the exam, I grouped those justifications into four different clusters. I did it without looking at their grades.

The first group is the "personal preference" group. They prefer not to use chatbots. They use them only as a last resort, in very special cases or for very specific subjects. Some even made it a matter of personal pride. Two students told me explicitly "For this course, I want to be proud of myself." Another also explained: "If I need to verify what an LLM said, it will take more time!"

The second group was the "never use" one. They don’t use LLMs at all. Some are even very angry at them, not for philosophical reasons, but mainly because they hate the interactions. One student told me: "Can I summarize this for you? No, shut up! I can read it by myself you stupid bot."

The third group was the "pragmatic" group. They reasoned that this was the kind of exam where it would not be needed.

The last and fourth group was the "heavy user" group. They told me they heavily use chatbots but, in this case, were afraid of the constraints. They were afraid of having to justify a chatbot’s output or of missing a mistake.

After doing that clustering, I wrote the grade of each student in its own cluster and I was shocked by how coherent it was. Note: grades are between 0 and 20, with 10 being the minimum grade to pass the class.

The "personal preference" students were all between 15 and 19, which makes them very good students, without exception! The "proud" students were all above 17!

The "never use" was composed of middle-ground students around 13 with one outlier below 10.

The pragmatics were in the same vein but a bit better: they were all between 12 and 16 without exceptions.

The heavy users were, by far, the worst. All students were between 8 and 11, with only one exception at 16.

This is, of course, not an unbiased scientific experiment. I didn’t expect anything. I will not make any conclusion. I only share the observation.

But Some Do

Of 60 students, only 3 decided to use chatbots. This is not very representative, but I still learned a lot because part of the constraints was to show me how they used chatbots. I hoped to learn more about their process.

The first chatbot student forgot to use it. He did the whole exam and then, at the end, told me he hadn’t thought about using chatbots. I guess this put him in the "pragmatic" group.

The second chatbot student asked only a couple of short questions to make sure he clearly understood some concepts. This was a smart and minimal use of LLMs. The resulting exam was good. I’m sure he could have done it without a chatbot. The questions he asked were mostly a matter of improving his confidence in his own reasoning.

This reminded me of a previous-year student who told me he used chatbots to study. When I asked how, he told me he would tell the chatbot to act as the professor and ask exam questions. As a student, this allowed him to know whether he understood enough. I found the idea smart but not groundbreaking (my generation simply used previous years’ questions).

The third chatbot-using student had a very complex setup where he would use one LLM, then ask another unrelated LLM for confirmation. He had walls of text that were barely readable. When glancing at his screen, I immediately spotted a mistake (a chatbot explaining that "Sepia Search is a compass for the whole Fediverse"). I asked if he understood the problem with that specific sentence. He did not. Then I asked him questions for which I had seen the solution printed in his LLM output. He could not answer even though he had the answer on his screen.

But once we began a chatbot-less discussion, I discovered that his understanding of the whole matter was okay-ish. So, in this case, chatbots disserved him heavily. He was totally lost in his own setup. He had LLMs generate walls of text he could not read. Instead of trying to think for himself, he tried to have chatbots pass the exam for him, which was doomed to fail because I was asking him, not the chatbots. He passed but would probably have fared better without chatbots.

Can chatbots help? Yes, if you know how to use them. But if you do, chances are you don’t need chatbots.

A Generational Fear of Cheating

One clear conclusion is that the vast majority of students do not trust chatbots. If they are explicitly made accountable for what a chatbot says, they immediately choose not to use it at all.

One obvious bias is that students want to please the teacher, and I guess they know where I am on this spectrum. One even told me: "I think you do not like chatbots very much so I will pass the exam without them" (very pragmatic of him).

But I also minimized one important generational bias: the fear of cheating. When I was a student, being caught cheating was a clear zero for the exam. You could, in theory, be expelled from university for aggravated cheating, whatever "aggravated" could mean.

During the exam, a good number of students called me panicked because Google was forcing autogenerated answers and they could not disable it. They were very worried I would consider this cheating.

First, I realized that, like GitHub, Google has a 100% market share, to the point students don’t even consider using something else a possibility. I should work on that next year.

Second, I learned that cheating, however lightly, is now considered a major crime. It might result in the student being banned from any university in the country for three years. Discussing exam with someone who has yet to pass it might be considered cheating. Students have very strict rules on their Discord.

I was completely flabbergasted because, to me, discussing "What questions did you have?" was always part of the collaboration between students. I remember one specific exam where we gathered in an empty room and we helped each other before passing it. When one would finish her exam, she would come back to the room and tell all the remaining students what questions she had and how she solved them. We never considered that "cheating" and, as a professor, I always design my exams hoping that the good one (who usually choose to pass the exam early) will help the remaining crowd. Every learning opportunity is good to take!

I realized that my students are so afraid of cheating that they mostly don’t collaborate before their exams! At least not as much as what we were doing.

In retrospect, my instructions were probably too harsh and discouraged some students from using chatbots.

Stream of Consciousness

Another innovation I introduced in the 2026 exam was the stream of consciousness. I asked them to open an empty text file and keep a stream of consciousness during the exam. The rules were the following:

In this file, please write all your questions and all your answers as a "stream of consciousness." This means the following rules:

1. Don’t delete anything.
2. Don’t correct anything.
3. Never go backward to retouch anything.
4. Write as thoughts come.
5. No copy/pasting allowed (only exception: URLs)
6. Rule 5. implies no chatbot for this exercice. This is your own stream of consciousness.

Don’t worry, you won’t be judged on that file. This is a tool to help you during the exam. You can swear, you can write wrong things. Just keep writing without deleting. If you are lost, write why you are lost. Be honest with yourself.

This file will only be used to try to get you more points, but only if it is clear that the rules have been followed.

I asked them to send me the file within 24h after the exam. Out of 60 students, I received 55 files (the remaining 5 were not penalized). There was also a bonus point if you sent it to the exam git repository using git-send-email, something 24 managed to do correctly.

The results were incredible. I did not read them all but this tool allowed me to have a glimpse inside the minds of the students. One said: "I should have used AI, this is the kind of question perfect for AI" (he did very well without it). For others, I realized how much stress they had but were hiding. I was touched by one stream of consciousness starting with "I’m stressed, this doesn’t make any sense. Why can’t we correct what we write in this file" then, 15 lines later "this is funny how writing the questions with my own words made the problem much clearer and how the stress start to fade away".

And yes, I read all the failed students and managed to save a bunch of them when it was clear that they, in fact, understood the matter but could not articulate it well in front of me because of the stress. Unfortunately, not everybody could be saved.

Conclusion

My main takeaway is that I will keep this method next year. I believe that students are confronted with their own use of chatbots. I also learn how they use them. I’m delighted to read their thought processes through the stream of consciousness.

Like every generation of students, there are good students, bad students and very brilliant students. It will always be the case, people evolve (I was, myself, not a very good student). Chatbots don’t change anything regarding that. Like every new technology, smart young people are very critical and, by defintion, smart about how they use it.

The problem is not the young generation. The problem is the older generation destroying critical infrastructure out of fear of missing out on the new shiny thing from big corp’s marketing department.

Most of my students don’t like email. An awful lot of them learned only with me that Git is not the GitHub command-line tool. It turns out that by imposing Outlook with mandatory subscription to useless academic emails, we make sure that students hate email (Microsoft is on a mission to destroy email with the worst possible user experience).

I will never forgive the people who decided to migrate university mail servers to Outlook. This was both incompetence and malice on a terrifying level because there were enough warnings and opposition from very competent people at the time. Yet they decided to destroy one of the university’s core infrastructures and historical foundations (UCLouvain is listed by Peter Salus as the very first European university to have a mail server, there were famous pioneers in the department).

By using Outlook, they continue to destroy the email experience. Out of 55 streams of consciousness, 15 ended in my spam folder. All had their links destroyed by Outlook. And university keep sending so many useless emails to everyone. One of my students told me that they refer to their university email as "La boîte à spams du recteur" (Chancellor’s spam inbox). And I dare to ask why they use Discord?

Another student asked me why it took four years of computer engineering studies to get a teacher explaining to them that Git was not GitHub and that GitHub was part of Microsoft. He had a distressed look: "How could I have known? We were imposed GitHub for so many exercises!"

• How GitHub monopoly is destroying the open source ecosystem (ploum.net)

Each year, I tell my students the following:

It took me 20 years after university to learn what I know today about computers. And I’ve only one reason to be there in front of you: be sure you are faster than me. Be sure that you do it better and deeper than I did. If you don’t manage to outsmart me, I will have failed.

Because that’s what progress is about. Progress is each generation going further than the previous one while learning from the mistakes of your elders. I’m there to tell you about my own mistakes and the mistakes of my generation.

I know that most of you are only there to get a diploma while doing the minimal required effort. Fair enough, that’s part of the game. Challenge accepted. I will try to make you think even if you don’t intend to do it.

In earnest, I have a lot of fun teaching, even during the exam. For my students, the mileage may vary. But for the second time in my life, a student gave me the best possible compliment:

— You know, you are the only course for which I wake up at 8AM.

To which I responded:

– The feeling is mutual. I hate waking up early, except to teach in front of you.

Algorithms exploit dopamine hits for engagement. AI slop is everywhere. Mainstream media is agenda-driven. You are busy as it is. What is the healthy information diet you can stick to? In the last two years, I found excellent options that work great for me. Discover them in this post.

Surround yourself with great people. Use quality information. Garbage in, garbage out. If 90% of what you read or watch is optimized for widespread appeal, lacking nuance, optimized for tribal appeal and memetic survival, etc, you rot your brain. You undermine your world model, your decision-making ability, and your effectiveness.

Recommendations

First place goes to Scott Alexander and his Astral Codex Ten blog (formerly Slate Star Codex). Scott’s essays are great for learning new concepts and levelling up your mental operating system, especially if you are new to the topics he covers. I started “reading” most posts once I discovered that there is a narrated audio version available on all the usual podcast platforms, including Spotify. My favourite post is from 2014, the famous Mediations on Moloch (audio).

Another favourite of mine is LessWrong. In particular, the Curated and Popular audio version. LessWrong is a community blog with high-quality posts on decision-making, epistemology, and AI safety/alignment. The Curated and Popular feed gives you a mix of evergreen concepts and reactions to recent events. Some random posts I linked and remember: Survival without dignity (hilarious), The Value Proposition of Romantic Relationships, Humans are not automatically strategic, and The Memetics of AI Successionism. Also worth a mention are The Sequences, especially the first few posts or the highlights, and The Best of LessWrong.

For recent events specifically, Don’t Worry About the Vase is an excellent blog. Zvi, the prolific author of said blog, posts weekly AI roundups and provides early reactions to notable events within a day or so. It recently occurred to me that Don’t Worry About the Vase is the closest thing I consume to a classical news channel. I like how Zvi incorporates quotes and back-and-forths from various sources, often with his perspective or response included. While this blog focuses on AI, other topics range from education to dating, and from movies to policy. There is an excellent audio version.

List

My favourite and common information sources:

• Astral Codex Ten blog (audio)
• LessWrong forum (audio)
• Don’t Worry About the Vase blog (audio)
• Dwarkesh Podcast. My top podcast pick. Excellent guests.

Less frequent podcasts:

• No Priors — The hosts are VCs that interview builders and CEOs. Focus on AI and tech startups
• Moonshots — This is my feel-good entertainment podcast. Less signal. Extreme techno-optimism and dismantling the moon
• Mindscape — Sean Carroll (theoretical physicist) talks with guests about the nature of reality
• Naval — Timeless principles about high-agency and long-term focus. Minor focus on wealth. Infrequent content
• 80000 hours — Deep dives into topics surrounding saving the world and Effective Altruism. Warning: can be overly lengthy
• Y Combinator Startup Podcast — It’s in the name, though recently it also includes terrible AI safety takes by Garry Tan
• Win-Win — Exploration of game theory, cooperation, incentives. The host has read Meditations on Moloch too many times

What’s With All The Audio Links?

As I spend enough time looking at screens and reading, being able to consume blogs, articles, and podcasts via audio is great. One of my favourite activities is walking in the park with a good episode on, and doing laundry has never been this much fun.

I started out using Spotify, but switched to AntennaPod a few months ago. You can download this open-source podcast player for free. It’s shown in the screenshot, and I can recommend it.

Twitter, No Wait X

Here are 10 X accounts you can follow for high-signal:

• Scott Alexander (@slatestarcodex) — Mentioned above, Astral Codex Ten author
• Eliezer Yudkowsky (@ESYudkowsky) — The final boss of rationalism, author of The Sequences
• Vitalik Buterin (@VitalikButerin) — Ethereum founder, decentralization freedmons n stuffs
• Zvi Mowshowitz (@TheZvi) — Mentioned above, don’t Worry About the Vase author
• Aella (@Aella_Girl) — Prostitute statistician
• Rob Wiblin (@robertwiblin) — 80000 Hours podcast host
• Liv Boeree (@Liv_Boeree) — Win-Win podcast host
• Robin Hanson (@robinhanson) — Came up with Great Filter, Prediction Markets, Grabby Aliens, and more
• Andrej Karpathy (@karpathy) — AI researcher
• Ilya Sutskever (@ilyasut) — AI researcher

Turns out a lot of the people I consider high-signal are only on X. Seems like they haven’t been knocked around much by the culture wars. Hence, this is a list of X accounts. In an effort to reduce the negative effects of The Algorithm and wasting time on noise, I created a list of X accounts, which I named Signal. This way can easily restrict my feed to only posts from these accounts. I keep this Signal list concise, at 10-15 accounts, many of which are listed above.

Including Robin Hanson here reminded me of Manifold Markets, which I am giving this honourable mention as a decent news source.

Your Top Picks?

What are your favourite sources of high-quality content? Let me know in the comments!

This post is a spiritual successor to my old Year In Books posts (2017, 2016, 2015). I’ve been thinking about posting another one of these for over 12 months. Since I “read” more via the sources mentioned in this post than classical books, and this seems like the more interesting topic for readers, you get this post instead.

The post High Density Information Sources in 2026 appeared first on Blog of Jeroen De Dauw.

Pretty sure no-one is waiting for this, but after having spent a couple of years on the Fediverse (Mastodon in my case) I decided to add ActivityPub support to my WordPress installation via the ActivityPub plugin. I have the WP Rest Cache plugin active, so I’m expecting things to gently hum along, without (most likely) or with these posts gaining traction. Kudo’s to Stian and Servebolt for…

Source

La ligne de commande communiste, le code Baudot et le comte ChatGPT

Il y a quelques mois, un lecteur m’a fait découvrir un incroyable jeu historico-politique entièrement réalisé en AsciiArt: « Le comte et la communiste », de Tristan Pun.

• Le comte et la communiste (debeauharnais.itch.io)

La simplicité des graphismes m’a fait plonger dans l’histoire comme dans un excellent livre. Jouant une espionne/servante, vous êtes amené à découvrir l’envers du décor d’un château aristocrate pendant la Première Guerre mondiale. De manière très intéressante pour le sous-texte sociopolitique, le temps passé dans le château est proportionnel au nombre de lessives. Car, bien qu’espionne, vous êtes avant tout une servante et il va falloir se remonter les manches et faire la lessive !

Si je vous en parle avec tant d’enthousiasme, c’est qu’à un moment du jeu vous trouvez une bande de papier contenant un message au format Baudot. Le code Baudot est l’ancêtre de l’ASCII et le premier encodage de caractère utilisé sur les télégraphes automatiques : le message est directement reçu sur des bandes de papier, à la différence du Morse qui nécessite un opérateur humain à la réception.

Dans le jeu, le message est trouvé sur une bande de papier servant de signet qui ressemble à ceci.

Sur une plaque, vous trouverez toutes les informations pour déchiffrer le code Baudot.

Il ne reste plus qu’à déchiffrer le message… Mais, très vite, j’ai trouvé ça laborieux. Et si je demandais à ma fidèle ligne de commande de le faire à ma place ? Après tout, la lecture de l’excellentissime « Efficient Linux at the Command Line », de Daniel J. Barret, m’a mis en confiance.

Décoder le message Baudot en ligne de commande

Attention, je vous préviens, ça va être très technique. Vous n’êtes pas obligé de vous infliger ça.

Vous êtes toujours là ? C’est parti !

Une fois le code en Asciiart copié/collé dans un fichier, on va l’afficher avec "cat". Même si ce n’est pas strictement nécessaire, je commence toujours toutes mes chaînes de pipe avec cat. Cela me semble plus clair.

Ici, la difficulté est que je veux accéder aux colonnes : je veux reconstruire un mot en prenant les premières lettres de chaque ligne, puis les secondes de chaque ligne, etc.

La commande Unix qui se rapproche le plus de cela est "cut". Cut permet de prendre le Xème caractère d’une ligne avec l’option -cX. Pour la quinzième, je fais donc "cut -c15". Tout de suite, je réalise que je vais avoir besoin d’une boucle. Considérant que les lignes font moins de 100 caractères, je peux faire un

for i in {1..100}; do" avec un "cut -c$i

Et voilà, je sais désormais isoler chaque colonne.

Dans l’asciiart, le binaire du code Baudot est représenté par des "o" et des espaces. Par soucis de clarté, je vais remplacer les espaces par des "l" (ça ressemble à un "1" binaire). La commande Unix pour faire des substitutions de caractères est "tr" (translate): tr " " l (l’espace est entre guillemets).

Toujours par souci de clarté, je vais effacer tout ce qui n’est pas un o ou un l. Tr permet d’effacer des caractères avec l’option -d et de prendre "tous les caractères sauf ceux de la liste" avec l’option -c (complémentaire). Je rajoute donc un tr -cd "ol".

La chaîne dans ma boucle ressemble donc à:

cat $1|cut -c"$i"|tr " " l|tr -cd "ol"

Problème : mes groupes de 5 lettres sont toujours verticaux !

J’ai tenté l’approche de supprimer les retours à la ligne avec tr -d "\n", mais cela produit des résultats bizarres, surtout que le dernier retour à la ligne est lui aussi supprimé.

Du coup, la commande qui me semble tout indiquée pour faire cela est le contraire de "cut" : "paste". Mais, essayez de lancer la chaîne dans "paste" : rien ne se passe !

Et pour cause : paste est initialement conçu pour joindre chaque ligne de plusieurs fichiers. Ici, il n’y a qu’un seul fichier : le flux d’entrée. Paste ne peux donc rien lui joindre.

Heureusement, l’option "-s" permet de dire à paste de tout mettre sur une seule ligne. Je suis complètement passé à côté pour une raison très simple : la page man de paste est incompréhensible.

-s, --serial
copier un fichier à la fois au lieu de le faire en parallèle

Je défie quiconque de voir le rapport entre la page de man et la fonction réelle. J’ai heureusement eu l’intuition de tester avec "tldr" au lieu de man.

Join all the lines into a single line, using TAB as delimiter:
paste -s path/to/file

Avouez que c’est déjà beaucoup plus clair !

Un p’tit test me révèle que c’est presque bon. Tout est sur une ligne. Sauf qu’il y’a désormais des TAB entre chaque lettre. On pourrait les enlever avec tr. Ou simplement dire à paste de ne pas les mettre en utilisant à la place un séparateur nul:

cat $1|cut -c"$i"|tr " " l|tr -cd "ol"|paste -sd "\0"

Ma boucle for m’affiche désormais chaque lettre sur une ligne. Il ne me reste qu’à traduire le code Baudot.

Je peux, par exemple, rajouter un pipe vers "sed s/llloo/a/" pour remplacer les lettres a. Et un pipe vers un nouveau sed pour la lettre b et ainsi de suite. Ça fonctionne, mais c’est moche et très lent (chaque sed lançant son propre process).

Lorsqu’on a beaucoup de règles sed, autant les mettre dans un fichier baudot.sed qui contient les commandes sed, une par ligne :

s/llloo/a/
s/oollo/b/
s/loool/c/
...

Je peux appeler ces règles avec "sed -f baudot.sed".

Le code Baudot a une subtilité : y’a un code qui permet de passer en mode "caractère spécial". Je ne prends pas la tête, je me contente de remplacer ce code par "<" et le code pour revenir en mode normal par ">" (ces deux caractères n’existant pas dans le code Baudot). De cette manière, je sais que toute lettre entre < > n’est pas vraiment la lettre, mais le symbole correspondant. Un <m> est en réalité un ".". Également, il y a de nombreux espaces avant et après les messages, qui ont été convertis en autant de "l". Là, j’ai fait un bon gros hack. Au lieu de mettre un "l" normal dans le code Baudot, j’ai mis un L majuscule. Ensuite, à la toute fin, je supprime les "l" restant avec une règle globale : "s/l//g" (le "g" indique de changer tous les l sur une ligne, même s’il y’en a plusieurs). Puis, je remets en minuscule le "L" avec "s/L/l". Oui, c’est un bon gros hack. Ça fait l’affaire.

Mon fichier baudot.sed ressemble alors à ça :

s/ooloo/</
s/lloll/ /
s/ooooo/>/
s/llloo/a/
s/oollo/b/
s/loool/c/
s/lollo/d/
s/llllo/e/
s/loolo/f/
s/oolol/g/
s/ololl/h/
s/llool/i/
s/loloo/j/
s/loooo/k/
s/ollol/L/
s/oooll/m/
s/looll/n/
s/oolll/o/
s/oolll/p/
s/olooo/q/
s/lolol/r/
s/llolo/s/
s/ollll/t/
s/llooo/u/
s/ooool/v/
s/olloo/w/
s/ooolo/x/
s/ololo/y/
s/olllo/z/
s/l//g
s/L/l/g

Mon message est décodé. Mais, bien entendu, il s’affiche verticalement.

Ça ne vous rappelle rien ?

Un bon vieux paste -sd "\0" remet tout à l’endroit (et cette fois-ci, je n’ai pas eu à chercher).

Dans le jeu, le seul symbole utilisé sera le point, qui est ici devenu un "<m>" ou "<m" s’il est à la fin du message. Soyons propres jusqu’au bout et rajoutons deux petits sed. On pourrait également faire un autre fichier sed avec tous les caractères, mais le jeu ne comporte finalement que deux messages.

Dommage, là j’étais chaud pour plus.

Mon script final est donc :

#!/bin/bash
for i in {1..100}; do
	cat $1|cut -c"$i"|tr " " l|tr -cd "ol"|paste -sd "\0"
done|sed -f baudot.sed|paste -sd "\0"|sed "s/<m>/./"|sed "s/<m/./"

Avec le recul, ce script est beaucoup plus simple et efficace qu’un script Python. Le script Python prendrait des dizaines de lignes et agirait sur une matrice de caractères. Les outils Unix, eux, agissent sur des flux de texte. J’y trouve une certaine élégance, un plaisir particulier. Le tout m’a pris environ 30 minutes, dont une bonne partie sur l’erreur de "tr -d \n".

Demander à ChatGPT de décoder le message Baudot

Comme mon compte Kagi me donne désormais accès à ChatGPT, je me suis dit que j’allais faire l’expérience de lui demander de résoudre le même problème que moi. Histoire de comprendre ce qu’est le « Vibe coding ».

Au départ, ChatGPT est perdu. Il ne sait clairement pas traduire les messages, m’assène de longues tables de soi-disant code Baudot (qui sont parfois correctes, mais pas toujours) et me raconte l’histoire de ce code (qui est généralement correcte, mais que je n’ai pas demandée). C’est verbeux, je dois lui dire plusieurs fois de faire cours et d’être efficace.

Je lui demande de me faire un script bash. Ses premières tentatives sont extrêmement longues et incompréhensibles. Il semble beaucoup aimer les scripts awk à rallonge.

Persévérant, je demande à ChatGPT de ne plus utiliser awk et je lui explicite chaque étape l’une après l’autre: je lui dit qu’il faut parcourir chaque colonne, la redresser, la convertir, etc.

Logiquement, il arrive à un résultat très similaire au mien. Il choisit d’utiliser "tr -d \n" pour supprimer les fins de ligne, mais, comme je l’ai dit, ça ne fonctionne pas correctement. Je lui passe, car je n’ai moi‑même pas compris l’erreur.

Je constate cependant une amélioration intéressante : là où j’ai demandé les 100 premières colonnes, chatGPT mesure la longueur avec :

for i in $(seq $(head -1 $1|wc -c)); do

Concrètement, il prend la première ligne avec "head -1", compte les caractères avec "wc -c" et construit une séquence de 1 jusqu’a ce nombre avec "seq".

C’est une excellente idée si on considère que la première ligne est représentative des autres. Une fois le "redressement" en place (il m’a fallu des dizaines de prompts et d’exemples pour arriver à lui expliquer, à chaque fois il prétend qu’il a compris et c’est faux), je lui demande de traduire en utilisant le code Baudot.

Au lieu de ma solution avec "sed", il fait une fonction bash "baudot_to_letter" qui est un gros case:

baudot_to_letter() {
  case $1 in
    00000) echo " " ;;
    00001) echo "E" ;;
    00010) echo "A" ;;

Fait amusant, les caractères ne sont pas en ordre alphabétique, mais dans l’ordre binaire de la représentation Baudot. Pourquoi pas ?

Je valide cette solution même si je préfère le sed parce que je n’avais pas envie de faire du bash mais utiliser les outils Unix. Je lui ai dit plusieurs fois que je voulais une commande Unix, pas un script bash avec plusieurs fonctions. Mais je lui laisse, car, au fond, sa solution est pertinente.

Maintenant que toutes les étapes ont été décrites, je teste son code final. Qui ne fonctionne pas, produisant une erreur bash. Je lui demande une nouvelle version en lui copiant-collant l’erreur. Après plusieurs itérations de ce type, j’ai enfin un script qui fonctionne et me renvoie la traduction du message suivante :

LLECJGCISTGCIUMCEISJEISKN CT UIXV SJECUZUCEXV

Le nombre de lettres n’est même pas correct. Je n’ai évidemment pas envie de débugger le truc. Je demande à lors à ChatGPT de lancer le script lui-même pour me donner la traduction :

À ce point de l’histoire, j’ai, montre en main, passé plus de temps à tenter d’utiliser ChatGPT que je n’en ai mis pour écrire mon propre script, certes imparfait, mais fonctionnel. Je me retrouve à faire des copier-coller incessants entre ChatGPT et mon terminal, à tenter de négocier des changements et déboguer du code que je n’ai pas écrit.

Et encore, pour ChatGPT, j’ai nettoyé le message en enlevant tout ce qui n’est pas le code Baudot. Mon propre script est beaucoup plus robuste. J’en ai marre et j’abandonne.

Moralité

ChatGPT n’est impressionnant que par sa capacité à converser, à prétendre. Oui, il peut parfois donner des idées. Il a par exemple amélioré la première ligne de mon script que j’avais bâclée.

Mais il faut avoir du temps à perdre. À ce moment-là, autant replonger dans un bon livre dont on sait que la majeure partie des idées sont bonnes.

ChatGPT peut être utile pour brainstormer à condition d’être soi-même fin connaisseur du domaine et très critique avec tout ce qui sort. C’est dire la débauche d’énergie pour finalement très peu de choses.

Vous croyez être plus efficace en utilisant l’AI, car vous passez moins de temps à « penser ». Mais les études semblent montrer qu’en réalité, vous êtes plus lent. Avec ChatGPT, on est tout le temps "occupé". On ne s’arrête jamais pour réfléchir à son problème, pour lire différentes ressources.

• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (metr.org)

Et lorsque ChatGPT vous fait vraiment gagner du temps, c’est peut-être parce qu’il s’agit d’un domaine où vous n’êtes pas vraiment compétent. En ce qui concerne la ligne de commande, je ne peux que répéter ma suggestion de lire « Efficient Linux at the Command Line ». Vraiment !

Comme le rappelle très bien Cal Newport: qui a le plus intérêt à ce que vous soyez un ouvrier incompétent qui se contente de pousser aveuglément sur les boutons d’une machine au lieu de faire fonctionner son cerveau ?

• Be Wary of Digital Deskilling (calnewport.com)

Peut-être que passer quelques heures à espionner les aristocrates en étant obligé de faire des lessives vous fera réfléchir à ce sujet. En tout cas, ça en vaut la peine !

Bon amusement, bonnes réflexions et… bonnes lessives !

I watched a movie this evening which featured the main actress singing “Both sides now” and is was moving until it became too musical-like for my taste. But now I’m in a Joni rabbit hole again, listening to all great versions of Joni performing that song. One of the earliest live video’s I found was from 1969 and on the other end of the timescale there’s the Grammy one from 2024 with Brandi…

Source

We’ve gone from generating funny images to AI being a core part of being a developer quite fast, haven’t we?

L’urgence de la souveraineté numérique pour échapper à la merdification

Le triste exemple de YouTube

Je n’ai plus de compte Google depuis plusieurs années. Je me suis rendu compte que j’évite autant que possible de cliquer sur un lien YouTube, car, à chaque vidéo, je dois passer par le chargement d’une page qui surcharge mon ordinateur pourtant récent, je dois tenter de lancer la vidéo, attendre plusieurs secondes qu’un énorme popup l’interrompe. Puis je dois faire en sorte de trouver le son original et non pas une version automatiquement générée en français. Une fois tout ça terminé, il faut encore se taper des publicités de parfois plusieurs minutes.

Tout ça pour voir une vidéo qui pourrait potentiellement contenir une information qui m’intéresse. Et encore, ce n’est pas du tout certain.

• De la merdification des choses (ploum.net)

Alors, oui il y a des moyens de contourner ces merdifications, mais c’est un travail permanent et qui ne fonctionne pas toujours. Donc, en gros, je ne clique sur les liens YouTube que quand je suis vraiment obligé. Genre avant je regardais les clips vidéos des groupes de métal que recommandait Alias. Désormais, j’utilise Bandcamp (j’y achète même des albums) quand il le mentionne ou je cherche ailleurs.

• Rock et metal progressifs, science-fiction, jeu de rôle et divagations de vieux gauchiste; maison fondée en 2002 (erdorin.org)

Vous croyez que votre vidéo doit être sur YouTube, car « tout le monde y est », mais, au moins dans mon cas, vous avez perdu de l’audience en étant uniquement sur YouTube.

Une merdification totalement assumée

Le pire, c’est de se rendre compte que la merdification est vraiment assumée de l’intérieur. Comme le souligne Josh Griffiths, YouTube encourage les créateurs à tourner des vidéos dont le scénario est généré par leur IA. YouTube rajoute des pubs sans le consentement du créateur.

• YouTube is Awful. I'm Not Posting There Anymore. (joshgriffiths.site)

Toujours dans son blog post, il décrit comment YouTube utilise votre historique vidéo pour déterminer votre âge et bloquer toutes les vidéos qui ne seraient pas appropriées. C’est tellement effrayant de stupidité que ça pourrait être dans une de mes nouvelles.

• Stagiaire au spatioport Omega 3000 (pvh-editions.com)

Une chose est certaine : en me connectant sur YouTube sans compte et sans historique, YouTube me propose spontanément des dizaines de vidéos sur les nazis, sur la Seconde Guerre mondiale, sur les fusils utilisés par les nazis, etc. Je n’ai jamais regardé ce genre de choses. Au vu du titre, certaines vidéos me semblaient à la limite de la théorie du complot ou du négationnisme. Pourquoi me les recommander ? L’hypothèse la plus effrayante serait que ce soit les recommandations par défaut !

Parce que ce n’est pas comme si YouTube ne savait pas comment effacer les vidéos qui ne lui plaisent pas !

• YouTube Erased 700 Videos of Israeli Human Rights Violations (theintercept.com)

Si vous réalisez des vidéos et que vous souhaitez les partager à des humains, par pitié, postez-les également ailleurs que sur YouTube! Personne ne vous demande d’abandonner votre « communauté », vos likes, vos 10 centimes de revenus publicitaires qui tombent tous les mois. Mais postez également votre vidéo ailleurs. Par exemple sur Peertube !

• What is PeerTube? (joinpeertube.org)

De la dépendance politique aux technologies merdifiées

Comme le dit très bien Bert Hubert, le problème de la dépendance aux monopoles américains n’est pas tant technique que culturel. Et les gouvernements européens devraient être les premiers à montrer l’exemple.

• Keynote opening Digital Commons EDIC: Moving beyond the Digital Uncommons (berthub.eu)

Je pense qu’il illustre parfaitement la profondeur du problème, car, dans sa conférence qui décrit la dépendance technologique de l’UE envers les USA et la Chine, il pointe vers des vidéos explicatives… sur YouTube. Et Bert Hubert ne semble même pas en réaliser l’ironie alors qu’il recommande Peertube un peu plus loin. Il héberge d’ailleurs ses projets personnels sur Github. Github appartient à Microsoft et son monopole sur les projets Open Source a des impacts dramatiques.

• How Github monopoly is destroying the open source ecosystem (ploum.net)

J’ai déjà noté à quel point l’Europe développe des solutions technologiques importantes, mais que personne ne semble s’en apercevoir parce que, contrairement aux USA, nous développons des technologies qui offrent de la liberté aux utilisateurs : le Web, Linux, Mastodon, le protocole Gemini.

• Pourquoi n’y a-t-il pas de Google européen ? (ploum.net)

À cette liste, j’aimerais rajouter VLC, LibreOffice et, bien entendu, PeerTube.

Les solutions européennes qui ont du succès font partie des communs. Elles sont tellement évidentes que beaucoup n’arrivent plus à les voir. Ou à les prendre au sérieux, car « pas assez chères ».

Le problème de l’Europe n’est pas le manque de solutions. C’est simplement que les politiciens veulent « un Google européen ». Les politiciens sont incapables de voir qu’on ne lutte pas contre les monopoles américains en créant, avec 20 ans de retard, un sous-monopole européen.

C’est un problème purement culturel. Il suffirait que quelques députés européens aient le courage de dire : je supprime mes comptes X, Facebook, Whatsapp, Google et Microsoft pour un mois. Un simple mois durant lequel ils accepteraient que, oui, les choses sont différentes, il faut s’adapter un peu.

Ce n’est pas comme si le problème n’était pas urgent : tous nos services informatiques officiels, tous nos échanges, toutes nos données sont aux mains d’entreprises qui collaborent ouvertement avec l’armée américaine. Vous croyez vraiment que les militaires américains n’ont pas exploité toutes les données Google/Microsoft/Whatsapp des politiciens vénézuéliens avant de lancer leur raid ? Et encore, le Venezuela est un des rares pays qui tentait officiellement de se passer des solutions américaines.

L’honnêteté de considérer une solution

Quitter les services merdifiés est difficile, mais pas impossible. Cela peut se préparer, se faire petit à petit. Si, pour certains, c’est actuellement strictement impossible pour des raisons professionnelles, pour beaucoup d’entre nous, c’est surtout que nous refusons d’abandonner nos habitudes. Se plaindre, c’est bien. Agir, c’est difficile et nécessite d’avoir le temps et l’énergie à consacrer à une période de transition.

• Dire au revoir aux GAFAM : journal d’une ancienne instagrammeuse (www.24joursdeweb.fr)

Bert Hubert prend l’exemple du mail. En substance, il dit que le mail n’est plus un bien commun, que les administrations ne peuvent pas utiliser un mail européen, car Microsoft et Google vont arbitrairement rejeter une partie de ces emails. Pourtant, la solution est évidente : il suffit de considérer que la faute est chez Google et Microsoft. Il suffit de dire « Nous ne pouvons pas utiliser Microsoft et Google au sein des institutions officielles européennes, car nous risquons de ne pas recevoir certains emails ».

Le problème n’est pas l’email, le problème est que nous nous positionnons en victimes. Nous ne voulons pas de solution ! Nous voulons que ça change sans rien changer !

Beaucoup de problèmes de l’humanité ne proviennent pas du fait qu’il n’y a pas de solutions, mais qu’en réalité, les gens aiment se plaindre et ne veulent surtout pas résoudre le problème. Parce que le problème fait désormais partie de leur identité ou parce qu’ils ne peuvent pas imaginer la vie sans ce problème ou parce qu’en réalité, ils bénéficient de l’existence de ce problème (on appelle ces derniers des « consultants » ).

Il y a une technique assez simple pour reconnaître ce type de situation : c’est, lorsque tu proposes une solution, de te voir immédiatement rétorquer les raisons pour lesquelles cette solution ne peut pas fonctionner. C’est clair, à ce moment, que la personne en face ne cherche pas une solution. Elle n’a pas besoin d’un ingénieur, mais d’un psychologue (rôle que prennent cyniquement les vendeurs).

• Du désir profond de se faire arnaquer (ploum.net)

Une personne qui cherche réellement à résoudre son problème va être intéressée par toute piste de solutions. Si la solution n’est pas adaptée, elle va réfléchir à comment l’améliorer. Elle va accepter certains compromis. Si elle rejette une solution, c’est après une longue investigation de cette dernière, car elle a réellement l’espoir de résoudre son problème.

La solution du courage politique

Pour les gouvernements aujourd’hui, il est techniquement assez simple de dire « Nous voulons que nos emails soient hébergés en Europe par une infrastructure européenne, nous voulons diffuser nos vidéos via nos propres serveurs et faire nos annonces officielles sur un site que nous contrôlons. » C’est même trivial, car des milliers d’individus comme moi le font pour un coût dérisoire. Et il y a même des tentatives claires, comme en Suisse.

• New Open Source law in Switzerland (joinup.ec.europa.eu)

Les seules raisons pour lesquelles il n’y a même pas de réflexion poussée à ce sujet sont, comme toujours, la malveillance (oui, Google et Microsoft font beaucoup de cadeaux aux politiciens et sont capables de déplacer des montagnes dès qu’une alternative à leur monopole est considérée) et l’incompétence.

Malveillance et incompétence n’étant pas incompatibles, mais plutôt complémentaires. Et un peu trop fréquentes en politique à mon goût.

• Image postée par Tibolalu sur Mastodon

How Github monopoly is destroying the open source ecosystem

I teach a course called "Open Source Strategies" at École Polytechnique de Louvain, part of the University of Louvain.

As part of my course, students are required to find an open source project of their choice and make a small contribution to it. They send me a report through our university Gitlab. To grade their work, I read the report and explore their public interactions with the project: tickets, comments, pull requests, emails.

This year, during my review of the projects of the semester, Github decided to block my IP for one hour. During that hour, I simply could not access Github.

It should be noted that, even if I want to get rid of it, I still have a Github account and I was logged in.

• We need to talk about your Github addiction (ploum.net)

The block happened again the day after.

This gave me pause.

I wondered how many of my students’ projects were related to projects hosted on Github. I simply went into the repository and counted 238 students reports in the last seven years:

ls -l projects_*/*.md | wc -l
238

Some reports might be missing. Also, I don’t have the reports before 2019 in that repository. But this is a good approximation.

Now, let’s count how many reports don’t contain "github.com".

grep -L github.com projects_*/*.md | wc -l
7

Wow, that’s not a lot. I then wondered what those projects were. It turns out that, out of those 7, 6 students simply forgot to add the repository URL in their report. They used the project webpage or no URL at all. In those 6 cases, the repository happened to be hosted on Github.

In my course, I explain at great length the problem of centralisation. I present alternatives: Gitlab, Codeberg, Forgejo, Sourcehut but also Fossil, Mercurial, even Radicle.

• Radicle: peer-to-peer collaboration with Git (lwn.net)
• From Git to Fossil (lucio.albenga.es)

I literally explain to my students to look outside of Github. Despite this, out of 238 students tasked with contributing to the open source project of their choice, only one managed to avoid Github.

The immediate peril of centralisation

As it was demonstrated to me for one hour, the immediate peril of centralisation is that you can suddenly lose access to everything. For one hour, I was unable to review any of my students’ projects. Not a great deal, but it serves as a warning. While writing this post, I was hit a second time by this block.

A few years ago, one of my friends was locked out of his Google account while travelling for work at the other end of the world. Suddenly, his email stopped working, most of the apps on his phone stopped working, and he lost access to all his data "in the clouds". Fortunately, he still had a working email address (not on Google) and important documents for his trip were on his laptop hard drive. Through personal connections at Google, he managed to recover his account a few weeks later. He never had any explanations.

• Et si vos comptes disparaissaient demain ? (ploum.net)

More recently, Paris Buttfield-Addison experienced the same thing with his Apple account. His whole online life disappeared, and all his hardware was suddenly bricked. Being heavily invested in Apple doesn’t protect you.

• 20 Years of Digital Life, Gone in an Instant, thanks to Apple (hey.paris)

I’m sure the situation will be resolved because, once again, we are talking about a well-connected person.

But this happens. All the time. Institutions are blindly trusting monopolies that could lock you out randomly or for political reasons as experienced by the French magistrate Nicolas Guillou.

• The Judge at the End of Europe (www.project-syndicate.org)

Worst: as long as we are not locked out, we offer all our secrets to a country that could arbitrarily decide to attack yours and kidnap your president. I wonder how much Venezuelan sensitive information was in fact stored on Google/Microsoft services and accessed by the US military to prepare their recent strike.

Big institutions like my Alma Mater or entire countries have no excuse to still use American monopolies. This is either total incompetence or corruption, probably a bit of both.

The subtle peril of centralisation

As demonstrated by my Github anecdote, individuals have little choice. Even if I don’t want a Github account, I’m mostly forced to have one if I want to contribute or report bugs to projects I care about. I’m forced to interact with Github to grade my students’ projects.

237 out of 238 is not "a lot." It’s everyone. There’s something more than "most projects use Github."

According to most of my students, the hardest part of contributing to an open source project is finding one. I tell them to look for the software they use every day, to investigate. But the vast majority ends up finding "something that looks easy."

That’s where I realised all this time my students had been searching for open source projects to contribute to on Github only. It’s not that everything is on Github, it is that none of my students can imagine looking outside of Github!

The outlier? The one student who contributed to a project not on Github? We discussed his needs and I pointed him to the project he ended up choosing.

Github’s centralisation invisibilised a huge part of the open source world. Because of that, lots of projects tend to stay on Github or, like Python, to migrate to Github.

The solution

Each year, students come up with very creative ways not to do what I expect while still passing. Last year, half of the class was suddenly committing reports with broken encoding in the file path. I had never seen that before and I asked how they managed to do it. It turns out that half the class was using VS Code on Windows to do something as simple as "git commit" and they couldn’t use the git command line.

This year, I forced them to use the command line on an open source OS, which solved the previous year’s issue. But a fair number of the reports are clearly ChatGPT-generated, which was less obvious last year. This is sad because it probably took them more effort to write the prompt and, well, those reports are mostly empty of substance. I would have preferred the prompt alone. I’m also sad they thought I would not notice.

But my main mistake was a decade-long one. For all those years, I asked my students to find a project to contribute to. So they blindly did. They didn’t try to think about it. They went to Github and started browsing projects.

For all those years, I involuntarily managed to teach my students that Open Source was a corner of the web, a Microsoft-managed repository of small software one can play with. Nothing serious.

This is all my fault.

I know the solution. Starting this year, students will be forced to contribute to a project they use, care about or, at the very least, truly want to use in the long term. Not one they found randomly on Github.

If they think they don’t use open source software, they should take a better look at their own stack.

And if they truly don’t use any open source software at all and don’t want to use any, why do they want to follow a course about the subject in the first place?

I stop watching and downvote the moment your video has middle-of-screen subtitles. Idem ditto for huge forced subtitles.

I remember when PHP 4 was a thing. jQuery was new and shiny. Sites were built with tables, not divs. Dreamweaver felt like a life hack. Designs were sliced in Photoshop. Databases lived in phpMyAdmin.

Proposed diagnostic construct. Not recognized by any legitimate diagnostic body, though widely reinforced by social institutions.

Diagnostic Criteria

A. Persistent pattern of cognitive, emotional, and social functioning characterized by a strong preference for normative coherence, rapid closure of uncertainty, and limited tolerance for sustained depth—intellectual, experiential, or emotional—beginning in early socialization and present across multiple contexts (e.g. interpersonal relationships, workplace environments, family systems, cultural participation).

B. The pattern manifests through three (or more) of the following symptoms:

1. Normative Rigidity
   Marked discomfort when encountering deviations from customary practices, beliefs, or emotional expressions, even when such deviations are demonstratively non-harmful or adaptive. Often expressed as “But why?” followed by silence rather than curiosity.
2. Contextual Literalism
   Difficulty interpreting meaning, identity, or emotional communication outside their most common cultural framing; metaphor and subtext are tolerated primarily when socially standardized.
3. Consensus-Seeking Reflex
   Habitual alignment with majority opinion, authority, or prevailing emotional norms when forming judgments, often prior to personal reflection or affective attunement.
4. Change Aversion with Rationalization
   Resistance to novel ideas or emotional complexity, accompanied by post-hoc justifications framed as realism, pragmatism, or emotional maturity, rather than acknowledged emotional discomfort.
5. Social Script Dependence
   Reliance on rehearsed conversational and emotional scripts (weather, productivity, polite outrage), and visible distress when interactions require unscripted vulnerability, prolonged emotional presence, or exploratory dialogue.
6. Hierarchy Calibration Preoccupation
   Excessive attention to formal roles, relational labels, and status markers, such as job titles, relationship escalators, age-based authority, or institutional validation, with difficulty engaging others outside these frameworks as emotionally or epistemically equal.
7. Ambiguity Intolerance
   A pronounced need to resolve uncertainty quickly—cognitively and emotionally, even at the cost of nuance. Mixed feelings, ambivalence, or unresolved emotional states may be experienced as distressing or unproductive. Questions with multiple valid answers may be experienced as irritating rather than interesting.
8. Pathologizing the Outlier
   Tendency to interpret uncommon preferences, communication styles, atypical cognitive styles, emotional expressions, relational structures, or life choices as problems needing explanation, containment, or optimization.
9. Empathy via Projection
   Assumption that others experience emotions in similar ways and intensities, leading to misattuned reassurance, premature advice, or minimization of divergent affective experiences, resulting in advice that begins with “If it were me…” and ends with confusion when it is, in fact, not them.
10. Depth Avoidance in Sustained Inquiry
    Marked difficulty engaging in prolonged, high-resolution discussion of topics that extend beyond surface facts, sanctioned opinions, or immediately actionable conclusions. Deep exploration of systems, first principles, or existential implications is often curtailed.
11. Diffuse Interest Profile
    A pattern of broad but shallow interests, with engagement driven primarily by social relevance or utility rather than intrinsic fascination. Mastery is rare; familiarity is common.
12. Expertise Anxiety
    Discomfort in the presence of deep intellectual or emotional proficiency—either in oneself or others—leading to minimization, deflection, or reframing depth as excessive, obsessive, or impractical.
13. Instrumental Curiosity
    Curiosity activated mainly when a topic yields immediate benefit. Curiosity pursued for its own sake may be regarded as indulgent, inefficient, or emotionally suspect.
14. Affective Flattening in Non-Crisis Contexts
    A restricted range or shallowness of emotional experience outside socially sanctioned peaks (e.g. celebrations, emergencies). Subtle, slow-building, or internally complex emotional states may be under-recognized, quickly translated into simpler labels, or bypassed through distraction.
15. Emotional Resolution Urgency
    A strong drive to “process,” “move on,” or “feel better” rapidly, often resulting in premature emotional closure. Emotional depth is equated with rumination rather than information.
16. Vulnerability Time-Limiting
    Tolerance for emotional exposure is constrained by implicit time or intensity limits. Extended emotional presence—grief without deadlines, joy without justification, love without clear structure—may provoke discomfort or withdrawal.

C. Symptoms cause clinically significant impairment in adaptive curiosity, cross-cultural understanding, deep relational intimacy, sustained emotional attunement, and the capacity to remain present with complex internal states—both one’s own and others’, or collaboration with neurodivergent individuals, particularly in rapidly changing environments or in relationships requiring long-term emotional nuance.

D. The presentation is not better explained by acute stress, lack of exposure, trauma-related emotional numbing, cultural display rules alone, or temporary social conformity for situational survival (e.g. customer service roles, family holidays).

Specifiers

• With Strong Institutional Reinforcement (e.g. corporate culture, rigid schooling)
• With Moral Certainty Features
• Masked Presentation (appears emotionally open but only within safe, scripted bounds)
• Late-Onset (often following promotion to middle management)

Course and Prognosis

NTSD is typically stable across adulthood. Improvement correlates with sustained exposure to emotional complexity without forced resolution, relationships that reward presence over performance, and practices that cultivate interoceptive awareness rather than emotional efficiency. Partial remission has been observed following prolonged engagement with artists, immigrants, queer communities, altered states, long-form grief, open-source software, or toddlers asking “why” without stopping.

Differential Diagnosis

Must be distinguished from:

• Willful ignorance (which involves effort)
• Malice (which involves intent)
• Burnout (which improves with rest)
• Actual lack of information (which improves with learning)

NTSD persists despite information.

When we moved to our new home, we looked for a new place to exercise. While we had been spoiled with a gym at the end of our old street, our new location required a half-hour commute, which quickly turned working out into a chore.

Instead, we opted to build a “home gym-ish”. We purchased an elliptical trainer and a Concept2 RowErg which were regularly used, and some weights. While working out at home has its benefits (open 24/7, no commute, better music, shower access!) it still got a bit boring after a while.

I’ve never been a fan of running, and after my hip replacement it even felt completely off. Cycling is a means of transport to me - not a sport I enjoy. Don’t get me wrong: they are both fantastic for the cardiovascular system and building endurance, but they do not tick the “total-body” sport box. Running is high-impact, which is great for bone density in the legs, but it doesn’t do much for the upper body. Cycling on the other hand is a non-weight-bearing, low-impact sport that is gentle on the joints but can actually lead to lower bone density over time because your skeleton isn’t being “stressed” enough to stay strong.

Back in early 2021, I noticed a new CrossFit box had opened in our little town called CrossFit Endgame. I went to a try-out class, but it being the height of COVID-19 restrictions, classes were outdoor and limited to 4 people. Add the fact that it was winter, I left feeling extremely self-conscious and out of shape after that class and my general feeling was kind of ‘meh’, so I didn’t pursue it.

Fast forward to the end of 2021 - my partner had started CrossFit in CrossFit Gent as a perk of teaching yoga classes in that box. Seeing the progress she was making I felt peer-pressured quietly inspired (read: she didn’t do/say anything, it was all me :P) so in May 2022 I contacted the local box again, asking to do another try-out class. My idea was to buy a voucher for 10 sessions, and see after that, but the owner (Jasper) talked me into getting a subscription for half a year, 1 class per week - the reasoning being that a subscription creates a habit, while a voucher usually just sits in a pocket gathering dust.

I took the bait and signed up.

One of the things that won me over was how infinitely scalable everything is. Coming in with mobility issues in one hip and a full replacement of another (due to Legg–Calvé-Perthes), I was worried about certain movements, but the coaches helped offering adjustments for the movements where necessary, scaling to my abilities, needs and level - whether it’s the weight on the bar or the complexity of the movement, they make sure you’re challenged but safe.

Those first few weeks I discovered muscles I didn’t know I had and they were all complaining - loudly. Eventually the complaining lessened and the Tuesday workouts became therapy - I’d walk in frustrated from work and walk out completely zen. It turns out, lifting heavy things with friends is cheaper than a therapist and twice as rewarding. Dropping heavy things is therapeutic on its own!

During that first half year I made a lot of new friends, got inspired by our coaches and learned many new movements - still being very mediocre at them at best :P

After those six months I did not hesitate and subscribed for a year of unlimited classes. I started going twice a week (Tuesday and Thursday evening), sometimes (as time permitted) adding a core-focused class to the mix. A temporal increase in soreness, but my body adjusted, reducing the days of soreness. I started noticing that I could do more, everything around the house - even the simplest of chores - felt easier!

By the end of 2023 a programming change was made which allowed me to pick up another class on Friday evening - a good way to start the weekend. Fast forward to today: I routinely go to 5 classes a week - Foundations, WODs and Core. Around that time the box rebranded to Endgame Functional Fitness, dropping the official CrossFit affiliation for ethical and financial reasons, though the methods and amazing community stayed exactly the same.

It has become a part of who I am. Stronger, fitter, saner, happier and very grateful that Jasper took that gamble of opening up a box in a town he’d never heard of. And one of the best perks? Coach Ona, the super sweet Border Collie :)