Live data from Hacker News

GNU Hurd News 2026-Q2

gnu.org

61–70 of 163 posts

Re: GNU Hurd News 2026-Q2

#61
post #39
post #16

Cool to finally see some small silly tech stuff here that isn't trying to make money.

You are calling a Linux (sorry, GNU/Linux) killer small silly stuff?

I know this is in jest, but because of the "hurr durr" connotations, only the absolute most bearded of free software zealot neckbeards are going to ever run GNU Hurd beyond simplytest driving it.

Open source continues its unbroken streak of showing us why naming things is important.

Re: GNU Hurd News 2026-Q2

#62
post #56
post #40

Earlier quoted context omitted.

I'd just like to interject for a moment. What you're referring to as GNU/Linux, is in fact, just Linux.

Are you saying that Hurd will also kill Google/Linux?

What I'm saying is that Hurd is just a kernel in the same way that Linux is also just a kernel

Re: GNU Hurd News 2026-Q2

#64
post #40
post #39

Earlier quoted context omitted.

You are calling a Linux (sorry, GNU/Linux) killer small silly stuff?

I'd just like to interject for a moment. What you're referring to as GNU/Linux, is in fact, just Linux.

I’ve recently taken to calling it GNU minus Linux.

Re: GNU Hurd News 2026-Q2

#65
post #27
post #15

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.

Is that a bottleneck anymore? Maybe something that was appreciable in 1994 isn't a big performance hit in 2026?

Yes, you want to do more IPC, its basically linear with the increase in performance. So the amount of overhead stays the same basically. At least in IPC benchmarks and those tend to be important.

Making that fast is fundamental to any OS.

Re: GNU Hurd News 2026-Q2

#66
post #62
post #56

Earlier quoted context omitted.

Are you saying that Hurd will also kill Google/Linux?

What I'm saying is that Hurd is just a kernel in the same way that Linux is also just a kernel

The snark artist in me would say that Linux is a kernel plus tens of millions of lines of code that absolutely should not be in the kernel but are.

Re: GNU Hurd News 2026-Q2

#67
post #15

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.

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.

Re: GNU Hurd News 2026-Q2

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

Re: GNU Hurd News 2026-Q2

#70

I hope Hurd has its day. Maybe in 100 years or something.

Instead of rewriting Bun, maybe Anthropic should have thrown some tokens at finishing Hurd.

I hold out hope for (human) work to coalesce on creating a stable/secure microkernel (SeL4 anybody???) and getting it mature enough to build an OS on.

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.

Post reply on HN