So there is this post which says:
"Yes, the people who are likely to care are admins with cobwebby
homebrew cronjobs that regularly generate painstakingly formatted
security reports and send them to the fax machine, or whatever."

...I feel extremely personally attacked by this :)
(Replace fax with mail, or whatever.)

I want my freshly upgraded to Debian Trixie Raspberry Pi to keep sending this cobwebby report... even if it is only for a couple of years to come... thus:

How to get lastb back on Debian

install dependencies:
apt install build-essential gettext autoconf flex bison libtool autopoint

get the source:
git clone https://github.com/util-linux/util-linux.git

rtfm:
cd util-linux
more Documentation/howto-compilation.txt

compile:
./autogen.sh && ./configure --disable-all-programs --enable-last
make last

install:
cp ./last /usr/bin/last
ln -s /usr/bin/last /usr/bin/lastb

happiness:
# lastb

btmp begins Thu Dec 4 15:50:47 2025

25 Mar 2026 11:44am GMT

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.

25 Mar 2026 11:44am GMT

The Social Smolnet

It might have been an email thread. Or a lobste.rs comment. It was a discussion about yet another attempt at a new decentralized social protocol. And we reached the conclusion that with blogs and email, we already had a decentralized social network. We only needed to use it.

This was the last push I needed to implement in Offpunk the social features I had imagined years ago. Share and Reply. Available since Offpunk 3.0.

• Offpunk 3.0 Release (ploum.net)
• Offpunk.net

Share

Are you reading something interesting in Offpunk and want to share it? Well, simply write it:

share

or

share myfriend@example.com

A new mail containing the URL to share will be opened in your email client of choice (as determined by xdg-open). The title will be the title of the page. You only need to add some text to explain why you want to share that page.

Reply

Ever read a blog post and wanted to send feedback or a simple thank you to the author? Simply write:

reply

Reply will try to find a mailto link by exploring the page, root pages and, since 3.1, potential "contact" pages. It sometimes works really well. Often, the mail address is obscured or hidden. That's not a problem. You only need to find it once because Offpunk allows you to save it for the page or the whole online space.

Give an email address as an argument to reply and it will be saved in Offpunk for the page or the whole online space.

If you come across an email address that may be of use in the future but don't want to react now, use "save":

reply save author@example.com

or, if you want to use autodetection:

reply save

Yes, it is enough

It looks like nothing. It looks like trivial. But for me, this really transformed Gemini/Gopher and the Small Web into a social network. As I use neomutt+neovim as my mail client, I don't leave my terminal. I simply write "reply", neovim opens, I write "Thank you for this nice post", :wq, ,and voilà. The mail will be sent during my next synchronization.

• My disconnected email workflow (ploum.net)

Almost as easy as clicking a "like" button but way more personal. Even easier if, like me, you dislike touching a mouse or opening a browser!

Replying to my own post in Neovim

This is the Social SmolNet

In less than two months, I already used this feature to react to 40 different online spaces, not counting that I've used it multiple times with some people.

40 saved reply addresses (41 but the first line is wrongly counted)

I even started using Offpunk as an address book for my blogger friends. Instead of laboriously autocompleting their email addresses, I go to their blog/gemini capsule/gopher hole and write "reply".

The biggest lesson I take is that "social networks" are not about protocols but about how we use the existing infrastructure. Microsoft and Google are working hard to make sure you hate email and hate building a website. But we don't have to obey. We can enjoy writing lightweight HTML and sending quick emails to each other. We have the right to read, write, and have social fun without Javascript and centralized platforms. We have the duty to keep this torch lit.

In the meantime, if you receive from me very short emails reacting to some of your posts, now you know why.

But, of course, feel free not to reply!

• Do not apologize for replying late to my email (ploum.net)

25 Mar 2026 11:44am GMT

Scène de salle d'attente

Extrait de mon journal du 6 mars, dans la salle d'attente du docteur X.

Le couple entre, asphyxiant l'air de l'étroite salle d'attente avec leurs remugles de fumée de cigarette. Les deux s'asseyent à l'aveugle sans jamais quitter leur smartphone des yeux, sans que les pouces ne cessent de s'agiter.

Après quelques instants, elle tente de le regarder, elle lui sourit, elle lui adresse plusieurs fois la parole. Lui ne se retourne même pas, n'interrompt pas une fraction de seconde la sarabande de ses pouces.

Alors elle replonge sur son écran, le manipule, le triture avant de tendre le bras pour le mettre sous le nez de son homme.

Lui, forcé de s'interrompre, recule légèrement la nuque, regarde l'écran de sa compagne puis tourne enfin la tête pour la regarder elle. Il n'a pas un sourire, pas un seul trait de son visage renfrogné ne tressaille. Mais elle a pu établir un contact visuel, elle est satisfaite, elle sourit.

Ils replongent alors tous deux dans leur petit univers distinct, comme s'ils étaient deux étrangers.

25 Mar 2026 11:44am GMT

How I fought my smartphone addiction

In a poignant Gemini post, Kevin Boone wrote about his anxiety to go out of his house without his phone. (This is the Gemini protocol, totally unrelated to the Google chatbot.)

• Phone anxiety (larsthebear.me)
• Web version of the former

Around 2018, I had the same epiphany: I was unable to get out of my house without my phone. In fact, I was so addicted that it was hard not to take the phone with me even inside the house or, God forbid, into the bathroom!

I had this discussion with Matt Baer, Write.as creator, and he told me that he had started to consciously go for short walks without his smartphone. I thought it was a good idea. I started to leave my phone at home for short walks. I disabled notifications. I even invested in an e-ink smartphone and, later, in a Mudita Kompakt.

• Se passer d'écran avec un téléphone e-ink (ploum.net)
• Une vie sans notifications (ploum.net)

At first, not having a phone was a real source of anxiety. For me, the anxiety was not about being able to call someone or being called. It was really about missing notifications, about not knowing if I had a new email. It was about not being able to "feel like I was doing something" if I had to wait a couple of minutes somewhere.

What is even more scary about this particular addiction is that the anxiety of being without a phone is not only internal: it is also highly socially inflicted. My mother asked me: "What if there is an urgency for me or your father?" To which I replied: "I'm not a medic and I live 30 minutes away from you. If there's an urgency for you, telling me about it is not urgent and will not help."

But, quickly, the feeling to be without a smartphone changed from anxiety to liberating. I felt really happy not to have a phone on me while outside. I was rediscovering my old way of getting lost in my thought, of sometimes talking to myself to clarify an idea. Which is less weird these days because everybody assumes you have an ear bud and are on the phone with someone else. In fact, when walking alone, I'm often on a call with myself.

It may seem weird, but instead of scrambling for my phone to find a direction or the name of that actor that was in that movie, I made peace with the fact that "I didn't know something." I look around for clues about a bus schedule, I ask strangers for directions. I let my subconscious work in the background to surface the forgotten name half an hour later. And I appreciate that. Sure, there are times when things would have been easier with a smartphone. But nothing insurmountable.

I became more and more allergic to any kind of notifications, even from other phones. I feel them as constant aggression. In part because I was addicted, in part because those are, by definition, designed to disrupt your thought. That's the whole purpose of a notification.

And we are only starting to understand the damage those are doing to our cognitive abilities.

• How Much Cognitive Damage Does A Phone Notification Actually Do? (carlhendrick.substack.com)

These days, I use a Mudita phone which has a side switch to put it completely offline (a kind of hardware enabled airplane mode). Every night, I pull that switch. Some days, I realise I totally forgot to put my phone online in the morning.

When I go outside, I ask my wife: "Is there any reason for me to take my phone?" If there's none, which is the usual case, I don't take it. This ritual has two purposes: it allows me to consciously choose whether to take my phone or not and to remind my wife that I don't have my phone with me.

My only exception is when I go cycling. I remember how my friend Thierry Crouzet broke his hip in the middle of the woods. So I take my phone, just in case. This is not problematic because you cannot mindlessly start checking your phone while pedalling. It's just a little weight in my jersey pocket.

• Un auteur se fracture le fémur pour faire parler de lui (gemini.tcrouzet.com)
• Web version of the former

I would like to say that I'm cured of my smartphone addiction, but this is not true. Put a smartphone with a shiny coloured screen in my pocket and it would probably not take more than a few days for me to return to what is the new social norm. I'm an addict and will stay an addict my whole life. But at least I have put in place enough guardrails to be free of smartphones and feel a lot happier about it.

Of course, this only applies to my smartphone. We will talk about my laptop another time…

25 Mar 2026 11:44am GMT

We recently asked the MariaDB community a simple question: Where do you run MariaDB most in production? The responses give a useful snapshot of how MariaDB is deployed today across our community: The big takeaway: MariaDB remains strongly infrastructure-aware The clearest signal from this poll is that MariaDB is still most commonly run in environments […]

25 Mar 2026 11:44am GMT

I am starting a new series on what makes MariaDB Server distinct from MySQL, highlighting innovations that make the difference. MariaDB 12.3 introduces a new binary log implementation that stores binlog events directly in InnoDB-managed tablespaces rather than in separate flat files on disk. This is an incredible innovation; for a long time, binary logs […]

25 Mar 2026 11:44am GMT

As a former MySQL DBA, I am less familiar with some MariaDB details. Also, the evolution of MariaDB Server is ongoing, with many new features, data types, and syntax, and more… I decided then to create a new blog series for those like me who need to reinforce their MariaDB knowledge and be unbeatable during […]

25 Mar 2026 11:44am GMT

We are pleased to announce the availability of a preview of the MariaDB 13.0 series. MariaDB 13.0 is a preview rolling release, published on 23 March 2026, and it continues the work started in 12.3 while adding a solid set of entirely new features. And this one is interesting. This preview release brings a nice […]

25 Mar 2026 11:44am GMT

When dealing with queries in MariaDB, there are several approaches, such as the general query log, the slow query log, and the performance_schema. The general query log is not recommended as it doesn't contain much valuable information and can use a lot of resources when writing to the file on busy systems. The slow query […]

25 Mar 2026 11:44am GMT

You may have noticed that MySQL Workbench has not been actively developed for a long time… You can see the number of open bugs. And the number of commits illustrates this too: In fact, Workbench has been put out of maintenance mode to add the MySQL HeatWave Migration Assistant to OCI. Not less, no more. […]

25 Mar 2026 11:44am GMT

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

25 Mar 2026 11:44am GMT

Yesterday I wrote about how Open Source infrastructure across many ecosystems is fragile and underfunded.

Drupal is no exception.

Like most Open Source projects, Drupal runs on infrastructure that millions of people depend on but very few people directly pay for.

Drupal's infrastructure costs roughly $3 million per year, including servers, bandwidth, CDNs, software, and staff.

Funding comes from a mix of donated infrastructure from AWS and the OSU Open Source Lab, corporate memberships through our Drupal Certified Partner program, in‑kind contribution from Tag1, revenue from DrupalCon, donations, and sponsorship on Drupal.org.

Last year, Drupal Association board member Tiffany Farriss and CTO Tim Lehnen analyzed the project's infrastructure costs. Their estimate: infrastructure for Drupal 8+ sites costs about $10 per active website per year.

But the Drupal Association has only about $7.50 per site per year to work with. About $3 comes from DrupalCon and the Certified Partner program. The remaining $4.50 comes from in-kind support: donated hosting, Tag1's infrastructure partnership, volunteer contributions and more.

The missing $2.50 per site shows up as technical debt: certain upgrades get deferred, legacy systems persist longer than they should, and the community sometimes wonders why infrastructure progress feels slow.

Plus, the $7.50 per site we currently fund is fragile. DrupalCon revenue depends on event attendance. Advertising depends on traffic. Tag1's in-kind contribution depends on one company's continued generosity. Our donated infrastructure from AWS and OSU could disappear at any time. If any of that support disappears, the funding gap grows, more infrastructure work gets deferred, and things could start breaking.

Before talking about new funding models, it is worth asking whether the Drupal Association could reduce its infrastructure costs. Ten dollars per site per year may sound like a lot. Should we operate all of this infrastructure ourselves, or rely more on hosted platforms like GitHub or GitLab.com? Are parts of our infrastructure more complex than they need to be? Could we customize less to reduce costs and move faster?

These are the right questions to ask. I believe we need to work both sides of the ledger: take a hard look at what we spend and build a funding model that depends less on goodwill. In practice, infrastructure decisions rarely optimize for everything at once. They involve tradeoffs between cost, speed, flexibility, and control.

Corporate patronage is worth considering. A single well-resourced sponsor could fund Drupal's infrastructure in a way community fundraising cannot, and if the choice were between a patron and a crisis, a patron wins. It's fast, requires no technical changes, and doesn't touch the social contract with site owners.

But patronage trades one fragility for another. Instead of depending on event attendance or AWS cloud credits, you depend on one company's continued generosity and strategic alignment with the project. If their priorities shift, we're back where we started.

A patron funding infrastructure at this scale would also expect meaningful benefits. That could mean greater visibility, access to lead flow, and some level of control over Drupal.org.

Most infrastructure systems connect usage to funding. Cloud platforms charge for compute. Roads are funded by taxes paid by the people who drive them. Drupal's infrastructure has no such mechanism: hundreds of thousands of sites depend on Drupal.org services, but the cost of operating those services is disconnected from the people who rely on them.

A funding model tied to usage avoids some of the issues with corporate patronage, but comes with its own trade-off. Open Source culture is built on anonymous access. You can download any package, no questions asked, no account required. Any usage-based model has to break that norm.

The simplest version would probably require a Drupal.org API key to download packages or receive automatic update notifications. Requiring an API key is standard practice for any commercial API, but in Open Source it feels different. Requiring site owners to identify themselves to Drupal.org is a cultural shift, even if the key itself is free forever.

Any such mechanism requires changes to Drupal Core, which could take years to reach the installed base. If we go down this route, we can't wait for a funding crisis to begin this work. By the time a real crisis arrives, we could still be years away from a solution.

I don't have a specific mechanism to propose yet. My goal here is to lay out the problem, explore potential solutions, and start the conversation. But we should start that conversation now, while we have the time and stability to get it right. Otherwise we may end up having this conversation later, under more pressure and with fewer options.

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

25 Mar 2026 11:44am GMT

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.

	Donated infrastructure	Multi-company sponsorship	Community funding	Single-company patronage
PyPI	☑	☐	☐	☐
Packagist	☐	☐	☐	☑
npm	☐	☐	☐	☑
WordPress	☐	☐	☐	☑
RubyGems	☐	☑	☑	☐
Drupal	☑	☑	☑	☐

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.

I look at Drupal as a concrete example of this in a follow-up post: what it costs to run Drupal's infrastructure.

In practice, this could mean the backend infrastructure around Open Source projects operating more like a SaaS service: the software remains open, but the infrastructure that powers updates and security becomes a paid service for large organizations.

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 organizers didn't step back because federation was the wrong idea. They stepped back because no host would commit funding.

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.

25 Mar 2026 11:44am GMT

Years ago, in the early Drupal days, you would see a mantra everywhere: "Don't hack core".

It showed up in issue queues, conference talks, support channels, stickers, and even on T-shirts. It was short and memorable, and it solved a real problem: too many people were modifying Drupal Core instead of extending it properly.

Over time the mantra worked. The ecosystem matured. Not just the software itself, but also the habits and expectations around it. Today you rarely hear people say "Don't hack core".

With AI changing how code gets written, we may need a new mantra.

In Open Source, all code needs to be understood and reviewed before it can be merged. That responsibility belongs to both contributors and maintainers. AI is changing how code gets written, but it does not change that responsibility. In fact, it may make it easier to forget.

Code you don't understand becomes someone else's problem. In Open Source, that someone is often the maintainer reviewing your patch.

Offloading bad code onto maintainers wastes people's time, which is inconsiderate, and slows down reviews for everyone. You also miss the chance to learn from the code and grow as a developer.

It shouldn't matter what tools you use. But if you submit code, you should be able to explain what it does, why it works, and how it interacts with the rest of the code.

Everyone starts somewhere. Even today's top contributors submitted imperfect patches early on. You are welcome here, with or without AI tools. Perfection isn't required, but understanding your code is. Own your code and respect people's time.

Maybe it's time for some new stickers and T-shirts.

Never submit code you don't understand.

Thanks to Natalie Cainaru, Jeremy Andrews and Gábor Hojtsy for reviewing my draft.

25 Mar 2026 11:44am GMT

I finally crossed 1800 on Chess.com. It took 17 months to gain 100 points. It felt endless.

A few times, I was one game away from reaching 1800. Each time, I collapsed into a losing streak and dropped back to the low 1700s. Few things I do for fun frustrate me as much as chess.

Growth never happens in a straight line. Improvement often looks like regression. Even when I'm going backward, I'm still improving. That lesson carries into work and life.

When working out on the Peloton, I often watch 2000-rated players on YouTube. They're only 200 Elo points higher, but the gap feels massive. Skill doesn't scale linearly.

My game has certainly improved. I see weaknesses faster now, which helps me form better middle game plans. For better or worse, I still rely on a few familiar openings, but they usually get me to a playable position.

Still, 17 months for 100 points feels slow. Should I aim for 2000? Part of me wants the challenge. Another part questions the tradeoff, or whether I'll get there at all. I've not decided yet. For now, I am proud of reaching 1800.

25 Mar 2026 11:44am GMT