Search Results: "ag"

1 July 2026

Ben Hutchings: FOSS activity in June 2026

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. 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. 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.

30 June 2026

Dirk Eddelbuettel: tl 0.0.2 on CRAN: First Update

The still-very-new logging package tl was just updated for the first time at CRAN. The tl package wraps the (also very new) rspdlite package to offer a lightweight and consistent logging interface from both R and C++ that enjoys being tiny, fast, capable thanks to spdlite. With tl we follow the same idea that our spdl package introduced: a simple consistent interface via just the tl:: prefix and the appropropriate logging level. In other words tl::debug("Alert: foo now ' '", foo) will work from both R and C++ (given a variable foo, and, in the case of C++, an extra semicolon) and log if the current level is debug or higher, and skip logging if not. 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 tl to an example package as a simple illustration, more on that hopefully soon. The NEWS entry for this release follows.

Changes in version 0.0.2 (2025-06-30)
  • Added badges to README now that package is on CRAN, add NEWS file
  • Condition the provided header on C++20 use, offer fallback
  • Add an exported initialization function picking up a logging level from either an environment variable or a global option, see '?init'

Courtesy of my CRANberries, there is also a diffstat report for the this release.

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

Joey Hess: big loads offgrid with a small battery (sidelined)

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. In Australia, everyone gets 24 kwh of free daytime electric power now. 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. In Germany, a 2 kwh plug-in home battery costs $350 and the electric company will pay you $130 per year to plug it into your wall. There are similar offers throughout Europe. In Cuba something something geopolitics, oil blockade, belt and road => suddenly 1GW of solar farms with another gigawatt on the way. 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. 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. 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. 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. 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. 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:
    -- When the battery is charged enough to run major loads that may prevent
    -- charging it further.
    --
    -- This varies with the hour of day. Early in the day, the battery does not
    -- need to be as full to be considered well charged, since there is
    -- still plenty of time for it to charge up. Later in the day, with less
    -- time to charge, it needs to be more full.
    wellCharged :: Hour -> Percentage
    wellCharged (Hour hour)
              hour < 9 = Percentage 90 -- night
              pmhour <= 0 = Percentage 50
              pmhour <= 1 = Percentage 60
              pmhour <= 2 = Percentage 70
              pmhour <= 3 = Percentage 80
              pmhour <= 4 = Percentage 90
              otherwise = Percentage 95
      where
            pmhour = hour - 12
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. 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. 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 wellCharged 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. 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. 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. 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". 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.
[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.

Russell Coker: Links June 2026

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]. Cory Doctorow wrote an insightful article for Locus Magazine about corporate valuations and why companies claim SciFi technologies [2]. Charles Stross wrote an interesting retcon of James Bond [3]. Trakkr.ai has an intresting post comparing political bias in LLM models, the site has lots of other comparisons of models too [4]. 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]. Here is the git repository for the programs used for the ssh-audit.com site, really good setup for checking ssh configuration [6]. 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]. Elvira Bary wrote an informative article about Russia s inability to build or design anything good [8]. Looks like we are at risk of another Chernobyl Lev Lafayette wrote an interesting blog post about the Sunway TaihuLight supercomputer with over 10,000,000 cores [9]. 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].

Russell Coker: Dirty Clone and SE Linux

There is a new Linux kernel exploit out named Dirty Clone [1]. The first thing to do to exploit this is to create a container with a separate network namespace via one of the following commands:
unshare -Urn
bwrap --bind / / --unshare-user --unshare-net --uid 0 --gid 0 /bin/bash
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. 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:
# ip link set lo up
RTNETLINK answers: Operation not permitted
That will give an entry in /var/log/audit/audit.log like the following:
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
Unlike previous exploits like Pintheft [2] 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. Now on a system with the unconfined module removed (as described in the SE Linux Protection part of my post about Copy Fail [3]) the following domains have such access:
# 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  ;
Conclusion 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. 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. 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. The increasing use of containers by applications is only going to make this problem worse. I think that what we need is something like Flatpak 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.

Utkarsh Gupta: FOSS Activities in June 2026

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

Debian
Whilst I didn t get a chance to do much, here are still a few things that I worked on:
  • Leading the DebConf Bursary team along with PEB.
    • This took most of my Debian time this month but we ve been able to wrap that work now.
    • Got back to all the tickets on Zammad, too.
  • Assisted a few folks in getting their patches submitted via Salsa.
  • Mentoring for newcomers.
  • Moderation of -project mailing list.

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

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

Released Security Updates

Work in Progress

Other Activities
  • [LTS] Emilio pointed out that the gst-plugins-ugly1.0 binaries were still not fully released, so I ran dcut migrate to fully release them. The DLA had gone out earlier.
  • [ELTS] Did some more work on ruby-rack - a lot of new CVEs have opened up and, whilst I made some progress, Santiago let me know that ruby-rack is no longer supported and so it ll be removed from the ela-needed list.
  • [E/LTS] Set up the security-tracker and a few other things on the new machine, and debugged the git repository size madness. Sent a summary here.
  • [E/LTS] Monitored discussions on mailing lists, IRC, and all the documentation updates.
  • [E/LTS] Attended the monthly LTS meeting on Jitsi. Meeting notes here.

Until next time.
:wq for today.

Reproducible Builds (diffoscope): diffoscope 323 released

The diffoscope maintainers are pleased to announce the release of diffoscope version 323. This version includes the following changes:
[ 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 >= 4.006.
You find out more by visiting the project homepage.

28 June 2026

Russell Coker: Plaud

While watching a YouTube video I saw an advert for the Plaud AI Note Taker [1]. 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 Humane AI Pin I previously blogged about [2]. 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. 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. 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. 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. 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.

Russell Coker: Some GPU Stuff

After getting a HP Z4 G4 tower server/workstation to house my Intel Battlemage GPU [1] I ve been playing around with some GPU stuff. For years I ve been just buying GPUs based on the resolution and price and not bothering about anything else due to lack of ability to measure what cards are doing. The nvidia-smi program is really good for NVidia/CUDA setups but I hadn t been aware of anything similar for AMD cards. As I prefer AMD cards for my workstations due to driver issues with NVidia that was a problem for me. I ve recently discovered that the program nvtop (Debian package nvtop) shows the GPU use of multiple GPU types, for me it s worked on AMD and Intel discrete GPUs and shows some information on Intel integrated GPUs, I don t have others convenient for testing at the moment. Currently BOINC has the Einstein@Home [2] project running on the HP Z4 G4 and it s using between 66% and 100% of GPU compute power and 1.6G of GPU RAM. Using 100% GPU compute power allegedly takes 62W of power out of the 190W quoted TDP. I presume that the power use reported by nvtop is very inaccurate. A friend installed a LLM on that system and the libraries used for the LLM were sufficient that BOINC just started using the GPU. On my workstation running an AMD [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (actually R560) with 4G of GPU RAM I have mpv taking 1G of GPU RAM to play a FullHD video expanded to a full screen window on my 5120*2160 display. I also have about 2G used by the kwin_wayland process (the Wayland server for KDE). That doesn t leave enough GPU RAM to allow Einstein@Home to use the GPU. When playing the FullHD video in question (which is 1.2G for 42 minutes about 500KB/s) at 1.5* speed (a common playback speed I use) that takes about 30% of the compute power on my GPU. I had installed the rocm-opencl-icd package on my workstation (with a 5120*2160 monitor) and restarted boinc-client.service which is all that s needed to allow BOINC to use an AMD GPU. Then the screen started flickering as the Einstein process repeatedly core dumped which I initially assumed to be it s reaction to not having enough GPU RAM available. On every core dump the screen flickered so it went through a process of dozens of screen flickers until it had caused a sufficient number of core dumps and BOINC gave up running that job. Another annoyance is that the boincmgr program (the graphical program for managing BOINC systems) launches two webkit processes that each use about 400M of GPU RAM, so even if other things weren t using all my GPU RAM the boincmgr process would stop the BOINC jobs from using the GPU. I shut down some of the programs that were using GPU RAM until there was 2G free and the BOINC process kept crashing so it seems that there is some other issue. On another system with a 4K monitor there were Chrome and Chromium GPU process taking 1.1G and 500M of GPU RAM respectively and the KWin Wayland process was taking 1G of GPU RAM. So that s well over half the GPU RAM for just browsers and Wayland. With programs like Kitty (terminal emulator) and Nheko (Matrix client) taking over 100M of GPU RAM it seems that 4G is the bare minimum for GPU RAM with modern software and a 4K or similar display. I also noticed the kscreenlocker_greet process taking 440M of GPU RAM. I wonder if a hostile web server could make a web browser take more GPU RAM and starve the screenlocker of GPU RAM, could that allow forcing a screen lock operation to fail? It seems that 4G is the minimum for modern systems, which isn t necessarily a problem as GPUs that are capable of driving 4K displays tend to have no less than 4G. My local computer store has new GPUs with 4G starting at $120 but 12G seems to be the next option up which starts at about $400. Ebay currently has a selection of AMD GPUs with 8G of RAM under $200. I ve had some problems with the GPU in my workstation crashing as described in my previous post where I thought it was driver issues [3]. I now believe that there are hardware issues and will look into buying one of the cards with 8G. Further Investigation I need to determine which of the AMD GPUs that are currently going cheap on ebay are best. While my current PC has support for 150W PCIe power I d rather something less power hungry than that. I have occasional issues of mpv reporting that my system is too slow for a video so slightly more compute power on the GPU would be good, but I think that every available option has significantly more compute power. I need to find out what the relationship is between screen resolution and GPU memory. If I get an 8K display or an array of 4*4K displays (which is quite plausible as 27 4K displays go for $230 each) will I find 16G of GPU RAM as limiting as I find 4G now? The nvtop program tracks PCIe data transfers for AMD GPUs, I haven t yet seen more than 25MB/s and I need to do more tests to see what the maximum is. Running on an Intel Battlemage card nvtop doesn t report PCIe data transfer speed which is a missing feature in either the driver or the program. I need to find out where the problem is and report a bug if someone hasn t already done so. The GPU RAM use of some applications seems excessive. 440M for a lockscreen? 100M+ for a terminal emulator? 320M for Thunderbird?

27 June 2026

Steve McIntyre: It's dead, Jim!

I previously wrote about the upcoming UEFI CA rollover. Well, it's happened now - the old Microsoft UEFI CA from 2011 expired yesterday: Third Party Marketplace Root (used for signing option ROMs and other software)
  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
It's dead - it's not coming back... The world doesn't seem to have ended yesterday, so I guess we did ok? :-) How did we do? 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 here 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. 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. 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. What's next? We already have one 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 fwupd in both those point releases, to make DB and KEK updates work better. For more information about these updates, see https://wiki.debian.org/SecureBoot/CAChanges. For your own safety, validate that your systems are updated when possible. If you don't, they may fail to boot in future.

Jonathan McDowell: onak 0.6.5 released

I had intended that the next release of onak, my OpenPGP keyserver, would be 0.7.0, and include OpenPGP v6 support (RFC9580). However events conspired to make a 0.6.5 release a really good idea. 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. I also enabled GitHub s security scanning. It mostly complained about format strings, and those were easy enough to fix up. Next I threw AFLplusplus at the code. I d previously tried American Fuzzy Lop, 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. valgrind is also a tool I ve used before, and rate highly. Thankfully it didn t find anything in my testing this time. Finally I threw a few more automated tests into the mix and discovered something has changed around dynamic linking such that the libonak 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. All in all this release is not my proudest moment; a bunch of the issues fixed should never have made it to a release. (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.) Available locally or via GitHub.
0.6.5 - 27th June 2026
  • Lots of fixes/improvements around length checking
  • Added extra basic tests for maxpaths/sixdegrees/CGI
  • Correctly end transactions in the stacked backend
  • Ensure the file backend avoids stale key data on updates
  • Fix decoding of v2/3 signature creation times
  • Fix EdDSA signature parsing when r < 249 bits long
  • Fix migration of bools from old to new config style
  • Fix parsing of new config details for DB parameters
  • Fix problems with linking + dynamic backends
  • Fix RSA-SHA2-384 signature checking
  • Fix sixdegrees parsing of keyids with high bit set
  • Handle failures in maxpath more gracefully
  • Make new style config path match old path

Russ Allbery: Review: The Folded Sky

Review: The Folded Sky, by Elizabeth Bear
Series: White Space #3
Publisher: Saga Press
Copyright: June 2025
ISBN: 1-6680-7812-0
Format: Kindle
Pages: 483
The Folded Sky is a far-future space opera and a fairly direct sequel to Ancestral Night, 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. 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 Ancestral Night. 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. 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. The Folded Sky 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. The book picks up considerably after the attempted murder. About a third of the way through, The Folded Sky 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. 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. 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 Ancestral Night, I finished this book thinking that The Folded Sky is primarily an examination of rightminding, but a more subtle one than the previous novel. 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 (James White 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. 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 Grail.) This book is not the argument for the technology, though; Bear dealt with that in Ancestral Night. This book is a look at its practical messiness for a person who needs a lot of psychological support. 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 Ancestral Night, 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. 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. 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. 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. I think The Folded Sky 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 Ancestral Night. 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. 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. Followed by a book tentatively titled Shipwreck Star that does not yet have a release date. Rating: 7 out of 10

26 June 2026

Jonathan Wiltshire: Streamlining Debian Updates with AI: The Stable Update Adviser

Please consider supporting my work in Debian and elsewhere through Liberapay.


Some months ago I started working on a small experiment: a specialised LLM assistant for Debian maintainers preparing proposed updates for stable and oldstable.

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.

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?

These are the sort of checks where a structured first pass can be useful, provided it is treated as advice rather than authority.

To explain what the tool does, what could be more appropriate in an AI age than to ask it?

Describe yourself and your abilities and limitations for a blog post.

It answers:

I m Debian Stable Update Adviser, a specialised ChatGPT assistant for Debian maintainers preparing proposed updates for Debian stable and oldstable.

My main job is to review a single .debdiff 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.

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 dpkg version semantics. I can review packaging changes under debian/, 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.

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.

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.

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.

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.

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.

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.

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.

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.

Try it out

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: Debian Stable Update Adviser

Russ Allbery: Review: Platform Decay

Review: Platform Decay, by Martha Wells
Series: Murderbot Diaries #8
Publisher: Tor
Copyright: 2026
ISBN: 1-250-82701-9
Format: Kindle
Pages: 245
Platform Decay 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. 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 System Collapse, not to mention the other times Preservation Station has upended corporate plans. Murderbot's job is to stop them. 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. 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. Also, well:
So I had installed a mental health module. I know, I was surprised I did it too.
After the events of System Collapse, University Medical decided that Murderbot needed a bit more metal health support.
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. (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.)
Speaking as someone whose neural tissue sometimes generates weird chemicals and whatever, I sympathize. The specific form this module takes is periodic "emotion check" parentheticals throughout the narration, which I found utterly delightful.
I ran that through risk assessment and it produced the equivalent of a shrug. (Emotion check: Shrug sigil right back at you, you piece of shit.)
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. 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. 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. Rating: 8 out of 10

Reproducible Builds (diffoscope): diffoscope 322 released

The diffoscope maintainers are pleased to announce the release of diffoscope version 322. This version includes the following changes:
[ Zbigniew J drzejewski-Szmek ]
* Add a local version of the (deprecated) os.path.commonprefix method.
You find out more by visiting the project homepage.

23 June 2026

Dirk Eddelbuettel: tl-0.0.1 on CRAN: New Package

A new small package of mine just hit CRAN. The tl package wraps the (also very new) rspdlite package (announced last week) to offer a lightweight and consistent logging interface from both R and C++ that is also tiny, fast, capable thanks to rspdlite. The rspdlite announcement is a good place to get a first glimpse at that package; the upstream spdlite repo has all the details (for the C++ side of things). With tl we follow the same idea that our spdl package introduced: a simple consistent interface via just the tl:: prefix and the appropropriate logging level. In other words tl::debug("Alert -- foo is at ' '", foo) will work from both R and C++ (given a variable foo, 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. The NEWS entry for this release is also very simple and just announces that we have a release. More details are in the ChangeLog and the GitHub repo.

Changes in version 0.0.1 (2025-06-17)
  • Initial CRAN upload

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

21 June 2026

Tim Retout: seL4 repo relationships

The seL4 organisation on GitHub uses git-repo to manage multiple source repositories, and so there are a large number of projects to get your head around when figuring out the ecosystem. As an experiment, I have taken the various manifest files across the org, and constructed a graph based on how frequently each pair of repositories is mentioned in a manifest together. See below: Graphviz Diagram [This may render badly when syndicated outside of my blog; and also on small screens. And probably large screens. I ve attempted to make sure there s a non-JS fallback on my site with JS enabled, if you hover over a node, it should highlight connected nodes.] The colouring of the nodes is mostly manual; I experimented with graph clustering algorithms but have not found a satisfactory result so far. Still, some clusters are obvious: It s quite hard to pull apart the CAmkES framework and the core libraries; there are definitely some which are more associated with VM management, but the overall shape of this co-occurence data is a messy ball in the middle with some outliers in orbit. One observation is that camkes is correctly identified as more peripheral than camkes-tool, which contains the actual core CAmkES code. Reflecting on this approach, in hindsight I m surprised that using co-occurences worked as well as it did there was no attempt to actually inspect the code and find direct mentions of other code e.g. library header dependencies. As the newer microkit effort largely eschews git-repo, better results might be found by actually taking that more detailed approach, so that graph edges could represent real dependencies between two packages. Additionally, this could allow diving into the various libraries held in the different libs repos, to get a more granular graph of relationships between them. However, I think I spent more time on making it possible to render graphviz graphs easily on my blog than actually gaining any insight into the codebase!

Dirk Eddelbuettel: RcppArmadillo 15.4.0-1 on CRAN: New Upstream Minor

armadillo image Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language and is widely used by (currently) 1282 other packages on CRAN, downloaded 47.1 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 697 times according to Google Scholar. This versions updates to the 15.4.0 upstream Armadillo release made on Thursday. We had run a complete reverse-dependency check leading up to it, asserting there were no issues with packages dependent on it. As it sometimes goes with that many packages involved, one CRAN package reported one test failure. And it turned out to be both unrelated and pre-existing. But sorting this out over one round of email delayed things by a day. And then I went cycling for a good cause so this announcement post comes a little later than usual. The package has also been updated for Debian, built for r2u, and by now also at CRAN for the different binary releases. All changes since the last CRAN release follow.

Changes in RcppArmadillo version 15.4.0-1 (2026-06-17)
  • Upgraded to Armadillo release 15.4.0 (Medium Roast Agave)
    • Added fill::nan, fill::pos_inf, fill::neg_inf as optional fill forms for the Mat class
    • Added .push_back() for appending elements to vectors
    • Faster handling of find() within .elem()
    • Faster element-wise min() and max()
    • Faster conv_to when element types of input and output objects are the same

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

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub. You can also sponsor my Tour de Shore 2026 ride in support of the Maywood Fine Arts Center.

Vasudev Kamath: Releasing debvulns: CLI for listing Debian vulnerabilities

Following up on my previous post, I have released the debvulns CLI. This utility uses the same parsing logic as the debsecan-mcp server but exposes the functionality directly via the command line.
Why a new CLI? While Debian's native debsecan 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. 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 debsecan-mcp, the MCP Inspector utility shows an overhead of roughly 150 tokens. 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.
What else is NEW? During testing, I observed discrepancies between the output of debsecan-mcp/debvulns and native debsecan. Debugging with an LLM revealed a bug in the version comparison logic that caused debvulns to underreport vulnerabilities. This has been resolved. The current interface supports structured formatting and customizable data backends:
usage: debvulns [-h] [-s  critical,high,medium,low,negligible ] [-f  json,csv ] [--sort-by  package,cve ] [--vuln-url VULN_URL] [--epss-url EPSS_URL] [--suite SUITE]
                [--cache-dir CACHE_DIR] [--no-cache] [-v]
debvulns - CLI Debian Vulnerabilities Tracker
options:
    -h, --help            show this help message and exit
    -s, --severity  critical,high,medium,low,negligible 
                          Filter vulnerabilities by severity
    -f, --format  json,csv 
                          Output format (default: json)
    -sort-by  package,cve 
                          Sort vulnerabilities by 'package' or 'cve'
    --vuln-url VULN_URL   Custom URL or local path for Debian Security Tracker data
    --epss-url EPSS_URL   Custom URL or local path for EPSS scores data
    --suite SUITE         Debian suite name (e.g. bookworm, sid). Auto-detected by default.
    --cache-dir CACHE_DIR
                          Directory to cache fetched and parsed data (default: /var/cache/debvulns)
    --no-cache            Do not use cached data, force downloading and parsing
    -v, --verbose         Enable verbose debug logging (sent to stderr)
By allowing users to override data sources with local snapshots of the Debian Security Tracker and EPSS feeds, debvulns can run natively in airgapped environments.
What Next? The next step is building a Prometheus exporter for this vulnerability data to streamline scanning and monitoring across data center infrastructure. Stay tuned.

20 June 2026

Russell Coker: HP Z4 G4

In what is hopefully the conclusion of my hunt for a cheap tower server supporting REBAR [1] I have just bought a HP Z4 G4 with W-2125 CPU for $320. Hardware One interesting thing is that it has an adaptor from SATA power to 8 pin PCIe power. According to Wikipedia the 8 pin connector provides 150W at 12V [2]. According to Wikipedia SATA power cables include 3 12V pins each of which can deliver 1.5A [3] which is 54W. The system as I received it had a single SATA power plug connected so potentially 150W could be drawn from a connector designed for 54W. The first thing I did was to connect a second SATA power connector on the same cable so I could have connectors designed for a total of 108W supplying potentially 150W (and definitely more than 75W). I found two versions of the specs for this system, this version seems to match what I bought as it references W-21xx CPUs [4] while this version matches what I would rather have with a W-22xx CPU [5]. The URL naming scheme implies that there are potentially at least a few other variants out there. So much for the buy name brand and you can buy two systems with the same model and have them work the same benefit you hope to get. Why don t they just name them G4.1 , G4.2 , etc? It seems that W-21xx and W-22xx CPUs are incompatible, so the W-2295 scoring 30,804 multithread and 2,634 single thread on passmark that I hoped to get isn t an option [6]. The system is well designed for space efficiency, both it and the Z640 are 17cm wide but the Z4G4 allows my to close the lid with the Intel Battlemage card installed which doesn t come close to fitting in a Z640. It has 8 DIMM sockets and with the ready availability of 32G DIMMS that allows 256G of RAM which is the maximum the motherboard supports. That compares well to the Z640 that only has 4 DIMM slots and the Z6G4 which only has 6. The system supports a maximum RAM speed of DDR4-2666 which is better than the DDR4-2400 of the Z640 but less than the DDR4-2933 of the Z6G4. The NVMe sockets on the motherboard are a convenient feature. Most systems I run need at most two NVMe devices so this saves a PCIe slot which is important when dealing with GPUs that take 2+ slots. Also for systems that don t really need NVMe I can use some of the small NVMe devices that I have no other use for. 128G NVMe devices aren t even worth selling and 256G will be of little use in the near future. So when I move to gen4 Z servers I can use up some of them without wasting slots. Using the lesser socket LGA2066 in the Z4G4 is a minor annoyance, but for a single socket system 18 cores is probably enough. The BIOS has an option for single-socket NUMA, which is basically locking cores in a single CPU to specific RAM channels. I enabled it but it did nothing presumably because I only have 2 DIMMs. When I get more DIMMs I ll do some tests of that and compare it with NUMA on my Z840. Variants There are many different variants of the Z4G4 and the only way to recognise them is by the CPU not by any part number or serial number AFAIK. The first difference is between server grade CPUs (the W-2xxx CPUs) and desktop grade CPUs (the i7 and i9 CPUs). The systems with i7 and i9 CPUs don t support ECC RAM which makes them less reliable, gives smaller limits for RAM The below table compares the Z640 which is my current desktop PC with the Z4G4, Z6G4, and Z8G4 systems. For the latter 3 I have included multiple options for the parts that differ in different models in the same name series. The Z4G4 I have is an early one which only supports W-21xx CPUs which means a maximum RAM speed of 2666 and the best possible CPU would only be 15% faster than my Z640. I can only use this for ML stuff as it s the only system I have with REBAR support (which works well).
Z640 (1 socket) Z4G4 Z6G4 (1 socket) Z8G4
DIMM slots 4 8 6 24
Max DDR4 speed 2400 2666/2933 2666/2933 2666/2933
Max DIMM size 32G 64G 64G 64G/128G
System Max Ram 128G 512G 192G/384G 1.5T/3T
CPU Socket LGA2011-3 LGA2066 LGA3647 LGA3647
Best CPU E5-2699A v4 W-2195/W-2295 Platinum 8180/W-3275 Platinum 8180/8280
Motherboard NVMe 0 2 2 ?
Conclusion In my previous blog post I concluded that the next step up for me would be DDR5 systems [10]. But now some of the LGA3647 systems are appealing. The Z8G4 would be a decent upgrade from my current Z840 build server and should be affordable long before any two socket DDR5 system becomes affordable. The Z4G4 doesn t have any potential for useful upgrades. But for me it was a good cheap way to house a GPU that had already damaged the motherboard of one good system. If the Z4G4 has a PCIe slot break the way my Z840 did then it wouldn t bother me a lot. It was annoying to discover how limited this variant of the Z4G4 is after buying it, but at that price I can t complain. A Z6G4 could be a nice workstation if I found one at a really low price. The only reason I d seek one out is if I had a need for a desktop workstation with REBAR support, which seems unlikely.

Next.

Previous.