Brent W. Baccala debugged some x86_64 SMP issues with a Claude AI bot. The bot did not contribute any code. It just found some incorrect code that Damien then fixed. It did get some things wrong, but it was incredibly helpful pointing out several problems. You can read its report here.

Joshua Branson tweaked the hurd wiki. The most helpful addition is this page, which documents how to flash a working qemu hurd image directly to an HDD or SSD. This is a really easy way to install the Hurd on real hardware! Buy a supported machine from this page and give it a shot! Consider this another reminder that the Hurd project could use more documentation writers. It's an easy way to contribute. As a fun fact, Joshua wrote this qoth on the Hurd running on a T420 with 12 GB of RAM! Running Debian GNU/Hurd on bare metal these days is largely fairly stable. Emacs, i3, netsurf, and luakit all work just fine and most of the Debian package archive compiles without issue on the Hurd.

Etienne Brateau fixed a compilation error. He also provided a simple test program that exposed a rather serious threading bug, which Samuel promptly fixed. This is a good reminder that writing simple C test programs that successfully run on Linux, but fail on the Hurd can have a large impact.

Gianluca Cannata worked on our httpfs translator.

Diego Nieto Cid added a daemon-wait option for console-client. This can help users with slow machines avoid a broken Hurd console. He also fixed a rumpdisk compilation issue.

Mike Kelley fixed a deadlock in SMP enabled GNU Mach kernels. He also fixed a page fault in amd64 SMP kernels. He fixed another deadlock in the alarm () function. He fixed a panic when running large builds without the mach-defpager. He also fixed some of our signal related code. He worked with Samuel to investigate an odd bug. Their detailed investigation uncovered and lead to a fix in the Hurd's ext2's xattr code.

Joan Lledó updated some patches for the dhcpcd port as well as some patches for upstream liblwip. He also tweaked our lwip translator. He also added a glibc patch for IP_PKTINFO.

Milos Nikic added some various fixes. He also made many considerable contributions on filesystem related things including adding ext2fs support for 64 bit time, He also fixed a rumpdisk deadlock. He also fixed a potential lock in GNU Mach. He fixed some IPC issues in glibc. He contributed some tiny fixes to speed up GNU Mach's IPC. His most exciting work is a JDB2 binary compliant journal, which is an ext3/ext4 compatible journal. The Hurd may soon be running on ext3fs or ext4fs instead of ext2fs! He writes:

I have been working on creating a prototype for a journal inside
ext2fs which is fully Linux compatible (binary JBD2 compatible). This
enables standard Linux tools (e2fsck, tune2fs, debugfs, etc.) to work
seamlessly with Hurd partitions.

This means one can mount a Hurd image from Linux and fix any issues
with the drive using standard journaling tools if the need
arises. While this is currently a prototype with polish still
required, it is functional.

Key Features:
* Log Replay: The driver writes JBD2-compliant transactions. I have
  verified that after a hard crash of the Hurd guest, a Linux host
  running e2fsck correctly replays the journal and restores filesystem
  metadata consistency.
* Continuous Operation: The driver handles ring-buffer wrap-around and
  checkpoints correctly. I have tested it with sustained loads
  (50,000+ transaction loops) without deadlocks or corruption.
* Crash Safety: I have verified via "sabotage tests" (modifying the
  disk offline after a crash) that the journal accurately restores the
  correct metadata state.
* Lightweight: The implementation consists of only a few new files and
  ~800 lines of code.

You can read the complete email here.

He then tweaked the code a few times and summed up the current status. He writes:

This is it. I have applied numerous fixes, performance tweaks, and
cleanups. I am happy to report that this (the journal) now performs on
par with unjournaled ext2 on normal workloads, such as
configuring/compiling the Hurd, installing and reinstalling packages
via APT, and untarring large archives (like the Linux kernel). I have
also heavily tested it against artificial stress conditions (which I
am happy to share if there is interest), and it handles highly
concurrent loads beautifully without deadlocks or memory leaks.

Progressive checkpointing ensures the filesystem runs smoothly, and
the feature remains strictly opt-in (until a partition is tuned with
tune2fs -j, the journal is completely inactive).

The new API in libdiskfs is minimal but expressive enough to wrap all
filesystem operations in transactions and handle strict POSIX sync
barriers.

Manolo de Medici fixed a bug allowing unprivileged users to modify the system time. He also worked on partially opening up the processor set API to unprivileged processes.

Samuel Thibault gave an update on the GNU Hurd project. His talk dived into rumpnet, rumpdisk, smp, etc. It was quite an interesting talk. Essentially the Hurd is becoming a fairly stable option for daily computing. Check out our status page for more information. He provided numerous fixes for packages that were failing to build, like xserver-xorg-input-keyboard. He also reported on a rumpnet bug, which highlighted an interesting feature of the Hurd's design. When Hurd's new or experimental device drivers crash, it does not bring down the system. One can just restart the driver. If a device driver crashes in Linux or BSD land, you may be in trouble.

He also discovered why the Hurd's crash translator hanged when generating core files on amd64. Thanks to a lot of code from Damien, Samuel was able to upload an amd64 SMP kernel to Debian Hurd! This kernel still restricts processes to cpu0, but with the /sbin/smp utility, one can experimentally run applications on multiple cores. Once we fix the various race conditions, we can run more of the Hurd via SMP. Please be aware that testing programs via /sbin/smp can lead to crashes.

He also worked on fixing xmm state restoration on signal.

Mesa was also ported to the Hurd. The patches are not quite merged upstream. The Hurd does not have a DRM yet, so the performance is quite poor. nexussfan on irc ported ClassiCube. It runs quite slowly. We are hoping to eventually add a proper DRM to the Hurd. Please reach out if you'd like to help us achieve this.

Damien Zammit ported qemu to the Hurd. He is currently using it for his continuous integration. It uses a Hurd host to launch qemu to test GNU Mach. He made many contributions to the Hurd's CI including testing the Hurd's xen support. He fixed GNU Mach compilation on GCC 10. He also contributed a lot of fixes for the Hurd's x86_64 support. Thanks to Damien's numerous contributions, the Hurd's SMP support is becoming far more useful!

If you did not see the recent Guix Hurd news, then please check out their most recent blog post! There are currently two active GNU Hurd distributions: Debian GNU/Hurd and GNU Guix Hurd. These two distributions run on real hardware! If you have been closely reading the #hurd irc channel, then you may have heard about some work on adding another Hurd distribution. Perhaps we will have more to report on this exciting news in the next Qoth!

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.

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.

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.

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.

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.

It is with huge pleasure that the Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2025.

This is a snapshot of Debian "sid" at the time of the stable Debian "Trixie" release (Auguest 2025), so it is mostly based on the same sources. It is not an official Debian release, but it is an official Debian GNU/Hurd port release.

Before posting questions on various webnews, please read the FAQ which will answer most if not all of them.

For release details, please read the announcement email.

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.

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.

Sergey Bugaev committed public headers for the GNU Mach AArch64 port. He writes that

...there is now a real port of GNU Mach to AArch64, using these headers as its actual API/ABI. We got the Mach port to run glibc, several Hurd servers, and simple Unix programs, including things like fork/exec and signal delivery & handling working, which exercises these architecture-specific definitions (thread state & exceptions). We have also managed to do some testing on real hardware; although not everything is working yet, we have seen thread state manipulation & Mach handling an unaligned SP fault work as expected.

His email also mentions that the GCC patches that enable GCC to compile GNU/Hurd programs on AArch64 have been merged! This apparently will make it easier to merge his AArch64 specific glibc patches.

He also added new tests to check that threads handle signals well, and he also fixed a use-after-free in vmmappageable_scan(). He also hosted a lengthy Hurd code jam (apologies for the poor audio quality).

He also very notably added support to copy a send once right to Mach and MIG.

Some time ago, Sergey also wrote the terrible-mdns-responder, and if you would like to be able to type in ssh HOSTNAME.local and connect to a locally running Hurd, then you may want to try it!

Flávio Cruz fixed some issues with the Hurd compiling on GCC 14.

Luca Dariz fixed message sizes, where the size was not set by userspace, and he added another test to check message sizes on various code paths.

Debian GNU/Hurd now offers an experimental SMP GNU Mach kernel (32-bit only) and the official rustc compiler! Now that we have ported rustc to Debian GNU/Hurd, we can compile important packages like librsvg. Debian GNU/Hurd now can compile 71% of the packages from the Debian archive.

Now for something trivial but fun! I updated the guide on the Hurd wiki that shows how one can run their own personal ext2fs translator.

You could go crazy even! Why not make something like this:

 ~/silly <--> silly.fs
    |   \
    |    \
    |     \
    |      \
    |       \
   \|/       \/
  silly1 <-> silly1.fs
        ...

 /hurd/joshua/silly/silly1/silly2/silly3/silly4

Each sillyN is another ext2fs filesystem! Make sure that as N gets bigger sillyN.fs gets smaller. Let us know in the #hurd irc channel how "silly" you are.

The current record is ~/silly1/silly2 where each sillyN is a different ext2fs. Does anyone want to volunteer to beat the current record?

So if you want to test if your favorite packages work on the Hurd and contribute towards making the full GNU system usable for a wider range of people, please check the contributing page.

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.

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.

Etienne Brateau modified console-client to use xkbcommon instead of x11 for xkb extended support, which improves keyboard layout coverage a lot!

Flavio Cruz also worked on porting GDB to the 64-bit Hurd, implemented setcontext/getcontext/makecontext/swapcontex () in glibc, and implemented child process resource accounting. The latter implementsgetrusage(RUSAGE_CHILDREN, ) and populates child related data in times().

He fixed the perl testsuite for the Hurd, and he also posted a RFC to enhance tracing utilities, which he used to port the RPC format to 64 bit.

Flavio also had a smattering of fixes here, here, here, here, and here.

Damien Zammit had some fixes including fixing the console with APIC enabled, patching GNU Mach to support ACPI v2, fixing baud rate on com ports, porting the Hurd to some AMD CPUs (WIP), adding HPET (high precision timers). He also worked on making ext2fs use xattr by default to store translators.

Damien also worked on more SMP fixes here, here, here, here, here, and here. Hurd currently boots in SMP mode on the BSP. Damien wrote a test program that lets you run a task on the APs.

Sergey Bugaev patched binutils to support the GNU/Hurd on AArch64, and he wrote some patches to make the Hurd easier to port here, here, and here,

Sergey also posted a fairly large RFC patch series for his AArch64 port. He writes:

MIG seems to just work (thanks to all of Flávio's work!). I'm using
 the same message ABI as on x86_64, and haven't seen any issues so far
 — neither compiler errors / failed static assertions (about struct
 sizes and such), nor hardware errors from misaligned accesses.

He also mentions that "the hardware hardening features (BTI, MTE, PAC) are currently 'not really supported', but I do want to support them in the future." Samuel merged many of the patches.

In Sergey's later glibc patch series, he wrote about the AArch64 port progress. He wrote:

Last time, there was no AArch64 port of GNU Mach, and so the only testing
 I have done was running a simple statically-linked executable on Linux under
 GDB, which, nevertheless, helped me identify and fix a number of issues.

 Since then, however, I have been (some may say, relentlessly) working on
 filling in the missing piece, namely porting GNU Mach (with important help &
 contributions by Luca D.). I am happy to report that we now have an
 experimental port of GNU Mach that builds and works on AArch64! While that may
 sound impressive, note that various things about it are in an extremely basic,
 proof-of-concept state rather than being seriously production-ready; and also
 that Mach is a small kernel (indeed, a microkernel), and it was designed from
 the start (back in the 80s) to be portable, so most of the "buisness logic"
 functionality (virtual memory, IPC, tasks/threads/scheduler) is explicitly
 arch-independent.

 Despite the scary "WIP proof-of-concept" status, there is enough
 functionality in Mach to run userland code, handle exceptions and
 syscalls, interact with the MMU to implement all the expected virtual
 memory semantics, schedule/switch tasks and threads, and so on.
 Moreover, all of GNU Mach's userspace self-tests pass!

 This meant there was enough things in place for me to try running
 glibc on it, and the amazing thing is my simple test executable, the
 same one I previously tested on Linux with GDB, just worked on real
 Mach without me having to make any additional changes to the glibc
 side, or even recompile it.

 But I did not stop there, and I got several of the core Hurd servers
 working!  Namely, these are ext2fs, exec, startup, auth, and proc
 servers. All of them but ext2fs are dynamically linked; ld
 aarch64.so.1 sucessfully locates and maps the programs themselves
 and their required dependencies, and Mach pages in code and data
 pages from ext2fs as they are accessed, transparently to the
 program, just as one would expect it to.

Be sure to read more from his announcement email.

Sergey also announced a new Alpine distro based on Hurd (it currently does not have a name). His goal is to add another Hurd distribution, which will force the Hurd to work with different software and hopefully fix more bugs. Alpine Linux also usually runs the latest software, so this new Hurd distribution will be for those who like living on the bleeding edge. He writes:

I have ported many Alpine packages to build with (i386, for now) GNU
 Mach, the Hurd, and glibc, replacing Linux and musl. If you want a
 specific number: as of yesterday, I have 299 installable packages; the
 number of source packages is of course several times less than that.
 Still, this includes things like curl, ncurses, nano, native binutils
 & gcc & mig, libffi, openrc, openssl, util-linux, busybox, apk-tools,
 ... and of course gnumach, hurd (with dependencies like libdaemon,
 parted, ...), and glibc. Importantly, all this cleanly bootstraps
 using the scripts/bootstrap.sh script that they provide; this is too
 somewhat like Flávio's scripts, but it uses the real full Alpine
 package definitions for e.g. GCC (patched by me for glibc / Hurd
 support).

 Above the kernel and libc, things remain much as they were in upstream
 Alpine: the system boots (will boot — I haven't tried it yet) with
 busybox init & OpenRC, and uses busybox as its basic userland. GNU
 software such as Bash is installable, too.

This new Hurd distribution currently does not have a mailing list, irc room, or website. If you are interesting in helping Sergei to develop it further, then please email bug-hurd@gnu.org.

Luca Dariz added userspace tests, which work with qemu. We currently test the Hurd in qemu on a GNU/Linux host. He also described how he currently uses the 64-bit Hurd. Perhaps you should follow that advice if you want to try running a 64-bit Hurd on qemu.

Manolo de Medici made a WIP patch series that gets qemu to run on the Hurd.

I organized a belated GNU/Hurd Christmas party. We had 6 or 7 attenders, which was pretty awesome! I was not able to record the event, so perhaps we should try for another meet perhaps at the end of Q2. If you would like to help me plan/organize/join such a party, then please email bug-hurd@gnu.org.

If you want to test if your favorite packages work on the Hurd and contribute towards making the full GNU system usable for a wider range of people, please check the contributing page.

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.

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.