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-Me785883729526654906417f7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Reply via email to