why self-host 9front

orib.dev: Why Self-Host 9Front?

In short: Because if you don’t use it, how will you know what the rough edges are? If you can’t be bothered to use the system, why would you stick around to hack on it? The theme we see over and over again is that nothing useful gets done without first getting to know the system, and learning how to use it. Trying to find a way to shortcut people learning is a self-own. It doesn’t help – it undermines. It shows that we don’t even think this system is worth using ourselves. If even the plan 9 developers don’t want to use the system, why would anyone else want to? In 9front, we host almost all parts of our development process on 9front – the git repositories, the mailing list, the ci/cd, the web site, and everything else. (The exception is #cat-v IRC) We use the system regularly, both when hacking on the system and in our personal use. Personally, I write most of my code on Plan 9, read my emails there, and often drive Linux from there. I run my home network off of a 9front CPU server, and host my websites off it. I know other people around 9front do similar. It’s not the only system we use, but it is a system we interact with daily, to get significant portions of our day to day computing needs accomplished. And as we see the other systems we use get enshittified, and we find the time to build the missing pieces, we slowly move more and more of our environment over to 9front. The system improves, and our lives along with it. As a result, we get a lot of improvements put into the system, and things rapidly get more usable over time. Several examples of this:

• Because of AI crawlers hitting shithub and generating a good deal of load, we found several issues with our system under load, including (most recently) a bug in error handling when we oom-kill big processes.
• Because coraid used upas for their corporate mail, nupas was written – now, I can actually load all of my email history in less than 12 hours.
• Because tailscale wanted a fun April Fool’s prank, we got monotonic time. Trying to use Plan 9 for an April Fool’s prank got more done towards Go working smoothly on Plan 9 than I’ve seen in years.
• Because we wanted to be able to hook in some Linux every now and then, we gained support for running VMs. And because some of us use vmx on wifi, we added the MAT Daemon – the tool for doing mac address translation on wifi. This is a capability that other OSes don’t have, and it makes networking on VMs much more pleasant.
• Because I wanted to get TLS certificates painlessly, 9front now ships with auth/acmed. It’s one of the only acme clients that supports DNS based auth painlessly.
• Because we wanted to test gefs using Go’s file system and build tests, we found several race conditions and bugs in unrelated utilities, including a long-standing cras around semaphores and task switching
• Because I wanted to read my emails and kept losing them, acme mail got a rewrite, and now supports threaded views
• Because I wanted to develop on some portable projects that ran on both Unix and Plan 9, I wrote git.
• Because several people in 9front use it as their home router, we got NAT support in the kernel. The list goes on and on. The repeated theme is that people find themselves wanting to accomplish a goal, solving a problem for themselves in their day to day lives, and with a little bit of work, we end up putting together a solution. Usually, the solution we end up with ends up being more pleasant than what we find on many competing systems. And because these changes are driven by concrete needs of real users and 9front hackers, there isn’t much need for trying to “rally the troops”; people already know what their needs are, the issue is finding the time to address the needs, and getting the design right so that we don’t end with a system composed of a collection of warts. 9front is developed via “I’m doing this, thoughts?”, and not “you should do this”. Often, the person who writes the patch isn’t the one who tried to use the system, but someone who learned enough to get the hang of how to do things, and then asked specific, well formed questions about how to accomplish a goal. Usually, the answer is “like this”, often the answer is “we have a better way to solve the problem”, but sometimes, the answer is “oh, that sucks – but we can fix it”. However, using the system needs to come first. Without regular use, everything falls apart – bitrot sets in. Using things is necessary to keep things usable. And if things aren’t usable, people are going to try it, shrug their shoulders, and wander off to use something that works.