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:

• Supertux (Debian package)
• SuperTux Kart (Debian package)
• LibreQuake (Flatpak with ironquake engine, Full HD and 60 fps)

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.

Dismal shores, my preferred game level.

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

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.

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.

• [1] https://etbe.coker.com.au/2018/09/11/thinkpad-x1-carbon-gen-6/
• [2] https://etbe.coker.com.au/2025/04/23/last-yoga-gen3/

The twenty-first release of the qlcal package arrivied at CRAN just now, and has been built for r2u. It comes a week after the 0.1.2 release.

qlcal delivers the calendaring parts of QuantLib. It is provided (for the R package) as a set of included files, so the package is self-contained and does not depend on an external QuantLib library (which can be demanding to build). qlcal covers over seventy country / market calendars and can compute holiday lists, its complement (i.e. business day lists) and much more. Examples are in the README at the repository, the package page, and course at the CRAN package page.

This releases includes a one-line fix we also sent upstream as a now-merged PR: one of the calendar files added in QuantLib 1.43 also needed to include the vector header file. And every compiler appears to be lenient (QuantLib itself has fourty different continuous integration jobs, we test with all builds at r-universe) apart from the CRAN macOS x86-64 machine. Sigh. This is now fixed. We also included a neat little local trick I should blog about: if the build is detected as a non-CRAN local build (simply by checking for a .git directory) then compiler flags can be updated to quieten the build. We cannot do that in the package because we would get our fingers slapped over so-called ‘non-portable compiler flags’. Sigh again. Anyway, the trick helps.

The full details from NEWS.Rd follow.

Changes in version 0.1.3 (2026-07-21)

• Add missing 'vector' header to new IslamicHolidays calendar file, also PRed upstream and merged there

• In local compilation out of git repo add additional compiler flags

Courtesy of my CRANberries, there is a diffstat report for this release. See the project page and package documentation for more details, and more examples.

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.

(no, this isn't a blog post about Joy Division songs)

Last time I wrote about Interzone, I was discussing issue #294, the first published under new management in a paperback-sized format ("JB6"). The format and presentation of the magazine was fantastic: it fit in a lot of my pockets, and was packed with 15 stories as well as the regular columns, in full colour with fantastic layouts and illustrations. Sadly there was only one more physical issue before Interzone was forced to become a digital-only publication.

IZ issues 294 and 295

I don't want to dwell on the sad necessity to move to digital. Interzone continues on, celebrating the milestone issue #300 in 2024. Subscriptions are managed via Patreon. Issue #305 just came out.

Instead I wanted to write a small bit about how I engaged with the paper magazine, and the difficulties I've had trying to engage with not just Interzone but any magazine-style publication in a digital context.

With most fiction, I read linearly: start the beginning and read to the end, in order. That works well for me with e-readers. But for magazines (and most non-fiction) I don't, I jump around: usually starting with the table of contents, I might pick a short column to start, or jump into the middle of the "book reviews" section to read about a specific book. I might skip sections entirely. I find it very difficult to read like this with an e-reader. I think this is partly because I reference the depth of the paper book or magazine, its thickness, to orient myself. But it's also partly the limitations of e-ink.

My tick-list for an issue of IZ

For print-Interzone, I used to start by inserting a small piece of paper inside the cover (the delivery slip was ideal). On this I listed the stories within and ticked them off when I read them (sometimes I double-ticked if I really liked a story). That helped me to remember, perhaps months or years later, whether I'd read all the stories or not, and which I liked. I could do something similar on some e-readers: the Remarkable for instance. But it's far from convenient to do on most e-ink devices.

Interzone digital is available as both ePUB, the most common format for e-books, and PDF. For reading on my regular Kobo e-reader, PDFs don't work very well at all. I think this is generally true of most e-readers.

Interzone was (and is) a well-designed magazine. The value of it was not just the content of the text, but the context: how the stories were presented; the accompanying art (most often colour in recent decades), but also the typesetting. ePUB doesn't specify much of that stuff exactly: it leaves that up to the client and the client's preferences. And there's a lot of advantages to that: Prefer a different font face or size? No problem. And most importantly for accessibility: If reading in ePUB makes Interzone available to more readers then that's a great thing. But sadly a lot is lost, IMHO.

IZ #305 on iPad Mini

The solution I'm trying is to read the PDF version on the iPad Mini I resurrected earlier in the year. Despite being an Internet tablet, since it's not really usable for browsing the web anymore it's strangely still a distraction-free device. In fact it's pretty much single-purpose for reading Interzone and the odd other book which benefits from being read as PDF. I can appreciate the stylistic choices made in the page-setting as they were intended; I can quickly jump around the issue without waiting for an e-ink refresh; I get full colour; and whilst it would be tiring to read for a long time on the iPad screen, for the length of articles or stories in a magazine, this isn't a problem.

It's not a solution for tracking what I've read (that version of ipadOS is too old to support clumsily scrawling on PDF pages with your fingers, at least in the Books app) but it otherwise seems to work well, so I'll see how it goes.

When you pass an AWS certification exam, sometimes it can extend the life of related lesser AWS certifications. But I could not find an illustration of exactly which ones, so here’s an up-to-date diagram:

Figure: Renewal relationships between AWS certifications.

Each arrow is a ‘renews’ relation – there’s no obligation to pass lesser exams before the harder ones, but you could also follow the arrows backwards if you want to learn easier material before sitting the more difficult exams.

I have made two important simplifications to the graph:

1. The ‘Advanced Networking – Specialty’ certification is being retired soon, so I’ve omitted it entirely. The last date to take that exam is 25th August 2026. But Specialty certs don’t renew anything else anyway.

2. I have left out transitive relationships in order to simplify the graph – so e.g. if you pass a ‘Solutions Architect – Professional’ exam, it also renews any Cloud Practitioner certificate you might hold, even if you do not currently hold the relevant Associate certificate.

You also have the option of sitting each exam again to renew of course, and there’s a new scheme to ‘maintain’ various certs via AWS Skill Builder which can extend them by one year rather than three.

DebConf26, the 27th annual Debian Developer Conference, is taking place at Santa Fe, Argentina from 20 to 25 July 2026. Debian contributors from all over the world have come together at the Facultad de Ingeniería en Ciencias Hídricas (Faculty of Engineering in Water Sciences), one of the faculties that belong to the Universidad Nacional del Litoral (National University of the Littoral), to participate and work in a conference exclusively ran by volunteers.

Today the main conference starts with around 300 expected attendants and over 80 scheduled activities, including 45-minute and 20-minute talks, Bird of a Feather ("BoF") team meetings, workshops, a job fair, as well as a variety of other events. The full schedule is updated each day, including activities planned ad-hoc by attendees over the course of the conference.

If you would like to engage remotely, you can follow the video streams available from the DebConf26 website for the events happening in the three main talk rooms: Aula Magna - FADU, Aula Magna - FBCB and Aula 0.3 - FICH accessible from the DebConf26 homepage. You can also join the conversations happening inside the talk rooms via the OFTC IRC network in the #debconf-fadu, #debconf-fbcb, and #debconf-fich3 channels. Please also join us in the #debconf channel for common discussions related to DebConf.

You can also follow the live coverage of news about DebConf26 provided by our micronews service or the @debian profile on your favorite social network.

DebConf is committed to a safe and welcoming environment for all participants. Please see our Code of Conduct page for more information on this.

Debian thanks the commitment of numerous sponsors to support DebConf26, particularly our Platinum Sponsors: Infomaniak and Proxmox.

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.

Hamming Codes

ECC RAM corrects errors that occur in memory before it gets to the CPU. The most common form of ECC is the Hamming Code [1] which when it has R redundant bits can correct single bit errors and detect double-bit errors in messages with 2^R-R-1 bits of data. For PC use that means if you want to protect 32bits of data you need R=6 and with 64bits you need R=7. The standard for DDR4 and similar RAM is 72 bits of data width on the bus and Hamming codes to correct single bit errors and detect double bit errors for 65bits of data. The computers we use have 64bits of data so that allows an extra bit that could be an extra parity, I don’t know what if anything is done with this extra bit.

RDIMM vs UDIMM

One point of confusion in such things is the difference between Registered memory AKA RDIMMs [2] and regular PC/laptop memory which is often referred to as UDIMMs. The “register” is just a buffer which due to complex issues that aren’t relevant to this post means that DIMMs can be larger and you can have more DIMMs in a system but latency may be slightly worse. It is technically quite possible to create RDIMMs without ECC (64bits wide instead of 72) but I have never seen a system that used such RAM.

I have used more than a few systems with ECC UDIMMs and I recommend avoiding them if convenient as ECC UDIMMs are expensive on the second hand market while ECC RDIMMs can get very cheap. There are servers with ECC RDIMMs that are very unsuitable for home use (such as dual-CPU 1RU servers which are very noisy) so once they are past the 5 year tax write-off period the server chassis gets sent to ewaste and the RAM goes on the second hand market, the glut of RAM without systems to use it forces the price down.

For the systems most commonly seen there are RDIMM systems with ECC and UDIMM systems without ECC.

Chipkill

If every bit in RAM was independent of every other bit then the basic Hamming code would solve most problems. However multiple bits in the same chip may be affected by the same problem, or one chip on the DIMM might entirely fail. With every RDIMM having 18 or 36 DRAM chips there are 2 or 4 bits per chip. On DIMMs with 36 DRAM chips one chip could fail and have the errors reliably detected with a Hamming code. On DIMMs with 18 DRAM chips one failed chip can’t necessarily be detected with Hamming codes. IBM trademarked the term ChipKill for ECC systems which can cope with a single DRAM chip failing [3]. This is referred to as “Advanced ECC” on Dell and HP servers which require an even number of DIMMs. If anyone knows what coding method is used for “ChipKill” type systems then please let me know.

Systems with advanced ECC also often have features like hot-spare for RAM and RAID-1 type functionality which is interesting but not something most people who read my blog will ever want to use.

DDR5

DDR5 has on-die ECC to deal with the increased error incidence from smaller and faster memory [4], this is specified as 8 bits of error correction per 128 bits of data which implies basic Hamming codes.

The on-die ECC is not a replacement for regular ECC, it’s a mitigation for new problems introduced. My experience of memory errors is that the majority of repeatable errors (where a system would get an error with Memtest86+ or an ECC error report repeatedly) were DIMM seating issues, I could unplug and reinsert the DIMM in question and then the same tests would pass. Those errors would not be affected by on-die ECC.

One thing that concerns me is the possibility of on-die ECC interacting with ECC on the motherboard and reducing it’s effectiveness. I haven’t been able to find out enough about how this works to determine if that’s the case. My concern is that an error of 3+ bits that’s corrected with a basic Hamming code might be more likely to create an error condition that “Advanced ECC” can’t fix than the original error.

Currently the best published research on the effectiveness of ECC on RAM errors is the Google paper published in 2009 which is based on DDR and DDR2 RAM [5]. So I don’t expect that we will see published research about even DDR4 ECC any time soon. I presume that Google and the other cloud providers are still doing such research and providing the information to DRAM vendors under NDA so we have to just hope that the DRAM vendors do what’s required to make things work correctly and allow us to buy products based on that research.

DDR5 EC4 vs EC8

DDR5 supports 2*32bit “subchannels” instead of just supporting 64bit words [6]. For DDR5 ECC RAM there are variants EC4 which has 36bits of data per subchannel and EC8 which has 40 bits. EC8 allows Hamming codes on each subchannel indepdendently. I haven’t found a reference on how exactly EC4 works, it could be reading 64bits at a time (not taking advantage of the subchannels) to use Hamming codes or it could have 1 parity bit for each subchannel and just assume that there’s no need to check Hamming codes unless the subchannel parity fails. EC8 allows full Hamming code checks on 32bits of data and presumably ChipKill on 64bits.

It’s widely claimed that all DDR5 RDIMMs are EC8 and all DDR5 ECC UDIMMs are EC4. A quick search on ebay turned up adverts for EC4 and EC8 RDIMMs and links to apparently reliable sites confirming that some of the RDIMMs are EC4. There are reports of EC8 UDIMMs even though I couldn’t find any advertised. This seems to mirror the situation with DDR4 where non-ECC RDIMMs are apparently available somewhere and ECC UDIMMs are something I’ve used a few times but most people have never seen.

I then searched for information on what servers support. The Dell R760 server supports both EC4 and EC8 RDIMMs but you can’t have both in the same system.

The existence of EC4 DIMMs is wrong. They shouldn’t make substandard gear, the manufacturing price difference between 72 and 80 bit wide DIMMs isn’t going to be great and the end result is some systems with inadequate specs and extra difficulty in upgrading systems with more things to check for compatibility.

Why ECC is Needed

Here’s an interesting article about Mozilla’s claim that 15% of Firefox crashes are due to RAM hardware errors [7], this seems to be based on repeatable errors and therefore won’t count errors where a bit flip happens once a day or less.

Some years ago I reported a BTRFS corruption issue on my desktop PC to the BTRFS developers and one of them stated that the corruption in question didn’t match any pattern expected from a BTRFS bug and recommended that I run Memtest86+. The memory test revealed that I was getting about one memory corruption per 5 hours so if I had used Firefox on that system any crashes probably wouldn’t have been regarded as hardware errors with RAM. Those errors caused filesystem corruption and some data loss, if I hadn’t been using BTRFS that could have gone unnoticed for years.

On another occasion I had a VM I was using for testing software I was developing that had some unexpected errors. After working on it for a day I had shared the errors with a mailing list of other developers who also spent some time investigating it. Eventually I began to suspect a hardware problem, I went on site and when I rebooted the system to run Memtest86+ it didn’t even boot as it had errors that stopped the BIOS from even working correctly. It was strange that the system was apparently working correctly and restarting the KVM VM resulted in the same errors happening in the same code and nothing else on the VM apparently having a problem. It turned out that the system had a motherboard problem that made all but one of the DIMM sockets unusable so I ended up sending it to e-waste. That wasted a day of my time and some hours of other people’s time. Presumably on other occasions developer time is wasted due to hardware errors and no-one even realises.

What Society Needs

We need ECC RAM to be more widely used. Ideally we would have some government action to force this given the ongoing cost to society in corrupted data and lost time due to RAM hardware errors. I think that at minimum we need sufficient taxes on non-ECC RAM (and EC4 RAM for DDR5) to make it more expensive when bought new than ECC RAM.

We need to have greater knowledge of the benefits of ECC RAM among computer experts, people need to recommend that computers be purchased with ECC RAM whenever possible and that systems which can’t have ECC RAM (laptops and phones) shouldn’t be used for storing important data.

We need to avoid silly things like having so many variants of RAM to confuse people and make it needlessly difficult to get ECC RAM working.

• [1] https://en.wikipedia.org/wiki/Hamming_code
• [2] https://en.wikipedia.org/wiki/Registered_memory
• [3] https://en.wikipedia.org/wiki/Chipkill
• [4] https://tinyurl.com/2aj7oztw
• [5] https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
• [6] https://en.wikipedia.org/wiki/DDR5_SDRAM#Subchannels
• [7] https://tinyurl.com/yv4of7hz

DebConf26, the 27th edition of the Debian conference is taking place at the Facultad de Ingeniería en Ciencias Hídricas of the Universidad Nacional del Litoral, in Santa Fe, Argentina. We appreciate the organizers for their hard work, and hope this event will be highly beneficial for those who attend in person as well as online.

This event would not be possible without the help from our generous sponsors. We would like to warmly welcome the sponsors of DebConf26, and introduce them to you.

We have two Platinum sponsors.

• Our first Platinum sponsor is Proxmox. Proxmox develops powerful, yet easy-to-use open-source server solutions. The comprehensive open-source ecosystem is designed to manage divers IT landscapes, from single servers to large-scale distributed data centers. Our unified platform integrates server virtualization, easy backup, and rock-solid email security ensuring seamless interoperability across the entire portfolio. With the Proxmox Datacenter Manager, the ecosystem also offers a "single pane of glass" for centralized management across different locations. Since 2005, all Proxmox solutions have been built on the rock-solid Debian platform. We are proud to return to DebConf26 as a sponsor because the Debian community provides the foundation that makes our work possible. We believe in keeping IT simple, open, and under your control.

• Infomaniak is the second Platinum sponsor. Infomaniak is an independent, employee-owned Swiss technology company that designs, develops, and operates its own cloud infrastructure and digital services entirely in Switzerland. With over 300 employees — more than 70% engineers and developers — the company reinvests all profits into R&D. Its public cloud is built on OpenStack, with managed Kubernetes, Database as a Service, object storage, and sovereign AI services accessible via OpenAI- compatible APIs, all running on its own Swiss infrastructure. Infomaniak also develops a sovereign collaborative suite — messaging, email, storage, online office tools, videoconferencing, and a built-in AI assistant — developed in- house and as a privacy-respecting solution to proprietary platforms. Open source is central to how Infomaniak operates. Its latest data center (D4) runs on 100% renewable energy and uses no traditional cooling: all the heat generated by its servers is captured and fed into Geneva's district heating network, supplying up to 6,000 homes in winter and hot water year-round. The entire project has been documented and open-sourced at d4project.org.

Our Gold sponsors are:

• Freexian, Freexian specializes in Free Software with a particular focus on Debian GNU/Linux. Freexian can assist with consulting, training, technical support, packaging, or software development on projects involving use or development of Free software. All of Freexian's employees and partners are well-known contributors in the Free Software community, a choice that is integral to Freexian's business model.

• Viridien an advanced technology, digital and Earth data company that pushes the boundaries of science for a more prosperous and sustainable future. Viridien has been using Debian-based systems to power most of its HPC infrastructure and its cloud platform since 2009 and currently employs two active Debian Project Members.

Our Silver sponsors are:

• Arm: leading technology provider of processor IP, Arm powered solutions have been supporting innovation for more than 30 years and are deployed in over 280 billion chips to date.
• Pexip brings the ease of commercial video platforms to secure and sovereign environments without compromising control or performance.
• The Bern University of Applied Sciences with around 7,959 students enrolled, located in the Swiss capital.
• Ubuntu, the Operating System delivered by Canonical.
• OS-Sci, Open Source Science is a world-leading institution dedicated to teaching computer science through Free and Open Source Software (FOSS).
• gcoop, a free software development company with over 19 years of market experience, organized as a worker cooperative, promoting best practices in software development.
• Qualcomm Technologies, one of the world's leading companies in field of mobile technology, sponsors and contributes to Open Source developer communities that drive collaboration.
• Civil Infrastructure Platform, a collaborative project hosted by the Linux Foundation, establishing an open source “base layer” of industrial grade software.
• Siemens is a technology company focused on industry, infrastructure and transport.
• Collabora, a global consultancy delivering Open Source software solutions to the commercial world.
• NERDEARLA, the largest free tech event in the Spanish-speaking world.

Bronze sponsors:

• Loongson,
• credativ,
• Google,
• SpacemiT,

And finally, our Supporter level sponsors:

• Altus Metrum,
• Loongson Hobbyists Community,
• Secretaría de Tecnologías para la Gestión de la Provincia de Santa Fe

A special thanks to the Facultad de Ingeniería y Ciencias Hídricas - FICH UNL, our Venue Partner!

Thanks to all our sponsors for their support! Their contributions enable a diverse global community of Debian developers and maintainers to collaborate, support one another, and share knowledge at DebConf26.

Running Graphical Applications in Incus Containers

I didn't know how easy it is to display the graphical console of a virtual machine until I tried recently.

$ sudo apt install virt-viewer
$ incus launch images:debian/trixie test --vm
$ incus console test --type=vga

That's it.

The diffoscope maintainers are pleased to announce the release of diffoscope version 325. This version includes the following changes:

[ Chris Lamb ]
* Fix tests to work with zipdetails 4.0008. (Closes: #1141359)
* Downgrade debhelper compatibility level to 13 for now.
* Update copyright years.

You find out more by visiting the project homepage.

Yay! Finally it’s that time of year — DebCamp is underway, and soon it will be time for DebConf! 🎉🥳

As it is by now tradition, it’s my task to coordinate the DebConf26 keysigning party. And, as usual, I have set up the list of DebConf26 keysigning maps for everybody involved.

So, if you are taking part of DebConf, make sure to:

• Find yourself in the keysigning map. Are you a part of the listing?

  • If you are not there, log in to the DebConf26 management system and edit the Personal Information section of your profile. Make sure you submit your OpenPGP key fingerprint.

  • Make sure your key is available in the keyserver network. They should basically be equivalent and interoperate, but in any case — my scripts will try to find your key at pgpkeys.eu, keys.openpgp.org, keyserver.computer42.org, keyserver.ubuntu.com, keyring.debian.org, pgp.surf.nl, pgp.pm, pgp.mit.edu, the.earth.li.

• Make sure your name is readable and matches what you want others to sign. If it does not, edit your key and upload it now!

• Remember that, as announced, the deadline for the final list is on Thursday, 2026.07.16, 09:00 GMT-3 (Argentinian time).

Five years or so ago, I had a look at trying to speed up dpkg's package installation; I concluded that it was probably possible to speed up, but that there was no appetite for this kind of large-scale changes. (You'd probably need to rewrite the transaction system to get rid of a lot of fsyncs, you'd ideally want to reduce the number of syscalls for unpack by io_uring and so on.)

This summer, I've been looking at something related on and off; it is possible to speed up the startup time? That's in a sense the opposite scenario; instead of installing lots of packages in a newly debootstrapped chroot (with very few packages), see how fast you can install one in a much more busy chroot (I just copied my laptop's dpkg dir, with ~6600 packages installed).

Before I show the numbers, I must stress that this is an investigation, not a fair benchmark, and you should not go shout at the dpkg maintainers that they need to get to “catch up”. That said:

> sudo time dpkg --root=root -i hello_2.12.3-1_amd64.deb >/dev/null
Not building database; man-db/auto-update is not 'true'.
1.12user 0.49system 0:01.85elapsed 87%CPU (0avgtext+0avgdata 171880maxresident)k
0inputs+14648outputs (0major+72963minor)pagefaults 0swaps

> sudo time ./src/dpkg --root=root -i hello_2.12.3-1_amd64.deb > /dev/null
0.04user 0.01system 0:00.15elapsed 38%CPU (0avgtext+0avgdata 6520maxresident)k
0inputs+1080outputs (0major+2705minor)pagefaults 0swaps

How is it unfair? Well, for one, the code to run triggers is messed up so they're not run (but the trigger in question should be very fast). And there's one step at the end with detecting “disappearing packages” that doesn't run properly because it's a bit tricky in my model and I didn't want to deal with, well, difficult problems. But I think both are perfectly doable without really affecting the end time, it just requires engineering. There's a lot of work to be done, though; diving into the code makes me shudder at all the complexities that need to be in place to support all the corner cases of multiarch, for instance.

The code is extremely proof-of-concept, but it runs and can read (and write) metadata from SQLite instead of flat text files, it can resolve dependencies in the most basic fashion, it can keep track of installed files, it should be crash- and powerloss-proof. You know, the very very basic stuff, and without changing the model fundamentally (like e.g. Michael Stapelberg did with distri, fundamentally replacing packages with disk images and ending up in a very fast but rather different-looking system). So it was satisfying to see that it ends up around 10x even on my not-very-new laptop (plus a significant RAM reduction); I believe it should be possible to squeeze under 100 ms, but that would probably require also optimizing the unpacking itself, which I didn't look at this time.

Having a bunch of files being read into RAM and then processed freely was a design that made a lot of sense when dpkg was written (in 1995!) and Debian had ~250 binary packages in total (and you probably wouldn't install all of them). There was no reasonable database available for desktop systems; the closest thing you'd have was probably BerkeleyDB and that wasn't really it, so flat files and fsync made a lot of sense, and was easy to manipulate and persist. But now, SQLite is widely available and probably the most battle-tested code in history, a typical system has thousands of packages (you could easily install tens of thousands if you're doing heavy development), SSDs have replaced HDDs almost everywhere for system disks, and the environment has just changed a lot in general. So I hope that someone at some point will be crazy enough to pick this up and run with it, because it's a lot of work and I don't intend to. :-)

PS: I didn't look at apt; I think what I'd really love to see first and foremost is a package format change so that apt-listchanges can look at (or look for) NEWS.gz without having to unpack the entire package. Perhaps a control field saying “nothing new here”?

I’ve just filed a Debian bug report about libproc-processtable-perl giving bad errors when SE Linux denies access to files under /proc [1].

Ran into unknown state (hex char: 0) at /tmp/test.pl line 8.

The errors are of the above form which Google didn’t find before now so obviously isn’t a common situation, below is my test program.

#!/usr/bin/perl
use strict;

use Proc::ProcessTable;

my $process_table = new Proc::ProcessTable('cache_ttys' => 0 );

foreach my $process ( @{$process_table->table} )
{
  print $process->fname . "\n";
}

Here is the relevant part of strace output:

newfstatat(AT_FDCWD, "/proc/2", 0x7fff19533c10, 0) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/proc/2/stat", O_RDONLY) = -1 EACCES (Permission denied)
access("/proc/2", F_OK)                 = 0
write(2, "Ran into unknown state (hex char: 0) at /tmp/test.pl line 8.\n", 61) = 61

Below is the apt sources.list line for my personal repository which has a version of the package with this fix. The gpg key is in the etbe-base package in that repository and the source is all there. To access it without apt use this web page [2].

deb [signed-by=/usr/share/keyrings/etbe.gpg arch=amd64 ] https://www.coker.com.au trixie misc

I’ve also done some work on the ps.monitor script in etbe-mon that uses this Perl package and made it better handle program names longer than 15 characters. That improvement apparently only works on Linux, Darwin, and Cygwin. People who want things to work better on BSD etc could patch libproc-processtable-perl accordingly.

• [1] https://tinyurl.com/2ckw4kh2
• [2] https://www.coker.com.au/dists/trixie/misc/binary-amd64/

Debian Contributions: 2026-06

Contributing to Debian is part of Freexian’s mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

Python 3.14 as default transition, by Stefano Rivera

Debian has had Python 3.13 and 3.14 in unstable and testing since December 2025, with Python 3.13 as the default version (/usr/bin/python3 = 3.13). This gave time for packages to implement support and detect issues in their test suites.

A slot to transition to 3.14 as default was requested from the release team in March, and they indicated that we would likely be able to schedule it in late June. In preparation, Stefano reviewed the open bugs against Python interpreters and squashed some in uploads of the latest point releases of Python: 3.13.14 and 3.14.6. Also in June, Python 3.15.0 beta 2 and beta 3 released. Stefano uploaded these to Debian experimental.

The 3.15 betas were reason to attempt to revive review of a blocked upstream patch to support Debian multiarch in stable ABI Python extensions, now that Python 3.15 is adding a new stable ABI abi3t.

DebConf 26 preparations, by Stefano Rivera, Antonio Terceiro, Lucas Kanashiro, Santiago Ruano Rincón and Anupa Ann Joseph

DebConf 26, the annual Debian Developer Conference, is being held in Santa Fe, Argentina, in July. Stefano Rivera, Antonio Terceiro, Lucas Kanashiro, Santiago Ruano and Anupa Ann Joseph contributed to the preparations for the event.

• As usual, Stefano has been supporting the conference website and registration, helping the local team to get accurate data on attendee numbers.
• Antonio has been supporting the conference website and helping the content team to put together the conference schedule.
• Santiago has been helping the local team on different topics regarding logistics.
• Anupa assisted with the accommodation arrangements for DebCamp and DebConf, working alongside Nattie.
• Lucas has been coordinating the conference schedule and communicating with some speakers.

debvm, by Helmut Grohne

The debvm tool used for creating and running ephemeral virtual machines saw a number of small improvements. The requirement of having a filesystem label has been removed in favor of using a uuid and /etc/fstab is no longer created. A memory balloon is enabled by default and this enables qemu to automatically release free guest memory to the host. Booting Ubuntu VMs regressed as a result of their use of uutils and has been fixed. The --architecture flag is back to be able to better support Hurd, which is a work-in-progress of Johannes Schauer Marin Rodrigues. Thanks to Jochen Sprickerhof, you can more easily create VMs for autopkgtest-virt-qemu using --hook-dir=/usr/share/mmdebstrap/hooks/autopkgtest-create-qemu. There also are a few documentation and error message improvements. All of this is pending in git waiting to be uploaded once development slows down. While booting a machine from virtiofsd succeeded, turning the proof-of-concept into production remains for later.

pconr, by Helmut Grohne

At DebConf25, Helmut reported on a schroot substitute called unschroot. The second iteration uses varlink IPC to construct a container. That varlink API is now separated into a new project called programmable container runtime. It is meant to provide more flexibility in constructing containers than established solutions such as the unshare command from util-linux, bubblewrap or podman provide while still managing repetitive complexity such as process orchestration for the developer. A new example that uses this infrastructure is a better containment for mmdebstrap eliminating chroot escape. There also is an asyncvarlink/0.3.2 release taking steps to become more maintainable in Debian to eventually get pconr into Debian.

Miscellaneous contributions

• Stefano did routine uploads (mostly new upstream versions) of python-pip, python-pipx, hatchling, dh-python, beautifulsoup4, python-virtualenv, python-mitogen.
• Stefano uploaded a snowball mini-transition: snowball, snowball-data, and pystemmer
• Stefano did some debian.net team admin, setting up a container and later a VM for vote.debian.net.
• Stefano responded to a semi-escalation to the Debian Technical Committee, after some communication between an upstream, a bug reporter, and a Debian package maintainer went sideways and got heated.
• Emilio managed several transitions, and filed bugs against the few remaining GCC 13 rdeps.
• Antonio did salsa maintenance work, debugging service issues, approving user registrations, and processing support requests.
• Antonio worked on Debian CI maintenance, including but not limited to deploying new armhf and armel workers, fixing bugs and preparing an upcoming release of debci.
• Antonio did several maintenance tasks for MiniDebConf websites.
• Antonio uploaded ruby-bunny, ruby-sinatra and ruby-mustermann, fixing a few FTBFS bugs among them.
• Carles using po-debconf-manager: Reviewed Catalan translations for 5 packages, submitted 6 packages. Added a draft blog/update about the po-debconf-manager project.
• Carles submitted a new Geeqie Catalan translation: it had accumulated a large number of untranslated strings over the last 4 years.
• Carles contributed to the Debian wiki: improved documentation for the Framework Laptop and added a new section “Battery charging control” (after doing some debugging and testing). He wrote a page about Signal Desktop. Carles started looking at testing/documenting Mailman2 -> Mailman3 migration.
• Carles, in relation to the migration process, double checked old pages without relevant information in the Debian wiki.
• Thorsten did another upload of package hplip to fix some bugs.
• In the context of the Google Summer of Code 2026 project, Santiago continued co-mentoring Aryan Karamtoth, who is working on the Linux live-patching project. As part of the team, Santiago guided Aryan to help design the different workflows and to study the different tools available, including the upstream klp-build (that was introduced in v6.19), and compare it with SUSE’s klp-build.
• Colin clarified the bug tracking system’s documentation to indicate that maintainers may sometimes reasonably ask users to file bugs upstream themselves.
• Colin fixed 15 packages for pytest 9.1.
• Colin fixed a depthcharge-tools regression with Python 3.14 as default that broke debian-installer builds.
• Helmut continued to report undeclared file conflicts and correspond about them.
• Helmut wrote patches for strace to enable cross building and a 32bit personality on arm64.
• Helmut continued maintaining rebootstrap working fixing build failures in fontconfig, gettext and sqlite3 as well as changing the way packages from gcc builds are installed to better serve a need reported by Samuel Thibault.

The twentieth release of the qlcal package arrivied at CRAN today, and has been built for r2u. This version synchronises with QuantLib 1.43 released today as well.

qlcal delivers the calendaring parts of QuantLib. It is provided (for the R package) as a set of included files, so the package is self-contained and does not depend on an external QuantLib library (which can be demanding to build). qlcal covers over seventy country / market calendars and can compute holiday lists, its complement (i.e. business day lists) and much more. Examples are in the README at the repository, the package page, and course at the CRAN package page.

This releases updates to several new calendars (see below), and extends the calendars for Israel to some added new conventions, updates a few helper functions, and turns on ccache for continuous integration builds.

The full details from NEWS.Rd follow.

Changes in version 0.1.2 (2026-07-14)

• Synchronized with QuantLib 1.43

• Calendar updates for India, Israel, and South Korea; small interface update for Israle

• New calendars for Croatia, Malta, Montenegro, North Macedonia, Serbia, Slovenia, Uzebekistan

• Updates to a number of QuantLib helper functions

• Continuous integration now uses ccache via a setup action

Courtesy of my CRANberries, there is a diffstat report for this release. See the project page and package documentation for more details, and more examples.

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.

Nextcloud PHP debugging with Xdebug in Zed editor

I started to switch from PhpStorm to Zed as IDE recently as Zed is open source and has a much smaller footprint and is more slick than PhpStorm.

One thing that I didn't get running immediately was Xdebug integration, so I did a bit of research and asked Claude for help. Here's a quick writeup of how to get it running.

I have Zed installed as Flatpak on a Debian Trixie host system.

The PHP process runs in a nextcloud-docker-dev Docker container.

Install Zed and configure debugging there

Install Zed: flatpak install flathub dev.zed.Zed

In Zed: open the Extensions view and install PHP.

Configure the debugger:

Create ~/.var/app/dev.zed.Zed/config/zed/debug.json:

[
  {
    "label": "PHP: Listen to Xdebug",
    "adapter": "Xdebug",
    "request": "launch",
    "port": 9003,
    "pathMappings": {
      "/var/www/html":             "/home/<user>/devel/nextcloud/server",
      "/var/www/html/apps-extra":  "/home/<user>/devel/nextcloud/server/apps-extra",
      "/var/www/html/apps-shared": "/home/<user>/devel/nextcloud/apps-shared"
    }
  }
]

Add one entry per bind-mounted app directory.

After creating the file, restart Zed.

Inside Zed, select "debugger: start" from command palette and then "PHP: Listen to Xdebug".

Verify Zed is listening. Running ss -tlnp | grep 9003 on the host should show *:9003 with Zed as the process.

Configure Xdebug inside the container

/usr/local/etc/php/conf.d/xdebug.ini:

xdebug.mode = debug
xdebug.idekey = PHPSTORM
xdebug.trace_output_name=trace.%R.%u
xdebug.profiler_output_name=profile.%R.%u
xdebug.output_dir=/shared/xdebug

xdebug.log = /var/log/xdebug.log
xdebug.log_level = 3

; Try to discover the client host, otherwise fall back to the docker host
xdebug.discover_client_host=true
xdebug.client_host=host.docker.internal

; When you cannot specify a trigger, use "xdebug.start_with_request = yes" to autostart debugging for all requests
; https://xdebug.org/docs/all_settings#start_with_request
xdebug.start_with_request = trigger

; Set xdebug.mode trace to use this
; More details at https://derickrethans.nl/flamboyant-flamegraphs.html
xdebug.trace_format=3
xdebug.trace_output_name=xdebug.%R.%u

Apply changes by restarting apache in the container: apache2ctl -k graceful

Notes:

• host.docker.internal resolves on Linux Docker only if the container was started with --add-host=host.docker.internal:host-gateway (nextcloud-docker-dev already does this).
• discover_client_host = true makes xdebug follow X-Forwarded-For - useful behind Nextcloud's dev reverse proxy.

Test xdebug with a PHP command inside the container

Run XDEBUG_SESSION=PHPSTORM php occ status inside the container and check /var/log/xdebug.log.

Install the browser extension

Install Xdebug Helper (Firefox/Chrome). In its preferences, set the IDE Key to PhpStorm. It will set the XDEBUG_SESSION cookie when toggled to Debug.

Click the Xdebug Helper icon in the browser and set it to Debug.

Test Xdebug with browser extension

Load the URL that exercises the code path with the breakpoint. Zed should stop the code exection at the breakpoint.

Here’s my monthly but brief update about the activities I’ve done in the FOSS world.

Debian

Whilst I didn’t get a chance to do much, here are still a few things that I worked on:

• Leading the DebConf Bursary team along with PEB.
  • This took most of my Debian time this month but we’ve been able to wrap that work now.
  • Got back to all the tickets on Zammad, too.
• Assisted a few folks in getting their patches submitted via Salsa.
• Mentoring for newcomers.
• Moderation of -project mailing list.

Ubuntu

I joined Canonical to work on Ubuntu full-time back in February 2021.

Whilst I can’t give a full, detailed list of things I did, here’s a quick TL;DR of what I did:

• Continued to push for infrastructure improvements:
  • Charming.
  • Artifact signing.
  • Reorganizing cdimage.
  • And so on.
• Successfully released 26.10 Snapshot 2!
  • We landed a breaking change in the directory structure.
  • …whihc had consequences on the rsync, being run by the sysadmins.
    • The 30 GB rsync failed because of the load on the system and it resulted in things blowing up. Yay. Stress-testing the shit out of our infra. :)
    • We got it back under control in the next few days but oh wow, what a journey to get there.
• Assisted a bunch of folks with my Archive Admin and Release team hats to:
  • Helped in archive opening tasks.
  • Promoting/demoting binaries to/from main.
  • Taking care of package removals and so on.
  • Reviewed the NEW queue.
• Reviewed quite a lot of MPs, specs, and other people’s work.
• Mentoring, coaching, and leading the Release Management team.

Debian (E)LTS

This month I have worked 15 hours on Debian Long Term Support (LTS) and on its sister Extended LTS project and did the following things:

Released Security Updates

• node-lodash: Prototype pollution and code injection during template compilation.

  • [LTS]: Fixed CVE-2025-13465, CVE-2026-2950, and CVE-2026-4800 via 4.17.21+dfsg+~cs8.31.173-1+deb11u1 for bullseye. This has been released as DLA 4663-1.
  • [trixie]: Filed the proposed-update (#1141450) and uploaded the fix.
  • [bookworm]: Filed the proposed-update (#1141449) but it was closed; will release the DLA next month (in July).

• openvpn: Multiple vulnerabilities leading to Denial of Service.

  • [LTS]: Fixed CVE-2026-11771, CVE-2026-12932, CVE-2026-12996, CVE-2026-13117, CVE-2026-13122, and CVE-2026-13698 via 2.6.14-0+deb12u2 for bookworm. This has been released as DLA 4666-1. The update itself was prepared by the maintainer; I helped prepare the paperwork.

Work in Progress

• php-phpseclib: Affected by CVE-2023-52892 and CVE-2026-32935.
  • [LTS]: Continued to work on this and it should be released soon. Uploaded the work to debusine: https://debusine.debian.net/debian/developers/work-request/906743/. Will release the DLA in July.

Other Activities

• [LTS] Emilio pointed out that the gst-plugins-ugly1.0 binaries were still not fully released, so I ran dcut migrate to fully release them. The DLA had gone out earlier.

• [ELTS] Did some more work on ruby-rack - a lot of new CVEs have opened up and, whilst I made some progress, Santiago let me know that ruby-rack is no longer supported and so it’ll be removed from the ela-needed list.

• [E/LTS] Set up the security-tracker and a few other things on the new machine, and debugged the git repository size madness. Sent a summary here.

• [E/LTS] Monitored discussions on mailing lists, IRC, and all the documentation updates.

• [E/LTS] Attended the monthly LTS meeting on Jitsi. Meeting notes here.

Until next time.
:wq for today.

Introduction

Recently, I've got a chance to try building Mozc (Most famous Japanese input method editor) with Bazel.

As you know, recently newer Bazel related packages were landed into debian/unstable. Then now I'm planning to update Mozc from 2.29.5160.102 to 3.33.6133.

Background story about Mozc and Debian

The upstream of Mozc had released 3.34.6239, but on Debian, we stick to Mozc 2.29.5160.102.

Mozc requires newer Bazel but we only had Bazel 4.2.3 at that time on Debian, so even though the upstream of Mozc switched from GYP to Bazel, we had patched Mozc with GYP based package.

We even did make an effort to restore build options that had been already removed. :-( And needed to migrate from GTK2 renderer to GTK3 renderer.

That is why the version of Mozc is diverged from upstream on Debian.

• 2.29.5160.102 (Now on Debian)
• 2.29.5268.102
• 2.29.5374.102
• 2.29.5544.102
• 2.30.5544.102
• 2.31.5712.102
• 2.31.5851.102
• 2.32.5994.102
• 3.33.6089
• 3.33.6133 (Target to upgrade for)
• 3.34.6239

How to switch from GYP to Bazel?

At first, we needed to decide what Mozc version to work with it.

Now latest version of Mozc is 3.34.x, but it requires Bazel 9.x. Please recall that Bazel 7.7.1 was introduced Debian/unstable. And more, newer dependency libraries are required.

You might feel that target version (3.33.6133) is too high from 2.29.5160.102, but if we upgrade to more older Mozc, it means that it requires to backport Mozc to older libabsl compatible codes and so on.

That is why Mozc 3.33.6133 was chosen.

Even once the target version has been decided, you can't let your guard down.

There are many technical tasks to solve.

• Revisit patch sets to apply
• Porting uim mozc patch and fix FTBFS
• Porting fcitx5 mozc patch and fix FTBFS
• Fix src/third_party vendoring
• Switch from GYP to Bazel build systems
• ...

At least, it will likely require several rounds of testing in the Debian experimental.

Conclusion

Currently, gbp buildpackge has succeeded finally on local machine, but need to tidy and cleanup stuffs.

I didn't know packaging with Bazel best practice yet, to remove many third party vendor/ bundles, I've found that it requires pile of patch to eliminate them.

In the current version of Debian, as a one of build system, further work — such as support from debhelper - will be needed.

I'll file working progress on #1085173

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.

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.

At May First, we recently received (all within a single week) three different complaints about domain names that previously worked fine suddenly not resolving to our servers.

While that isn’t terribly uncommon, we discovered that in each case, the domain name’s authoritative name servers were pointing to our mail servers (a.mx.mayfirst.org, b.mx.mayfirst.org and c.mx.mayfirst.org) instead of our name servers (a.ns.mayfirst.org, b.ns.mayfirst.org and c.ns.mayfirst.org). The weird part: this mistaken configuration was happening at the registrar level, protected by each member’s own credentials that we don’t have access to.

Each affected member fixed their records to resolve the problem but also made very clear that they had not logged into their registrar in years, sugggesting that the DNS authoritative records in their registrar accounts spontaneously changed on their own. The first time was weird, the second time could possibly be a coincidence? But by the third time this happened, we started to panic. How could registrar records spontaneously change? All three domain names were registered with different companies - so it couldn’t be a single registrar problem? Are we going to get a flood of these complaints? What is going on!?!?

We did an inventory to see if this was happening with other domain names in use by our membership and that’s when we discovered just how hard it is for our mostly non-technical users to set a domain’s authoritative name servers. The error rate was less than 1% but still that was a lot of domain names with typos:

• raise your fist in the air with a.ns.mayfist.org!
• or just plain give up and hit the floor with a.ns.matfirst.org
• Or more commonly people added our name servers, but also left the default name servers in place.
• Also, one person added as their authoritative name servers: a.ns.mayfirst.org, b.ns.mayfirst.org, c.ns.mayfirst.org, a.mx.mayfirst.org, b.mx.mayfirst.org, c.mx.mayfirst.org, and even a.webproxy.mayfirst.org - in other words, all the domain names we tell you do to anything with.
• And lastly, I did find two more domains just pointing to a.mx.mayfirst.org, b.mx.mayfirst.org and c.mx.mayfirst.org.

That’s when it occurred to me: for years we have maintained an offsite server that provides both c.ns.mayfirst.org and c.mx.mayfirst.org. It hangs out in case something terrible happens to our main colo. The week before we started receiving these complaints, I separated these services, moving c.mx.mayfirst.org to a dedicated MX server. As a result, these two domain names stopped pointing to the same IP address. And that’s when the complaints started rolling in. In other words: the affected members set the incorrect name servers years ago, but because just one of the name servers resolved to an IP that happened to provide the correct authoritative lookup services, it went undeteced all this time.

So… mystery solved. Nobody’s authoritative registrar records “suddenly” changed. They were mis-configured for years but thanks to the amazing resilience of the DNS system, nobody noticed because just one working DNS server is all you need.

Welcome to the June 2026 report from the Reproducible Builds project!

In these reports, we outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised or not.

If you are interested in contributing to the project, please visit our Contribute page on our website.

In this month’s report, we cover:

1. Only installing reproducible packages with repro-threshold
2. Distribution work
3. diffoscope development
4. From our mailing list…
5. Documentation updates
6. Patches
7. Four new scholarly papers

Only installing reproducible packages with repro-threshold

A very interesting demonstration is now available showing how you might configure your Debian system to only install packages that have been reproduced by m/n rebuilders.

This is implemented via a reproduced+https:// APT transport ( a mechanism for communicating between the APT client and its repository source — commonly HTTP):

Every package download is intercepted by repro-threshold, which queries two independent rebuilders for a signed attestation before allowing installation to proceed. [It] is important to note that [an] install will only succeed if all package dependencies are also reproducible.

The demo gives examples of how to quickly experiment with this using a Docker container.

Distribution work

In Debian this month:

• The debian-installer package in Debian was uploaded with a substantial reproducibility-related changelog. This means, for the first time, the uploaded version could finally be reproduced.

• Various OpenJDK packages were also uploaded to Debian, including the fix for JDK-8385738 (“Javadoc does not produce reproducible output…”) (for example). […][…][…]

• The “reason” pages on reproduce.debian.net, such as the one for ppc64el, now feature links labeled with the bug emoji (i.e. 🐛) which links to the categorized issues packages have been tagged with in the reproducible-notes.git repo.

• Indeed, 25 reviews of Debian packages were added, 31 were updated and 33 were removed this month adding to our extensive knowledge about identified issues. Two issue types were updated as well. […][…]

The IzzyOnDroid Android APK repository reached its next milestone this month, now covering 2 out of every 3 apps (66.7%) with reproducible builds. Their documentation for debugging and fixing failed builds has steadily grown as well. More clients have picked up showing reproducibility results (e.g. Droid-ify), and Neo Store now can be configured to stick to only reproducible applications. Further, an independent builder has been added to the build farm, increasing the trust level even more as APK builds can have multiple confirmations now.

At the same time, IzzyOnDroid’s rbtlog got several new features. The most outstanding is caching for frequently used resources such as reproducible-apk-tools, command-line tools and NodeJS in order to counter ongoing issues with GitHub availability, while at the same time saving bandwidth and build time. This change also enables some other some smaller enhancements such as being able to configure build timeouts per recipe for those builds running longer than the average, release pattern filtering for update checks or having a field for maintainer notes to shortly summing up e.g. why a reproducible build failed.

Lastly, Bernhard M. Wiedemann posted another openSUSE monthly update for their reproducibility work there.

diffoscope development

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 319, 320, 321, 322 and 323 to Debian:

• Debian adds an extra Flags: line in the output of ocamlobjinfo, so adjust the test for cross-distribution compatibility. […]
• Bump debhelper compatibility level to 14. […]
• Fix compatibility with Ocaml 5.4.1. […]
• Use --long-form-style arguments when calling apktool in order to support apktool version 3. […]
• Support Androguard version 4 and previous versions at the same time. […]
• Update copyright years. […]

In addition, Jochen Sprickerhof added better header detection for the Sphinx documentation system […], Michael Daniels fixed the tests when run with zipdetails version 4.006 […] and Zbigniew Jędrzejewski-Szmek added a version of the deprecated os.path.commonprefix method […].

In addition, Vagrant Cascadian updated diffoscope in GNU Guix to version 321 and 323.

Chris Lamb also made the following changes to strip-nondeterminism, our tool to remove specific non-deterministic results from a completed build:

• Skip symlinks when manually called via /usr/bin/strip-nondeterminism. (#1139000)
• Update debian/watch format. […]
• Drop Rules-Requires-Root: no and Priority: optional fields. […]
• Bump Standards-Version to version 4.7.4. […]

From our mailing list…

On our mailing list this month:

• kpcyrd posted to our mailing list regarding the “waves of malware uploads to aur.archlinux.org”. Curiously, “every incident I looked at used npmjs.com for malware delivery”, specifically where the npm package includes an (automatically executed) preinstall script that is an ELF binary.

• kpcyrd also announced the release of debian-repro-status version 0.4.0, a tool written “to give you an approximate idea of how viable it would be to enforce a ‘reproducible packages only’ update policy for the computer system you’ve built”:

  The change updates dependencies to the latest versions, and adds support for multiple -H options, to query results from multiple rebuilderd instances. The results are also now fetched concurrently.

• kpcyrd also reported that, whilst taking a screenshot for the above release, they noticed that the debian:sid container now is 100% reproducible.

• Finally, kpcyrd also created a pull request against the add-determinism package to update the itertools and zip Python dependencies.

Documentation updates

Yet again, there were a number of improvements made to our website this month including:

• Chris Lamb added a reminder re. using the UTC variants of the Javascript Date methods. […]

• Mattia Rizzolo moved OTF to the ‘old’ sponsors list. Thank you for your support!. […]

• kpcyrd updated the Rust documentation to recommend using the --release argument for consistency. […]

Patches

The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where applicable or possible. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:

  • cvise
  • efl
  • gettext-runtime/bash
  • hadrian
  • plasma6-keyboard
  • syntax-highlighting

• Chris Lamb:

  • #1139654 filed against node-fuse.js.
  • #1139655 filed against node-egjs-hammerjs.
  • #1139656 filed against node-chartjs-adapter-date-fns.
  • #1139662 filed against mkdocs-include-markdown-plugin.
  • #1139704 filed against lmarbles.
  • #1140240 filed against rocm-docs-core.
  • #1140567 filed against libecoli.
  • #1140688 filed against golang-github-tobischo-gokeepasslib.

• Jochen Sprickerhof:

  • #1139457 filed against c-munipack.
  • #1140365 filed against latex-coffee-stains.
  • #1140366 filed against cxxtest.
  • #1140367 filed against slime.
  • #1140368 filed against spooles.
  • #1140369 filed against sdpb.
  • #1140645 filed against procmail.
  • #1140676 filed against proftpd-dfsg.
  • #1141059 filed against mah-jong.
  • #1141133 filed against dxf2gcode.
  • #1141194 filed against afterstep.
  • #1141195 filed against ledger2beancount.
  • #1141196 filed against ocamlviz.

• Kris Van Hee and Vagrant Cascadian:

  • #1140167 filed against dtrace.

Four new scholarly papers

Kenichiro Muto and Kuniyasu Suzaki of the Institute of Information Security in Yokohama, Japan published an interesting paper this month titled Attestable Build Chain: Enabling Trust in Reproducible Builds (PDF). Their abstract is as follows:

Ensuring trust in software supply chains requires verifying not only artifacts but also the processes that produce them. Although Reproducible Builds (R-B) require rebuilding to validate artifacts, they cannot verify whether the build was executed with the intended toolchain and inputs and may reproduce unintended or compromised builds without detection. We present Attestable Build Chain, a framework for externally verifying build-time execution without rebuilding. Rather than preventing compromise, it provides verifiable, tamper-evident evidence of actual build-time execution, enabling verification of build process integrity from observed file accesses during the build. […]

Julien Malka, Stefano Zacchiroli and Théo Zimmermann published a 50-page report detailing A Decade of Software Reproducibility in the Nix Package Ecosystem:

We find that functional package management enables extremely high rebuildability over time (near-universal ability to reconstitute historical build environments and rebuild software packages), while bitwise reproducibility has steadily improved and reaches a high point in recent years (up to 93% in 2024). Early years show substantially lower bitwise reproducibility, indicating that functional package management alone does not guarantee bitwise-identical outputs, and that the observed high level of bitwise reproducibility is not solely due to the package management approach. Common causes of unreproducibility, both in the rebuildability and bitwise reproducibility dimensions, include management of dates in build and test processes; we quantify their prevalence and other common causes using manual analysis of logs of rebuild failures and automated analysis of diffoscope.

A PDF of their report is available online

Tim Bastin of L3montree GmbH and Jacek Galowicz of Applicative Systems GmbH from DevGuard published a paper detailing How We Built a Sovereign, Reproducible Container Supply Chain for DevGuard:

This paper presents how the DevGuard project rebuilt its OCI container pipeline around reproducible Nix builds and independent dual-platform digest verification. DevGuard images are built hermetically from pinned source revisions, signed with Sigstore/Cosign, and verified through digest comparison across GitHub Actions and sovereign GitLab infrastructure hosted on container.gov.de. We describe the practical integration of reproducible OCI image builds into existing CI/CD workflows and argue that independently reproducible container digests provide a stronger integrity guarantee against build tampering than provenance alone. The paper further discusses remaining trust assumptions and the relevance of sovereign build infrastructure for government and regulated environments.

Finally, Yiseul Choi, Junga Kim, Jun-Ho Hong and Seongmin Kim of the Department of Convergence Security Engineering at the Sungshin Women’s University in Seoul, Korea titled Attestation-based verification of SBOM integrity via consumer-side reproducibility:

Software bills of materials (SBOMs) support supply chain transparency, but they do not prove that a delivered SBOM reproducibly corresponds to its software artifact. Existing signing and provenance mechanisms protect integrity and traceability, yet lack consumer-side reproducible verification. We propose an SBOM integrity verification framework combining procedure disclosure, consumer-side reproduction, authority-generated reference evidence, and digest comparison. A trusted authority records a reference digest, and consumers compare it with locally reproduced and delivered SBOM digests. Experiments on 100 real-world container images show detection of artifact tampering, SBOM substitution, distribution modification, and adaptive tampering beyond signature-based approaches

Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.

• Mastodon: @reproducible_builds@fosstodon.org

• Mailing list: rb-general@lists.reproducible-builds.org

A new minor release 0.4.28 of RQuantLib arrived on CRAN this evening, has been uploaded to Debian, and is being built for r2u as well.

QuantLib is a rather comprehensice free/open-source library for quantitative finance. RQuantLib connects (some parts of) it to the R environment and language, and has been part of CRAN for nearly twenty-three years (!!) as it was one of the first packages I uploaded to CRAN.

This release of RQuantLib brings a minor update to the calendars for Israel which in QuantLib 1.43 can now use one of three different exchange choices. However, using ‘settlement’ is now deprecated so we adjusted our code. This came up as we had packaged the 1.43-rc version of the (upcoming) 1.43 release a few days ago, and it is now in testing requiring RQuantLib to catch up. Full details from the NEWS file follow as usual.

Changes in RQuantLib version 0.4.28 (2026-07-10)

• Adjust to Israel calendar constructor change in QuantLib 1.43

• Continuous integration uses ccache-with-R action

Courtesy of my CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the RQuantLib page. Questions, comments etc should go to the rquantlib-devel mailing list. Issue tickets can be filed at the GitHub repo.

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

Team Rcpp is excited to share that an brandnew new version 1.1.2 of Rcpp is now on CRAN, has also been uploaded to Debian, and has already built for r2u and r-universe; Windows etc builds at CRAN should follow in due course.

Rcpp has long established itself as the most popular way of enhancing R with C or C++ code. Right now, 3236 packages on CRAN depend on Rcpp for making analytical code go faster and further. On CRAN, 13.4% of all packages depend (directly) on Rcpp, and 61.4% of all compiled packages do. From the cloud mirror of CRAN (which is but a subset of all CRAN downloads), Rcpp has been downloaded 121.6 million times. The two published papers (also included in the package as preprint vignettes) have, respectively, 2263 (JSS, 2011) and 471 (TAS, 2018) citations, while the the book (Springer useR!, 2013) has another 742.

The is the second update in the 1.1.* series which had, among other changes, switched to C++11 as the minimum standard. This release continues as usual with the six-months January-July cycle started with release 1.0.5 in July 2020. Interim snapshots are always available via the r-universe page and repo. We continue to strongly encourage the use of these development released and their testing—we tend to run our systems with them too.

Having said that, we would like to reiterate that we strongly object to the upstream R release and change management which in this 4.6.* cycle made several abrupt changes forcing packages which consume header files to make very abrupt change. Rcpp, just like numerous other CRAN packages demonstrates that API changes can be undertaken responsibly in a managed manner which allows for transition periods followed by possible warning periods, deprecations periods and finally (but only at long last) errors. What happened here is a speed run to the final stage of forced errors. Uncool and irritating for something as widely used as R. This forced us to make an interim release 1.1.1-1.1 even though we have of course had a policy of always keeping properly tested, installable, and error-free releases candidate version in the main repository branch and hence available via R-universe tested packages for all relevant platforms, and even via binaries for most (including Ubuntu LTS). It would be nice if R Core found a way to take advantage of this. Maybe development cycles, running apart for a year as they do for R, should also include selected packages.

Once again I am not attempting to summarize the different changes. The full list follows below and details all these changes, their respective PRs and, if applicable, issue tickets. Big thanks from all of us to all contributors!

Changes in Rcpp release version 1.1.2 (2026-07-01)

• Changes in Rcpp API:

  • Use of execinfo.h is again conditional to avoid build complexity (Dirk in #1445 addressing #1442)

  • An internal state component for Datetime is now int (Dirk in #1448 and #1449 fixing #1447)

  • Three new (in R 4.6.0) attribute accessors are used conditionally (Dirk in #1450 closing #1432)

  • An UBSAN error in the Sugar-based NA comparison has been corrected (Iñaki in #1453 fixing #1452)

  • Treatment of Inf outside of integer range in Sugar function has been corrected (Iñaki in #1458 fixing #1455)

  • Integer overflow protection has been added for sugar functions (Iñaki in #1457 fixing #1454)

  • The parent environment is now accessed via R_ParentEnv (Dirk in #1460 fixing #1459)

  • Change to returning dataptr again for better handling of empty vectors (Iñaki in #1462 fixing #1461)

  • Undefined behavior errors in use of ListOf proxies have been addressed (Iñaki in #1464 fixing #1463)

  • Under newer R version, R_UnboundValue is no longer used (Iñaki in #1466 fixing #1465)

  • New R API access point R_getRegisteredNamespace() is used with current R versions (Dirk in #1469 fixing #1468)

  • The Nullable::as() exporter now uses an explicit cast to the templated type (Dirk in #1471 fixing #1470)

  • A memory leak in the variadic Rcpp::warning() template has been fixed (Kevin in #1475 fixing #1474)

  • The Nullable::operatorT() has been added as a 'opt-out' (Dirk in #1477 with coordination in #1472)

  • Add templated integer-index overload for operator[] on small systems such as WASM (Jeroen Ooms in #1482)

  • The attribute accessors in AttributeProxyPolicy no longer rely on get__() (Kevin in #1484 fixing #1483)

• Changes in Rcpp Documentation:

  • Reference in the bibliography used by the package vignettes have been updated.

• Changes in Rcpp Deployment:

  • Excute permissions are set consistently on scripts with shebangs (Mattias Ellert in #1467)

  • R 4.5.* has been added to the CI matrix (Dirk in #1476)

  • Three nag messages issued when obsolete build flag accessors are used now show Rcpp::: (Dirk in #1480 fixing #1456)

  • Reference GitHub Actions have been updated to their current versions (Dirk in #1481)

• Non-release Changes:

  • A non-release hotfix 1.1.1-1 used by CRAN accommodates breaking changes to the API in R 4.6.0. It would be nice to have the same level of release management in R itself that CRAN expects from us.

Thanks to my CRANberries, you can also look at a diff to the previous interim release along with pre-releases 1.1.1-1 and 1.1.1-1.1 that were needed because R-devel once again sudden decided to move fast and break things. Not our doing. And there also should not have been a need to two such uploads but it was amateur hour all around.

Questions, comments etc should go to the GitHub discussion or issue section, or the Rcpp list. Bugs reports are welcome at the GitHub issue tracker as well. GitHub offers decent search for issue, pull requests and discussions; as many topics have been covered it is worth checking as well.

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.

I used to ice skate as a teenager but I stopped at University. I tried to pick it back up in 2024 but had to stop when I got ill. I restarted in 2025, initially with a weekly skate session but last month I started group hockey skate lessons.

There's not a lot of pics of me skating… this one from an IR camera

I've been skating in a pair of Bauer¹ Nexus N77s that I bought 7 years ago on a work trip to Toronto. These did a great job of getting me back into the hobby for 6 years but recently I felt it was time to step up to a better quality pair. Despite being a size down from my shoe size, the Nexuses are too large: I had been compensating with thick socks but still struggling to get the boots tight enough. I'd have to wear gloves to lace up because I'd cut my hands pulling the laces otherwise.

After too long researching/deliberating/kvetching (very much on trend for me) I upgraded to Bauer Vapor Fly30s another half-size down (and nearly ten times as much). The fit is much better, in almost every respect. They actually go on easier and I don't have to tear my hands tightening the laces. They feel like a natural extension of my feet. I seem to be using a different set of muscles to skate, so the first few sessions were very fatiguing, but that settled. The Vapor line is speed-oriented, which I thought would fit my skate style best.

new and old skates

I have unfortunately gained a common problem: arch pain. More precisely, my navicular bone seems to be quite prominent², and that part is pressing uncomfortably into the boot. Boots typically take a few sessions to break in, but after 7-8 sessions the pain was getting to the stage that I couldn't skate for a full session without being in agony.

The last time I skated I tried to throw everything at the problem: I'd had the skates baked³; bought some orthotic insoles; then some "Bunga" pads over the sore bit and an attempt to more loosely tie the laces over the affected area. I tried a ten minute skate, and it seemed a bit better.

I then tried experimentally to swap back to my old skates, and I felt like Bambi: I just couldn't do it! They didn't press on the navicular, and they're softer so you can compensate for the size with tight lacing, but I had no confidence in them, I couldn't lean into the turns. They just felt weird. I realised there's no way back.

I switched back to the fly30s, adjusted the bunga pad positioning, tweaked the lacing and went back on for about 40 minutes. It went well: the rink was quiet, it was cool whilst we had a heat wave outside, so I worked up a sweat. By the end there was some discomfort, but not too much, and I think partly the area is currently sensitive so just about anything will cause discomfort. Fingers (or toes) crossed that I've mitigated the problem! If not, it might be time to try a punch out.

“You are what you eat” – but perhaps this is even more true of our information diet. It is hard to strike a balance between remaining a well-informed citizen versus spending hours ingesting unnecessary news about issues and events we can’t affect. But I’m increasingly convinced that my hours lost to doomscrolling are down to design choices by web publishers rather than a failure of individual willpower.

We have created an “obesogenic” information environment

I don’t think it is just me – I think our information environment has been progressively altered over time as news sites look to maximize engagement. Even outside of social media, the invisible hand of the market for eyeballs forces sites to optimize for browse time or risk irrelevance.

Even as newspapers find it increasingly difficult to fund good journalism through advertising in an online world, especially local journalism, they need to keep readers on their sites, clicking through as many articles as possible. Clickbait headlines, “urgent” flashing live icons to draw the attention, and many opportunities to leap from one article to another, and another.

But this design approach even extends to news organisations with a different funding model, like BBC News, which is a public service (state-owned but arms-length) organisation funded through a mandatory television licence – a matter of controversy in some quarters. And it extends even to sites where I pay a subscription fee; I might get adverts removed, but I am still bombarded with the same design philosophy; too many opportunities to be pulled away from what I’m reading towards some other unrelated article.

Even if I try and limit my exposure to algorithmic “discovery” of new news, via RSS feeds or similar, if I’m reading the full article in a browser then I am prompted to read more stuff that I didn’t intend. This defeats the benefit of curating a set of feeds, because you still get dragged away to random articles.

Only 44% of BBC News is news

To show you what I mean, I’m going to pick on the BBC, although I love them dearly and the same issue very much applies elsewhere.

I’ve taken a screenshot of a random BBC News article in mobile view (my preferred doomscrolling user access device), and measured approximately what proportion of the full length of the page is taken up by each section. This is a fairly in-depth news article, so I reckon if anything the figures would be worse than this on shorter articles.

(These numbers will not sum to 100% for reasons which are obvious if you look at the crossbars. Also they’re approximations.)

Less than half of the page (44% if you exclude the inline related links) is actual news text/images; the rest are links trying to help you find the next thing to read/watch. I do not want this.

I’m sure this A/B tests well in terms of reader figures, but it sometimes leaves me exhausted – it must take subconscious mental energy to ignore, or I spend too much time trying to keep on top of things.

And remember, this is a publicly-funded site that does not rely on advertising!

Blocking out the noise

If you are technically-minded, you can use an ad-blocker such as uBlock Origin to take back some control. Applying the following lines as a custom filter (Settings > My filters) brutally cuts out almost all of these links:

bbc.co.uk##aside
bbc.co.uk##footer>div:has(h2)
bbc.co.uk##[data-block="uploaderEmbed"]
bbc.co.uk##[data-block="links"]

Caveat emptor: I have not road-tested this for more than half an hour, so who knows what consequences this could have on your web browsing. In particular, international readers outside the UK will likely be redirected to bbc.com, the commercial arm of the BBC, where these rules will need adapting.

Is it unethical to use an ad-blocker to remove these links? I would argue not. I am not depriving the BBC of any revenue, because I pay my licence fee. I might reduce the amount of time I spend on their website, but if anything the subjectively better experience might encourage me to consume more news from them, not less. In other circumstances (outside the UK for instance, where the BBC relies on advertising), the balance might be different.

Product managers, please find better metrics

I lament the state of the internet in 2026. I now can’t unsee these innocuous “related stories” links as a mechanism to grab my attention, and it’s gone too far.

If you are a normal person just browsing the news and looking to discover the latest important stories relatively quickly, I can see that these types of links might actually be useful for discovery; but I’m actually reasonably sure that I’m not going to miss out on anything major. You still have the option of the news home page if you want to be presented with more news for example, and it feels natural to go back to there when you’ve run out of stories to consume.

But it shouldn’t be down to individual responsibility to ignore or geekily block these types of link; news sites with alternative funding models should find better metrics for engagement than “hours spent on site” – how about optimizing for customer mental wellbeing, or minimizing time required to catch up with the news? There’s no need to maximize clicks and eyeballs. This is a societal level issue, because we are all going mad with news over-engagement.

Product managers, over to you.

The diffoscope maintainers are pleased to announce the release of diffoscope version 324. This version includes the following changes:

[ Paul Spooren ]
* Allow trailing garbage in Gzip files.

[ Chris Lamb ]
* Bump debhelper compatibility level to 14.

You find out more by visiting the project homepage.