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...GuixSD with GNU Hurd would be a really fun way to repurpose an old MBP.
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.
Actually in all seriousness reviving dead interesting FOSS projects is one use for AI coding I've thought about.
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 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.
That said, if there's a resurgence in microkernel, it will probably come from the Rust community.
Like, the point is tech making money. You’re in the wrong place if you’re looking for something other than that.
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.
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.
Last neckbeards standing?
For every year development Hurd moves forward, so does everyone else's, only the they have much more resources.
My guess is that the GNU/HURD people are doing a lot of novel work that doesn't yet exist.
Linux just has too much momentum and there are too few real benefits to Hurd.
Like templeOS I guess
Open source continues its unbroken streak of showing us why naming things is important.
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.
Making that fast is fundamental to any OS.
You think what they're doing isn't covered in the intersection of OS books, OS papers, other OSs, osdev, random GitHub projects?
Shouldn't the "hot" path fit in the L1 of a "modern" processor (100 kB+)?
* Apple sucks
* The internet is too centralised
* The financial system is unstable
* Browsers got a new API
* Some communist country regulated tech
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.
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.
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.
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.
https://gs.statcounter.com/os-market-share/desktop/worldwide
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.
I gave a conference talk about this about 4 years ago. There may be slight errors in my recollection
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.
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
Maybe the name was more fitting than I realized.
And there's Android.
Anyways, HURD's biggest problems are performance and perennially missing important features (2026 and no USB support)
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.
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.
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 really was a GNU project, but it was just an attempt to harmonize system tools across all open and proprietary Unices.
Sorry, only pun I could think of.
Also lets not forget those distros play Windows games, because hardly any studio bothers with native Linux games.
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.
I suggest that you look at genode/sculpt:)
I would look into those statistics regarding desktop world wide adoption, distribution per OS.
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.
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.
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.
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!
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.
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.
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!)
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.
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.
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.
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 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.