GNU Hurd News 2026-Q2 • Hacker News Board

Re: GNU Hurd News 2026-Q2

#161

Post by inigyou » Fri, Aug 07, 2026, 7:51 AM UTC

zbentley wrote: post #144

tremon wrote: post #129

Earlier quoted context omitted.

Ok, I'll bite. Which parts of the kernel should not be there, given that Linux is not a microkernel? I maintain that most of the code is there for hardware support, for security, or to support user-space application models. 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…

Hot take: filesystem drivers. Final stage boot should load two images: a kernel which surfaces block devices via HAL, and a one or more filesystem drivers which function as external backends for the in-kernel vfs system. 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,…

You're welcome to implement inotify for procfs right now.

Nonblocking I/O only makes sense for IPC. You want async I/O, which Linux doesn't support but Windows does.

Re: GNU Hurd News 2026-Q2

#162

Post by 927373912092 » Fri, Aug 07, 2026, 1:07 PM UTC

pessimizer wrote: post #71

stackghost wrote: post #61

Earlier quoted context omitted.

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.

> but because of the "hurr durr" connotations 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.

[dead]

Re: GNU Hurd News 2026-Q2

#163

Post by zbentley » Fri, Aug 07, 2026, 2:10 PM UTC

inigyou wrote: post #161

zbentley wrote: post #144

Earlier quoted context omitted.

Hot take: filesystem drivers. Final stage boot should load two images: a kernel which surfaces block devices via HAL, and a one or more filesystem drivers which function as external backends for the in-kernel vfs system. 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,…

You're welcome to implement inotify for procfs right now. Nonblocking I/O only makes sense for IPC. You want async I/O, which Linux doesn't support but Windows does.

> You're welcome to implement inotify for procfs right now.

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.