GNU Hurd News 2026-Q2
gnu.org
gnu.org
I gave a conference talk about this about 4 years ago. There may be slight errors in my recollection
I'll grant you the in-kernel nfs server and ipsec implementations, but those are not tens of millions of lines of code. The only way I can reach that number is by lobbing off a huge part of device drivers into userspace, but that's not really an interesting discussion as it seems purely subjective.
This would facilitate more innovation and ability to quickly resolve reliability issues with filesystems, make the whole “can you boot off of it or do you need a kernel module” distinction obsolete, and would massively reduce the temptation for the kernel to support certain APIs only for certain filesystems (let me inotify on procfs, and use nonblocking IO on any FS I like, dammit!)
Nonblocking I/O only makes sense for IPC. You want async I/O, which Linux doesn't support but Windows does.
I more meant that if filesystem drivers had always been external to the kernel, then it would have been harder for so many syscalls to develop filesystem-specific behavior (e.g. things that work on block FSes but not nfs/tmpfs/9pfs/procfs and so on--inotify, atimes, inode stability, sparsity, stuff like that). Being monolithic made it easier to get lots of FS-specific exceptions, which results in some things requiring you to carefully parse manpages or debug EINVALs based on where files live. The benefit of that approach is that it enabled fast development of new features, but looking back I'm not sure if it was worth it.
> Nonblocking I/O only makes sense for IPC.
I want O_NONBLOCK to not fail for disk files. It could lie and block, or only report ready once things were in the buffer cache, or only report ready once part of the VFS response came out of the hardware interrupt/command queue, or any one of several options. I don't know which if any of those count as "async I/O", but the core problem here is ubiquitous syscalls (read/open/inotify_add_watch) whose failure-or-not is contingent on the type of object you give them (blockdev file vs. non-blockdev file vs. semaphore vs. socket vs. pipe vs. timerfd and so on).
> You want async I/O, which Linux doesn't support but Windows does.
Linux kind of has async block device I/O with io_uring now, but they repeated what is basically the Linux original sin mentioned above and made it contingent on whether a device/driver/filesystem support asynchronous operation or not.
Windows overlapped I/O definitely did it first and better though.
Linux is not an operating system unto itself, but rather one more free component of a fully functioning systemd system, made useful by the systemd unit files, target definitions and vital service managers comprising a full OS as defined by Lennart Poettering.
Many computer users run a modified version of the systemd system every day without realizing it. Through a peculiar turn of events, the version of systemd which is widely used today is often called "Linux," and many of its users are not aware that it is basically the systemd system, developed by the systemd project.
There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. Chiefly systemd-udevd, systemd-journald, systemd-resolved, systemd-networkd, systemd-timesyncd, systemd-logind, systemd-homed, systemd-boot, and systemd-oomd, which decides which of your remaining programs deserve to live The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete set of systemd unit files.
Personally I use Google/Windows at work, and Steam/Windows at home. I also have a Meta/Android OS for my phone and a Garmin/Auto OS for my car.
My websites are hosted on AWS/Linux, and I browse on Comcast/Internet. My entertainment comes from Warner/Netflix. Or Disney/Disney)
I call it Linux, when I call it at all.
There really was a GNU project, but it was just an attempt to harmonize system tools across all open and proprietary Unices.
GCC, GDB, CoreUtils, etc - A COLLECTION of useful programs alongside a kernel such as Linux.
Barely relevant?
We owe our thanks to the GNU project. If Linus did not create Linux, something else would have taken it's place. "Maybe" HURD... or maybe something else.
systemd is not a project unto itself, but rather one more component of a fully functioning GNOME system, made useful by the systemd unit files, target definitions and vital service managers comprising a full OS as defined by Lennart Poettering and the Red Hat vendor lock-in team.
Linux just has too much momentum and there are too few real benefits to Hurd.
Open source continues its unbroken streak of showing us why naming things is important.
I have no idea why you think this. You might be terminally online. Hurd is just like "herd" because it's a microkernel, and hurr durr is some social media/gamer shit a tiny amount of people started saying decades after Hurd started being developed.
Anyways, HURD's biggest problems are performance and perennially missing important features (2026 and no USB support)
I grew up in one of the other ex-British colonies and we didn’t use “git” either. It’s a pretty localized word. Apparently it only came to prominence after the empire was already collapsing, so didn’t spread much.
Was there any insult that Monty Python didn't use? Some of their gags literally involved opening up the thesaurus and reciting an entry. Most of their sketches involved hurling insults at one another. It was a Petri Dish of British slang!
Maybe the name was more fitting than I realized.
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Date: 25 Aug 91 20:57:08 GMT
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones...
...PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks...The initial filesystem was minix
The kernel was Linux.
So I would say Linus had 100s of man years of ecosystem he could benefit from and that is the oss spirit.
But yeah he did not write a shell or an editor or Compiler etc and the kernel was of course oriented towards an unix like os.imagine you would have had to start from scratch, if you had just had a PC and a bios.
Like templeOS I guess
Like, the point is tech making money. You’re in the wrong place if you’re looking for something other than that.
* Apple sucks
* The internet is too centralised
* The financial system is unstable
* Browsers got a new API
* Some communist country regulated tech
ps: some slides from earlier this year https://fosdem.org/2026/events/attachments/7FZXHF-updates_on...
full vid here https://fosdem.org/2026/schedule/event/7FZXHF-updates_on_gnu...
I'm not sure this holds today. One example I can see is related to crypto. We used to have specific hardware for computing cryptography functions but it's now handled directly in standard hardware and the software has not evolved ( but it's been faster and faster to compute checksum functions )
Adding 20% to a 10 second operation is a lot longer on a wall clock than adding 20% to a 1 second operation.
If I could get a micro kernel with a better security profile than Linux, that doesn’t sound so bad. I could easily be using a ten year old chip for my day to day browsing and probably wouldn’t notice.
I suggest that you look at genode/sculpt:)
Making that fast is fundamental to any OS.
Most microkernals have methods to do IO in a different way. If they don't then likely they would pretty slow when doing I/O heavy operations.
Nginx is IO bound in general - for my headless go stateful server, i could get syscall6 up to 20% of the profile time. It was a fight between GC in the gRPC code allocating for headers and the syscall6 for top single profile footprint.
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.
Shouldn't the "hot" path fit in the L1 of a "modern" processor (100 kB+)?
From the wiki:
> 9P is perhaps not as robust or as fault tolerant as NFS
How is it not robust? What metric did they use? Fault tolerance is not explained here so I don't know what they mean by this. You can use aan(8) on 9front which runs on each side of the connection and holds it open if the network breaks, then resume on reconnect.
GuixSD with GNU Hurd would be a really fun way to repurpose an old MBP.
And there's Android.
I would look into those statistics regarding desktop world wide adoption, distribution per OS.
It gives a Linux experience within the security sandbox from Android, which is why there are limitations when using it on regular devices, via PlayStore.
Also it requires working around the NDK limitations on available POSIX APIs.
Linux is not userspace. Linux is a kernel, and android is a parallel fork of the kernel. So android is a version of linux but is not GNU/Linux.
Android/Linux, if you will. We dont have to be shy this.
GNU/Linux, the Linux desktop, has zero relevance on Android.
No one, not a single person, buying Android tablets and phones at places like MediaMarkt, cares about GNU/Linux Desktop.
They care about what apps via PlayStore, Samsung, Huawei and Xiomi stores, they can use, just like all normies.
However the recent success of gaming-related distros such as SteamOS and Bazzite seem to be succeeding where Usability-focused distros such as Mint, Pop!, and Zorin couldn't get deep traction
Ubuntu is "like Windows but not" which is mostly relevant to people boycotting Windows. Steam Deck is "a gamebox" which people who already like games might want to buy. Bazzite is "a thing that turns your computer into a gamebox." Of course, people don't actually want gameboxes either - they want to play games - but it's a few steps closer.
Also lets not forget those distros play Windows games, because hardly any studio bothers with native Linux games.
Game studios will keep buying Windows, using Visual Studio, and let Valve do the needful.
Additionally people keep acting as if Valve and Gabe will be around forever, they won't, none of us will.
https://gs.statcounter.com/os-market-share/desktop/worldwide
If you have a pro to help you, already for a long time Linux has been fine on the desktop for anyone. My parents, over 80 years old, have used Linux on their PCs for many years, and they did not even know what "Linux" is. That was possible because I installed and configured for them the operating system and all the applications they needed for reading and writing documents, Internet browsing, e-mail, music listening and movie watching etc.
Windows is easy only because it comes preinstalled. I have installed Windows at work on many kinds of computers and during installation I have encountered much more problems impossible to solve for a non-expert than when installing Linux.
Yes, the games support was rough but that is almost a non issue nowadays. Thanks to Proton and Steamdeck support, I don't even check compatibility any more on games.
There is an extra cost associated with it (I’m paying more for the same hardware), but for me totally worth it to have a functioning Linux install on delivery.
Sorry, only pun I could think of.
Once that is done, then you build out the absolutely massive collection of userspace drivers that would be needed to replace linux by leveraging LLMs and other automated techniques. The good part is that by keeping the drivers in userspace, the security risk of generative techniques for driver development is pretty low.
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.
Last neckbeards standing?
For every year development Hurd moves forward, so does everyone else's, only the they have much more resources.
Actually in all seriousness reviving dead interesting FOSS projects is one use for AI coding I've thought about.
My guess is that the GNU/HURD people are doing a lot of novel work that doesn't yet exist.
You think what they're doing isn't covered in the intersection of OS books, OS papers, other OSs, osdev, random GitHub projects?
That said, if there's a resurgence in microkernel, it will probably come from the Rust community.