---
title: "2026-q2"
url: https://daily.dev/posts/2026-q2-brbn8iu87
source_url: https://www.gnu.org/software/hurd/news/2026-q2.html
type: article
source: "Hacker News"
published: 2026-08-05T19:47:58.296Z
updated: 2026-08-06T11:31:31.994Z
tags: ["open-source", "rust"]
reading_time: 9
upvotes: 0
comments: 0
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-q2

**[Hacker News](https://daily.dev/sources/hn)** · 9 min read · 0 upvotes · 0 comments

## Summary

A quarterly update on GNU Hurd development covering Q2 2026. Highlights include: a WIP 9P filesystem translator by Sergey Bugaev with basic read and write support; AArch64 kernel-side implementation patches by Paulo Duarte; a WIP Hurd trivfs implementation written in Rust by Almudena Garcia; dynamic SATA device population at boot via an expanded partfs translator by Mikhail Karpov; porting of OpenNTPD and dhcpcd; ext3/ext4 journal support committed by Samuel Thibault; Neovim port and ext3/ext4 journal deadlock fix by Milos Nikic; pfinet crash fixes under memory pressure; CI improvements for AArch64 and QEMU integration; and various bug fixes across glibc, GNU Mach, libdiskfs, procfs, and other components.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://www.gnu.org/software/hurd/news/2026-q2.html>

## Community take

How the wider developer community reacted, aggregated from 2 discussions and 128 comments across hackernews, lobsters (as of 2026-08-06).

**TL;DR:** The community greets the GNU Hurd Q2 2026 update with a mix of genuine curiosity about technical details (microkernel IPC performance, AArch64 support) and heavy skepticism that the project will ever reach practical relevance, punctuated by jokes about its decades-long development timeline.

**Sentiment:** 20% positive · 40% mixed · 40% skeptical

**The case for**

- Some commenters expressed genuine interest in Hurd's microkernel architecture and its potential security benefits over a monolithic kernel like Linux.
- The AArch64 and Apple M1 porting work excited a few people who saw it as a fun way to repurpose old hardware.
- A handful of commenters appreciated seeing a non-commercial, passion-driven project on the site.
- The idea of using LLMs or AI tooling to accelerate stalled FOSS projects like Hurd was floated as a potentially interesting use case.

**The pushback**

- Many commenters doubt Hurd will ever achieve practical relevance given Linux's overwhelming momentum and Hurd's lack of basic features like USB support after 35+ years.
- Mach-based IPC overhead is seen as a fundamental performance concern, with Spectre mitigations having made kernel/user transitions even more expensive.
- The project is perceived as severely under-resourced compared to mainstream OS efforts, with progress described as slow and meandering.
- Several commenters noted that the quarterly update led with an SVG logo, reinforcing a perception that priorities are misaligned for a project still missing critical functionality.

**By community**

- hackernews (mixed): Engagement is lively but dominated by jokes about Hurd's age, tangential Linux-desktop debates, and only a thin layer of genuine technical discussion about microkernel IPC performance and porting efforts.
- lobsters (mixed): No comments were posted, so no signal is available beyond the single upvote.

**Hottest debate:** Whether Mach-style IPC overhead is still a meaningful performance problem on modern hardware, or whether raw CPU speed and cache sizes have made it negligible.

**Open questions**

- Will the AArch64 and Apple M1 work ever reach a bootable, usable state?
- How does Hurd plan to address the lack of USB support and other missing hardware subsystems?
- Could AI-assisted coding realistically accelerate Hurd's development on novel, undocumented subsystems?
- What percentage of real-world CPU time is actually spent in syscalls for typical workloads, making microkernel IPC overhead meaningful or not?

**Highlights**

> Does anyone more familiar with Hurd know how they addressed performance issues encountered by other Mach-based kernels? I remember reading that one of Mach's bottlenecks was validating that each IPC message had proper permissions/access when sending them between processes due to the large number and frequency of messages.
> — [csb6 on hackernews · 5 comments](https://news.ycombinator.com/item?id=49187759)

> If anything, Mach style IPC has gotten worse because of the greater overhead if kernel/user transitions.  Spectre really did a number on context switching overhead.
> — [monocasa on hackernews](https://news.ycombinator.com/item?id=49188715)

> Mach's problem wasn't that it had slow IPC, but rather that in terms of microkernels, Mach was pretty damn big. There are some very fast microkernels out there, like the L4 family, which negate the IPC overhead of microkernels by being small enough to fit entirely in the L2 cache of most processors. Linux may only have the single IPC call per round trip, but it's a fucking huge kernel and there is typically a ton of cache thrashing going on.
> — [darksaints on hackernews · 2 comments](https://news.ycombinator.com/item?id=49189981)

> I can't help but feel disappointed that after 35 years the first thing they're talking about is an SVG logo. I mean, there's a certain novelty that it was made on a laptop running Hurd itself, but still I was left with a sense that progress is meandering and whimsical. I remember being excited by Hurd's ambitions after studying Tanenbaum's OS book in university and drinking the microkernel kool-aid; now I'm too old and jaded to believe it'll be a viable alternative.
> — [shaggie76 on hackernews · 2 comments](https://news.ycombinator.com/item?id=49190369)

> Someone should do the blasphemous thing and have Opus 5 finish HURD. Actually in all seriousness reviving dead interesting FOSS projects is one use for AI coding I've thought about.
> — [api on hackernews · 1 comments](https://news.ycombinator.com/item?id=49189986)

**Source threads**

- [hackernews](https://news.ycombinator.com/item?id=49146183) · 181 points · 128 comments
- [lobsters](https://lobste.rs/s/l9jtnl/gnu_hurd_news_2026_q2) · 1 points · 0 comments

## Similar posts on daily.dev

- [GNU Hurd Makes Progress On AArch64, Writing Translators In Rust](https://daily.dev/posts/gnu-hurd-makes-progress-on-aarch64-writing-translators-in-rust-rjhfxycmc) · Phoronix · 0 upvotes · 0 comments
- [The 64-bit Hurd is Here\! — 2026 — Blog — GNU Guix](https://daily.dev/posts/the-64-bit-hurd-is-here-2026-blog-gnu-guix-hkuw5xyio) · Lobsters · 0 upvotes · 0 comments

---

Tags: [#open-source](https://daily.dev/tags/open-source), [#rust](https://daily.dev/tags/rust)

[View this post on daily.dev](https://daily.dev/posts/2026-q2-brbn8iu87)
