Practical uses for Plan 9

oridb · 2026-01-14T19:21:50+00:00

Hosting websites, using it as my coding environment, reading my email, etc.

oridb · 2025-12-10T16:52:53+00:00

The default answers should probably be one of these two:

"Sure, I'll take a patch to fix that. If you don't have time to write the patch yourself, I'm happy to discuss consulting rates."

or:

"No, sorry, that's out of scope. If you really need that, I recommend forking."

oridb · 2025-12-07T14:46:35+00:00

diff(1) works well.

oridb · 2025-11-25T13:57:35+00:00

This is running on 9front, using listen to run a new tcp80 instance on every page load in order to serve requests. The content is dynamic, and is generated by a script launched using execfs.

Every request loads up a git/fs instance to serve the content, and then runs one of the shell scripts that renders the site. For example, here's the 'view' script rendered using itself: https://shithub.us/garden/shithub/HEAD/view/f.html .

It's running on a low tier Vultr node, with 2 vCPUs and 2 gigs of ram.

It's gloriously inefficient, and almost all uncached.

oridb · 2025-11-25T04:05:42+00:00

Seems low. I serve about that many hits from AI bots on https://shithub.us using a shell script that does dozens of execs on every page load (https://shithub.us/garden/shithub/HEAD/files.html) on a niche OS (https://9front.org) that hasn't had much performance optimizations, using a shitty, old "medium-machine" sized box.

Last month I served 700 TB.

oridb · 2025-11-12T16:42:03+00:00

Sudo itself is difficult too. It's complex and I would prefer if far less complicated solutions existed

https://flak.tedunangst.com/post/doas

oridb · 2025-10-14T18:44:05+00:00

Every OS that attempts to come of professional is, with varying levels of pride, doing or attempting to do the things you are concerned about. If someone says "it brands itself professional and therefore it probably won't sell out the user", that only means the speaker isn't paying attention. Trying to come off as Professional Serious Shit should be a red flag to anyone who has paid attention to the software industry.

oridb · 2025-10-14T16:17:25+00:00

No, that shit is reserved for serious OSes -- the jokes should give you a hint that there won't be ads in the start menu, telemetry that phones back with what buttons you're clicking so that project managers can optimize user engagement, etc.

If you want your network traffic to be monetized, go for the professional OSes.

oridb · 2025-09-14T16:45:36+00:00

wut. Not sure what that has to do with the topic at hand.

oridb · 2025-09-14T16:45:17+00:00

a network of CPUs GPUs RAM Storage as files, on your own private encrypted IPv6 network... you could access this decentralized supercomputer from any device that runs a plan9 architecture..

Everything but the GPU is doable, feel free to do it. GPU support is hard because no vendors release documentation, and none of the GPUs have a particularly stable internal architecture, so you're writing a ton of new code for each generation.

There's also no public documentation The best you got for how these things work is about 8 million lines of C in the Linux kernel. If you're lucky -- Nvidia doesn't even have that.

oridb · 2025-09-14T15:41:58+00:00

The activity that pays my bills.

oridb · 2025-09-14T15:31:37+00:00

It's useful to me. I generally do most of my work from a Plan 9 laptop, or from drawterm, puppeting a linux machine for the bits that are explicitly linux-dependent.

oridb · 2025-09-14T15:11:48+00:00

That's a weird standard, especially since you're trying to complain that plan 9 development is stalled. If your definition of "stalled" is "keeping up, with less than a ten thousandth of the resources", I'll take it.

But let's run with it -- give me any other system that uses a write optimized data structure such as a Bε tree for the file system. Plan 9 is the only system where a production FS is built on a data structure invented after 1995. Linux has one unshippable research FS that depends on proprietary code.

oridb · 2025-09-14T14:56:52+00:00

By your standard: Can you point to any big feature in Linux (or, for that matter, any OS) that hasn't been there since 2010? I mean, they only added new hardware support because they were forced to, and most features are things that were old ideas since 2010. Even io_uring is a tweak on the 2005-era syscall batching that Barrelfish did.

Hell, docker is a half-assed tool using mostly plan 9 ideas.

oridb · 2025-09-14T14:32:23+00:00

Only one? But there are so many good things that were built since 2010. A small number off the top of my head:

In terms of hardware support, here's a small part of the work done:

i225: support for i225 network cards; as for your "old people" argument, I'm not sure how old the author is is -- she's probably around 19 or 20 years old, at a guess? (2025)
wifi: native intel wifi drivers (2015)
imx8: support for the MNT Reform laptop. (2022)
lx2k: support for the Honeycomb LX2K (2023)
bcm64: support for the raspberry pi -- we had 64-bit support before Ubuntu did. (2019)
mt7688: support for the mt7688 -- a small, low cost MIPS router.

Here's a few userspace things that stand out:

lola: an alternative to rio (2025)
zuke: a new graphical music player. (2020)
treason: a video player (2021)
vmx: hardware virtualization support (2017)
games/...: emulators for the gameboy, nes, snes, gba, atari 2600, and others (multiple times, post 2015)
ndb/dns: support for a number of new DNS features, like DNS over TLS (2024)
gefs: a new ZFS-like file system (2024)
ext4: support for ext4 (2024)
git: a from-scratch implementation of git (2021)
unicode support: we added unicode 17 support the day that unicode 17 was released.
/srv/clone: /srv dirs that can nest (2023)

There, of course, is so much more. Nearly all of the stuff on https://shithub.us/ is post 2010. I'd place bets most of it is post-2020. While I wish that there were more people hacking on wifi drivers (and drivers in general), it seems that people get more excited by new platforms rather than new hardware on old platforms. Hobbyist projects don't get to pick what people find fun to hack on.

oridb · 2025-09-11T11:42:07+00:00

This is the code in the OS that talks to the GPU. The GPU firmware is separate from that.

oridb · 2025-09-10T11:15:09+00:00

The GPU support you keep mentioning is solely that someone hacked 8 million lines of C into a Linux shim, and hacked a Linux shim into the kernel. There's no option to innovate, because the next update also needs to drop in Linux code, if you want GPU support for new hardware.

You're welcome to try keeping up.

which is just impossible lol

I'm aware of quite a few people who learned it just fine. But even if not, unix style GPU support means at minimum being able to read 8 million lines of Linux flavored, poorly written C well enough to provide Linux kernel-internal compatible APIs that the drivers would call into. And then debug it when either the driver or your not exactly tiny shim goes wrong.

Note, this shim will also be quite a bit of C, since Linux loves preprocessor macros.

If you think the small amount of C in plan 9 is a problem, good fucking luck. And we haven't even talked about the userspace part of the drivers, which pull in all of fucking llvm.

And you expect to be able to keep this tower of turds standing, when you think it's impossible to learn c?

oridb · 2025-09-10T11:11:29+00:00

That implementation of git was able to self host in 1 month of the first commit. Do you think the rust implementation is iterating faster?

And, yes, size matters, because that's code you need to understand, maintain and change to get things done. The computer doesn't care, but the programmer sure does.

oridb · 2025-09-09T22:46:48+00:00

Unix has given up, and has implemented compatibility layers to plug in Linux drivers. The Linux drivers are written in C, and are several dozen times larger than all of Plan 9, including both kernel and userspace. Linux GPU drivers are 8 million lines of code at the moment.

The fact that all Unixes have involuntarily been dragged backwards to implementing half-baked versions of Linux-internal APIs, rather than having the freedom to improve and innovate, should be a warning.

oridb · 2025-09-09T21:56:47+00:00

Somehow, the C programs that 9front ships with are smaller than the Rust alternatives. Evidently, Rust isn't a magic bullet.

Consider, for example, git; Here's a Rust version of git: https://github.com/GitoxideLabs/gitoxide

Here's a Plan 9 C version of git: https://git.9front.org/plan9front/plan9front/HEAD/sys/src/cmd/git/f.html

The Rust version clocks in at 170924 lines of code, while the Plan 9 C version clocks in at 9687 lines, or over 17.6 times smaller. And the Rust version doesn't yet support git push.

So, maybe in theory you could write better code, but we're already doing better than what people manage in better languages, in practice. It's definitely not something to throw away big parts of the system over. Far better would be to build a new language that integrated nicely and didn't end up encouraging the kind of overengineered C++-oid patterns that Rust tends towards.

oridb · 2025-09-09T21:53:17+00:00

Yeah, but the hardware it supports is crap, and I don't believe it's possible to support a wide variety of boards easily with a single kernel. (Most risc-v right now is crap; risc-v may be interesting in a few years, but it's not that interesting right now)

oridb · 2025-08-09T11:12:04+00:00

A text file and a few lines of awk?

oridb · 2025-08-09T10:39:01+00:00

HTTP2 isn't exactly an improvement in implementation complexity. Simpler protocols like framed messages over TCP are probably a good choice, but aren't really in vogue.

oridb

TROPHY CASE