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
1. Advantages and Challenges

News

RSS Atom

Edit
?Discussion

Hello and welcome to another Qoth! Here's what's been happening in Q2 of 2026!

Joshua Branson added a pretty cool svg logo for our ethernet multiplexor. He built that image with Inkscape whilst using a Hurd laptop (Thinkpad 420) running on real iron! The Hurd wiki could certainly use more artwork. Perhaps you have a favorite Hurd translator that you believes needs some artwork!

Sergey Bugaev announced his WIP 9pfs (source code), and it has a wiki page! He writes:

Some years ago, I experimented with implementing a 9P translator for
the Hurd. Hopefully there is no need to tell this list what 9P is :)

Besides just browsing files on the few existing servers out there, a
potential use case is virtio-9p, to enable shared directory trees
between VMs and the host. But that would need someone to implement
virtio support in the Hurd.

I wanted to complete 9pfs before publishing, but that ultimately
didn't happen, so now it's time to turn it over to the community. I
now went and made the repository public on GitHub:
https://github.com/bugaevc/9pfs

What's implemented is basic browsing (readdir, stat), path resolution
(dir_lookup), and reading files (io_read). And below that, the whole
tracking for nodes, peropens, protids, fids, tags, and 9p RPCs.

Improvements are welcome, send patches to this list with [PATCH 9pfs]
in the subject. A good starting point would be to continue porting
things that I had implemented in the old netfs-based version (see
netfs.c) but didn't yet port to the new one.

He then got a little more motivated, and he added some write support!

Etienne Brateau added validation to msync, so that the Hurd better follows POSIX.

Diego Nieto Cid worked on allowing privileged users to set their task priority (nice value). His patches landed in glibc and GNU Mach. He also fixed a tiny bug in our test suite. He fixed an adjtime bug, which is helpful to the OpenNTPD port, and he fixed two more bugs.

Paulo Duarte sent a RFC patch series trying to commit Sergey’s previous AArch64 work. He writes:

This series adds the gnumach kernel-side implementation for the
aarch64 ABI Sergey landed in April 2024, plus the test-suite arms.
Patch 01 brings in the aarch64-only sources from bugaevc/wip-aarch64
verbatim, with Sergey as Author; the rest is mine.

The meaningful divergence from wip-aarch64 is what I left out:
roughly 150 files of cross-arch refactoring across kern/, ipc/, vm/,
device/intr.{c,h}, and the i386 tree. Each got replaced with a
smaller per-arch shim under aarch64/ so kern/bootstrap.c,
device/intr.{c,h}, kern/lock.h, and the i386 trees all stay
bit-identical to current master. The shared-file footprint outside
aarch64/ is four files: a new ELF constant, two missing decls plus
their include, and a linker-symbol filter extension...

Tested: 12/12 pass on x86_64, i686, and aarch64 under qemu. No
bare-metal validation yet. I plan to build bootable images and boot
the kernel on Apple M1 / Raspberry Pi (aarch64) and an x86_64 box
(x86_64 + i686). Help on any of these welcome.

He also fixed a tiny cross compilation issue.

gfleury fixed some tmpfs typos. He also fixed a kernel crash on a null pointer deference.

Almudena Garcia is developing a WIP trivfs implementation in rust. The work is not complete yet, but it is possible to write Hurd translators in Rust!

Mikhail Karpov added some checks for mmap in several places. He also worked on adding storeio to the bootstrap chain. This is actually quite interesting. Currently the Hurd sets device entries in /dev/ statically. For example, I am writing this qoth on a Hurd machine that is using two /dev/ entries for my filesystem: /dev/wd0s1 for swap and /dev/wd0s5 for my root filesystem. However, /dev/wd0s1 through /dev/wd0s16 exist on my computer! Once Mikhail's project is done, then the Hurd will dynamically populate SATA devices at boot time! No more need for static translators! He writes:

I've expanded the functionality of the partfs translator to work
with multiple disks and their partitions. Thus, by running the
command:
settrans -c partfs /hurd/partfs /root/disk1.img /root/disk2.img /root/disk3.img


The translator directory will have the following directory tree:
partfs
├── 0
│ ├── 1
│ ├── 2
│ └── ...
├── 1
│ ├── 1
│ ├── 2
│ └── ...
├── 2
│ ├── 1
│ ├── 2
│ └── ...
Since the disks are directories, the cd and ls commands work in the translator node.

I also tested mounting, reading, and writing using the commands:
`settrans -c ext01 /hurd/ext2fs -w -T typed file:/root/partfs/0/1`
and
`settrans -c ext1_1 /hurd/ext2fs -w -T typed part:1:file:/root/partfs/1`

It actually is even cooler! Samuel (our fearless leader) is seeking feedback for how to name these newer /dev entries. Samuel writes:

One thing that would be really needed for efficiency is to implement
netfs_file_get_storage_info, so that libstore would be able to get the
underlying storage information, and directly get data from there rather
than partfs having to pass data with io_read/write.

I'm then wondering how this would fit in the "grand scheme". Our current
approach, /dev/hd0s* being always there, is indeed not really good
because it doesn't easily tell the user which partitions are actually
there. We used to have to have this because partitions used to be
handled by the kernel, and then we have moved to
storerio+parted-supported partitions, which brings much more
flexibility.

Perhaps we could use

settrans -c /dev/hd0s /hurd/partfs /dev/hd0

and then we'd have /dev/hd0s/1, which is almost like before, but allows
the entries to be dynamic. Actually, we could even have some

settrans -c /dev/hd /hurd/probedisk hd

and then we'd have /dev/hd/0, and we could have /dev/hd/0s being partfs,
so we'd eventually have

/dev/hd/0s/1

But I'm also thinking that perhaps it could be integrated more with
storeio, i.e. /dev/hd0 can as well also act as a directory with partfs
behavior, so you could have

/dev/hd0/1

and with the probedisk translator, you could have

/dev/hd/0/1

What do people think about it?

Mike Kelly has been hard at work porting OpenBSD’s OpenNTPD, which required some glibc work. The Hurd doesn't currently have a NTP daemon, so thanks Mike!

He also debugged a weird memory error with rump, and he provided a "brown-tape" solution for it. Hopefully, he (or you dear reader), can reach out to the NetBSD people to fix this bug. This just goes to show that when two projects use the same code, both projects benefit!

He also got a glibc patch committed. Essentially SIGSTOP/SIGCONT was duplicating portions of files, which is now fixed. However, there are still some other issues with building some haskell packages.

Joan Lledó continued his work on porting dhcpcd. Also Roy Maples, the dhcpcd maintainer did a lot of helpful work to help us out. Thanks Roy!

Bradley Morgan fixed a tiny implementation bug with cat. He also tweaked procfs to show hidden files, and he allowed passing “-s” to init. Previously, passing "-s" to init was silently ignored.

Johannes Schauer Marin Rodrigues has been working on getting s-build to run on amd64 Hurd. It is a rather long email thread, so grab some popcorn and dig in!

Milos Nikic ported Neovim. He also worked on bug fixes to libdiskfs, and he fixed a deadlock bug in the “ext3/ext4” filesystem journal.

In the last qoth we had talked about how the Milos was working on adding an ext3/ext4 binary compatible journal. Samuel has committed it! Samuel wrote:

There is a couple things that I fixed on the fly:

- We want to use pthread_cond_clockwait rather than
  pthread_cond_timedwait, to be able to use CLOCK_MONOTONIC instead of
  CLOCK_REALTIME, to avoid being hit by ntpdate and such.

- In diskfs_S_dir_rename, there was an addition of:

  pthread_mutex_unlock (&fnp->lock);

  which was clearly bogus: we were unlocking it again below.

There are a couple things that we'd want to fix now:

- when calling diskfs_file_update, don't we have to be inside a
  transaction? Otherwise if we pass wait=1 and use a journal, we won't
  be waiting AIUI? Notably, in diskfs_S_dir_rmdir we don't use a
  transaction. And ideally we'd have an assertion that makes sure we
  respect this.

- we should define some helper for this recurring pattern:

  if ((docommit) && (diskfs_synchronous || diskfs_journal_needs_sync (txn)))
    diskfs_journal_commit_transaction (txn);
  else
    diskfs_journal_stop_transaction (txn);

- journal_drain_deferred_blocks should document what it does, not just
  its call conditions :), and more generally the functions that are
  not already documented in a .h and not just a _locked variant of a
  documented function.

Leonardo Lopes Pereira did some spring cleaning to remove some dead code.

Samuel Thibault mentioned in an email that the Hurd can support nvmes with rump, but that the work was just not done yet. Perhaps you, dear reader, would like to help us accomplish this task?

The mysterious user yelini worked on porting the D language compiler.

Damien Zammit worked on tweaking the Hurd’s WIP CI. He also fixed several bugs to make it possible to run the Hurd’s test suite from GNU/Linux running on an AArch64 computer. He also is working on integrating qemu’s Hurd support into upstream qemu’s CI, so that the support does not bitrot.

Sophiel Zhou fixed a tiny pfinet permission checking issue and taught pfinet to not fail under memory pressure:

This series fixes two latent crash bugs in pfinet where mmap
return values go unchecked, may causing crash when memory is tight.

Both bugs follow the same pattern: mmap is called to grow a buffer,
but the returned pointer is dereferenced before (or without) checking
for MAP_FAILED.  Under normal operation mmap rarely fails, so these
have gone unnoticed, but under address-space pressure pfinet would
crash.

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 https://codeberg.org/thesamesam/gentoo-hurd (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.

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

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

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.

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

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 hurd, mach, and mig repository are continuously updated, please check out the latest git development, downstream distributions pick up snapshots every few months..

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.