GNU Hurd
GNU Hurd
Recent Changes
Preferences
Edit
History
Source
Discussion
Welcome to...
... the GNU Hurd!
Community
Donate
Contributing
Source Code
Public Hurd Boxen
QEMU Images
Getting Help
Project Ideas
Open Issues
Documentation
FAQ
Hurd
Documentation
Building
Running
Mach
Documentation
GNU Mach
Building GNU Mach
MIG
Documentation
GNU MIG
Building GNU MIG
Debian GNU/Hurd
Guix GNU/Hurd
Arch GNU/Hurd
Gentoo GNU/Hurd
GNU System
Hurd NG
What is the GNU 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
What is the mission of the GNU Hurd project?
Our mission is to create a general-purpose kernel suitable
for the GNU operating system, which is viable for everyday use,
and gives users and programs as much control over their
computing environment as possible.
Our mission explained
Download latest stable release
here
or
browse the Git repository
News
Contributing
Getting Help
Running the Hurd
Current Status
Advantages and Challenges
News
RSS
Atom
2026-04-01-gentoo gnu hurd
Edit
Discussion
Gentoo GNU/Hurd released!
Details.
The year is 2026 and Gentoo is perhaps ready for an advanced kernel:
the GNU Hurd.
[...]
Scripts to build a working image that can be booted in QEMU can be
found at
(will move that to Gentoo infra).
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
2026-q1
Edit
Discussion
Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd
developments in Q1 of 2026!
Details.
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
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
2025-q4
Edit
Discussion
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]
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
2025-08-10-debian gnu hurd 2025
Edit
Discussion
Debian GNU/Hurd 2025 released!
Details.
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
2024-q2
Edit
Discussion
Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd
developments in Q2 of 2024!
Details.
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
vm
map
pageable_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
Older news entries can be found in the
news archive
. For Hurd
developers' musings have a look at the
shared weblog
The
@ recent changes
page lists the latest changes of this website.
Contributing
So, you are interested in contributing to the GNU Hurd project? Welcome!
Every single contribution is very much encouraged. Please read our
detailed
recommendations about how to contribute
Follow section
Running the Hurd
to run the Hurd. See our
source repositories
for the source code.
Getting Help
There are a couple of different
FAQ lists
There are a number of
IRC channels
and several
different
mailing lists
with searchable archives.
Before asking a question on a mailing list or on IRC, first, please try to
answer your own question using a search engine and reading the introductory
information. If you have done this and you cannot find the answer to your
question, feel free to ask on a mailing list or on IRC.
Running the Hurd
Running the Hurd may not be as hard as some people think. There are
various ways
. The easiest one might be using a
virtual machine platform. We also provide accounts on our
public Hurd boxen
Four of them are
Installing a
GNU/Hurd distribution
to a real machine.
Running it in
Xen
Running it with
QEMU
Running it with
VirtualBox
, if you are familiar
with VirtualBox or using an OS which is difficult to run QEMU like Windows.
For a virtual machine, you can use either a
pre-installed qemu image
or a
LiveCD
. The pre-installed image (converted
to proper format) can be used as a hard disk in a virtual machine to skip the
installation step and run the Hurd directly. The LiveCD is just like the one of
other OS.
There are also various
GNU/Hurd distributions
which you
can choose from. The most functional one is the one provided
by Debian. It's a good choice for a start, whether you have experience with it,
or if you can't decide which one to choose. It provides both a pre-installed
image and a LiveCD. Find more information about it at the
Debian GNU/Hurd website
And these web pages are a living proof of the usability of the Hurd, as they
are rendered on a
Debian GNU/Hurd
system.
Current Status
The latest GNU releases are
Hurd 0.9
Mach 1.8
, and
MIG
1.8
(Release Notes)
, 2016-12-18.
The Hurd is developed by
a few volunteers in their spare time
The project welcomes any assistance
you can provide
Porting and development expertise is still badly needed in many key areas.
Functional systems are installable in a dual-boot configuration. Development
systems are currently mostly based on the
Debian GNU/Hurd
port
sponsored by the
Debian project
Aside from this Wiki, community resources for related projects focus around
gnu.org
, the
mailing lists
, and the
IRC channels
If you want to see the current discussions in the Hurd project, please have a look at
the
bug-hurd mailinglist archives
If you want to have a look at the current coding work, you can just head over to our
source repositories
For more details, please read our writeup on the
current state of the GNU Hurd
Advantages and Challenges
The GNU Hurd operating system design provides
advantages
, but uncovers new
challenges
, too.
These pages are powered by
ikiwiki
Further information about this site and how it was created can be found in the
colophon
Links:
sidebar
Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
2013, 2014, 2015, 2016, 2017, 2018, 2019 -
Free Software Foundation, Inc.
License:
GFDL 1.2+
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
Last edited
2025-01-31 10:31:39 UTC