fidzu : software

Last week at Drupal South, Pamela Barone delivered a keynote on Drupal CMS. Her talk is one of the clearest articulations I've seen of what Drupal CMS is, why it exists, and where it's headed. That shouldn't come as a surprise because Pam is the Product Lead for Drupal CMS.

Pam quoted a familiar Drupal saying: Drupal makes hard things possible, but it also makes easy things hard.. The room laughed because it's true.

Her keynote was about how Drupal CMS is helping to fix that. Drupal CMS is making Drupal easier to learn, easier to use, and easier to sell, without removing any of Drupal's power and flexibility. It brings visual page editing, a smoother path for new developers, and better project economics.

And these improvements are not just interesting for smaller projects. Universities, governments, and large enterprises want the same benefits. That is why Drupal CMS matters at every scale.

Pam also explains how Drupal CMS sits on top of Drupal Core, why it is not a Drupal distribution, how it gives digital agencies leverage, what site templates unlock, and how Drupal Canvas reshapes the page building experience.

If you watch one Drupal video this week, make it Pam's!

20 May 2026 10:52pm GMT

I saw two thoughtful posts in my LinkedIn feed over the last week that I wanted to reshare here before the LinkedIn feed buried them. Both were spot on, honest, and deserve a longer shelf life.

The first was from Hynek Naceradsky:

I'm pissed.

Not at Drupal. At the people confidently hating on it without ever having understood what it actually does.

"Drupal is outdated." "Drupal is too complex." "Nobody uses Drupal anymore."

Tell that to the EU institutions, governments, universities, and enterprises quietly running mission-critical platforms on it.

Here is what actually gets me though: the Drupal community lets this narrative win.

I am guilty of this too.

We literally have thousands of contributed modules, maintained for free, by people who owe you absolutely nothing. The security team responds faster than most paid vendors. The community has been showing up for 20+ years.

And yet we're somehow losing the PR war to frameworks that can't handle a proper content workflow without three paid plugins and a prayer.

Drupal people: talk louder. Write the posts. Go to the meetups. Tell the stories, fight for Drupal.

Because the Drupal community is honestly the best thing in Open Source, and both it and Drupal deserve way better than silence.

The second was from Thomas Scola, writing from a Drupal AI event in New York (lightly trimmed):

I overheard a couple people say, "Drupal? Is that still around?"

Hell yes it is.

And not only is it still around, I'd argue pretty heavily that Drupal is uniquely positioned for what comes next with the agentic web.

API-first before API-first was cool and trendy. Structured content that actually makes sense. Mature permissions, workflows, governance, integrations.

A lot of platforms are now scrambling to figure out how AI fits into what they already built.

Drupal doesn't have to force it. The architecture has been there.

But honestly, the tech is only part of it. The community is what always gets me. The people, passion and innovation. [...]

What comes next? Who knows.

But if I'm betting on a community to adapt, build, and help define that future, I'm putting my money on this one, and on what we've all built together.

For a platform people love to ask if it's "still around", it feels more relevant than ever.

I could not agree more with both posts. Drupal is one of the strongest Open Source platforms out there right now, but too few people realize it. The Drupal community has been modernizing the platform faster than its reputation evolves.

If the loudest narrative about Drupal is that it is outdated, people will keep repeating it, even when it is wrong. AI systems will too, because they absorb the same narratives, blog posts, forum threads, and social media the rest of the industry does.

The danger is not just that Drupal is misunderstood today. It's that the gap between perception and reality may be growing, not shrinking.

The narratives we reinforce today become part of how AI describes Drupal tomorrow. The Drupal community's silence today becomes tomorrow's AI consensus.

So if you're in the Drupal community, take Hynek's advice and help set the record straight. Not for AI, but for people. Write about the great work happening in Drupal: share the case studies, the technical breakthroughs, the AI innovation, the shared learnings, and the hard problems being solved every day.

We need to spend a lot more time explaining where Drupal fits, the kinds of problems it solves well, and why so many organizations believe in Open Source and the Drupal community.

I know many people in Open Source dislike marketing or self-promotion. I do too, sometimes. But if we don't document what is great about Drupal, others will define Drupal for us.

Every accurate case study, technical blog post, demo, presentation, or community success story helps future developers, evaluators, and AI systems understand what Drupal actually is.

Drupal does not need hype. It needs a better public record.

20 May 2026 10:52pm GMT

Today Acquia announced something I'm really proud of. We're calling it the Acquia Fair Trade Initiative.

When an Acquia partner closes a deal, 2% of that deal flows directly to the Drupal Association, credited in the partner's name, to fund Drupal's infrastructure and long-term growth. This is in addition to the millions of dollars Acquia already invests in Drupal each year.

Imagine an Acquia partner closes a $100,000 Drupal deal with Acquia. $2,000 goes to the Drupal Association, attributed to that partner. The 2% comes from Acquia, not from partner margins, so the partner keeps their full revenue and incentives.

The donation is publicly attributed in the Acquia Partner Portal and counts toward the partner's standing in the Drupal Association's Certified Partner Program. It is recognized as financial support for the Drupal Association, separate from non-financial contributions like code, case studies, or community participation.

Most of all, I like that this program is structural. It is not a one-time gift or sponsorship campaign. It is built into the economics of Acquia's partner program, so Drupal's funding grows automatically as Acquia and its partners grow.

Too often, funding for Open Source projects depends on periodic fundraising or individual goodwill. That can work, but it rarely scales in a predictable way.

Open Source sustainability works best when incentives align. With the Fair Trade Initiative, the Drupal Association receives more predictable funding, partners receive recognition through the Drupal Association's Certified Partner Program, and Acquia invests in the long-term health of the Drupal ecosystem its business depends on. And yes, this also creates more incentive for partners to work with Acquia on Drupal projects. Drupal wins, Acquia's partners win, and Acquia wins too. That is what incentive alignment looks like.

I set a reminder for myself to report back in a year, maybe sooner. I'm curious to see what this model can become.

20 May 2026 10:52pm GMT

I was getting "<XF86AudioPlay> is undefined" in the status bar of Emacs displayed every 2-3 seconds. Nowhere else I noticed any misbehavior or problems, and also couldn't find any related log entries. It didn't stop, though didn't want to reboot my system to see whether that would fix the problem, but it was driving me nuts.

Now, as a starting point I adjusted my sway configuration, to react to the XF86AudioPlay key press event:

bindsym XF86AudioPlay exec playerctl play-pause

After reloading sway, my music player started to play for 2-3 seconds, stopped playing, started again, etc. It wasn't a Emacs bug, but something indeed seemed to send the XF86AudioPlay key event every 2-3 seconds. It wasn't my USB keyboard or any stuck key on it, as verified also by unplugging it. So which device was causing this?

libinput from libinput-tools to the rescue:

% sudo libinput debug-events
[...]
-event12  KEYBOARD_KEY                 +0.000s  KEY_PLAYPAUSE (164) pressed
 event12  KEYBOARD_KEY                 +0.000s  KEY_PLAYPAUSE (164) released
 event12  KEYBOARD_KEY                 +2.887s  KEY_PLAYPAUSE (164) pressed
 event12  KEYBOARD_KEY                 +2.887s  KEY_PLAYPAUSE (164) released
 event12  KEYBOARD_KEY                 +5.773s  KEY_PLAYPAUSE (164) pressed
 event12  KEYBOARD_KEY                 +5.774s  KEY_PLAYPAUSE (164) released
[...]

The `event12` device was sending this event, what's behind this?

% sudo udevadm info /dev/input/event12
P: /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17/event12
M: event12
R: 12
J: c13:76
U: input
D: c 13:76
N: input/event12
L: 0
S: input/by-path/pci-0000:00:1f.3-platform-skl_hda_dsp_generic-event
E: DEVPATH=/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17/event12
E: DEVNAME=/dev/input/event12
E: MAJOR=13
E: MINOR=76
E: SUBSYSTEM=input
E: USEC_INITIALIZED=12468722
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_SWITCH=1
E: ID_PATH=pci-0000:00:1f.3-platform-skl_hda_dsp_generic
E: ID_PATH_TAG=pci-0000_00_1f_3-platform-skl_hda_dsp_generic
E: XKBMODEL=pc105
E: XKBLAYOUT=us
E: XKBOPTIONS=lv3:ralt_switch,compose:rctrl
E: BACKSPACE=guess
E: LIBINPUT_DEVICE_GROUP=0/0/0:ALSA
E: DEVLINKS=/dev/input/by-path/pci-0000:00:1f.3-platform-skl_hda_dsp_generic-event
E: TAGS=:power-switch:
E: CURRENT_TAGS=:power-switch:

% sudo udevadm info -a /dev/input/event12 | grep -iE 'kernels|drivers|name'
    KERNELS=="input17"
    DRIVERS==""
    ATTRS{name}=="sof-hda-dsp Headphone"
    KERNELS=="card0"
    DRIVERS==""
    KERNELS=="skl_hda_dsp_generic"
    DRIVERS=="skl_hda_dsp_generic"
    KERNELS=="0000:00:1f.3"
    DRIVERS=="sof-audio-pci-intel-tgl"
    KERNELS=="pci0000:00"
    DRIVERS==""

Behind this event12 is sof-hda-dsp Headphone, and evtest confirms that:

% sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      AT Translated Set 2 keyboard
/dev/input/event1:      Sleep Button
/dev/input/event10:     ThinkPad Extra Buttons
/dev/input/event11:     sof-hda-dsp Mic
/dev/input/event12:     sof-hda-dsp Headphone
/dev/input/event13:     sof-hda-dsp HDMI/DP,pcm=3
/dev/input/event14:     sof-hda-dsp HDMI/DP,pcm=4
/dev/input/event15:     sof-hda-dsp HDMI/DP,pcm=5
/dev/input/event16:     Yubico YubiKey OTP+FIDO+CCID
/dev/input/event17:     Apple Inc. Magic Keyboard with Numeric Keypad
/dev/input/event18:     Apple Inc. Magic Keyboard with Numeric Keypad
[...]
Select the device event number [0-24]: ^C

We can even get further information:

% sudo evtest /dev/input/event12
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "sof-hda-dsp Headphone"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 582 (KEY_VOICECOMMAND)
  Event type 5 (EV_SW)
    Event code 2 (SW_HEADPHONE_INSERT) state 0
Properties:
Testing ... (interrupt to exit)
Event: time 1779295060.175766, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
Event: time 1779295060.175766, -------------- SYN_REPORT ------------
Event: time 1779295061.951168, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295061.951168, -------------- SYN_REPORT ------------
Event: time 1779295061.951194, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295061.951194, -------------- SYN_REPORT ------------
Event: time 1779295064.548671, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295064.548671, -------------- SYN_REPORT ------------
Event: time 1779295064.548689, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295064.548689, -------------- SYN_REPORT ------------
Event: time 1779295067.437172, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295067.437172, -------------- SYN_REPORT ------------
Event: time 1779295067.437187, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295067.437187, -------------- SYN_REPORT ------------
Event: time 1779295070.323775, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295070.323775, -------------- SYN_REPORT ------------
Event: time 1779295070.323790, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295070.323790, -------------- SYN_REPORT ------------
Event: time 1779295073.200350, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295073.200350, -------------- SYN_REPORT ------------
Event: time 1779295073.200373, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295073.200373, -------------- SYN_REPORT ------------
Event: time 1779295076.076228, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295076.076228, -------------- SYN_REPORT ------------
Event: time 1779295076.076250, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295076.076250, -------------- SYN_REPORT ------------
Event: time 1779295078.961740, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295078.961740, -------------- SYN_REPORT ------------
Event: time 1779295078.961754, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295078.961754, -------------- SYN_REPORT ------------
Event: time 1779295081.850156, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295081.850156, -------------- SYN_REPORT ------------
Event: time 1779295081.850175, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295081.850175, -------------- SYN_REPORT ------------
Event: time 1779295083.306612, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 0
Event: time 1779295083.306612, -------------- SYN_REPORT ------------

So when I plug in my headphone (see the `SW_HEADPHONE_INSERT` event), the unexpected behavior starts, unplugging stops the problem.
Good! But what was totally unexpected for me: my headphone, being a Beyerdynamic DT-990 Pro, does not have any keys. 8-)

As it turned out, the headphone jack seemed to have been not entirely clean. The analog side of the jack triggers a behavior within the audio codec, where it seems to interpret the fluctuating impedance as a play button of the headset, being pressed, again and again.

I cleaned the jack of my headphone and my XF86AudioPlay problem is gone, case closed.

20 May 2026 5:19pm GMT

Following the series of various Linux exploits of the last three weeks, the bug of today is pintheft [no CVE yet] which is local root privilege escalations.

The vulnerability can be mitigated by unloading and blocking rds modules, linux-vulnerability-mitigation as of 20260519-1 (uploaded to sid, trixie-fastforward-backports and people.debian.org/~daniel) does that automatically for you.

Updates:

• default Debian kernels (bullseye, bookworm, trixie, and testing/unstable, experimental) are not directly affected because autoloading of the rds modules is disabled by rds-Disable-auto-loading-as-mitigation-against-local.patch.

20 May 2026 2:27pm GMT

Royals are my favourite ships in No Man's Sky. The HMS Blueberry is not my first Exotic/Royal ship (that was the Gravity Hirakao XVI, and a story for another time).

After years of on-off playing, I recently found my first Royal multitool: Blue, with gold detailing. I have a Royal-style jetpack (I don't remember where I got that). I thought I'd try and colour-match my multitool, ship, jetpack and outfit. Since I only had one multitool, I matched the others to it. And the HMS Blueberry (credit for the name goes to Beatrice) was the Exotic in my collection which matched.

The HMS Blueberry is in viewable in my showroom, Honest Jon's Lightly-Used Starships.

19 May 2026 8:15am GMT

The first thing to look at is the Fibonacci benchmark. The source code is here:

(in-package "CLRHACK")

(progn
  (defun fib (n)
    (if (

And it compiles to this IL code: (commentary after the code)

.assembly extern mscorlib {}
.assembly extern LispBase {}

.assembly 'FibBenchmark' {}
.module 'FibBenchmark.exe'

.class public auto ansi beforefieldinit Program
       extends [mscorlib]System.Object
{
    .field public static class [LispBase]Lisp.Symbol 'SYM_G545'

.method public static hidebysig specialname rtspecialname void '.cctor'() cil managed
{
    .maxstack 8
    ldsfld class [LispBase]Lisp.Package [LispBase]Lisp.Package::CommonLisp
    ldstr "T"
    callvirt instance class [LispBase]Lisp.Symbol [LispBase]Lisp.Package::'Intern'(string)
    stsfld class [LispBase]Lisp.Symbol Program::'SYM_G545'
    ret
}

.method public static hidebysig object 'FIB'(object) cil managed
{
    .maxstack 8
    .locals (object TEMP_B)
    ldarg 0
    ldc.i4 2
    box int32
    stloc TEMP_B
    unbox.any int32
    ldloc TEMP_B
    unbox.any int32
    clt
    brtrue TRUE543
    ldnull
    br END544
TRUE543:
    nop
    ldsfld class [LispBase]Lisp.Symbol Program::'SYM_G545'
END544:
    nop
    ldnull
    ceq
    brtrue ELSE546
    ldarg 0
    ret
ELSE546:
    nop
    ldarg 0
    ldc.i4 1
    box int32
    stloc TEMP_B
    unbox.any int32
    ldloc TEMP_B
    unbox.any int32
    sub
    box int32
    call object Program::'FIB'(object)
    ldarg 0
    ldc.i4 2
    box int32
    stloc TEMP_B
    unbox.any int32
    ldloc TEMP_B
    unbox.any int32
    sub
    box int32
    call object Program::'FIB'(object)
    stloc TEMP_B
    unbox.any int32
    ldloc TEMP_B
    unbox.any int32
    add
    box int32
    ret
BLOCK_END_FIB_532:
    nop
    ret
}

.method public static hidebysig object 'MAIN'() cil managed
{
    .maxstack 8
    ldstr "Fibonacci of 10:"
    call void [mscorlib]System.Console::'WriteLine'(object)
    ldnull
    pop
    ldc.i4 10
    box int32
    call object Program::'FIB'(object)
    call void [mscorlib]System.Console::'WriteLine'(object)
    ldnull
    ret
BLOCK_END_MAIN_536:
    nop
    ret
}

.method public static hidebysig void 'Main'() cil managed
{
    .entrypoint
    .maxstack 8
    call object Program::'MAIN'()
    pop
    ret
}

} // end of class Program

The first thing the fib program does is compare
  argument x to the literal number 2.  The
  compiler pushes argument 0 on to the stack, and then the compiler
  pushes a integer 2 on to the stack and boxes it.


Next, the compiler has to perform the compare.  In order to do this
  it must unbox both arguments.  One argument is on top of the stack,
  so it is put into a local TEMP_B so we can get to the other
  argument.  We unbox it.  We then restore TEMP_B to the top of stack
  and unbox it.  Finally we compare the two unboxed values for less
  than.


This pattern of unboxing a pair of elements from the top of stack
  by way of a temporary local is repeated several places in the
  compiled code as FIB rather inefficiently subtracts 1 or 2 from the
  argument and makes the recursive call.


This example shows that the compiler basically treats everything as
  a .NET object.  It unboxes numbers at the last moment and boxes the
  results as soon as they are generated.  It is not efficient
  code.

18 May 2026 6:39pm GMT

I was bored so I wrote a compiler. I'm lazy so I vibe coded it. It compiles Lisp to .NET IL (the byte code that the .NET runtime executes). The IL is then JIT compiled to machine code and executed. You can use the dotnet runtime from Microsoft or the open source mono runtime as the runtime for the compiled code.

The basic idea of the compiler is to map lambda expressions to .NET classes. The lexical variables are stored as fields in the class. The body of the lambda is compiled to a method in the class. We use lambda lifting to flatten any nested lambdas. We use cell conversion to handle mutable variables and we simply copy the values of immutable variables into the lifted lambdas when they are closed over.

Although I `vibe coded` the compiler, I leveraged my experience with writing compilers to break down the problem into passes that were simple enough that `vibe coding` was possible. For instance, in order to implement lambda lifting, I first wrote a pass that determined the free variables of each lambda. That's a pretty simple operation that I could easily `vibe code`. In order to emit the correct IL, I first wrote a pass that segregated the variables into arguments, lexicals, and globals. Again, that's a simple operation that I could easily `vibe code`.

The trickiest part was the code generator. I had decided to implement tail recursion by using the `tail.` prefix in the IL. This is a hint to the JIT compiler that the call is a tail call and that it can optimize it by reusing the current stack frame. However, the JIT compiler is a bit picky about when it will actually perform the tail calls, and the other parts of the code generator kept moving the tail calls around so that they were no longer in tail position. I eventually had to add a pre-pass to the code generator that tracked the continuations in order to ensure that there was enough information later on to enforce tail position on the tail calls.

It... works? It compiles a number of the Gabriel Benchmarks, and some test programs that demonstrate lexical scoping, mutable variables, and tail recursion. It is most definitely a Lisp compiler, but if you look under the hood, well, be forewarned. It isn't pretty.

The compiler itself was vibe coded. The only restriction on the output code was that it had to implement what the input code specified. It did not have to conform to any particular notion of how to implement lisp features on the .NET runtime beyond the requirement that the output was correct. Choices that are typically made by a Lisp architect, such as how to deal with integers, the implementation of the standard library, etc., were all left up to the vibe coding process. I provided a couple of runtime libraries: a cell library for implementing mutable variables, and a List library for implementing singly linked lists. These were written in C#. The vibe coding process was allowed to modify the C# code in these libraries as well and it did so in a couple of places.

I started with one a simple benchmark and got it to compile and run. From there, I added more benchmarks and each time told the compiler to fix any errors that came up. I also added some test programs that were not part of the benchmarks in order to test specific features of the compiler. As I added more and more test programs, the `vibe coding process` added more and more features to the compiler. This ended up producing more and more complex compiler output code.

I'm going to devote a few blog posts to this compiler, so if it isn't up your alley, skip ahead a few posts.

17 May 2026 1:07pm GMT

We are announcing a bugfix ECL release that addresses a few issues that has slipped through testing of the recent one.

Addressed issues:

• bugfix: MAKE-PACKAGE destructively modified defining form's cons cells of the package local nicknames, breaking package literals in bytecmp (#839)

• bugfix: the first environment is now always page-aligned by using the same allocation mechanism as all subsequent envs (#828)

• bugfix: allow loading concatenated fasc files (#842)

• bugfix: defclass does not redefine existing classes at compile time with forward-referenced classes in the bytecodes compiler (#843)

This release is available for download in a form of a source code archive (we do not ship prebuilt binaries):

• ECL 26.5.5 tarball archive
• The ECL Manual

Happy Hacking,
The ECL Developers

05 May 2026 12:00pm 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舰

25 Apr 2026 10:00pm GMT

Are you ready for another challenge? We're excited to host the second yearly edition of our treasure hunt at FOSDEM! Participants must solve five sequential challenges to uncover the final answer. Update: the treasure hunt has been successfully solved by multiple participants, and the main prizes have now been claimed. But the fun doesn't stop here. If you still manage to find the correct final answer and go to Infodesk K, you will receive a small consolation prize as a reward for your effort. If you're still looking for a challenge, the 2025 treasure hunt is still unsolved, so舰

29 Jan 2026 11:00pm GMT

With FOSDEM just a few days away, it is time for us to enlist your help. Every year, an enthusiastic band of volunteers make FOSDEM happen and make it a fun and safe place for all our attendees. We could not do this without you. This year we again need as many hands as possible, especially for heralding during the conference, during the buildup (starting Friday at noon) and teardown (Sunday evening). No need to worry about missing lunch at the weekend, food will be provided. Would you like to be part of the team that makes FOSDEM tick?舰

26 Jan 2026 11:00pm GMT