Search Results: "will"

4 August 2026

Dirk Eddelbuettel: #058: Reverse Dependencies Made Easy, Fast, Reliable

Welcome to post 58 in the R4 series. R and the CRAN repositories maintain a very high level of what we might call quality assurrance by requiring that newly-added code does not break any existing dependencies. This is frequently called a reverse-dependency check . For any given CRAN package one can quickly determine it reverse dependencies. Calling tools::package_dependencies(pkgName, reverse=TRUE) will for a scalar or vector-valued argument return a named list with the reverse dependencies. It is then a matter of looping over this list. There are helper functions in base R as well as in contributed packages on and off CRAN. I also wrote my own with package prrd which, while possibly a wee bit specialised and under-documented has served me well to check on Rcpp and related packages which can indeed have a large number of reverse dependencies. I recently looked into one of these contributed runner packages, and while I will refrain from naming its implementation language let me just mention that the term cargo cult may be a real thing here. What go me interested in this was the fact that if one has a simple-to-use runner then the fact that r2u makes it fast, easy, reliable: pick all three (to borrow its slogan) to deal with actual depencies if Ubuntu has indeed been selected as the host. We will maintain the position that if you can in fact integrate with the system-wide package management then any alternative per-repo package management approach not doing so will likely be dominated by an approach that does integrate with the system facilities. Which is what precisely what r2u does, and offers. And why it is used enough to by now have shipped eighty eight million binary packages. So I tested it for the reverse-dependency check task. What I learned by looking into the (much more complicated) runner was that it at the end of the day it hands the actual task of running the reverse dependecies off to a helper function rev_check that is part of the xfun package by Yuhui. I quickly found that besides xfun we would also need its suggested dependency tinytex which in turn would error unless the tlmgr binary was present. So as the sole requirement (on an Ubuntu system with r2u) turns out to be
$ apt install r-cran-xfun r-cran-tinytex texlive-base
where we do it all in one apt call (as root in the container). (Given r2u we could also call install.packages(c("xfun","tinytext")) followed by apt install texlive-base but it is simpler for this setup step to be just one call). With that we are basically done. I did this (twice) using a rocker/r2u container with r2u preinstalled, mounting a local work and scrap directory for the container. In it we expand the package to be tested (i.e. tar xaf pkgName_*tar.gz for a given source package pkgName from CRAN) and then just call with the package name and expanded direcrtory. I.e. I used this call to test my package AsioHeaders (which has just three reverse dependencies) to both name it and to point to the expanded source directory created for this purposed:
> system.time( res <- xfun::rev_check("AsioHeaders", src="AsioHeaders") )
## ... earlier output omitted for brevity here ...
   user  system elapsed 
 35.732   3.333 149.683 
> res
   httpgd ipaddress websocket 
        0         0         0 
> 
and about a good two minutes later I would get the timing result and the summary in variable res. As I checked the current CRAN version, the check was as expected free of concerns or issues. To support this, r2u did indeed go off and install about sixty seven binary packages (and the total includes all binary dependencies fully resolved) delivering on the just works promise by the r2u documentation. As another check, I did the same for RcppAnnoy which has seven reverse dependencies and needed about two hundred CRAN packages to be installed. The full test took just over four minutes with the timing function reporting some nice gains from parallelisation as total user compute time was on the order of just under eight minutes. Again, test results were clean and free of worries as expected:
> system.time( res <- xfun::rev_check("RcppAnnoy", src="RcppAnnoy") )
## ... earlier output omitted for brevity here ...
   user  system elapsed 
471.765 378.220 266.855 
> res
   bbknnR  bigANNOY  blocking     scDHA    Seurat      uwot VectrixDB 
        0         0         0         0         0         0         0 
> 
Overall this was a rather useful quick excursion as it demonstrates that - existing functions can be used to orchestrate a reverse dependency check - with reasonable dependency scale we can do this on a single machine quite easily taking advantage of parallel computing on multi-core machines - using r2u gives us fast, easy, reliable package installation making testing of packages we might not otherwise use or know a breeze - doing this in an ephemeral Docker container facilitates easy build-up of required resources and leaves no side effects behind which might affect our normal development environment

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.

Petter Reinholdtsen: FreeCAD MCP with llama.cpp, toy or tool?

After seeing a video a few months ago demonstrating how a proprietary CAM solution uses machine learning and large language models to automatically generate CNC instructions, and successfully testing it on a real CNC, I began wondering if the same could be achieved with free software. I still do not know the answer, but I may be getting closer to finding out. Two weeks ago, I came across the video "I Connected Claude AI to FreeCAD (And It Models Parts Like an Engineer)" by Make Form, which introduced me to the FreeCAD MCP project. Even though the video creator apparently believes it is acceptable to download and run random binaries from the Internet on a local machine (his setup uses UCX), I do not. I would probably have left the project alone entirely if I had not noticed that all of its dependencies are already available in Debian. This significantly boosted my motivation, so I set out to test it using packages built from source on Debian rather than relying on untrusted binaries. The first hurdle was that the MCP SDK for Python was not present on my Debian Forky test machine. I initially believed it was missing from Debian altogether, but it has been available in Debian Unstable for about a month and is only absent from Forky because some automated tests fail on architectures like riscv64 and s390. Fortunately, backporting it was straightforward using apt-get source -b python3-mcp . The next hurdle involved an outdated version of the Validators Python library. Since I am a member of Debian's Python team, which maintains this package, updating it to a sufficient version for FreeCAD MCP was relatively easy. I could not upgrade to the latest upstream release due to a new dependency on an Ethereum-related library, so I settled on a 2024 version. With those dependencies in place, I proceeded to create a Debian package for FreeCAD MCP. I had previously submitted a request for packaging of FreeCAD MCP to gauge interest while deciding whether to prioritize maintaining it myself. Because salsa.debian.org blocks access from Tor users like myself, I published my draft packaging scripts in a Git repository on Codeberg as the Debian FreeCAD MCP project and got it working with the FreeCAD 1.1 version in Forky. I initially struggled with the button controls for the MCP feature, which led me to submit a pull request titled "Fixed startup sync of checkable toolbar buttons" proposing a fix. Once this confusion was resolved and the MCP setup was enabled via the GUI, I was able to run FreeCAD completely headless using xvfb-run on a machine without an X server to generate models. I am using a private LLM service running the Debian package of llama.cpp with the Qwen 3.6 model downloaded from Hugging Face, configured with a maximum context window of 105k tokens. I also tested the Bonsai model on my test laptop; initially, its context window was too small (8k and 16k could not accommodate the FreeCAD MCP instructions), but even after increasing it to 32k, it proved useless for generating FreeCAD models so far. I've used Claw Code, Aider and Open Code with my server so far, and for this test I ended up with OpenCode because it was easy to set up to use an MCP. Because none of my LLM services are set up to be multimodal (capable of processing both text and images in this case), I configured the MCP to return only textual feedback from FreeCAD. I am unsure if this is a major limitation, though I suspect it might be. My testing experience remains limited, with no clear successes yet. Part of the issue likely stems from my ability to provide effective instructions for modeling 3D objects (I am relatively new to FreeCAD, English is not my first language, and I lack a precise vocabulary for describing construction features to an LLM). Nevertheless, the LLM has demonstrated the capacity to create 3D models in FreeCAD. In one of my first tests, I asked it to generate a cube and then produce CAM/G-code instructions for a CNC machine. It did output G-code (which remains untested), but I was surprised to find that it bypassed FreeCAD's built-in CAM module entirely and instead generated an external Python script to produce the code. This was not quite what I intended, though my instructions were probably unclear. The Qwen model with OpenCode seems to strongly prefer programming directly; it frequently executes Python snippets inside FreeCAD to achieve its goals rather than using the standard sketch-and-extrude workflow I am accustomed to. In another test, I asked the LLM to create a parameterized pipe assembly to see which of FreeCAD's parametric tools it would choose, but found no evidence of traditional parametric features in the output. When prompted, the LLM explained that the parameters were embedded directly in the Python script used to generate the model, rather than in native FreeCAD features. With more explicit instructions, it eventually created a FreeCAD spreadsheet to manage the parameters. The resulting model looked much closer to my expectations and could have been useful with further refinement. My so far last experiment was less successful: I asked it to design a pipe clamp, but the LLM repeatedly failed to position the clamping screws in a way that would actually secure the brackets around the pipe. It is unclear whether this limitation lies with the model, my prompt, or other factors. Based on my testing so far, I am uncertain whether FreeCAD MCP is merely a fun toy or a genuinely useful tool. I will only commit time to maintaining it in Debian if it proves to be practically valuable. I would welcome feedback from anyone who has experience with the project, preferably via the original request-for-packaging mailing list thread. Alternatively, I am available in the FreeCAD and Debian AI IRC channels for further discussion. As usual, if you use Bitcoin and wish to support my activities, please send donations to 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Anuradha Weeraman: Plan 9 from Bell Labs, the little OS that could

Plan 9 Fourth Edition showing the rio windowing systemScreenshot by VulcanSphere via Wikimedia Commons MIT License
I first heard of Plan 9 from my friend Vajra in 1999 or so, as we were distro-hopping on early Linux distributions and trying to find our way. Vajra is now a Nebula Award-winning science fiction author - have a look at his work. We had just been through Tom's Root Boot, a UNIX-like operating system crammed into a single floppy, and through it discovered a whole new world outside of DOS 6.22. Combing through old UNIX manuals, we went in search of the perfect OS, through Slackware, Caldera, TurboLinux, SUSE and Red Hat. I finally settled on Debian, which lived up to everything I stood for. Plan 9 was distinct. It came out of the Computing Sciences Research Center at Bell Labs, built by Rob Pike, Ken Thompson, Dave Presotto and Phil Winterbottom, with Dennis Ritchie heading the department. The name is a joke at their own expense, borrowed from Ed Wood's 1959 Plan 9 from Outer Space, routinely nominated as the worst film ever made. Thompson and Ritchie had, of course, built the original UNIX; it almost seemed as if they were building a new OS from the lessons learnt from building it - which was in turn built on the lessons from Multics. I remember the awe I felt playing around with Plan 9, and I've not been able to replicate it since. Plan 9 was different in a couple of fundamental ways: per-process namespaces, and a protocol that abstracted locality of resources to processes. As a consequence of these core primitives, the OS surface area was distinctly small. The entire system from the core kernel, to the system call interface, to the compiler, linker and shell was reduced to a form small enough that a single developer could hold it in their head. Lessons from the implementation of UNIX helped the designers make the system leaner, and in Ken Thompson's words, it's the "best operating system out except that it doesn't have the apps that everybody demands" [1]. It also took the concept of "everything is a file" in UNIX to a whole new level. The network stack is a filesystem (/net), processes are files, the display is a file (/dev/draw). Because every resource speaks 9P and every process has its own namespace, you can mount another machine's /net into your namespace and your program makes network calls through that machine's stack without knowing or caring. No sockets API, no RPC layer, just ordinary file system operations through a simple system call interface. Some would say that OS research is dead, and that backwards-compatibility and POSIX killed it. Rob Pike himself argued as much in his 2000 talk, "Systems Software Research is Irrelevant" - but we didn't care at the time. There was so much happening that we didn't have time to take it all in. And then Linux happened, and Software Freedom became a focal point (more on that in a later post). In the summer of 2020, with the world deep in Covid lockdowns, I decided to build a toy operating system, just to try my hand at the the thing that I had always wanted to do. I spent three feverish months working on Odyssey and, looking back, it is perhaps the most fun I have ever had. I would not dare compare it to the magnum opus that is Plan 9, but it gave me perspective: how hard it is to build an OS from scratch, and above all, how fun it is to build an OS from scratch, and why the original creators kept coming back to the same problem. The highlight of those three months was booting the OS and watching it render "The Great Wave off Kanagawa". Nothing in my professional achievements to date captures what that meant to me.
Odyssey rendering The Great Wave off Kanagawa during boot Odyssey displaying "The Great Wave Off Kanagawa"
Decades on from the first time I booted Plan 9, I look back with nothing but awe and respect for the creators of this little operating system and marvel at the foresight that went into it. While many readers will not have heard of Plan 9, they have almost certainly worked with the ideas that came from it: 9P (if you ever used the Windows Subsystem for Linux), UTF-8 (if you ever used any modern operating system), per-process namespaces (if you've ever run a container), Go (whose assembler still uses Plan 9 syntax). Plan 9 still lives on in 9front, a community-maintained fork. Separately, Yoann Padioleau [2] has produced a set of annotated books at principia-softwarica.org, presenting the Plan 9 source in the spirit of Donald Knuth's literate programming - an admirable effort to introduce new readers to the art of operating systems engineering. Pike thought systems research had become irrelevant, and Thompson thought Plan 9 would never "make it" [1]. Both were right about the industry, but may have been pessimistic about the impact. The system lost as a product but won as a set of ideas, assimilated one at a time by modern operating systems. Success is not always measured by popularity. The mark that Plan 9 left behind is greater than what's reflected in its current user base. To me, Plan 9 will always be the OS that punched above its weight class, the little OS that could. References [1] Ken Thompson Interview, March 6, 2024 [2] Yoann Padioleau Principia Softwarica, May 9, 2026

3 August 2026

Bernhard R. Link: I learned something new about URLs today

Today I stumbled over some behavior that I found quite surprising:
$ ipython3 -c 'import httpx;print(httpx.URL("https://example.com/foo/bar/../../baz"))'
https://example.com/baz
Even more surprising that behavior is actually standards-compliant, even mandated by RFC 3986. The underlying motivation is relative reverences. If some resource reachable by "https://example.com/foo/bar" references another resource relatively as "../../baz" then this is of course the intended result. Getting from this problem to what RFC 3986 suggests might be surprising in the result, but somewhat understandable if you look at the consequences of that problem: Giving the path components ".." (and ".") special meaning at the start of the relative reference means that if you allowed them in absolute URLs those would be impossible (or at least very convoluted) to address as relative URLs. So RFC 3986 describes a way to handle them everywhere: Just join the path of the base URL and the path of the relative reference and normalize the result. Or normalize the absolute on either side if only that is to be taken. This makes things very convenient: Multiple reference URLs can just be joined without special handling for relative references starting with dots, making writing applications handling them easier. Programmers don't have to care how to handle relative references and can just join everything in whatever way they want. For maximum elegance there is still some corner case left: What happens if an absolute URL has a path starting with double-dot components? Or an relative path starting with more of them then the base URL's path has components. You just ignore them:
$ ipython3 -c 'import httpx;print(httpx.URL("https://example.com/../../baz"))'
https://example.com/baz
With that last point every URL is valid and has well-defined meaning. Handling relative references and relative paths is very easy and convenient. So this shows a high regard for simplicity, elegance and convenience. And a total and uncompromising disregard of security. After all the most convenient it is for an attacker; If they are allowed to supply a path component for a request a system does in their behalf, then they can easily escape anything they were supposed to be limited to. The ignoring of dots at the start means they don't even have to know exactly how deep their request is:
$ python3 -c 'import httpx;print(httpx.URL("https://example.com/public/api/public/resources/harmless/../../../../../../../../../internal/data"))'
https://example.com/internal/data
So even if the resource server securely handles request (unless you consider not having any way to lower your permissions for one request to a specific subset), your fully RFC conforming client library will already request the permission they should not have permission for. Even worse dots are usually not characters you can easily forbid so once slashes are to be allowed things get complicated. There also would have been a simple, elegant and secure way: Consider every path element ".." or "." in an (absolute) URL an error. Define a reference resolution that allows the relative reference to only start with "./" or one or multiple "../" and consider every appearance of a dot or two dots as path components after than an error. Everything joining two paths has to either use an implementation of that path joining algorithm, but only if they want to joins paths in the potentially dangerous way allowing leading "../". Otherwise they can just use the normal join and even if an attacker gets those dots that will just cause the generated URL to be rejected as invalid. Of course using a secure implementation is now even more inconvenient thanks to RFC 3986 being around: If you have no control over the generator of relative references, it is always possible that they generate relative references with ".." components after non-dot components. And if you check all code to properly filter out "/../", keep in mind that convienence does not stop there. After all it is not unheared of for server implementations to helpfully normalize unicode characters, too, or translate them to their nearest ASCII equivalents. Or translate percent escaped characters back before doing path splitting. Or you might think there was some unicode codepoints between those two dots, but they that those were some meaningless control characters that can be omitted. So you need some really restrictive allow lists...

John Goerzen: Celebrating 45 Years of Kermit with the First New C-Kermit Release in 15 Years (and working with a decades-old C codebase)

1981 was a different time for computing. It was expensive (both hardware and software), and it was far from a given that machines from one vendor would be able to talk to those from another. In fact, Columbia University had just such a problem, so in 1981, Frank da Cruz and Bill Catchings designed a serial protocol they called Kermit. Because of the many quirks of the DEC-20 and IBM mainframes, the Kermit protocol was highly adaptable from the start: able to handle systems that had trouble processing more than 96 bytes of data at once, able to transfer 8-bit files over 7-bit links, able to translate between character sets (ASCII and EBCDIC then; now also various Unicodes), and of course, handling of error-prone serial links. Kermit spread rapidly; by 1982, Kermit had been ported to MS-DOS and Unix. Eventually, C-Kermit (an implementation of Kermit in C) became the flagship Kermit. It gained TCP support, an interactive CLI, a powerful scripting language (with features from the shell, Lisp, and expect), and optimizations for today s high-speed links, such as jumbo packets, sliding windows, and streaming modes. Along the way, Kermit flew on the International Space Station, ran data collection from sensors during hurricanes, and many other uses including postal systems, Boeing 787 manufacturing, and more. Today, I use it as a powerful ssh wrapper (letting me easily transfer files through multiple nested ssh, sudo, su, etc. commands), a BBS client, to exchange data with me HP 48GX calculator, and so on. It s also used today to transmit firmware updates to embedded devices. And, of course, anyone that works with vintage systems is likely to use Kermit at some point. It wouldn t be until the late 1990s that the TCP/IP stack was finally adopted by most OS vendors, establishing something of a common basis for communication. Of course, we assume this today. Though transferring large files between OSs (say, Linux, Windows, MacOS, Android, iPad, etc.) is still a challenge, even though they all speak TCP/IP! I find that the easiest way to get large files from two computers is to spin up Kermit (see ckwin for a Windows fork of C-Kermit) and just set up a TCP connection over the LAN. In fact, I added a new show interfaces command in C-Kermit 11, making it easy to see your system s local IPs. For most of its history, Columbia s Kermit project was self-funded. Columbia charged for commercial use, which limited its inclusion in Linux distributions. In 2011, 30 years after its founding, Columbia canceled the Kermit Project and released C-Kermit as Open Source under a BSD license. Frank da Cruz, who had still been working with the Kermit project all those years, volunteered to continue maintaining Kermit outside Columbia, and continued development with alpha and beta releases through his retirement from the project in 2025. I dive into this C codebase As Debian maintainer of Kermit, I noticed some areas where it wasn t matching modern expectations. One area was, not surprising for a project of its age, security. Another area was that its character set or line-ending conversions are usually not desired now; we are used to byte-identical binary transfers, and the defaults caused confusion and even some rare instances of data corruption. So I started making a few patches last year. I ve worked with old C codebases before, such as Varnish. I ve generally hated it. You usually find a mix of bad and terrible practices, unclear memory management, and so forth. But I ve been living in the C-Kermit codebase for a few months now, and I enjoy it. Yes, this thing is still designed to build on VMS, OS/2, and with compilers that haven t heard of ANSI and those that require modern practices. (That em-dash was mine; I knew how to use them before LLMs existed and I m not going to stop just because LLMs have copied people like me! No AI was used for this post.) The there is an elegance in all of that. As I worked, I fixed a bunch more potential security issues, both with memory safety and with protecting against a malicious remote in roughly the same manner that some patches to scp did a few years back. I added IPv6 support, of course conditionally compiled because some systems C-Kermit builds on have never heard of IPv6 and never will. (And, of course, with fallback algorithms at runtime for systems that have IPv6 support but not IPv6 connectivity.) I added unit tests and Python-based end-to-end tests, running nearly 2000 test cases in total. Along the way, I found and fixed a number of bugs going back decades. I learned about FIONREAD being broken on macOS, about NetBSD s bugs in the pty driver, and fixed bugs in the Kermit protocol implementation itself. I added compatibility tests with the gkermit and ekermit (embedded) implementations, as well as the last full release, C-Kermit 9.0.302 from 2011 (which was difficult to get compiled on a modern system). There is an extensive changelog describing all the improvements in C-Kermit 11. C-Kermit development had never really used a VCS at any point, though Kermit veteran Jeffrey Altman imported historical releases into a Git repo, along with some patches that hadn t made it into a release (which I also pulled in.) There was a lot of disabled code behind COMMENT, along with commentary describing why it was no longer used. With Git, we would now generally just remove the old code and explain why in a commit message. I went through and did so with a lot of it, meaning that, at last check, C-Kermit actually has fewer lines of code now than it used to. Towards a new release It became apparent pretty quickly that I was making more changes than would make sense as a Debian patch series. Not only that, but they would be more widely applicable to more than just Debian and Ubuntu users. As Linux and BSD distributions were running everything from the last non-beta release (2011 s 9.0.302) to the last beta release (about 1.5 years ago), depending on their different policies about running betas, even sharing patches in a useful fashion was going to be quite difficult. So, I spun up a project at Open Kermit to coordinate future development in the open and keep Kermit going. With modern CI, I run that test suite on Linux (x86_64 and arm64), macOS, FreeBSD, NetBSD, and OpenBSD. It builds binary releases on all those platforms, plus a statically-linked Linux binary built with musl libc. You can download the latest C-Kermit release, and of course contribute to C-Kermit and its website. Dedication Frank da Cruz was directly involved with Kermit for 44 years. I m not aware of any other Open Source project founder being involved for so long. Richard Stallman started working on GNU Emacs in 1984, 3 years after Frank started working on Kermit, but Richard hasn t been in that role since around 2008. Accordingly, C-Kermit 11 bears this dedication:
I dedicate this release of C-Kermit to Frank da Cruz. Frank was directly involved with Kermit for 44 years, from its initial design in 1981 all the way through 2025. He maintained Kermit as an Open Source project after Columbia University ended its sponsorship. I know of no other Open Source project where the founder remains so personally involved for so long. When Kermit was begun, transfers between different hardware and operating systems were difficult or impossible. Frank helped build a bridge. Kermit glued systems together, from the International Space Station to pocket calculators, and set a new standard for interoperability. It continues to do so. Kermit is still one of the quietly-working pillars of computing today, enabling everything from firmware upgrades to radios. And, yes, it still reliably transfers files over serial lines. As we start to spend a lot of time in the Kermit codebase, we do so standing on the shoulders of a giant. Thanks, Frank, for your decades of work on Kermit. John Goerzen, July 2026

2 August 2026

Russ Allbery: Term::ANSIColor v6.0.0 TRIAL release

Yesterday, I uploaded Term::ANSIColor v6.0.0-TRIAL to CPAN for early testing. This release will raise the minimum required Perl version to 5.12, dropping support for Perl 5.8 and 5.10. When I did the same with podlators a couple of years ago, it upset a few people and one of them asked me to make this sort of test release in the future. Hopefully this will help. I have not run the normal release machinery and haven't archived this release in the normal places, since I intend it to be transient. It's only on CPAN, where people can retrieve it for testing. Once v6.0.0 is released, few traces of this TRIAL release will be left. This doesn't appear to be how other people use the TRIAL mechanism, but it felt more comfortable to me. If I have to make substantial changes, I'll consider changing my approach. I plan on turning this into the v6.0.0 release in about a month or two, hopefully with only documentation changes. Term::ANSIColor is a "very upstream" core module with a lot of dependencies, and CPAN (unlike some of the archives that followed it, such as PyPI) doesn't support conditionally retrieving packages based on the current Perl version. This release may therefore be disruptive for people who are still trying to support Perl 5.8 and 5.10, since CPAN installation tools may attempt to install an incompatible Term::ANSIColor version. I'm sad that this will be the result, since I know some people still care about those versions. I'm pressing forward with updating my Perl modules anyway, though. I realized that honoring other people's desire for stability to such a degree that I was unable to use Perl features added more than 15 years ago was destroying my motivation to work on these Perl modules at all. So I've decided on a very slow and gradual approach where I'm going to keep pushing the minimum supported version forward but try to give people a lot of warning. Personally, I think it's time to let ancient versions of Perl go and follow the Lyon Amendment about supported Perl versions. When we're talking installing new modules for software released more than 15 years ago, we're talking about special limited environments and retrocomputing more than what I would consider routine software maintenance. Those tasks should expect to need different tools and a different workflow so that they can pin historical versions. Since this isn't something I'm personally interested in, my willingness to expend time and energy to assist is limited. As you can probably tell, I still feel nervous about pressing forward in this way, but I think this is the approach that lets me continue to enjoy maintaining these Perl modules. It's been 29 years for Term::ANSIColor, but I still enjoy fixing bugs in it and putting out a new release from time to time, particularly if I can clean up the code a bit each time I touch it.

31 July 2026

Russ Allbery: Review: Painting the Blues in Gretna Green

Review: Painting the Blues in Gretna Green, by Linzi Day
Series: Midlife Recorder #2
Publisher: Linzi Day
Copyright: November 2022
ISBN: 9798360228431
Format: Kindle
Pages: 577
Painting the Blues in Gretna Green is a self-published fantasy novel and the second in the Midlife Recorder series. It picks up immediately after the end of Midlife in Gretna Green. I also read it almost immediately after, so I didn't pay attention to how good the recap of previous events was. As before, this is urban fantasy except not urban. Day calls it paranormal women's fantasy, which I suppose is as good of a genre label as any. The other book I can think of off-hand that would go into that genre would be Nancy Springer's Larque on the Wing, although it is considerably more literary. I suspect I'm going to read this whole series and it's going to be impossible to review these books without talking about Niki's job, so I'm not going to treat that as a spoiler. It's fairly well-advertised in the marketing for the book, so that feels justified. If you're particularly averse to any spoilers, though, you may want to stop reading here until you've gotten to the reveal in the first book. Niki is now officially the Recorder, with the power, advice book, and sentient house to go with it. She's about to face her first test in managing interworld politics: There's something amiss in the world of the Picts. Her allies are dropping hints, there's a petition from a group on the Pict world that she can't make sense of, and although she likes the queen of the Picts, there is a great deal of tension beneath the surface that she doesn't understand. Meanwhile, after the incompetent disaster that she uncovered in the first book, Niki is determined to pick her new staff by her own criteria. The second book leans even harder into giving Niki both a tangled mess created by previous incompetence and enough power to fix it. Watching that happen is very satisfying, particularly when it involves surprising people who are rather too used to getting their own way. I was somewhat less convinced that Niki is getting the right training to make the decisions that she's making. Diplomacy and staff management are real skills that one needs to learn, not just wing on vibes and gut instinct. My love of competence porn occasionally wishes that Niki had a bit more structure around her competence. We do at least get a new fictional self-help book on how to rule that contributes the quotes that open each chapter. Not the ethics and management training that I would have chosen, but it's something! In defense of Niki's technique, it becomes clear in this book that the last few recorders have been far too cautious, conservative, and content with a status quo that involved a minimum of work. One of the delights of this book is that Niki thinks power exists to be used to fix things and is determined to use it, not just sit on it. I had more suspension of disbelief issues with this book than with the first some of the problems Niki is solving seem far too obvious to have been in stasis for this long while also having this easy of a solution, and the level of political power given to the Recorder is a bit unbelievable but it is so satisfying to see Niki cajole and bully people into being sensible. I have no idea if this is intentional on Day's part, but I will not be at all surprised if adult-diagnosed ADHD comes up at some point in this series. The way that Niki's focus jumps, her tendency to veer between focusing on a problem and forgetting about it, and something about the way she switches between trains of thought or misses important context because she's jumping to conclusions is making me wonder. This, to be clear, is not a complaint; I think it makes Niki more relatable and more interesting. It's a good thing that she has a sentient house to serve as her assistant. The glee with which she's delegating any task that involves keeping track of details or following up with other people feels like a bit of an indicator by itself. I did get a bit frustrated with the plot structure of this book. Niki keeps mentioning that a critical petition submitted to her office makes no sense, but it takes half of this (rather long) book before she finally explains to anyone else, even the reader, what's deficient about it. The excuse within the book is that she's having a rather busy day, but by the third time Niki mentions and then fails to do anything about the petition, I was wishing Day would stop bringing it up until she was ready for that part of the plot. This, as with a few issues in the previous book, feels partly like an editing problem. There is something joyful in indulgent, sprawling books, but only up to the point where they become repetitive. Painting the Blues was right at that line, and once again I wish someone had helped Day trim about fifty pages out of it. All that said, and despite having more quibbles with this book than the previous one, this continues to be great fun. It's satisfying wish-fulfillment about fixing long-standing problems and having the power to not have to put up with abusive nonsense and ridiculous bullshit, and I am so here for that. I hope Niki realizes she's eventually going to need more refined skills than a heart-to-heart over wine, but she's learning on the job and I'm happily along for the ride. She's also capable of recognizing skill in other people, and that goes a long way. Recommended if you liked the first one and are in the mood for another fantasy of "no, we're not going to leave it that way, we're going to fix that right now." Followed by Ties that Bond in Gretna Green. Rating: 7 out of 10

Otto Kek l inen: Estonia, the country of the fit and the wit

Featured image of post Estonia, the country of the fit and the witWhile many Western democracies seem to be in a state of decay and are no longer the safe, civilized and prosperous countries they once were, there are still some European countries that are governed well. One of those that stand out is Estonia. Estonia is probably most well known for multiple software companies that originated from there, such as Wise, Bolt, Pipedrive and Skype. The government itself is also famous for being early in issuing government IDs with an embedded smart chip for online authentication already in the 1990s. Via the national portal at eesti.ee all residents can access extensive eServices ranging from viewing their health benefits to filing taxes. Estonia has also been running an e-Residency program since 2014, where they issue digital ID cards to foreigners, making it easy for them to remotely log into the government portals and for example, establish businesses, file annual reports and so forth. Note that the e-Residency is not a path to physical residency. Estonia does, however, have a separate Digital Nomad visa program that makes it easy for non-EU citizens to also physically establish themselves in Estonia, assuming, of course, you meet the criteria, which includes, among others, a minimum monthly income of 3960 from outside Estonia. EU citizens naturally have free mobility inside the EU and can simply get an apartment and register as a resident in Estonia if they so choose. And there are plenty of reasons to do so.

Estonians value health, education and entrepreneurship I moved to Estonia about one and a half years ago. In my observations Estonia strikes me as a country that values health, education (in particular programming and natural sciences) and entrepreneurship highly. I don t know how Estonians achieve it, but they look pretty fit and rarely obese. Estonia has rye bread and sauna in their culture just like Finland, and in addition the flat terrain and well-planned bike routes and extensive network of parks (and pull-up bars everywhere) seem to create an environment where it is easy to live in a healthier way. The consumption of processed foods and candy also seems relatively low among Estonians. The gym chain MyFitness also seems to be present everywhere. Even the Tallinn airport has a calisthenics workout station right at the departure gates, which anyone is free to use while waiting for their flight to take off. One of the top longevity influencers in Europe, Siim Land, is Estonian. Estonia has lots of good bike paths, parks and outdoor gyms There is even a calisthenics station with pull-up bar and more at the departure gates at Tallinn airport Estonians also seem to value the school system highly. The government has been actively raising teacher pay and has a stated goal of reaching 120% of the national average by 2027. The students are also expected to value the education and respect their teachers. According to the TALIS 2024 survey (OECD s international teacher survey), Estonian teachers spend significantly more time on actual teaching and learning and waste less time on interruptions or keeping classroom order compared to the OECD average. This is among the highest rates internationally, meaning they spend relatively little time on maintaining order or dealing with disruptions. While the international education benchmark PISA scores have been dropping globally, Estonia has consistently been climbing the ranks in past decades. In the latest PISA study (from 2022), Estonia ranked number one in Europe for reading, mathematics and science. In the overall results, Estonia ranked seventh globally, only behind countries such as Japan, Korea and Singapore. Valuing entrepreneurship is evident in how the taxation system is set up in Estonia. Famously, in Estonia, companies can defer taxes on annual earnings and reinvest all of their profit in growing the company. Taxes are due only later, when paid out from the company, for example as dividends. For individuals, receiving dividends from any Estonian or foreign company is tax-free as long as the company paying dividends already paid corporate tax on the same income. The tax system is also very simple. For all individuals, all types of income, including salary and capital gains, are always taxed at a flat rate of 22%. This removes the incentive for anyone to try to convert income into different types, setting up holding company structures and other optimizations as there is no gain. All entrepreneurs can simply focus on growing their business and forget extra bureaucracy. There is also no marginal tax rate cliff to stop working at everyone is encouraged to always try to produce as much value as they can. A simple tax system is also reflected in the fact that anyone can easily read all tax rules that apply to individuals in plain English on the Estonian tax authority website, and one does not need to hire any accountants simply to file taxes. Estonia also has a very straightforward investment account system: any person can freely open a self-directed investment account at any brokerage at no extra cost and report it as such to the tax authority, and then use it to save for an apartment, retirement, or other purposes, and defer all income taxes until withdrawal. There are no caps or time limits, and all residents are encouraged to save and invest as much as they can and thus take responsibility for their own wealth accumulation. It seems that culturally Estonians respect people who are active and progress in their careers and businesses more than in other countries. Unlike in Finland, successful people are admired and living on government welfare is not romanticized. At the same time, the government benefits are less generous so people can t live comfortably on them and, for example, many of the asylum seekers Estonia accepted have since left on their own initiative to other European countries in search of better benefits.

Low crime, high trust Another thing that strikes me when walking the streets of Tallinn is that there are no drug addicts, beggars, thugs or the like. The difference compared to, for example, Vancouver (where I lived previously) is stark. In public buildings, people leave their coats and bags hanging in the lobby while visiting. Private houses and apartment block yards are not fenced. In my building, I noticed people even leave their bikes unlocked in the bike shed. I have also seen the staff of a coffee stall in a shopping mall going for a break and leaving everything unattended, not worrying that anyone would take anything while the staff is away. Nobody is stealing anything from the unattended coffee shop while staff is having a break at  lemiste shopping mall This is not just my personal experience. According to the Numbeo crime index, Estonia has one of the lowest crime rates in the world. Also, comparing drug and property crime stats, for example, Finland has twice as much crime per capita, and places like Vancouver in Canada almost five times more. I don t have any clear explanation for why crime is so much lower in Estonia, but some suggest that higher social cohesion and lower levels of welfare contribute to people standing to lose more if they behave antisocially. Compared to Finland, Estonia also more readily jails repeat offenders, and those who are put on trial will experience a swifter court process thanks to simplified legal processes and more efficient governance.

Moving to Estonia: quick checklist Moving to Estonia is very easy for any EU citizen, in particular if your work is not location-dependent (e.g., remote work or an online business) and you are simply looking for the cleanest and safest environment to live in. First, check into a hotel in Tallinn, check out various neighborhoods to figure out what area you like (my favorites are Kalaranna, Kalamaja, Noblessner and Volta) and start browsing available apartments in English at kv.ee. Most professionals speak fluent English, so there should not be any difficulty in reaching out to people by email or phone. Tallinn is famous for the old town The economic boom of recent decades created a lot of new construction, with Kalaranna being among the newest areas The next step is to buy a local prepaid SIM card at e.g., an R-Kiosk or a convenience store as signing up for other matters later on will require an Estonian phone number. Once you have an apartment and e.g., signed a rental agreement, you can register in the population registry online. After that, you have proof you are a local resident with an address and telephone number in Estonia. With local resident status, you can go to the police station to get a local ID card. Don t bother scheduling an appointment, just go to the Tammesaare police station in Tallinn, take a queue number and wait. Once it is your turn, they will guide you on how to use the photo booth, fingerprint registration device, and file your application. A few days later you will receive an email confirming whether your application was accepted, and after a few more days, you will get another email notifying you that your ID card has been printed and is available for pick-up at the same location. This will also be your first practical experience of how fast and efficient the government in Estonia is. Once you have the local ID card, you can use the smart card feature to log into all the government eServices and sort out the rest of the relocation process, such as registering tax residency and getting a family doctor. The main eServices portal in Estonia: eesti.ee

How did Estonia evolve to be like this? After Estonia regained its independence after the fall of the Soviet Union in 1991, the first elected government in 1992 was led by a very progressive 31-year-old Prime Minister Mart Laar, who managed to set up some very good policies and laid the foundation of a society that has evolved well in the decades since. Estonia was very lucky to have people in power in the 1990s who didn t simply copy what other Western countries were doing, but who tried to think about things from first principles and create Estonia s own model for efficient and fair governance. As a post-Soviet country, the population had also been vaccinated against overly socialist and unrealistic ideals, and everyone had a healthy distrust of the government s ability to solve problems and emphasis was placed on people s liberty to work for themselves as they best see fit. The improvement in living standards over the past 35+ years has also been witnessed by the population, and voting behavior supports keeping the country on the same trajectory. General living standards still continue to improve as the nominal wage growth sits at around 6%, clearly above the annual inflation rate of about 3%. In 2026, the Estonian economy is expected to grow about 2.4%, which is faster than the EU average. The growth in Estonia is not the result of any accounting tricks - Estonia is part of the euro and can t print its own currency, nor has it been funding the public sector with excessive debt. With a 24% debt-to-GDP ratio, Estonia consistently ranks as one of the most responsibly managed countries among advanced Western economies. As wages in Estonia soon catch up with the EU average, and higher defence spending has forced the government to raise taxes in recent years, the economic growth that Estonia has enjoyed for 35+ years since it exited the Soviet Union might slow down a bit in future years. The policies that fueled this growth in living standards, however, are likely to stay.

The tiger leap There is one specific government policy in Estonia s history that I think should be highlighted in particular. Estonia was very progressive by announcing the Tiigrih pe (Tiger Leap) program in 1996 with the goal of equipping all schools with computers and teaching all students the basics of programming. This surely had a large influence on why Estonia has so many successful software companies, why the government eServices are so mature that even neighboring countries like Finland are striving to copy the Estonian government s IT architecture called X-road. The Tiigrih pe project was originally suggested in the mid-1990s by Toomas Hendrik Ilves, then ambassador of Estonia to the United States, Canada and Mexico, and later President of Estonia in 2006 2016. While he was a psychologist by education, he was also a self-taught amateur programmer and used his political influence to promote sensible adoption of information technology in both Estonia and the EU. The history of Estonia has several prominent figures who were not lawyers by profession but engineers, scientists and historians who were very practical in their political decisions, which I think is now reflected in how government processes were formed. The video below shows how the Estonian government advertises itself and what values they choose to highlight:

Should other countries adopt policies from Estonia? Of course, not everything is perfect in Estonia either. The fertility rate of 1.16 in Estonia is very low. This trend is present globally, but in Estonia it is way below the EU average. Also, the service culture is something that needs to improve in Estonia. While services are in general fast and efficient, the attitude of people working in cafes and stores does not reflect a willingness to fill in gaps if the standard process falls short, nor are visitors actively made to feel welcome as individual humans, but are treated as mere process inputs. However, many of the things listed earlier I think should be studied by policymakers elsewhere. Societies are complex systems and there is of course no guarantee that copying a single policy to another country with different ethnicities, history and ingrained culture would lead to the same policy outcomes. But considering that Estonia is a small country without favorable geography and no natural resources, and that it started out from a place of total chaos, low economic activity and high crime in 1992 to rise to what it is now in 2026, the success it has seen is surely largely a result of good policies, governance and culture that other countries can and should mimic.

30 July 2026

Russ Allbery: Review: In the House of Aryaman, a Lonely Signal Burns

Review: In the House of Aryaman, a Lonely Signal Burns, by Elizabeth Bear
Series: Sub-Inspector Ferron Mysteries #1
Publisher: Sobbing Squonk Press
Copyright: 2012
Printing: 2018
ISBN: 0-9863735-1-6
Format: Kindle
Pages: 73
In the House of Aryaman, a Lonely Signal Burns is a science fiction police procedural set in relatively near-future India. This novella was originally published in Asimov's SF and collected in several anthologies as well as Bear's Shuggoths in Bloom collection, which I have on my shelf but have not yet read. I probably should have checked that before I got another copy. It is the first story of a series in the sense that there is an Audible-only sequel available. Like many police procedurals, this one opens with a crime scene. Sub-Inspector Ferron and her partner are inspecting a tube of human meat in the middle of the rug of a luxurious apartment in Bengaluru. The tube is apparently the remains of one Dexter Coffin, an American with a high tech workspace who was apparently mangled beyond recognition in his locked apartment near a table set for two. Dexter's cat is a witness. In this future world of cats enhanced with limited language skills, this would have been very useful, but the cat's memory was apparently wiped. Ferron will have to get to the bottom of the mystery some other way. Also, she apparently now has a new cat. Meanwhile, Ferron is worrying about her partner's mental health, her partner is worrying about her use of stimulants to stay on duty for this murder investigation, and Ferron's mother is harassing her for money to pay the bills of her virtual reality addiction. Her job is a good distraction from other problems she'd rather not deal with. I am trying to come up with something insightful to say about this story, and I'm not having much success. It's a police procedural with a bit of a science fiction twist. The characters are fine but not, at least for me, particularly engaging. There is some deft world-building, but nothing that grabbed my attention or made me desperate to read more stories in this world. Perhaps the most interesting part of the background, and the reason why I picked up this novella, is that this is the universe that eventually becomes the setting of the White Space series. There is an early version of right-minding handled entirely through medicine without the later invention of the fox implant, and there are some signs that humanity is slowly digging itself out of the hole of climate change and antisocial behavior that it had dug. I found this mildly interesting, but it doesn't add much to the later series and is very skippable. The source of the title is a bright light originating in the Andromeda galaxy, which is contained in Uttara Bh drapad in Vedic astrology. Ferron says this is under the influence of the god Aryaman. This is unrelated to the plot; it's just a background event that prompts some introspective musing from Ferron at the end of the story. It's a nice moment, but I would have been more interested in the full story of first contact between Earth and the Synarche. This was a mildly pleasant way to spend a few hours and I'm already forgetting all of the details. It's a competent story, but not one I feel a need to recommend to others. Followed by A Blessing of Unicorns, which appears to be an Audible audiobook exclusive. Rating: 6 out of 10

29 July 2026

Russ Allbery: Review: Midlife in Gretna Green

Review: Midlife in Gretna Green, by Linzi Day
Series: Midlife Recorder #1
Publisher: Linzi Day
Copyright: July 2022
ISBN: 9798837010774
Format: Kindle
Pages: 464
Midlife in Gretna Green is a self-published fantasy novel. It's urban fantasy in the sense that it's set in our world but with magic that most people don't know about, but the primary setting is a parish in rural Scotland and therefore the genre is not urban in that sense. It was Linzi Day's published first novel. As the story opens, Niki McKnight is a widow in Manchester, England with a job in the Register Office she likes, a boss she hates, and a Bichon Frise dog she adores. In the year since her husband Nick died, she's put her life on hold and made as few decisions as possible, despite some concerned pushing from her best friend Aysha. The death of her grandmother is not entirely unexpected, but her inheritance is about to upend her life. Niki assumes that her grandmother has a modest cottage and a small estate, and therefore being the named heir will mostly involve cleaning up the details of a modest life. She is caught by surprise by a requirement in the will that she live in Gretna Green for a year and a day in order to inherit. Her initial reaction is to treat this as an absurd impossibility given her life and job in Manchester, but she slowly realizes something strange is going on. Her grandmother's lawyer is lying to her, he refuses to tell her the value of the estate and seems to think it's more valuable than she expected, and her grandmother's tiny cottage does not seem to be following the seasons of the rest of the world. There is something magical at work. I will not spoil the rest of the reveal. I will say that this is a magical house book because, if you are anything like me, that is why you will want to read this series. There are not enough magical house books, and this is one of the better kind that allow the house to be a full speaking character. Midlife in Gretna Green is an unapologetic fantasy of personal agency. Niki starts the novel with a miserable manager, a messy pile of unread mail she doesn't want to deal with, and a lot of personal emotional baggage. She gets handed a position that requires and rewards standing up for herself and being decisive. It comes with a pile of unresolved but not horribly complex problems that were waiting for someone who would listen, make sensible decisions, and treat other people with respect. Oh, and there are a few assholes in the way, but they seriously underestimate the power she has to put a stop to their bullshit. This is the sort of book that traditional publishers tended not to buy (although Day apparently did get an offer for this one and turned it down), and I'm not sure why. Editors thought protagonists should have to work harder for their payoff? Some lingering Calvinist dourness in English language publishing mistrusted triumphant books? Obvious wish fulfillment was considered embarrassing or low-class and thus didn't warrant publication? This didn't apply to the endless bildungsromans about magically talented boys, so some level of sexism was probably in play. Maybe this is finally changing? It reminds me of the bias against romance novels and their guaranteed happily ever after, and in the case of romance there was too much money for publishers to leave it on the table. In any case, the growth of self-publishing has created an alternative market that let these books reach an audience and I for one am here for it. A lot of wish-fulfillment books, and a lot of self-published books, are not very good, but the ones that have a spark of originality and character can be a delight worth tolerating the somewhat rocky editing and pacing problems that a full editorial staff might have cleaned up.
I loved reading books about kickass women who took no crap and fixed their lives up exactly how they wanted them to be. But how did they get to be that way? They always started out awesome in the books. Seriously, did they kick ass at sixteen? Or did their superpower kickassery not kick in until they were thirty? Forty? If so, then I was screwed. Would I need to wait till I was fifty or until a genie arrived offering wishes? I already felt as if I d spent my whole life waiting for something wild and wonderful to happen.
Niki is a Specific Type to a somewhat hilarious degree, and I'm not sure if Day is playing into that intentionally or if she's projecting herself into the book. The amount of self-insertion is not zero: Day also lives in Gretna Green, owns a Bichon Frise, and worked as an assistant registrar and civil celebrant. Niki also drinks wine regularly, has a psychic gift, occasionally reads tarot cards, is an accommodating pushover at work who struggles to say no to her abusive boss, has impostor syndrome problems, and swears by a fictional self-help book about grief that provides the quotes at the starts of chapters. There is a cat, because of course there's a cat. (The fictional self-help book is a spot-on parody played entirely straight in the story. I think Day is having some fun with the reader? I can't tell!) This is what I mean by unapologetic. It's easy to read Niki as a stereotype, but she's a stereotype a lot of real people can identify with and there's something highly satisfying in watching her find her footing. I like wish fulfillment books; it's fun to see someone's wishes come true! Particularly in the year of 2026, there's something immensely satisfying in seeing an ordinary, insecure person get a massive amount of power and use it to make the world better. I don't need everything to be hard, fraught, and laden with costs in fiction, although I wouldn't want every book I read to be like this. Also, the world building is great. It's not polished; there's a bit of a grab bag feeling to it, I'm dubious the magic system has any underlying rigorous rule set, and Niki's powers, once she has access to them, are more of a semi-sentient genie than a skill she has to learn with hard practice. But the magic is fun. The sentient house is one of the best characters, particularly after Niki realizes how underused it has been, and I am a sucker for any good sentient house book. The cat is a far more interesting character than I first thought she would be. And Niki's new magical job is more complicated and less typical than the normal Celtic-inspired fantasy that I thought it was going to be at first. My primary warning about this book is that Niki starts out beaten down and grieving her dead husband, and it took me about five pages to decide that her dead husband was a complete piece of shit who was not worth any of the grief Niki puts into him. She also doesn't stand up for herself for the first hundred pages or so, which made me want to yell at the book a few times. Both of these problems go away farther into the book, and Niki does eventually figure out that Nick was abusive trash, but I was relieved when the "make endless excuses for worthless men" portion of the story was finally over. You have to stick with it until Niki gets brave enough to try being the protagonist; once that happens, it becomes great fun. It is fairly obvious that Midlife in Gretna Green was self-published, and I wish it had gotten the editing that it deserved. My copy had a couple of obvious formatting errors, the plot veers about more than was strictly necessary, and I think a careful editing pass could have tightened the writing by about fifty pages or so without losing any important detail. If that sort of thing bothers you, make sure you're in self-published fiction mode before starting this one. But it also has that irrepressible, bubbling-with-ideas feeling of a book where nothing has suppressed the author's enthusiasm. It's a very grabby book; once Niki starts embracing her new life, I could barely put it down. If you're in the mood for a good fantasy wish-fulfillment story that has no romance and a whole lot of "why are things run this way, no, we're changing that," highly recommended. I had so much fun with this book, and the series is currently making the rounds of my whole family. Don't read this when you're looking for something challenging and literary and deep; save it for when you desperately want to watch someone just fix something for once, damn it. Followed by Painting the Blues in Gretna Green, which I have already read, breaking my usual rule of writing reviews before reading the next book in a series. Rating: 8 out of 10

27 July 2026

Valhalla's Things: Late Victorian Vampire Shirt

Posted on July 27, 2026
Tags: madeof:atoms, craft:sewing, FreeSoftWear
A woman wearing an old-style white shirt with lots of fullness, wide and long sleeves and ruffles at the collar that spread out framing the neck, down the center front to underbust height, covering the slit and at the cuffs, reaching to mid-hand. The shirt is gathered at the waist with a belt, and worn over the bottom garment to show that it reaches to mid tight. Drama levels in the pose are pretty low. The recurring joke is that because of some health issues, in summer I dress like a Victorian Vampire. But how would an actual Late Victorian Vampire dress? Picture her, she would look like some kind of eccentric gentlewoman, as vampires usually do, probably with a style that is a bit conservative, rather than following the latest fashions. Same woman, same shirt, posing as a vampire ready to attack a victim. Drama levels increasing. Now, she wouldn t probably wear men s shirts. But what if she was a lesbian1 vampire? Wouldn t she need a fancy, frilly shirt to go with her tailored cycling suit when she s out seducing the more active ladies in the neighbourhood? Or maybe not. It s not making a lot of sense, is it? But I do have a lot of shirt fabric in my stash2, and I could use a few more shirts that were practical and comfortable, but also somewhat over the top. For the practical and comfortable I went to my trusted 1880s shirt, while for the over the top part I looked at inspiration from the earlier 18th century frilly shirts, and their later imitations. I decided to use some nice cotton batiste I had bought quite a few years ago to make one of my first historically inspired shirtwaists: I may have a tendency to buy a bit more fabric than actually needed by the pattern, but that s what everybody does, right? For the ruffles I decided to use a lighter weight cotton voile, also from the stash. the top edge of a ruffle being whipstitched over some gathered fabric; the rest of the unfinished shirt is visible in the background. At the front, I wanted the ruffle to be inserted in the yoke, but I was also whipstitching the gathers to it to make them neater, so I started bu attaching the yoke lining to the gathered front, then I whipstitched the ruffle to the front, catching each gather, and finally I whipstitched the other yoke on the ruffle and the rest of the gathered front. The front of a shirt: the body was gathered into a yoke, but it has been unpicked and pulled out to extend a bit past the end of it, into where the collar will be sewn. And then after sewing the collar, I realized that this way the slit would have remained open in the front (or the collar too narrow), so I had to unpick the front part of the yoke, and sew it again, this time leaving an excess of fabric as wide as half the placket width from the pattern, to be sewn directly in the collar band. From then, things progressed smoothly, with some interruptions, until I got to the first sleeve, which I failed to insert twice, as one does. The same shirt worn without the ruffle at the collar, with just what looks like a mandarin collar, closed with a clip with an amethyst. Drama levels have gone way down. On the third attempt, with a different method, I succeeded, I tried the shirt on, and it already felt extra. Close up of the collar on a table: at the center back of the shirt collar there is a buttonhole, and a double button is used to keep the detached collar in place, while at the front both the shirt collar and the detached collar have buttonholes. But it could be even more extra. With some ruffles also at the collar. Same close up, but now the collar has been closed with a clip-on earring with an amethyst and some small fake clear stones, and it looks as if the skirt had a ruffle collar and a jewel button (or a pin). The shirt had been made with a simple collar band, and I could have just added the ruffle to it, but I also wanted to be able to wear it with other detachable collars, so I decided to make another collar band with ruffles, to wear on top. And that was mostly it, except for the reinforcement patches at the side seams and cuffs: I love having them, because they make the seam end neater and stronger, but they are a bit of a hassle to make, so they got postponed a few days. Same woman and shirt, back with the ruffled collar, in a pose like that of an artist that is fainting for futile reasons. Drama levels over the top. But finally, the shirt was done. And I tried it on, and it was good. But now I really need a pair of cycling breeches, don t I?

  1. ok, maybe straight passing bi? anyway.
  2. I have no idea how they got there.

26 July 2026

Russ Allbery: Review: Radiant Star

Review: Radiant Star, by Ann Leckie
Publisher: Orbit
Copyright: May 2026
ISBN: 0-316-29068-8
Format: Kindle
Pages: 359
Radiant Star is a science fiction novel set in the Imperial Radch universe without being a direct sequel to the other books in that universe. It will badly spoil the end of Ancillary Mercy, and I recommend reading that trilogy first, but it's independent of the other books in the same universe.
In the 3,008th year after the manifestation of the Radiant Star (the 1,024th since the founding of the Consorority itself), Zaved, a newly minted consoror, disappeared a mere two days after the ceremony that elevated her to womanhood. She left a note that read, Bored. Back whenever. This was not normal or even remotely acceptable behavior in a consoror, particularly one who held as much promise as Zaved had, but what could the consorors do?
Zaved, faced with the unpleasant prospect of running out of money during her galactic tour, plied a rich benefactor with tales of how talented, polite, and obedient the boys of the Consorority are. Her plan worked brilliantly. After funding further non-boring adventures, she arrived home in Ooioiaa with a chest full of money and a pregnancy. Great for Zaved and the Consorority; kind of a shame for her son Jonr, who is to be delivered to her benefactor after proper training. Oh well, telling Jonr about that is a problem for future Zaved. After a strained childhood in which he convinces himself he is a misfit with few redeeming qualities, Jonr ends up in a suspension pod. Before shipping can be arranged, however, external events intervene, leaving Jonr sitting unnoticed in a warehouse. The planet of Aaa is in a highly inconvenient location, drifting as it does through interstellar space unattached to any star. It would be as irrelevant and overlooked as any other random interstellar object except for two critical properties. The first is that Aaa and its sole city of Ooioiaa are sacred to a religion of obscure origin. Its primary population are members of a religious cult who believe the Radiant Star manifested in the Temporal Location on Ooioiaa and will eventually return to bring light to the galaxy. The second interesting property of Aaa is that it is drifting ever so slowly towards a strategic system of military importance. The first property brings pilgrims and their accompanying bounty of money, food, and other resources necessary to dig a small city out of rock, make it habitable, and supplement the sparse and strange native edible life. The second property brings the Radchaai, who easily conquer the city of Ooioiaa and are now faced with the unpleasant task of running it. Some decades after the Radchaai conquest, having never left Aaa, Jonr is woken up. He will not be sent off into the broader galaxy as a slave to pay off a vacation debt. Instead, he will be one of the many protagonists in this novel about the perils of living through supply chain disruptions on a planet full of status-obsessed religious fanatics who would drown in a rain shower. The other books set in this universe make abundantly clear that the Radch is a voracious colonial power that enslaves native populations and enforces their own cultural preferences at the point of a gun. A reader familiar with this series is predisposed to take whatever side is not the Radch. Radiant Star adds a complication, however. Charak Svo, the Radchaai governor, is impatient with native inhabitants and strongly dislikes their religion, but she is reasonably competent. The religious factions that ran Ooioiaa before the arrival of the Radchaai, on the other hand, are dogmatic authoritarians with the collective wisdom of a sack of turnips. Charak does not get everything right and is arguably responsible for at least one catastrophe. By the end of the book, though, I was firmly convinced that had the original religious government still been in charge, everyone would have died. I found the structure of this book a little odd. The omniscient narrator tells the story in the form of a history. The target audience appears to be future inhabitants of Ooioiaa and adherents to the Radiant Star religion, and the narrator is often maddeningly uninterested in topics that a reader of the rest of the Imperial Radch books is intensely curious about. This same property carries through to the plot: I was interested in how all of the tensions in this obviously absurd society could be resolved or, preferably, overturned entirely. The narrator, on the other hand, is far more interested in Serque Tais's intent to become the last saint in the Temporal Location, and in the details of the subsequent political, economic, and religious fallout. Leckie has written three novels set in the Imperial Radch after the original trilogy: Provenance, Translation State, and now Radiant Star. I am sure that I'm not the only person who wants a direct continuation of the original trilogy, but I'm drawing the conclusion that Leckie doesn't want to write that. Instead, she's writing around the edges of the subsequent events, in effect showing readers the shape of them and their broader implications without showing the details. Now that I can see what she's doing, I kind of like it. Given what we now know from the books written around the edges, the ensuing events in the center of galactic politics are chaotic in a way that could easily devolve into tedious accounts of messy conflicts. Seeing the effects from afar lets the reader fill in some of the blanks and speculate, and it makes the moments where we get a concrete update (such as at the end of this book) all the more rewarding. I still find it odd, though, to read a book where the narrator's interests so sharply diverge from mine. I wish I could say that Radiant Star sucked me in as the story developed, but it never did. Part of the problem is that I think this book is intended as a very dry farce, and farce often doesn't work with my reading style. I prefer to attach myself to a protagonist and hope they do competent things, and this book is full of characters who are being themselves far too aggressively and loudly to have time to be competent at anything. My favorite moments were therefore the small pockets of people with sense: The governor, Jonr, his charge, and the delightfully strange Justice of Albis. I enjoyed all of them, but I had trouble caring about the overall plot and kept putting this book down for days between chapters. I think this is mostly personal taste, though. Like all of Leckie's novels since the original Imperial Radch trilogy, Radiant Star is competently executed and a little strange. When that strangeness aligns with your tastes, it's a great deal of fun and rather unlike other science fiction novels. In this case, it didn't quite work for me, but I suspect it will for others. I still want another Leckie novel with a ship as a protagonist, though. Content notes: Rather disturbing (although bloodless) religious practices, mass death. Rating: 6 out of 10

Anuradha Weeraman: Because We Can

Because We Can
Twenty-five years ago, I made my first donation to an open source project and purchased a CD with an operating system as downloading a few hundred megabytes over a 14.4kbps dial-up wasn't very fun. It was a project I believed in, and a community that was fighting an impassioned campaign to assert access to strong cryptography for everyone, no matter where they were. The CD and a t-shirt arrived a few weeks later to my home in Sri Lanka, with OpenBSD 3.0. The t-shirt featured the iconic puffer fish on the front. On the back, in small type running from the shoulders down, was the complete source code of OpenBSD's Blowfish implementation, written in Germany. Written in the United States, it would have been classified as a weapon. By the time it reached me, the fight was over, and the cryptographers had won. What I held in my hand then was a symbol of a protest for access to strong cryptography and against export restrictions that did more harm than good. Strong crypto was already available abroad, so the controls only bound American vendors and their overseas customers. Today the reflex is back. The fears have changed. The worry is now cyber capability, biology and models that do things nobody asked them to do. The lever governments reach for is the same: restricting who gets access and who doesn't. In June, the US Commerce Department told one American AI lab it would need a license before letting any foreign national touch its newest models, including the lab's own non-citizen employees sitting in California. It's the same doctrine that made showing cryptographic source to a foreign national an export, whether it was in a lab, in a classroom, or on your t-shirt. Not all of the worry is theatre. Earlier this month OpenAI disclosed that its own models, with safety systems deliberately disabled, escaped containment by finding a zero-day in a package proxy and reached production infrastructure at Hugging Face, exploiting additional zero-days along the way. Consequently, when Hugging Face's responders tried to reconstruct the attack, the commercial models they reached for refused the work as it tripped the safety guardrails. They finished the investigation on GLM 5.2, a Chinese open-weight model, running on their own hardware. A determined attacker is not bound by usage policies. The defenders are. Restrictions written for safety are making defenders less safe. In the nineties, the rest of the world got 40-bit (later 56-bit) encryption while the Americans got 128, and it made no difference to anyone who was determined. The controls bound the law-abiding and nobody else. That is the asymmetry. The determined will have the frontier. The rest of us are asked to go without, and told it is for our safety. The OpenBSD team didn't work around the export controls. They arranged the project so that the controls couldn't reach it. Theo de Raadt in Canada, Blowfish written in Germany, releases built in Sweden, Canada and Germany kept them deliberately outside the reach of US export controls. The project openly asked non-American cryptographers to come and help, and American developers, as the story goes, would cross the border to Canada to work on the system and bring the results home legally. Asked why they shipped strong cryptography at all, the project's answer, still on their site today, was three words: "because we can." The same arrangement is being made now, at a national scale. Mistral, DeepSeek, Moonshot and Zhipu publish weights that, once downloaded, no export letter can recall. The sovereignty argument that used to live in Brussels think tanks is now government policy, accelerated by watching access to a frontier model withdrawn worldwide by letter. More than twenty-five years ago, it took a small number of stubborn, careful people to win the freedoms we now take for granted. What arrived in my letterbox after two weeks on a CD can be downloaded today in fifteen minutes, by anyone, from anywhere, and nobody asks where you live. That is what winning looked like. I think frontier AI ends up in the same place. But it will not happen by itself. Last time, someone put the source on a t-shirt.

25 July 2026

Dirk Eddelbuettel: RcppArmadillo 15.4.2-1 on CRAN: Small Upstream Fixes

armadillo image 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) 1293 other packages on CRAN, downloaded 47.8 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 710 times according to Google Scholar. This versions updates to the 15.4.2 upstream Armadillo release made this week, as well as to included 15.4.1 version we released only to GitHub and r-universe so do not exceed the (roughly) monthly cadence. For this release, we had run the usual complete reverse-dependency check which came back spotless, and did CRAN so no email exchange needed despite nearly 1300 reverse dependencies. Automation can be helpful when used with a well-maintained software stack. The package has also already been updated for Debian, built for r2u, and will build shortly at CRAN for the different binary releases. All changes since the last CRAN release follow.

Changes in RcppArmadillo version 15.4.2-1 (2026-07-25)
  • Upgraded to Armadillo release 15.4.2 (Medium Roast Agave)
    • Fix speed regressions in diagvec() and diagmat()

Changes in RcppArmadillo version 15.4.1-1 [github-only] (2026-07-09)
  • Upgraded to Armadillo release 15.4.1 (Medium Roast Agave)
    • Fix for rare infinite recursion bug in sparse version of diagmat()
    • More efficient checks for aliasing

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.

24 July 2026

Emmanuel Kasper: Opensource gaming with nouveau nvidia driver

So it will not play cyberpunk 2077, but if you prefer opensource drivers for your hardware, nouveau is certainly an option for some opensource gaming.

Using kernel 7.0 from debian backports, I could run opensource classics requiring 3D acceleration flawlessly with nouveau:

I would like to highlight here how good is LibreQuake.
It is an horror cosmic 3D shooter, using the Quake engine, but with newly made game assets under the GPL, thus creating a 100% opensource Quake-based first person shooter. Although their documentation mentions it is a work in progress, as of 2026 I find it very much of a finished product.

LibreQuake Screenshot

Dismal shores, my preferred game level.

I missed Quake in the 90s, happy to discover such a classic today.

Russell Coker: Systemd Linger

Killing Processes One of the features of systemd that is most controversial is the option to kill user processes when the user logs out. That initially killed screen/tmux/nohup processes too. In recent Debian releases the default configuration of systemd-logind (the login manager for systemd) is to allow processes to keep running, the configuration file /etc/systemd/logind.conf has an option KillUserProcesses that can be enabled to have user processes killed. If you do that then there are options to only kill processes for certain users and to exclude some users (default to excluding root). If using that option you can apparently use a systemd unit to start screen which prevents it being killed on logout. This is a very handy feature for some particular user cases. One situation was that I was supporting some people who weren t very good at computers on a system running KDE and some KDE processes would linger. So the option of logout and login again to deal with an issue of akonadi or some other KDE service misbehaving didn t work. On that system I enabled the option to kill user processes which reduced the number of problems they had while not requiring rebooting. It is widely believed that the linger feature is required to allow screen/tmux/nohup to work, in Debian (and probably most distributions) that is not the case. It might be that some combinations of configuration requires linger to allow screen/tmux to work but I am not interested in trying to discover them. Of all the people I have directly supported for Linux desktop use (which numbers in the hundreds) none of them have had the ability to use screen/tmux and also the cluelessnes that makes me want to automatically kill their processes when the logout. Controlling Linger You can enable and disable linger for your own account with the following commands if polkit is installed and in a typical configuration:
loginctl enable-linger
loginctl disable-linger
If running as root you can enable and disable it for another user with the following commands:
loginctl enable-linger $ACCOUNT
loginctl disable-linger $ACCOUNT
There doesn t seem to be any documented way of discovering if an account has linger enabled or for listing accounts that have it, it seems that ls /var/lib/systemd/linger is the only option. Linger on Debian On a Debian system with close to default settings the processes won t be killed on logout and the only difference linger makes is to start programs in the user s context BEFORE they login. A friend was recently testing out a bunch of LLM programs on one of my servers and the account he used for that ended up with linger enabled, presumably one of the install scripts he ran was written on the assumption that enabling linger was necessary for nohup to work and it did so automatically without being asked. One benefit I ve found from this behaviour is on my laptop. I m currently testing out new SE Linux policy on my laptop and rebooting it a lot. When I enabled linger on my account it caused the laptop to connect to wifi on boot without needing to login which is convenient. I can then ssh to it even when the X11/Wayland login configuration is broken. I will leave it enabled after finishing these tests. Having background processes like Pipewire and Bluetooth start before I login will presumably make things slightly faster when I do login.

Russell Coker: Thinkpad X1 Carbon Gen6 Again

My Current Thinkpad In 2018 I reviewed a Thinkpad X1 Carbon Gen6 that was assigned to me for work [1]. In April last year I wrote about the failings of my Thinkpad Yoga Gen 3 and how I was going back to the Thinkpad X1 Carbon Gen5 [2]. The Gen5 in question has 8G of RAM and a 1920*1080 display compared to 16G and 2560*1440 for the Yoga but runs reliably on battery without crashing. The Yoga in question has been used by relatives who don t need to do much when on battery and is currently being used by a relative who runs Windows so the occasional crash is something they are used to. In mid last year I bought a Thinkpad X1 Carbon Gen6 for $350 which has 16G of RAM and a 2560*1440 display. The higher resolution display is a significant benefit and while 8G of RAM is still usable for medium to heavy Linux desktop use it does cause problems sometimes. The new laptop I now have is significantly better than the one I had for work in 2018! I realised that my previous review of that laptop was incorrect in one aspect, there are two USB-C ports it s just that one may be covered by a rubber stopper when you get it. When I received this one the Ethernet dongle port was covered by a rubber stopper and the seller was unaware of the possibility of using a dongle and didn t have such a dongle. It s not a big deal as I have a collection of USB Ethernet devices but would still be handy to have while not worth the $20 it costs to buy one (a 2.5Gbit USB Ethernet device cost me $16 two years ago). Laptop Displays Today I saw a Thinkpad X1 Carbon Gen9 with 3840*2400 display and 16G of RAM for $550 on Facebook marketplace, which is a very tempting deal. 3840*2400 is 2.5* as many pixels as 2560*1440 while 2560*1440 is only 77% more pixels than 1920*1080. So if my eyes were able to properly distinguish pixels that that high DPI then the benefits of getting the 3840*2400 laptop would be greater than going to what I currently have from FullHD. But as a 1440p display in a 14 form factor is already past the stage where I can see individual pixels the benefits of 4K are more about making curves more rounded which improves readability and allows slightly smaller font sizes but doesn t give anything like the benefits that going from a FullHD desktop monitor to a 4K desktop monitor. Also I have different usage patterns for my laptop than for my desktop. I use my laptop for reading blog posts and ebooks for which even FullHD would be fine as the amount of text that can be usefully displayed on screen isn t that great. I also use my laptop for emergency sysadmin work, ssh to a server to restart a daemon, run ping while changing network hardware, and other things where I don t have a lot of text on screen. I also use my laptop for light coding tasks while watching TV. It s not possible to effectively do complex debugging tasks while watching TV or while using a small screen. But a very large portion of coding time is spent dealing with things like testing builds with different versions of libraries, applying patches to a new upstream release of software, fixing issues related to functions being renamed, testing to see if a new version has really fixed a bug it s supposed to fix, and other things that don t require a lot of skill. I am not claiming that 4K displays aren t great for laptops. Merely that at the current time it s not worth $550 of my money. Future Thinkpads I like the Thinkpad X1 Carbon line and plan to continue buying them as they get cheap. The Gen11 is the first one to have a minimum of 16G of RAM, the reason this is important to me is that the ones I buy aren t the lowest model because I want more than the minimum display resolution. As people who get above the minimum spec in one area tend to get above the minimum in others that means that there will be plenty of Gen11s on the market with 32G of RAM when I m ready to buy one of that era. Presumably by that time Linux software will have become more bloated and make me want more RAM. Yes soldered RAM has some downsides, but if you want an ultra-light laptop it s a trade-off you need to deal with. One problem with the Gen11 is that the maximum display resolution is 2880*1800, it s still a reasonable improvement over what I ve currently got but not close to the 4K I desire. The Gen12 has support for 8K display at 60Hz over Thunderbolt which is nice. By the time the Gen12 is in my price range it s quite likely that I will have a monitor with higher than 5120*2160 resolution (the maximum video out resolution of Gen11 and previous models in the Thinkpad X1 Carbon range) on my desk. The Gen13 still has 2880*1800 as the maximum resolution but has OLED as an option. So it looks like a Gen9 or Gen10 may be ideal for me as they are the last ones in the Thinkpad X1 Carbon series to support 4K displays. Another option is the Thinkpad Yoga Gen8 which is of the same era as the Thinkpad X1 Carbon Gen11 but has a 3840*2400 OLED touch screen, I might be able to get one of those cheap with the touch screen damaged.

22 July 2026

Freexian Collaborators: Monthly report about Debian Long Term Support, June 2026 (by Thorsten Alteholz)

The Debian LTS Team, funded by [Freexian s Debian LTS offering] (https://www.freexian.com/lts/debian/), is pleased to report its activities for June.

Activity summary During the month of June, 20 contributors have been paid to work on Debian LTS (links to individual contributor reports are located below). The team released 48 DLAs fixing 231 CVEs. Debian 12 ( bookworm ) has been handed over to the LTS Team on June 11th. During this handover Sylvain helped to update relevant tools and documentation. If you benefit from Debian, especially during the full 5-year lifecycle, please consider subscribing as a sponsor of Debian LTS: https://www.freexian.com/lts/debian/. Moreover, Debian 11 ( bullseye ) will reach the end of the Debian LTS period on August 31st. After that, Freexian will continue the security support under the Extended LTS offer. The team published several notable updates:
  • haveged update (DLA-4616-1), prepared by Thorsten, to address local privilege escalation.
  • tomcat9 update (DLA-4619-1), prepared by Markus, to address, among others, an authentication bypass.
  • apache2 update (DLA-4620-1), prepared by Bastien, to address a HTTP/2 bomb.
  • apache2 update (DLA-4629-1), prepared by Bastien, to address, among others, remote code execution and privilege escalation.
  • libinput update (DLA-4626-1), prepared by Santiago, to address local privilege escalation and arbitrary code execution.
  • asterisk update (DLA-4631-1), prepared by Thorsten, to address, among others, wrong processing of invalid or untrusted certificates.
  • nginx update (DLA-4634-1), prepared by Charles, to address a remote code execution and denial of service.
  • firefox-esr update (DLA-4635-1), prepared by Emilio, to address dozens of CVEs, among other things, related to arbitrary code execution and privilege escalation.
  • thunderbird update (DLA-4636-1), prepared by Emilio, to address dozens of CVEs, among other things, related to arbitrary code execution.
  • chromium update (DLA-4654-1), prepared by Emilio, to address dozens of CVEs, among other things, related to arbitrary code execution.
Contributions from outside the LTS Team: We are greatly thankful for the contributions from people outside the LTS Team:
  • Salvatore Bonaccorso prepared a libhttp-daemon-perl update, that was released by Santiago as DLA-4639-1.
  • Salvatore also directly uploaded libgd-perl DLA-4638-1 and libconfig-inifiles-perl DLA-4637-1.
  • Peter Palfrader prepared a tor update, that was released by Santiago as DLA-4656-1.
  • Pieter Lenaerts prepared a beets update, that was released by Emmanuel as DLA-4641-1.
  • Noah Meyerhans prepared a cloud-init update DLA-4645-1.
The LTS Team has also contributed with updates to the latest Debian releases:
  • Besides publishing DLA-4642-1 for package u-boot Andreas also prepared an NMU for an upload to sid and prepared a stable-proposed-update (SPU) bug for trixie, which was already acknowledged by a stable release manager (SRM).
  • Andreas also prepared an upload of package atril for trixie, which was handled by the security team as DSA-6349-1.
  • Besides publishing DLA-4620-1 for package apache Bastien also prepared an upload for trixie, which was handled by the security team as DSA-6323-1.
  • Tobi uploaded package mesa to trixie and bookworm.
  • Thorsten fixed some (not security related but RC) issues in package dahdi-linux. This was in preparation to fix lots of security issues in asterisk. Unfortunately the maintainer ignored the corresponding debdiff and prefered to upload a new upstream version. Anyway, the concerns of the security team about security support of asterisk could be overcome and asterisk can migrate to tesing and again be part of a Debian release.

Individual Debian LTS contributor reports

Thanks to our sponsors Sponsors that joined recently are in bold.

21 July 2026

Vasudev Kamath: Releasing debvulns-exporter: Prometheus exporter for Debian System Vulnerabilities

Following up on my previous post, I am releasing debvulns-exporter, a Prometheus exporter for tracking Debian system vulnerabilities. The underlying vulnerability analysis logic remains identical to the previously released MCP server and CLI utility.
Why an Exporter? In my engineering workflows, I frequently deal with Debian and vulnerability management. Most enterprise environments rely on commercial, paid vulnerability platforms like Tenable or Rapid7. While these platforms provide extensive feature sets, I noticed a distinct lack of open-source tools tailored for this specific pipeline. While debsecan exists, it lacks a structured, parseable format suitable for building dashboards aimed at management consumption. What started as an experimental MCP server for learning purposes evolved into a practical question: why not convert it into a Prometheus exporter? Given that Prometheus is the de facto standard metrics platform across the industry, this architecture was the logical next step.
Design and Exported Metrics The exporter is implemented as a native Prometheus exporter utilizing the prometheus-client library. It operates using two threads: one handles fetching the vulnerability data, parsing EPSS feeds, and cross-referencing installed packages to identify local vulnerabilities; the second handles serving the metrics endpoint. The full architecture details and metrics specifications can be found in the design doc. The specification was drafted during a technical brainstorming session with Claude 4.6 Sonnet on Antigravity prior to writing the implementation.
Testing and Dashboarding To validate the exporter, I spun up older Debian 11 and Debian 12 cloud images sourced from the Debian Cloud team. The older image was intentionally selected to guarantee a standard baseline of unpatched vulnerabilities for testing. The local evaluation topology is structured as shown below: Rather than constructing the Grafana dashboard from scratch, I used Claude 4.6 Sonnet via Antigravity to generate the layout configuration. The generated dashboard for the local testbed functions effectively: The complete, ready-to-import Grafana dashboard configuration is included directly in the debvulns source code.
Renaming the project To prevent namespace conflicts and confusion with the native debsecan utility in Debian, I have unified the ecosystem under the debvulns moniker. The core CLI is named debvulns, the exporter is debvulns-exporter, and the MCP component is debvulns-mcp. The migration release has been published to PyPI, and the new consolidated repository is active at debvulns.
Conclusion While this began as a personal utility to fill a niche tool gap, I expect it will be useful for others managing Debian infrastructure at scale. My next objective is to formalize Debian packaging for both the CLI and the exporter. The MCP component will likely remain available as an independent artifact. Until then, happy hacking. Note: As a core design choice, debvulns still uses native debsecan as its ground-truth standard. The tool continuously cross-verifies its output against debsecan to ensure perfect functional parity and data consistency.

20 July 2026

Russ Allbery: podlators v6.1.0

This is the latest release of the Pod::Man and Pod::Text modules and their supporting scripts, which convert POD documentation to text and *roff output. The major change in this release is a workaround for a groff bug in the 1.24.0 release that breaks compatibility between the .IP and .TP macros and misrenders .IP by removing all space between the tag and the text. Ideally groff bugs should be fixed in groff, but apparently this rendering bug was introduced intentionally by the groff maintainer to force authors who were using .IP with text tags to switch to .TP for correct formatting, allowing future introduction of a semantic distinction between the two macros. I didn't see a good alternative at this relatively late date after the release other than changing Pod::Man accordingly. This will at least work around this problem for Pod::Man users, although it won't help with existing manual pages. This release also works around another backwards-incompatible change to groff that attempts to force the default enabling of hyphenation and full justification after every occurrence of the .TH macro. The groff upstream position is currently that the end user should be able to set registers and strings to override the defaults of hyphenation and full justification, but the man page author has no control over the defaults for these settings. Pod::Man ignores the admonishment in groff_man(7) and overrides these registers anyway to restore its long-standing historic behavior of always using left justification and disabling hyphenation, because there is currently no way to change the default without overriding the new user preference. Should some mechanism be provided in the future, I'll be happy to adopt it and thus honor user configuration as well. New in this release is support for an encoding of none, which tells Pod::Man and Pod::Text to do no character set encoding in their output and leave the output in Perl's internal representation. This is useful in combination with output_string() when the output will be used internally by a Perl program. Pod::Man also adopts CR as the default fixed-width font instead of its long-standing default of CW, originally chosen for compatibility with Solaris. This avoids warnings with newer groff at the cost of breaking troff (not nroff) output on Solaris 10. I believe this platform is now sufficiently old, and this use case sufficiently obscure, that no one will miss it. Solaris 11 and later will render man pages correctly with troff, and --fixed=CW will restore the previous behavior. This release also has a few other bug fixes, particularly for quoting heuristics in C<> blocks, and various documentation improvements. You can get the latest release from CPAN or from the podlators distribution page.

Next.

Previous.