GNU Hurd

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 ... [More] 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. [Less]

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 ... [More] (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. [Less]

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 ... [More] 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. [Less]

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 ... [More] 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. [Less]

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 ... [More] 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][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. [Less]

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 ... [More] 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][hurd/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][hurd/translator/ext2fs]. 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. [Less]

Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd developments in Q1 of 2024! Details. Etienne Brateau modified console-client to use xkbcommon instead of x11 for xkb extended support, which improves keyboard layout ... [More] 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 [email protected]. 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 [email protected]. 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. [Less]

Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd developments in Q4 of 2023! Details. Samuel Thibault fixed gcc's Hurd's default pie and added static pie support. He also added a whatis command to GNU Mach's kernel ... [More] debugger, which can determine what an address points to (a stack? a port? some kalloc? ...). He also added hurd-amd64 support to GCC. Samuel requested that the Hurd team set up a continuous integration, so that when developers make code changes, they can be certain that they did not break anything. It turns out that the Hurd supports several different environments: 32 bit, 64 bit, 32-on-64 bit, ACPI, non-ACPI, SMP, non-SMP, Xen, etc. Apparently Flavio has a personal CI, but it is set up in a Debian independent way. If you are interested in helping the Hurd project set up a CI, then please get in touch! Luca Dariz worked on adding some simple GNU Mach user-space tests . With a working MiG, a GNU/Linux machine can run make check in the GNU Mach source code, which will launch qemu to ensure that 32 bit (PAE and non PAE), 32 on 64 bit, and full 64 bit GNU Mach works. We currently do this testing on GNU/Linux, because qemu does not run on the Hurd. Many people worked on the Hurd's new x86_64 bit support. A 64-bit debian buildd is set up, and we can bootstrap a chroot! The hurd-amd64 wanna-build infrastructure is also set up. We are having issues reliably building packages on a 64-bit Hurd, which lead Samuel to uncover and fix a proc leak. Flavio Cruz improved GNU Mach's IPC by reordering mach_msg_type_t fields to byte align msgt_name and msgt_size. He also created a patch series to avoid message resizing for x86_64. He also removed untyped mach RPC code. GNU Mach uses typed IPC. The Hurd could support both typed and untyped, but it appears that the Hurd only uses typed RPC. So it seems best to remove any untyped RPC code. Sergey Bugaev added GNU Mach entry re-coalescing support. Essentially, Mach was not always able to merge two vm entries that are made next to each other, which was slowing down ext2, bash, etc. Sergey allowed GNU Mach to merge entries in the common cases, which greatly helps ext2fs for instance. Sergey is also working on porting the Ladybird web browser to the Hurd. The author of this post uses the netsurf web browser on the Hurd, which works on simple websites like wikipedia, but it badly renders javascript heavy websites, which makes many websites un-useable. If Sergey is successful in porting Ladybird, then Hurd users could start using sites like Github! It is worth noting that someone should update the Firefox port as well. Sergey also started porting the Hurd to AArch64! While a port to RISC-V might be more exciting, it is worth mentioning that AArch64 is more established. What is interesting is that Sergey is already able to build Hurd servers for AArch64! Normally, in order to run the binaries, one would port GNU Mach to AArch64. Luckily for us, he turned to GDB and directly ran a 'Hello World' Hurd AArch64 binary on Linux! This helped him fix some bugs along the way. We still need to define the ABI and complete the GNU Mach port, but this is exciting news! Tobias Platen started porting GNU Mach to Power9. 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. [Less]

Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd developments in Q3 of 2023! Details. Joan Lledo modified the PCI arbiter to prevent mapping I/O region files. He previously sent some patches to implement mapping region ... [More] and ROM files using mmap(). However, a BAR region can represent either memory or I/O space, and only memory should be allowed to be mapped. Since I/O BARs only contain I/O addresses, he went ahead and prevented the mapping of I/O region files. The next step is to make IO spaces available for users through the pci-arbiter. He plans to add a new RPC that checks for permission and calls i386_io_perm_create(). Then it returns the resulting port. Our Google summer of code student Vedant Tewari decided to port rust, and the rust porting effort is making good progress. The build process is a bit wonky, and Debian is using an older rust version. Check out the rust pull request that adds Hurd support! Samuel worked on setting up PAE, which will eventually let us use more than 4GB of RAM on a 32-bit Hurd! It is also useful for the X86_64 architecture. He also fixed the jemalloc build. Samuel was incredibly productive this quarter making the X86_64 bit port more stable. He fixed the 64-bit Hurd PIE build, and he got git working on the 64-bit port! Though a few of the git tests are failing on both X86_64 and the 32 bit port. He fixed the glibc build, which involved fixing pmap_remove and pmap_protect. He discovered that core dumping is currently causing problems on the 64-bit port, and he temporarily encourages people to disable core dumping. Samuel fixed some networking issues and a dpkg issue for the 64-bit port. It was hard to discover what the problem was, because the debugging tools have not been ported to the 64-bit port. He add some helpers to locking to fix some bugs, and he encourages other developers to help him fix the debugging tools for X86-64. It seems that most developers are currently running the 64-bit Hurd in a virtual machine and not in real hardware. Luca Dariz got a patch series merged for the 64 bit port. Sergey implemented MAP_EXCL and provided MAP_FIXED_NOREPLACE and MAP_TRYFIXED as aliases of (MAP_FIXED|MAP_EXCL) as well other mmap work. He explains: MAP_FIXED is defined to silently replace any existing mappings at the address range being mapped over. However, this is dangerous and only rarely desired behavior. Various Unix systems provide replacements or additions to MAP_FIXED. SerenityOS and Linux provide MAP_FIXED_NOREPLACE. If the address space already contains a mapping in the requested range, Linux returns EEXIST. SerenityOS returns ENOMEM, however that is a bug, as the MAP_FIXED_NOREPLACE implementation is intended to be compatible with Linux. DragonFly BSD, NetBSD, and OpenBSD provide MAP_TRYFIXED, but with different semantics. DragonFly BSD returns ENOMEM if the requested range already contains existing mappings. NetBSD does not return an error, but instead creates the mapping at a different address if the requested range contains mappings. OpenBSD behaves the same, but also notes that this is the default behavior even without MAP_TRYFIXED (which is the case on the Hurd too). Since the Hurd leans closer to the BSD side, add MAP_EXCL as the primary API to request the behavior of not replacing existing mappings. Declare MAP_FIXED_NOREPLACE and MAP_TRYFIXED as aliases of (MAP_FIXED|MAP_EXCL), so any existing software that checks for either of those macros will pick them up automatically. For compatibility with Linux, return EEXIST if a mapping already exists. Damien Zammit added a USB mass storage translator via rumpusbdisk. Though it has some issues as he explains: Netdde sneems to exhibit a bug when running ifdown /dev/eth0 simultanously to running the rumpusbdisk translator, because to the two devices share the same IRQ. Damien also worked on the Hurd's SMP support (much of his SMP contributions is based on the earlier work done by Almudena Garcia): He tweaked GNU Mach's scheduler, and he merged three GNU Mach commits. He added a show all runqs command to GNU Mach's kernel debugger. He also improved SMP in GNU Mach by storing the struct processor in a percpu area and avoiding an expensive cpu_number every call of current_processor(), as well as getting the cpu_number from an offset in the percpu area. Further improvements can be made by using other percpu areas. It was untested on 64 bit. Damien also taught GNU Mach to use the x86 CPUID instruction to get the CPU ID for speed. He reduced the time it takes to get the CPUID. He made it 100 times faster! He mentioned some issues: 60% of the time, booting a 32 bit Hurd, with SMP enabled, fails to boot (sometimes apparently getting stuck in the rumpdisk). When it does boot, it is not particularly stable and likely to crash. Essentially, the SMP work is progressing, but it is not ready for production use. His recent work made the non-SMP faster, and a 32 bit Hurd, with SMP enabled and only one core, appears relatively stable (but slow to boot). The 32-bit SMP enabled Hurd may soon be as fast as the non-SMP Hurd. Eventually the SMP enabled Hurd will be faster than a non-SMP Hurd. Flavio Cruz halved the size of mach_msg_type_long_t, from 16 to 8 bytes. He also simplified the overall 64bit RPC ABI, removing "holes" in mach_msg_type_t or mach_msg_type_long_t, which prevents possible leakages to userspace. Some Hurd people talked to Kent Overstreet, the author of bcachefs to discuss the possibility of porting Linux's newest filesystem to the Hurd; the conversation was recorded. While most Hurd developers believe that it would possible to port bcachefs to the Hurd, all agree that it would be difficult to port and hard to maintain. No Hurd developers are currently planning or working on porting bcachefs to the Hurd. But perhaps you want to? 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. [Less]

Debian GNU/Hurd 2023 released! Details. It is with huge pleasure that the Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2023. This is a snapshot of Debian "sid" at the time of the stable Debian "bookworm" release (June 2023), so it ... [More] is mostly based on the same sources. It is not an official Debian release, but it is an official Debian GNU/Hurd port release. 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. [Less]