I'm having some issues with git send-email at the moment.
I'm attaching the latest qoth.
Thanks!
Joshua
[[!meta copyright="Copyright © 2026 Free Software Foundation, Inc."]] [[!meta
license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license"
text="Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or any later
version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!meta date="2026-01-02 06:07 UTC"]]
Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd
developments in Q4 of 2025!
[[!if test="included()" then="""[[!toggle id=full_news
text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]"""
else="
[[!paste id=full_news]]"]]
[[!cut id="full_news" text="""
Joan Lledó worked on [porting
dhcpcd](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00084.html)
to the hurd. He also made some changes so that
[lwip would work with
dhcpcd](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00068.html). In
this
[message](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00084.html) 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](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00123.html)
[interupt
bugs](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00132.html)
in the acpi server.
He also made some
[fixes](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00059.html) for
rumpnet.
He also worked on adding a
[callwheel to GNU Mach's
clock](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00015.html).
This would make GNU Mach faster in certain ways. Particularly, Damien noticed
that his machine boots up one second faster. 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](https://doi.org/10.7936/K7VM49H5)
Damien also made some progress on the
[SMP support for
`x86_64`](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00007.html).
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](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00019.html).
Diego Nieto Cid fixed several compiler warnings throughout our codebase:
[lwip](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00052.html),
[nfsd](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00050.html),
[nfs](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00047.html), 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](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00052.html)
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](https://lists.gnu.org:443/archive/html/bug-hurd/2025-11/msg00038.html).
He
has even started to stress test in
[real
hardware](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00023.html)!
Thanks Mike for making the Hurd more stable!
He also worked on gnumach [fiddling
to](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00026.html)
[decrease compile
time](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00047.html).
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](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00035.html).
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](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00001.html).
Some time ago, Milos Nikic, implemented a
[metadata journal for
ext2fs](https://lists.gnu.org:443/archive/html/bug-hurd/2025-08/msg00040.html).
It has not been commited to `libdiskfs`, and it is a
[different design from
ext3](https://lists.gnu.org:443/archive/html/bug-hurd/2025-07/msg00048.html).
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](https://lists.gnu.org:443/archive/html/bug-hurd/2025-11/msg00014.html).
In other rust news, apparently the crate `uzers-rs` has recently been built with
[Hurd
support](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00020.html).
Apparently,
this is quite a commonly used crate, which should help more rust code work on
the Hurd.
---
The **GNU Hurd** is the GNU project's replacement for the Unix kernel. It is a
collection of servers that run on the Mach microkernel to implement file
systems, network protocols, file access control, and other features that are
implemented by the Unix kernel or similar kernels (such as Linux). [[More
detailed|hurd/documentation]].
**GNU Mach** is the microkernel upon which a GNU Hurd system is based. It
provides an Inter Process Communication (IPC) mechanism that the Hurd uses to
define interfaces for implementing in a distributed multi-server fashion the
services a traditional operating system kernel provides. [[More
detailed|microkernel/mach/gnumach]].
"""]]
