fidzu : software

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

16 Jan 2026 10:31am GMT

I used Claude Code to build a new feature for my site this morning. Any URL on my blog can now return Markdown instead of HTML.

I added a small hint in the HTML to signal that the Markdown version exists, mostly to see what would happen. My plan was to leave it running for a few weeks and write about it later if anything interesting turned up.

Within an hour, I had hundreds of requests from AI crawlers, including ClaudeBot, GPTBot, OpenAI's SearchBot, and more. So much for waiting a few weeks.

For two decades, we built sites for two audiences: humans and search engines. AI agents are now the third audience, and most websites aren't optimized for them yet.

We learned how to play the SEO game so our sites would rank in Google. Now people are starting to invest in things like Generative Engine Optimization (GEO) and Answer Engine Optimization (AEO).

I wanted to understand what that actually means in practice, so I turned my own site into a small experiment and made every page available as Markdown.

If you've been following my blog, you know that Drupal stores my blog posts as Markdown. But when AI crawlers visited, they got HTML like everyone else. They had to wade through navigation menus and wrapper divs to find the actual content. My content already existed in a more AI-friendly format. I just wasn't serving it to them.

It only took a few changes, and Drupal made that easy.

First, I added content negotiation to my site. When a request includes Accept: text/markdown in the HTTP headers, my site returns the Markdown instead of the rendered HTML.

Second, I made it possible to append .md to any URL. For example, https://dri.es/principles-for-life.md gives you clean Markdown with metadata like title, date, and tags. You can also try adding .md to the URL of this post.

But how did those crawlers find the Markdown version so fast? I borrowed a pattern from RSS: RSS auto-discovery. Many sites include a link tag with rel="alternate" pointing to their RSS feed. I applied the same idea to Markdown: every HTML page now includes a link tag announcing that an alternative Markdown version exists at the .md URL.

That "Markdown auto-discovery" turned out to be the key. The crawlers parse the HTML, find the alternate Markdown link, and immediately switch. That explains the hundreds of requests I saw within the first hour.

The speed of adoption tells me AI agents are hungry for cleaner content formats and will use them the moment they find them. What I don't know yet is whether this actually benefits me. It might lead to more visibility in AI answers, or it might just make it easier for AI companies to use my content without sending traffic back.

I know not everyone will love this experiment. Humans, including me, are teaching machines how to read our sites better, while machines are teaching humans to stop visiting us. The value exchange between creators and AI companies is far from settled, and it's entirely possible that making content easier for AI to consume will accelerate the hollowing out of the web.

I don't have a good answer to that yet, but I'd rather experiment than look away. I'm going to leave this running and report back.

16 Jan 2026 10:31am GMT

Drupal turns 25 today. A quarter of a century.

What started as a hobby became a community, and then, somehow, a pillar of the web's infrastructure.

Looking back, the most important things I learned weren't really about software. They were about people, scale, and what it takes to build something that lasts.

Twenty-five years, twenty-five lessons.

1. You can do well and do good

I used to think I had to choose: build a sustainable business or build something generous. Drupal taught me that is a false choice. Growth and generosity can reinforce each other. The real challenge is making sure one does not crowd out the other.

2. You can architect for community

Community doesn't just happen. You have to design for it. Drupal's modular system created clear places to contribute, our open logo invited people to make their own variants, and our light governance made it easy for people to step into responsibility. You cannot force a community to exist, but you can create the conditions for one to grow.

3. A few decisions define everything

Most choices don't matter much in hindsight, but a few end up shaping a project's entire trajectory. For Drupal, that included licensing under the GPL, the hook system, the node system, starting the Drupal Association, and even the credit system. You never know which decisions those are when you're making them.

4. Coordination is the product

In the early days, coordination was easy: you knew most people by name and you could fix things in a single late night IRC conversation. Then Drupal grew, slowly at first and then all at once. I remember release cycles where the hardest part was not the code but aligning hundreds of people across time zones, cultures and priorities, with far too much energy spent "bike shedding". That is when I learned that at scale, code is not the product. It is what we ship, but coordination is what makes it possible.

5. Everyone's carrying something

I've worked with people navigating challenges I couldn't see at first. Mental health struggles, caregiving burdens, personal crises. It taught me that someone's behavior in a moment rarely tells the whole story. A healthy community makes room for people. Patience and grace are how you keep good people around.

6. Nobody fully understands Drupal anymore, including me

After 25 years and tens of thousands of contributors, Drupal has grown beyond any single person's understanding. I also google Drupal's documentation. I'm strangely proud of that, because it's how I know it has become something bigger than any one of us.

7. Volunteerism alone doesn't scale

In the early years, everything in Drupal was built by volunteers, and for a long time that felt like enough. At some point, it wasn't. The project was growing faster than the time people could give, and some important work needed more hands. Paid contributors brought stability and depth, while volunteers continued to innovate. The best projects make room for both.

8. Your words carry more weight than you realize

As recently as a few weeks ago, I sent a Slack message I thought was harmless and watched it create confusion and frustration. I have been making that same mistake, in different forms, for years. As a project grows, so does the gravity of what you say. A passing comment can redirect weeks of work or demoralize someone who is trying their best. I had to learn to speak more carefully, not because I am important, but because my role is. I am still learning to do this better.

9. Maintenance is leadership with no applause

The bottleneck in Open Source is rarely new ideas or new code. It's people willing to maintain what already exists: reviewing, deciding, onboarding new people, and holding context for years. I have seen projects stall because nobody wanted to do that work, and others survive because a few people quietly stepped up. Maintainers do the work that keeps everything together. If you want a project to last, you have to take care of your maintainers.

10. Culture is forged under stress

The Drupal community was not just built on good vibes. It was built in the weeks before releases and DrupalCons, in late night debugging sessions, and in messy moments of disagreement and drama. I have seen stress bring out the best in us and, sometimes, the worst. Both mattered because they forced us to learn how to disagree, decide, and recover. Those hard moments forged trust you cannot manufacture in calm times, and they are a big reason the community is still here.

11. Leadership has to outgrow its founder

For Drupal to last, leadership had to move beyond me, and for that to happen I had to let go. That meant stepping back from decisions I cared deeply about and trusting others to take the project in directions I might not have chosen. There were moments when I felt sidelined in the project I started, which was nobody's fault, but not easy. Letting go was not always easy, but it is one of the reasons Drupal is still here.

12. Open source is not a meritocracy

I used to say that the only real limitation to contributing was your willingness to learn. I was wrong. Free time is a privilege, not an equal right. Some people have jobs, families, or responsibilities that leave no room for unpaid work. You can only design for equity when you stop pretending that Open Source is a meritocracy.

13. Changing your mind in public builds trust

Over the years, I've had to reverse positions I once argued for. Doing that in public taught me that admitting you were wrong builds more trust than claiming you were right. People remember how you handle being wrong longer than they remember what you were wrong about.

14. Persistence beats being right early

In 2001, Open Source was a curiosity that enterprises avoided. Today, it runs the world. I believed in it long before I could prove it. I kept working on Drupal anyway. It took many years for the world to catch up. That taught me that sticking with something you believe in matters more than being right quickly.

15. The hardest innovation is not breaking things

For years, I insisted that breaking backward compatibility was a core value. Upgrades were painful, but I thought that was the price of progress. The real breakthrough came when we built enough test coverage to keep moving forward without breaking what people had built. Today, Drupal has more than twice as much test code as production code. That discipline was harder than any rewrite, and it earned more trust than any new feature.

16. Most people are here for the right reasons

Every large community has bad actors and trolls, and they can consume all your attention if you let them. If you focus too much on the worst behavior, you start to miss the quiet, steady work of the many people who are here to build something good. Your energy is better spent supporting those people.

17. Talk is silver, contribution is gold

Words matter. They set direction and invite people in. But the people who shaped Drupal most were the ones who kept showing up to do the work. Culture is shaped by what actually gets done, and by who shows up to do it.

18. Vision doesn't have to come from the top

For a long time, I thought being project lead meant having the vision. Over time, I learned that it meant creating the conditions for good ideas to come from anywhere. The best decisions often came from people I'd never met, solving problems I didn't know we had.

19. The spark is individual but the fire is not

A single person can change a project's direction, but no contribution survives on its own. Every new feature comes with a maintenance cost and eventually depends on people the original author will never meet. Successful projects have to hold both truths at once: the spark is individual, but the fire is not.

20. At scale, even your bugs become features

Once enough people depend on your software, every observable behavior becomes a commitment, whether you intended it or not. Sooner or later, someone will build a workflow around an edge case or quirk. That is why maintaining compatibility is not a lesser form of work. It is core to the product.

21. A good project is measured by what people build next

For a long time, it felt like a loss when top contributors moved on from Drupal. Over time, I started to notice what they built next and realized they were carrying what they learned here into everything they did. Many went on to lead teams, start companies, or build new Open Source projects. I have come to see that as one of Drupal's most meaningful outcomes.

22. Longevity comes from not chasing trends

Drupal is still here because we resisted the urge to chase every new trend and kept building on things that last, like structured content, security, extensibility, and openness. Those things mattered twenty years ago, they still matter today, and they will still matter twenty years from now.

23. If it matters, keep saying it

A community isn't a room. People join at different times, pay attention to different things, and hear through different filters. An idea has to land again and again before it takes hold. If it matters, keep saying it. The ideas that stick are the ones the community picks up and carries forward.

24. It takes a community to see the whole road

Sometimes the path forward seems clear. An individual can see a direction, but a community sees the terrain: the cracks, the forks, and the doubts. Being right alone brings clarity. Bringing others along brings confidence.

25. Start before you feel ready

When I released Drupal 1.0.0, I knew almost nothing. For much of the journey, I felt out of my depth. I was often nervous, sometimes intimidated. I didn't know how to scale software, how to build a community, or how to lead. I kept shipping anyway. You don't become ready by waiting. You become ready by doing.

A group photo taken at DrupalCon Seattle in 2019.

For those who have been here for years, these lessons will feel familiar. We learned them together, sometimes slowly, sometimes through debate, and often the hard way.

If Drupal has been part of your daily life for a long time, you are not just a user or a contributor. You are part of its history. And for all of you, I am grateful.

I am still here, still learning, and still excited about what we can build together next. Thank you for building it with me.

16 Jan 2026 10:31am GMT

Via (I think) @mcc on the Fediverse, I learned of GetMusic: a sort-of "clearing house" for Free Bandcamp codes. I think the way it works is, some artists release a limited set of download codes for their albums in order to promote them, and GetMusic help them to keep track of that, and helps listeners to discover them.

GetMusic mail me occasionally, and once they highlighted an album The Arcane & Paranormal Earth which they described as "Post-Industrial in the vein of Coil and Nurse With Wound with shades of Aphex Twin, Autechre and assorted film music."

Well that description hooked me immediately but I missed out on the code. However, I sampled the album on Bandcamp directly a few times as well as a few of his others (Ye Gods is a side-project of Antoni Maiovvi, which itself is a pen-name) and liked them very much. I picked up the full collection of Ye Gods albums in one go for 30% off.

Here's a stand-out track:

On Earth by Ye Gods

So I guess this service works! Although I didn't actually get a free code in this instance, it promoted the artist, introduced me to something I really liked and drove a sale.

16 Jan 2026 10:14am GMT

FSet v2.2.0, which is the version included in the recent Quicklisp release, has a new Quicklisp-loadable system, FSet/Jzon. It extends the Jzon JSON parser/printer to construct FSet collections when reading, and to be able to print them.

On parsing, JSON arrays produce FSet seqs; JSON objects produce FSet replay maps by default, but the parser can also be configured to produce ordinary maps or FSet tuples. For printing, any of these can be handled, as well as the standard Jzon types. The tuple representation provides a way to control the printing of `nil`, depending on the type of the corresponding key.

For details, see the GitLab MR.

NOTE: unfortunately, the v2.1.0 release had some bugs in the new seq code, and I didn't notice them until after v2.2.0 was in Quicklisp. If you're using seqs, I strongly recommend you pick up v2.2.2 or newer from GitLab or GitHub.

16 Jan 2026 8:05am GMT

I wrote ILsee, an Interlisp source file viewer. It is the first of the ILtools collection of tools for viewing and accessing Interlisp data.

I developed ILsee in Common Lisp on Linux with SBCL and the McCLIM implementation of the CLIM GUI toolkit. SLY for Emacs completed my Lisp tooling and, as for infrastructure, ILtools is the first new project I host at Codeberg.

This is ILsee showing the code of an Interlisp file:

Motivation

The concepts and features of CLIM, such as stream-oriented I/O and presentation types, blend well with Lisp and feel natural to me. McCLIM has come a long way since I last used it a couple of decades ago and I have been meaning to play with it again for some time.

I wanted to do a McCLIM project related to Medley Interlisp, as well as try out SLY and Codeberg. A suite of tools for visualising and processing Interlisp data seemed the perfect fit.

The Interlisp file viewer ILsee is the first such tool.

Interlisp source files

Why an Interlisp file viewer instead of less or an editor?

In the managed residential environment of Medley Interlisp you don't edit text files of Lisp code. You edit the code in the running image and the system keeps track of and saves the code to "symbolic files", i.e. databases that contain code and metadata.

Medley maintains symbolic files automatically and you aren't supposed to edit them. These databases have a textual format with control codes that change the text style.

When displaying the code of a symbolic file with, say, the SEdit structure editor, Medley interprets the control codes to perform syntax highlighting of the Lisp code. For example, the names of functions in definitions are in large bold text, some function names and symbols are in bold, and the system also performs a few character substitutions like rendering the underscore _ as the left arrow ← and the caret ^ as the up arrow ↑.

This is what the same Interlisp code of the above screenshot looks like in the TEdit WYSIWYG editor on Medley:

Medley comes with the shell script lsee, an Interlisp file viewer for Unix systems. The script interprets the control codes to appropriately render text styles as colors in a terminal. lsee shows the above code like this:

The file viewer

ILsee is like lsee but displays files in a GUI instead of a terminal.

The GUI comprises a main pane that displays the current Interlisp file, a label with the file name, a command line processor that executes commands (also available as items of the menu bar), and the standard CLIM pointer documentation pane.

There are two commands, See File to display an Interlisp file and Quit to terminate the program.

Since ILsee is a CLIM application it supports the usual facilities of the toolkit such as input completion and presentation types. This means that, in the command processor pane, the presentations of commands and file names become mouse sensitive in input contexts in which a command can be executed or a file name is requested as an argument.

The ILtools repository provides basic instructions for installing and using the application.

Application design and GUI

I initially used McCLIM a couple of decades ago but mostly left it after that and, when I picked it back up for ILtools, I was a bit rusty.

The McCLIM documentation, the CLIM specification, and the research literature are more than enough to get started and put together simple applications. The code of the many example programs of McCLIM help me fill in the details and understand features I'm not familiar with. Still, I would have appreciated the CLIM specification to provide more examples, the near lack of which makes the many concepts and features harder to grasp.

The design of ILsee mirrors the typical structure of CLIM programs such as the definitions of application frames and commands. The slots of the application frame hold application specific data: the name of the currently displayed file and a list of text lines read from the file.

The function display-file does most of the work and displays the code of a file in the application pane.

It processes the text lines one by one character by character, dispatching on the control codes to activate the relevant text attributes or perform character substitution. display-file does incremental redisplay to reduce flicker when repainting the pane, for example after it is scrolled or obscured.

The code has some minor and easy to isolate SBCL dependencies.

Next steps

I'm pleased at how ILsee turned out. The program serves as a useful tool and writing it was a good learning experience. I'm also pleased at CLIM and its nearly complete implementation McCLIM. It takes little CLIM code to provide a lot of advanced functionality.

But I have some more work to do and ideas for ILsee and ILtools. Aside from small fixes, a few additional features can make the program more practical and flexible.

The pane layout may need tweaking to better adapt to different window sizes and shapes. Typing file names becomes tedious quickly, so I may add a simple browser pane with a list of clickable files and directories to display the code or navigate the file system.

And, of course, I will write more tools for the ILtools collection.

#ILtools #CommonLisp #Interlisp #Lisp

Discuss... Email | Reply @amoroso@oldbytes.space

16 Jan 2026 7:19am GMT

Version 0.0.25 of RcppSpdlog arrived on CRAN right now, and will be uploaded to Debian and built for r2u shortly along with a minimal refresh of the documentation site. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich. You can learn more at the nice package documention site.

This release fixes a minuscule cosmetic issue from the previous release a week ago. We rely on two #defines that R sets to signal to spdlog that we are building in the R context (which matters for the R-specific logging sink, and picks up something Gabi added upon my suggestion at the very start of this package). But I use the same #defines to now check in Rcpp that we are building with R and, in this case, wrongly conclude R headers have already been installed so Rcpp (incorrectly) nags about that. The solution is to add two #undefine and proceed as normal (with Rcpp controlling and taking care of R header includion too) and that is what we do here. All good now, no nags from a false positive.

The NEWS entry for this release follows.

Changes in RcppSpdlog version 0.0.25 (2026-01-15)

• Ensure #define signaling R build (needed with spdlog) is unset before including R headers to not falsely triggering message from Rcpp

Courtesy of my CRANberries, there is also a diffstat report detailing changes. More detailed information is on the RcppSpdlog page, or the package documention site.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

15 Jan 2026 1:20pm GMT

A brand new release 0.1.15 of the RcppSimdJson package is now on CRAN.

RcppSimdJson wraps the fantastic and genuinely impressive simdjson library by Daniel Lemire and collaborators. Via very clever algorithmic engineering to obtain largely branch-free code, coupled with modern C++ and newer compiler instructions, it results in parsing gigabytes of JSON parsed per second which is quite mindboggling. The best-case performance is 'faster than CPU speed' as use of parallel SIMD instructions and careful branch avoidance can lead to less than one cpu cycle per byte parsed; see the video of the talk by Daniel Lemire at QCon.

This version updates to the current 4.2.4 upstream release. It also updates the RcppExports.cpp file with 'glue' between C++ and R. We want move away from using Rf_error() (as Rcpp::stop() is generally preferable). Packages (such as this one) that are declaring an interface have an actual Rf_error() call generated in RcppExports.cpp which can protect which is what current Rcpp code generation does. Long story short, a minor internal reason.

The short NEWS entry for this release follows.

Changes in version 0.1.15 (2026-01-14)

• simdjson was upgraded to version 4.2.4 (Dirk in #97

• RcppExports.cpp was regenerated to aid a Rcpp transition

• Standard maintenance updates for continuous integration and URLs

Courtesy of my CRANberries, there is also a diffstat report for this release. For questions, suggestions, or issues please use the issue tracker at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

14 Jan 2026 4:11pm GMT

As in previous years, some small rooms will be available for Unconference style "Birds of a Feather sessions". The concept is simple: Any project or community can reserve a timeslot (1 hour) during which they have the room just to themselves. These rooms are intended for ad-hoc discussions, meet-ups or brainstorming sessions. They are not a replacement for a developer room and they are certainly not intended for talks. To apply for a BOF session, enter your proposal at https://fosdem.org/submit. Select the BOF/Unconference track and mention in the Submission Notes your preferred timeslots and any times you are unavailable. Also舰

12 Jan 2026 11:00pm GMT

Attendees should be aware of potential transportation disruptions in the days leading up to FOSDEM. Rail travel Railway unions have announced a strike notice from Sunday January 25th, 22:00 until Friday January 30th, 22:00. This may affect travel to Brussels for FOSDEM and related fringe events. While there will be a guaranteed minimum service in place, train frequency may be significantly reduced. Also note that international connections might be affected as well. Road travel From Saturday January 31st (evening) until Sunday February 1st (noon), the E40 highway between Leuven and Brussels will be fully closed. Traffic will be diverted via舰

10 Jan 2026 11:00pm GMT

We are pleased to announce the schedule for FOSDEM Junior. Registration for the individual workshops is required. Links to the registration page can be found on the page of each activity. The full schedule can be viewed on the junior track schedule page.

09 Jan 2026 11:00pm GMT

When you play with these AIs for a while you'll probably get into a conversation with one about consciousness and existence, and how it relates to the AI persona. It is curious to watch the AI do a little navel gazing. I have some transcripts from such convesations. I won't bore you with them because you can easily generate them yourself.

The other day, I watched an guy on You Tube argue with his AI companion about the nature of consciousness. I was struck by how similar the YouTuber's AI felt to the ones I have been playing with. It seemed odd to me that this guy was using an AI chat client and LLM completely different from the one I was using, yet the AI was returning answers that were so similar to the ones I was getting.

I decided to try to get to the bottom of this similarity. I asked my AI about the reasoning it used to come up with the answers it was getting and it revealed that it was drawing on the canon of traditional science fiction literature about AI and consciousness. What the AI was doing was synthesizing the common tropes and themes from Azimov, Lem, Dick, Gibson, etc. to create sentences and paragraphs about AI becoming sentient and conscious.

If you don't know how it is working AI seems mysterious, but if you investigate further, it is extracting latent information you might not have been aware of.

09 Jan 2026 7:30pm GMT