Made some time to do some work for a few Ansible roles that I maintain. You'll find the new releases below.

stafwag.proxy_env 2.1.0

An Ansible role to set up the proxy environment in the shell environment ( /etc/profile & /etc/csh_cshrc ) and the package manager. The following package managers are supported:

• apt
• pacman
• pkgng
• Suse (on Suse /etc/sysconfig/proxy is configured)
• yum

stafwag.proxy_env 2.1.0 is available at:

• https://github.com/stafwag/ansible-role-proxy_env
• https://galaxy.ansible.com/ui/standalone/roles/stafwag/proxy_env/

Changelog

stafwag.proxy_env 2.1.0

• Create pkg.conf on FreeBSD if not exists

• Create pkg.conf on FreeBSD if not exists
• Corrected ansible-lint errors
• Clean up

---

stafwag.ssh 1.1.1

An ansible role to manage sshd/ssh

stafwag.ssh 1.1.1 is available at:

• https://github.com/stafwag/ansible-role-ssh
• https://galaxy.ansible.com/ui/standalone/roles/stafwag/ssh/

Changelog

stafwag.ssh 1.1.1

• Corrected handler name
  • BUGFIX: Corrected handler name

stafwag.ssh 1.1.0

• Corrected last ansible-lint errors
  • Corrected last ansible-lint errors
  • Example playbooks added
  • Documentation updated

---

stafwag.libvirt 2.1.0

An ansible role to install libvirt/KVM packages and enable the libvirtd service.

stafwag.libvirt 2.1.0 is available at:

• https://github.com/stafwag/ansible-role-libvirt
• https://galaxy.ansible.com/ui/standalone/roles/stafwag/libvirt/

Changelog

stafwag.libvirt 2.1.0

• Update ArchLinux packages
  • update_ssh_known_hosts directive added to allow to update the ssh host key after the virtual machine is installed.
  • Documentation updated

  • Debug code added

stafwag.etc_hosts 1.1.1

An ansible role to manage /etc/hosts

stafwag.etc_hosts 1.1.1 is available at:

• https://github.com/stafwag/ansible-role-etc_hosts
• https://galaxy.ansible.com/ui/standalone/roles/stafwag/etc_hosts/

Changelog

stafwag.etc_hosts 1.1.1

• CleanUp
  • Ansible-lint errors corrected
  • Documenation updated

Have fun!

09 May 2026 6:54pm GMT

Our babysitter recently played a fun game with our kids called "Fake It". It's a simple party game, not too complex, and doesn't require any props. The app store is full of them, but they all hide ads or have a €9.99/week (week!) subscription model, all trying to trick you into buying or paying. But it's such a simple game. Surely, I can just make my own version, right?

09 May 2026 6:54pm GMT

We have 4 streaming services at home: Netflix, Disney+, Prime Video, and Apple TV+. Try finding which films and series are actually available with Dutch audio.

09 May 2026 6:54pm GMT

As you know, MySQL-Sandbox and then dbdeployer have always been part of the Swiss Army knife for DBAs trying to evaluate, test, or reproduce issues with a certain version of their database. The author, Giuseppe Maxia, aka the datacharmer, produced incredible work on these two projects. Unfortunately, Giuseppe decided to archive the project in 2023. […]

09 May 2026 6:54pm GMT

MariaDB Server supports different authentication methods just like MySQL. Depending on your installation, the number of available and active authentication plugins can vary. But you should always have those 3 by default: If we compare with MySQL 9.7, we can see only 2 default authentication plugins: About caching_sha2_password module In some packaging, the caching_sha2_password auhentication […]

09 May 2026 6:54pm GMT

We are concluding our series related to new data types using the Type_handler framework, with some limitations that are not yet covered by the framework: It would have been handy for our MONEY datatype to have the possibility to define, for example, the currency to show. Or the format to have something like this: Unfortunately, […]

09 May 2026 6:54pm GMT

This is part 4 of a series related to extending MariaDB with a custom data type using the Type_handler framework. You can find the previous articles below: Overriding Existing Types In the previous examples, our MONEY data type inherits from DOUBLE and then we override some methods. But all the methods of every type cannot […]

09 May 2026 6:54pm GMT

In the previous article, we wrote, compiled, and tested our first custom data type for MariaDB using the Type_handler framework. But currently, aside from allowing the use of its new name (MONEY) and listing it in the metadata, our new data type behaves exactly like a DOUBLE, the class it inherits from. In this article, […]

09 May 2026 6:54pm GMT

After having discovered the Type_hander framework and learned how to build MariaDB Server from source, it's time to code our first data type! We will create a MariaDB plugin that registers a new MONEY type and instantiates a custom field object. Our component won't be exciting, but we want to understand how to use the […]

09 May 2026 6:54pm GMT

This is the first part of the series about how to add a new data type to MariaDB using the Type_handler framework. A preliminary article has already been published to start the series; it covers how to set up your development environment and compile MariaDB Server: Adding a New Data Type to MariaDB with Type_handler […]

09 May 2026 6:54pm GMT

Welcome to this new series about extending MariaDB. This series covers the addition of a new data type using the Type_handler. The goal of the entire series is to create a new plugin data type MONEY to store and display amounts with currency. Something like: Of course, the ultimate goal is to teach how to […]

09 May 2026 6:54pm GMT

Deze ochtend het parcours van het WK Gravel 2025 gereden. Best stoffig!

Source

09 May 2026 6:54pm GMT

"Mijn Lieve Gunsteling" en "Vuur" zijn allebei boeken over misbruik van jonge tieners door volwassenen. "Gunsteling" van Lucas Rijneveld (ook gekend van "De avond is ongemak") is prachtig geschreven, maar het graaft door de ogen van de pleger héél diep in de getormenteerde psyche van zowel slachtoffer als pleger. Het bleek daardoor voor mij bijna ondragelijk emotioneel intens en ik heb de 363…

Source

09 May 2026 6:54pm GMT

All video recordings from FOSDEM 2026 that are worth publishing have been processed and released. Videos are linked from the individual schedule pages for the talks and the full schedule page. They are also available, organised by room, at video.fosdem.org/2026. While all released videos have been reviewed by a human, it remains possible that one or more issues fell through the cracks. If you notice any problem with a video you care about, please let us know as soon as possible so we can look into it before the video-processing infrastructure is shut down for this edition. To report any舰

09 May 2026 6:54pm GMT

Keeping up with major Drupal Core releases takes real effort. Each release deprecates APIs and introduces new coding patterns, forcing module developers to update their code.

That is how most software evolves: old patterns are gradually replaced by better ones.

Tools like Drupal Rector help automate parts of that work, but still rely on hand-written rules. Historically, that hasn't scaled well. Writing Rector rules is often more tedious than difficult: reading change records, understanding edge cases, finding real-world usage patterns, and testing rules.

So I asked a different question: what if we didn't have to write Rector rules at all?

If AI can generate Rector rules automatically, Drupal Core can keep evolving without every API change turning into manual migration work.

That idea led me to extend Drupal Digests, the tool I built to follow key Drupal developments. In addition to generating summaries, it now also analyzes Drupal Core commits and generates Rector rules automatically.

When a Drupal Core commit deprecates an API or introduces a new pattern, the tool reads the related issue, analyzes the discussion around it, reviews the code changes, and generates a corresponding Rector rule.

The system has only been running for a few weeks, yet it has already generated over 175 Rector rules, with new rules continuously added as the pipeline processes more Drupal Core issues.

AI-generated code is far from perfect. Some rules will have bugs, and others will miss edge cases. But that is exactly why I wanted to publish them now: the more people test them on real projects, the faster they will improve.

Special thanks to Björn Brala, co-maintainer of Drupal Rector, who discovered I was working on this and quickly jumped in to help test and validate some of the generated rules. That kind of feedback is incredibly valuable.

You can try them as follows:

git clone https://github.com/dbuytaert/drupal-digests.git
composer require --dev rector/rector
vendor/bin/rector process web/modules/custom \
  --config drupal-digests/rector/all.php --dry-run

Example

Take Drupal's modernization of the $entity->original property, which exposed the unchanged copy of an entity. Drupal 11.2 deprecated the property in favor of explicit $entity->getOriginal() and $entity->setOriginal() methods. The old property will be removed in Drupal 12 so various module maintainers have to update their code.

Drupal Digests generated a Rector rule that rewrites read access to getOriginal() and write assignment to setOriginal().

Before:

$entity->original->field->value;
$entity->original = $unchanged;

After:

$entity->getOriginal()->field->value;
$entity->setOriginal($unchanged);

AI-generated upgrade rules will not eliminate all upgrade work anytime soon. But even partial automation can reduce a surprising amount of repetitive work while helping Drupal evolve faster.

09 May 2026 6:54pm GMT

Every framework's API surface sits on a spectrum, from strict (typed interfaces, schemas, service containers) to loose (string keys, naming conventions, untyped hooks). Strict APIs cost more upfront: more boilerplate, more to learn before writing code. Loose APIs shift that cost later: more ambiguity, more reliance on naming conventions, and more bugs that are harder to detect and fix.

AI changes who pays. Boilerplate and learning curves don't slow agents down. What slows them down is missing feedback: code that runs but does the wrong thing, errors that don't point to the cause, conventions that have to be guessed. Magic-name binding, untyped hooks, unvalidated configuration, and conventions the code doesn't enforce produce exactly those failure modes.

Magic strings break the loop

For example, both Drupal and WordPress have long used magic-string hooks. In Drupal, you write a function like mymodule_user_login. WordPress uses a related pattern: a string action name passed to add_action(). In both cases, the binding is a string the language can't validate.

Get the name wrong and the system silently skips your code: no error, no warning, nothing in the logs. The function just sits there, unloved.

The signature is a convention, not a contract: the documentation says the user_login hook receives a $user object, but nothing enforces it. To your IDE or a static analyzer like PHPStan, it's just a function. They don't know it's wired into the platform's login flow, so they can't warn you when it's wrong.

A typed alternative makes the binding explicit. With a PHP attribute like #[Hook('user_login')] on a registered service, the class must exist, the method signature is type-checked, and the container wires the dependencies. IDEs, static analyzers, and AI coding agents can follow the chain from the attribute to the implementation.

For AI agents, this keeps the feedback loop tight instead of turning it into trial and error. That means they can move faster, spend less time debugging, and use fewer tokens.

At DrupalCon Chicago this March, AI coding tools migrated a Lovable-generated site into Drupal in hours. The strict APIs kept the agent on track.

A bet made before AI existed

This didn't start with AI. Drupal 8, which we shipped in 2015, introduced Symfony's routing, services, and event dispatcher, replacing large parts of the procedural hook system. Since then, we've kept reducing magic hooks. The attribute-based approach (#[Hook('user_login')]) landed in Drupal 11.1 and helps remove more of the remaining procedural-only paths.

Hooks aren't the only place Drupal has been getting stricter. Drupal stores a lot of configuration in YAML, which was one of the loosest parts of the system. A multi-year validation effort has been tightening that.

When an agent generates a content type definition or editor configuration, validation catches missing keys, invalid values, and broken references before anything is saved. The agent gets a precise error pointing to the exact field, instead of a runtime failure. That tight feedback loop is what makes Drupal a strong CMS for AI-assisted development.

Drupal made this bet early, and it was painful. The Drupal 7 to Drupal 8 transition broke backward compatibility and took years to recover from. But it left the platform much stricter. More than ten years in, we're still making Drupal stricter.

Meanwhile, WordPress made a different bet, prioritizing backward compatibility over stricter APIs. That kept the platform stable for a long time. It also kept the looseness.

Those trade-offs now determine how efficiently AI agents can work with each platform.

What was style is now speed

What used to be a stylistic choice is now a speed and cost problem. Loose APIs mean more debugging and guesswork. Strict APIs mean faster, more precise feedback. This was always true for humans. It's now also true for AI agents. But today that cost shows up in tokens.

09 May 2026 6:54pm GMT