2025-q4

Fri, 02 Jan 2026 07:07:00 +0100

Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd developments in Q4 of 2025! Details.

Joan Lledó worked on porting dhcpcd to the hurd. He also made some changes so that lwip would work with dhcpcd. In this message he writes:

This is the current state of the port:

Support only for IPv4. IPv6 not supported yet.

It works only over lwip. First, because dhcpcd requires some definitions from headers and pfinet doesn't provide them AFAIK, but lwip provide the headers through the liblwip-dev package. Second, because both pfinet and lwip need changes in the translator in order to be fully compatible with dhcpcd, and I made the changes in lwip since I know it better.

Only Ethernet is supported. This is because the Hurd doesn't define AF_LINK so dhcpcd can't get any data from the interface other thant what is returned by getifaddrs(). I'm manually providing the MAC address and hardcoding the interface type to Ethernet in the if_init function. I assume this is correct because the Hurd only supports ethernet interfaces AFAIK.

dhcpcd monitors the interfaces and gets notified when there are changes in routes or network configurations. This is not working yet for the Hurd.

dhcpcd implements some privilege separation by which the process spawns new processes that run as a non-privileged user. Or that's what I understood. It's not implemented for the Hurd because I've deferred this for now.

Access to BPF is provided by libpcap.

libpcap and liblwip-dev are dependencies for the Hurd.

This has been tested only in a 32-bit Hurd.

Damien Zammit worked on fixing some interrupt bugs in the acpi server.

He also made some fixes for rumpnet.

He also worked on adding a callwheel to GNU Mach's clock. This would make GNU Mach faster in certain ways. He writes:

Timeouts are now very fast to look up, at the expense of more memory, a much shorter list is traversed rather than all of them. See [1]. Timeouts that are stopped before expiry are now faster to remove, and inserting a timeout is faster. [1] https://doi.org/10.7936/K7VM49H5

Damien also made some progress on the SMP support for x86_64. He writes:

This allows gnumach to be compiled with --enable-ncpus > 1 on x86_64. However, there is still work to be done particularly with SWAPGS instruction. Notably, this changeset modifies the AP low boot address to be hardcoded to 0x11000 because it is very difficult to implement 64 bit AP bringup without knowing the offset in advance of waking up the AP via SIPI.

TESTED:

i386 UP still boots

i386 SMP still works with -smp 1 (but freezes during rumpdisk probe)

i386 SMP still works with -smp 6 (but freezes during rumpdisk probe)

x86_64 UP still boots

x86_64 SMP now compiles, but freezes with -smp 1 during grub module load

x86_64 SMP now compiles, but freezes with -smp 6 just before AP bringup

We still have work to do, but this definitely makes progress.

We had a kind developer submit a tiny patch that kills lingering zombie processes.

Diego Nieto Cid fixed several compiler warnings throughout our codebase: lwip, nfsd, nfs, etc.

He also tidied up the glibc setrlimit () call that lets a process limit its consumption of system resources. When Samuel committed this he noticied that it works well. Samuel wrote:

Thanks for this! That will stabilize boxes against programs that allocate like crazy!

Yes, it works well ; on packages that used to kill buildd boxes, we properly get virtual addressing space limitation errors.

For some time now, Mike Kelly has used stress-ng to stress test the hurd, and he keeps finding bugs to fix. He has even started to stress test in real hardware! Thanks Mike for making the Hurd more stable!

He also worked on gnumach fiddling to decrease compile time. He writes:

This implementation now searches for pages in the order: inactive/external, inactive/internal, active/external and active/internal as suggested by Samuel (https://lists.gnu.org/archive/html/bug-hurd/2025-12/msg00034.html). The performance improvement is considerable. A test case involving 3 instances of g++ compiling C++ template code (MatrixSine.cpp from libeigen-dev) uses sufficient memory on a 4GB machine to require around 500MB of swap. This test takes about 11 minutes with previous gnumach version (using a virtual machine) but 3 minutes with this alteration. I have not been able to complete this test on a 64 bit Hurd 'real hardware' installation with previous gnumach but the compilation does complete with this patch after about 10 minutes

João Pedro Malhado updated our alternative hurd installation documentation page. I think it's pretty cool, that using a Debian GNU/Linux computer, one can install the Hurd via mmdebstrap.

We also now have some people running the x86_64 hurd port on real hardware.

Some time ago, Milos Nikic, implemented a metadata journal for ext2fs. It has not been commited to libdiskfs, and it is a different design from ext3. He writes:

This patch introduces a working implementation that captures metadata changes, writes them to a CRC32-protected journal file, and replays them during early boot—before fsck runs—allowing us to correct inconsistencies proactively.

I'm now using this system routinely without issues, and I believe it already provides value for users.

Some people are mentioning on other news channels that Debian is considering requiring rust for apt. We just want to mention that rust was ported to the Hurd, so while there might be some challenges in getting a "rusted" apt working on the Hurd, we do not forsee any unsurmountable problems.

In other rust news, apparently the crate uzers-rs has recently been built with Hurd support. Apparently, this is quite a commonly used crate, which should help more rust code work on the Hurd.