Re: [9front] package install

[hiro <23hiro@gmail.com>]

wow, that's a very long life story you're sharing here. very
unexpected. but easy to read!

about the first stuff and combining plan9 stuff to do stuff at $dayjob:
definitely consider using rc, you'll learn very fast that it's in many
ways superior to bourne shell, not just in terms of features, also in
readability, expressiveness of the syntax.

and if you really get to a point where you need to run some python:
just put some `ssh shit-server python3 bla.py` into your script, don't
shy to use ssh. don't shy to use remote command execution, combine all
your OS's in whatever way is most pragmatic to you to get that shitty
job done as fast as possible :D
yes, we have a really well working ssh client at this point. one of
the many special 9front additions.

> What to do after you installed CPU/Auth + FS and make a successful Drawterm
> session. Do you split-up the FS or keep those 3 things together. If you need
> another CPU for speed just add it.

that depends what you want to do with this.

personally i was convinced i want to collaborate with others online,
while traveling around with my laptop roaming from wifi to wifi, often
with long offline periods far away from civilization.
this obviously goes against the canonical plan9 setup:

one central office where you meet the whole team on workdays and
dial-up terminals for the rare occasion (back then probably a
privilege and esp. a huge technical novelty) you have to do some work
from home. networks were more stable, had very low latency, were
always point to point and direct routing, and highly bandwidth
constrained. home computers would have likely been harder to setup,
maintain, and keeping redundent disks with enough storage would have
been extremely costly and perhaps impossible to sync the server stuff
to it with the limited bandwidth. i.e. the network was more stable,
reliable, responsive and useful than a home computer infrastructure.

this all has changed now: networks are extremely high bandwidth, have
shitty routing with very high latency, are extremely unstable,
overloaded, intermittently unavailable, or even non-existent (on the
go). we kinda demand more from our networks but we really get less
now.
so we need offline stuff to work instead. everything has to be cached
(mirrored) locally.
that's now how one central fileserver setup in plan9 works.
the code to fix this is non-existent.

i always dreamed we could make some very nice modern distributed
fileserver for this reason, something that i can share with the whole
9front team without any slowdowns (would require very intelligent
locking/cache invalidation heuristics). from a computer science pov
this is fascinating, from a feature pov it's definitely what i want to
have.

now do i really need it? corona tells me no. i stopped using laptops
in cafes. i stopped hanging out for >5 hours in trains. i stopped
playing around with mobile internet access, bec. i only use the
internet at home now.
perhaps i wanted too much, i don't know :D
i really don't feel like i need it and i feel like i shouldn't ask for it.

the only one thing that i would lack now is the collaborative aspect
and a reliability fix.
if networks were as reliable and had low enough latency as they were
during dialup times where stuff wasn't overcomissioned and you had
guaranteed service levels even for end-users (e.g. to make sure they
can call emergency services in an emergency), then i'd just drawterm
into a shared server.
that's not very viable bec. we live too far apart, and the latencies
really hurt if you go once around the world (due to geography or
shitty routing). and sometimes it stops working, that's annoying. so
i'd still like a distributed filesystem tbh. i just can't argue for it
as strongly as i used to...

> Should I gut my mac mini and install
no

> plan9 on it. That would be a pain in butt,  also a learning experience if I
> can get it done.

there's a good list of already well supported hardware in the fqa!
if you want to port to a new platform, i'd wait a bit more, it doesn't
seem there's anything interesting out there right now. and mac mini
doesn't look like something that has any future tbh :)
if you're lucky it just works anyway out of the box, and then it
wouldn't even be a learning experience.

> What’s the benefits of splitting them up. Honestly I don’t
> see any at this point.

Generally, if you can afford to run every process on a separate PC
that's ultimate isolation. And isolation is useful in many ways: be it
stability. of course we have long ago virtualised a certain level of
isolation with stuff like virtual memory, which helps with the most
common form of instability at the time...
But there's always more. You could do it for security reasons. For
scaling reasons (one PC might just not be fast enough. might explain
it historically in our case).
But even if there's less valid reasons today, you can probably still
find scenarios that benefit from the modularization that provided this
possibility in the first place.

> It seems like if you have FS on some other server it
> needs to have a fast connection.

Yes. Having only one FS is a huge reduction of complexity if you boot
many systems (imagine 10 employees with terminals being able to share
one filesystem). The dumber the terminals are the less you have to
administer them. Instead you administer ONE system (the one on the
central file server).

> Perhaps authentication since you only need
> to do that once and briefly.

Not sure what you mean. Generally I see new possibilities for
authentication in this age: I'd like to change the canonical model and
instead have a way to have multiple auth servers. For example I'd like
a mobile auth server to carry WITH ME at all times (like a hardware
security dongle).
I'd like an auth server that I can leave somewhere in the cloud, share
with friends, but that doesn't grant access to ALL MY SERVERS.
Again, that work has not been done. Everything is still built as if
one single corporation with N employees will run it.

> Then I though why have it installed at home. My business cable connection is
> slower than AWS. Can this be installed on AWS? How difficult would it be to
> build an AMI. I guess in the progress of building the AMI I would have to
> setup auth/keyfs and all of that stuff including making SSH v2 work with AWS
> keygen. So it's a lot of services to think about. But really that’s the same
> for everything else. Or would it be cheaper to host this on rat shack or
> something similar.

Some of us are hosting 9front on ovh, ramnode or vultr. It generally
works well in kvm hypervisor, and even vmware. I heard AWS mentioned
by I doubt it's any use, generally AWS seemed just hyped while
actually providing bad service for more money than ramnode or vultr.
Same for google's and microsoft's cloud offers.
Just avoid everything based on openstack also. Go for very simple
kvm-based cloud offers with local dedicated chunks of real SSD disks
(just no hipster distributed filesystems - yes i know i argue the
opposite above, but that's bec. i want something better than that for
us and believe it's possible bec. of our superior and cleaner
architecture)

Hope this helps a bit.