having done the non-self-hosted versions of plan 9 several times now (NxM
and Harvey) I'd have to agree.

technically, the Blue Gene port was not self hosting, but maybe that's a
special case.


On Mon, Jun 2, 2025 at 3:50 PM <[email protected]> wrote:

> This has been bouncing around in my head for a bit, but it felt
> like a good time to put this in writing.
> 
> Warning, incoming screed.
> 
> So, -- Why self hosting?
> 
> 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.
> 

------------------------------------------
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T767651d6223b6d46-M087307168ad5816478fa6fc9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Reply via email to