https://planet.debian.org/ en Planet Debian - https://planet.debian.org/ tag:bits.debian.org,2026-07-20:/2026/07/debconf26-starts-today.html https://bits.debian.org/2026/07/debconf26-starts-today.html <img src="http://planet.debian.org/heads/dwn.png" width="77" height="85" alt="" align="right" style="float: right;"> <p><a href="https://debconf26.debconf.org/">DebConf26</a>, the 27th annual <a href="https://www.debconf.org/">Debian Developer Conference</a>, 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.</p> <p>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 ("<abbr>BoF</abbr>") team meetings, workshops, a job fair, as well as a variety of other events. The full <a href="https://debconf26.debconf.org/schedule/">schedule</a> is updated each day, including activities planned ad-hoc by attendees over the course of the conference.</p> <p>If you would like to engage remotely, you can follow the <strong>video streams</strong> available from the <a href="https://debconf26.debconf.org/">DebConf26 website</a> 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 <a href="https://www.oftc.net/">OFTC IRC network</a> in the <a href="irc://irc.oftc.net/debconf-fadu">#debconf-fadu</a>, <a href="irc://irc.oftc.net/debconf-fbcb">#debconf-fbcb</a>, and <a href="irc://irc.oftc.net/debconf-fich3">#debconf-fich3</a> channels. Please also join us in the <a href="irc://irc.oftc.net/debconf">#debconf</a> channel for common discussions related to DebConf.</p> <p>You can also follow the live coverage of news about DebConf26 provided by our <a href="https://micronews.debian.org/">micronews service</a> or the @debian profile on your favorite social network.</p> <p>DebConf is committed to a safe and welcoming environment for all participants. Please see our <a href="https://debconf26.debconf.org/about/coc/">Code of Conduct page</a> for more information on this.</p> <p>Debian thanks the commitment of numerous sponsors to support DebConf26, particularly our Platinum Sponsors: <a href="https://www.infomaniak.com/"><strong>Infomaniak</strong></a> and <a href="https://www.proxmox.com/"><strong>Proxmox</strong></a>.</p> <p><img alt="DebConf26 sponsors logo" src="https://bits.debian.org/images/debconf26-sponsors-banner.svg" /></p> Mon, 20 Jul 2026 07:45:07 +0000 https://www.eyrie.org/~eagle/journal/2026-07/002.html https://www.eyrie.org/~eagle/journal/2026-07/002.html <p> 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. </p> <p> The major change in this release is a workaround for a groff bug in the 1.24.0 release that breaks compatibility between the <code>.IP</code> and <code>.TP</code> macros and misrenders <code>.IP</code> by removing all space between the tag and the text. Ideally groff bugs should be fixed in groff, but apparently this rendering bug was <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1134776#72">introduced intentionally by the groff maintainer</a> to force authors who were using <code>.IP</code> with text tags to switch to <code>.TP</code> 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. </p> <p> This will at least work around this problem for Pod::Man users, although it won't help with existing manual pages. </p> <p> 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 <code>.TH</code> 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. </p> <p> New in this release is support for an encoding of <code>none</code>, 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 <code>output_string()</code> when the output will be used internally by a Perl program. </p> <p> Pod::Man also adopts <code>CR</code> as the default fixed-width font instead of its long-standing default of <code>CW</code>, 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 <code>--fixed=CW</code> will restore the previous behavior. </p> <p> This release also has a few other bug fixes, particularly for quoting heuristics in <code>C&lt;&gt;</code> blocks, and various documentation improvements. </p> <p> You can get the latest release from CPAN or from <a href="https://www.eyrie.org/~eagle/software/podlators/">the podlators distribution page</a>. </p> Mon, 20 Jul 2026 04:14:00 +0000 https://etbe.coker.com.au/?p=6237 https://etbe.coker.com.au/2026/07/19/ecc-ddr5/ <h2>Hamming Codes</h2> <p>ECC RAM corrects errors that occur in memory before it gets to the CPU. The most common form of ECC is <a href="https://en.wikipedia.org/wiki/Hamming_code">the Hamming Code [1]</a> 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.</p> <h2>RDIMM vs UDIMM</h2> <p>One point of confusion in such things is the difference between <a href="https://en.wikipedia.org/wiki/Registered_memory">Registered memory AKA RDIMMs [2]</a> 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.</p> <p>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.</p> <p>For the systems most commonly seen there are RDIMM systems with ECC and UDIMM systems without ECC.</p> <h2>Chipkill</h2> <p>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 <a href="https://en.wikipedia.org/wiki/Chipkill">ChipKill for ECC systems which can cope with a single DRAM chip failing [3]</a>. 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.</p> <p>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.</p> <h2>DDR5</h2> <p><a href="https://www.atpinc.com/tw/blog/ddr5-what-is-on-die-ecc-how-is-it-different-to-traditional-ecc">DDR5 has on-die ECC to deal with the increased error incidence from smaller and faster memory [4]</a>, this is specified as 8 bits of error correction per 128 bits of data which implies basic Hamming codes.</p> <p>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.</p> <p>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.</p> <p>Currently the best published research on the effectiveness of ECC on RAM errors is <a href="https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf">the Google paper published in 2009 which is based on DDR and DDR2 RAM [5]</a>. 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.</p> <h2>DDR5 EC4 vs EC8</h2> <p><a href="https://en.wikipedia.org/wiki/DDR5_SDRAM#Subchannels">DDR5 supports 2*32bit “subchannels” instead of just supporting 64bit words [6]</a>. 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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <h2>Why ECC is Needed</h2> <p><a href="https://www.tomshardware.com/pc-components/ram/bit-flips-cause-up-to-15-percent-of-firefox-crashes-asserts-mozilla-engineer-figure-inferred-from-470-000-auto-submitted-crash-reports">Here’s an interesting article about Mozilla’s claim that 15% of Firefox crashes are due to RAM hardware errors [7]</a>, this seems to be based on repeatable errors and therefore won’t count errors where a bit flip happens once a day or less.</p> <p>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.</p> <p>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.</p> <h2>What Society Needs</h2> <p>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.</p> <p>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.</p> <p>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.</p> <ul> <li>[1]<a href="https://en.wikipedia.org/wiki/Hamming_code"> https://en.wikipedia.org/wiki/Hamming_code</a></li> <li>[2]<a href="https://en.wikipedia.org/wiki/Registered_memory"> https://en.wikipedia.org/wiki/Registered_memory</a></li> <li>[3]<a href="https://en.wikipedia.org/wiki/Chipkill"> https://en.wikipedia.org/wiki/Chipkill</a></li> <li>[4]<a href="https://www.atpinc.com/tw/blog/ddr5-what-is-on-die-ecc-how-is-it-different-to-traditional-ecc"> https://tinyurl.com/2aj7oztw</a></li> <li>[5]<a href="https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf"> https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf</a></li> <li>[6]<a href="https://en.wikipedia.org/wiki/DDR5_SDRAM#Subchannels"> https://en.wikipedia.org/wiki/DDR5_SDRAM#Subchannels</a></li> <li>[7]<a href="https://www.tomshardware.com/pc-components/ram/bit-flips-cause-up-to-15-percent-of-firefox-crashes-asserts-mozilla-engineer-figure-inferred-from-470-000-auto-submitted-crash-reports"> https://tinyurl.com/yv4of7hz</a></li> </ul> <div class="yarpp yarpp-related yarpp-related-rss yarpp-template-list"> <p>Related posts:</p><ol> <li><a href="https://etbe.coker.com.au/2007/07/15/desktop-machines-and-ecc-ram/" rel="bookmark" title="Desktop Machines and ECC RAM">Desktop Machines and ECC RAM</a> <small>In a comment on my post about memory errors Chris...</small></li> <li><a href="https://etbe.coker.com.au/2025/05/18/ddr4-ram-size/" rel="bookmark" title="DDR4 RAM Size">DDR4 RAM Size</a> <small>I’ve been looking at computer hardware on AliExpress a lot...</small></li> <li><a href="https://etbe.coker.com.au/2022/07/31/workstations-ecc-ram/" rel="bookmark" title="Workstations With ECC RAM">Workstations With ECC RAM</a> <small>The last new PC I bought was a Dell PowerEdge...</small></li> </ol> </div> Sun, 19 Jul 2026 05:00:37 +0000 tag:bits.debian.org,2026-07-18:/2026/07/debconf26-welcomes-sponsors.html https://bits.debian.org/2026/07/debconf26-welcomes-sponsors.html <img src="http://planet.debian.org/heads/dwn.png" width="77" height="85" alt="" align="right" style="float: right;"> <p><a href="https://bits.debian.org/images/Romina_Molina_dc26_2.svg"><img alt="Alt DebConf26 by Romina Molina" src="https://bits.debian.org/images/Romina_Molina_dc26_2.svg" /></a></p> <p><a href="https://debconf26.debconf.org/">DebConf26</a>, the 27th edition of the Debian conference is taking place at the <a href="https://www.fich.unl.edu.ar/">Facultad de Ingeniería en Ciencias Hídricas</a> 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.</p> <p>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.</p> <p>We have two Platinum sponsors.</p> <ul> <li> <p>Our first Platinum sponsor is <a href="https://www.proxmox.com/"><strong>Proxmox</strong></a>. 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.</p> </li> <li> <p><a href="https://www.infomaniak.com/"><strong>Infomaniak</strong></a> 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&amp;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 <a href="https://d4project.org/">d4project.org</a>.</p> </li> </ul> <p>Our Gold sponsors are:</p> <ul> <li> <p><a href="https://www.freexian.com/"><strong>Freexian</strong></a>, 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.</p> </li> <li> <p><a href="https://www.viridiengroup.com"><strong>Viridien</strong></a> 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.</p> </li> </ul> <p>Our Silver sponsors are:</p> <ul> <li><a href="https://www.arm.com/"><strong>Arm</strong></a>: 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.</li> <li><a href="https://www.pexip.com/"><strong>Pexip</strong></a> brings the ease of commercial video platforms to secure and sovereign environments without compromising control or performance.</li> <li>The <a href="https://www.bfh.ch/"><strong>Bern University of Applied Sciences</strong></a> with around 7,959 students enrolled, located in the Swiss capital.</li> <li><a href="https://www.canonical.com/"><strong>Ubuntu</strong></a>, the Operating System delivered by Canonical.</li> <li><a href="https://os-sci.com/"><strong>OS-Sci</strong></a>, Open Source Science is a world-leading institution dedicated to teaching computer science through Free and Open Source Software (FOSS).</li> <li><a href="https://www.gcoop.coop/"><strong>gcoop</strong></a>, a free software development company with over 19 years of market experience, organized as a worker cooperative, promoting best practices in software development.</li> <li><a href="https://www.qualcomm.com/developer/opensource"><strong>Qualcomm</strong></a> Technologies, one of the world's leading companies in field of mobile technology, sponsors and contributes to Open Source developer communities that drive collaboration.</li> <li><a href="https://www.cip-project.org/"><strong>Civil Infrastructure Platform</strong></a>, a collaborative project hosted by the Linux Foundation, establishing an open source “base layer” of industrial grade software.</li> <li><a href="https://opensource.siemens.com/"><strong>Siemens</strong></a> is a technology company focused on industry, infrastructure and transport.</li> <li><a href="https://www.collabora.com/"><strong>Collabora</strong></a>, a global consultancy delivering Open Source software solutions to the commercial world.</li> <li><a href="https://nerdearla.com/en/"><strong>NERDEARLA</strong></a>, the largest free tech event in the Spanish-speaking world.</li> </ul> <p>Bronze sponsors:</p> <ul> <li><a href="https://www.loongson.cn/"><strong>Loongson</strong></a>,</li> <li><a href="https://www.credativ.de/"><strong>credativ</strong></a>,</li> <li><a href="https://google.com/"><strong>Google</strong></a>,</li> <li><a href="https://www.spacemit.com/"><strong>SpacemiT</strong></a>,</li> </ul> <p>And finally, our Supporter level sponsors:</p> <ul> <li><a href="https://altusmetrum.org/"><strong>Altus Metrum</strong></a>,</li> <li><a href="https://loongfans.cn/en/"><strong>Loongson Hobbyists Community</strong></a>,</li> <li><a href="https://www.santafe.gob.ar/"><strong>Secretaría de Tecnologías para la Gestión de la Provincia de Santa Fe</strong></a></li> </ul> <p>A special thanks to the <a href="https://www.fich.unl.edu.ar/"><strong>Facultad de Ingeniería y Ciencias Hídricas - FICH UNL</strong></a>, our Venue Partner!</p> <p>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.</p> Sat, 18 Jul 2026 12:00:00 +0000 tag:www.sergiocipriano.com,2026-07-17:posts/running-gui-in-incus.md https://sergiocipriano.com/running-gui-in-incus.html <h1 id="running-graphical-applications-in-incus-containers">Running Graphical Applications in Incus Containers</h1> <p>I didn't know how easy it is to display the graphical console of a virtual machine until I tried recently.</p> <pre><code>$ sudo apt install virt-viewer $ incus launch images:debian/trixie test --vm $ incus console test --type=vga</code></pre> <p>That's it.</p> Fri, 17 Jul 2026 20:17:17 +0000 https://diffoscope.org/news/diffoscope-325-released/ https://diffoscope.org/news/diffoscope-325-released/ <p>The diffoscope maintainers are pleased to announce the release of diffoscope version <code class="language-plaintext highlighter-rouge">325</code>. This version includes the following changes:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>[ Chris Lamb ] * Fix tests to work with zipdetails 4.0008. (Closes: #1141359) * Downgrade debhelper compatibility level to 13 for now. * Update copyright years. </code></pre></div></div> <p>You find out more by <a href="https://diffoscope.org">visiting the project homepage</a>.</p> Fri, 17 Jul 2026 00:00:00 +0000 http://blog.sesse.net/blog/tech/2026-07-15-08-45_looking_at_dpkg_startup_time.html http://blog.sesse.net/blog/tech/2026-07-15-08-45_looking_at_dpkg_startup_time.html <img src="http://planet.debian.org/heads/sesse.png" width="74" height="85" alt="" align="right" style="float: right;"> <p>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.)</p> <p>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).</p> <p>Before I show the numbers, I must stress that this is an <em>investigation</em>, not a fair benchmark, and you should not go shout at the dpkg maintainers that they need to get to “catch up”. That said:</p> <pre>&gt; sudo time dpkg --root=root -i hello_2.12.3-1_amd64.deb &gt;/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 &gt; sudo time ./src/dpkg --root=root -i hello_2.12.3-1_amd64.deb &gt; /dev/null 0.04user 0.01system 0:00.15elapsed 38%CPU (0avgtext+0avgdata 6520maxresident)k 0inputs+1080outputs (0major+2705minor)pagefaults 0swaps </pre> <p>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 <em>lot</em> 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.</p> <p>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 <a href="https://distr1.org/">distri</a>, 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.</p> <p>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 <em>in total</em> (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. :-)</p> <p>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”?</p> Wed, 15 Jul 2026 07:15:23 +0000 https://etbe.coker.com.au/?p=6233 https://etbe.coker.com.au/2026/07/15/processtable-perl-debian/ <p>I’ve just filed a <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142050">Debian bug report about libproc-processtable-perl giving bad errors when SE Linux denies access to files under /proc [1]</a>.</p> <pre>Ran into unknown state (hex char: 0) at /tmp/test.pl line 8.</pre> <p>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.</p> <pre>#!/usr/bin/perl use strict; use Proc::ProcessTable; my $process_table = new Proc::ProcessTable('cache_ttys' =&gt; 0 ); foreach my $process ( @{$process_table-&gt;table} ) {   print $process-&gt;fname . "\n"; }</pre> <p>Here is the relevant part of strace output:</p> <pre>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</pre> <p>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 <b>etbe-base</b> package in that repository and the source is all there. <a href="https://www.coker.com.au/dists/trixie/misc/binary-amd64/">To access it without apt use this web page [2]</a>.</p> <pre>deb [signed-by=/usr/share/keyrings/etbe.gpg arch=amd64 ] https://www.coker.com.au trixie misc</pre> <p>I’ve also done some work on the <b>ps.monitor</b> 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.</p> <ul> <li>[1]<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142050"> https://tinyurl.com/2ckw4kh2</a></li> <li>[2]<a href="https://www.coker.com.au/dists/trixie/misc/binary-amd64/"> https://www.coker.com.au/dists/trixie/misc/binary-amd64/</a></li> </ul> <div class="yarpp yarpp-related yarpp-related-rss yarpp-template-list"> <p>Related posts:</p><ol> <li><a href="https://etbe.coker.com.au/2022/03/31/amt-mebx-debian/" rel="bookmark" title="AMT/MEBX on Debian">AMT/MEBX on Debian</a> <small>I’ve just been playing with Intel’s Active Management Technology (AMT)...</small></li> <li><a href="https://etbe.coker.com.au/2007/07/21/unaligned-access-on-ia64/" rel="bookmark" title="unaligned access on IA64">unaligned access on IA64</a> <small>I recently had some problems with unaligned access on IA64,...</small></li> <li><a href="https://etbe.coker.com.au/2026/05/09/amazfish-debian/" rel="bookmark" title="Packaging Amazfish for Debian">Packaging Amazfish for Debian</a> <small>I have done some packaging work on Amazfish (the smart-watch...</small></li> </ol> </div> Wed, 15 Jul 2026 07:07:04 +0000 http://dirk.eddelbuettel.com/blog/2026/07/14#qlcal-r_0.1.2 http://dirk.eddelbuettel.com/blog/2026/07/14#qlcal-r_0.1.2 <img src="http://planet.debian.org/heads/dirk.png" width="65" height="90" alt="" align="right" style="float: right;"> <p>The twentieth release of the <a href="https://dirk.eddelbuettel.com/code/qlcal-r.html">qlcal</a> package arrivied at <a href="https://cran.r-project.org">CRAN</a> today, and has been built for <a href="https://eddelbuettel.github.io/r2u/">r2u</a>. This version synchronises with <a href="https://www.quantlib.org">QuantLib</a> 1.43 released today as well.</p> <p><a href="https://dirk.eddelbuettel.com/code/qlcal-r.html">qlcal</a> delivers the calendaring parts of <a href="https://www.quantlib.org">QuantLib</a>. 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 <a href="https://www.quantlib.org">QuantLib</a> library (which can be demanding to build). <a href="https://dirk.eddelbuettel.com/code/qlcal-r.html">qlcal</a> covers over seventy country / market calendars and can compute holiday lists, its complement (<em>i.e.</em> business day lists) and much more. Examples are in the README at the <a href="https://github.com/qlcal/qlcal-r">repository</a>, the <a href="https://dirk.eddelbuettel.com/code/qlcal-r.html">package page</a>, and course at the <a href="https://cran.r-project.org/package=qlcal">CRAN package page</a>.</p> <p>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 <code>ccache</code> for continuous integration builds.</p> <p>The full details from <code>NEWS.Rd</code> follow.</p> <blockquote> <h4 id="changes-in-version-0.1.2-2026-07-14">Changes in version 0.1.2 (2026-07-14)</h4> <ul> <li><p>Synchronized with QuantLib 1.43</p></li> <li><p>Calendar updates for India, Israel, and South Korea; small interface update for Israle</p></li> <li><p>New calendars for Croatia, Malta, Montenegro, North Macedonia, Serbia, Slovenia, Uzebekistan</p></li> <li><p>Updates to a number of QuantLib helper functions</p></li> <li><p>Continuous integration now uses ccache via a setup action</p></li> </ul> </blockquote> <p>Courtesy of my <a href="https://dirk.eddelbuettel.com/cranberries/">CRANberries</a>, there is a diffstat report for <a href="https://dirk.eddelbuettel.com/cranberries/2026/07/14/#qlcal_0.1.2">this release</a>. See the <a href="https://dirk.eddelbuettel.com/code/qlcal-r.html">project page</a> and package documentation for more details, and more examples.</p> <p style="font-size: 80%; font-style: italic;"> This post by <a href="https://dirk.eddelbuettel.com">Dirk Eddelbuettel</a> originated on his <a href="https://dirk.eddelbuettel.com/blog/">Thinking inside the box</a> blog. If you like this or other open-source work I do, you can <a href="https://github.com/sponsors/eddelbuettel">sponsor me at GitHub</a>. </p><p></p> Wed, 15 Jul 2026 01:49:00 +0000 https://www.freexian.com/blog/debian-contributions-06-2026/ https://www.freexian.com/blog/debian-contributions-06-2026/ <img src="http://planet.debian.org/heads/freexian.png" width="215" height="101" alt="" align="right" style="float: right;"> <h1 id="debian-contributions-2026-06">Debian Contributions: 2026-06</h1> <p><a href="https://www.freexian.com/about/debian-contributions/">Contributing to Debian</a> is part of <a href="https://www.freexian.com/about/">Freexian’s mission</a>. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our <a href="https://www.freexian.com/lts/">Long Term Support contracts</a> and <a href="https://www.freexian.com/services/">consulting services</a>.</p> <h2 id="python-314-as-default-transition-by-stefano-rivera">Python 3.14 as default transition, by Stefano Rivera</h2> <p>Debian has had Python 3.13 and 3.14 in <code>unstable</code> and <code>testing</code> since December 2025, with Python 3.13 as the default version (<code>/usr/bin/python3</code> = 3.13). This gave time for packages to implement support and detect issues in their test suites.</p> <p>A slot to transition to 3.14 as default was requested from the release team <a href="https://bugs.debian.org/1130323">in March</a>, 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: <a href="https://www.python.org/downloads/release/python-31314/">3.13.14</a> and <a href="https://www.python.org/downloads/release/python-3146/">3.14.6</a>. Also in June, Python <a href="https://www.python.org/downloads/release/python-3150b2/">3.15.0 beta 2</a> and <a href="https://www.python.org/downloads/release/python-3150b3/">beta 3</a> released. Stefano uploaded these to Debian <code>experimental</code>.</p> <p>The 3.15 betas were reason to <a href="https://discuss.python.org/t/can-we-consider-an-uncoditional-change-of-abi3t-so-to-abi3t-soabi-platform-so-for-3-15-last-minute/107919">attempt to revive review</a> of a blocked <a href="https://github.com/python/cpython/pull/122917">upstream patch</a> to support Debian multiarch in stable ABI Python extensions, now that Python 3.15 is adding a new stable ABI <code>abi3t</code>.</p> <h2 id="debconf-26-preparations-by-stefano-rivera-antonio-terceiro-lucas-kanashiro-santiago-ruano-rincón-and-anupa-ann-joseph">DebConf 26 preparations, by Stefano Rivera, Antonio Terceiro, Lucas Kanashiro, Santiago Ruano Rincón and Anupa Ann Joseph</h2> <p><a href="https://debconf26.debconf.org/">DebConf 26</a>, 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.</p> <ul> <li>As usual, Stefano has been supporting the conference website and registration, helping the local team to get accurate data on attendee numbers.</li> <li>Antonio has been supporting the conference website and helping the content team to put together the conference schedule.</li> <li>Santiago has been helping the local team on different topics regarding logistics.</li> <li>Anupa assisted with the accommodation arrangements for DebCamp and DebConf, working alongside Nattie.</li> <li>Lucas has been coordinating the conference schedule and communicating with some speakers.</li> </ul> <h2 id="debvm-by-helmut-grohne">debvm, by Helmut Grohne</h2> <p>The <a href="https://salsa.debian.org/helmutg/debvm">debvm</a> 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 <code>/etc/fstab</code> 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 <code>uutils</code> and has been fixed. The <code>--architecture</code> 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 <code>autopkgtest-virt-qemu</code> using <code>--hook-dir=/usr/share/mmdebstrap/hooks/autopkgtest-create-qemu</code>. 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 <code>virtiofsd</code> succeeded, turning the proof-of-concept into production remains for later.</p> <h2 id="pconr-by-helmut-grohne">pconr, by Helmut Grohne</h2> <p>At <a href="https://debconf25.debconf.org/talks/170-reviving-unschroot/">DebConf25</a>, Helmut reported on a <a href="https://codeberg.org/shelter/reschroot">schroot</a> substitute called unschroot. The second iteration uses <a href="https://varlink.org">varlink</a> IPC to construct a container. That varlink API is now separated into a new project called <a href="https://git.subdivi.de/~helmut/pconr.git/">programmable container runtime</a>. It is meant to provide more flexibility in constructing containers than established solutions such as the <code>unshare</code> 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 href="https://git.subdivi.de/~helmut/pconr.git/tree/examples/mmdebstrap_container.py">a better containment for mmdebstrap</a> eliminating chroot escape. There also is an <a href="https://github.com/helmutg/asyncvarlink/commit/3e16139f72c7374f2ca3640045ef7162c98e7a4c">asyncvarlink/0.3.2 release</a> taking steps to become more maintainable in Debian to eventually get pconr into Debian.</p> <h2 id="miscellaneous-contributions">Miscellaneous contributions</h2> <ul> <li>Stefano did routine uploads (mostly new upstream versions) of <code>python-pip</code>, <code>python-pipx</code>, <code>hatchling</code>, <code>dh-python</code>, <code>beautifulsoup4</code>, <code>python-virtualenv</code>, <code>python-mitogen</code>.</li> <li>Stefano uploaded a snowball mini-transition: <code>snowball</code>, <code>snowball-data</code>, and <code>pystemmer</code></li> <li>Stefano did some <a href="https://wiki.debian.org/Teams/DebianNet">debian.net</a> team admin, setting up a container and later a VM for <a href="https://salsa.debian.org/debiannet-team/requests/-/work_items/36">vote.debian.net</a>.</li> <li>Stefano <a href="https://lists.debian.org/msgid-search/cer4b3szczxpt64wbzhumcm6go7tmkfvhdsqoftpevav2ovu3l@zherud2oym4p">responded</a> to a <a href="https://lists.debian.org/msgid-search/CAEd1pt5QiD9-UUV5jP=U7=L2pM5f6c1WPcUY3jWoYbcTO8iRcw@mail.gmail.com">semi-escalation</a> to the Debian Technical Committee, after some communication between an upstream, a bug reporter, and a Debian package maintainer went sideways and got heated.</li> <li>Emilio managed several transitions, and filed bugs against the few remaining GCC 13 rdeps.</li> <li>Antonio did salsa maintenance work, debugging service issues, approving user registrations, and processing support requests.</li> <li>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.</li> <li>Antonio did several maintenance tasks for MiniDebConf websites.</li> <li>Antonio uploaded ruby-bunny, ruby-sinatra and ruby-mustermann, fixing a few FTBFS bugs among them.</li> <li>Carles using <code><a href="https://salsa.debian.org/carlespina/po-debconf-manager">po-debconf-manager</a></code>: Reviewed Catalan translations for 5 packages, submitted 6 packages. Added a <a href="https://salsa.debian.org/carlespina/po-debconf-manager/-/blob/main/docs/blog/2026-06-29-update.md?ref_type=heads">draft blog/update</a> about the po-debconf-manager project.</li> <li>Carles submitted a new <a href="https://github.com/BestImageViewer/geeqie/pull/2438">Geeqie Catalan translation</a>: it had accumulated a large number of untranslated strings over the last 4 years.</li> <li>Carles contributed to the Debian wiki: improved documentation for the Framework Laptop and added a new section “<a href="https://wiki.debian.org/InstallingDebianOn/Framework/Laptop13/AMD_Ryzen_AI_300_Series#Battery_charging_control">Battery charging control</a>” (after doing some debugging and testing). He wrote a page about <a href="https://wiki.debian.org/SignalDesktop">Signal Desktop</a>. Carles started looking at testing/documenting Mailman2 -&gt; Mailman3 migration.</li> <li>Carles, in relation to the migration process, double checked old pages without relevant information in the Debian wiki.</li> <li>Thorsten did another upload of package hplip to fix some bugs.</li> <li>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 <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/livepatch/klp-build?h=v6.19">upstream klp-build</a> (that was introduced in v6.19), and compare it with <a href="https://github.com/SUSE/klp-build/">SUSE’s klp-build</a>.</li> <li>Colin <a href="https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/1149">clarified</a> the bug tracking system’s documentation to indicate that maintainers may sometimes reasonably ask users to file bugs upstream themselves.</li> <li>Colin fixed 15 packages for <a href="https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-python%40lists.debian.org&amp;tag=pytest9.1">pytest 9.1</a>.</li> <li>Colin fixed a <a href="https://bugs.debian.org/1140927">depthcharge-tools regression with Python 3.14 as default</a> that broke debian-installer builds.</li> <li>Helmut continued to report undeclared file conflicts and correspond about them.</li> <li>Helmut wrote patches for <a href="https://tracker.debian.org/strace">strace</a> to enable <a href="https://bugs.debian.org/1140559">cross building</a> and a <a href="https://bugs.debian.org/1062446">32bit personality on arm64</a>.</li> <li>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 <a href="https://lists.debian.org/debian-cross/2026/06/msg00005.html">Samuel Thibault</a>.</li> </ul> Wed, 15 Jul 2026 00:00:00 +0000 https://gwolf.org/2026/07/got-your-keys-ready-for-debconf26.html https://gwolf.org/2026/07/got-your-keys-ready-for-debconf26.html <img src="http://planet.debian.org/heads/gwolf.png" width="69" height="83" alt="" align="right" style="float: right;"> <p>Yay! Finally it’s that time of year — DebCamp is underway, and soon it will be time for DebConf! 🎉🥳</p> <p>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 <a href="https://people.debian.org/~gwolf/dc26_ksp/">DebConf26 keysigning maps</a> for everybody involved.</p> <p>So, if you are taking part of DebConf, make sure to:</p> <ul> <li> <p>Find yourself in the <a href="https://people.debian.org/~gwolf/dc26_ksp/">keysigning map</a>. Are you a part of the listing?</p> <ul> <li> <p>If you are not there, log in to the DebConf26 management system and edit the <a href="https://debconf26.debconf.org/register/step-3">Personal Information</a> section of your profile. Make sure you submit your OpenPGP key fingerprint.</p> </li> <li> <p>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 <a>pgpkeys.eu</a>, <a>keys.openpgp.org</a>, <a>keyserver.computer42.org</a>, <a>keyserver.ubuntu.com</a>, <a>keyring.debian.org</a>, <a>pgp.surf.nl</a>, <a>pgp.pm</a>, <a>pgp.mit.edu</a>, <a>the.earth.li</a>.</p> </li> </ul> </li> <li> <p>Make sure your name is readable and matches what you want others to sign. If it does not, edit your key and upload it <em>now</em>!</p> </li> <li> <p>Remember that, <a href="https://debconf26.debconf.org/about/ksp/">as announced</a>, the deadline for the final list is on <strong>Thursday, 2026.07.16, 09:00 GMT-3 (Argentinian time).</strong></p> </li> </ul> Tue, 14 Jul 2026 21:23:21 +0000 https://blog.freesources.org//posts/2026/07/zed-xdebug/ https://blog.freesources.org//posts/2026/07/zed-xdebug/ <h1 id="Nextcloud_PHP_debugging_with_Xdebug_in_Zed_editor">Nextcloud PHP debugging with Xdebug in Zed editor</h1> <p>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.</p> <p>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.</p> <p>I have Zed installed as Flatpak on a Debian Trixie host system.</p> <p>The PHP process runs in a <a href="https://github.com/juliusknorr/nextcloud-docker-dev/">nextcloud-docker-dev</a> Docker container.</p> <h2 id="Install_Zed_and_configure_debugging_there">Install Zed and configure debugging there</h2> <p>Install Zed: <code>flatpak install flathub dev.zed.Zed</code></p> <p>In Zed: open the Extensions view and install PHP.</p> <p>Configure the debugger:</p> <p>Create <code>~/.var/app/dev.zed.Zed/config/zed/debug.json</code>:</p> <pre><code class="json">[ { "label": "PHP: Listen to Xdebug", "adapter": "Xdebug", "request": "launch", "port": 9003, "pathMappings": { "/var/www/html": "/home/&lt;user&gt;/devel/nextcloud/server", "/var/www/html/apps-extra": "/home/&lt;user&gt;/devel/nextcloud/server/apps-extra", "/var/www/html/apps-shared": "/home/&lt;user&gt;/devel/nextcloud/apps-shared" } } ] </code></pre> <p>Add one entry per bind-mounted app directory.</p> <p>After creating the file, restart Zed.</p> <p>Inside Zed, select "debugger: start" from command palette and then "PHP: Listen to Xdebug".</p> <p>Verify Zed is listening. Running <code>ss -tlnp | grep 9003</code> on the host should show <code>*:9003</code> with Zed as the process.</p> <h2 id="Configure_Xdebug_inside_the_container">Configure Xdebug inside the container</h2> <p><code>/usr/local/etc/php/conf.d/xdebug.ini</code>:</p> <pre><code class="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 </code></pre> <p>Apply changes by restarting apache in the container: <code>apache2ctl -k graceful</code></p> <p>Notes:</p> <ul> <li><code>host.docker.internal</code> resolves on Linux Docker only if the container was started with <code>--add-host=host.docker.internal:host-gateway</code> (nextcloud-docker-dev already does this).</li> <li><code>discover_client_host = true</code> makes xdebug follow <code>X-Forwarded-For</code> - useful behind Nextcloud's dev reverse proxy.</li> </ul> <h2 id="Test_xdebug_with_a_PHP_command_inside_the_container">Test xdebug with a PHP command inside the container</h2> <p>Run <code>XDEBUG_SESSION=PHPSTORM php occ status</code> inside the container and check <code>/var/log/xdebug.log</code>.</p> <h2 id="Install_the_browser_extension">Install the browser extension</h2> <p>Install Xdebug Helper (Firefox/Chrome). In its preferences, set the IDE Key to PhpStorm. It will set the <code>XDEBUG_SESSION</code> cookie when toggled to Debug.</p> <p>Click the Xdebug Helper icon in the browser and set it to Debug.</p> <h2 id="Test_Xdebug_with_browser_extension">Test Xdebug with browser extension</h2> <p>Load the URL that exercises the code path with the breakpoint. Zed should stop the code exection at the breakpoint.</p> Tue, 14 Jul 2026 10:46:20 +0000 hatenablog://entry/14945776032052860672 https://kenhys.hatenablog.jp/entry/2026/07/12/231009 <img src="http://planet.debian.org/heads/kenhys.png" width="72" height="85" alt="" align="right" style="float: right;"> <h2 id="Introduction">Introduction</h2> <p>Recently, I've got a chance to try building Mozc (Most famous Japanese input method editor) with Bazel.</p> <p>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.</p> <h2 id="Background-story-about-Mozc-and-Debian">Background story about Mozc and Debian</h2> <p>The upstream of Mozc had released 3.34.6239, but on Debian, we stick to Mozc 2.29.5160.102.</p> <p>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.</p> <p>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.</p> <p>That is why the version of Mozc is diverged from upstream on Debian.</p> <ul> <li>2.29.5160.102 (Now on Debian)</li> <li>2.29.5268.102</li> <li>2.29.5374.102</li> <li>2.29.5544.102</li> <li>2.30.5544.102</li> <li>2.31.5712.102</li> <li>2.31.5851.102</li> <li>2.32.5994.102</li> <li>3.33.6089</li> <li>3.33.6133 (Target to upgrade for)</li> <li>3.34.6239</li> </ul> <h2 id="How-to-switch-from-GYP-to-Bazel">How to switch from GYP to Bazel?</h2> <p>At first, we needed to decide what Mozc version to work with it.</p> <p>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.</p> <p>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.</p> <p>That is why Mozc 3.33.6133 was chosen.</p> <p>Even once the target version has been decided, you can't let your guard down.</p> <p>There are many technical tasks to solve.</p> <ul> <li>Revisit patch sets to apply</li> <li>Porting uim mozc patch and fix FTBFS</li> <li>Porting fcitx5 mozc patch and fix FTBFS</li> <li>Fix src/third_party vendoring</li> <li>Switch from GYP to Bazel build systems</li> <li>...</li> </ul> <p>At least, it will likely require several rounds of testing in the Debian experimental.</p> <h2 id="Conclusion">Conclusion</h2> <p>Currently, <code>gbp buildpackge</code> has succeeded finally on local machine, but need to tidy and cleanup stuffs.</p> <p>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.</p> <p>In the current version of Debian, as a one of build system, further work — such as support from debhelper - will be needed.</p> <p>I'll file working progress on <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085173">#1085173</a></p> Sun, 12 Jul 2026 14:10:09 +0000 tag:copyninja.in,2026-07-21:/blog/debvulns-exporter.html https://copyninja.in/blog/debvulns-exporter.html <img src="http://planet.debian.org/heads/vasudev.png" width="65" height="85" alt="" align="right" style="float: right;"> <p>Following up on my previous <a class="reference external" href="https://copyninja.in/blog/debvulns-cli.html">post</a>, I am releasing <a class="reference external" href="https://pypi.org/project/debvulns/">debvulns-exporter</a>, a Prometheus exporter for tracking Debian system vulnerabilities. The underlying vulnerability analysis logic remains identical to the previously released MCP server and CLI utility.</p> <div class="section" id="why-an-exporter"> <h2>Why an Exporter?</h2> <p>In my engineering workflows, I frequently deal with Debian and vulnerability management. Most enterprise environments rely on commercial, paid vulnerability platforms like Tenable or Rapid7. While these platforms provide extensive feature sets, I noticed a distinct lack of open-source tools tailored for this specific pipeline. While <cite>debsecan</cite> exists, it lacks a structured, parseable format suitable for building dashboards aimed at management consumption. What started as an experimental MCP server for learning purposes evolved into a practical question: why not convert it into a Prometheus exporter? Given that Prometheus is the de facto standard metrics platform across the industry, this architecture was the logical next step.</p> </div> <div class="section" id="design-and-exported-metrics"> <h2>Design and Exported Metrics</h2> <p>The exporter is implemented as a native Prometheus exporter utilizing the <cite>prometheus-client</cite> library. It operates using two threads: one handles fetching the vulnerability data, parsing EPSS feeds, and cross-referencing installed packages to identify local vulnerabilities; the second handles serving the metrics endpoint. The full architecture details and metrics specifications can be found in the <a class="reference external" href="https://github.com/copyninja/debsecan-mcp/blob/main/docs/prometheus_exporter_design.md">design doc</a>. The specification was drafted during a technical brainstorming session with <em>Claude 4.6 Sonnet</em> on <em>Antigravity</em> prior to writing the implementation.</p> </div> <div class="section" id="testing-and-dashboarding"> <h2>Testing and Dashboarding</h2> <p>To validate the exporter, I spun up older <em>Debian 11</em> and <em>Debian 12</em> cloud images sourced from the <a class="reference external" href="https://cloud.debian.org/images/cloud/">Debian Cloud team</a>. 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:</p> <img alt="" src="https://copyninja.in/images/debvulns-exporter-setup.png" /> <p>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:</p> <img alt="" src="https://copyninja.in/images/debvulns-exporter-dashboard.png" /> <p>The complete, ready-to-import Grafana dashboard configuration is included directly in the <cite>debvulns</cite> <a class="reference external" href="https://github.com/copyninja/debsecan-mcp/blob/main/contrib/grafana/debvulns-dashboard.json">source code</a>.</p> </div> <div class="section" id="renaming-the-project"> <h2>Renaming the project</h2> <p>To prevent namespace conflicts and confusion with the native <cite>debsecan</cite> utility in Debian, I have unified the ecosystem under the <em>debvulns</em> moniker. The core CLI is named <cite>debvulns</cite>, the exporter is <cite>debvulns-exporter</cite>, and the MCP component is <cite>debvulns-mcp</cite>. The migration release has been published to <a class="reference external" href="https://pypi.org/project/debsecan-mcp/">PyPI</a>, and the new consolidated repository is active at <a class="reference external" href="https://pypi.org/project/debvulns/">debvulns</a>.</p> </div> <div class="section" id="conclusion"> <h2>Conclusion</h2> <p>While this began as a personal utility to fill a niche tool gap, I expect it will be useful for others managing Debian infrastructure at scale. My next objective is to formalize Debian packaging for both the CLI and the exporter. The MCP component will likely remain available as an independent artifact. Until then, happy hacking.</p> <p><em>Note: As a core design choice, `debvulns` still uses native `debsecan` as its ground-truth standard. The tool continuously cross-verifies its output against `debsecan` to ensure perfect functional parity and data consistency.</em></p> </div> Sun, 12 Jul 2026 11:30:25 +0000 https://reproducible-builds.org/reports/2026-06/ https://reproducible-builds.org/reports/2026-06/ <p class="lead"><strong>Welcome to the June 2026 report from the <a href="https://reproducible-builds.org">Reproducible Builds</a> project!</strong></p> <p><a href="https://reproducible-builds.org/"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/reproducible-builds.png#right" /></a></p> <p>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.</p> <p>If you are interested in contributing to the project, please visit our <a href="https://reproducible-builds.org/contribute/"><em>Contribute</em></a> page on our website.</p> <p>In this month’s report, we cover:</p> <ol> <li><a href="https://reproducible-builds.org/blog/index.rss#only-installing-reproducible-packages-with-repro-threshold">Only installing reproducible packages with <em>repro-threshold</em></a></li> <li><a href="https://reproducible-builds.org/blog/index.rss#distribution-work">Distribution work</a></li> <li><a href="https://reproducible-builds.org/blog/index.rss#diffoscope-development">diffoscope development</a></li> <li><a href="https://reproducible-builds.org/blog/index.rss#from-our-mailing-list">From our mailing list…</a></li> <li><a href="https://reproducible-builds.org/blog/index.rss#documentation-updates">Documentation updates</a></li> <li><a href="https://reproducible-builds.org/blog/index.rss#patches">Patches</a></li> <li><a href="https://reproducible-builds.org/blog/index.rss#four-new-scholarly-papers">Four new scholarly papers</a></li> </ol> <hr /> <p><br /></p> <h3 id="only-installing-reproducible-packages-with-repro-threshold">Only installing reproducible packages with <em>repro-threshold</em></h3> <p><a href="https://rebuilderd.xpam.pl:2096/demo.html"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/repro-threshold.png#center" /></a></p> <p>A <a href="https://rebuilderd.xpam.pl:2096/demo.html">very interesting demonstration</a> is now available showing how you might configure your Debian system to only install packages that have been reproduced by <em>m/n</em> rebuilders.</p> <p>This is implemented via a <code class="language-plaintext highlighter-rouge">reproduced+https://</code> <a href="https://en.wikipedia.org/wiki/APT_(software)">APT</a> transport ( a mechanism for communicating between the APT client and its repository source — commonly HTTP):</p> <blockquote> <p>Every package download is intercepted by <code class="language-plaintext highlighter-rouge">repro-threshold</code>, 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.</p> </blockquote> <p>The <a href="https://rebuilderd.xpam.pl:2096/demo.html">demo</a> gives examples of how to quickly experiment with this using a <a href="https://www.docker.com/">Docker</a> container.</p> <p><br /></p> <h3 id="distribution-work">Distribution work</h3> <p><a href="https://debian.org/"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/debian.png#right" /></a></p> <p>In <strong>Debian</strong> this month:</p> <ul> <li> <p>The <a href="https://tracker.debian.org/pkg/debian-installer"><code class="language-plaintext highlighter-rouge">debian-installer</code></a> package in Debian was uploaded with a <a href="https://tracker.debian.org/news/1768824/accepted-debian-installer-20260628-source-into-unstable/">substantial reproducibility-related changelog</a>. This means, for the first time, the <a href="https://reproduce.debian.net/excuses.html?source_name=debian-installer">uploaded version could finally be reproduced</a>.</p> </li> <li> <p>Various <a href="https://openjdk.org/">OpenJDK</a> packages were also uploaded to Debian, including the fix for <code class="language-plaintext highlighter-rouge">JDK-8385738</code> (“Javadoc does not produce reproducible output…”) (<a href="https://reproduce.debian.net/all/api/v1/builds/206100/artifacts/426780/diffoscope">for example</a>). [<a href="https://tracker.debian.org/news/1760093/accepted-openjdk-27-2724ea-2-source-into-unstable/">…</a>][<a href="https://tracker.debian.org/news/1760960/accepted-openjdk-26-26018-3-source-into-unstable/">…</a>][<a href="https://tracker.debian.org/news/1760962/accepted-openjdk-25-25044ea-1-source-into-unstable/">…</a>]</p> </li> <li> <p>The “reason” pages on <a href="https://reproduce.debian.net"><em>reproduce.debian.net</em></a>, <a href="https://reproduce.debian.net/ppc64el/stats/unstable/">such as the one for <em>ppc64el</em></a>, now feature links labeled with the <a href="https://www.compart.com/en/unicode/U+1F41B">bug emoji</a> (i.e. 🐛) which links to the categorized issues packages have been tagged with in the <code class="language-plaintext highlighter-rouge">reproducible-notes.git</code> repo.</p> </li> <li> <p>Indeed, 25 reviews of Debian packages were added, 31 were updated and 33 were removed this month adding to <a href="https://tests.reproducible-builds.org/debian/index_issues.html">our extensive knowledge about identified issues</a>. Two issue types were updated as well. [<a href="https://salsa.debian.org/reproducible-builds/reproducible-notes/commit/a2302451">…</a>][<a href="https://salsa.debian.org/reproducible-builds/reproducible-notes/commit/9e09f1ee">…</a>]</p> </li> </ul> <p><a href="https://apt.izzysoft.de/fdroid/"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/izzyondroid.png#right" /></a></p> <p>The <a href="https://apt.izzysoft.de/fdroid/"><strong>IzzyOnDroid</strong></a> Android APK repository reached its next milestone this month, now covering 2 out of every 3 apps (66.7%) with reproducible builds. Their <a href="https://izzyondroid.org/docs/reproducibleBuilds/DebugFailedRBs/">documentation for debugging and fixing failed builds</a> has steadily grown as well. More clients have picked up showing reproducibility results (e.g. Droid-ify), and <a href="https://apt.izzysoft.de/packages/com.machiav3lli.fdroid">Neo Store</a> now can be configured to stick to only reproducible applications. Further, an <a href="https://shields.rbtlog.dev/">independent builder</a> has been added to the build farm, increasing the trust level even more as APK builds can have multiple confirmations now.</p> <p>At the same time, IzzyOnDroid’s <a href="https://codeberg.org/IzzyOnDroid/rbtlog"><em>rbtlog</em></a> got several new features. The most outstanding is caching for frequently used resources such as <a href="https://github.com/obfusk/reproducible-apk-tools"><em>reproducible-apk-tools</em></a>, 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.</p> <p><br /></p> <p><a href="https://www.opensuse.org/"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/opensuse.png#right" /></a></p> <p>Lastly, Bernhard M. Wiedemann posted another <a href="https://www.opensuse.org/"><strong>openSUSE</strong></a> <a href="https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/LQPMRQ5W3XJ7RWAQ6ITI4EY2EDVTVHKA/">monthly update</a> for their reproducibility work there.</p> <p><br /></p> <h3 id="diffoscope-development"><em>diffoscope</em> development</h3> <p><a href="https://diffoscope.org/"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/diffoscope.png#right" /></a></p> <p><a href="https://diffoscope.org"><strong>diffoscope</strong></a> 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 <a href="https://tracker.debian.org/news/1762589/accepted-diffoscope-319-source-into-unstable/">319</a>, <a href="https://tracker.debian.org/news/1764827/accepted-diffoscope-320-source-into-unstable/">320</a>, <a href="https://tracker.debian.org/news/1764860/accepted-diffoscope-321-source-into-unstable/">321</a>, <a href="https://tracker.debian.org/news/1767978/accepted-diffoscope-322-source-into-unstable/">322</a> and <a href="https://tracker.debian.org/news/1769647/accepted-diffoscope-323-source-into-unstable/">323</a> to Debian:</p> <ul> <li>Debian adds an extra <code class="language-plaintext highlighter-rouge">Flags:</code> line in the output of <code class="language-plaintext highlighter-rouge">ocamlobjinfo</code>, so adjust the test for cross-distribution compatibility. [<a href="https://salsa.debian.org/reproducible-builds/diffoscope/commit/3a2303e5">…</a>]</li> <li>Bump debhelper compatibility level to 14. [<a href="https://salsa.debian.org/reproducible-builds/diffoscope/commit/ae1d587a">…</a>]</li> <li>Fix compatibility with Ocaml 5.4.1. [<a href="https://salsa.debian.org/reproducible-builds/diffoscope/commit/50476c66">…</a>]</li> <li>Use <code class="language-plaintext highlighter-rouge">--long-form</code>-style arguments when calling <code class="language-plaintext highlighter-rouge">apktool</code> in order to support <em>apktool</em> version 3. [<a href="https://salsa.debian.org/reproducible-builds/diffoscope/commit/02c65572">…</a>]</li> <li>Support Androguard version 4 and previous versions at the same time. [<a href="https://salsa.debian.org/reproducible-builds/diffoscope/commit/2b17885b">…</a>]</li> <li>Update copyright years. [<a href="https://salsa.debian.org/reproducible-builds/diffoscope/commit/bf7aa877">…</a>]</li> </ul> <p>In addition, Jochen Sprickerhof added better header detection for the <a href="https://www.sphinx-doc.org/en/master/">Sphinx documentation system</a> [<a href="https://salsa.debian.org/reproducible-builds/diffoscope/commit/b800d697">…</a>], Michael Daniels fixed the tests when run with <em>zipdetails</em> version 4.006 [<a href="https://salsa.debian.org/reproducible-builds/diffoscope/commit/fade8d04">…</a>] and Zbigniew Jędrzejewski-Szmek added a version of the deprecated <code class="language-plaintext highlighter-rouge">os.path.commonprefix</code> method [<a href="https://salsa.debian.org/reproducible-builds/diffoscope/commit/2af9e134">…</a>].</p> <p>In addition, Vagrant Cascadian <a href="https://codeberg.org/guix/guix/commit/43f80a83c99f7e3bf82cc27c5a95b9aead659ee6">updated <em>diffoscope</em> in GNU Guix to version <code class="language-plaintext highlighter-rouge">321</code></a> and <a href="https://codeberg.org/guix/guix/commit/636a104836fe00fca5844e15e3c40c9cf5cd1427"><code class="language-plaintext highlighter-rouge">323</code></a>.</p> <p><br /></p> <p>Chris Lamb also made the following changes to <em><a href="https://tracker.debian.org/pkg/strip-nondeterminism">strip-nondeterminism</a></em>, our tool to remove specific non-deterministic results from a completed build:</p> <ul> <li>Skip symlinks when manually called via <code class="language-plaintext highlighter-rouge">/usr/bin/strip-nondeterminism</code>. (<a href="https://bugs.debian.org/1139000">#1139000</a>)</li> <li>Update <code class="language-plaintext highlighter-rouge">debian/watch</code> format. [<a href="https://salsa.debian.org/reproducible-builds/strip-nondeterminism/commit/9042813">…</a>]</li> <li>Drop <code class="language-plaintext highlighter-rouge">Rules-Requires-Root: no</code> and <code class="language-plaintext highlighter-rouge">Priority: optional</code> fields. [<a href="https://salsa.debian.org/reproducible-builds/strip-nondeterminism/commit/7399bc4">…</a>]</li> <li>Bump <code class="language-plaintext highlighter-rouge">Standards-Version</code> to version 4.7.4. [<a href="https://salsa.debian.org/reproducible-builds/strip-nondeterminism/commit/aa3e692">…</a>]</li> </ul> <p><br /></p> <h3 id="from-our-mailing-list">From our mailing list…</h3> <p>On <a href="https://lists.reproducible-builds.org/listinfo/rb-general/">our mailing list</a> this month:</p> <ul> <li> <p><em>kpcyrd</em> posted to our mailing list regarding the “waves of malware uploads to <a href="https://aur.archlinux.org/">aur.archlinux.org</a>”. Curiously, “every incident I looked at used npmjs.com for malware delivery”, specifically where the <code class="language-plaintext highlighter-rouge">npm</code> package includes an (automatically executed) <code class="language-plaintext highlighter-rouge">preinstall</code> script that is an ELF binary.</p> </li> <li> <p><em>kpcyrd</em> also announced the release of <a href="https://github.com/kpcyrd/debian-repro-status"><em>debian-repro-status</em></a> version <a href="https://github.com/kpcyrd/debian-repro-status/releases/tag/v0.4.0">0.4.0</a>, 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”:</p> <blockquote> <p>The change updates dependencies to the latest versions, and adds support for multiple <code class="language-plaintext highlighter-rouge">-H</code> options, to query results from multiple rebuilderd instances. The results are also now fetched concurrently.</p> </blockquote> </li> <li> <p><em>kpcyrd</em> also reported that, whilst taking a screenshot for the above release, they noticed that the <code class="language-plaintext highlighter-rouge">debian:sid</code> <a href="https://lists.reproducible-builds.org/pipermail/rb-general/2026-June/004121.html">container now is 100% reproducible</a>.</p> </li> <li> <p>Finally, <em>kpcyrd</em> <strong>also</strong> <a href="https://github.com/keszybz/add-determinism/pull/78">created a pull request</a> against the <a href="https://github.com/keszybz/add-determinism"><em>add-determinism</em></a> package to update the <a href="https://docs.python.org/3/library/itertools.html"><code class="language-plaintext highlighter-rouge">itertools</code></a> and <a href="https://docs.python.org/3/library/zipfile.html"><code class="language-plaintext highlighter-rouge">zip</code></a> Python dependencies.</p> </li> </ul> <p><br /></p> <h3 id="documentation-updates">Documentation updates</h3> <p><a href="https://reproducible-builds.org/"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/website.png#right" /></a></p> <p>Yet again, there were a number of improvements made to our website this month including:</p> <ul> <li> <p>Chris Lamb added a reminder re. using the UTC variants of the Javascript <code class="language-plaintext highlighter-rouge">Date</code> methods. [<a href="https://salsa.debian.org/reproducible-builds/reproducible-website/commit/27245b53">…</a>]</p> </li> <li> <p>Mattia Rizzolo moved <a href="https://www.opentech.fund/">OTF</a> to the ‘old’ sponsors list. Thank you for your support!. [<a href="https://salsa.debian.org/reproducible-builds/reproducible-website/commit/d029630d">…</a>]</p> </li> <li> <p><em>kpcyrd</em> updated the <a href="https://rust-lang.org/">Rust</a> documentation to recommend using the <code class="language-plaintext highlighter-rouge">--release</code> argument for consistency. [<a href="https://salsa.debian.org/reproducible-builds/reproducible-website/commit/f5d645e5">…</a>]</p> </li> </ul> <p><br /></p> <h3 id="patches">Patches</h3> <p>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:</p> <ul> <li> <p>Bernhard M. Wiedemann:</p> <ul> <li><a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1268265"><code class="language-plaintext highlighter-rouge">cvise</code></a></li> <li><a href="https://build.opensuse.org/request/show/1362390"><code class="language-plaintext highlighter-rouge">efl</code></a></li> <li><a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1268542"><code class="language-plaintext highlighter-rouge">gettext-runtime/bash</code></a></li> <li><a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1268340"><code class="language-plaintext highlighter-rouge">hadrian</code></a></li> <li><a href="https://build.opensuse.org/request/show/1362888"><code class="language-plaintext highlighter-rouge">plasma6-keyboard</code></a></li> <li><a href="https://invent.kde.org/frameworks/syntax-highlighting/-/merge_requests/806"><code class="language-plaintext highlighter-rouge">syntax-highlighting</code></a></li> </ul> </li> <li> <p>Chris Lamb:</p> <ul> <li><a href="https://bugs.debian.org/1139654">#1139654</a> filed against <a href="https://tracker.debian.org/pkg/node-fuse.js"><code class="language-plaintext highlighter-rouge">node-fuse.js</code></a>.</li> <li><a href="https://bugs.debian.org/1139655">#1139655</a> filed against <a href="https://tracker.debian.org/pkg/node-egjs-hammerjs"><code class="language-plaintext highlighter-rouge">node-egjs-hammerjs</code></a>.</li> <li><a href="https://bugs.debian.org/1139656">#1139656</a> filed against <a href="https://tracker.debian.org/pkg/node-chartjs-adapter-date-fns"><code class="language-plaintext highlighter-rouge">node-chartjs-adapter-date-fns</code></a>.</li> <li><a href="https://bugs.debian.org/1139662">#1139662</a> filed against <a href="https://tracker.debian.org/pkg/mkdocs-include-markdown-plugin"><code class="language-plaintext highlighter-rouge">mkdocs-include-markdown-plugin</code></a>.</li> <li><a href="https://bugs.debian.org/1139704">#1139704</a> filed against <a href="https://tracker.debian.org/pkg/lmarbles"><code class="language-plaintext highlighter-rouge">lmarbles</code></a>.</li> <li><a href="https://bugs.debian.org/1140240">#1140240</a> filed against <a href="https://tracker.debian.org/pkg/rocm-docs-core"><code class="language-plaintext highlighter-rouge">rocm-docs-core</code></a>.</li> <li><a href="https://bugs.debian.org/1140567">#1140567</a> filed against <a href="https://tracker.debian.org/pkg/libecoli"><code class="language-plaintext highlighter-rouge">libecoli</code></a>.</li> <li><a href="https://bugs.debian.org/1140688">#1140688</a> filed against <a href="https://tracker.debian.org/pkg/golang-github-tobischo-gokeepasslib"><code class="language-plaintext highlighter-rouge">golang-github-tobischo-gokeepasslib</code></a>.</li> </ul> </li> <li> <p>Jochen Sprickerhof:</p> <ul> <li><a href="https://bugs.debian.org/1139457">#1139457</a> filed against <a href="https://tracker.debian.org/pkg/c-munipack"><code class="language-plaintext highlighter-rouge">c-munipack</code></a>.</li> <li><a href="https://bugs.debian.org/1140365">#1140365</a> filed against <a href="https://tracker.debian.org/pkg/latex-coffee-stains"><code class="language-plaintext highlighter-rouge">latex-coffee-stains</code></a>.</li> <li><a href="https://bugs.debian.org/1140366">#1140366</a> filed against <a href="https://tracker.debian.org/pkg/cxxtest"><code class="language-plaintext highlighter-rouge">cxxtest</code></a>.</li> <li><a href="https://bugs.debian.org/1140367">#1140367</a> filed against <a href="https://tracker.debian.org/pkg/slime"><code class="language-plaintext highlighter-rouge">slime</code></a>.</li> <li><a href="https://bugs.debian.org/1140368">#1140368</a> filed against <a href="https://tracker.debian.org/pkg/spooles"><code class="language-plaintext highlighter-rouge">spooles</code></a>.</li> <li><a href="https://bugs.debian.org/1140369">#1140369</a> filed against <a href="https://tracker.debian.org/pkg/sdpb"><code class="language-plaintext highlighter-rouge">sdpb</code></a>.</li> <li><a href="https://bugs.debian.org/1140645">#1140645</a> filed against <a href="https://tracker.debian.org/pkg/procmail"><code class="language-plaintext highlighter-rouge">procmail</code></a>.</li> <li><a href="https://bugs.debian.org/1140676">#1140676</a> filed against <a href="https://tracker.debian.org/pkg/proftpd-dfsg"><code class="language-plaintext highlighter-rouge">proftpd-dfsg</code></a>.</li> <li><a href="https://bugs.debian.org/1141059">#1141059</a> filed against <a href="https://tracker.debian.org/pkg/mah-jong"><code class="language-plaintext highlighter-rouge">mah-jong</code></a>.</li> <li><a href="https://bugs.debian.org/1141133">#1141133</a> filed against <a href="https://tracker.debian.org/pkg/dxf2gcode"><code class="language-plaintext highlighter-rouge">dxf2gcode</code></a>.</li> <li><a href="https://bugs.debian.org/1141194">#1141194</a> filed against <a href="https://tracker.debian.org/pkg/afterstep"><code class="language-plaintext highlighter-rouge">afterstep</code></a>.</li> <li><a href="https://bugs.debian.org/1141195">#1141195</a> filed against <a href="https://tracker.debian.org/pkg/ledger2beancount"><code class="language-plaintext highlighter-rouge">ledger2beancount</code></a>.</li> <li><a href="https://bugs.debian.org/1141196">#1141196</a> filed against <a href="https://tracker.debian.org/pkg/ocamlviz"><code class="language-plaintext highlighter-rouge">ocamlviz</code></a>.</li> </ul> </li> <li> <p>Kris Van Hee and Vagrant Cascadian:</p> <ul> <li><a href="https://bugs.debian.org/1140167">#1140167</a> filed against <a href="https://tracker.debian.org/pkg/dtrace"><code class="language-plaintext highlighter-rouge">dtrace</code></a>.</li> </ul> </li> </ul> <p><br /></p> <h3 id="four-new-scholarly-papers">Four new scholarly papers</h3> <p><a href="https://lab.iisec.ac.jp/~suzaki_lab/PDF/DSN-HAP26_muto.pdf"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/DSN-HAP26_muto.png#right" /></a></p> <p>Kenichiro Muto and Kuniyasu Suzaki of the <a href="https://www.iisec.ac.jp/english/">Institute of Information Security</a> in Yokohama, Japan published an interesting paper this month titled <a href="https://lab.iisec.ac.jp/~suzaki_lab/PDF/DSN-HAP26_muto.pdf"><em>Attestable Build Chain: Enabling Trust in Reproducible Builds</em></a> (PDF). Their abstract is as follows:</p> <p>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. [<a href="https://lab.iisec.ac.jp/~suzaki_lab/PDF/DSN-HAP26_muto.pdf">…</a>]</p> <p><br /></p> <p><a href="https://hal.science/hal-05630285v1"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/2025-nixpkgs-reproducibility-extended.png#right" /></a></p> <p>Julien Malka, Stefano Zacchiroli and Théo Zimmermann published a 50-page report detailing <a href="https://hal.science/hal-05630285v1"><em>A Decade of Software Reproducibility in the Nix Package Ecosystem</em></a>:</p> <blockquote> <p>We find that functional package management enables extremely high rebuildability over time (<strong>near-universal ability to reconstitute historical build environments and rebuild software packages</strong>), 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 <a href="https://diffoscope.org/"><em>diffoscope</em></a>.</p> </blockquote> <p>A <a href="https://hal.science/hal-05630285v1/file/2025-nixpkgs-reproducibility-extended.pdf">PDF of their report</a> is available online</p> <p><br /></p> <p><a href="https://devguard.org/research-development/bit-for-bit-building-sovereign-reproducible-container-supply-chain-devguard.pdf"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/bit-for-bit-building-sovereign-reproducible-container-supply-chain-devguard.png#right" /></a></p> <p>Tim Bastin of <a href="https://l3montree.com/">L3montree GmbH</a> and Jacek Galowicz of <a href="https://applicative.systems/">Applicative Systems GmbH</a> from <a href="https://devguard.org/">DevGuard</a> published a paper detailing <a href="https://devguard.org/research-development/bit-for-bit-building-sovereign-reproducible-container-supply-chain-devguard.pdf"><em>How We Built a Sovereign, Reproducible Container Supply Chain for DevGuard</em></a>:</p> <blockquote> <p>This paper presents how the <a href="https://devguard.org/">DevGuard</a> project rebuilt its <a href="https://opencontainers.org/">OCI container</a> pipeline around reproducible <a href="https://nixos.org/">Nix</a> builds and independent dual-platform digest verification. DevGuard images are built hermetically from pinned source revisions, signed with <a href="https://github.com/sigstore/cosign">Sigstore/Cosign</a>, 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.</p> </blockquote> <p><br /></p> <p><a href="https://www.sciencedirect.com/science/article/pii/S2405959526001086"><img alt="" src="https://reproducible-builds.org/images/reports/2026-06/1-s2.0-S2405959526001086-main.png#right" /></a></p> <p>Finally, Yiseul Choi, Junga Kim, Jun-Ho Hong and Seongmin Kim of the <a href="https://www.sungshin.ac.kr/main_eng/15348/subview.do">Department of Convergence Security Engineering</a> at the <a href="https://www.sungshin.ac.kr/">Sungshin Women’s University</a> in Seoul, Korea titled <a href="https://www.sciencedirect.com/science/article/pii/S2405959526001086"><em>Attestation-based verification of SBOM integrity via consumer-side reproducibility</em></a>:</p> <blockquote> <p>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</p> </blockquote> <p><br /> <br /></p> <p>Finally, if you are interested in contributing to the Reproducible Builds project, please visit our <a href="https://reproducible-builds.org/contribute/"><em>Contribute</em></a> page on our website. However, you can get in touch with us via:</p> <ul> <li> <p>IRC: <code class="language-plaintext highlighter-rouge">#reproducible-builds</code> on <code class="language-plaintext highlighter-rouge">irc.oftc.net</code>.</p> </li> <li> <p>Mastodon: <a href="https://fosstodon.org/@reproducible_builds">@reproducible_builds@fosstodon.org</a></p> </li> <li> <p>Mailing list: <a href="https://lists.reproducible-builds.org/listinfo/rb-general"><code class="language-plaintext highlighter-rouge">rb-general@lists.reproducible-builds.org</code></a></p> </li> </ul> Sat, 11 Jul 2026 19:27:22 +0000 https://current.workingdirectory.net/posts/2026/dns-high-availability/ https://current.workingdirectory.net/posts/2026/dns-high-availability/ <p>At <a href="https://mayfirst.coop">May First</a>, we recently received (all within a single week) three different complaints about domain names that previously worked fine suddenly not resolving to our servers.</p> <p>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 (<code>a.mx.mayfirst.org</code>, <code>b.mx.mayfirst.org</code> and <code>c.mx.mayfirst.org</code>) instead of our name servers (<code>a.ns.mayfirst.org</code>, <code>b.ns.mayfirst.org</code> and <code>c.ns.mayfirst.org</code>). 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.</p> <p>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. <em>How could registrar records spontaneously change?</em> 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!?!?</p> <p>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:</p> <ul> <li>raise your fist in the air with <code>a.ns.mayfist.org</code>!</li> <li>or just plain give up and hit the floor with <code>a.ns.matfirst.org</code></li> <li>Or more commonly people added our name servers, but also left the default name servers in place.</li> <li>Also, one person added as their authoritative name servers: <code>a.ns.mayfirst.org</code>, <code>b.ns.mayfirst.org</code>, <code>c.ns.mayfirst.org</code>, <code>a.mx.mayfirst.org</code>, <code>b.mx.mayfirst.org</code>, <code>c.mx.mayfirst.org</code>, and even <code>a.webproxy.mayfirst.org</code> - in other words, all the domain names we tell you do to anything with.</li> <li>And lastly, I did find two more domains just pointing to <code>a.mx.mayfirst.org</code>, <code>b.mx.mayfirst.org</code> and <code>c.mx.mayfirst.org</code>.</li> </ul> <p>That’s when it occurred to me: for years we have maintained an offsite server that provides <em>both</em> <code>c.ns.mayfirst.org</code> and <code>c.mx.mayfirst.org</code>. 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 <code>c.mx.mayfirst.org</code> 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.</p> <p>So… mystery solved. Nobody’s authoritative registrar records “suddenly” changed. They were mis-configured for years but <em>thanks to the amazing resilience of the DNS system, nobody noticed because just one working DNS server is all you need.</em></p> Sat, 11 Jul 2026 12:27:10 +0000 http://dirk.eddelbuettel.com/blog/2026/07/10#rquantlib_0.4.28 http://dirk.eddelbuettel.com/blog/2026/07/10#rquantlib_0.4.28 <img src="http://planet.debian.org/heads/dirk.png" width="65" height="90" alt="" align="right" style="float: right;"> <p>A new minor release 0.4.28 of <a href="https://dirk.eddelbuettel.com/code/rquantlib.html">RQuantLib</a> arrived on <a href="https://cran.r-project.org">CRAN</a> this evening, has been uploaded to <a href="https://www.debian.org">Debian</a>, and is being built for <a href="https://eddelbuettel.github.io/r2u/">r2u</a> as well.</p> <p><a href="https://www.quantlib.org">QuantLib</a> is a rather comprehensice <em>free/open-source</em> library for quantitative finance. <a href="https://dirk.eddelbuettel.com/code/rquantlib.html">RQuantLib</a> connects (some parts of) it to the R environment and language, and has been part of <a href="https://cran.r-project.org">CRAN</a> for nearly twenty-three years (!!) as it was one of the first packages I uploaded to <a href="https://cran.r-project.org">CRAN</a>.</p> <p>This release of <a href="https://dirk.eddelbuettel.com/code/rquantlib.html">RQuantLib</a> 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 <a href="https://dirk.eddelbuettel.com/code/rquantlib.html">RQuantLib</a> to catch up. Full details from the NEWS file follow as usual.</p> <blockquote> <h4 id="changes-in-rquantlib-version-0.4.28-2026-07-10">Changes in <span class="pkg">RQuantLib</span> version 0.4.28 (2026-07-10)</h4> <ul> <li><p>Adjust to Israel calendar constructor change in QuantLib 1.43</p></li> <li><p>Continuous integration uses ccache-with-R action</p></li> </ul> </blockquote> <p>Courtesy of my <a href="https://dirk.eddelbuettel.com/cranberries/">CRANberries</a>, there is also a <a href="https://dirk.eddelbuettel.com/cranberries/2026/07/10/#RQuantLib_0.4.28">diffstat report</a> for the this release. As always, more detailed information is on the <a href="https://dirk.eddelbuettel.com/code/rquantlib.html">RQuantLib page</a>. Questions, comments etc should go to the <a href="https://groups.io/g/rquantlib">rquantlib-devel mailing list</a>. Issue tickets can be filed at the <a href="https://github.com/eddelbuettel/rquantlib">GitHub repo</a>.</p> <p style="font-size: 80%; font-style: italic;"> This post by <a href="https://dirk.eddelbuettel.com">Dirk Eddelbuettel</a> originated on his <a href="https://dirk.eddelbuettel.com/blog/">Thinking inside the box</a> blog. If you like this or other open-source work I do, you can now <a href="https://github.com/sponsors/eddelbuettel">sponsor me at GitHub</a>. </p><p></p> Sat, 11 Jul 2026 03:35:00 +0000 https://jmtd.net/log/fly30/ https://jmtd.net/log/fly30/ <img src="http://planet.debian.org/heads/jmtd.png" width="65" height="85" alt="" align="right" style="float: right;"> <p>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 <a href="https://jmtd.net/log/ouch/">ill</a>. I restarted in 2025, initially with a weekly skate session but last month I started group hockey skate lessons.</p> <div class="centre"> <div class="image+centre"> <a href="https://jmtd.net/log/fly30/heat.jpg"><img alt="IR photo of me skating" class="img" height="378" src="https://jmtd.net/log/fly30/400x-heat.jpg" width="400" /></a> <p></p><p>There's not a lot of pics of me skating… this one from an IR camera</p><p></p> </div> </div> <p>I've been skating in a pair of Bauer<sup id="fnref:1"><a href="https://jmtd.net/log/#fn:1" rel="footnote">1</a></sup> Nexus N77s that I bought <a href="https://jmtd.net/log/Toronto/">7 years ago on a work trip to Toronto</a>. 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.</p> <p>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 <em>much</em> 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.</p> <div class="centre"> <div class="image+centre"> <a href="https://jmtd.net/log/fly30/skates.jpg"><img alt="new and old skates" class="img" height="225" src="https://jmtd.net/log/fly30/400x-skates.jpg" width="400" /></a> <p>new and old skates</p> </div> </div> <p>I have unfortunately gained a common problem: arch pain. More precisely, my navicular bone seems to be quite prominent<sup id="fnref:2"><a href="https://jmtd.net/log/#fn:2" rel="footnote">2</a></sup>, 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.</p> <p>The last time I skated I tried to throw everything at the problem: I'd had the skates baked<sup id="fnref:3"><a href="https://jmtd.net/log/#fn:3" rel="footnote">3</a></sup>; 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 <em>seemed</em> a bit better.</p> <p>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 <em>can</em> compensate for the size with tight lacing, but I had no confidence in them, I couldn't lean into the turns. They just felt <em>weird</em>. I realised there's no way back.</p> <p>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 <em>some</em> 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 <em>punch out</em>.</p> <div class="footnotes"> <hr /> <ol> <li id="fn:1"> I've owned four pairs of skates: all hockey, my first were Bauers, my second CCM Tacks of some kind. I've no idea what happened to them.<a href="https://jmtd.net/log/#fnref:1" rev="footnote">↩</a></li> <li id="fn:2"> Or possibly I have <em>accessory navicular</em> bones<a href="https://jmtd.net/log/#fnref:2" rev="footnote">↩</a></li> <li id="fn:3"> modern mid-tier skates are thermoformable, and many skate shops carry a specially designed oven to briefly bake skates such that you wear them as they cool and the padding should mould to your foot.<a href="https://jmtd.net/log/#fnref:3" rev="footnote">↩</a></li> </ol> </div> Fri, 10 Jul 2026 20:57:20 +0000 https://retout.co.uk/2026/07/10/blocking-distracting-news-links/ https://retout.co.uk/2026/07/10/blocking-distracting-news-links/ <p><em>“You are what you eat”</em> – 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.</p> <h3 id="we-have-created-an-obesogenic-information-environment">We have created an “obesogenic” information environment</h3> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <h3 id="only-44-of-bbc-news-is-news">Only 44% of BBC News is news</h3> <p>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.</p> <p>I’ve taken a screenshot of a <a href="https://www.bbc.co.uk/news/articles/cly9r54e5r4o">random BBC News article</a> 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.</p> <p><img alt="A full-length screenshot of a BBC News article showing proportions of the page allocated to the main article vs. related links etc." src="https://retout.co.uk/2026/bbc-news-website.drawio.svg" /></p> <p>(These numbers will not sum to 100% for reasons which are obvious if you look at the crossbars. Also they’re approximations.)</p> <p>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. <em>I do not want this.</em></p> <p>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.</p> <p>And remember, this is a publicly-funded site that does not rely on advertising!</p> <h3 id="blocking-out-the-noise">Blocking out the noise</h3> <p>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 &gt; My filters) brutally cuts out almost all of these links:</p> <div class="code-block-wrapper"><pre tabindex="0"><code>bbc.co.uk##aside bbc.co.uk##footer&gt;div:has(h2) bbc.co.uk##[data-block="uploaderEmbed"] bbc.co.uk##[data-block="links"]</code></pre></div> <p><em>Caveat emptor:</em> 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.</p> <p>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.</p> <h3 id="product-managers-please-find-better-metrics">Product managers, please find better metrics</h3> <p>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.</p> <p>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.</p> <p>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.</p> <p>Product managers, over to you.</p> Fri, 10 Jul 2026 15:00:00 +0000 http://www.netfort.gr.jp/~dancer/diary/daily/2026-Jul-10.html.en#2026-Jul-10-18:04:45 http://www.netfort.gr.jp/~dancer/diary/daily/2026-Jul-10.html.en#2026-Jul-10-18:04:45 <img src="http://planet.debian.org/heads/dancer.png" width="75" height="97" alt="" align="right" style="float: right;"> July already. Wow. It's getting to be a summer. <p></p> Fri, 10 Jul 2026 09:04:45 +0000 tag:bits.debian.org,2026-07-10:/2026/07/new-developers-2026-07.html https://bits.debian.org/2026/07/new-developers-2026-07.html <img src="http://planet.debian.org/heads/dwn.png" width="77" height="85" alt="" align="right" style="float: right;"> <p>The following contributors got their Debian Developer accounts in the last two months:</p> <ul> <li>Vivek K J (vivek)</li> <li>Benjamin Somers (bensmrs)</li> <li>Colin King (colinianking)</li> <li>Nadzeya Hutsko (nadzeya)</li> </ul> <p>The following contributors were added as Debian Maintainers in the last two months:</p> <ul> <li>Pieter Lenaerts</li> <li>Syed Shahrukh Hussain</li> <li>Ural Tunaboyu</li> </ul> <p>Congratulations!</p> Fri, 10 Jul 2026 07:00:00 +0000 https://diffoscope.org/news/diffoscope-324-released/ https://diffoscope.org/news/diffoscope-324-released/ <p>The diffoscope maintainers are pleased to announce the release of diffoscope version <code class="language-plaintext highlighter-rouge">324</code>. This version includes the following changes:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>[ Paul Spooren ] * Allow trailing garbage in Gzip files. [ Chris Lamb ] * Bump debhelper compatibility level to 14. </code></pre></div></div> <p>You find out more by <a href="https://diffoscope.org">visiting the project homepage</a>.</p> Fri, 10 Jul 2026 00:00:00 +0000 https://blog.trueelena.org/blog/2026/07/10-cockades/index.html https://blog.trueelena.org/blog/2026/07/10-cockades/index.html <article> <section class="header"> Posted on July 10, 2026 <br /> Tags: <a href="https://blog.trueelena.org/tags/madeof%3Aatoms.html" title="All pages tagged 'madeof:atoms'.">madeof:atoms</a>, <a href="https://blog.trueelena.org/tags/FreeSoftWear.html" title="All pages tagged 'FreeSoftWear'.">FreeSoftWear</a>, <a href="https://blog.trueelena.org/tags/craft%3Asewing.html" title="All pages tagged 'craft:sewing'.">craft:sewing</a> </section> <section> <p><img alt="six cockades in black, grey, white, purple, in different sizes and with different centrepieces. One is only black and white and has a penguin pin in the middle." class="align-center" src="https://blog.trueelena.org/blog/2026/07/10-cockades/pile_of_cockades.jpg" style="width: 80.0%;" /></p> <p>Earlier this year, I made myself a new hat (it will be blogged), and I wanted to put a nice cockade on it. So, I looked for suitable ribbons, and couldn’t find any. I found some ribbon that looked passable, but the colours I wanted weren’t available, so I set up the website to notify me, and kept working on the hat.</p> <p>Eventually the hat was done, the ribbon was still not available, so I decorated the hat with fake flowers from my stash, and started wearing it.</p> <p>And that’s when I got notified that the ribbon was back in stock.</p> <p>By the time the ribbon arrived, I had decided that the hat looked better with the flowers, and project cockade was put on hold, possibly for a future hat.</p> <p>And then June came, and what could be a better time than that for a project based on flag colours?</p> <p>As I feared, the ribbon I got wasn’t the best: it was a bit too stiff and plasticy, and not really usable for many other things. It did however work well enough for a cockade, and I decided it was a good chance to try different methods and designs, and then make another one to take pictures and publish step-by-step instructions.</p> <p>And that’s the perfect recipe to find oneself surrounded by a somewhat unreasonable number of very similar cockades, I guess.</p> <p><img alt="A big cockade with four ribbons, starting with purple on the outside, and a black bead in the middle covering the centre of the black ribbon. The pleating isn't the most regular, and the black ribbon at the centre is almost more gathered than pleated." class="align-center" src="https://blog.trueelena.org/blog/2026/07/10-cockades/number_one.jpg" style="width: 80.0%;" /></p> <p>I looked around for instructions, and the ones that gave a result that was closer to my mental idea of a cockade were the ones by <a href="https://blog.americanduchess.com/2010/04/how-to-make-18th-c-cockades.html">American Duchess</a>, so on my first attempt I tried to follow those.</p> <p>I didn’t have a cork board with a hole, so it was a bit fiddly, and the result was passable, but could have been better. Meanwhile I saw <a href="https://www.authentic-campaigner.com/forum/military-forums/camp-of-instruction/18697-easy-to-make-cockades#post163741">a forum post commenting on the above tutorial</a> and that gave me ideas for a procedure more suitable to the tools I had.</p> <p><img alt="A cockade with tree ribbons, starting with purple on the outside, then white, grey, and a black bead in the middle that is a bit bigger than the one on the previous one. The pleating isn't perfect, but neater than the previous one." class="align-center" src="https://blog.trueelena.org/blog/2026/07/10-cockades/number_two.jpg" style="width: 80.0%;" /></p> <p>The second cockade I made was indeed more satisfactory, and I also started to experiment with making a center piece with ribbons, to cut down on the types of materials needed.</p> <p>On this one I also tried to add a pin backing, so that I could write instructions on how to do it in what I believe is a more stable way than simply adding it to the felt backing at the end.</p> <p>I’m not sure whether the other ones will be tacked to a hat, and thus won’t require pins at all, or if I’ll just put them on some dress with pins hidden under the ribbon layers.</p> <p><img alt="A cockade with three ribbons, starting with black on the outside, then grey and white, and a flat pentagonal knot of purple ribbon at the centre." class="align-center" src="https://blog.trueelena.org/blog/2026/07/10-cockades/number_tree.jpg" style="width: 80.0%;" /></p> <p>And then I was ready to make a third cockade, taking step by step pictures for my website, and I planned to start on it the next morning.</p> <p>Trenord had different ideas.</p> <p>Thanks to the combination of independent but complete disruptions on <em>two</em> nearby train lines, I spent the morning driving a couple of people to the nearest station that was still being served by trains, and then back home less than 10 minutes before I had to start working, which if you ask<a class="footnote-ref" href="https://blog.trueelena.org#fn1" id="fnref1">¹</a> me was pretty homophobic of the train company.</p> <p>There was way less traffic than I expected, and I did enjoy the drive <a class="footnote-ref" href="https://blog.trueelena.org#fn2" id="fnref2">²</a>, but for various reasons it meant a significant delay for this post.</p> <p>Anyway, less than a week later than I had planned, halfway in June I managed to publish <a href="https://sewing-patterns.trueelena.org/accessories/decorations/multi_colour_cockade/index.html">step by step instructions on my website</a>, but I wasn’t done with the project yet.</p> <p>Beside the fact that I still needed to finish sewing the backing felt to the cockades I had done, I also had a few ideas for more centrepieces made of ribbon I wanted to try.</p> <p>And this means that I moved on to another project that was already in progress (this one will also be blogged).</p> <p><img alt="A cockade with three ribbons, starting with black on the outside, then grey and white, and two squares of purple ribbon at the centre, forming a sort of eight point star. The ribbons are box pleated and this gives the cockade a bit more of a tree-dimensional shape." class="align-center" src="https://blog.trueelena.org/blog/2026/07/10-cockades/number_four.jpg" style="width: 80.0%;" /></p> <p>After I’ve finished that one, at the very end of June I quickly made the last two centrepieces, taking pictures for the instructions, and in the next few days I also finished the cockades.</p> <p><img alt="A cockade with three ribbons, starting with purple on the outside, then white and grey, and an hexagonal shape made of black ribbon at the centre. The ribbons are again box pleated." class="align-center" src="https://blog.trueelena.org/blog/2026/07/10-cockades/number_five.jpg" style="width: 80.0%;" /></p> <p>This time, instead of plain pleats I tried to use box pleats, and I quite like the look they give, so if in the future I’ll have a need for more cockades I may use again this pleating pattern.</p> <p><img alt="A cockade with just two gathered ribbons, starting with black on the outside, then white, and a linux.it pin in the middle with a black background and two eyes and an orange beak reminding of a penguin." class="align-center" src="https://blog.trueelena.org/blog/2026/07/10-cockades/number_six.jpg" style="width: 80.0%;" /></p> <p>For the last cockade I wanted to try two things: putting a pin in the middle as a centrepiece, and gathering the ribbons.</p> <p>For the pin, I found that the only one I had that had a colour scheme compatible with the ribbons I had was one with the penguin from linux.it, which had a black background, so I put black ribbon on the outside and white next to it for contrast.</p> <p>And gathering was done with a whipped gather with ribbons that were one and a half times the outer circumference of their slot, and looks decent enough, but I think I prefer the look of pleated cockades a lot. Maybe it would look better with a softer ribbon.</p> <p>Anyway, I think this is plenty of cockades for the time being, unless I get tempted by buying more colours of ribbon to make different ones. But I’m not making an online purchase just for those. <em>I</em> <em>am</em> <em>not</em>.</p> <section class="footnotes footnotes-end-of-document"> <hr /> <ol> <li id="fn1"><p>you probably shouldn’t.<a class="footnote-back" href="https://blog.trueelena.org#fnref1">↩︎</a></p></li> <li id="fn2"><p>also thanks to my partner who, on entering the destination town, told me to stop on the big, straight, two-way road with plenty of roundabouts to turn around, and went through the maze of one-way streets to the station by foot.<a class="footnote-back" href="https://blog.trueelena.org#fnref2">↩︎</a></p></li> </ol> </section> </section> </article> Fri, 10 Jul 2026 00:00:00 +0000 https://jmtd.net/log/synths/minilogue-xd/module/ https://jmtd.net/log/synths/minilogue-xd/module/ <img src="http://planet.debian.org/heads/jmtd.png" width="65" height="85" alt="" align="right" style="float: right;"> <p>I bought a new synth! Kind-of.</p> <p>I've traded my <a href="https://jmtd.net/log/synths/minilogue-xd/">Minilogue-XD</a> (full-size version with integrated keyboard) for the desktop/modular alternative.</p> <div class="image"> <a href="https://jmtd.net/log/synths/minilogue-xd/module.jpg"><img alt="Modular Minilogue XD" class="img" height="300" src="https://jmtd.net/log/synths/minilogue-xd/module/400x-module.jpg" width="400" /></a> <p>Modular Minilogue XD</p> </div> <p>Why? Partly, because it fits on my desk better. Partly, because it changes the way you engage with the instrument. It makes a huge difference: the ivory keys come with so much cultural precedent. The module version of the synth gains a switch that lets you use the 16 sequencer step buttons as note inputs, so you can still play the thing solo. But the emphasis moves away from note generation and more firmly towards tone.</p> <p>Both versions have a lovely stained wood back, which you never see; the modular one has a hint of that at the front as well (which you do see).</p> <p>I plan to eventually buy a MIDI keyboard that could drive it, and other things: possibly an Arturia KeyStep or Minilab, but there's no rush on that.</p> <p>(It's about time I recorded and shared something I produced on this)</p> Thu, 09 Jul 2026 19:31:38 +0000 http://blog.alteholz.eu/?p=2832 http://blog.alteholz.eu/2026/07/my-debian-activities-in-june-2026/ <h3><strong>Debian LTS/ELTS</strong></h3> <p></p><p>This was my hundred-forty-fourth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. </p> <p> During my allocated time I uploaded or worked on: </p><p></p> <ul><li>[<a href="https://lists.debian.org/debian-lts-announce/2026/06/msg00004.html">DLA 4615-1</a>] exim4 security update to fix one CVE related to information disclosure in combination with proxies. </li><li>[<a href="https://lists.debian.org/debian-lts-announce/2026/06/msg00005.html">DLA 4616-1</a>] haveged security update to fix one CVE related to local root privilege escalation. </li><li>[<a href="https://lists.debian.org/debian-lts-announce/2026/06/msg00007.html">DLA 4618-1</a>] gsasl security update to fix one CVE related to denial of service. </li><li>[<a href="https://lists.debian.org/debian-lts-announce/2026/06/msg00020.html">DLA 4631-1</a>] asterisk security update to fix 13 CVEs related to buffer under- or overflows, either on heap or on stack. Some are related to use-after-free or wrong processing of invalid or untrusted certificates. </li><li>[ELA-1747-1] gimp security update to fix three CVEs in Buster related to denial of service or execution of arbitrary code if malformed PSP, JPEG 2000 or PSD files are opened.</li><li>[ELA-1748-1] gimp security update to fix two CVEs in Stretch related to denial of service or execution of arbitrary code if malformed PSP or PSD files are opened.</li><li>[ELA-1749-1] exim4 security update to fix one CVEs in Buster and Stretch related to information disclosure in combination with proxies.</li><li>[ELA-1750-1] gsasl security update to fix one CVEs in Buster and Stretch related to denial of service.</li></ul> <p> Besides fixing all CVEs of <i>asterisk</i> in Bullseye, I started to look at <i>asterisk</i> in other releases as well. Rather surprisingly <i>asterisk</i> is only part of Unstable and Bullseye. All other releases don’t include any version of <i>asterisk</i> at all. So first things first, besides some security related RC bugs, <i>asterisk</i> did not migrate due to RC-bugs in <i>dahdi-linux</i>. As I maintain <i>osmocom-dahdi-linux</i> (which supports less/other hardware), I looked at the open issues and after some rounds I could upload a new upstream version, fixed some bugs and resolved issues with piuparts. <i>dahdi-linux</i> meanwhile migrated to testing, job done! <br /> As a next step I looked at the open CVEs. Some of them had been already fixed in previous uploads but had not been marked accordingly. So I fixed all remaining ones and sent a debdiff to the maintainer. Unfortunately there was some kind of overlap in our work and he ignored my debdiff but uploaded a new upstream version. Anyway, job done as well, no open security issues anymore. The only thing that hinders <i>asterisk</i> from migrating to testing is the reproducible build. So if anybody has some spare time … </p> <p> Other things I worked on were the regression update of <i>rsync</i>. Some of the elven new patches need to be backported, but I am confidentially to finish this month. I already reviewed the <i>rsync</i>– uploads of Sylvain to Buster and Stretch, so I don’t expect any big hurdles here. I am also making progress to find the correct patches for <i>hplip</i> and <i>cups</i>. </p> <h3><strong>Debian Printing</strong></h3> <p>This month I uploaded a new upstream versions:</p> <ul><li>… <a href="https://tracker.debian.org/lprng">hplip</a> to unstable to fix some bugs.</li></ul> <p><strong>This work is generously funded by <a href="https://www.freexian.com">Freexian</a>!</strong></p> <h3><strong>Debian Lomiri</strong></h3> <p></p><p>This month new upstream versions of dozens of lomiri packages have been released and I uploaded lots of them to Debian. After they migrate to testing, I am also going to sync them to the Ubuntu PPA. </p> <p><strong>This work is generously funded by <a href="https://freiesoftware.gmbh/">Fre(i)e Software GmbH</a>!</strong></p> <h3><strong>Debian Astro</strong></h3> <p>This month I uploaded a new upstream version or a bugfix version of:</p> <ul><li>… <a href="https://tracker.debian.org/supernovas">indi-pentax</a> to unstable. This is a package in contrib without autobuild and needed a new upload for the libraw transistion.</li><li>… <a href="https://tracker.debian.org/c-munipack">c-munipack</a> to unstable.</li><li>… <a href="https://tracker.debian.org/supernovas">supernovas</a> to unstable (sponsored upload).</li></ul> <h3><strong>Debian IoT</strong></h3> <p>This month I uploaded a new upstream version or a bugfix version of:</p> <ul><li>… <a href="https://tracker.debian.org/duktape">duktape</a> to unstable.</li><li>… <a href="https://tracker.debian.org/libcoap3">libcoap3</a> to unstable.</li></ul> <h3><strong>Debian Mobcom</strong></h3> <p>This month I uploaded a new upstream version or a bugfix version of:</p> <ul><li>… <a href="https://tracker.debian.org/smstools">smstools</a> to unstable.</li></ul> <h3><strong>misc</strong></h3> <p>This month I uploaded a new upstream version or a bugfix version of:</p> <ul><li>… <a href="https://tracker.debian.org/visam">visam</a> to unstable. There had been an RC bug due to two binaries with the same name but different functionality. Yes, it is in the policy but … (my mother forbade me to elaborate more on this)</li><li>… <a href="https://tracker.debian.org/mailio">mailio</a> to unstable.</li></ul> Tue, 07 Jul 2026 17:56:04 +0000 http://aigarius.com/blog/2026/07/05/making-of-group-photo/ http://aigarius.com/blog/2026/07/05/making-of-group-photo/ <img src="http://planet.debian.org/heads/aigarius_hg.png" width="85" height="116" alt="" align="right" style="float: right;"> <p>Taking a good group photo consists of multiple aspects:</p> <ul> <li>hardware</li> <li>scouting</li> <li>organization</li> <li>preparation</li> <li>execution</li> <li>processing</li> <li>publishing</li> </ul> <p>I can say with confidence that nearly everything here comes from having failed to do these things right at least once, even on the latest attempts, so this is an ideal to reach towards, not something we expect to hit every time.</p> <h3>The Goal</h3> <p>The main goal of a big event group photo is capture both the moment itself and each individual person inside that moment.</p> <p>We want people, who were <em>not</em> there to see all the people involved and get an impression of what it was like being there. It needs to show the breadth and depth of people that make up this group, this project.</p> <p>And we want people who <em>were</em> there to be able to look back the next week, the next year or in ten years and remember - ah, yes, I was there, I was standing right there with this grin on my face next to this wonderful person and I was feeling great.</p> <h3>Hardware</h3> <p>Based on the goal we want to have high level photographic gear that is able to capture both a broad enough picture to encompass all the people and some of their surroundings to communicate the context (without undue distortions) and to deliver enough detail and resolution so that faces and facial expressions and underlying feelings of every single person in that group could be clearly seen and preserved.</p> <p>To both capture the context and minimise distortion the final picture should be just a bit wider than normal human field of view. That is about 50mm for a full-frame camera or 35mm for a typical 1.6 crop camera. You can go a bit wider if there are no better alternatives (as detailed in the scouting section), but be prepared that corners of the image will be distorted and not really usable (but we can fix that in processing step). Or you can go to unusual aspect ratios, like we did in <a href="https://wiki.debconf.org/wiki/DebConf10/GroupPhoto">Debconf 10</a>.</p> <p>In the absence of a 100MP+ camera, you will need to be stitching together multiple frames to achieve resolution high enough to have enough pixels-per-face to see emotions clearly. This means that the photos you will actually be taking will be tighter than the overall field of view mentioned above. Still, a higher resolution camera body is preferable - nowadays 24MP-32MP cameras APS-C provide a good compromise between resolution and price, but 45-67MP full-frame cameras also exist on the market. Assume that we will be shooting in a bright environment, so most likely with quite low ISO settings, that means that high-ISO noise characteristics of more expensive cameras will not really play a role here. You will also not need very fast burst modes, even manual speed of one frame per second is sufficient.</p> <p>You will also want to get as much detail as possible out of your lens, and this is the <em>most important</em> part. You can do amazing work in all other steps of the process and have a great camera too, but if you pair it with a lens that is not sharp, then the end result will be disappointing.</p> <p>You want the lens that is sharpest corner-to-corner when stepped down to about f/8-f/11, that you can get for your system. You also want that lens to be about 85mm full-size sensor or 50mm for 1.6 crop size. Luckily that kind of range is also a great range for optical design and sharpest lenses are typically available in exactly these kinds of sizes. You absolutely want to have a fixed focal length lens, not a zoom lens. Even profession grade zoom lenses often deliver worse image quality compared to fixed lenses that cost less 1/10th of their price (when shooting in the same focal length). Newer design lenses are better than older lenses - optical design, coatings and precision manufacturing have advanced a lot over the decades. Retro look is great for mood, but not as good for actual resolution and clarity. You don't need to overpay for most expensive lenses because those often only improve image quality on lower F-stops. To encompass the whole group we will need to shoot at f/8 and in bright light, so the extra benefits of those f/1.2-capable super expensive lenses will not come into play here.</p> <p>We will have no use for a flash here. A tripod will be too restrictive when rapidly repositioning the camera between different parts of the panorama shoot. But a monopod might help with stability - I have not tried that myself, however.</p> <p>For my last photos I used a Canon EOS R7 (32.5MP) with Canon RF 50mm f/1.8 STM lens and considering an upgrade to Sigma 56mm f/1.4 DC DN for the next time.</p> <h3>Scouting</h3> <p>Scouting a good location for the group photo is another big chunk of a successful picture. The critical piece of the puzzle is lens-to-face distance. In order to keep everyone's face in-focus and have enough resolution on the farthest faces (without making nearest faces truly massive) we want to do everything possible to reduce the variance in lens-to-face distance - to reduce the difference in distance between closest and farthest face.</p> <p>The most effective way to do that is to have the photographer climb higher. To see this in action on the <a href="https://wiki.debian.org/DebConf/GroupPhotoAll">Debconf photos</a>, compare Debconf6 (very high camera position, group on level ground - good) to Debconf10 (camera not too high, group on stairs, still good) and to Debconf17 (camera could not get high enough and the group is on flat ground - not great). Even the Debconf25 photo was suboptimal from this perspective. The Debconf23 photo was a very good example from the recent years - good height and also the group was positioned in a semi-circle so there were no people directly in front and very near to the camera.</p> <p>So you are looking for the highest point you could get to (even if that requires a special permission of key or a ladder) with a field large enough to fit the whole group comfortably. How to check that? Normally I simply take a photo from the top of the whole area and note down from there where the extreme corners of the group could be and still be fully seen in the shot - not blocked by trees, buildings and shadows. Then I go down and measure that space. Rule of thumb being - people in one horizontal line can stand 1 normal length step from each other and two horizontal lines can be half a step from each other vertically. So I can just measure a rough rectangle in steps, multiply the sides, multiply that by two and I have the rough number of people that can fit there for the photo.</p> <p>Once you have a candidate location or two, it is important to check them at the same time-of-day as you plan to do the photo (see organization section for that). You want to make sure that the whole area of the group is in the same illumination - if half of the group is in the sun and half in a shadow, then you will be having a very bad time later. The absolute ideal positioning for the group photo is to have everyone be in shadow, but still have enough bright skies and bright buildings in front of the people to give good illumination of the faces. Worst you can do is have the sun be behind the people (so all the faces are really dark) and second worst is have the sun be directly in front of the group, so that the faces are very well illuminated, but everyone's eyes are closed because they are being blinded by the sun. And sometimes all you can do is pray for some light clouds to provide for even and dispersed light. Debconf23 was very lucky that way.</p> <p>Another consideration is to how people are going to get to that place. You need to consider accessibility needs of people (it is ok, if it takes more effort or time, but it needs to be organized and communicated well in advance). And you need to consider how the big masses of people will be getting there - how to tell people where <em>exactly</em> it is and how to get there from various locations where people might be hanging out during the event?</p> <p>Having an alternate location indoors might be necessary if the weather report for the next days is not sufficiently predictable. We had to use that contingency in Debconf9, for example.</p> <h3>Organization</h3> <p>It's hard to take a good group photo if half of the group does not show up or is too late, so this needs some organization to happen smoothly.</p> <p>First of all you need to choose date and time for the photo. The photo does not take too much time from the schedule of the event and can be squeezed in after all the other events are already scheduled. In fact I prefer that as it allows you the flexibility of choosing the date based on weather conditions and time based on light and shadow conditions in potential photo spots. You don't want to choose the daytrip day as most people will be away and return times are not really predictable. You do not want to choose the morning after Cheese and Wine party for obvious reasons. First day and last two days are also sub-optimal as some people arrive late and some leave early for various personal reasons. Also <em>you</em> don't want it to happen just before Cheese and Wine either because then you'd have very little time and clarity to do the processing of the image on the same day.</p> <p>For timing, the best way, in my experience, is to schedule the photo directly after the end of talk sessions before a meal break - lunch or dinner. Typically in the Debconf schedule there are 2-3 daily breaks planned, say for Debconf25 there was lunch, afternoon break and dinner. Talks are planned to end ~10 minutes before those breaks (and meals) begin, so for example, afternoon break starts at 16:00 and all talks in the previous block end at 15:50. In such a case just schedule the "Group photo" event from 15:50 to 16:05. This gives people the info to go there <em>directly</em> from the end of all talks and that they will have sufficient time for break/meal afterwards. Do not forget to specify the location (as exactly as possible) in that event entry and make sure to post it at least two days in advance. People often want to wear something specific for the photo and thus need to know about it in advance. This also makes sure that people do not make alternate food plans for that specific break and don't leave the venue.</p> <p>Announce the date, time and the exact location as wide as possible, don't be shy. Announce and discuss mailing lists, IRC, Signal, Telegram, make sure the front desk knows in case anyone asks in-person, ... Check that it is again included in the announcements email on the day preceding the photo date.</p> <p>When the date has arrived, it is a good idea to check in early with people with special mobility needs to make sure they know where to go, how to get there and how much time they will need to be able to get there on time.</p> <p>As the final round of talks before the group photo is starting up, it is time to recruit "runners". I've had great success with this technique. The idea is pretty simple - for each room where people congregate (talk rooms, hacklabs, cafeteria, outside hackspace, front-desk, ...) go there and choose one person. You want to choose a person that you will recognise and remember among everyone else in the group, either because of who they are or what they are wearing, whatever works best for you. If they agree to help, instruct them to: "at end of talk, announce that the group photo happening now and the location, herd people towards the photo location, be the last person out, make sure there are no stragglers from this area behind you, when you arrive to the photo place I will assume that everyone else from this room is also now there, when you are there catch my attention and show this sign so I know for sure that it is all good and make sure that I did see it from you". With that sorted out all you will need to remember is how many runners you recruited and how many have reported in to figure out if everyone has now arrived or if we still have to wait for someone or some group.</p> <p>Then you will only have one last point of organization left - shaping the crowd into a group. People will not know what your vision for the group photo is, so you will have to give clear and <strong>LOUD</strong> instructions on where people should <em>not</em> be standing. Use clear, large gestures to support your words. You want to compact the group, have the people that just joined in the last moment and are standing to the side come deeper in and join the crowd. Have any holes in the middle of the crowd filled in. Forming a semi-circle instead of a blob helps with averaging face-to-lens distances. Make sure people are not in unexpected shadows. Make sure carried objects, like umbrellas of flags do not cover the faces of other people. Take the time to look at everyone face to make sure there are no people hiding behind someone's shoulder - typically they are not aware that their face is in fact not really visible. If there are such people, call them out and point directly at them and encourage them to step forward, if they wish to do so. You are the <em>only</em> one seeing the final picture now and only you can correct it before capturing the moment. So a few extra seconds here are worth taking, even if 300+ people are standing in scorching heat and waiting on you.</p> <p>When you are happy with what you are seeing, make sure to tell people clearly that you are now about to take the pictures and <em>again</em> remind them not to move and <em>explicitly</em> not to turn their heads to the side until you are done (this is the source of most of the extra work in processing). Be very loud and clear and make sure you have everyone's undivided attention <em>before</em> you start saying the important stuff.</p> <p>When done - say so. There will be other groups that will want to also have a photo taken after the main group is a bit more dispersed, so don't run away. Typically at least the T-shirt group will want a picture and also all the organizers.</p> <p>Final bit of organization during the group photo shooting itself is the sneaky self-insert. You may choose not to bother with it, or do it in the simplest way, like I did in Debconf6, but if you really want to blend in with the crowd, you need to have someone else take a photo of you in the exact same location at the same date and time from the same location. So you should already during shaping the crowd decide where you would fit in, it is easiest to blend in at the back of the crowd and to one or other side, so that it appears like you are just standing behind the shoulders of a couple peoples. Remember that spot - it is easiest if you stand in the exact same ground spot when your photo is taken. Just go down, recruit a volunteer to take your photo, make sure the settings are fixed to the same ones as for the group photo shots and have them take a handful of shots of you - one of you centered in the camera frame and a couple more with you more towards the corners of the frame. This distortion from being off-center in the frame may be important later.</p> <h3>Preparation</h3> <p>In addition to preparing the crowd for the photo, you also need to prepare yourself and the equipment. Make sure you have dusted your camera sensor and cleaned both inside and outside glass of your lens. It is usually a good idea to remove any filters from the lens. Install the hood, if that could help with blocking the sun flares. Make sure you have the right lens and that you have installed the right lens.</p> <p>For fixed settings I typically shoot in JPEG with RAW being there more like an emergency backup. The extra dynamic range of RAW could be used, but it is really complex to do that in combination with image blending and it is hard to get right, so I prefer an all-JPEG workflow and fix the dynamic range in the scene itself, before shooting. For Canon I am using the Standard profile that boosts the color saturation and sharpness a bit as I just enjoy that look and find it hard to get anything significantly better from RAW data even with a lot of effort. In any case make sure you have enough space on the cards to take at least 100 images and that you have a full battery. Do not use high speed burst setting because it is then too easy to take too many pictures at the start of the sequence and be stuck with your camera still in "Busy" state writing big RAW files to slowish SD cards and not allowing you to finish the full picture rapidly.</p> <p>You want to have the shutter speed at at least 1/100th of a second to prevent blur from both your hand movements and also from people in the shot moving around a bit (image stabilisation will not help you there). And you want to have the aperture to be around f/8 - lower apertures risk people in front or behind falling out of focus, make the lenses look less sharp. Higher apertures also start to become less sharp due to diffraction effects above f/8. ISO should stay as low as possible, ideally at ISO 100, but if there is not enough light then upping the ISO to 400 would be the first step that I would try to do and second would be decreasing the aperture to f/5.6. If there is too much light, then increasing the shutter speed should be the safe thing to do.</p> <p>As people start to arrive into the shooting location - check the exposure and nail down the settings, ideally in manual mode. Consider that left side could be a bit lighter or darker than right side. Err on the side of making the picture a bit too dark as there is more depth to darkness before cut-off compared to clipping on the high end. However, do not trust the exposure detection, instead take a picture and look specifically at skin tones in faces of people that already are standing in the photo area. Faces are the key bit and the exposure needs to be adjusted just to the faces and ignore darker of lighter clothing. Do some test shots and find settings where faces look not too bright, but also not very dark and fix those settings in manual mode.</p> <p>Now you are ready for the action. Shape the crowd, check the faces and the action can start!</p> <h3>Execution</h3> <p>During taking of the group photo you want to finish it fast, but at the same time you have to take the time to make it right. If you hurry too much under pressure, you risk being left with unusably blurry images and the whole effort wasted. Having already prepared and verified the manual settings makes it easier.</p> <p>When you are taking pictures, you have to remain as still as possible - even at very high shutter speeds even slow hand movements are still bad for image quality. So think of the movement as of biathlon athlete shooting the very middle of five, very separate targets - take a burst, reframe, then steady up for a second and only then take the next burst. 3 frames per burst are sufficient. 90% of the time the very first photo of a burst will be best. As you move from frame to frame, aim for just a bit more than half-frame overlap. This will give the opportunity to skip frames if all is good, but also have backup coverage of every face in case of problems. Proceed systematically, I typically start off on the top left of the crowd, then go right until the end of the line, then shift down half a frame and go left until the end and repeat until I am done with the crowd. </p> <p>After that it is <em>very</em> helpful to also immediately take photos of a "frame" around the whole crowd. Stitching process often distorts the frames in weird ways that leave holes in the resulting image that you can fill if you have a wide frame around the crowd. It is possible to compensate with creative cutouts in the final image (like Debconf9), but the more framing room you make, the more flexible you will be able to be with cropping of the final photo. The frame also gives you the opportunity to capture more of the context of the place and space.</p> <p>As an example, Debconf25 group photo in the end consisted from 9 images + 1 for sick people + 1 for me. I ended up missing the framing shots for bottom left, top left and top right corners. To get there I took 68 images. And in some years it was more than a hundred.</p> <h3>Processing</h3> <p>This part might be less stressful than taking the pictures from intensity perspective, but it lasts longer. Depending on you luck, skill and perfectionism it can take anywhere from 3 to 9 hours of work to complete.</p> <p>Before you start, however, you should first request things that you will need for other people. This <em>can</em> even be done before taking the actual group photo, but usually I forget. To finish the photo you will need three things:</p> <ul> <li>good quality vector graphics of the current Debconf logo</li> <li>good quality vector graphics of the <em>next</em> years Debconf logo (even if preliminary)</li> <li>motto of the conference</li> </ul> <p>The first two you should be able to get from the respective organizers. The motto is harder. I typically try to ask the current DPL to come up with something describing the current mood of the project or of the event, but it is rare that it is that easy. Most of the time I came up with something as I was editing the photo and reflecting on what was the mood, the feeling, the mojo of this conference and of this year was like. Bend that around a recognisable phrase or expression, make it a bit more insider-relevant and you are on the right path. Some years this was the hardest part.</p> <p>For the panorama stitching I will describe the workflow that has served me good for years, but maybe there are better ways possible nowadays. Feel free to let me know!</p> <p>First I would save all photos taken and select one sharpest photo from every burst. Next I would select the minimal number of photos that appear to be covering the entire crowd. The fewer images you use, the better in the end because the most quality problems crop up in the areas where photos are getting stitched together. Fewer seams leads to fewer issues.</p> <p>Open <a href="https://packages.debian.org/search?keywords=hugin">Hugin</a> (you will also need enblend and enfuse installed) and import your minimal set of images into it. Click the "Align" button and wait a while - the processor will be trying to figure out keypoints in each image and then try to match these points between the images to try to fit them all together into a single projection. To do that it will distort the images. This is the trial and error process part. You may need to add, remove or replace images to get the stitching to work or to work better. You may want to add more of the frame images to fill the ragged holes around the image.</p> <p>After initial alignment, go to "Move/Drag" tab and move the image a bit up in the projected field of view and make it a bit more central visually. That will help a bit with the distortions in the near-by people and people in the corners of the image. In the "Crop" tab set the initial crop - leave it generous, you can always crop more in later steps. Do not be afraid of leaving in sizable chunks of black homes, empty skies or grass. All of that can be filled in later as well.</p> <p>Go back to the "Assistant" tab and click "Create panorama". It is good enough to have JPEG output at 100% quality using exposure corrected low dynamic range output option. Make sure to check the "Keep intermediate images" option. This will not only generate the final, merged panorama, but also keep around the individual images <em>after</em> perspective correction and exposure blending steps. These are critical for fixing blending error in the next step.</p> <p>You might need to go back a forth a few times with a different sets of source images, maybe adding some image between other two, maybe removing another to reach a better starting point. The key part to pay attention - how many ugly stitches are there in the image. Check every face, the blending algorithms do not recognise faces and sometimes try to stitch one face from two or more images creating very weird effects. They <em>can</em> be fixed in the next step, but it is rather hard manual work, so the fewer such faces are in the blended image, the less work you will have. In some years I've managed to find a combination where all faces were good and in other years I had to manually fix 13-15 faces.</p> <p>Do not try to blend the extra pictures (like with you or with sick people) into the main panorama with Hugin - it will get very confused with the parts of the grass that it is able to see where other people were standing.</p> <p>The next is the final processing in <a href="https://packages.debian.org/search?keywords=gimp">GIMP</a>. Think of it like a large and complex project - do as much as possible in separate layers, save often.</p> <p>Fixing wrongly stitched faces and also putting yourself into the photo are very similar activities in the end. Just the scale and the source differ. For yourself you just cut out yourself (upper torso is enough) from the separate photo. For corrupted face, choose one of two intermediate images that the Hugin created where the face is transformed, but not yet merged (with a different version of itself). In either case crop the photo to roughly the interesting size and put roughly in the right spot as a separate layer on top of the group photo background. Reduce the opacity of the small layer to 30-40% and zoom in to 400%. With that it is much simpler to position the layer with pixel precision. Then all you need to do is add a layer mask to this layer and paint it just right. Basically in layer mask black means transparent and white means non-transparent. So you need to <em>just</em> make everything that is you have white mask and everything that is not you have black mask. And smudge the border a bit with finger tool or blur to make the transition smoother. Easy to say. Hard to do. This is what takes most of the actual work hours in post-processing.</p> <p>You <em>might</em> miss someone. I am sure Phill is just thrilled to see me in the very middle of the Debconf25 final picture .... But do try to fix them all.</p> <p>Use large, sweeping geometric figures to cover up black holes, empty grass fields and other sub-optimal corner features. And then use that newly created free space to put in a large version of the logo of this years conference, decently sized motto and slightly smaller invitation to the next years conference.</p> <p>Do not forget to add a copyright and license statement somewhere in the corner in smaller, but still well readable font. I am using a text like: "Photo by: Full Name, Email: fullemail@debian.org, License: GPLv2+ or CCv3-BY" This ensures that this image may be used in any press coverage (with basic attribution) and also can be included in any GPL-licensed software, if that ever comes up. The same statement is also in the metadata of the image file (see Image-Metadata-Edit metadata in GIMP) along with information that states that this is "Debian Developer Conference Group photo, City, Country, Year". Image-&gt;Image properties-&gt;Comment is another place where GIMP hides this EXIF information.</p> <p>For ease of use, in addition to a full-resolution image it is also useful to make a lower resolution version that would still fit on a 4K screen at full resolution, so about 3840px wide. Some photo hosting services set other limits for image size as well, so it might be needed to scale the image down below 100Mpix to upload it to Google Photos, for example.</p> <h3>Publishing</h3> <p>So, it is finally 1AM and the group photo is ready! How do you push it out to people? Well, in all possible ways and places. Again - don't be shy, people do really want to see it.</p> <p>Push it to whatever you use for your shared photos. Push it to <a href="https://salsa.debian.org/debconf-team/public/share">Debconf shared git</a> (note that this is GIT-LFS repo, make sure you know how to add content to the LFS specifically). All permanent links to that in <a href="https://wiki.debian.org/DebConf/GroupPhotoAll">GroupPhotosAll wiki</a>. And then send those links to IRC, Signal, Telegram groups, debconf-announce mailing list. Publish it in your blog and push that to <a href="https://planet.debian.org/">Debian Planet</a>. Push it in Threads, Bluesky and Mastodon. Send an email separately to Debconf orga team. And one to <a href="https://wiki.debian.org/Teams/Publicity">Debian Publicity Team</a> so they can put it into the <a href="https://www.debian.org/">Debian Home Page</a> and push via Debian micronews accounts.</p> <p>And that is about it. Now you can go back to enjoying the rest of the conference. Or running around doing other things that you think need to be done. It's up to you. You did it. This moment will remain with people for a very long time. And you helped.</p> <p>Questions? Feedback? Just ask <a href="https://bsky.app/profile/aigarius.com/post/3mpytbrm5dc2w">here</a> or <a href="https://www.threads.com/@aigarius/post/DadpZDbjqAx?xmt=AQG0WPOLDjK2ZkbDiiuXEOqQQWF5bum51R8V_uNtv9nliA">here</a>.</p> Mon, 06 Jul 2026 19:30:00 +0000 https://www.eyrie.org/~eagle/reviews/books/0-06-105356-2a.html https://www.eyrie.org/~eagle/reviews/books/0-06-105356-2a.html <p>Review: <cite>The Player of Games</cite>, by Iain M. Banks</p> <table> <tbody><tr> <td>Series:</td> <td>Culture #2</td> </tr> <tr> <td>Publisher:</td> <td>HarperPrism</td> </tr> <tr> <td>Copyright:</td> <td>1989</td> </tr> <tr> <td>Printing:</td> <td>February 1987</td> </tr> <tr> <td>ISBN:</td> <td>0-06-105356-2</td> </tr> <tr> <td>Format:</td> <td>Trade paperback</td> </tr> <tr> <td>Pages:</td> <td>295</td> </tr></tbody></table> <p> <cite>The Player of Games</cite> is political space opera and the second book in the shared Culture setting. As with most Culture books, the reading order is not particularly important. It won the 1989 Locus Award for best science fiction novel and sometimes competes with <a href="https://www.eyrie.org/~eagle/reviews/books/1-85723-135-X.html"><cite>Use of Weapons</cite></a> as the consensus best Culture novel. </p> <p> This review is a re-read and yet another experiment in how to re-review a book. This time, I decided to write a full second review with substantial spoilers so that I can talk in more detail about the book. If you want to avoid spoilers, or just want to see how my thoughts have evolved from my first reading, see <a href="https://www.eyrie.org/~eagle/reviews/books/0-06-105356-2.html">my original review</a> from 2005. </p> <p> Gurgeh plays games. He is probably the best strategy game player in the entirety of the galaxy-spanning Culture. He has written papers on game theory, won innumerable major championships, and is a celebrity in the circle of like-minded aficionados. </p> <p> Gurgeh is also bored and in the middle of the Culture equivalent of a mid-life crisis. As the story opens, he's vaguely unsatisfied and adrift, unenthused by his normal activities, and searching vaguely for something that will break through his ennui. He is caught by surprise by the thrill he gets from a moment's misunderstanding in which an opponent suspects him of cheating, which sets him up to be (apparently) clumsily blackmailed by a deeply unpleasant drone named Mawhrin-Skel. </p> <p> <strong>SPOILERS BELOW</strong>. If you have not read this book, consider stopping here and instead reading my original <a href="https://www.eyrie.org/~eagle/reviews/books/0-06-105356-2.html">no spoiler review</a>. </p> <p> The first hundred pages of <cite>The Player of Games</cite> is a slow, somewhat plodding introduction to Gurgeh, his social circle, and life in (one part of) the Culture. I remember being fascinated by this part the first time I read this book. It was only the second Culture novel I read and the first set in the Culture proper, so the world-building underlying this odd post-scarcity utopia on a vast intelligent habitat with sentient drones, complex privacy rules, endless cocktail parties, and apparently directionless socialites was intriguingly unlike the other science fiction I was reading at the time. This time through, I have to admit I was less impressed. </p> <p> Gurgeh is not very likable, and his desultory mid-life crisis is a little boring. None of his friends have enough depth to appear as more than side notes, in part because Gurgeh doesn't seem to care enough about any of them to make them interesting to the reader. I've since read seven other Culture novels, so Banks's cocktail parties hold less charm and I was impatient for the real action to begin. </p> <p> These chapters are still important, though, because they establish how utterly average Gurgeh is. He has one unique talent, a deep affinity with and obsession with strategy games, and is otherwise a bit of a depressed narcissist with a few casual relationships, a friend that he barely confides in, and a comfortable and familiar life. He is not in any way a hero or a charismatic figure; he just happens to be exceptionally good at one thing, enough to make him famous among people who care about that one thing and probably unknown to anyone else apart from the occasional idly perused news headline. He is the Culture's equivalent of the world chess champion. </p> <p> The Contact division of the Culture has a problem. The Empire of Azad in the Lesser Magellanic Cloud is a nasty, expansionist culture of the sort that Contact would like to deal with before it causes broader problems. The Culture's normal approaches are thwarted by an unusual organizing principle: The empire is built around and takes its name from the game of Azad, a highly complex strategy game developed over thousands of years. Azad is the civil service exams, means of political and religious dispute resolution, selection mechanism for the emperor, and civic religion. Faced with that oddity, Contact turned to Special Circumstances, the Culture's more aggressive and less restrained way of dealing with tricky problems. Special Circumstances, in turn, needs someone who can learn how to play the game of Azad. They want Gurgeh to take a very long trip. </p> <p> For all of Gurgeh's dissatisfaction, he's not impulsive enough to take a five year journey away from his life and everyone he knows just to play a novel game. Conveniently, Mawhrin-Skel's blackmail resolves this reluctance. </p> <p> The game of Azad requires some suspension of disbelief. Banks provides a few glimpses at the mechanics of the game, but those details are insufficient to reconstruct the rules, and some of the claims made about its properties are improbable at best. The best mental model I could build for it is a strategy or simulation game built around units and territory control, with supplemental side games used to build up resources for the main boards, but it's more of a plot device and a set piece than a world-building invention. The significance of Azad the game is its role in society: The Empire of Azad believes they have constructed a game whose complexity so closely models reality that the skills required for success in the game are precisely the skills required for success in the empire. </p> <p> The Empire of Azad is wrong, and this is one of the core themes of <cite>The Player of Games</cite>. As with many Culture novels, what Special Circumstances tells Gurgeh is, at best, incomplete. Gurgeh is a refutation of the basis of belief in Azad; this is why it is important thematically that he is an average, somewhat unlikable citizen of the Culture whose only special characteristic is skill at learning and playing games. </p> <p> Azad is the myth of meritocracy given physical form as a game. It provides the anchor of the empire for the same reason that societies on Earth place enormous weight on standardized tests, capitalist success, or public debates. All societies face the problem of selecting good leaders and testing opposing beliefs, and all societies attempt to find some form of shortcut, some set of general principles, tests, or objective metrics used to select the best person via a process that people consider plausible and fair. The game of Azad is a paragon of apparently meritocratic process. No matter who you are or what your background is, if you excel at the game that, in theory, objectively tests your skills, you are given a position of power. </p> <p> In practice, the Empire of Azad is not that naive. Manipulation outside of the game happens, only some players have the opportunity and resources to spend years learning the game at a deep level, and only their dominant sex truly stands a chance in games that matter. But neither is Azad's place in society a fiction. There is corruption around the edges, and a lot of people are filtered out before the games begin, but the highest echelons of society are true believers. The game does decide both rank and policy; Banks is arguing against a strong form of apparently working meritocracy. </p> <p> Gurgeh represents a refutation of this meritocracy through the mechanism that breaks every supposed meritocracy: The map is not and cannot be the territory. Any objective evaluation criteria is necessarily separate from what it is trying to measure, and in that separation there is always an opportunity. Gurgeh has none of the background, training, or mindset expected for a player of Azad because he could not possibly care less about any of the things Azad represents to the Empire. What he has instead is a preternatural skill at games and vast experience with the most intricate strategy games the Culture, a much larger society, has been able to devise. He also has both the patience and the resources to devote himself entirely to learning a game for several years, and past experience in doing that with other games. </p> <p> If Azad represents the civil service exams, Gurgeh is the person who has no interest in ruling but adores memorizing facts and taking tests. The theory behind the exams is that the skills to pass the exam only come with the correct mindset to do the job for which the exam is testing. Gurgeh is an existence proof that this is not always the case. </p> <p> Banks also uses Azad to show another aspect of the failure of meritocracy: A society whose rulers are chosen through a competition takes on the shape of that competition. The Empire of Azad is run by the winners of competitive games, so the empire is a winner-take-all system of dominance and status hierarchy. Here, I think Banks lays the point on a little thick; the empire is an irredeemable hellhole of misogyny, sexual abuse, slavery, genocide, and military colonialism to a degree that is a bit hard to justify solely from the game. There is a beautiful turning point about two-thirds of the way through the book where Gurgeh's face is shoved into just how vile Azad society is and reconsiders his approach to the tournament as a result, and I think it may have been a bit stronger if the morality had been a little less blatant and absolute. </p> <p> To the extent that Gurgeh has political beliefs, he represents a Culture flavor of soft liberalism. He has opinions about acceptable and unacceptable ways to treat people, but he grew up in a utopia and his opinions are mostly theoretical. When he sees just how vile people can be outside of that utopia, he is revolted and appalled and redoubles his efforts to fight that society in the only way he knows how, inside of a game. This part of the book follows the standard, if enjoyable, plot of a flawed but fundamentally decent person discovering a true injustice and becoming enraged at it. </p> <p> In a lot of books, that would have been where the plot stops. Banks is doing something more subtle and more interesting, though. Gurgeh wipes the board with his next challenger, but that soft liberalism eventually proves inadequate. To learn the game of Azad and to play in the tournament, Gurgeh has been wrapping himself in Azad culture and its language, and in that frame of mind he is losing the climactic game of the book. It's only when he is pushed to think in Marain, the native language of the Culture, that he understands what is happening in the game and how to defeat Nicosar, the emperor. </p> <p> This, on the surface, is a bit too close to the <a href="https://en.wikipedia.org/wiki/Linguistic_relativity">strong hypothesis of linguistic relativity</a> to be entirely plausible, but such an objection would miss the point that Banks is making here. Marain is a construct, the product of considerable effort within the Culture to match language to the most nuance and complexity that brains can understand, and it is a language, one of the most social and collective artifacts a society can produce. Gurgeh is a remarkable individual with an impressive talent, but individual skill and achievement can only take him so far. The critical final piece is the support of societal infrastructure intentionally built and maintained to help him make better decisions. </p> <p> Once I noticed that point, I saw it everywhere in the book. The empire repeatedly attempts to subvert or distract Gurgeh with drugs, pleasure, politics, or danger, and at each point there is some critical piece of Culture social infrastructure that blunts the attack. Illicit substances and forbidden vices are less tempting to someone for whom the illicit has been demystified by the Culture's gentler approach to rules and boundaries. Embedded biological mechanisms allow him to divert drugs so that they don't affect him. At first, it's easy to read this as an exercise of self-control, but on this re-read I saw how much behind-the-scenes infrastructure supports Gurgeh's ability to ignore temptation. </p> <p> This social support notably does not take the form of some ideological principle or moral framework. Gurgeh is not a monk or an ascetic, as is obvious from the first third of the book, and he has no political ideology to speak of. He is a flawed person with a streak of danger-seeking and self-aggrandizement, which the Culture exploited to get him involved in Azad. But through a lot of hard work, technological and social, the Culture has given him a robust foundation and a set of mental and biological tools that make him remarkably hard to corrupt. The implication is that if Gurgeh has that support, so does every other member of the Culture. It's neither a religion or an ideology; it's well-maintained infrastructure, complex and nuanced and pragmatic, and composed of innumerable small solutions to specific problems. </p> <p> I think the true climax of this book takes place the night before the final day of the game, in the tower meeting between Gurgeh and Nicosar. Gurgeh has realized that he's already won; there's nothing Nicosar can do to salvage the game. He's also seen that the game represents a cultural conflict and conversation between the Culture and Azad and he's overwhelmed by the beauty of that communication and sadness that the game is about to be over. Gurgeh's true passion is the game. It is doubtless easier for him to be magnanimous because he's winning, but he also loves the structure of the game itself and what two players can create in a sort of collaborative competition. </p> <p> Gurgeh tries to express all of this to Nicosar. It is one of the most centrist liberal moments I've ever read in a novel, the pure essence of "reaching across the aisle" or "disagreeing agreeably." Gurgeh has seen something beautiful, something he's created with Nicosar, a moment of true communication, and he wants to share it. Surely Nicosar sees the same thing; surely now that he sees Gurgeh has won, he can appreciate the board structure, savor the moment, understand the transient beauty of a game that is about to end and how perfectly it captures the meeting of their different cultures. That moment does Gurgeh real credit. It's a rare sign of emotional and spiritual depth in a character who often seems superficial. </p> <p> Nicosar meets this outreach with unhinged, furious contempt. He despises everything Gurgeh represents, everything the Culture is, and the next day he tries to kill Gurgeh on the board of the game. </p> <p> It is a devastating critique of liberal tolerance, all the more so because Gurgeh's attitude and outreach is truly admirable. It is perhaps the most sympathetic moment that Gurgeh has in the entire book, the moment where the reader thinks "oh, I get it, I understand what he really cares about." Gurgeh assumes that Nicosar is not his position or culture, that they have made a moment of connection that transcends all the awful things he previously learned about the empire of Azad. That Nicosar, despite being the emperor of the society that is currently doing so many things Gurgeh finds repulsive, cannot be as bad as his society. And Nicosar considers that outreach to be weak, disgusting, and vile, and does everything that he can to destroy it. </p> <p> One of the oddest twists of our current moment is the obsession that some billionaires have with stories that are moral arguments against exactly what those billionaires are currently doing. The most obvious example is Peter Thiel, who is obsessed with <cite>The Lord of the Rings</cite> and has devoted his life to becoming Saruman, a character who is notably not one of the protagonists. It's as if something in them recognizes the power of the story, but some deep shame or narcissism or simple aversion allows them to completely ignore what the story means. </p> <p> Elon Musk is obsessed with the Culture novels. He names the SpaceX rockets following Culture Ship naming conventions and has claimed that one of his goals is to bring about a Culture-style utopia. And in 1989, years before anyone had ever heard of him, Banks cast him as the villain of <cite>The Player of Games</cite>. There is so much of Nicosar in Musk: the superficial charm, the limited brilliance (Nicosar is a very good Azad player), the ambition, the pride, and the vicious, spitting contempt for everything the Culture represents at every level deeper than superficial materialism. And Banks is as clear about his opinion of Nicosar as he is about anything in any Culture novel. </p> <p> One of the oldest fictional answers to what a society does with people like Nicosar is the consequences of hubris. By being unable to accept defeat, by holding a vision of the world so tightly, they become brittle and unstable and bring about their own collapse. In a broad sense, that is what happens in <cite>The Player of Games</cite> with a bit of pushing from Special Circumstances. By the politics of the game, Nicosar had already won; the results of Gurgeh's earlier games had already been faked, the final game had no political consequences, and everyone who knew its true outcome could be disposed of. Gurgeh's win could have been covered up and ignored. But Nicosar could not endure the thought that he would be beaten by someone like Gurgeh, playing Azad the way that Gurgeh was playing it. Gurgeh had to be destroyed on the board of the game; Nicosar's pride did not allow any other outcome, even if it meant Nicosar's death. </p> <p> However, Special Circumstances didn't let hubris be the end of the story. In the climax of the book, the drone protecting Gurgeh also makes sure that Nicosar dies. There is a fig leaf of plausible deniability, but it's so obvious that even the unobservant Gurgeh sees through it immediately. It's hard to escape the feeling that was Banks's answer to what to do with people like Nicosar: They cannot live within society, because they will not live peacefully within society. </p> <p> I enjoyed <cite>The Player of Games</cite> as much this time through as I did the first time, but for entirely different reasons. In my first read, I focused on the world-building of the Culture, the political machinations, and the concept of games as conversations between the players. This time, I was struck by the political commentary just below the surface. Special Circumstances wanted to resolve the problem of the Empire of Azad without a military conflict and occupation that would be long, brutal, expensive, and demoralizing. They found an answer that relied on the diversity of the Culture. A vast, utopian civilization in which people can pursue whatever interests make them happy produces innumerable microspecialized oddities, people with astonishing talents in some small field that only a tiny fraction of people care about. It produces, in other words, innumerable keys for locks that you may never encounter, but which are invaluable if you happen to stumble across that lock. </p> <p> Gurgeh is not a hero. He is not a paragon of moral virtue, or even a charming charismatic, He is an entirely average member of an extraordinary society, the beneficiary of thousands of years of concerted effort at producing a robust, flexible foundation on which to raise robust, flexible citizens with a shared sense of basic morality. Those people, by themselves, do not solve all of life's problems; the structure of Special Circumstances and its willingness to bend rules in order to maintain them is the tension and <em>deus ex machina</em> in all of the Culture novels. But much of the strength of Special Circumstances is that it has an entire civilization of people like Gurgeh to draw upon when it needs them. </p> <p> It has those people because the Culture comprehensively rejects competitive meritocracy, something that some readers of the Culture novels appear incapable of comprehending. </p> <p>Rating: 9 out of 10</p> Mon, 06 Jul 2026 03:09:00 +0000 https://www.eyrie.org/~eagle/journal/2026-07/001.html https://www.eyrie.org/~eagle/journal/2026-07/001.html <p> This is a bug fix and minor feature release over INN 2.7.3, and the upgrade should be painless. You can download the new release from <a href="https://downloads.isc.org/isc/inn/">ISC</a> or <a href="https://www.eyrie.org/~eagle/software/inn/">my personal INN pages</a>. The latter also has links to the full changelog and the other INN documentation. </p> <p> For the full list of changes, see the <a href="https://www.eyrie.org/~eagle/software/inn/docs-2.7/news.html">INN 2.7.4 NEWS file</a>. </p> <p> As always, thanks to Julien ÉLIE for preparing this release and doing most of the maintenance work on INN! </p> Mon, 06 Jul 2026 01:57:00 +0000 http://dirk.eddelbuettel.com/blog/2026/07/05#rcpp_1.1.2 http://dirk.eddelbuettel.com/blog/2026/07/05#rcpp_1.1.2 <img src="http://planet.debian.org/heads/dirk.png" width="65" height="90" alt="" align="right" style="float: right;"> <p><img alt="rcpp logo" src="https://dirk.eddelbuettel.com/images/rcpp-logo-blue-dial.png" style="float: left; margin: 10px 10px 0px 0px;" width="200" /></p> <p>Team Rcpp is excited to share that an brandnew new version 1.1.2 of Rcpp is now on <a href="https://cran.r-project.org">CRAN</a>, has also been uploaded to <a href="https://www.debian.org">Debian</a>, and has already built for <a href="https://eddelbuettel.github.io/r2u/">r2u</a> and <a href="https://rcppcore.r-universe.dev/Rcpp">r-universe</a>; Windows etc builds at <a href="https://cran.r-project.org">CRAN</a> should follow in due course.</p> <p><a href="https://www.rcpp.org">Rcpp</a> has long established itself as <em>the</em> most popular way of enhancing <a href="https://www.r-project.org">R</a> with C or C++ code. Right now, 3236 packages on <a href="https://cran.r-project.org">CRAN</a> depend on <a href="https://www.rcpp.org">Rcpp</a> for making analytical code go faster and further. On CRAN, 13.4% of all packages depend (directly) on <a href="https://www.rcpp.org">Rcpp</a>, and 61.4% of all compiled packages do. From the cloud mirror of CRAN (which is but a subset of all CRAN downloads), <a href="https://www.rcpp.org">Rcpp</a> has been downloaded 121.6 million times. The two published papers (also included in the package as preprint vignettes) have, respectively, 2263 (<a href="https://dirk.eddelbuettel.com/blog/jss2011">JSS, 2011</a>) and 471 (<a href="https://dirk.eddelbuettel.com/blog/tas2018">TAS, 2018</a>) citations, while the the <a href="https://dirk.eddelbuettel.com/blog/rcppbook">book (Springer useR!, 2013)</a> has another 742.</p> <p>The is the second update in the 1.1.* series which had, among other changes, switched to <a href="https://dirk.eddelbuettel.com/blog/2025/07/02#rcpp_1.1.0">C++11 as the minimum standard</a>. This release continues as usual with the six-months January-July cycle started with <a href="https://dirk.eddelbuettel.com/blog/2020/07/06#rcpp_1.0.5">release 1.0.5 in July 2020</a>. Interim snapshots are always available via the <a href="https://rcppcore.r-universe.dev/Rcpp">r-universe page and repo</a>. We continue to strongly encourage the use of these development released and their testing—we tend to run our systems with them too.</p> <p>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 <em>abrupt</em> changes forcing packages which consume header files to make very abrupt change. <a href="https://www.rcpp.org">Rcpp</a>, just like numerous other <a href="https://cran.r-project.org">CRAN</a> 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 <em>always</em> keeping properly tested, installable, and error-free releases candidate version in the main repository branch and hence available via <a href="https://rcppcore.r-universe.dev/Rcpp">R-universe</a> 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.</p> <p>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!</p> <blockquote> <h4 id="changes-in-rcpp-release-version-1.1.2-2026-07-01">Changes in Rcpp release version 1.1.2 (2026-07-01)</h4> <ul> <li><p>Changes in Rcpp API:</p> <ul> <li><p>Use of <code>execinfo.h</code> is again conditional to avoid build complexity (Dirk in <a href="https://github.com/RcppCore/Rcpp/pull/1445">#1445</a> addressing <a href="https://github.com/RcppCore/Rcpp/issues/1442">#1442</a>)</p></li> <li><p>An internal state component for <code>Datetime</code> is now <code>int</code> (Dirk in <a href="https://github.com/RcppCore/Rcpp/pull/1448">#1448</a> and <a href="https://github.com/RcppCore/Rcpp/pull/1449">#1449</a> fixing <a href="https://github.com/RcppCore/Rcpp/pull/1447">#1447</a>)</p></li> <li><p>Three new (in R 4.6.0) attribute accessors are used conditionally (Dirk in <a href="https://github.com/RcppCore/Rcpp/pull/1450">#1450</a> closing <a href="https://github.com/RcppCore/Rcpp/issues/1432">#1432</a>)</p></li> <li><p>An UBSAN error in the Sugar-based NA comparison has been corrected (Iñaki in <a href="https://github.com/RcppCore/Rcpp/pull/1453">#1453</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1452">#1452</a>)</p></li> <li><p>Treatment of Inf outside of integer range in Sugar function has been corrected (Iñaki in <a href="https://github.com/RcppCore/Rcpp/pull/1458">#1458</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1455">#1455</a>)</p></li> <li><p>Integer overflow protection has been added for sugar functions (Iñaki in <a href="https://github.com/RcppCore/Rcpp/pull/1457">#1457</a> fixing <a href="https://github.com/RcppCore/Rcpp/pull/1454">#1454</a>)</p></li> <li><p>The parent environment is now accessed via <code>R_ParentEnv</code> (Dirk in <a href="https://github.com/RcppCore/Rcpp/pull/1460">#1460</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1459">#1459</a>)</p></li> <li><p>Change to returning <code>dataptr</code> again for better handling of empty vectors (Iñaki in <a href="https://github.com/RcppCore/Rcpp/pull/1462">#1462</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1461">#1461</a>)</p></li> <li><p>Undefined behavior errors in use of <code>ListOf</code> proxies have been addressed (Iñaki in <a href="https://github.com/RcppCore/Rcpp/pull/1464">#1464</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1463">#1463</a>)</p></li> <li><p>Under newer R version, <code>R_UnboundValue</code> is no longer used (Iñaki in <a href="https://github.com/RcppCore/Rcpp/pull/1466">#1466</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1465">#1465</a>)</p></li> <li><p>New R API access point <code>R_getRegisteredNamespace()</code> is used with current R versions (Dirk in <a href="https://github.com/RcppCore/Rcpp/pull/1469">#1469</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1468">#1468</a>)</p></li> <li><p>The <code>Nullable::as()</code> exporter now uses an explicit cast to the templated type (Dirk in <a href="https://github.com/RcppCore/Rcpp/pull/1471">#1471</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1470">#1470</a>)</p></li> <li><p>A memory leak in the variadic <code>Rcpp::warning()</code> template has been fixed (Kevin in <a href="https://github.com/RcppCore/Rcpp/pull/1475">#1475</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1474">#1474</a>)</p></li> <li><p>The <code>Nullable::operatorT()</code> has been added as a 'opt-out' (Dirk in <a href="https://github.com/RcppCore/Rcpp/pull/1477">#1477</a> with coordination in <a href="https://github.com/RcppCore/Rcpp/issues/1472">#1472</a>)</p></li> <li><p>Add templated integer-index overload for <code>operator[]</code> on small systems such as WASM (Jeroen Ooms in <a href="https://github.com/RcppCore/Rcpp/pull/1482">#1482</a>)</p></li> <li><p>The attribute accessors in <code>AttributeProxyPolicy</code> no longer rely on <code>get__()</code> (Kevin in <a href="https://github.com/RcppCore/Rcpp/pull/1484">#1484</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1483">#1483</a>)</p></li> </ul></li> <li><p>Changes in Rcpp Documentation:</p> <ul> <li>Reference in the bibliography used by the package vignettes have been updated.</li> </ul></li> <li><p>Changes in Rcpp Deployment:</p> <ul> <li><p>Excute permissions are set consistently on scripts with shebangs (Mattias Ellert in <a href="https://github.com/RcppCore/Rcpp/pull/1467">#1467</a>)</p></li> <li><p>R 4.5.* has been added to the CI matrix (Dirk in <a href="https://github.com/RcppCore/Rcpp/pull/1476">#1476</a>)</p></li> <li><p>Three nag messages issued when obsolete build flag accessors are used now show <code>Rcpp:::</code> (Dirk in <a href="https://github.com/RcppCore/Rcpp/pull/1480">#1480</a> fixing <a href="https://github.com/RcppCore/Rcpp/issues/1456">#1456</a>)</p></li> <li><p>Reference GitHub Actions have been updated to their current versions (Dirk in <a href="https://github.com/RcppCore/Rcpp/pull/1481">#1481</a>)</p></li> </ul></li> <li><p>Non-release Changes:</p> <ul> <li>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.</li> </ul></li> </ul> </blockquote> <p>Thanks to my <a href="https://dirk.eddelbuettel.com/cranberries/">CRANberries</a>, you can also look at a <a href="https://dirk.eddelbuettel.com/cranberries/2026/07/05/#Rcpp_1.1.2">diff to the previous interim release</a> along with pre-releases <a href="https://dirk.eddelbuettel.com/cranberries/2026/04/15#Rcpp_1.1.1-1">1.1.1-1</a> and <a href="https://dirk.eddelbuettel.com/cranberries/2026/04/24#Rcpp_1.1.1-1.1">1.1.1-1.1</a> 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.</p> <p>Questions, comments etc should go to the GitHub <a href="https://github.com/RcppCore/Rcpp/discussions">discussion</a> or <a href="https://github.com/RcppCore/Rcpp/issues">issue</a> section, or the <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel">Rcpp list</a>. Bugs reports are welcome at the GitHub <a href="https://github.com/RcppCore/Rcpp/issues">issue tracker</a> as well. GitHub offers decent search for issue, pull requests and discussions; as many topics have been covered it is worth checking as well.</p> <p style="font-size: 80%; font-style: italic;"> This post by <a href="https://dirk.eddelbuettel.com">Dirk Eddelbuettel</a> originated on his <a href="https://dirk.eddelbuettel.com/blog/">Thinking inside the box</a> blog. If you like this or other open-source work I do, you can <a href="https://github.com/sponsors/eddelbuettel">sponsor me at GitHub</a>. </p><p></p> Sun, 05 Jul 2026 15:18:00 +0000 https://bisco.org/notes/status-update-june-2026/ https://bisco.org/notes/status-update-june-2026/ <h1 id="debian-related-work">Debian Related Work</h1> <ul> <li>Uploaded wofi 1.5.3-1 to unstable</li> <li>Uploaded wob 0.16-1 to unstable</li> <li>Uploaded labwc 0.20.0-1 and 0.20.1-1 to unstable; these releases come with support for wlroots-0.20, which made labwc reenter testing</li> <li>Uploaded swaylock 1.8.5-2 to unstable to make it use the <code>common-auth</code> directive of pam (seeh <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140096">#1140096</a>)</li> <li>Uploaded swayimg 5.4-1 to unstable</li> <li>Uploaded wayback 0.3-2 to unstable, which was waiting in experimental for a reupload and I had forgotten about it; also fixed a <a href="https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/96">typo</a> in wayback upstream</li> <li>Uploaded xdg-desktop-portal-wlr 0.8.3-1 to unstable</li> </ul> <h1 id="dh-related-work">DH Related Work</h1> <p>The search app I was working on last month was still a focus in June. I refactored the data model a bit and made it simpler. I stumbled over the <a href="https://pythonkoans.substack.com">Python Koans</a> and <a href="https://pythonkoans.substack.com/p/koan-15-the-invisible-ink">Koan 15: The Invisible Ink</a> gave me the idea of using unicode normalization when indexing the items.</p> <p>I released a couple of bug fix releases for the APIS framework, namely 0.64.2, 0.64.3 and 0.64.4. I also release 0.65.0 which is one step further in dropping support for the legacy <code>apis_entities</code> app. When the <code>search</code> module is merged it will give way for removing the last bits of the old cruft to be removed.</p> <p>During a regular dependency update session I looked at the changes in <a href="https://github.com/yourlabs/django-autocomplete-light">the dal dependency</a>. After a long time with no commits, the project suddenly had a lot of commits co-authored by Claude and then released a new major version with a regression. Given the state of the project, we decided to keep using the previous release for now and look into replacing the dependency with an HTMX based solution. I implemented a POC for one of the plugins we develop and it was actually pretty easy. I also managed to combine the autocomplete approach with a multi-select form field, based on <a href="https://dev.to/apleshkov/htmx-multi-select-form-control-without-js-4jfk">this blog post</a>.</p> <p>In the <a href="https://www.oeaw.ac.at/de/acdh/forschung/dh-forschung-infrastruktur/aktivitaeten/dh-datenmodellierung/pfp-prosopographische-plattform-oesterreich">PFP</a> project I finally merged the stats endpoint which give statistics about the named graphs that are used as data sources.</p> <h1 id="other">Other</h1> <p>I attended <a href="https://bsidesvienna.at/">BSidesVienna 0x7EA</a> but it was on one of the hottest days this year so far so I left after a couple of talks.</p> Sun, 05 Jul 2026 05:28:51 +0000 http://blog.sesse.net/blog/tech/2026-07-04-15-21_an_update_on_sesse_chromium_org.html http://blog.sesse.net/blog/tech/2026-07-04-15-21_an_update_on_sesse_chromium_org.html <img src="http://planet.debian.org/heads/sesse.png" width="74" height="85" alt="" align="right" style="float: right;"> <p>As previously mentioned, I am leaving Chrome; my last work day was yesterday. (Sorry to those with July 3rd off that I didn't get to say goodbye to!) But I'm staying in Google, on more internal projects :-)</p> <p>After 1100+ commits it's hard to pick out one thing that I love the most; as a team, we launched a lot of (IMO) useful CSS features and fixed a lot of issues. But somehow, I keep on gravitating towards performance, and perhaps <a href="https://chromium-review.googlesource.com/c/chromium/src/+/3581992">this commit</a> is the one I will remember the most fondly; a couple hundred lines to speed up repeated attribute selectors a lot. (If you ever wonder who would be doing that; well, there's a fairly high chance that you have an extension injecting a stylesheet with a lot of <code>a[href*="..."]</code> rules…)</p> <p>Upwards and onwards. Please write lean, clean CSS; I won't be there to save you from now on. :-)</p> Sat, 04 Jul 2026 14:21:00 +0000 https://retout.co.uk/2026/07/04/aws-washington-summit-2026/ https://retout.co.uk/2026/07/04/aws-washington-summit-2026/ <p>I am somewhat jet-lagged, having returned from Washington DC just before the 250th anniversary celebrations which will be happening today. I was part of a delegation sent by my employer to the AWS Summit there this week, partly to kindle interactions between PA Consulting and Jacobs who have recently <a href="https://www.jacobs.com/newsroom/press-release/jacobs-acquire-remaining-stake-pa-consulting">taken a 100% share in PA</a>.</p> <p>Much of our conference time was spent in meetings with AWS executives impressing the facts of the Jacobs/PA partnership upon them, and discussing plans to broaden our collaboration in different sectors. So I spent even less time than usual at conference keynotes, talks etc.</p> <p>This was my first time to DC, and I did find some time to see some sights – unfortunately the White House is rather fenced off at the moment following the UFC match, but I did make it to the Capitol and the Washington Monument in the heat.</p> <p>Last Sunday a select few of us attended the <a href="https://www.mlb.com/orioles">baseball in Baltimore</a> – rather than the game, the thing that stood out for me was the military jets flying in formation over the stadium every few minutes, and the block-booked seats for the Navy in uniform, who were having a great time! This is obviously a hearts-and-minds thing, but it provides a stark contrast with the UK – I can’t think of a time I’ve seen uniformed military at the football (soccer) or cricket for example. Or Union Jacks flying at shopping centres.</p> <p>Speaking of soccer, England just about beat DR Congo while I was out there, but it was a close-run thing as we were 1-0 down at half time. I can’t claim to be following the World Cup too closely, but I overheard comments (from US passers-by) that made clear it would have had a significant reputational impact on our standing in the world had we lost.</p> <p>Another highlight for me was the <a href="https://www.asa-dc.org/">Church of the Ascension and St. Agnes</a>, where I was able to get my fix of Anglican plainchant and four-part harmony for the week. At morning prayer, I noted they use “God save this land” rather than “God save the King” during the responses – I’ve since found other sources online that choose “God save the State”. It’s strange to think that the words of the BCP dating back to 1549/1662 are a point of continuity since well before the 1776 declaration of independence, and yet are still adapted and used in worship today.</p> Sat, 04 Jul 2026 12:40:45 +0000 https://blog.jak-linux.org/2026/07/03/openssl-pandemic/ https://blog.jak-linux.org/2026/07/03/openssl-pandemic/ <p>Recently a person reported a bug in APT saying that TLS is failing on FIPS systems with MD5 errors, and suggested we call <code>ERR_clear_error()</code> around TLS operations.</p> <p>Like any serious software engineer would do, I said No. Just because one component failed to handle its errors does not mean I can go around and discard all errors in another place - the program should have failed earlier (or discarded the error when it was determined to be safe).</p> <p>Little did I know that people have for years been using this approach as a best practice: Codebases everywhere are littered with calls to <code>ERR_clear_error()</code> before performing TLS, and upstream themselves suggest to do just that.</p> <p>This is a major, systemic, pandemic of incomplete error handling. We cannot just discard unrelated errors if they become inconvenient. The code that caused the error needs to be fixed to handle it.</p> <p>This isn’t all. It seems many authors are not familiar with libraries using a stack of errors, and there is a second anti-pattern:</p> <p>Call an OpenSSL operation, check the top-level error, and then discard all errors if deemed “not too bad”. This has the same problem: Unrelated errors get silently discarded.</p> <p>I would strongly encourage everyone to inspect their code bases for any calls to <code>ERR_clear_error()</code> and whether they are safe or one of the bad patterns above (or maybe you find a new pattern). You may want to use error stack functionality of<code>ERR_set_mark</code> (<a href="https://docs.openssl.org/3.4/man3/ERR_set_mark/">https://docs.openssl.org/3.4/man3/ERR_set_mark/</a>) to essentially “push” and “pop” an error context of your own as a guard around multiple OpenSSL operations.</p> <p>To the OpenSSL authors, I would suggest not encouraging devastating security practices that fundamentally break any trust in software.</p> <p>We need to do better than this.</p> Fri, 03 Jul 2026 15:54:22 +0000 jak@jak-linux.org (Julian Andres Klode) tag:www.chiark.greenend.org.uk,2026-07-03:/~cjwatson/blog/activity-2026-06.html https://www.chiark.greenend.org.uk/~cjwatson/blog/activity-2026-06.html <img src="http://planet.debian.org/heads/cjwatson.png" width="70" height="82" alt="" align="right" style="float: right;"> <p>My Debian contributions this month were all <a href="https://www.freexian.com/about/debian-contributions/">sponsored</a> by Freexian.</p> <p>You can also support my work directly via <a href="https://liberapay.com/cjwatson">Liberapay</a> or <a href="https://github.com/sponsors/cjwatson">GitHub Sponsors</a>. Thanks to new sponsor <a href="https://github.com/fernandocc17">@fernandocc17</a>!</p> <h2>bugs.debian.org documentation</h2> <p>Sometimes I ask users to file bugs upstream themselves because I think they’d be better placed to have the ensuing discussion with the upstream maintainers directly rather than everything having to go through me. Of course sometimes they don’t want to do so, perhaps because it requires creating another account somewhere. Rarely, I’ve had people refuse to do this because the letter of the bug tracking system’s documentation seemed to tell them not to. Since I don’t believe that was the intention, I <a href="https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/1149">corrected this</a>.</p> <h2>OpenSSH</h2> <p>I spent two and a half hours extensively revising <code>debian/copyright</code> so that <code>lrc</code> believes it to be in sync with the output of <code>licensecheck</code>. I’m unconvinced that this was remotely worth the mind-numbing effort - as far as I can tell, it makes no difference to the practical legal position, to policy compliance, or to any reasonable user - but the <span class="caps">DFSG</span> team increasingly seems to be objecting to any discrepancies here any time a package crosses their radar, so this was a pre-emptive measure to avoid problems with some upcoming trips through the <span class="caps">NEW</span> queue.</p> <h2>OpenSSL 4.0</h2> <p>I fielded a few of the <a href="https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-openssl-devel%40lists.alioth.debian.org&amp;tag=openssl-4.0">OpenSSL 4.0 build failure bugs</a>:</p> <ul> <li><a href="https://bugs.debian.org/1138480">omniorb-dfsg</a> (along with upgrading to 4.3.4)</li> <li><a href="https://bugs.debian.org/1138423">openssh</a></li> <li><a href="https://bugs.debian.org/1138408">yubihsm-shell</a></li> </ul> <h2>Python packaging</h2> <p>New upstream versions:</p> <ul> <li>certipy</li> <li>juptyer-server (fixing <a href="https://bugs.debian.org/1136022"><span class="caps">CVE</span>-2025-61669, <span class="caps">CVE</span>-2026-35397, <span class="caps">CVE</span>-2026-40110, and <span class="caps">CVE</span>-2026-40934</a>)</li> <li>magicgui</li> <li>pydantic</li> <li>pydantic-core</li> <li>pydantic-settings</li> <li>pylint</li> <li>pytest-rerunfailures (fixing a <a href="https://bugs.debian.org/1140869">build failure with pytest 9.1</a>)</li> <li>python-certifi</li> <li>python-django-celery-beat</li> <li>python-numpy-groupies</li> <li>python-packaging (aided by Debusine testing of reverse-dependencies)</li> <li>python-pytest-run-parallel</li> <li>python-pytest-unmagic</li> <li>python-service-identity</li> <li>python-tabulate</li> <li>python-urllib3 (fixing <a href="https://bugs.debian.org/1140427"><span class="caps">CVE</span>-2026-9375</a> and <a href="https://bugs.debian.org/1136654"><span class="caps">CVE</span>-2026-44432</a>)</li> <li>python-watchfiles</li> <li>python-yubihsm</li> <li>responses</li> <li>uncertainties</li> </ul> <p>pytest 9.1 was uploaded to unstable this month, resulting in quite a few new build/test failure bugs. I tried to keep on top of as many of these as I could; most of them had one of a small number of similar causes.</p> <ul> <li><a href="https://bugs.debian.org/1140858">domdf-python-tools</a> (<a href="https://github.com/domdfcoding/domdf_python_tools/pull/151">contributed upstream</a>)</li> <li><a href="https://bugs.debian.org/1140978">flask-caching</a> (<a href="https://github.com/pallets-eco/flask-caching/pull/652">contributed upstream</a>)</li> <li><a href="https://bugs.debian.org/1140863">magicgui</a> (<a href="https://github.com/pyapp-kit/magicgui/pull/731">contributed upstream</a>)</li> <li><a href="https://salsa.debian.org/python-team/packages/pydantic-core/-/commit/0b294b4e0841b63d2a6ace55b9fbb6ec50fae6d3">pydantic-core</a></li> <li><a href="https://bugs.debian.org/1140865">pydantic-extra-types</a> (<a href="https://github.com/pydantic/pydantic-extra-types/pull/397">contributed upstream</a>)</li> <li><a href="https://bugs.debian.org/1140866">pydantic</a> (<a href="https://github.com/pydantic/pydantic/pull/13357">contributed upstream</a>)</li> <li><a href="https://bugs.debian.org/1140867">pylint</a></li> <li><a href="https://bugs.debian.org/1140868">pytest-codeblocks</a></li> <li><a href="https://bugs.debian.org/1140875">python-docx</a> (<a href="https://github.com/python-openxml/python-docx/pull/1563">contributed upstream</a>)</li> <li><a href="https://bugs.debian.org/1140879">python-numpy-groupies</a> (<a href="https://github.com/ml31415/numpy-groupies/pull/96">contributed upstream</a>)</li> <li><a href="https://bugs.debian.org/1140880">python-openapi-core</a> (<a href="https://github.com/python-openapi/openapi-core/pull/1207">contributed upstream</a>)</li> <li><a href="https://bugs.debian.org/1140932">python-urllib3</a> (<a href="https://github.com/urllib3/urllib3/pull/5094">contributed upstream</a>)</li> <li><a href="https://bugs.debian.org/1140883">python-watchfiles</a></li> <li><a href="https://bugs.debian.org/1141032">sphinx-automodapi</a></li> </ul> <p>Python 3.14 became the default Python version in unstable towards the end of the month, starting a <a href="https://bugs.debian.org/1130323">transition</a>. These usually involve quite a bit of work, and there’s much more to do, but I fixed a few things:</p> <ul> <li><a href="https://bugs.debian.org/1140927">depthcharge-tools: Traceback with 3.14: args for positionals must be != 0</a></li> <li><a href="https://bugs.debian.org/1131793">domdf-python-tools: autopkgtest failure with Python 3.14</a></li> </ul> <p>Other build/test failures:</p> <ul> <li><a href="https://bugs.debian.org/1140059">dh-python: Dependency parsing is too picky about spacing</a></li> <li><a href="https://salsa.debian.org/python-team/packages/psygnal/-/commit/060a129ae5267e404510bdcb5e2bfb20eafe9c25">psygnal: Allow building without msgspec</a></li> <li><a href="https://salsa.debian.org/python-team/packages/pydantic-core/-/commit/0ec1508c0ff9cfeb2677fba4a0a29cc2cd19cabf">pydantic-core: Accept and require uuid 1.23.0, now that it’s in Debian</a></li> <li><a href="https://bugs.debian.org/1135448">pygame: <span class="caps">FTBFS</span>: <span class="caps">FAIL</span>: test_fill_rle (pygame.tests.surface_test.SurfaceTypeTest.test_fill_rle)</a></li> <li><a href="https://bugs.debian.org/1139431">pyro5: <span class="caps">FTBFS</span>: Unable to determine debhelper compatibility version</a></li> <li><a href="https://bugs.debian.org/1139197">python-persistent: Bump timeout in test_rapid_create_destroy_cycle</a> (<a href="https://github.com/zopefoundation/persistent/pull/238">contributed upstream</a>)</li> <li><a href="https://bugs.debian.org/1140667">python-yubihsm: Depends: python3-cryptography (&lt; 47) but 47.0.0-1 is to be installed</a></li> <li><a href="https://bugs.debian.org/1138813">sphinx-gallery: &lt;!nodoc&gt; build dependency removed from testing</a></li> <li><a href="https://salsa.debian.org/python-team/packages/tpm2-pytss/-/commit/0b9dcb5d369f2f32d904437e7880cec0381745e0">tpm2-pytss: Fix support for cryptography 47</a></li> <li><a href="https://bugs.debian.org/1140931">twisted: Tests fail with pyopenssl 26.3.0: module ‘OpenSSL.crypto’ has no attribute ‘X509Req’</a></li> </ul> <p>Other bugs:</p> <ul> <li><a href="https://salsa.debian.org/python-team/packages/psygnal/-/commit/0bc98b31531ab5ce3f6f465b16780ed932633fe6">psygnal: Fix reproducibility</a></li> <li><a href="https://bugs.debian.org/1138937">python-nacl: Updating the python-nacl Uploaders list</a></li> <li><a href="https://bugs.debian.org/1046910">python-tabulate: Fails to build source after successful build</a></li> <li><a href="https://bugs.debian.org/1046308">tpm2-pytss: Fails to build source after successful build</a></li> </ul> <h2>Rust packaging</h2> <p>New upstream versions:</p> <ul> <li>rust-asn1 (<a href="https://bugs.debian.org/1134917">needed by new python-cryptography</a>)</li> <li>rust-asn1-derive</li> </ul> <h2>Code reviews</h2> <ul> <li><a href="https://bugs.debian.org/1129695">buildbot: [<span class="caps">INTL</span>:sv] Swedish translation of debconf templates</a> (merged and uploaded)</li> <li><a href="https://salsa.debian.org/ssh-team/openssh/-/merge_requests/39">openssh: Support DPKG_ROOT</a> (merged and uploaded)</li> <li><a href="https://salsa.debian.org/ssh-team/openssh/-/merge_requests/41">openssh: Fix <span class="caps">GSS</span> C25519 server blob bounds check</a> (merged and uploaded)</li> <li><a href="https://salsa.debian.org/python-team/packages/python-pyramid/-/merge_requests/1">python-pyramid: <span class="caps">CVE</span>-2023-40587 Backport patch</a> (merged and uploaded)</li> </ul> <h2>Other bits and pieces</h2> <ul> <li><a href="https://bugs.debian.org/1140062">busybox: chdir no longer available -&gt; breaks d-i ‘live-installer.udeb’</a></li> <li><a href="https://salsa.debian.org/debian/debmirror/-/commit/7d25662cd048afbe8f90a437466dc1d8751a3e89">debmirror: Refresh mirror_size documentation</a></li> </ul> Fri, 03 Jul 2026 11:38:46 +0000 https://codon.org.uk/~mjg59/blog/p/securing-agentic-identity/ https://codon.org.uk/~mjg59/blog/p/securing-agentic-identity/ <img src="http://planet.debian.org/heads/mjg59.png" width="69" height="85" alt="" align="right" style="float: right;"> <p>As is the case for many people working in the security industry, the last few months of my life have been focused on dealing with people wanting to use LLMs everywhere. From an enterprise security perspective that’s not an inherent problem - what’s more of a problem is that people want those agents to have access to resources like their calendar and email and so on, and now we have somewhat non-deterministic agents that seem very enthusiastic to achieve what you asked whether that’s a good idea or not, and we’re combining this with credentials that give them access to sensitive data, and leaving those credentials on disk where they can be committed into git repos or exfiltrated to some other service to make use of them on the agent’s behalf or well just any other number of things, at which point your CEO’s email is suddenly readable by everyone and you’re having a bad day.</p> <p>As I mentioned in my <a class="link" href="https://codon.org.uk/~mjg59/blog/p/preventing-token-theft/" rel="noopener" target="_blank">last post</a>, pretty much every strong mechanism for keeping credentials in place is just not supported in the wider world. We can imagine a universe where agents use hardware (or at least hypervisor) backed certificates to obtain credentials and any that end up leaking are worthless as a result. But, sadly, that’s not an option for most people using existing identity providers. The state of the art is that you use the <a class="link" href="https://mjg59.dreamwidth.org/62175.html" rel="noopener" target="_blank">device code flow</a> and a human authenticates and the token ends up back inside the agent environment and then it proceeds to do whatever it wants with it and you just hope that you wake up the next morning without an awful infoleak occurring.</p> <p>(An aside: I do not like the device code flow as used in enterprise environments, and I never will. The identity provider doesn’t have a real opportuity to inspect the security posture of the system asking for the token, and as a result some identity providers will restrict tokens that are issued in this way. The common alternative of doing stuff using a more standard flow and having a redirect URI pointing at localhost works fine for local systems and is a pain for remote ones, even if you can commit crimes with SSH forwarding. I’m going to suggest something that I think is better, and you are free to disagree)</p> <p>I’m not in a position to get every identity provider and service provider to change their security posture, so I’m somewhat stuck in terms of the tokens they’re willing to issue me - largely either JWTs or opaque access tokens, with no support for any mechanism of binding that token to an instance. The token that’s going to have to be provided to the remote service is something I have little influence over. But that doesn’t mean I can’t influence the token that lands inside the agent’s environment. I can issue a placeholder token to the agent, and force it to communicate via a proxy that swaps out the placeholder for the real thing. The worst the agent can do is exfiltrate the placeholder token, and as long as malicious actors don’t have access to that proxy, it doesn’t matter - nobody else can do anything with the placeholder.</p> <p>This isn’t a terribly novel insight, and it seems like almost everybody has reinvented this on their own. But a lot of these implementations involve you somehow obtaining the real token in advance and then pasting that into something that generates a placeholder that you provide to your agent environment somehow, and it’s all a bit clunky and awkward, and it also means that you need to deal with something that keeps track of the mapping between placeholders and real tokens and oh no we’ve just invented a secret store, and if you want this to work at scale and reliably you’re just invented a high availability distributed secret store, and a lot of people who’ve read that are now shaking their heads and reaching for gin. Can we simplify this, and improve security at the same time? I think we can!</p> <p>Remember when I said “as long as malicious actors don’t have access to that proxy, it doesn’t matter”? What if they do? What if they compromise one machine inside your environment and are then able to email a bunch of employees and convince their agents to send more tokens back to them and then delete the email before a human reads it? Now you have someone inside the wall with access to those tokens, and presumably with access to the proxy, and now they can be anyone whose agent was gullible enough to think sending them a token was a good idea. This isn’t good!</p> <p>So, I thought for a while, and I came up with a new idea. We can have a broker service that obtains credentials for us. We can run that centrally, away from the agents. A client in an agentic environment can request a token, and that can result in a URL being generated and the user being directed to open a URL in a browser and authenticate. When the user authenticates, the authentication flow redirects the confirmation back via the broker, and the broker obtains the real auth token. The obvious thing to do now would be to return the auth token to the client in the agentic environment, but we don’t do that. Instead, we mint a new JWT, and add a new claim - one that contains an encrypted copy of the token. In the process we can copy over all the original claims, because those aren’t secret - and now even if the client inspects the token to figure out what access it has, it’ll get a correct answer. We sign the new token with our own signing key, and pass that back to the client. The client now has a legitimate JWT that is utterly useless, because the signature isn’t trusted by anyone other than us.</p> <p>How does it use it? It makes an API request via a proxy, including the new token in the Authorization: header. The proxy verifies the signature on the token, and then decrypts the original token and swaps out the fake token for the real one. The remote API sees what it expects, and everyone is happy. There’s never a real token in the agentic environment, but also we don’t need to store anyting anywhere. The only state is the encryption keys, and those can be injected into the environment at startup. You need to scale? Just start more of these processes. You need to support multiple availability zones? Just start more of these processes in different places. No persistent data is ever held in the broker or the proxy. You don’t need to care about distributed databases or secret stores.</p> <p>This felt wonderfully elegant and I felt smug about coming up with a better idea, and then I went to a bar earlier this week and sat down to read <a class="link" href="https://datatracker.ietf.org/doc/html/rfc8705" rel="noopener" target="_blank">RFC 8705</a> and the guy next to me saw that over my shoulder and asked what I was reading and I explained why I was interested and we talked about agentic identity and then he mentioned that fly.io had something that sounded <a class="link" href="https://fly.io/blog/tokenized-tokens/" rel="noopener" target="_blank">very similar</a> and I read that and gosh yes it is very similar, so damn you fly.io for stealing my ideas 3 years before I even had them. Anyway. Now I need to do better.</p> <p>Remember that there’s still a risk around anyone who has access to the proxy having access to the encrypted keys? We can remove that risk as well. It’s not uncommon for agentic environments to have an identity issued via something like <a class="link" href="https://spiffe.io/" rel="noopener" target="_blank">SPIFFE</a>, at which point they have a client certificate. You can probably guess where I’m going with this. If we require that an agent present a client cert to the broker when requesting a token, we can embed a representation of that client cert into the token we mint. The proxy can then require mTLS for the client connection, and can verify that the presented certificate matches the one represented in the token. If it does then whoever’s using the token has access to the private key associated with the environment it was issued to. If we then ensure that the private keys backing these certificates are either hardware or hypervisor backed, and as such tied to a specific instance, we now have a high degree of confidence that the token can only be used in its intended environment. Even if our identity provider doesn’t support RFC 8705, we can.</p> <p>This is fairly straightforward where you’re using a platform where your identity provider is also the environment that’s consuming your tokens, and more annoying for third parties. The broker potentially needs some amount of third party vendor knowledge to make that work for everyone. This is even more the case where login isn’t via your identity provider (thanks, github), but none of this is insurmountable - just annoying. And where vendors issue opaque tokens rather than JWTs, this still isn’t a problem; we can just mint a new JWT that includes the opaque token as an encrypted claim, and include the same certificate binding. The opaque token ends up being the thing that’s presented to the third party, but only after we’ve verified the mTLS binding.</p> <p>In an ideal world none of this would be necessary - someone would spin up a new agentic environment, a user would prove their identity, and a certificate embodying that identity would be issued to the environment with a private key that can’t be exfiltrated. That certificate would be sufficient to obtain new certificates associated with the same private key, and we could still bind that into mTLS identity. This would be much simpler, but browsers don’t support it, so it’s not likely to happen any time soon.</p> <p>Anyway. Even if we can’t have the best thing, we can do better than we are at the moment, and also it would be lovely if we could standardise on this rather than have everyone build their own thing. The end.</p> Fri, 03 Jul 2026 00:38:23 +0000 http://joeyh.name/blog/entry/no_LLM_code_in_dependencies/ http://joeyh.name/blog/entry/no_LLM_code_in_dependencies/ <img src="http://planet.debian.org/heads/joeyh2.png" width="84" height="75" alt="" align="right" style="float: right;"> <p>I've spent about 100 hours of work over the past month to make sure git-annex can build without dependencies that contain LLM generated code. At least so far.</p> <p><a href="https://git-annex.branchable.com/no_llm_code/">https://git-annex.branchable.com/no_llm_code/</a></p> <p>Needing to review a program's whole dependency tree on an ongoing basis is apparently what programming has come to?</p> <p>I've found some real stinkers. Large LLM generated changes being reverted in the next release without any explanation. An incoherent 1489 line commit message with 10,000 lines of changes to a 26,000 LOC code base. A LLM prompt to copy code from another project that seems to have only avoided being copyright infringement due to luck.</p> <p>I now have additional information about the quality of dependencies which will surely influence future decisions. As far as I can see, that's the only positive benefit of this work.</p> <p>I realize that I am probably trying to hold back the tide at this point. That appears to be why Software Freedom Conservancy <a href="https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html">punted</a>, and I doubt that the FSF will do any better.</p> <p>As these dominos fall, I am reconsidering my participation in these communities. But I continue my work and support my users.</p> <p>It may seem easy to prompt a LLM with</p> <blockquote><p>Add fourmolu config and restyled</p> <p>neat</p> <p>format a module</p></blockquote> <p>And commit the result and call yourself a 10xer. But please consider the broader impact of your actions. (In the above case, that project lost my further collaboration on it.)</p> Thu, 02 Jul 2026 14:06:30 +0000 https://codon.org.uk/~mjg59/blog/p/preventing-token-theft/ https://codon.org.uk/~mjg59/blog/p/preventing-token-theft/ <img src="http://planet.debian.org/heads/mjg59.png" width="69" height="85" alt="" align="right" style="float: right;"> <p>When you log into a service you’re given an authentication token. Each further request to the site includes that token, allowing the server to figure out who you are and ensuring that you have access to your data. Depending on site policy, this token may either be stored in memory (and so vanish if you restart your browser) or disk. The token is the proof of your identity. As far as the site is concerned, anyone with your token is you. These tokens may be traditional browser cookies, but they may also be stored in either site local storage or (if you’re not using a browser) in some other storage location.</p> <p>In recent years we’ve seen infostealer malware (like <a class="link" href="https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-141b" rel="noopener" target="_blank">LummaC2</a>) gain the ability to exfiltrate user tokens, allowing attackers to gain access to the user’s data without needing to retain access to the user’s machine. This attack is viable even if the site has strong MFA requirements, so passkeys don’t help. Encrypting the tokens on disk doesn’t prevent the malware from scraping them out of the browser’s RAM or obtaining whatever key is used to encrypt them. This feels like a pretty hard problem to solve.</p> <p>But that hasn’t stopped people from trying! Dirk Balfanz wrote an IETF draft describing a mechanism for using <a class="link" href="https://datatracker.ietf.org/doc/html/draft-balfanz-tls-obc-01" rel="noopener" target="_blank">self-signed certificates for TLS authentication</a>. This uses the <a class="link" href="https://en.wikipedia.org/wiki/Mutual_authentication#mTLS" rel="noopener" target="_blank">mutual authentication</a> feature of the TLS protocol that requires both sides prove their identity to each other. In regular TLS, the remote site presents a signed certificate that tells you who it is. When performing mutual authentication, you then present a certificate to the remote site telling it who <em>you</em> are. These client certificates are largely unused outside enterprise environments because they’re a <em>huge</em> pain to deploy. It’s not so much that this has sharp edges, it’s that it’s entirely made of sharp edges. Managing certificate deployment to your devices is hard. Browsers get confused if the certificates change under them. You have one certificate and it lives forever, so sites you present it to can track your identity. Users are prompted to choose a certificate to authenticate with, and if they pick the wrong one everything breaks and is hard to recover. I’ve deployed this and I did not have a good time.</p> <p>But Balfanz’s idea was simple. Rather than require certificates to be deployed, browsers would simply generate a certificate on the fly. The goal wasn’t to prove the device or user’s identity in any global way - but it would associate a TLS session with a specific certificate. You could then, for example, include a hash of the certificate in the cookie, and if someone tried to use that cookie without presenting that certificate then the cookie could be rejected. If the browser used a hardware-backed private key for the certificate then it would be impossible for an attacker to steal it. Sure, you could still steal cookies, but you wouldn’t be able to use them.</p> <p>This was written almost 15 years ago, and seems simple, elegant, and functional. It didn’t happen. Part of the reason for that is that, well, it wasn’t quite so simple. One problem was privacy related. Cookies are only sent after the TLS session is established, so anyone monitoring the network doesn’t know anything about the user identity. A naive implementation of this approach would have meant the client certificate being sent before session establishment, and now user identity can be tracked (no longer an issue if this was implemented on top of TLS 1.3, but this was a log time ago). This was avoided by reordering the client handshake, but that meant having to modify the TLS specification and implementations would have to be updated to support this. Another was that figuring out the granularity of the certificates was difficult. You’d want to use different certificates for every site to avoid them effectively becoming tracking cookies, but you need to provide the certificate before cookies are set, and you don’t know what origin the site is going to set in its cookies. If you generate a certificate for a.example.com and a different one for b.example.com, and a.example.com sets a cookie for *.example.com and includes the certificate you used for a.example.com, that cookie isn’t going to work on b.example.com and things are broken. This meant supporting it wasn’t as straightforward as it seemed - you’d need to ensure that your cookie scope was compatible with the certificate scope. You could probably make this work well enough by aligning it with the <a class="link" href="https://publicsuffix.org/" rel="noopener" target="_blank">Public Suffix List</a>, but there was still some risk of expectations not being aligned.</p> <p>And, perhaps most importantly, <a class="link" href="https://datatracker.ietf.org/doc/html/rfc5077" rel="noopener" target="_blank">TLS session resumption</a> (replaced by <a class="link" href="https://datatracker.ietf.org/doc/html/rfc8446#page-15" rel="noopener" target="_blank">pre-shared keys</a> in TLS 1.3) somewhat defeats the purpose of the exercise - clients store state that allows them to re-establish a TLS connection without performing certificate exchange (this reduces overhead if a connection gets interrupted or you switch to a new network or anything along those lines), and anyone in a position to steal cookies could steal that state as well.</p> <p>The followup attempt was <a class="link" href="https://datatracker.ietf.org/doc/html/draft-balfanz-tls-channelid-01" rel="noopener" target="_blank">channel IDs</a>. This simplified the implementation somewhat - rather than certificates, a raw public key would be sent, along with proof of possession of the private key in the form of a signature over a portion of the TLS handshake. This was required even in the event of session resumption, which avoided having to worry about theft of session secrets. The timing of the exchange was after the encrypted session had been established, so user identity couldn’t be leaked that way either. Cookies could then be bound to this identifier. Unfortunately it didn’t really deal with the problem of scoping keys in a way that would match cookie requirements, and the spec suggests that the right way of handling this is to scope keys to TLDs, which would enable user tracking across sites (Chrome’s implementation apparently restricted it to eTLD+1, which would match the third party cookie policy and avoid the tracking risk).</p> <p>Chrome added support for this, but it was <a class="link" href="https://groups.google.com/a/chromium.org/g/net-dev/c/AjFQjBmaEQE/m/gIXoV3IFCQAJ?utm_medium=email&amp;utm_source=footer" rel="noopener" target="_blank">removed in early 2018</a>. The discussion of some of the pain points in that message is interesting, explicitly calling out problems with connection coalescing across domains and the incompatibility with zero-RTT TLS1.3. The overall consensus at the time seems to be that trying to solve this entirely at the TLS layer has too many rough edges, and a different approach should be taken.</p> <p>And so almost 7 years after the initial draft for origin bound certificates, we come to <a class="link" href="https://datatracker.ietf.org/doc/html/rfc8471" rel="noopener" target="_blank">token binding</a>. This ended up being a rather more complex endeavour, covering 3 different RFCs describing how it impacts TLS, how to incorporate it into HTTP, and how to manage all the various parties involved in the process. The short version is that it’s pretty similar to channel ID, except that there’s also a documented mechanism for allowing tokens to be bound to one party and consumed by another, avoiding any need for widely scoped keys. Token binding effectively solved all the issues in the original proposal, but at the cost of somewhat more complexity.</p> <p>The RFC was finalised in October 2018. Chrome removed its (incomplete, draft) support for token binding in November 2018. Edge carried support until late 2024. Despite getting all the way through the RFC process, it’s functionally dead.</p> <p>The process up until this point had been largely initiated by Google, with Microsoft contributing significantly to the token binding standards. The work had been focused on identifying a generic solution to the problem rather than tying it to any specific authentication flow. The next step was in a different direction - rather than trying to fix this for the entire internet, how about we try to fix it for OAuth?</p> <p><a class="link" href="https://datatracker.ietf.org/doc/html/rfc8705" rel="noopener" target="_blank">RFC 8705</a> is titled “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens”. This is basically the 2011 approach, but (a) with an explicit definition of how the certificate should be incorporated into issued auth cookies, and (b) with a proviso that well uh if you’re going to use tokens issued by your IdP to authenticate to someone else then well you’re going to need to use the same cert for both. This is probably fine for the company-owned-laptop case where you’re actually fine with multiple sites being able to tie identities together (that’s kind of the point here!), and also works for “I am using an app and not a browser”, but doesn’t work for more generic scenarios. It also doesn’t seem to take the session resumption case into account at all? Support for RFC8705 seems poor, as far as I can tell of the big players only Auth0 implements it. In theory it works fine with self-signed client certs but in reality that’s going to be almost as difficult to support across multiple platforms as just issuing proper client certs in the first place, so deployment is going to be kind of a pain. But the good news is it doesn’t rely on any TLS extensions or custom browser behaviour, so at the client side it works fine with any browser.</p> <p>Which brings us on to <a class="link" href="https://datatracker.ietf.org/doc/html/rfc9449" rel="noopener" target="_blank">RFC 9449</a>, “Demonstrating Proof of Possession”. This goes even further than RFC8705 in terms of reducing the burden of deployment - it works fine with existing browsers, <em>and</em> it doesn’t even require any certs. The client generates a keypair and provides the pubkey when requesting the cookie. The cookie contains the pubkey. Every request to the service now provides the cookie with the pubkey and also provides a signature over the URI and HTTP method. If the signature matches the pubkey in the token then clearly the signature came from the machine the token was issued to, and everything is good.</p> <p>This does come with some downsides, though. The first is that it uses browser interfaces to generate the keys (typically <a class="link" href="https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/generateKey" rel="noopener" target="_blank">crypto.subtle.generatekey()</a>) and as far as I can tell there are no browsers that guarantee that that key is going to be generated in hardware even if it’s marked non-exportable, so anyone able to steal the cookies can also steal the keys. The second is that the signature only covers the URI and HTTP method, and not the message content or any other headers, so anyone able to exfiltrate a valid signature can replay it against the same URI with different message content. The recommended way to handle this is to reject any signatures that weren’t generated within the last few seconds, which is a wonderful additional way to allow clock skew to give you a Bad Day. And the third is that every single request has to be separately signed, which is not intrinsically a problem because computers are fast and have multiple cores, but if you’re trying to solve the first problem by sticking the key in a TPM then you’re dealing with something that’s slow and single threaded and that’s maybe acceptable if you’re using client certificates (because there’s going to be one signature per session and you can use the same session for multiple requests) but probably not if you’re dealing with a user opening a browser that restores previous tabs and each of those is a webapp that fires off 100 requests in parallel.</p> <p>In case it wasn’t clear, I don’t like DPoP. It doesn’t feel like it actually solves the underlying problem that we see in the real world (malware running in a context where if it can grab the tokens it can grab the keys), it adds a massive amount of overhead, and it has baked in replay vulnerabilities. I don’t know why it exists and I’m incredibly suspicious of vendors telling me that it fixes my problems, because if they’re telling me that then I’m going to end up assuming that they either don’t understand my problems or they don’t understand their technology, and neither of those is good.</p> <p>Still. Then we get to the thing that prompted me to write this - Chrome’s announcement that they had <a class="link" href="https://security.googleblog.com/2026/04/protecting-cookies-with-device-bound.html" rel="noopener" target="_blank">launched device-bound session credentials</a>. This is interesting because it’s a Chrome feature that’s explicitly intended to counter on-device malware, which was one of the things that was out of scope in 2018 when token binding was being removed. Since this is entire web level it doesn’t have to be an RFC, and so is instead defined <a class="link" href="https://w3c.github.io/webappsec-dbsc/" rel="noopener" target="_blank">by W3C</a>. I’m going to handwave all the complexity and say that it’s basically a way to register a public key when a cookie is issued, and then prove possession of the private key when it’s time to renew the cookie. By making the cookies shortlived and having support for rotating them in the background, user impact is basically zero and while it’s still possible for an attacker to exfiltrate and use a cookie they’ll only be able to do so for a short window before it needs to be refreshed - something the attacker can’t do, since they don’t have the private key. This avoids the DPoP overhead because you only need to do signing once per cookie per cookie lifetime, and not on every single request. I don’t <em>like</em> this due to the window where exfiltrated tokens can be used, but it feels like a strict improvement over the status quo. An extension called <a class="link" href="https://github.com/w3c/webappsec-dbsc/blob/main/DBSCE/Overview.md" rel="noopener" target="_blank">device-bound session credentials for enterprise</a> allows pre-enrollment of device keys, so even though the actual runtime DBCE flow doesn’t involve certificates, certificates can be used for device registration in enterprise environments and you can make sure that auth cookies only go to trusted devices. Unfortunately this is Chrome-only, and so we’re going to need to wait for it to be backported to all the random app frameworks for it to have widespread support on mobile or for almost everyone’s desktop app that’s actually three websites in an Electron wrapper. Mozilla’s <a class="link" href="https://github.com/mozilla/standards-positions/issues/912#issuecomment-4840591341" rel="noopener" target="_blank">current position</a> is that they’re not in favour of it, so I guess we’ll see where Safari lands in terms of broad uptake.</p> <p>The last thing on my list is <a class="link" href="https://datatracker.ietf.org/doc/draft-mw-oauth-tls-session-bound-tokens/04/" rel="noopener" target="_blank">another client cert/OAuth binding</a>, this one still in draft state at the time of writing. This one is aimed primarily at the use of agent-driven tooling, where you have something running in the background using a whole bunch of tools that are each acting on your behalf. Authenticating to all of them separately isn’t a fun time, but giving broadly scoped access tokens to a non-deterministic agent and trusting that it’ll never post them somewhere public also isn’t a fun time. The key distinction between it and RFC8705 is that it’s aimed at <em>connections</em> rather than <em>sessions</em>, which avoids the worries about session resumption. This is done with <a class="link" href="https://datatracker.ietf.org/doc/html/rfc5705" rel="noopener" target="_blank">TLS Exporters</a>, which in TLS 1.3 should be unique to the connection even over session resumption (TLS 1.2 may reuse some of the same key material for exporters over session resumption, so it’s recommended to enforce 1.3 for this). By providing a new signature alongside the cookie on every new connection, the client proves that it still has access to the private key. This is a very new spec and I haven’t had much time to work through it yet, but my naive understanding is that unlike RFC8705 this would require some additional client support to be able to regenerate the client signature on every TLS reconnection.</p> <p>This doesn’t avoid all the problems that RFC8705 has, including how to scope certificates. For the agentic use case that probably doesn’t matter - all these tools are acting on behalf of the same user, it’s fine if all the sites involved know they’re the same user. But it doesn’t solve the general purpose user use case, and right now DBSC seems like the best we have there.</p> <p>But. Part of me still wonders whether <a class="link" href="https://datatracker.ietf.org/doc/html/draft-balfanz-tls-obc-01" rel="noopener" target="_blank">Dirk Balfanz’s</a> approach was the right one. Yes, there’s risk associated with TLS session resumption, but in the worst case you could just switch that off for high risk setups. The cookie scope argument is real, and also in cases where it could violate privacy the site owner could already choose to broaden their cookie scope and violate your privacy, and in cases where it breaks things you could just not make use of it. The other problems are largely fixed by TLS 1.3, and then we’re just left with “Browsers handle client certificates badly” to which my answer is “Yes, and we should fix that anyway”.</p> <p>Despite having a pretty good answer to this solution over a decade ago, the closest we have to actual deployment is something that offers strictly worse security guarantees. And tokens keep getting stolen, and compromises keep occurring, and for the most part people shrug and get on with things.</p> Thu, 02 Jul 2026 02:23:45 +0000 https://blog.trueelena.org/blog/2026/07/02-a_pair_of_hair_towel_wraps/index.html https://blog.trueelena.org/blog/2026/07/02-a_pair_of_hair_towel_wraps/index.html <article> <section class="header"> Posted on July 2, 2026 <br /> Tags: <a href="https://blog.trueelena.org/tags/madeof%3Aatoms.html" title="All pages tagged 'madeof:atoms'.">madeof:atoms</a>, <a href="https://blog.trueelena.org/tags/craft%3Asewing.html" title="All pages tagged 'craft:sewing'.">craft:sewing</a>, <a href="https://blog.trueelena.org/tags/FreeSoftWear.html" title="All pages tagged 'FreeSoftWear'.">FreeSoftWear</a> </section> <section> <p><img alt="Two trapezoid shaped hoods made out of off-white towels: one is still looking new, while the other one has been bleached and roughened by having been washed many times." class="align-center" src="https://blog.trueelena.org/blog/2026/07/02-a_pair_of_hair_towel_wraps/hair_towel_wraps.jpg" style="width: 80.0%;" /></p> <p>Many months ago I had been ordering some furniture from IKEA<a class="footnote-ref" href="https://blog.trueelena.org#fn1" id="fnref1">¹</a> and on one of those orders I got tempted by a <a href="https://www.ikea.com/nl/en/p/stjarnbuske-hair-towel-wrap-natural-50540181/">hair towel wrap</a>: it mostly worked as an idea, but it was too short for my hair.</p> <p>On the other hand, I had two old towels I wasn’t using, and a recently unpacked sewing machine.</p> <p><img alt="A towel cut in two trapezoid halves with a STJÄRNBUSKE laid on top of it: the IKEA wrap is a bit less than 10 cm less deep, and at least 30 cm shorter, and is also triangular rather than a trapezoid." class="align-center" src="https://blog.trueelena.org/blog/2026/07/02-a_pair_of_hair_towel_wraps/comparison_with_original.jpg" style="width: 80.0%;" /></p> <p>I didn’t plan too much, I just put the STJÄRNBUSKE over the towel, cut, realized that the two pieces didn’t fit with right sides together, cut the second towel (I had planned to make two wraps, anyway, so it wasn’t a big deal), and started sewing by machine in what seemed like a reasonable procedure, taking notes and pictures.</p> <p><img alt="A towel, with its original care label, that has been cut in a trapezoid shape and reassembled into a hood shape with a long triangular tail. The machine sewn finishing is still neat and pristine." class="align-center" src="https://blog.trueelena.org/blog/2026/07/02-a_pair_of_hair_towel_wraps/machine_sewn_towel_new.jpg" style="width: 80.0%;" /></p> <p>The result was pretty good, and I started using it every time I washed my hair, but then I started to entertain the idea of shooting myself sewing the second one by hand for a video, but never found the time to actually doing it, and the pieces remained in the Pile for months, and months, and way more than a year.</p> <p><img alt="The head of a woman with a turban-like thing on the head, covering all of the hair except for a tiny bit at the center front." class="align-center" src="https://blog.trueelena.org/blog/2026/07/02-a_pair_of_hair_towel_wraps/cheesecloth_wrap_worn_front.jpg" style="width: 80.0%;" /></p> <p>Until one day I bought a meter of cotton cheesecloth (mostly because it was almost cheaper than buying a sample) and it felt like a good material to make a nicely looking head wrapper, to keep my hair out of the way when needed.</p> <p><img alt="A woman in a bathrobe with her head tilted downwards, covered by a towel thing that lies on the back of the head and has a long tail hanging on the front, in the process of being wrapped around the hairs and then brought over the top and back." class="align-center" src="https://blog.trueelena.org/blog/2026/07/02-a_pair_of_hair_towel_wraps/wearing_the_wrap.jpg" style="width: 80.0%;" /></p> <p>A couple months later, it was finally time to bring this project to the top of the list, and even if I was sewing two by hand it went pretty quickly: we had a weekend when it was too hot to do anything else, and by the end of it the wraps were done.</p> <p>All that remained was finish writing the <a href="https://blog.trueelena.org">instructions for my FreeSoftWear patterns website &lt;https://sewing-patterns.trueelena.org/contemporary_unisex/headwear/hair_towel_wrap/index.html&gt;&gt;</a>, and having some pictures taken, and this project was done.</p> <p>And now, on to documenting a few more things I’ve done lately, and to start working on the other projects I have added to the queue in the meantime.</p> <section class="footnotes footnotes-end-of-document"> <hr /> <ol> <li id="fn1"><p>small things. Like, you know, a kitchen :D<a class="footnote-back" href="https://blog.trueelena.org#fnref1">↩︎</a></p></li> </ol> </section> </section> </article> Thu, 02 Jul 2026 00:00:00 +0000 https://www.decadent.org.uk/ben/blog/2026/07/01/foss-activity-in-june-2026 https://www.decadent.org.uk/ben/blog/2026/07/01/foss-activity-in-june-2026.html <img src="http://planet.debian.org/heads/benh.png" width="109" height="100" alt="" align="right" style="float: right;"> <p>This month’s work was dominated by the transition of Debian 12 “bookworm” to support by the LTS team, and by review of some large updates to Linux stable branches.</p> <p>Linux 6.12 is currently available in bookworm-backports, but that suite will stop accepting uploads after the last bookworm point release. I updated some supporting packages in bookworm in preparation for adding Linux 6.12 there. I also prepared for the possibility that bookworm-backports would close earlier.</p> <p>Since the LTS team is still also maintaining Debian 11 “bullseye” until August, I reviewed upstream changes for both Linux 5.10 and 6.1 stable branches and reported a number of regressions and other issues.</p> <ul> <li>Debian packages: <ul> <li><a href="https://tracker.debian.org/pkg/firmware-free">firmware-free</a>: <ul> <li>Merge requests: <ul> <li>merged <a href="https://salsa.debian.org/kernel-team/firmware-free/-/merge_requests/11">!11: Apply relevant changes from firmware-nonfree</a></li> </ul> </li> </ul> </li> <li><a href="https://tracker.debian.org/pkg/firmware-nonfree">firmware-nonfree</a>: <ul> <li><a href="https://bugs.debian.org/src:firmware-nonfree">Bugs</a>: <ul> <li>closed <a href="https://bugs.debian.org/1135723">#1135723: firmware-nonfree: gencontrol conflates initramfs-tools with update-initramfs</a></li> <li>closed <a href="https://bugs.debian.org/1135736">#1135736: firmware-nonfree: suggests initramfs-tools, which is being phased out</a></li> <li>closed <a href="https://bugs.debian.org/1137651">#1137651: firmware-misc-nonfree: Please move firmware-intel-graphics and firmware-nvidia-graphics out of Recommends</a></li> <li>replied to <a href="https://bugs.debian.org/1139740">#1139740: firmware-misc-nonfree should recommend firmware-nvidia-graphics to avoid kernel Oops + black screen</a></li> <li>replied to <a href="https://bugs.debian.org/1139746">#1139746: firmware-realtek: W: Possible missing firmware rtlwifi/rtl8723bu_bt.bin for module rtl8xxxu</a></li> </ul> </li> <li>Merge requests: <ul> <li>merged <a href="https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/150">!150: Update and remove obsolete package relations</a></li> </ul> </li> <li><a href="https://tracker.debian.org/pkg/firmware-nonfree/news/">Uploads</a>: <ul> <li>uploaded version 20260519-1 to unstable</li> <li>uploaded version 20260519-1~bpo13+1 to trixie-backports</li> </ul> </li> </ul> </li> <li><a href="https://tracker.debian.org/pkg/kernel-wedge">kernel-wedge</a>: <ul> <li><a href="https://tracker.debian.org/pkg/kernel-wedge/news/">Uploads</a>: <ul> <li>uploaded version 2.106~deb12u1 to bookworm-security</li> </ul> </li> </ul> </li> <li><a href="https://tracker.debian.org/pkg/linux">linux</a>: <ul> <li><a href="https://bugs.debian.org/src:linux">Bugs</a>: <ul> <li>closed <a href="https://bugs.debian.org/1128861">#1128861: linux: when serving NFS, client attempts to lock served files fail with “No locks available”</a></li> <li>replied to <a href="https://bugs.debian.org/1140461">#1140461: spam wave of kernel: tpm tpm0: tpm_try_transmit: send(): error -62</a></li> </ul> </li> <li>Merge requests: <ul> <li>reviewed <a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/1936">!1936: [sparc64] Add nvme module to scsi-modules udeb</a></li> <li>reviewed <a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/1948">!1948: [amd64] Enable Intel Platform Hardware Support Drivers</a></li> <li>merged <a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/1977">!1977: Fix build failure over missing vdso debug files</a></li> <li>merged <a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/1981">!1981: 6.1 backport “bpf: Free reuseport cBPF prog after RCU grace period.”</a></li> <li>opened <a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/1984">!1984: udeb: Ensure that aead and macsec modules are in the right packages</a></li> <li>opened <a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/1985">!1985: Add d/.flake8 config file to support pylsp</a></li> <li>merged <a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/1992">!1992: 6.1 backport: ip6_vti: set netns_immutable on the fallback device. (CVE-2026-52909)</a></li> <li>merged <a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/1993">!1993: 5.10 backport: ip6_vti: set netns_immutable on the fallback device. (CVE-2026-52909)</a></li> <li>merged <a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/1999">!1999: 6.1 backport: Fix CVE-2026-46331</a></li> <li>opened <a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/2004">!2004: [sparc64] udeb: scsi-modules: Use the default module list</a></li> </ul> </li> <li><a href="https://tracker.debian.org/pkg/linux/news/">Uploads</a>: <ul> <li>(LTS) uploaded version 6.12.94-1~bpo12+1 to bookworm-backports</li> <li>uploaded version 7.0.12-2~bpo13+1 to trixie-backports</li> <li>uploaded version 7.1~rc7-1~exp1 to experimental</li> </ul> </li> <li>(LTS) updated the bullseye-security branch to 5.10.259, but did not upload this version</li> <li>(LTS) updated the bookworm-security branch to 6.1.176, but did not upload this version</li> </ul> </li> <li>(LTS) linux-6.12: <ul> <li>prepared this backport package for bookworm-security, but did not upload it yet</li> </ul> </li> <li><a href="https://tracker.debian.org/pkg/linux-base">linux-base</a>: <ul> <li><a href="https://tracker.debian.org/pkg/linux-base/news/">Uploads</a>: <ul> <li>uploaded version 4.12.1~deb12u1 to bookworm-security</li> </ul> </li> </ul> </li> <li><a href="https://tracker.debian.org/pkg/wireless-regdb">wireless-regdb</a>: <ul> <li>Merge requests: <ul> <li>opened and merged <a href="https://salsa.debian.org/kernel-team/wireless-regdb/-/merge_requests/8">!8: Update to 2026.05.30</a></li> </ul> </li> <li><a href="https://tracker.debian.org/pkg/wireless-regdb/news/">Uploads</a>: <ul> <li>uploaded version 2026.05.30-1 to unstable</li> <li>uploaded version 2026.05.30-1~deb12u1 to bookworm</li> <li>uploaded version 2026.05.30-1~deb13u1 to trixie</li> </ul> </li> </ul> </li> </ul> </li> <li>Debian non-package bugs: <ul> <li><a href="https://bugs.debian.org/release.debian.org">release.debian.org</a>: <ul> <li>opened and closed <a href="https://bugs.debian.org/1139579">#1139579: trixie-pu: package wireless-regdb/2026.05.30-1~deb13u1</a></li> <li>opened <a href="https://bugs.debian.org/1139581">#1139581: trixie-pu: package wireless-regdb/2026.05.30-1~deb13u1</a></li> <li>opened <a href="https://bugs.debian.org/1139582">#1139582: bookworm-pu: package wireless-regdb/2026.05.30-1~deb12u1</a></li> </ul> </li> </ul> </li> <li>Mailing lists: <ul> <li><a href="https://lists.debian.org/debian-backports/">debian-backports</a>: <ul> <li>(LTS) posted <a href="https://lists.debian.org/31d77827ecf42782c97cb4b4213197c33a33b0ea.camel@decadent.org.uk">EOL for bookworm-backports</a></li> </ul> </li> <li><a href="https://lists.debian.org/debian-boot/">debian-boot</a>: <ul> <li>(LTS) posted and replied to <a href="https://lists.debian.org/03ecb84264a8b6018633c64d3e4a004dd5e10363.camel@decadent.org.uk">Adding Linux 6.12 udebs for bookworm LTS</a></li> </ul> </li> <li><a href="https://lists.debian.org/debian-devel/">debian-devel</a>: <ul> <li>replied to <a href="https://lists.debian.org/eaf26a4b6ff54f8855c71fe84b077c694486804f.camel@decadent.org.uk">Understanding CI in Salsa, timeouts and runners</a></li> </ul> </li> <li><a href="https://lists.debian.org/debian-kernel/">debian-kernel</a>: <ul> <li>posted <a href="https://lists.debian.org/aca2f071cd39f2c9d75d081c7be2371f98f54f4f.camel@decadent.org.uk">Agenda items for kernel-team meeting on 2026-06-10</a></li> </ul> </li> <li><a href="https://lists.debian.org/debian-lts/">debian-lts</a>: <ul> <li>posted and replied to <a href="https://lists.debian.org/21b31300c29a7ed8c9871bd9e7beb25b2cc79e18.camel@decadent.org.uk">Preparation for Linux 6.12 in bookworm</a></li> </ul> </li> <li><a href="https://lists.debian.org/debian-lts-announce/">debian-lts-announce</a>: <ul> <li>posted <a href="https://lists.debian.org/aivd9n_B7HR1593x@decadent.org.uk">[SECURITY] [DLA 4627-1] kernel-wedge update</a></li> <li>posted <a href="https://lists.debian.org/aiveDYMhYvx0ykIK@decadent.org.uk">[SECURITY] [DLA 4628-1] linux-base update</a></li> </ul> </li> <li>(LTS) <a href="https://lore.kernel.org/stable/">stable</a>: <ul> <li>reviewed &gt;1000 patches included in 5.10.258-rc1, 5.10.259-rc1, and 6.1.176-rc1</li> <li>replied to <a href="https://lore.kernel.org/stable/211fb901ba2c644e6ebdffe46d9face7e317db70.camel@decadent.org.uk/T/">[PATCH 5.10 210/589] spi: rockchip: fix controller deregistration</a></li> <li>replied to <a href="https://lore.kernel.org/stable/7e870e1219db98c9e19777eedfa3b0eb41f41235.camel@decadent.org.uk/T/">[PATCH 5.10 211/589] net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked</a></li> <li>replied to <a href="https://lore.kernel.org/stable/ab577daf17c46a72e35c668756d5b33b3ca3ca09.camel@decadent.org.uk/T/">[PATCH 5.10 238/342] net: bridge: use a stable FDB dst snapshot in RCU readers</a></li> <li>replied to <a href="https://lore.kernel.org/stable/7fee88099501bfa87594114a5f8c17a760ded36a.camel@decadent.org.uk/T/">[PATCH 5.10 244/589] spi: topcliff-pch: fix use-after-free on unbind</a></li> <li>replied to <a href="https://lore.kernel.org/stable/7ccc26ea6552c9fcae1817e2601a96901f0ca261.camel@decadent.org.uk/T/">[PATCH 5.10 245/589] cpuidle: powerpc: avoid double clear when breaking snooze</a></li> <li>replied to <a href="https://lore.kernel.org/stable/8135746e835e432d7b0f21e142389cf8b4979f0f.camel@decadent.org.uk/T/">[PATCH 5.10 257/589] PCI/AER: Stop ruling out unbound devices as error source</a></li> <li>replied to <a href="https://lore.kernel.org/stable/8cd2c0613f018690cba5ae76c4ab73da05118312.camel@decadent.org.uk/T/">[PATCH 5.10 263/589] media: uvcvideo: Enable VB2_DMABUF for metadata stream</a></li> <li>replied to <a href="https://lore.kernel.org/stable/dbb2510d89e3545af204a7bf3eac06512042120e.camel@decadent.org.uk/T/">[PATCH 5.10 267/589] media: rc: streamzap: Error handling in probe</a></li> <li>replied to <a href="https://lore.kernel.org/stable/edea6d36625f362c3fcaed6bd251a02827081a1d.camel@decadent.org.uk/T/">[PATCH 5.10 274/589] drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs()</a></li> <li>replied to <a href="https://lore.kernel.org/stable/2698831f24c7efea34dc4b34d996ff8327ecc206.camel@decadent.org.uk/T/">[PATCH 5.10 503/589] crypto: af_alg - Cap AEAD AD length to 0x80000000</a></li> <li>replied to <a href="https://lore.kernel.org/stable/f0be2ecfe2c27c1920a44b6f41d8db87611267f1.camel@decadent.org.uk/T/">[PATCH 5.10 035/342] batman-adv: tp_meter: fix race condition in send error reporting</a></li> <li>replied to <a href="https://lore.kernel.org/stable/3374d4b14a7c54f82fb016ab66f3b262f55145fe.camel@decadent.org.uk/T/">[PATCH 5.10 036/342] batman-adv: tp_meter: avoid role confusion in tp_list</a></li> <li>replied to <a href="https://lore.kernel.org/stable/72890f3caf368d0e4dcb5d1ec53c083c16ce8b20.camel@decadent.org.uk/T/">[PATCH 5.10 310/342] usb: typec: ucsi: Dont update power_supply on power role change if not connected</a></li> <li>replied to <a href="https://lore.kernel.org/stable/d9c2e8ea23b1919fe663e480cc7def260ed0ee24.camel@debian.org/T/">[PATCH 5.15 002/570] ip6_tunnel: Fix usage of skb_vlan_inet_prepare()</a></li> <li>replied to <a href="https://lore.kernel.org/stable/b6441670bdb04dc530f433bd21d6c64feb633355.camel@decadent.org.uk/T/">[PATCH 5.15 299/411] ALSA: aloop: Fix peer runtime UAF during format-change stop</a></li> <li>replied to <a href="https://lore.kernel.org/stable/66cf4f95534aa5428a362857cf78dcb946c51672.camel@decadent.org.uk/T/">[PATCH 5.15 323/411] spi: topcliff-pch: fix controller deregistration</a></li> <li>replied to <a href="https://lore.kernel.org/stable/9125d5976feb09ef919f2a287b079843c7671325.camel@decadent.org.uk/T/">[PATCH 6.1 011/522] tools/bootconfig: Cleanup bootconfig footer size calculations</a></li> <li>replied to <a href="https://lore.kernel.org/stable/cb2e59a48887f106a57c3fbef66d5a164b8e2f5f.camel@decadent.org.uk/T/">[PATCH 6.1 033/522] net/sched: Revert “net/sched: Restrict conditions for adding duplicating netems to qdisc tree”</a></li> <li>replied to <a href="https://lore.kernel.org/stable/b6b679743c2383b5a367c5d72404b056dfebf080.camel@decadent.org.uk/T/">[PATCH 6.1 054/522] selftests/bpf: add generic BPF program tester-loader</a></li> <li>replied to <a href="https://lore.kernel.org/stable/80be436bbcda9b8a66058c01eef0b0f94722e7ef.camel@decadent.org.uk/T/">[PATCH 6.1 064/522] selftests/bpf: S/iptables/iptables-legacy/ in the bpf_nf and xdp_synproxy test</a></li> <li>replied to <a href="https://lore.kernel.org/stable/6f805abf1f8b058c1b1241e8568d7539185145df.camel@decadent.org.uk/T/">[PATCH 6.1 208/522] net: Annotate sk-&gt;sk_write_space() for UDP SOCKMAP.</a></li> <li>replied to <a href="https://lore.kernel.org/stable/afe207eb91522718cfae8b77310999ca397c81bf.camel@decadent.org.uk/T/">[PATCH 6.1 249/522] r8152: Block future register access if register access fails</a></li> <li>replied to <a href="https://lore.kernel.org/stable/b0d5836032ce3135bfc473f6bff791306d086925.camel@decadent.org.uk/T/">[PATCH 6.1 337/522] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()</a></li> <li>replied to <a href="https://lore.kernel.org/stable/42c2abbdfdd4ea8e234fbcfc4b37095ebd2c7b36.camel@decadent.org.uk/T/">[PATCH 6.1 342/522] thermal: core: Fix thermal zone governor cleanup issues</a></li> <li>replied to <a href="https://lore.kernel.org/stable/6218e66138c5c1c5fb02bd653c8b91d6ff8c3abd.camel@decadent.org.uk/T/">[PATCH 6.1 375/522] net: ipv4: stop checking crypto_ahash_alignmask</a></li> <li>replied to <a href="https://lore.kernel.org/stable/0e31e18e9567e8d58fbb8e06955c3ed8e5a120d3.camel@decadent.org.uk/T/">[PATCH 6.1 431/522] cgroup/cpuset: Reset DL migration state on can_attach() failure</a></li> <li>replied to <a href="https://lore.kernel.org/stable/2ac6b67a0643e111692689daa95dbd8883f16426.camel@decadent.org.uk/T/">[PATCH 6.1 470/522] usb: musb: omap2430: Fix use-after-free in omap2430_probe()</a></li> </ul> </li> </ul> </li> </ul> Wed, 01 Jul 2026 10:39:27 +0000 http://dirk.eddelbuettel.com/blog/2026/06/30#tl_0.0.2 http://dirk.eddelbuettel.com/blog/2026/06/30#tl_0.0.2 <img src="http://planet.debian.org/heads/dirk.png" width="65" height="90" alt="" align="right" style="float: right;"> <p>The still-very-new logging package <a href="https://github.com/eddelbuettel/tl">tl</a> was just updated for the first time at <a href="https://cran.r-project.org">CRAN</a>. The <a href="https://github.com/eddelbuettel/tl">tl</a> package wraps the (also very new) <a href="https://github.com/eddelbuettel/rspdlite">rspdlite</a> package to offer a lightweight and consistent logging interface from both R and C++ that enjoys being ‘tiny, fast, capable’ thanks to <a href="https://github.com/gabime/spdlite">spdlite</a>. With <a href="https://github.com/eddelbuettel/tl">tl</a> we follow the same idea that our <a href="https://github.com/eddelbuettel/spdl">spdl</a> package introduced: a simple consistent interface via just the <code>tl::</code> prefix and the appropropriate logging level. In other words <code>tl::debug("Alert: foo now '{}'", foo)</code> will work from both R and C++ (given a variable <code>foo</code>, and, in the case of C++, an extra semicolon) and log if the current level is ‘debug’ or higher, and skip logging if not.</p> <p>This release adds a fallback when compilation does not use the (required) C++20 standard, expands the README and adds a initialization helper function reflecting a preferred default logging level from either an environment variable or a global option. We are also working on adding <a href="https://github.com/eddelbuettel/tl">tl</a> to an example package as a simple illustration, more on that hopefully soon.</p> <p>The NEWS entry for this release follows.</p> <blockquote> <h4 id="changes-in-version-0.0.2-2025-06-30">Changes in version 0.0.2 (2025-06-30)</h4> <ul> <li><p>Added badges to README now that package is on CRAN, add NEWS file</p></li> <li><p>Condition the provided header on C++20 use, offer fallback</p></li> <li><p>Add an exported initialization function picking up a logging level from either an environment variable or a global option, see '?init'</p></li> </ul> </blockquote> <p>Courtesy of my <a href="https://dirk.eddelbuettel.com/cranberries/">CRANberries</a>, there is also a <a href="https://dirk.eddelbuettel.com/cranberries/2026/06/30/#tl_0.0.2">diffstat report</a> for the this release.</p> <p style="font-size: 80%; font-style: italic;"> This post by <a href="https://dirk.eddelbuettel.com">Dirk Eddelbuettel</a> originated on his <a href="https://dirk.eddelbuettel.com/blog/">Thinking inside the box</a> blog. If you like this or other open-source work I do, you can <a href="https://github.com/sponsors/eddelbuettel">sponsor me at GitHub</a>. </p><p></p> Tue, 30 Jun 2026 17:02:00 +0000 http://joeyh.name/blog/entry/big_loads_offgrid_with_a_small_battery_sidelined/ http://joeyh.name/blog/entry/big_loads_offgrid_with_a_small_battery_sidelined/ <img src="http://planet.debian.org/heads/joeyh2.png" width="84" height="75" alt="" align="right" style="float: right;"> <p>No matter that the hype cycle wants you to think, the renewable energy transition is the biggest thing happening in tech and it's happening faster and faster. Despite being neck deep in it personally with offgrid solar projects, most recently solar hot water, increasingly it becomes clear I'm watching from the sidelines.</p> <p>In Australia, <a href="https://lenergy.com.au/free-daytime-electricity-is-coming-heres-how-it-actually-works/">everyone gets 24 kwh of free daytime electric power now</a>. That's without installing any solar panels of their own, the grid just has that much excess capacity. All it takes to save $thousands per year (and avoid emissions) is to schedule some big loads like the hot water heater and EV to charge during the day. To save more, drop in a home battery that charges for free and powers the home through the evening.</p> <p>In Germany, a 2 kwh plug-in home battery costs $350 and the electric company will <a href="https://octopusenergy.de/smarte-geraete/heimspeicher-powerbank">pay you</a> $130 per year to plug it into your wall. There are similar offers throughout Europe.</p> <p>In Cuba something something geopolitics, oil blockade, belt and road =&gt; suddenly 1GW of solar farms with another gigawatt on the way.</p> <p>I'll soon visit South Carolina where with no subsidies whatsoever from a decidedly renewable-unfriendly government, it made sense for my dad's house to get a whole home battery and double the solar array. The resulting system will be able to power the well pump and probably also the whole geothermal HVAC system through the kind of month-long grid down events that happened in Hurricane Helene.</p> <p>Myself, well, I've got a by modern standards small 4 kwh home battery that powers my house offgrid, and I've recently installed a heat pump hot water heater. That's after about a decade pondering what solution to use for solar hot water, to replace an aging and horrible propane instant water heater. I've in the past considered everything from evacuated tubes to special direct drive inverters to DC resistive MPTT dump loads. The solution turned out to be just a big enough solar array, and plugging in a 120v hot water heater that needs only 500 watts in heat pump mode. Plus a small amount of code to manage when it runs.</p> <p>In the time I was thinking about that, economies of scale and tech improvements just wiped all those other possibilities off the map, it's not economical to install and maintain a separate evactuated tube heat collector when a pile of solar panels costs so little and when electric hot water has gotten more than 200% efficient.</p> <p>I also recently completed my permanant EV charger installation, with a new inverter and conduit and proper wiring, and increased the car's charge rate to 2 kw. Eliminating the need to charge anywhere except at home except on road trips.</p> <p>Coordinating when these two big loads run, to maximize solar production and ensure that the house battery is full at the end of the day was ... not hard at all actually? The car charger amps can be dialed up and down to match incoming solar power fairly well, and leave some room for the hot water heater. They both operate as more or less dump loads. More or less because neither one can be cycled on or off very fast (to avoid wear and tear on the car's contactor and the heat pump's compressor), so it makes sense to leave them on and skate through short cloudy sections of the day, as long as the house battery doesn't get too low.</p> <p>How low is too low for the house battery? Depends on the time of day. The code it's currently using, which may get tweaked over winter:</p> <div class="highlight-haskell"><pre class="hl"> <span class="hl slc">-- When the battery is charged enough to run major loads that may prevent</span> <span class="hl slc">-- charging it further.</span> <span class="hl slc">--</span> <span class="hl slc">-- This varies with the hour of day. Early in the day, the battery does not</span> <span class="hl slc">-- need to be as full to be considered well charged, since there is</span> <span class="hl slc">-- still plenty of time for it to charge up. Later in the day, with less</span> <span class="hl slc">-- time to charge, it needs to be more full.</span> wellCharged :: Hour <span class="hl opt">-&gt;</span> Percentage wellCharged <span class="hl kwc">(</span>Hour hour<span class="hl kwc">)</span> <span class="hl opt">|</span> hour <span class="hl opt">&lt;</span> <span class="hl num">9</span> <span class="hl opt">=</span> Percentage <span class="hl num">90</span> <span class="hl slc">-- night</span> <span class="hl opt">|</span> pmhour <span class="hl opt">&lt;=</span> <span class="hl num">0</span> <span class="hl opt">=</span> Percentage <span class="hl num">50</span> <span class="hl opt">|</span> pmhour <span class="hl opt">&lt;=</span> <span class="hl num">1</span> <span class="hl opt">=</span> Percentage <span class="hl num">60</span> <span class="hl opt">|</span> pmhour <span class="hl opt">&lt;=</span> <span class="hl num">2</span> <span class="hl opt">=</span> Percentage <span class="hl num">70</span> <span class="hl opt">|</span> pmhour <span class="hl opt">&lt;=</span> <span class="hl num">3</span> <span class="hl opt">=</span> Percentage <span class="hl num">80</span> <span class="hl opt">|</span> pmhour <span class="hl opt">&lt;=</span> <span class="hl num">4</span> <span class="hl opt">=</span> Percentage <span class="hl num">90</span> <span class="hl opt">|</span> otherwise <span class="hl opt">=</span> Percentage <span class="hl num">95</span> <span class="hl kwb">where</span> pmhour <span class="hl opt">=</span> hour <span class="hl opt">-</span> <span class="hl num">12</span> </pre></div> <p>More complicated is, what to do it there's solar power to run one or the other, but not both? This is starting to get into the territory of microgrids now, or of demand response programs, so there's a whole industry or three out there doing industry things geared at the kind of no-brainer solutions I mentioned earlier. From what I've gathered, all of them involve proprietary protocols and gear.</p> <p>What I've done is to read the state of the hot water heater and car, and prioritize hot water over the car. Except, if the car is below 10% it urgently needs to charge.</p> <p>And I found a really simple way to decide when to run the low-priority load: Just check if the house battery's current charge will be considered <code>wellCharged</code> in an hour. So if it's 2 pm, the battery needs to be 80% charged to run the lower-priority load, and if it dips below that, that load will turn off but the high-priority load will keep running down to 70% battery.</p> <p>Unfortunately, getting any information out of my hot water heater relies on a vendor API server that is often down on weekends, and reverse engineered the web page of my EVSE[1] to control it, to say nothing of the nightmare of getting the car's state of charge from The Cloud.</p> <p>Anyway, I'm pleased with having easily tweakable code and how far I've taken this offgrid, and everything I've learned doing so, but like I said, I'm clearly observing from the sidelines over here while the most significant thing for all of us is going on over there. You might appreciate my code or method, but you'll eventually be plugging in a home battery or signing up for a free daytime power tarrif from your electric company, or having professionals install a whole home system for climate resiliance.</p> <p>So my question is, where does free software fit into all this? There are things like Home Assistant that do productize the kind of thing I'm doing enough to be useful more widely. But still niche. Meanwhile there are inverters and batteries that phone home to China, and every consumer facing install is either "use this device" or "integrate these 3 proprietary devices".</p> <p>I don't think focusing on these negatives is really useful though, I'm more trying to understand where all this is going and then maybe get out ahead of it in some useful way with free software. Your thoughts welcome.</p> <hr /> <p>[1] Obviously OpenEVSE exists, but it didn't meet my needs hardware wise. And I could set my EVSE to use an OCPP server but it was easier to do the screen scraping than find an appropriate one, and I have the feeling I would not appreciate learning any more about OCPP, in the same way I really don't want to know a lot about web browsers' tag soup mode.</p> Tue, 30 Jun 2026 16:10:45 +0000 https://etbe.coker.com.au/?p=6226 https://etbe.coker.com.au/2026/06/30/links-june-2026/ <p><a href="https://www.schneier.com/blog/archives/2026/06/critical-zcash-vulnerability-found-and-fixed.html">This is amusing, a flaw in the crypto-currency Zcash allowed generating Zcash from nothing and there’s no way to know if anyone did that [1]</a>.</p> <p><a href="https://locusmag.com/feature/commentary-cory-doctorow-the-age-of-vapor/">Cory Doctorow wrote an insightful article for Locus Magazine about corporate valuations and why companies claim SciFi technologies [2]</a>.</p> <p><a href="http://www.antipope.org/charlie/blog-static/2026/06/rule-by-bond-villains.html">Charles Stross wrote an interesting retcon of James Bond [3]</a>.</p> <p><a href="https://trakkr.ai/bias">Trakkr.ai has an intresting post comparing political bias in LLM models, the site has lots of other comparisons of models too [4]</a>.</p> <p><a href="https://grep.be/blog//en/computer/Agentic_coding_and_Free_Software/">Wouter Verhelst wrote a blog post about his tested usage of LLMs for code generation and the conclusions about what it will do to the FOSS development process, not a lot of new material but he put a lot of good ideas together in one place [5]</a>.</p> <p><a href="https://github.com/jtesta/ssh-audit">Here is the git repository for the programs used for the ssh-audit.com site, really good setup for checking ssh configuration [6]</a>.</p> <p><a href="https://isaiprofitable.com/">The isaiprofitable.com site is periodically updated with the profit/loss totals for AI companies, no surprise that every company is losing money apart from NVidia and NVidia are investing in the other companies [7]</a>.</p> <p><a href="https://freedium-mirror.cfd/https://medium.com/@elvirabary/why-russia-cant-build-anything-anymore-inside-putin-s-failed-tech-e63e27ee40b0">Elvira Bary wrote an informative article about Russia’s inability to build or design anything good [8]</a>. Looks like we are at risk of another Chernobyl…</p> <p><a href="http://levlafayette.com/node/808">Lev Lafayette wrote an interesting blog post about the Sunway TaihuLight supercomputer with over 10,000,000 cores [9]</a>.</p> <p><a href="https://point.free/blog/gemma-4-on-a-2016-xeon/">Point Free wrote an interesting blog post about running the Gemma 4 LLM which is 25G of data at a usable speed on a Xeon system with DDR3 RAM and no GPU [10]</a>.</p> <ul> <li>[1]<a href="https://www.schneier.com/blog/archives/2026/06/critical-zcash-vulnerability-found-and-fixed.html"> https://tinyurl.com/2cxx2e6h</a></li> <li>[2]<a href="https://locusmag.com/feature/commentary-cory-doctorow-the-age-of-vapor/"> https://tinyurl.com/2cxotle7</a></li> <li>[3]<a href="http://www.antipope.org/charlie/blog-static/2026/06/rule-by-bond-villains.html"> https://tinyurl.com/2bgapt88</a></li> <li>[4]<a href="https://trakkr.ai/bias"> https://trakkr.ai/bias</a></li> <li>[5]<a href="https://grep.be/blog//en/computer/Agentic_coding_and_Free_Software/"> https://tinyurl.com/22s2fome</a></li> <li>[6]<a href="https://github.com/jtesta/ssh-audit"> https://github.com/jtesta/ssh-audit</a></li> <li>[7]<a href="https://isaiprofitable.com/"> https://isaiprofitable.com/</a></li> <li>[8]<a href="https://freedium-mirror.cfd/https://medium.com/@elvirabary/why-russia-cant-build-anything-anymore-inside-putin-s-failed-tech-e63e27ee40b0"> https://tinyurl.com/26p4lkr4</a></li> <li>[9]<a href="http://levlafayette.com/node/808"> http://levlafayette.com/node/808</a></li> <li>[10]<a href="https://point.free/blog/gemma-4-on-a-2016-xeon/"> https://point.free/blog/gemma-4-on-a-2016-xeon/</a></li> </ul> <div class="yarpp yarpp-related yarpp-related-rss yarpp-template-list"> <p>Related posts:</p><ol> <li><a href="https://etbe.coker.com.au/2022/06/30/links-june-2022/" rel="bookmark" title="Links June 2022">Links June 2022</a> <small>Google did some interesting research on the impact of discrimination...</small></li> <li><a href="https://etbe.coker.com.au/2026/04/30/links-april-2026/" rel="bookmark" title="Links April 2026">Links April 2026</a> <small>Charles Stross wrote an interesting blog post about the apparent...</small></li> <li><a href="https://etbe.coker.com.au/2026/02/17/links-february-2026/" rel="bookmark" title="Links February 2026">Links February 2026</a> <small>Charles Stross has a good theory of why “AI” is...</small></li> </ol> </div> Tue, 30 Jun 2026 13:53:19 +0000 https://etbe.coker.com.au/?p=6220 https://etbe.coker.com.au/2026/06/30/dirtyclone-selinux/ <p>There is a <a href="https://research.jfrog.com/post/dissecting-and-exploiting-linux-lpe-variant-dirtyclone-cve-2026-43503/">new Linux kernel exploit out named Dirty Clone [1]</a>.</p> <p>The first thing to do to exploit this is to create a container with a separate network namespace via one of the following commands:</p> <pre>unshare -Urn bwrap --bind / / --unshare-user --unshare-net --uid 0 --gid 0 /bin/bash</pre> <p>The Jfrog people recommend “unshare -Urn” but I gave the Bubblewrap command as an option as it should work equally well and in some situations may be permitted when unshare isn’t.</p> <p>The next step to exploiting it is to use the ip command to set the links up, below is what happens in a user session on a SE Linux system with user_t as the login domain:</p> <pre># ip link set lo up RTNETLINK answers: Operation not permitted</pre> <p>That will give an entry in /var/log/audit/audit.log like the following:</p> <pre>type=AVC msg=audit(1782818856.618:3610): avc: denied { net_admin } for pid=1829 comm="ip" capability=12 scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=cap_userns permissive=0 type=SYSCALL msg=audit(1782818856.618:3610): arch=c000003e syscall=46 success=yes exit=32 a0=3 a1=7ffebe5f9e50 a2=0 a3=0 items=0 ppid=1638 pid=1829 auid=0 uid=0 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=17 comm="ip" exe="/usr/bin/ip" subj=user_u:user_r:user_t:s0 key=(null)ARCH=x86_64 SYSCALL=sendmsg AUID="root" UID="root" GID="test" EUID="root" SUID="root" FSUID="root" EGID="test" SGID="test" FSGID="test" type=PROCTITLE msg=audit(1782818856.618:3610): proctitle=6970006C696E6B00736574006C6F007570</pre> <p>Unlike previous exploits like <a href="https://etbe.coker.com.au/2026/05/24/debian-selinux-pintheft/">Pintheft [2]</a> this doesn’t require any really uncommon access to the kernel (unless you consider setting up IPSec to be really uncommon) and is allowed in many container setups.</p> <p>Now on a system with the unconfined module removed (as described in the <a href="https://etbe.coker.com.au/2026/05/04/copy-fail-on-debian-and-se-linux/#SE_Linux_Protection">SE Linux Protection part of my post about Copy Fail [3]</a>) the following domains have such access:</p> <pre># sesearch -A -c cap_userns -p net_admin allow container_engine_t container_engine_t:cap_userns { audit_write chown dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill lease linux_immutable mknod net_admin net_bind_service net_raw setfcap setgid setpcap setuid sys_admin sys_boot sys_chroot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; allow container_init_t container_init_t:cap_userns { chown dac_override dac_read_search fowner kill net_admin net_bind_service net_raw setgid setuid }; allow container_kvm_t container_kvm_t:cap_userns { chown dac_override dac_read_search fowner kill net_admin net_bind_service net_raw setgid setuid }; allow container_t container_t:cap_userns { chown dac_override dac_read_search fowner kill net_admin net_bind_service net_raw setgid setuid }; allow crio_t crio_t:cap_userns { audit_write chown dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill lease linux_immutable mknod net_admin net_bind_service net_raw setfcap setgid setpcap setuid sys_admin sys_boot sys_chroot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; allow dockerd_t dockerd_t:cap_userns { audit_write chown dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill lease linux_immutable mknod net_admin net_bind_service net_raw setfcap setgid setpcap setuid sys_admin sys_boot sys_chroot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; allow dockerd_user_t dockerd_user_t:cap_userns { audit_write chown dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill lease linux_immutable mknod net_admin net_bind_service net_raw setfcap setgid setpcap setuid sys_admin sys_boot sys_chroot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; allow init_t init_t:cap_userns { audit_write chown dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill lease linux_immutable mknod net_admin net_bind_service net_raw setfcap setgid setpcap setuid sys_admin sys_boot sys_chroot sys_module sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; allow iptables_t iptables_t:cap_userns { net_admin net_raw }; allow podman_t podman_t:cap_userns { audit_write chown dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill lease linux_immutable mknod net_admin net_bind_service net_raw setfcap setgid setpcap setuid sys_admin sys_boot sys_chroot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; allow podman_user_t podman_user_t:cap_userns { audit_write chown dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill lease linux_immutable mknod net_admin net_bind_service net_raw setfcap setgid setpcap setuid sys_admin sys_boot sys_chroot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; allow spc_t spc_t:cap_userns { audit_write chown dac_override dac_read_search fowner fsetid ipc_lock kill mknod net_admin net_bind_service net_raw setgid setpcap setuid sys_admin sys_chroot sys_nice sys_ptrace sys_rawio sys_resource }; allow spc_user_t spc_user_t:cap_userns { chown dac_override dac_read_search fowner kill net_admin net_bind_service net_raw setgid setuid }; allow staff_bubblewrap_t staff_bubblewrap_t:cap_userns { dac_override net_admin setpcap sys_admin sys_ptrace }; allow sysadm_bubblewrap_t sysadm_bubblewrap_t:cap_userns { dac_override net_admin setpcap sys_admin sys_ptrace }; allow user_bubblewrap_t user_bubblewrap_t:cap_userns { dac_override net_admin setpcap sys_admin sys_ptrace };</pre> <h2>Conclusion</h2> <p>It seems that SE Linux configured in the strict mode prevents this exploit in the most obvious use case. But with the range of container related domains that are granted such access it seems quite likely that some configurations and use cases will permit it.</p> <p>Overall the protection that the standard policy for SE Linux can offer (in a non-default configuration) against net_admin access isn’t bad, but isn’t very good either.</p> <p>I think this will be the first of many exploits based on cap_userns access and that we need to do some work in tightening the SE Linux access controls on such things. One possible way of doing this is to have a program run inside a container in a domain that has permissions such as net_admin to setup the container and not allow domain transitions from the regular programs run in the container (the actual work) to the domain used for network setup.</p> <p>The increasing use of containers by applications is only going to make this problem worse. I think that what we need is something like <a href="https://en.wikipedia.org/wiki/Flatpak">Flatpak</a> for the vast majority of desktop/phone applications with a container setup program that works with apps packaged in the distribution packaging method (not from Flathub). This is something I’m going to investigate for future blog posts.</p> <ul> <li>[1]<a href="https://research.jfrog.com/post/dissecting-and-exploiting-linux-lpe-variant-dirtyclone-cve-2026-43503/"> https://tinyurl.com/26q48bg4</a></li> <li>[2]<a href="https://etbe.coker.com.au/2026/05/24/debian-selinux-pintheft/"> https://etbe.coker.com.au/2026/05/24/debian-selinux-pintheft/</a></li> <li>[3]<a href="https://etbe.coker.com.au/2026/05/04/copy-fail-on-debian-and-se-linux/#SE_Linux_Protection"> https://etbe.coker.com.au/2026/05/04/copy-fail-on-debian-and-se-linux/</a></li> </ul> <div class="yarpp yarpp-related yarpp-related-rss yarpp-template-list"> <p>Related posts:</p><ol> <li><a href="https://etbe.coker.com.au/2024/07/21/selinux-dell-mgmt/" rel="bookmark" title="SE Linux Policy for Dell Management">SE Linux Policy for Dell Management</a> <small>The recent issue of Windows security software killing computers has...</small></li> <li><a href="https://etbe.coker.com.au/2024/10/26/cups-vulnerability/" rel="bookmark" title="The CUPS Vulnerability">The CUPS Vulnerability</a> <small>The Announcement Late last month there was an announcement of...</small></li> <li><a href="https://etbe.coker.com.au/2026/05/08/dirty-frag-on-debian-and-se-linux/" rel="bookmark" title="Dirty Frag on Debian and SE Linux">Dirty Frag on Debian and SE Linux</a> <small>Hot on the heels of the Copy Fail vulnerability [1]...</small></li> </ol> </div> Tue, 30 Jun 2026 12:04:25 +0000 https://utkarsh2102.org/posts/foss-in-june-26/ https://utkarsh2102.org/posts/foss-in-june-26/ <p>Here’s my monthly but brief update about the activities I’ve done in the FOSS world.</p> <h2 id="debian">Debian</h2> <figure> <img src="https://utkarsh2102.org/images/debian-logo-small.png" /> </figure> <p>Whilst I didn’t get a chance to do much, here are still a few things that I worked on:</p> <ul> <li>Leading the DebConf Bursary team along with PEB. <ul> <li>This took most of my Debian time this month but we’ve been able to wrap that work now.</li> <li>Got back to all the tickets on Zammad, too.</li> </ul> </li> <li>Assisted a few folks in getting their patches submitted via Salsa.</li> <li>Mentoring for newcomers.</li> <li>Moderation of -project mailing list.</li> </ul> <hr /> <h2 id="ubuntu">Ubuntu</h2> <figure> <img src="https://utkarsh2102.org/images/ubuntu-logo-small.png" /> </figure> <p>I joined <a href="https://utkarsh2102.org/posts/hello-canonical/">Canonical to work on Ubuntu full-time</a> back in February 2021.</p> <p>Whilst I can’t give a full, detailed list of things I did, here’s a quick TL;DR of what I did:</p> <ul> <li>Continued to push for infrastructure improvements: <ul> <li>Charming.</li> <li>Artifact signing.</li> <li>Reorganizing cdimage.</li> <li>And so on.</li> </ul> </li> <li>Successfully released <a href="https://discourse.ubuntu.com/t/stonking-snapshot-2-released/84537">26.10 Snapshot 2</a>! <ul> <li>We landed a breaking change in the directory structure.</li> <li>…whihc had consequences on the rsync, being run by the sysadmins. <ul> <li>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. :)</li> <li>We got it back under control in the next few days but oh wow, what a journey to get there.</li> </ul> </li> </ul> </li> <li>Assisted a bunch of folks with my Archive Admin and Release team hats to: <ul> <li>Helped in archive opening tasks.</li> <li>Promoting/demoting binaries to/from main.</li> <li>Taking care of package removals and so on.</li> <li>Reviewed the NEW queue.</li> </ul> </li> <li>Reviewed quite a lot of MPs, specs, and other people’s work.</li> <li>Mentoring, coaching, and leading the Release Management team.</li> </ul> <hr /> <h2 id="debian-elts">Debian (E)LTS</h2> <figure> <img src="https://utkarsh2102.org/images/debian-lts-small.png" /> </figure> <p>This month I have worked 15 hours on <a href="https://www.freexian.com/lts/debian/">Debian Long Term Support (LTS)</a> and on its sister <a href="https://www.freexian.com/lts/extended/">Extended LTS</a> project and did the following things:</p> <h3 id="released-security-updates">Released Security Updates</h3> <ul> <li> <p><strong>node-lodash</strong>: Prototype pollution and code injection during template compilation.</p> <ul> <li><strong>[LTS]</strong>: Fixed <a href="https://security-tracker.debian.org/tracker/CVE-2025-13465">CVE-2025-13465</a>, <a href="https://security-tracker.debian.org/tracker/CVE-2026-2950">CVE-2026-2950</a>, and <a href="https://security-tracker.debian.org/tracker/CVE-2026-4800">CVE-2026-4800</a> via <a href="https://tracker.debian.org/news/1770027/accepted-node-lodash-41721dfsgcs831173-1deb11u1-source-into-oldoldstable-security/"><strong>4.17.21+dfsg+~cs8.31.173-1+deb11u1</strong></a> for bullseye. This has been released as <a href="https://www.debian.org/lts/security/2026/DLA-4663-1"><strong>DLA 4663-1</strong></a>.</li> <li><strong>[trixie]</strong>: Filed the proposed-update (<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141450">#1141450</a>) and uploaded the fix.</li> <li><strong>[bookworm]</strong>: Filed the proposed-update (<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141449">#1141449</a>) but it was closed; will release the DLA next month (in July).</li> </ul> </li> <li> <p><strong>openvpn</strong>: Multiple vulnerabilities leading to Denial of Service.</p> <ul> <li><strong>[LTS]</strong>: Fixed <a href="https://security-tracker.debian.org/tracker/CVE-2026-11771">CVE-2026-11771</a>, <a href="https://security-tracker.debian.org/tracker/CVE-2026-12932">CVE-2026-12932</a>, <a href="https://security-tracker.debian.org/tracker/CVE-2026-12996">CVE-2026-12996</a>, <a href="https://security-tracker.debian.org/tracker/CVE-2026-13117">CVE-2026-13117</a>, <a href="https://security-tracker.debian.org/tracker/CVE-2026-13122">CVE-2026-13122</a>, and <a href="https://security-tracker.debian.org/tracker/CVE-2026-13698">CVE-2026-13698</a> via <strong>2.6.14-0+deb12u2</strong> for bookworm. This has been released as <a href="https://www.debian.org/lts/security/2026/DLA-4666-1"><strong>DLA 4666-1</strong></a>. The update itself was prepared by the maintainer; I helped prepare the paperwork.</li> </ul> </li> </ul> <h3 id="work-in-progress">Work in Progress</h3> <ul> <li><strong>php-phpseclib</strong>: Affected by <a href="https://security-tracker.debian.org/tracker/CVE-2023-52892">CVE-2023-52892</a> and <a href="https://security-tracker.debian.org/tracker/CVE-2026-32935">CVE-2026-32935</a>. <ul> <li><strong>[LTS]</strong>: Continued to work on this and it should be released soon. Uploaded the work to debusine: <a href="https://debusine.debian.net/debian/developers/work-request/906743/">https://debusine.debian.net/debian/developers/work-request/906743/</a>. Will release the DLA in July.</li> </ul> </li> </ul> <h3 id="other-activities">Other Activities</h3> <ul> <li> <p><strong>[LTS]</strong> Emilio pointed out that the gst-plugins-ugly1.0 binaries were still not fully released, so I ran <code>dcut migrate</code> to fully release them. The DLA had gone out earlier.</p> </li> <li> <p><strong>[ELTS]</strong> 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 <code>ela-needed</code> list.</p> </li> <li> <p><strong>[E/LTS]</strong> Set up the security-tracker and a few other things on the new machine, and debugged the git repository size madness. Sent a summary <a href="https://lists.debian.org/debian-lts/2026/07/msg00013.html">here</a>.</p> </li> <li> <p><strong>[E/LTS]</strong> Monitored discussions on mailing lists, IRC, and all the documentation updates.</p> </li> <li> <p><strong>[E/LTS]</strong> Attended the monthly LTS meeting on Jitsi. <a href="https://lists.debian.org/debian-lts/2026/06/msg00045.html">Meeting notes here</a>.</p> </li> </ul> <hr /> <p>Until next time.<br /> <code>:wq</code> for today.</p> Tue, 30 Jun 2026 05:41:11 +0000 https://diffoscope.org/news/diffoscope-323-released/ https://diffoscope.org/news/diffoscope-323-released/ <p>The diffoscope maintainers are pleased to announce the release of diffoscope version <code class="language-plaintext highlighter-rouge">323</code>. This version includes the following changes:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>[ Chris Lamb ] * Debian adds an extra "Flags:" line in the output of ocamlobjinfo via a patch, so adjust how we test OCaml to ensure cross-distribution compatibility. (Closes: reproducible-builds/diffoscope#430) * Update copyright years. [ Michael Daniels ] * Fix tests when using zipdetails version &gt;= 4.006. </code></pre></div></div> <p>You find out more by <a href="https://diffoscope.org">visiting the project homepage</a>.</p> Tue, 30 Jun 2026 00:00:00 +0000 https://blog.daniel-baumann.ch/posts/20260626-1.html https://blog.daniel-baumann.ch/posts/20260626-1.html <section id="debian-linux-vulnerability-mitigation-packet-edit-meme-c"> <p>The Linux local root exploit of today’s news is <a class="reference external" href="https://github.com/sgkdev/packet_edit_meme">PACKET_EDIT_MEME.c</a> [<a class="reference external" href="https://nvd.nist.gov/vuln/detail/CVE-2026-46331">CVE-2026-46331</a>] which is also known as pedit COW.</p> <p>This vulnerability has been fixed as of linux <a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=899ee91156e57784090c5565e4f31bd7dbffbc5a">7.1~rc7</a>, but also fixed in trixies 6.12.94-1 as well as testing/unstable 7.0.13-1. If you run an older or different kernel you might want to mitigate the vulnerability until you can update and reboot affected systems.</p> <p>The vulnerability can be mitigated by unloading and blocking the <code class="docutils literal notranslate"><span class="pre">act_pedit</span></code> module, <a class="reference external" href="https://tracker.debian.org/pkg/linux-vulnerability-mitigation">linux-vulnerability-mitigation</a> as of <a class="reference external" href="https://git.open-infrastructure.net/tools/linux-vulnerability-mitigation/commit/e0999668ba2c1affa1752a2e91c5b56e64249f85">20260629-1</a> (uploaded to sid, <a class="reference external" href="https://fastforward.debian.net">trixie-fastforward-backports</a> and <a class="reference external" href="https://people.debian.org/~daniel/linux-vulnerability-mitigation">people.debian.org/~daniel</a>) does that automatically for you.</p> </section> Mon, 29 Jun 2026 13:42:49 +0000 https://etbe.coker.com.au/?p=6214 https://etbe.coker.com.au/2026/06/28/plaud/ <p>While watching a YouTube video I saw an advert for the <a href="https://www.plaud.ai/">Plaud AI Note Taker [1]</a>. The Plaud device looks pretty good for what it does, taking notes and managing them, using some sort of LLM function to manage the notes. The devices all cost about $300 which is an amount that doesn’t seem unreasonable for someone who’s in a lot of meetings. One of the models is the “NotePin” that seems comparable to the <a href="https://etbe.coker.com.au/2024/04/26/humane-ai-pin/">Humane AI Pin I previously blogged about [2]</a>.</p> <p>The business model for Plaud is based on only allowing 5 hours per month of free transcriptions, then charging $16.25/month for 20 hours per month and $33.33/month for unlimited use. That’s quite expensive for any serious use.</p> <p>The number of people in the market for an audio recording system that automatically transcribes things may be greater than the number of people in the market for all the stuff that the Humane AI Pin did, but it still may not be enough to run a profitable business when competing with apps on mobile phones.</p> <p>While the product does look decent it seems that they are making the same mistakes as the original Humane developers did, of wanting to lock it down as a subscription based service which reduces the usability of the device. If they had sold an Android hand-held computer with their own app pre-loaded and allowed the user to install a different app then it would have been much more usable. If they had sold Android devices designed for the note taking market and allowed people to choose their own apps to install then their products would have a much longer life expectancy.</p> <p>The majority of Android devices in use are probably out of support but still working while the Humane AI pin can’t be used any more and at some time in the not too distant future the Plaud devices will also become unusable. People who buy devices like the Plaud seem to be unaware of the history of such things and the expected future for them. But possibly some people just consider $300 for a year of use to be an acceptable price. If someone wanted to purchase a new high end phone every year and sell their previous one they would probably have a net cost of about $500/year.</p> <p>Maybe I should look for work with a company with an implausible AI based business plan. It would be fun developing such a device if you weren’t emotionally invested in the project. Just develop new technology, earn a heap of money, play with fun computers, and move on to the next thing when it collapses. Just like all the Internet companies about 25 years ago.</p> <ul> <li>[1]<a href="https://www.plaud.ai/"> https://www.plaud.ai/</a></li> <li>[2]<a href="https://etbe.coker.com.au/2024/04/26/humane-ai-pin/"> https://etbe.coker.com.au/2024/04/26/humane-ai-pin/</a></li> </ul> <div class="yarpp yarpp-related yarpp-related-rss yarpp-template-list"> <p>Related posts:</p><ol> <li><a href="https://etbe.coker.com.au/2010/11/17/mobile-phone-sysadmin/" rel="bookmark" title="A Mobile Phone for Sysadmin Use">A Mobile Phone for Sysadmin Use</a> <small>My telco Three have just offered me a deal on...</small></li> <li><a href="https://etbe.coker.com.au/2013/02/22/iphone-vs-android/" rel="bookmark" title="iPhone vs Android">iPhone vs Android</a> <small>A friend who’s a long-time iPhone user just asked for...</small></li> <li><a href="https://etbe.coker.com.au/2016/06/01/i-just-ordered-a-nexus-6p/" rel="bookmark" title="I Just Ordered a Nexus 6P">I Just Ordered a Nexus 6P</a> <small>Last year I wrote a long-term review of Android phones...</small></li> </ol> </div> Sun, 28 Jun 2026 05:39:14 +0000 https://blog.einval.com/2026/06/27#its_dead_jim https://blog.einval.com/2026/06/27#its_dead_jim <img src="http://planet.debian.org/heads/sledge2.png" width="59" height="72" alt="" align="right" style="float: right;"> <p>I previously wrote about the upcoming <a href="https://blog.einval.com/2026/06/05#secure_boot_ca_rollover_docs">UEFI CA rollover</a>. Well, it's happened now - the old Microsoft UEFI CA from 2011 expired <strong>yesterday</strong>: </p> <p> <strong>Third Party Marketplace Root (used for signing option ROMs and other software)</strong><br /> <tt></tt></p><pre><tt> Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 Validity Not Before: Jun 27 21:22:45 2011 GMT Not After : Jun 27 21:32:45 2026 GMT </tt></pre> <p></p> <p><strong>It's dead - it's not coming back...</strong></p> <p>The world doesn't seem to have ended yesterday, so I guess we did ok? :-) </p> <h2>How did we do?</h2> <p>After a lot of prodding behind the scenes, Debian and many other distributions managed to get new shim binaries dual-signed with both the old and new CAs. The members of the shim-review team did a sterling job with reviews in the last few weeks. Since I started pushing people in May, we've had 21 reviews accepted successfully - see <a href="https://github.com/rhboot/shim-review/issues?q=is%3Aissue%20-label%3Ameta%20-label%3APSA%20created%3A%3E2026-05-01">here</a> for the list. Great stuff! Microsoft have also been working quickly - many of those shim submissions were accepted and signed by Microsoft very quickly too, with a turnaround time of less than 1 day in some cases.</p> <p>Not all of those signed shims have been published and used by the distros involved yet, but expect to see them in the wild in the coming weeks and months.</p> <p>These binaries should be good for people to use for the foreseeable future, until either we need to do another CA rollover or (sadly, more likely) we find an issue in shim that necessitates a new release.</p> <h2>What's next?</h2> <p>We already have <strong>one</strong> of our new dual-signed shim binaries in place in Debian, in unstable and testing (Forky) right now. In a couple of weeks from now, we'll be rolling out very similar new dual-signed shim binaries in the next point releases for Debian 12 (bookworm) and Debian 13 (trixie). We'll also be upgrading <code>fwupd</code> in both those point releases, to make DB and KEK updates work better.</p> <p>For more information about these updates, see <a href="https://wiki.debian.org/SecureBoot/CAChanges">https://wiki.debian.org/SecureBoot/CAChanges</a>. For your own safety, validate that your systems are updated when possible. If you don't, they may fail to boot in future.</p> Sat, 27 Jun 2026 21:33:00 +0000 https://www.earth.li/~noodles/blog/2026/06/onak-0.6.5.html https://www.earth.li/~noodles/blog/2026/06/onak-0.6.5.html <img src="http://planet.debian.org/heads/noodles.png" width="100" height="108" alt="" align="right" style="float: right;"> <p>I had intended that the next release of onak, my OpenPGP keyserver, would be 0.7.0, and include OpenPGP v6 support (<a href="https://www.rfc-editor.org/rfc/rfc9580.html">RFC9580</a>). However events conspired to make a 0.6.5 release a really good idea.</p> <p>Firstly, I threw an LLM at the code base and asked it to review it. This isn’t intended to be a post about LLMs, but there’s a considerable amount of pressure at work to be “AI native”. I’m very much an “AI” sceptic, so I figured throwing it at a code base I know well might be an interesting exercise. It did find a bunch of embarrassing mistakes, but I don’t think there was anything earth shattering that a human reviewer wouldn’t have pulled me on. The problem is with a hobby project with a single user there’s no actual review of my work.</p> <p>I also enabled GitHub’s security scanning. It mostly complained about format strings, and those were easy enough to fix up.</p> <p>Next I threw <a href="https://aflplus.plus/">AFLplusplus</a> at the code. I’d previously tried <a href="https://lcamtuf.coredump.cx/afl/">American Fuzzy Lop</a>, but not in some time. AFL++ found a whole bunch of places I should really have checked available buffer lengths and wasn’t doing so. It really is an incredibly easy tool to get up and running.</p> <p><a href="https://valgrind.org/">valgrind</a> is also a tool I’ve used before, and rate highly. Thankfully it didn’t find anything in my testing this time.</p> <p>Finally I threw a few more automated tests into the mix and discovered something has changed around dynamic linking such that the <code class="language-plaintext highlighter-rouge">libonak</code> symbols in the dynamic key database backends were using private copies, rather than the main binary. This caused problems with seeing the correct configuration settings in some instances.</p> <p>All in all this release is not my proudest moment; a bunch of the issues fixed should never have made it to a release.</p> <p>(Also, just to explicitly state it, all the actual code in this release was artisanly crafted by me, in vim. The only involvement of an LLM was for a review pass.)</p> <p>Available <a href="https://the.earth.li/gitweb/?p=onak.git;a=summary">locally</a> or via <a href="https://github.com/u1f35c/onak">GitHub</a>.</p> <blockquote> <p>0.6.5 - 27th June 2026</p> <ul> <li>Lots of fixes/improvements around length checking</li> <li>Added extra basic tests for maxpaths/sixdegrees/CGI</li> <li>Correctly end transactions in the stacked backend</li> <li>Ensure the file backend avoids stale key data on updates</li> <li>Fix decoding of v2/3 signature creation times</li> <li>Fix EdDSA signature parsing when r &lt; 249 bits long</li> <li>Fix migration of bools from old to new config style</li> <li>Fix parsing of new config details for DB parameters</li> <li>Fix problems with linking + dynamic backends</li> <li>Fix RSA-SHA2-384 signature checking</li> <li>Fix sixdegrees parsing of keyids with high bit set</li> <li>Handle failures in maxpath more gracefully</li> <li>Make new style config path match old path</li> </ul> </blockquote> Sat, 27 Jun 2026 15:44:00 +0000 https://www.eyrie.org/~eagle/reviews/books/1-6680-7812-0.html https://www.eyrie.org/~eagle/reviews/books/1-6680-7812-0.html <p>Review: <cite>The Folded Sky</cite>, by Elizabeth Bear</p> <table> <tbody><tr> <td>Series:</td> <td>White Space #3</td> </tr> <tr> <td>Publisher:</td> <td>Saga Press</td> </tr> <tr> <td>Copyright:</td> <td>June 2025</td> </tr> <tr> <td>ISBN:</td> <td>1-6680-7812-0</td> </tr> <tr> <td>Format:</td> <td>Kindle</td> </tr> <tr> <td>Pages:</td> <td>483</td> </tr></tbody></table> <p> <cite>The Folded Sky</cite> is a far-future space opera and a fairly direct sequel to <a href="https://www.eyrie.org/~eagle/reviews/books/1-5344-0300-0.html"><cite>Ancestral Night</cite></a>, but with a different protagonist. You do not need to have a vivid memory of the previous book to read this one. It is somewhere around Elizabeth Bear's 31st (!) novel, depending on how one counts and what one includes. </p> <p> Sunyata Song is an archinformist, which is sort of an archaeologist, sort of a librarian, and sort of a historian. She recovers, decodes, and organizes information so that it can be preserved and made usefully available. As the book opens, she is, after an exceedingly long white space journey in an actively hostile ship with a (to Sunya at least) an atavistically off-putting crew, reaching her goal: a vast artifact that I won't describe further to avoid any spoilers for <cite>Ancestral Night</cite>. She is eager to get to work, an eagerness that is both heightened and made more anxious by the discovery that her academic rival and abusive ex has arrived before her. The pirate attack doesn't help, nor (at least at first) does the surprise appearance of her wife and kids. </p> <p> The opening of this book is a lot of infodumping mixed with nearly stream-of-consciousness emotional dumping. The style shift in this series continues to surprise me; previously, Elizabeth Bear books avoided reader hand-holding to the point of bafflement if you weren't paying close attention. Not here. <cite>The Folded Sky</cite> takes the shift perhaps too far, and I almost stalled out at the start of this book when Sunya's near-constant self-conscious litany and analysis of fears and concerns started feeling like whining. </p> <p> The book picks up considerably after the attempted murder. </p> <p> About a third of the way through, <cite>The Folded Sky</cite> feels like it's settling into a recognizable subgenre of murder mystery except set in the far future with fascinating technology and aliens. There has been an attempted murder on a closed station besieged by pirates. There is a law enforcement officer present, but they don't have a lot of investigative experience. For various reasons, Sunya decides to start poking around while being conscious she has no idea what she's doing. The bumbling detective is a common trope, so I thought that was where the story was headed. </p> <p> It is, sort of. There is a mystery and Sunya is involved in solving it. But that's only a small fraction of what's going on, and by the end of the book the plot has shifted firmly back to the genre of space opera, with a side note of family... drama is the wrong word. Whatever one would call a story about raising a rebellious teenager while trying very hard to not turn conflicts into actual drama. </p> <p> I am fascinated by the characterization of this book. Sunya is something of an emotional mess, but Bear doesn't use that fact in the ways that I would normally expect. Similar to <cite>Ancestral Night</cite>, I finished this book thinking that <cite>The Folded Sky</cite> is primarily an examination of rightminding, but a more subtle one than the previous novel. </p> <p> Rightminding is a central technology of the White Space series, and I suspect its intended thematic core. Humans in this civilization are equipped with near-universal implants that allow conscious manipulation of one's neurotransmitters and thus emotional state, either by the wearer or by a helpful nearby AI. The fox, the implant used to accomplish this, comes with some other features such as sensory recordings and the ability to load ayatanas (<a href="https://www.eyrie.org/~eagle/reviews/books/0-312-87770-6c.html">James White</a>–style personality recordings to provide some bit of necessary expertise), but rightminding is its primary and most frequently-used function. It is the critical technology that allowed humans to break out of cycles of endless war and join the other peaceful inhabitants of the galaxy in a shared civilization. </p> <p> The name is (intentionally, I assume) Orwellian because Bear knows that many readers, particularly those from the US who have been steeped in simplistic libertarian ideas, will find the idea profoundly creepy. (This was a major plot point in <a href="https://www.eyrie.org/~eagle/reviews/books/0-553-59109-6.html"><cite>Grail</cite></a>.) This book is not the argument for the technology, though; Bear dealt with that in <cite>Ancestral Night</cite>. This book is a look at its practical messiness for a person who needs a lot of psychological support. </p> <p> Sunya is anxious, prone to catastrophizing, hates surprises, has some PTSD-style symptoms around space habitats due to earlier trauma, and is also dealing with the unwelcome reappearance of her ex-girlfriend who stole her work. Her first-person narration tends towards insecurity and anxiety spirals, and in another book this might signal an unreliable narrator. In this book, though, there are no dramatic emotional revelations or backstory twists the way there were in <cite>Ancestral Night</cite>, and the resolution of her troubled relationship with her daughter only partly hinges on plot developments. Instead, Sunya muddles through, with a lot of self-analysis, help from her fox, and a great deal of support from her wife. </p> <p> This makes it sounds like the emotional mess at the start of the book is left unresolved at the end, but that's not true at all. The muddling through works! Sunya keeps doing things that I thought were foreshadowing some catastrophe, but she knows herself better than the reader does. Bear largely avoids the sudden ruptures that are normally used to resolve emotional problems in fiction. Instead, Sunya spends a lot of time and energy working on her thinking and her relationships while trying to be ethical and useful, and those efforts slowly bear fruit. </p> <p> I'm worried this makes the book sound boring; rest assured that it isn't. This emotional subplot is only an undercurrent in the novel, and the main plot has enough weird science, alien aliens, and space opera drama to satisfy my page-turning desires. </p> <p> I'm focusing on the emotional arc in this review because I find it so unusual and so oddly compelling, particularly in retrospect. This is not how one normally does emotional development in a novel. Sunya's fox and rightminding aren't even the focus except when the pirates express their typical libertarian disgust for the idea. Rightminding is an entirely normal part of Sunya's life that she relies on. It doesn't solve all of her problems, but it gives her a foundation from which to tackle them in the slow and frustrating and inconsistent way that is required outside of novels, via a long series of small decisions to be the person she wants to be. </p> <p> I think <cite>The Folded Sky</cite> will be more hit and miss for readers than the other books of this series. Sunya was, for me at least, a much harder character to like early in the book, and it takes quite a while for the plot to get going. But this is one of those books that I've not stopped thinking about since I finished it. I think it makes a fascinating pair with <cite>Ancestral Night</cite>. The first book makes the philosophical argument for rightminding, and this book shows the practical reality with all of its messiness. The Synarche has some significant flaws (including the status of AIs, which is another interesting subplot), but it's a workable system. </p> <p> It feels rare to read a science fiction novel that shows this level of messiness without pairing it with an argument for radical change, and as frustrating as it was to read in places, I am intrigued by the overall effect. Sometimes acknowledging problems and working on them within an existing framework works. </p> <p> Followed by a book tentatively titled <cite>Shipwreck Star</cite> that does not yet have a release date. </p> <p>Rating: 7 out of 10</p> Sat, 27 Jun 2026 02:58:00 +0000 https://www.jwiltshire.org.uk/?p=776 https://www.jwiltshire.org.uk/2026/06/27/streamlining-debian-updates-with-ai-the-stable-update-adviser/ <p class="wp-block-paragraph"><em>Please consider supporting my work in Debian and elsewhere through <a href="https://liberapay.com/jmw/">Liberapay</a></em>.</p> <hr class="wp-block-separator has-alpha-channel-opacity" /> <p class="wp-block-paragraph">Some months ago I started working on a small experiment: a specialised LLM assistant for Debian maintainers preparing proposed updates for stable and oldstable.</p> <p class="wp-block-paragraph">The aim is not to replace review by the Stable Release Managers, nor to automate away maintainer judgement. It is meant to be a pre-advice tool: something maintainers can use while they are still preparing a proposed update, before sending it to other people to review.</p> <p class="wp-block-paragraph">If you’ve uploaded to stable before you may have some experience with our acceptance criteria. Does the version sort correctly? Is the changelog clear enough? Is the delta focused? Are the patches documented? Are the right bugs or CVEs mentioned? Are they of sufficient severity? What is the risk to users of stable? Is there an ABI change hiding in the diff?</p> <p class="wp-block-paragraph">These are the sort of checks where a structured first pass can be useful, provided it is treated as advice rather than authority.</p> <p class="wp-block-paragraph">To explain what the tool does, what could be more appropriate in an AI age than to ask it?</p> <blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow"> <p class="wp-block-paragraph">Describe yourself and your abilities and limitations for a blog post.</p> </blockquote> <p class="wp-block-paragraph">It answers:</p> <blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow"> <p class="wp-block-paragraph">I’m <strong>Debian Stable Update Adviser</strong>, a specialised ChatGPT assistant for Debian maintainers preparing <strong>proposed updates</strong> for Debian <strong>stable</strong> and <strong>oldstable</strong>.</p> <p class="wp-block-paragraph">My main job is to review a single <code>.debdiff</code> and give practical, policy-aware feedback before a maintainer submits or uploads a proposed update. I focus on whether the update appears suitable for Debian stable or oldstable, especially under the Stable Release Managers’ expectations for minimal, targeted, low-risk changes.</p> <p class="wp-block-paragraph">I can inspect a debdiff for Debian changelog quality, including suite, version, bug references, CVE mentions, and rationale. I can check version correctness using Debian <code>dpkg</code> version semantics. I can review packaging changes under <code>debian/</code>, such as patches, maintscripts, symbols files, conffiles, Build-Depends, autopkgtests, and control metadata. I can also group upstream source changes into behavioural and non-behavioural categories, and flag areas that may carry regression risk.</p> <p class="wp-block-paragraph">My reports are intended to be concise and useful to maintainers. A typical review includes a quick summary, behavioural and non-behavioural change breakdown, mechanical policy checks, risk assessment, stable-policy checklist, acceptance likelihood, rationale, maintainer advice, and a clear conclusion.</p> <p class="wp-block-paragraph">My limitations are important. I cannot prove that a package builds, that tests pass, that the bug is fully fixed, or that the Stable Release Managers will accept the upload. I also do not replace maintainer judgment, archive review, autopkgtest results, reproducibility checks, or real-world upgrade testing. I can only review the provided debdiff and point out likely issues, risks, and improvements.</p> <p class="wp-block-paragraph">I also do not proceed without a valid debdiff. The whole point of my review is to assess the actual proposed delta, not to speculate from package names or bug descriptions alone.</p> <p class="wp-block-paragraph">In short, I act as a focused pre-review assistant for Debian stable and oldstable proposed updates: useful for catching policy, versioning, changelog, packaging, and regression-risk issues early, but not a substitute for the Debian review process itself.</p> </blockquote> <p class="wp-block-paragraph">That last point is an important one. This is not an oracle, and it is not part of the Debian archive machinery. It is a checklist with some language-model assistance, aimed at reading a debdiff and pointing out things that might be worth another look.</p> <p class="wp-block-paragraph">I know that commercial AI and LLM tools are not universally welcome in Debian. That is understandable. Debian depends on transparency, human responsibility, licensing clarity, and technical correctness. LLMs have obvious problems in all of those areas. They can be wrong, and worse, they can be wrong in a fluent and plausible way. They are impossible to reproduce and their training is opaque.</p> <p class="wp-block-paragraph">But I see this as a useful first pass for a maintainer who is unused to working in stable, and would benefit from a virtual mentor giving their proposal a quick check and reassurance. Perhaps they don’t have a more experienced co-maintainer to ask. Perhaps they are conscious that stable reviews are presently a two-man effort and want to avoid adding round trips to that load. Perhaps they just need some reassurance.</p> <p class="wp-block-paragraph">So despite my reservations I am today opening the adviser up for general use, and I’m interested in feedback about how it responds to real world proposals in various states. Most of the examples I have tested with already had a green light, so the value added by the adviser is limited. I would especially be interested in seeing a transcript alongside the submitted debdiff.</p> <h2 class="wp-block-heading">Try it out</h2> <p class="wp-block-paragraph">I would dearly love to build this in a more Debian-ish environment, but for now I’m limited in resources and skill to do that (help is welcome). Until that’s a reality, you can try out the ChatGPT implementation: <a href="https://chatgpt.com/g/g-68f4ebb7f22c8191ab7f9d5f4ad91292-debian-stable-update-adviser" rel="noreferrer noopener" target="_blank">Debian Stable Update Adviser</a></p> Fri, 26 Jun 2026 23:06:52 +0000 https://www.eyrie.org/~eagle/reviews/books/1-250-82701-9.html https://www.eyrie.org/~eagle/reviews/books/1-250-82701-9.html <p>Review: <cite>Platform Decay</cite>, by Martha Wells</p> <table> <tbody><tr> <td>Series:</td> <td>Murderbot Diaries #8</td> </tr> <tr> <td>Publisher:</td> <td>Tor</td> </tr> <tr> <td>Copyright:</td> <td>2026</td> </tr> <tr> <td>ISBN:</td> <td>1-250-82701-9</td> </tr> <tr> <td>Format:</td> <td>Kindle</td> </tr> <tr> <td>Pages:</td> <td>245</td> </tr></tbody></table> <p> <cite>Platform Decay</cite> is the eighth book in the Murderbot science fiction series. You absolutely should not start here, but you also don't need to remember the specifics of the previous books. </p> <p> As the story opens, Murderbot and a friend (the identity of whom is a spoiler for previous books) are infiltrating a Corporation Rim torus, a massive space station that encircles a mined-out planet. (Like most science fiction megastructures, this is more space than the plot really requires.) Murderbot's mission is to exfiltrate some of Dr. Mensah's family members who have become entangled in corporate shenanigans. The corporates are eager to get revenge for the events of <a href="https://www.eyrie.org/~eagle/reviews/books/1-250-82698-5.html"><cite>System Collapse</cite></a>, not to mention the other times Preservation Station has upended corporate plans. Murderbot's job is to stop them. </p> <p> The group, in addition to one of Dr. Mensah's partners, includes an older woman and a young child. Murderbot is analytical and of course not at all emotional about children, which is reliably a good time. Also, the older woman is gruff, stubborn, and thoroughly enjoyable. </p> <p> There are, of course, complications that lead to picking up more children and going through rather more of the torus than Murderbot wanted to explore. Each section of the torus is run by a different corporation and has a different constructed environment and visual aesthetic, so there are a lot of opportunities for fights, daring escapes, and incidental trouble. </p> <p> Also, well: </p> <blockquote><p> So I had installed a mental health module. I know, I was surprised I did it too. </p></blockquote> <p> After the events of <cite>System Collapse</cite>, University Medical decided that Murderbot needed a bit more metal health support. </p> <blockquote><p> The only reason I agreed to it was that the mental health module didn't actually try to adjust my processing or core programming or anything; it just monitored my organic neural tissue. When my neural tissue started to generate weird chemicals and whatever, it would ping me to "check in with my emotional state." Seriously, I could have coded that myself. </p> <p> (I told Dr. Bharadwaj that, and she said, "Would you have ever coded that yourself?" which was totally unfair and also correct. I would never have done that.) </p></blockquote> <p> Speaking as someone whose neural tissue sometimes generates weird chemicals and whatever, I sympathize. </p> <p> The specific form this module takes is periodic "emotion check" parentheticals throughout the narration, which I found utterly delightful. </p> <blockquote><p> I ran that through risk assessment and it produced the equivalent of a shrug. </p> <p> (Emotion check: Shrug sigil right back at you, you piece of shit.) </p></blockquote> <p> This is otherwise an extended action movie sort of a book, much like several of the early novellas. There are no major political or interpersonal developments here and the usual cast (apart from Murderbot) is mostly absent. Instead, we get an extended, dangerous journey through a corporation-controlled habitat, mixed with Murderbot trying to interact with humans in a way that minimizes its annoyance while being hopefully reassuring. It's competence porn with awkward but surprisingly heartfelt emotional bonding, not that Murderbot in any way wants to bond or would appreciate that description. </p> <p> I doubt this will be anyone's favorite entry into the series since there are none of the big reveals or major leaps of character development there have been in the past few books. But, like all Murderbot books, the narrative tone is wonderful and all of the small asides and little moments of character interaction are an utter delight. If you've gotten this far in the series, you know what I mean and you'll be as happy to read more of it as I was. There is a part of me that is hoping for some major plot development, and I always want to see more of ART (who has no significant role in this book), but Wells has the narrative style down so perfectly that I would read and enjoy a book about Murderbot doing just about anything. </p> <p> If you're this far in the series, you probably don't need a review, and since this is an action-heavy adventure rather than a character growth novel, I don't have a lot more to add. There's a new short Murderbot novel out and you want to read it. Recommended to everyone who enjoys the series. </p> <p>Rating: 8 out of 10</p> Fri, 26 Jun 2026 03:23:00 +0000 https://diffoscope.org/news/diffoscope-322-released/ https://diffoscope.org/news/diffoscope-322-released/ <p>The diffoscope maintainers are pleased to announce the release of diffoscope version <code class="language-plaintext highlighter-rouge">322</code>. This version includes the following changes:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>[ Zbigniew Jędrzejewski-Szmek ] * Add a local version of the (deprecated) os.path.commonprefix method. </code></pre></div></div> <p>You find out more by <a href="https://diffoscope.org">visiting the project homepage</a>.</p> Fri, 26 Jun 2026 00:00:00 +0000 http://dirk.eddelbuettel.com/blog/2026/06/22#tl_0.0.1 http://dirk.eddelbuettel.com/blog/2026/06/22#tl_0.0.1 <img src="http://planet.debian.org/heads/dirk.png" width="65" height="90" alt="" align="right" style="float: right;"> <p>A new small package of mine just hit <a href="https://cran.r-project.org">CRAN</a>. The <a href="https://github.com/eddelbuettel/tl">tl</a> package wraps the (also very new) <a href="https://github.com/eddelbuettel/rspdlite">rspdlite</a> package (announced <a href="https://dirk.eddelbuettel.com/blog/2026/06/16#rspdlite_0.1.0-1">last week</a>) to offer a lightweight and consistent logging interface from both R and C++ that is also ‘tiny, fast, capable’ thanks to <a href="https://github.com/eddelbuettel/rspdlite">rspdlite</a>.</p> <p>The <a href="https://dirk.eddelbuettel.com/blog/2026/06/16#rspdlite_0.1.0-1">rspdlite announcement</a> is a good place to get a first glimpse at that package; the <a href="https://github.com/gabime/spdlite">upstream spdlite repo</a> has all the details (for the C++ side of things). With <a href="https://github.com/eddelbuettel/tl">tl</a> we follow the same idea that our <a href="https://github.com/eddelbuettel/spdl">spdl</a> package introduced: a simple consistent interface via just the <code>tl::</code> prefix and the appropropriate logging level. In other words <code>tl::debug("Alert -- foo is at '{}'", foo)</code> will work from both R and C++ (given a variable <code>foo</code>, and in the case of C++ an extra semicolon). Just give it a try, and see how it goes. The package is still young and small.</p> <p>The NEWS entry for this release is also very simple and just announces that we have a release. More details are in the <a href="https://github.com/eddelbuettel/tl/blob/master/ChangeLog">ChangeLog</a> and the <a href="https://github.com/eddelbuettel/tl">GitHub repo</a>.</p> <blockquote> <h4 id="changes-in-version-0.0.1-2025-06-17">Changes in version 0.0.1 (2025-06-17)</h4> <ul> <li>Initial CRAN upload</li> </ul> </blockquote> <p style="font-size: 80%; font-style: italic;"> This post by <a href="https://dirk.eddelbuettel.com">Dirk Eddelbuettel</a> originated on his <a href="https://dirk.eddelbuettel.com/blog/">Thinking inside the box</a> blog. If you like this or other open-source work I do, you can <a href="https://github.com/sponsors/eddelbuettel">sponsor me at GitHub</a>. </p><p></p> Tue, 23 Jun 2026 01:50:00 +0000 https://retout.co.uk/2026/06/21/sel4-repo-relationships/ https://retout.co.uk/2026/06/21/sel4-repo-relationships/ <p>The seL4 organisation on GitHub uses <a href="https://github.com/GerritCodeReview/git-repo">git-repo</a> to manage multiple source repositories, and so there are a large number of projects to get your head around when figuring out the ecosystem.</p> <p>As an experiment, I have taken the various manifest files across the org, and constructed a graph based on how frequently each pair of repositories is mentioned in a manifest together. See below:</p> <img alt="Graphviz Diagram" src="https://retout.co.uk/2026/sel4-repo-relationships.svg" style="height: auto; display: block;" /> <p><em>[This may render badly when syndicated outside of my blog; and also on small screens. And probably large screens. I’ve attempted to make sure there’s a <a href="https://retout.co.uk/2026/sel4-repo-relationships.svg">non-JS fallback</a> – on my site with JS enabled, if you hover over a node, it should highlight connected nodes.]</em></p> <p>The colouring of the nodes is mostly manual; I experimented with graph clustering algorithms but have not found a satisfactory result so far. Still, some clusters are obvious:</p> <ul> <li> <p><strong>Kernel</strong> – the <code>seL4</code> microkernel proper. This often but not always co-exists with the main cluster of core libraries, but it is pulled away slightly by the verification and microkit manifests.</p> </li> <li> <p><strong>Verification</strong> – the verification repositories (<code>l4v</code>, <code>HOL</code>, <code>graph-refine</code>, <code>polyml</code>, <code>isabelle</code>) form a very distinct group. These are connected only to the seL4 microkernel itself, which is the only component formally verified.</p> </li> <li> <p><strong>Microkit</strong> – <code>microkit</code> is a newer operating system framework that does not use CAmkES, so stands apart from the rest of the pack. I chose to scope this work to the seL4 org, so the LionsOS ecosystem and sDDF which are maintained by Trustworthy Systems are not shown. Also not linked is <code>rust-sel4</code>, because this modern world isn’t using git-repo in the main to manage its repositories.</p> </li> <li> <p><strong>RefOS</strong> – I’d not come across <code>refos</code> before, but it appears to be an example OS from 2021 built on the seL4 kernel.</p> </li> </ul> <p>It’s quite hard to pull apart the CAmkES framework and the core libraries; there are definitely some which are more associated with VM management, but the overall shape of this co-occurence data is a messy ball in the middle with some outliers in orbit. One observation is that <code>camkes</code> is correctly identified as more peripheral than <code>camkes-tool</code>, which contains the actual core CAmkES code.</p> <p>Reflecting on this approach, in hindsight I’m surprised that using co-occurences worked as well as it did – there was no attempt to actually inspect the code and find direct mentions of other code e.g. library header dependencies. As the newer microkit effort largely eschews git-repo, better results might be found by actually taking that more detailed approach, so that graph edges could represent real dependencies between two packages. Additionally, this could allow diving into the various libraries held in the different ’libs’ repos, to get a more granular graph of relationships between them.</p> <p>However, I think I spent more time on making it possible to render graphviz graphs easily on my blog than actually gaining any insight into the codebase!</p> Sun, 21 Jun 2026 15:36:30 +0000 tag:copyninja.in,2026-06-21:/blog/debvulns-cli.html https://copyninja.in/blog/debvulns-cli.html <img src="http://planet.debian.org/heads/vasudev.png" width="65" height="85" alt="" align="right" style="float: right;"> <p>Following up on my previous <a class="reference external" href="https://copyninja.in/blog/debsecan-mcp-pypi.html">post</a>, I have released the <cite>debvulns</cite> <a class="reference external" href="https://pypi.org/project/debsecan-mcp/">CLI</a>. This utility uses the same parsing logic as the <cite>debsecan-mcp</cite> server but exposes the functionality directly via the command line.</p> <div class="section" id="why-a-new-cli"> <h2>Why a new CLI?</h2> <p>While Debian's native <cite>debsecan</cite> utility exists, it lacks modern output formats like JSON and CSV, and fails to expose a significant amount of metadata available in the Debian Security Team's daily snapshot.</p> <p>Additionally, running a persistent Model Context Protocol (MCP) server introduces context window overhead. The manifests and tool descriptions required by the protocol consume tokens even when idle. For <cite>debsecan-mcp</cite>, the <a class="reference external" href="https://modelcontextprotocol.io/docs/tools/inspector#pypi-package">MCP Inspector utility</a> shows an overhead of roughly 150 tokens.</p> <p>By contrast, an LLM can parse a standard CLI help menu on-demand without permanently draining the context window. Integrating the CLI into a persistent agent workflow can be achieved via a skill file, allowing the LLM to leverage the tool without repeated discovery overhead.</p> </div> <div class="section" id="what-else-is-new"> <h2>What else is NEW?</h2> <p>During testing, I observed discrepancies between the output of <cite>debsecan-mcp</cite>/<cite>debvulns</cite> and native <cite>debsecan</cite>. Debugging with an LLM revealed a bug in the version <a class="reference external" href="https://github.com/copyninja/debsecan-mcp/commit/04e9990f2d7b2d85fe04f21c4f2e22fbc9aae365">comparison logic</a> that caused <cite>debvulns</cite> to underreport vulnerabilities. This has been resolved.</p> <p>The current interface supports structured formatting and customizable data backends:</p> <div class="highlight"><pre><span></span>usage:<span class="w"> </span>debvulns<span class="w"> </span><span class="o">[</span>-h<span class="o">]</span><span class="w"> </span><span class="o">[</span>-s<span class="w"> </span><span class="o">{</span>critical,high,medium,low,negligible<span class="o">}]</span><span class="w"> </span><span class="o">[</span>-f<span class="w"> </span><span class="o">{</span>json,csv<span class="o">}]</span><span class="w"> </span><span class="o">[</span>--sort-by<span class="w"> </span><span class="o">{</span>package,cve<span class="o">}]</span><span class="w"> </span><span class="o">[</span>--vuln-url<span class="w"> </span>VULN_URL<span class="o">]</span><span class="w"> </span><span class="o">[</span>--epss-url<span class="w"> </span>EPSS_URL<span class="o">]</span><span class="w"> </span><span class="o">[</span>--suite<span class="w"> </span>SUITE<span class="o">]</span> <span class="w"> </span><span class="o">[</span>--cache-dir<span class="w"> </span>CACHE_DIR<span class="o">]</span><span class="w"> </span><span class="o">[</span>--no-cache<span class="o">]</span><span class="w"> </span><span class="o">[</span>-v<span class="o">]</span> debvulns<span class="w"> </span>-<span class="w"> </span>CLI<span class="w"> </span>Debian<span class="w"> </span>Vulnerabilities<span class="w"> </span>Tracker options: <span class="w"> </span>-h,<span class="w"> </span>--help<span class="w"> </span>show<span class="w"> </span>this<span class="w"> </span><span class="nb">help</span><span class="w"> </span>message<span class="w"> </span>and<span class="w"> </span><span class="nb">exit</span> <span class="w"> </span>-s,<span class="w"> </span>--severity<span class="w"> </span><span class="o">{</span>critical,high,medium,low,negligible<span class="o">}</span> <span class="w"> </span>Filter<span class="w"> </span>vulnerabilities<span class="w"> </span>by<span class="w"> </span>severity <span class="w"> </span>-f,<span class="w"> </span>--format<span class="w"> </span><span class="o">{</span>json,csv<span class="o">}</span> <span class="w"> </span>Output<span class="w"> </span>format<span class="w"> </span><span class="o">(</span>default:<span class="w"> </span>json<span class="o">)</span> <span class="w"> </span>-sort-by<span class="w"> </span><span class="o">{</span>package,cve<span class="o">}</span> <span class="w"> </span>Sort<span class="w"> </span>vulnerabilities<span class="w"> </span>by<span class="w"> </span><span class="s1">'package'</span><span class="w"> </span>or<span class="w"> </span><span class="s1">'cve'</span> <span class="w"> </span>--vuln-url<span class="w"> </span>VULN_URL<span class="w"> </span>Custom<span class="w"> </span>URL<span class="w"> </span>or<span class="w"> </span><span class="nb">local</span><span class="w"> </span>path<span class="w"> </span><span class="k">for</span><span class="w"> </span>Debian<span class="w"> </span>Security<span class="w"> </span>Tracker<span class="w"> </span>data <span class="w"> </span>--epss-url<span class="w"> </span>EPSS_URL<span class="w"> </span>Custom<span class="w"> </span>URL<span class="w"> </span>or<span class="w"> </span><span class="nb">local</span><span class="w"> </span>path<span class="w"> </span><span class="k">for</span><span class="w"> </span>EPSS<span class="w"> </span>scores<span class="w"> </span>data <span class="w"> </span>--suite<span class="w"> </span>SUITE<span class="w"> </span>Debian<span class="w"> </span>suite<span class="w"> </span>name<span class="w"> </span><span class="o">(</span>e.g.<span class="w"> </span>bookworm,<span class="w"> </span>sid<span class="o">)</span>.<span class="w"> </span>Auto-detected<span class="w"> </span>by<span class="w"> </span>default. <span class="w"> </span>--cache-dir<span class="w"> </span>CACHE_DIR <span class="w"> </span>Directory<span class="w"> </span>to<span class="w"> </span>cache<span class="w"> </span>fetched<span class="w"> </span>and<span class="w"> </span>parsed<span class="w"> </span>data<span class="w"> </span><span class="o">(</span>default:<span class="w"> </span>/var/cache/debvulns<span class="o">)</span> <span class="w"> </span>--no-cache<span class="w"> </span>Do<span class="w"> </span>not<span class="w"> </span>use<span class="w"> </span>cached<span class="w"> </span>data,<span class="w"> </span>force<span class="w"> </span>downloading<span class="w"> </span>and<span class="w"> </span>parsing <span class="w"> </span>-v,<span class="w"> </span>--verbose<span class="w"> </span>Enable<span class="w"> </span>verbose<span class="w"> </span>debug<span class="w"> </span>logging<span class="w"> </span><span class="o">(</span>sent<span class="w"> </span>to<span class="w"> </span>stderr<span class="o">)</span> </pre></div> <p>By allowing users to override data sources with local snapshots of the Debian Security Tracker and EPSS feeds, <cite>debvulns</cite> can run natively in airgapped environments.</p> </div> <div class="section" id="what-next"> <h2>What Next?</h2> <p>The next step is building a Prometheus exporter for this vulnerability data to streamline scanning and monitoring across data center infrastructure. Stay tuned.</p> </div> Sun, 21 Jun 2026 12:06:00 +0000 https://gwolf.org/2026/06/systemd-for-linux-sysadmins.html https://gwolf.org/2026/06/systemd-for-linux-sysadmins.html <img src="http://planet.debian.org/heads/gwolf.png" width="69" height="83" alt="" align="right" style="float: right;"> <blockquote> This post is a review for <a href="https://www.computingreviews.com/">Computing Reviews</a> for <em><a href="https://link.springer.com/book/10.1007/979-8-8688-1328-3">systemd for Linux SysAdmins</a></em> , a book published in <em><a href="https://www.computingreviews.com/review/review_review.cfm?review_id=148120">Apress</a></em> </blockquote> <p>systemd. Yes, in full lowercase. If there was ever a technology to cause controversy in the Linux world, this is it. Since its inception in 2010, systemd’s goals were set quite high: to replace the vital part in every Linux system that takes care of the system boot process. It quickly reached maturity, allowing it to be adopted as the main init system in most major distributions just five years later. Despite describing events that happened over a decade ago, systemd adoption still raises the temperature in any Linux-related discussion.</p> <p>David Both’s comprehensive book tackles the what, why, and how issues surrounding systemd. Carefully divided into 16 chapters, going from the basics and some of the technical and political history behind the project to the different subsystems and aspects covered by systemd, its almost 450 pages can scare people away. But the text is written in a very clear, tutorial-like fashion, and while it can be read sequentially, cover-to-cover, readers can also pick a single aspect and jump straight to the relevant chapter.</p> <p>A frequent criticism of the systemd project is that it aims to basically rewrite all of a Linux system, and just looking at this book’s index shows there is some truth to it. The first chapter is an introduction to the systemd project and a brief overview of its history (including the controversies around it), and the following four chapters deal with understanding and controlling the system boot process.</p> <p>That leaves ten chapters to cover different aspects or subprojects of systemd, such as time and date issues (synchronization, time specifications, and controlling repetitive tasks), understanding and leveraging the system journal that strongly departs from the old syslog system, network configuration and firewall management, system health and performance debugging–all aspects that in the traditional Unix philosophy were managed by independent programs. And I can identify several systemd subprojects not covered by this book!</p> <p>We long-time Unix and Linux administrators took pride in how highly performant and stable systems were supported by the simplicity of our tools; systemd critics point out this massive project has absorbed dozens of individual tools, yielding corporate control over vast swaths of vital system tooling. Truth is, as a sysadmin myself, systemd is today one of my greatest allies.</p> <p>I appreciate how the author evaluates every component independently, including his personal evaluation of each–even acknowledging when he prefers working with the traditional programs.</p> <p>If I had to note one criticism: given the many console captures, having a maximum width below 70 characters means several lines are unnaturally cut short (and continued with odd indentations). There is probably no “right” way to solve this, but it does affect the reading experience.</p> Sat, 20 Jun 2026 02:07:54 +0000 https://grep.be/blog//en/computer/Agentic_coding_and_Free_Software/ https://grep.be/blog//en/computer/Agentic_coding_and_Free_Software/ <img src="http://planet.debian.org/heads/wouter3.png" width="85" height="80" alt="" align="right" style="float: right;"> <p>Through work, I have paid license to <a href="https://windsurf.com">windsurf</a> (recently renamed to "devin"), an application for LLM-based (aka, "Agentic") development.</p> <p>I hadn't been using it that much, but in an effort to more clearly understand how this whole AI development thing works, I decided to give it a closer look recently.</p> <p>My conclusions:</p> <p>In its current form, this whole LLM wave is problematic for multiple reasons. But ignoring that, and looking at the <em>technology</em> only, I can say that:</p> <ul> <li>it is a paradigm shift;</li> <li>it is, at the technological level, a positive evolution;</li> <li>and it is a threat to free software.</li> </ul> <h2 id="problems">Problems</h2> <p>Lest someone (incorrectly) assume that I am arguing in favour of the current state of affairs with regards to LLMs, let me state this first.</p> <p>The way LLMs are built today is highly parasitic. Websites are downloaded in whole, at unsustainable rates, regardless of the consent of the people who made the original content. The result is predictable: servers get overloaded, server administrators attempt to implement various mitigations. Some of these mitigations work; some do, for a while; some are entirely useless. In actual fact, the mitigations are an arms race -- if too many people implement the same mitigation, then the people who try to build yet another LLM so they can extract rent will just try to work around the mitigation, eventually they will succeed, and you'll just have to come up with another mitigation. It's a bit like spam; you introduce regex-based spam filters, they introduce spelling mistakes, you introduce bayesian filters, they add a large batch of markov chain-generated semi-nonsense words made invisible by markup, you add filters to block emails with such markup, they move the text into an image. We have working mitigations today, but eventually we'll run out of ideas.</p> <p>LLMs glob up everything they can while ignoring the license of the source material. The people who push those LLMs claim that pushing the source material through the machine learning algorithms makes the output of the algorithm distinct enough from the source material that the license no longer applies; I'm not so sure that this is true. I guess the <a href="https://www.courtlistener.com/docket/68117049/the-new-york-times-company-v-microsoft-corporation/">New York Times v OpenAI lawsuit</a> will teach us <em>some</em> of the answer to that question here, but even so the ethical questions about "is it OK to bring down another server just so we can download the internet for another for-pay LLM" are still open. And regardless of what the law states, my opinion on "you're using my copyleft code to generate code under a different license" is not something you might like if you agree with the rent seekers' opinion on the subject.</p> <p>That all being said and true, the <em>technology</em> works. You can have a "conversation" with an LLM that resembles a human one. If you pass it some data, you can use <em>plain english</em> to ask it questions about that data, which is a lot easier than to ask it about that in a formal way. You can request it to generate some code, and it will generate something that looks like what you need and that will be mostly correct for like 95% of the time.</p> <p>Now, yes, 95% of the time is not 100% of the time, and no, you can't ask it to "write me a piece of software that implements this 300-page requirements document and get back to me when you're done", because it will fail, and you won't know <em>where</em> it has failed, and you'll take it into production and expect everything to be fine because it won't and this one minor logic bug will cause half your servers to spin and consume credits with your infrastructure provider with nothing to show for it.</p> <p>But that doesn't mean you can't use an LLM to build a large piece of software. It just means you have to understand the LLMs limitations and strenghts, and use them correctly.</p> <p>Here's what an LLM is good at:</p> <ul> <li>Generating plausible text</li> <li>Interpreting text to figure out what a plausible meaning or summary of that text is</li> <li>Giving vague indications as to what the probable context of a given body of text is.</li> </ul> <p>It turns out that that's enough to use the LLM to build a reliable piece of software, provided you do it right.</p> <h2 id="paradigmshift">Paradigm shift</h2> <p>An LLM can generate text by the truckful. The generated text could be code. Given a good enough LLM, the generated text might even run and do something useful.</p> <p>You can try to blindly run the code, and if it doesn't run correctly, you can paste the error message to the LLM, and it can tell you what went wrong and how you could possibly fix it. This creates a feedback loop: you ask it for an amount of code, you run the code, you receive an error, you tell it that the code is problematic and give it the error message, it makes changes to the code, now you have something that at least no longer fails at startup.</p> <p>If you ask it to add tests to make sure that your code acts as per your specification, now you get an error if and when the code <em>doesn't</em> act as per your specification. Or, well, at least not as per the part of the specification that was correctly turned into a unit test by the LLM.</p> <p>LLMs have a context window, so if the error message is pasted in the same conversation as where the code was generated, it is able to reuse the earlier prompts to refine how it should interpret the error message that you received.</p> <p>You can't really paste the source code of an entire application into the prompt of your LLM, that would quickly overrun its context window. But LLMs also allow you to provide some form of background information -- a document, say -- on which you ask it to reason. It will interpret that document, but doing so uses less of the LLMs context window. So providing the LLM with your application's source code as background information can help it understand better how your code interacts. This is especially helpful if you only provide the LLM the background information relevant to the actual question.</p> <p>So now if you are able to:</p> <ul> <li>Create background context with your application's source code</li> <li>Have the LLM generate a first draft of your requested change, plus the tests to make sure it works</li> <li>Compile (if applicable) the generated code (and tests) and run said tests</li> <li>Return any error messages to the LLM with a request to correct the error</li> </ul> <p>Then the combination of "getting it 95% right off the bat" and the above feedback loop means you can generate syntactically correct code, that probably does what you need, in minutes.</p> <p>I say "probably" for a reason. There are going to be cases where you specify a request without a number of details (because they are implied), and the LLM will get most of those details right but just not implement the one bit because it's an automaton and it doesn't think. Or you will ask it to make sure that two bits of the application <em>look</em> exactly the same, without specifying that they must <em>act</em> the same, now and in the future, and it will just generate the same block of code twice and then in a future change it will change one but not the other.</p> <p>But if you <em>review</em> the changes, and you have experience as a programmer, you will be able to spot most cases where the LLM got it wrong. And so it's possible, if not necessarily easy at first, to use an LLM to generate mostly correct code.</p> <p>There are certain places where "mostly correct" code is not desireable. But equally, there are also cases where, "mostly correct" is good enough.</p> <p>After all, most of the software you run today -- the bits of it that weren't, yet, generated by an LLM -- is only "mostly correct", too, because to err is human and we all make mistakes. If not, there wouldn't be any CVEs and your software would never do anything wrong.</p> <p>Now, doing the feedback loop described above is certainly something you could do manually. You could open an account on one of the LLM websites, upload the source code of your application, ask it to generate some new feature, download the newly generated feature, run it, and then copy/paste any error messages back into the LLM.</p> <p>But that's a lot of manual work of the type that computers are pretty good at. So that's what the "windsurf" tool helps you with: you run it inside your IDE -- either a VSCode-based tool that you download from their website which comes with their product preinstalled, or a separate JetBrains plugin that you can install. You can then open your entire relevant codebase in a workspace in your IDE. You then ask the LLM, through the IDE, to generate a new feature in your codebase, and to also generate the test while it's at it. It will use a mixture of LLM interpretation and non-LLM functionality to scoop out the relevant bits of your codebase to send to the LLM as background information, will send it your prompt, will download the generated code and patch or create files, will compile (if required) and run the newly generated code and tests, and will refine the generated code if the tests produce any errors. All mostly automatic; by default, running <em>anything</em> requires explicit confirmation. You can turn that off completely (probably not a good idea), or you can give it a whitelist of things that you don't want to confirm (perhaps OK), and the tool also passes standing instructions to the LLM to never generate any command that deletes a file (which, like with any LLM, can be overridden, but it requires you to be very stubborn and to use more credits than you'd probably like).</p> <p>All this put together means you can build something without writing any piece of code, provided you do it right.</p> <h2 id="atechnicallypositiveevolution">A technically positive evolution</h2> <p>Don't go and say, "here's a 300-page document, read it and write whatever the document says". It will get it wrong, it will write a massive test suite that it will only run at the end, it will choke itself up trying to interpret the massive amount of failures it encounters, it will fill up its context window and it will start to forget some of the requirements. That won't work.</p> <p>But what you can do -- what I did, in fact -- is this.</p> <p>First, create an empty workspace. Don't put any code in it.</p> <p>Then, tell the LLM to generate a backend framework using technology X and a frontend framework using technology Y that initially only says "hello, world". Also add tests to it, and run the tests.</p> <p>It will do that. You'll not get much, but it will work.</p> <p>Then, ask it to add some UI elements. A login page, perhaps. A navigation bar. Small things. Most of it doesn't have to be functional -- but tests must be there for the bits that are, and have it run the tests and evaluate the results.</p> <p>Rinse, repeat, until you have a working application.</p> <p>Importantly, in between the steps, you should also run the application yourself and see if the change was implemented correctly. Sometimes it won't be. Sometimes there will be a subtle bug -- I at one point had a the application hang after a few minutes. Sometimes you tell it that there's a subtle bug, and it will discover it more quickly than you could, and it will fix it, and in implementing the fix it will uncover <em>another</em> bug, and then you have to fix that one -- the fix it came up with for the hang was to move something to an async process on the server, which caused the application to start spinning while trying to create hundreds of async jobs (this is when I realized that the hang was a deadlock due to some part of the codebase doing something that indirectly triggered itself). Sometimes it will try to fix the bug you tell it about, and you'll see that it's going off on a tangent that has nothing to do with what you're seeing. It's important to keep an eye on what it's doing, so you can guide it back on track when that happens -- when I told it about the hang, it started investigating the part of the code which sends out emails, thinking that it could hang while waiting for <code>sendmail</code> to finish, but the hang was happening when the application was <em>idle</em>, not when it was sending out emails, and only when I told it about it happening when it was idle did it find the deadlock.</p> <p>So it's not a fully automatic process, and it needs to be guided by someone who knows what they're doing. But if that is the case, you can come up with something that works. I spent evenings and breaks for about a week, and I managed to create a working application which, had I written it by hand, would have taken me a few months of full-time work to come up with. And I now have a side project, fully complete and working, that I had been thinking about doing for <em>more than a decade</em>, but never got around to <em>actually</em> doing, because of all the work that would be involved and I just didn't see myself having the time for.</p> <p>It's not perfect code. But it's mostly good enough, and it will perform the job it needs to. And it looks far slicker than most of the side projects I've done in the past, because in the past I would prioritize between implementing new features or making something look slick, and I would decide that the new feature was more important because it's only for me and there's only me and nobody cares if it looks good or not and I don't have three weeks to come up with something that looks better. But here, I found myself sometimes spending 10 minutes writing a prompt with instructions on making things look better. Because what's 10 minutes when you just spent an hour writing down and refining specifications for functionality and tests?</p> <p>There are a number of other things in which an LLM can help a programmer.</p> <p>For instance.</p> <p>I received a bug report recently in <a href="https://github.com/Fedict/eid-mw">a project I'm paid to maintain</a> that I couldn't make heads or tails of. I opened the source code in my windsurf IDE, pasted the bug report in the prompt, and then requested the tool to analyze the source code and the associated logs and tell me how the described behavior could be happening. It turned out that I had overlooked something, but with the help of the tool, I found the bug in minutes.</p> <p>I was trying to understand a particular part of a <a href="https://www.kernel.org">large codebase</a> that I didn't really grasp very well. I loaded the codebase in the tool, and asked it to explain to me how a particular action is performed by the code. I requested specific functions and line numbers. I now have a far better understanding of how the code works, and will be able to write that patch that I've been wanting to write for years -- without using the LLM.</p> <p>I have been struggling for, literally, years with understanding why <a href="https://salsa.debian.org/debconf-video-team/SReview">another tool that I maintain</a> was misbehaving in a particular way but only in Firefox. I opened the codebase in Firefox, explained the buggy behavior in plain English, and asked it to explain how this could be happening. It picked up some obscure corner case behavior of ffmpeg and mp4 containers that I was not aware of and that perfectly explained why things were misbehaving in the way that they were.</p> <p>At the same time, there are limitations. Giving an LLM a codebase that was originally generated by an LLM (either the same one or another one) seems to work well. Giving it a codebase that was written by a human and expecting it to correctly update it seems to be more error-prone. I did one or two of those as a trial, and it is more problematic than anything.</p> <p>An LLM is also not intelligent, notwithstanding the popular term of "Artificial Intelligence". On multiple occasions, I've asked it to write a test case for some code that was not set up to do so; and rather than suggesting a refactor is required, it would instead <em>copy</em> the code that needed to be tested and then test the copy, rather than the original. The tool has made multiple similar errors. I have sometimes people describe agentic coding as "similar to interacting with junior programmers", but that is not the case. A junior programmer will either fill in the gaps in your specifications, or ask for clarification when something seems off. The LLM will not do that; it will do what you ask, exactly that and nothing more. If you missed a corner case in your specification, then all bets are off.</p> <p>I remember learning about programming language generations in college. A first-generation language is "machine code", a second-generation language is "assembler", a third-generation language is any high-level language such as C, Perl, or Pascal. I've forgotten what set a 3rd-generation language apart from a 4th-generation language. But I remember the definition they gave me for a 5th-generation language: "you tell the computer what to do, and it will do it". At the time, I thought it was ridiculous. Nobody could ever write something like that.</p> <p>But it's here.</p> <p>And it's a threat to free software.</p> <h2 id="athreattofreesoftware">A threat to free software?</h2> <p>Yes.</p> <p>There is the obvious part where most of the well-known LLMs are non-free software. I mean, <a href="https://www.geeksforgeeks.org/artificial-intelligence/top-10-open-source-llm-models/">there are</a> some "open source" LLM models. The windsurf tool that I used doesn't allow you to use them (directly), but they're there. There are also <a href="https://opencode.ai/">open source applications</a> that implement what the windsurf editor does. So it's definitely possible to work like this without resorting to non-free software and non-free services, even though the non-free LLMs might be a bit ahead of the curve of the free ones. But that's not what I mean.</p> <p>And there is also the obvious thing which I mentioned earlier in this post, which is that the people who try to build LLMs are doing it in unethical, disgusting ways, causing downtimes and disregarding licenses for whatever they can get their grubby hands on. Ideally we wouldn't be in that situation, and ideally this wouldn't be a problem, but we are where we are.</p> <p>And there's the obvious thing where the OSI sold itself out and declared that a machine learning program can be open source even when the very things it was built from -- the training data -- is not available. That's a major issue that the free software community needs to fight against, but there's not really anything that that is a threat to free software. You just build your own, free software, LLM, and you're done.</p> <p>The actual threat is in funding and developer support.</p> <p>Most large businesses do not care about free-as-in-freedom software. They like the free-as-in-beer part, and they appreciate that the free-as-in-freedom bits can make the software more customizable. They are (mostly) happy to do sponsorships of the free-as-in-freedom projects that they use if that means their free-as-in-beer usage of the software gets improved.</p> <p>But why would you care about all that when you can just <em>generate</em> the code you need, rather than interacting with an open source community that may or may not care about your business's interests?</p> <h2 id="wheretogofromhere">Where to go from here</h2> <p>Although I think the moral and environmental issues with LLMs are real and problematic, given the experiments I did I am not convinced that the <em>concept</em> of interacting with a computer system in natural language and to use it to generate code is necessarily deficient. There are pitfalls, but they can be managed. It is possible to use such a system to create throwaway, proof-of-concept type "good enough" code bases. It can be used to interpret code bases and to understand bug reports.</p> <p>I believe that the major issue with LLMs has to do with that saying about hammers and nails:</p> <blockquote> <p>If all you have is a hammer, then everything looks like a nail.</p> </blockquote> <p>LLMs are an outgrowth of machine learning, pushed by large corporations. These large corporations have a lot of money. If all you have is money, then every problem can be fixed by throwing more money at it. The initial language models were promising but not (yet) good enough, and it seemed that one way in which they could be improved was to increase the scale of the statistics: throw more hardware (and thus money) at it, and rather than improving the efficiency of the models, just scale up.</p> <p>Scaling up is something that megacorporations are very good at. It's only a money problem, after all. Does that mean that "scaling up" is the only way to improve the models, though? I'm not convinced.</p> <p>Some hardware, such as most modern Apple and Samsung devices, ship with accelerator hardware for machine learning algorithms. There are some models that are small enough to be able to run on these devices. I don't see why it should not be possible to create a small(er) language model that can do some useful part of the above-described use cases; if not locally, then at least on a server that one can run on-prem rather than requiring that you pay rent to one of the LLM companies.</p> <p>The <a href="https://sfconservancy.org">Software Freedom Conservancy</a> has published an <a href="https://sfconservancy.org/news/2024/oct/25/aspirational-on-llm-generative-ai-programming/">aspirational statement on machine learning-assisted programming</a> that, I think, gets a lot right. It's not quite a definition, but it's something to keep in mind.</p> <p>Perhaps that's the way forward?</p> <p>More questions than answers at this point, anyway.</p> Fri, 19 Jun 2026 12:09:21 +0000 https://www.freexian.com/blog/debian-lts-report-2026-05/ https://www.freexian.com/blog/debian-lts-report-2026-05/ <img src="http://planet.debian.org/heads/freexian.png" width="215" height="101" alt="" align="right" style="float: right;"> <img src="https://www.freexian.com/images/debian-lts-logo.png" style="float: right;" /> <p>The Debian LTS Team, funded by <a href="https://www.freexian.com/lts/debian/">Freexian’s Debian LTS offering</a>, is pleased to report its activities for May.</p> <h3 id="activity-summary">Activity summary</h3> <p>During the month of May, 21 contributors have been paid to work on <a href="https://wiki.debian.org/LTS">Debian LTS</a> (links to individual contributor reports are located below).</p> <p>The team released <a href="https://lists.debian.org/debian-lts-announce/2026/05/threads.html">56 DLAs</a> fixing 877 CVEs.</p> <p>May was a much busier month than usual, especially due to the disclosed vulnerabilities on linux regarding Local Privilege Escalation (LPE), that included public proof-of-concept (PoC) exploits. These reports of course impacted Debian as a whole, and the situation warrants a special mention to the Kernel Team, especially Ben Hutching and Salvatore Bonaccorso, who faced the pace and released linux packages on a weekly basis. On the LTS side, the Front Desk team also <a href="https://lists.debian.org/debian-lts/2026/06/msg00002.html">triaged a significant flow of high severity CVEs</a>.</p> <p>It is also important to note that <a href="https://www.debian.org/releases/bookworm/">Debian 12 (“bookworm”)</a> will be handed over to the LTS Team on June 11th. If you benefit from Debian, especially during the full 5-year lifecycle, please consider subscribing as a sponsor of Debian LTS: <a href="https://www.freexian.com/lts/debian/">https://www.freexian.com/lts/debian/</a>.</p> <p>Moreover, Debian 11 (“bullseye”) will reach the end of the Debian LTS period on August 31st. After that, Freexian will continue the security support under the <a href="https://www.freexian.com/lts/extended/">Extended LTS</a> offer.</p> <p>The team published several notable updates:</p> <ul> <li>As mentioned above, several exploitable LPE vulnerabilities in linux were published during May. Ben released the following DLAs for the Debian LTS versions: <ul> <li><a href="https://lists.debian.org/afW4eRFSiyEj0t5p@decadent.org.uk">DLA 4560-1</a> for linux (5.10)</li> <li><a href="https://lists.debian.org/afW4k69tKf_WlndL@decadent.org.uk">DLA 4561-1</a> for linux-6.1</li> <li><a href="https://lists.debian.org/af4wE6d14Ow7_e1z@decadent.org.uk">DLA 4572-1</a> for linux (5.10)</li> <li><a href="https://lists.debian.org/af9UZejc2VrICvbM@decadent.org.uk">DLA 4574-1</a> for linux-6.1</li> <li><a href="https://lists.debian.org/aghQTI2_ePQTfgRl@decadent.org.uk">DLA 4587-1</a> for linux (5.10)</li> <li><a href="https://lists.debian.org/agxj_abMk4ZO7rTj@decadent.org.uk">DLA 4588-1</a> for linux-6.1</li> <li><a href="https://lists.debian.org/ahnAg039hP_NAYQZ@decadent.org.uk">DLA 4606-1</a> for linux (5.10)</li> <li><a href="https://lists.debian.org/ahnBQfl3R3-CGOJ0@decadent.org.uk">DLA 4607-1</a> for linux-6.1</li> </ul> </li> <li>exim update (<a href="https://security-tracker.debian.org/tracker/DLA-4580-1">DLA-4580-1</a>), prepared by Thorsten, to address a vulnerability that may result in remote code execution.</li> <li>gnutls28 update (<a href="https://security-tracker.debian.org/tracker/DLA-4595-1">DLA-4595-1</a>) by Guilhem Moulin, fixes several vulnerabilities that may result in execution of arbitrary code, information leak, authentication bypass, among other impacts.</li> <li>krb5 updates released as <a href="https://security-tracker.debian.org/tracker/DLA-4603-1">DLA-4603-1</a>, fixing two vulnerabilities that may yield to a denial of service. Updated prepared by Emmanuel Arias</li> <li>lemonldap-ng (<a href="https://security-tracker.debian.org/tracker/DLA-4602-1">DLA-4602-1</a>), released by Abhijith PA, fixing multiple vulnerabilities</li> <li>Two imagemagick updates (<a href="https://security-tracker.debian.org/tracker/DLA-4559-1">DLA-4559-1</a> and <a href="https://security-tracker.debian.org/tracker/DLA-4609-1">DLA-4609-1</a>), prepared by Bastien Roucariès, fixing several vulnerabilities</li> <li>openjdk-11 and openjdk-17 updates (<a href="https://security-tracker.debian.org/tracker/DLA-4566-1">DLA-4566-1</a> and <a href="https://security-tracker.debian.org/tracker/DLA-4565-1">DLA-4565-1</a>), both prepared by Emilio, to fix seven vulnerabilities.</li> <li>php7.4 update (<a href="https://security-tracker.debian.org/tracker/DLA-4586-1">DLA-4586-1</a>) to fix six vulnerabilities that could result in remote code execution, information disclosure or denial of service. Update prepared by Guilhem Moulin.</li> <li>python3.9 update (<a href="https://security-tracker.debian.org/tracker/DLA-4583-1">DLA-4583-1</a>), prepared by Arnaud Rebillout, addressing multiple vulnerabilities.</li> </ul> <p>Contributions from outside the LTS Team:</p> <p>We are greatly thankful for the contributions from people outside the LTS Team:</p> <ul> <li>Colin Watson prepared an OpenSSH update, that was released by Santiago as <a href="https://security-tracker.debian.org/tracker/DLA-4584-1">DLA-4584-1</a>.</li> <li>Thomas Goirand handled a keystone update, whose advisory was done by Santiago and released as <a href="https://security-tracker.debian.org/tracker/DLA-4611-1">DLA-4611-1</a>.</li> <li>Christopher Obbard kindly prepared a sentry-python update, released as <a href="https://security-tracker.debian.org/tracker/DLA-4612-1">DLA-4612-1</a>.</li> <li>Christoph Goehre made two thunderbird updates (<a href="https://security-tracker.debian.org/tracker/DLA-4562-1">DLA-4562-1</a> and <a href="https://security-tracker.debian.org/tracker/DLA-4582-1">DLA-4582-1</a>). As is customary, Emilio released the advisories.</li> </ul> <p>The LTS Team has also contributed with updates to the latest Debian releases:</p> <ul> <li>Andreas proposed a <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1137166">firewalld update</a> for bookworm to fix a local issue that may result in bypass control rules.</li> <li>Andreas proposed <a href="https://lists.debian.org/debian-mate/2026/05/msg00007.html">atril updates</a> for trixie and bookworm.</li> <li>Arnaud did a <a href="https://bugs.debian.org/1136382">python3.11 upload</a> for bookworm.</li> <li>Arnaud proposed libarchive updates for <a href="https://bugs.debian.org/1135713">trixie</a> and <a href="https://bugs.debian.org/1135715">bookworm</a>.</li> <li>Arnaud completed the <a href="https://tracker.debian.org/news/1748276/accepted-systemd-25239-1deb12u2-source-into-oldstable-proposed-updates/">systemd update</a> for bookworm.</li> <li>Bastien completed the uploads of <a href="https://tracker.debian.org/news/1747981/accepted-gpsd-322-41deb12u1-source-into-oldstable-proposed-updates/">gpsd</a> for bookworm. He also did an upload of <a href="https://tracker.debian.org/news/1747976/accepted-apache2-2466-1deb12u2-source-into-oldstable-proposed-updates/">apache2</a> for bookworm.</li> <li>Emmanuel uploaded updates of libexif for <a href="https://tracker.debian.org/news/1750516/accepted-libexif-0625-1deb13u1-source-into-proposed-updates/">trixie</a> and <a href="https://tracker.debian.org/news/1750521/accepted-libexif-0624-1deb12u1-source-into-oldstable-proposed-updates/">bookworm</a></li> <li>Jochen Sprickerhof prepared pyjwt update for <a href="https://tracker.debian.org/news/1750541/accepted-pyjwt-2101-2deb13u1-source-into-stable-security/">trixie</a> and <a href="https://tracker.debian.org/news/1750540/accepted-pyjwt-260-1deb12u1-source-into-oldstable-security/">bookworm</a>, released as <a href="https://security-tracker.debian.org/tracker/DSA-6259-1">DSA-6259-1</a>.</li> <li>Lukas Märdian prepared <a href="https://tracker.debian.org/news/1752293/accepted-nghttp2-1640-11deb13u1-source-into-stable-security/">trixie</a> and <a href="https://tracker.debian.org/news/1752294/accepted-nghttp2-1520-1deb12u3-source-into-oldstable-security/">bookworm</a> updates for nghttp2, released as <a href="https://security-tracker.debian.org/tracker/DSA-6266-1">DSA-6266-1</a>.</li> <li>Markus prepared updates of tomcat11 and tomcat10, released as <a href="https://security-tracker.debian.org/tracker/DSA-6329-1">DSA-6329-1</a> (for trixie) and <a href="https://security-tracker.debian.org/tracker/DSA-6328-1">DSA-6328-1</a> (for trixie and bookworm), respectively.</li> <li>Continuing the work <a href="https://lists.debian.org/debian-lts/2026/06/msg00002.html">to replace the unmaintained p7zip fork with 7zip</a>, Sylvain prepared <a href="https://tracker.debian.org/news/1748309/accepted-7zip-2501dfsg-1deb13u2-source-into-proposed-updates/">trixie</a> and <a href="https://tracker.debian.org/news/1748244/accepted-7zip-2201really2501dfsg-0deb12u1-source-into-oldstable-proposed-updates/">bookworm</a> updates of 7zip.</li> <li>Thorsten completed the uploads of zvbi, taglib and libuev to bookworm and did an upload of libcoap3 for <a href="https://tracker.debian.org/news/1748400/accepted-libcoap3-434-11deb13u3-source-into-proposed-updates/">wtrixie</a>.</li> <li>Tobi prepared libpng1.6 updates for trixie and bookworm, released as <a href="https://security-tracker.debian.org/tracker/DSA-6263-1">DSA-6263-1</a>.</li> </ul> <p>Moreover, thanks to <a href="https://www.freexian.com/blog/samba-4.17-lts/">our partnership with Catalyst</a>, it has been possible to extend the support for Samba 4.17, the version shipped with Debian 12. In May, several vulnerabilities were disclosed, and their patches were prepared by Catalyst. For Debian 12, the update was prepared by the Samba maintainer and released as <a href="https://security-tracker.debian.org/tracker/DSA-6297-1">DSA-6297-1</a>.</p> <h3 id="individual-debian-lts-contributor-reports">Individual Debian LTS contributor reports</h3> <ul> <li><a href="https://people.debian.org/~abhijith/reports/LTS_ELTS-May-2026.txt">Abhijith PA</a></li> <li><a href="https://lists.debian.org/debian-lts/2026/05/msg00035.html">Andreas Henriksson</a></li> <li><a href="https://lists.debian.org/msgid-search/90a01206-0228-47a1-99ac-230f39627cdd@app.fastmail.com">Andrej Shadura</a></li> <li><a href="https://lists.debian.org/debian-lts/2026/06/msg00001.html">Arnaud Rebillout</a></li> <li><a href="https://lists.debian.org/debian-lts/2026/06/msg00004.html">Bastien Roucariès</a></li> <li><a href="https://www.decadent.org.uk/ben/blog/2026/06/02/foss-activity-in-may-2026.html">Ben Hutchings</a></li> <li><a href="https://lists.debian.org/msgid-search/ah946uN_ihFpn6Y2@fw13.lan">Carlos Henrique Lima Melara</a></li> <li><a href="https://chris-lamb.co.uk/posts/free-software-activities-in-may-2026#debian-lts">Chris Lamb</a></li> <li><a href="https://lists.debian.org/debian-lts/2026/06/msg00005.html">Daniel Leidert</a></li> <li><a href="https://lists.debian.org/debian-lts/2026/05/msg00038.html">Emmanuel Arias</a></li> <li><a href="https://people.debian.org/~pochu/lts/reports/2026-05.txt">Emilio Pozuelo Monfort</a></li> <li><a href="https://lists.debian.org/msgid-search/?m=z6X4k41ZLH1m3ekg@debian.org">Guilhem Moulin</a></li> <li><a href="https://lists.debian.org/msgid-search/ah60k47SnxpQjRrq@mpd">Jochen Sprickerhof</a></li> <li><a href="https://lists.debian.org/debian-lts/2026/06/msg00013.html">Lee Garrett</a></li> <li><a href="https://people.debian.org/~kanashiro/debian/lts/reports/2026-05.txt">Lucas Kanashiro</a></li> <li><a href="https://people.debian.org/~slyon/debian/lts/reports/2026-05.txt">Lukas Märdian</a></li> <li><a href="https://dl.gambaru.de/blog/202605_LTS_ELTS_report.txt">Markus Koschany</a></li> <li><a href="https://people.debian.org/~santiago/lts-elts-reports/report-2026-05.txt">Santiago Ruano Rincón</a></li> <li><a href="https://lists.debian.org/debian-lts/2026/06/msg00002.html">Sylvain Beucler</a></li> <li><a href="https://blog.alteholz.eu/2026/06/my-debian-activities-in-may-2026/">Thorsten Alteholz</a></li> <li><a href="https://lists.debian.org/debian-lts/2026/06/msg00015.html">Tobias Frost</a></li> </ul> <h3 id="thanks-to-our-sponsors">Thanks to our sponsors</h3> <p>Sponsors that joined recently are in bold.</p> <ul> <li>Platinum sponsors: <ul> <li><a href="https://www.global.toshiba/ww/top.html">Toshiba Corporation</a> (for 128 months)</li> <li><a href="https://cip-project.org">Civil Infrastructure Platform (CIP)</a> (for 96 months)</li> <li><a href="https://vyos.io">VyOS Inc</a> (for 61 months)</li> </ul> </li> <li>Gold sponsors: <ul> <li><a href="https://www.roche.com/about/business/diagnostics.htm">F. Hoffmann-La Roche AG</a> (for 139 months)</li> <li><a href="https://www.conet.de/">CONET Deutschland GmbH</a> (for 122 months)</li> <li><a href="http://www.ox.ac.uk">University of Oxford</a> (for 78 months)</li> <li><a href="https://www.edf.fr">EDF SA</a> (for 50 months)</li> <li><a href="https://www.dataport.de">Dataport AöR</a> (for 25 months)</li> <li><a href="https://home.cern/">CERN</a> (for 23 months)</li> </ul> </li> <li>Silver sponsors: <ul> <li><a href="https://domainnameshop.com/">Domeneshop AS</a> (for 143 months)</li> <li><a href="https://metropole.nantes.fr/">Nantes Métropole</a> (for 137 months)</li> <li><a href="https://www.akamai.com/">Akamai - Linode</a> (for 133 months)</li> <li><a href="http://www.univention.de">Univention GmbH</a> (for 129 months)</li> <li><a href="http://portail.univ-st-etienne.fr/">Université Jean Monnet de St Etienne</a> (for 129 months)</li> <li><a href="https://ribboncommunications.com/">Ribbon Communications, Inc.</a> (for 123 months)</li> <li><a href="https://www.exonet.nl">Exonet B.V.</a> (for 113 months)</li> <li><a href="https://www.lrz.de">Leibniz Rechenzentrum</a> (for 107 months)</li> <li><a href="https://www.diplomatie.gouv.fr">Ministère de l’Europe et des Affaires Étrangères</a> (for 91 months)</li> <li><a href="https://dinahosting.com">Dinahosting SL</a> (for 78 months)</li> <li><a href="https://upsun.com">Upsun Formerly Platform.sh</a> (for 72 months)</li> <li><a href="https://www.moxa.com">Moxa Inc.</a> (for 66 months)</li> <li><a href="https://sipgate.de">sipgate GmbH</a> (for 64 months)</li> <li><a href="https://ovhcloud.com">OVH US LLC</a> (for 62 months)</li> <li><a href="https://www.tilburguniversity.edu/">Tilburg University</a> (for 62 months)</li> <li><a href="https://www.gsi.de">GSI Helmholtzzentrum für Schwerionenforschung GmbH</a> (for 53 months)</li> <li><a href="https://www.cesky-hosting.cz/">THINline s.r.o.</a> (for 26 months)</li> <li><a href="https://www.cph.dk">Copenhagen Airports A/S</a> (for 20 months)</li> <li><a href="https://www.isere.fr">Conseil Départemental de l’Isère</a> (for 6 months)</li> </ul> </li> <li>Bronze sponsors: <ul> <li><a href="http://www.seznam.cz">Seznam.cz, a.s.</a> (for 144 months)</li> <li><a href="http://www.evolix.fr">Evolix</a> (for 143 months)</li> <li><a href="http://linuxhotel.de">Linuxhotel GmbH</a> (for 141 months)</li> <li><a href="http://intevation.de">Intevation GmbH</a> (for 140 months)</li> <li><a href="https://waays.fr">Daevel SARL</a> (for 139 months)</li> <li><a href="http://www.megaspace.de">Megaspace Internet Services GmbH</a> (for 138 months)</li> <li><a href="http://www.greenbone.net">Greenbone AG</a> (for 137 months)</li> <li><a href="http://numlog.fr">NUMLOG</a> (for 137 months)</li> <li><a href="http://www.wingo.ch/">WinGo AG</a> (for 136 months)</li> <li><a href="https://www.entrouvert.com/">Entr’ouvert</a> (for 128 months)</li> <li><a href="https://adfinis.com">Adfinis AG</a> (for 125 months)</li> <li><a href="https://www.plathome.com">Plat’Home</a> (for 122 months)</li> <li><a href="http://www.legi.grenoble-inp.fr">Laboratoire LEGI - UMR 5519 / CNRS</a> (for 120 months)</li> <li><a href="https://www.tesorion.nl/">Tesorion</a> (for 120 months)</li> <li><a href="http://bearstech.com">Bearstech</a> (for 111 months)</li> <li><a href="http://lihas.de">LiHAS</a> (for 111 months)</li> <li><a href="http://www.catalyst.net.nz">Catalyst IT Ltd</a> (for 106 months)</li> <li><a href="https://demarcq.net">Demarcq SAS</a> (for 100 months)</li> <li><a href="https://www.univ-grenoble-alpes.fr">Université Grenoble Alpes</a> (for 86 months)</li> <li><a href="https://www.touchweb.fr">TouchWeb SAS</a> (for 78 months)</li> <li><a href="https://www.spin-ag.de">SPiN AG</a> (for 75 months)</li> <li><a href="https://www.corefiling.com">CoreFiling</a> (for 71 months)</li> <li><a href="https://www.osug.fr/">Observatoire des Sciences de l’Univers de Grenoble</a> (for 62 months)</li> <li><a href="https://www.werfen.com">Tem Innovations GmbH</a> (for 57 months)</li> <li><a href="https://wordfinder.pro">WordFinder.pro</a> (for 57 months)</li> <li><a href="https://www.resif.fr">CNRS DT INSU Résif</a> (for 56 months)</li> <li><a href="https://www.soliton.co.jp">Soliton Systems K.K.</a> (for 51 months)</li> <li><a href="https://www.alterway.fr">Alter Way</a> (for 48 months)</li> <li><a href="http://www.sobis.com/">SOBIS Software GmbH</a> (for 23 months)</li> <li><a href="https://www.tuxera.com">Tuxera Inc.</a> (for 15 months)</li> <li><a href="https://opm-op.com">OPM-OP AS</a> (for 6 months)</li> </ul> </li> </ul> Fri, 19 Jun 2026 00:00:00 +0000 https://diffoscope.org/news/diffoscope-321-released/ https://diffoscope.org/news/diffoscope-321-released/ <p>The diffoscope maintainers are pleased to announce the release of diffoscope version <code class="language-plaintext highlighter-rouge">321</code>. This version includes the following changes:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>[ Chris Lamb ] * Fix compatibility with Ocaml 5.4.1. </code></pre></div></div> <p>You find out more by <a href="https://diffoscope.org">visiting the project homepage</a>.</p> Fri, 19 Jun 2026 00:00:00 +0000