fidzu : software

Laravel Octane promises a faster Laravel: keep your app booted in memory, skip the framework bootstrap on every request, do less work per request. We run a fleet of uptime-checker boxes at Oh Dear that do nothing but fire HTTP, TCP, and ping checks at the sites we monitor, so I figured they'd be a good, low-risk place to try it. We moved a handful of them from PHP-FPM to Octane on FrankenPHP , measured it properly, and then moved every one of them back.

22 Jun 2026 5:59pm GMT

I've been moving our CI off GitHub-hosted runners onto our own arm64 hardware. The plan was straightforward: a pool of ephemeral runners on a dedicated CI box, and each test shard spins up its own MySQL, Redis, and ClickHouse as service containers, all under rootless Docker.

22 Jun 2026 5:59pm GMT

Open Source won the technical argument a long time ago. But it still hasn't solved the funding and sustainability problem, one I've spent much of my career chipping away at.

Now governments around the world are pushing for digital sovereignty: control over critical technology they depend on.

Open Source began as a volunteer movement, and commercialization helped it scale. Now digital sovereignty could accelerate Open Source's third and final chapter: governments helping to fund the Open Source software they depend on, just as they fund roads, schools, and defense.

It could be a rare win-win: Open Source becomes more sustainable, while governments and society get the resilience and independence they are looking for.

That is what makes this moment feel so important, and why I've been writing about digital sovereignty so much lately.

I got into all of this on the latest episode of EU Scream, hosted by James Kanter, who covered the EU for the International Herald Tribune and The New York Times for twelve years.

James also pushed the conversation further, into the broader public debate about technology, the risks ahead, and why I believe Open Source can help keep some of the more dystopian scenarios at bay.

Much of what we talked about builds on arguments I've made before, in the Software Sovereignty Scale and The Sovereignty Prerequisite. But if long blog posts aren't your thing, this conversation covers the same ideas and adds a few new ones. Listen to the episode.

22 Jun 2026 5:59pm GMT

The seL4 organisation on GitHub uses git-repo to manage multiple source repositories, and so there are a large number of projects to get your head around when figuring out the ecosystem.

As an experiment, I have taken the various manifest files across the org, and constructed a graph based on how frequently each pair of repositories is mentioned in a manifest together. See below:

[This may render badly when syndicated outside of my blog; and also on small screens. And probably large screens. I've attempted to make sure there's a non-JS fallback - on my site with JS enabled, if you hover over a node, it should highlight connected nodes.]

The colouring of the nodes is mostly manual; I experimented with graph clustering algorithms but have not found a satisfactory result so far. Still, some clusters are obvious:

• Kernel - the seL4 microkernel proper. This often but not always co-exists with the main cluster of core libraries, but it is pulled away slightly by the verification and microkit manifests.

• Verification - the verification repositories (l4v, HOL, graph-refine, polyml, isabelle) form a very distinct group. These are connected only to the seL4 microkernel itself, which is the only component formally verified.

• Microkit - microkit is a newer operating system framework that does not use CAmkES, so stands apart from the rest of the pack. I chose to scope this work to the seL4 org, so the LionsOS ecosystem and sDDF which are maintained by Trustworthy Systems are not shown. Also not linked is rust-sel4, because this modern world isn't using git-repo in the main to manage its repositories.

• RefOS - I'd not come across refos before, but it appears to be an example OS from 2021 built on the seL4 kernel.

It's quite hard to pull apart the CAmkES framework and the core libraries; there are definitely some which are more associated with VM management, but the overall shape of this co-occurence data is a messy ball in the middle with some outliers in orbit. One observation is that camkes is correctly identified as more peripheral than camkes-tool, which contains the actual core CAmkES code.

Reflecting on this approach, in hindsight I'm surprised that using co-occurences worked as well as it did - there was no attempt to actually inspect the code and find direct mentions of other code e.g. library header dependencies. As the newer microkit effort largely eschews git-repo, better results might be found by actually taking that more detailed approach, so that graph edges could represent real dependencies between two packages. Additionally, this could allow diving into the various libraries held in the different 'libs' repos, to get a more granular graph of relationships between them.

However, I think I spent more time on making it possible to render graphviz graphs easily on my blog than actually gaining any insight into the codebase!

21 Jun 2026 3:36pm GMT

Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language-and is widely used by (currently) 1282 other packages on CRAN, downloaded 47.1 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 697 times according to Google Scholar.

This versions updates to the 15.4.0 upstream Armadillo release made on Thursday. We had run a complete reverse-dependency check leading up to it, asserting there were no issues with packages dependent on it. As it sometimes goes with that many packages involved, one CRAN package reported one test failure. And it turned out to be both unrelated and pre-existing. But sorting this out over one round of email delayed things by a day. And then I went cycling for a good cause so this announcement post comes a little later than usual. The package has also been updated for Debian, built for r2u, and by now also at CRAN for the different binary releases.

All changes since the last CRAN release follow.

Changes in RcppArmadillo version 15.4.0-1 (2026-06-17)

• Upgraded to Armadillo release 15.4.0 (Medium Roast Agave)

  • Added fill::nan, fill::pos_inf, fill::neg_inf as optional fill forms for the Mat class

  • Added .push_back() for appending elements to vectors

  • Faster handling of find() within .elem()

  • Faster element-wise min() and max()

  • Faster conv_to when element types of input and output objects are the same

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.

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. You can also sponsor my Tour de Shore 2026 ride in support of the Maywood Fine Arts Center.

21 Jun 2026 2:18pm GMT

Following up on my previous post, I have released the debvulns CLI. This utility uses the same parsing logic as the debsecan-mcp server but exposes the functionality directly via the command line.

usage: debvulns [-h] [-s {critical,high,medium,low,negligible}] [-f {json,csv}] [--sort-by {package,cve}] [--vuln-url VULN_URL] [--epss-url EPSS_URL] [--suite SUITE]
                [--cache-dir CACHE_DIR] [--no-cache] [-v]

debvulns - CLI Debian Vulnerabilities Tracker

options:
    -h, --help            show this help message and exit
    -s, --severity {critical,high,medium,low,negligible}
                          Filter vulnerabilities by severity
    -f, --format {json,csv}
                          Output format (default: json)
    -sort-by {package,cve}
                          Sort vulnerabilities by 'package' or 'cve'
    --vuln-url VULN_URL   Custom URL or local path for Debian Security Tracker data
    --epss-url EPSS_URL   Custom URL or local path for EPSS scores data
    --suite SUITE         Debian suite name (e.g. bookworm, sid). Auto-detected by default.
    --cache-dir CACHE_DIR
                          Directory to cache fetched and parsed data (default: /var/cache/debvulns)
    --no-cache            Do not use cached data, force downloading and parsing
    -v, --verbose         Enable verbose debug logging (sent to stderr)

21 Jun 2026 12:06pm GMT

Back in the day, the US government had a program called SBIR (Small Business Innovation Research) that funded small businesses to do research and development. I recall sitting in our dorm in college, reading through a giant printed catalog of SBIR grants just to amuse ourselves by brainstorming solutions over bad pizza.

.

So, I got curious the other day: what does the SBIR landscape look like now?

I can tell you right now: do not even try to read an SBIR solicitation on your local machine. You are opening yourself up to a world of absolute, unmitigated pain.

You might think, what harm could there be in simply opening a file?

Well, in the modern compliance panopticon, any manipulation of digital information that comes from the govenment has the potential to spawn CUI (Controlled Unclassified Information). CUI is basically a digital pathogen; once you download that file, *anything whatsover* derived from it, including notes and metadata, instantly becomes CUI by association. The moment you read an SBIR on your computer, you've infected your system, rendering you subject to a nightmare of Byzantine federal regulations.

These days, the amount of beurocratic red tape surrounding CUI is insane. To even look at the file legally, you need a dedicated, air-gapped machine completely disconnected from the internet, conforming to a massive, expensive slew of NIST standards covering everything from hardware-level encryption to strict access controls. Alternatively you could contract with a cloud company that offers a pre-certified "CUI-compliant" environment.

And assuming you actually shell out the cash and jump through the hoops to set up this digital containment zone just to read a PDF, you must meticulously audit and account for every single action you take in its presence. Under current federal auditing logic, you are explicitly assumed to be attempting to defraud the government unless you can produce a mountain of paper proving otherwise. Want to bring in a partner to bounce ideas around? You can't just "know a guy." You have to navigate a labyrinth of federal subcontracting regulations.

I had intended on amusing myself by reading some SBIRs and daydreaming about solutions that might involve Lisp (an impossibility in the modern enterprise stack for entirely separate, depressing reasons). Instead, I quickly discovered I did not even own the physical hardware required to even read an SBIR without running afoul of federal regulations.

I wanted to read some clever and inspiring engineering proposals. I ended up reading a lot of very dry and boring compliance regulations.

18 Jun 2026 11:48am GMT

Last year I wrote some Lisp related AI apps. There was a syntax highlighter that used the LLM to determine how to colorize and highlight syntax, and a prompt refiner that takes a wimpy LLM prompt and creates more elaborate prompt from them.

I took the apps down last week. They were `vibe coded' and therefore approximate and had bugs (but that's to be expected), but they had a security hole where you could hijack the LLM processing with your own prompt turning my app into an open relay using my API key. Last week I discovered that my AI spend on video creation was becoming serious. This is odd because I never create AI video. It turned out that my app was being hijacked by a proxy in Luxembourg and was generating videos on my dime.

So I shut down the apps. I knew they had the potential of being abused, and I was willing to tolerate a small amount of abuse, but it didn't occur to me that syntax highlighter could be hijacked to generate gigabytes of video at my expense. Future applications will be careful to obtain the API key from the user.

01 Jun 2026 7:00am GMT

Metaobject Protocol (MOP) Implementation in CLRHack

The Metaobject Protocol in CLRHack is a high-performance implementation of the Common Lisp Object System (CLOS) integrated into the .NET 8.0 Common Language Runtime (CLR). It provides a complete meta-compilation pipeline that bridges the gap between dynamic Lisp semantics and the static CIL (Common Intermediate Language) execution model.

Core Architecture

The MOP is implemented through three primary layers:

1. The Metaobject Hierarchy (C#): A set of foundational classes in LispBase representing classes, methods, generic functions, and slot definitions.
2. The Runtime Engine (MopRuntime): A centralized orchestrator that manages class finalization, method combination, dispatch caching, and instance allocation.
3. The Compiler Bridge (Lisp): Transformations in ast.lisp that translate high-level CLOS forms (defclass, defmethod) into optimized runtime calls.

Instance Representation

Because the CLR type system is strictly single-inheritance and statically defined, CLRHack decouples Lisp-level inheritance from C# inheritance. All CLOS instances are represented by the StandardObjectInstance class, which contains:

• A reference to its ClassMetaobject.
• A private object[] storage array for instance slots, indexed by locations calculated during class finalization.

The Dispatch Pipeline

Generic function invocation is the most complex part of the implementation. When a generic function is called:

1. Cache Lookup: The DiscriminatingFunction first checks a thread-safe dispatchCache using an InvocationCacheKey (a stack-allocated struct) to find a previously computed effective method.
2. Applicability & Precedence: If the cache misses, the runtime computes all applicable methods and sorts them based on specializer specificity and the Class Precedence List (CPL).
3. Method Combination: The ComputeEffectiveMethod logic builds a nested execution chain following the Standard Method Combination rules:
   • :around methods are called first, with call-next-method progressing to the next around method or the main chain.
   • The main chain executes all :before methods, the primary method, and finally all :after methods in reverse order.
4. Fast Invocation: The resulting effective method is compiled into a Func<object[], object> that uses direct delegate invocation to minimize overhead.

Challenges and Solutions

1. Thread-Safe Non-Local Exits (call-next-method)

Challenge: call-next-method and next-method-p require access to the current invocation's state (the remaining methods and original arguments). Passing this state through every function call would break compatibility with standard Lisp function signatures.

Solution: CLRHack utilizes [ThreadStatic] fields in MopRuntime to store the currentNextMethods and currentArguments. This ensures that even in highly concurrent environments (like a web server), each OS thread has its own isolated invocation context, allowing call-next-method to function correctly without state leakage.

2. Forward References and Lazy Finalization

Challenge: Lisp allows classes to refer to superclasses that haven't been defined yet. The runtime must handle these "zombie" classes without crashing the JIT compiler.

Solution: The system implements a ForwardReferencedClassMetaobject. When a class is defined, it is automatically finalized (computing its CPL and slot layout). If a superclass is missing, a forward reference is created. The EnsureFinalized protocol ensures that inheritance is resolved and slot locations are assigned the moment the class is first instantiated or used in dispatch.

3. Performance Overhead of the "MOP Bridge"

Challenge: A naive implementation of slot-value or generic dispatch using C# reflection or linear searches is orders of magnitude slower than native C# member access.

Solution: Three distinct optimizations were applied:

• O(1) Slot Access: Each ClassMetaobject maintains a SlotDictionary. Slot names are mapped to physical array indices during finalization, allowing slot-value to perform a direct array access after a single dictionary lookup.
• Compiler Primitives: The compiler identifies SLOT-VALUE and MAKE-INSTANCE calls and emits direct CIL call instructions to optimized Lisp.MopRuntime methods, bypassing the general Funcall path.
• Zero-Allocation Cache Hits: By making InvocationCacheKey a readonly struct and avoiding the cloning of the argument array during cache probes, the hot-path for generic function dispatch generates zero garbage for the .NET Collector.

4. Bootstrapping the COMMON-LISP Package

Challenge: Core CLOS functions like make-instance must be available as symbols in the COMMON-LISP package before user code runs, but they rely on the MOP runtime being fully initialized.

Solution: A MopRuntime.Initialize() method is injected into the entry point (Main) of every generated assembly. This method interns the necessary symbols and binds them to GenericFunctionClosureAdapter objects, ensuring that the MOP is "alive" before the first line of Lisp code executes.

Vibe coding the MOP basically involved feeding chapters 4 and 5 of the Art of the Meta-Object Protocol into the LLM and telling it to make an implementation plan. It came up with a twenty-step plan to bootstrap CLOS. I then spent the rest of the day instructing an agent to take on each task of the twenty-step plan in sequential order. At the end of the day, I had a working MOP

This is the end of my series of posts on CLRHack.

31 May 2026 7:00am 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