Re: [9front] Enabling a service

[sl@stanleylieber.com]

> And yet, the FQA recommends laptops.

the fqa lists hardware that is known to work.  most users who start
out with hardware that doesn't work never get to the stage of
complaining about what the installer does and doesn't do.  i keep
track of the stuff i've used, and share that information, just in case
someone else stumbles across the same machines.

if you'd prefer to get a taste of the pre- fqa3 plan 9 experience, you
can buy a random laptop manufactured in 2024 and report back on its
status, re: booting and running 9front.  if you do that, i'll add the
information to the hardware inventory linked in fqa3.

if instead you'd prefer the pre- 9front experience, you can keep this
information all to yourself and nobody will ever know what you
accomplished.  for the highest level of fidelity to the pre- 9front
experience, you could opt to brag vaguely about all the cool stuff you
got working on your computer, but never, ever make details or source
code available to the general public.  bonus if you lord any of this
over the newbs who are even newer to plan 9 than you are, assuring
them that, yes, all these wonderful things you're claiming you did are
trivial to accomplish in plan 9.

laptops are useful beyond the obvious use case because of they come
with built-in battery power.


> Usually the assumption with a
> laptop is you can take it on the subway or to the coffee shop and keep
> working.

you'd think so, right?  but if you read through the 9fans archives,
labs people basically blew off laptop problems as being irrelevant to
plan 9.  the system as designed never accounted for most the things
people today want to do with laptops, and not only because the system
assumes fast access to the disk file server.

here are some other unsolved, laptop-specific problems you'll encounter:

- how do i sleep and resume?	(we don't do state)
- how do i lock my screen?	(this exists, but relies on the network, lol)


> That implies that you want to have some relevant files with
> you.  (So it’s good the default install has a local filesystem.) Then
> later you get back to the home/office and maybe want to use a machine
> with a bigger monitor and more files available, but some work in
> progress is on the laptop so maybe you want to rcpu to it for a while.
> Eventually files get synced up again (manually or automatically).
> Maybe at home there is a file server, sure it’s good to have the
> dumps.  That’s probably how I’d use it as soon as I get to the point
> of depending on Plan 9 for any particular task, not just trying
> things.  (It reminds me of learning how to use Linux, 30 years ago.
> It was at a similar level of development back then.)

it's funny because all of this started with rob's experiments with
graphical terminals.  the terminal itself ran a small, custom
operating system that would be downloaded from the server at the start
of a session.  the user would do operations on data in local memory,
periodically syncing with the remote file server over the network.
there is a remnant of this design in how the sam editor's gui operates
on files.

and of course, plan 9 itself.

for many years i ran diskless terminals at home over wired ethernet
and wifi.  it was great because my environment was always the same, my
files were always exactly where i left them, and when i was finished i
could just power off the machine without worrying about unclean
shutdowns.

some people say, we have drawterm, best of both worlds!  but drawterm
also sucks when there's latency.  moody may run doom in drawterm over
local ethernet, but that's not happening over the internet.

today, i'm almost always remote, in different places at different
times.  my network is a wifi access point provided by my mobile phone.
over many years i've tried lots of different ways of running plan 9
with this setup, from tls booting over the internet, to
drawterm<->9front running in a local qemu on openbsd, etc., etc.  what
i typically do now is boot my laptop from a local disk (so, local
binaries), but all my critical work files live on the remove disk file
server i physically operate at home.  sometimes this is painfully
slow, so i'll work on files on the local disk and then sync them up.
i never, ever, need to rcpu into my terminal.  i just do whatever
syncing is necessary before i turn it off.  if i need a modern web
browser, i connect to openbsd over ssh/vnc (which is also sometimes
painfully slow).  this is far from ideal but works better than the
other combinations i've tried so far.

pick this apart, but this is me telling you what worked and didn't
work for me, and i'm happy to answer questions in detail.


> trying to preserve the labs experience

personally, i don't care at all about preserving the labs experience.
we already dumped fossil, made tons of changes.  but before you start
proposing all sorts of changes to the system it's important to
understand exactly what you're changing.  plan 9 was not designed by
idiots, or by accident.  everything that went in is the way it is for
a reason.  you may disagree with the reason, but it's important to
understand that reason before blowing it off.  and yes, people
involved with 9front will challenge you on every little detail,
because the details are important, and that's why we're all here.

this isn't linux.


> I agree that setting up a mail server should be more effort.

turning on listeners by default is bad practice.  by now, all
operating systems err on the side of this principle.  obviously, there
is leeway here when it comes to services needed to actually use the system.


>> 9p vs latency is a losing battle.  trying to run a diskless terminal
>> over the internet really, REALLY sucks.  even drawterm is not great
>> in this context.
> 
> I left a 9front machine running on my LAN in Norway while I’m in
> Phoenix for a while, and set up a wireguard vpn on the openwrt router
> in Norway so that I can connect to home.  Latency in Phoenix is worse
> than normal (Verizon wireless internet: it's only meant to be
> temporary).  Despite that, the performance I see connecting with rcpu
> or drawterm halfway around the world is comparable to connecting to
> Linux over VNC: not bad for an experiment (as long as wifi on 9front
> is not in the path!  ;-) I don’t expect to play video over that link.
> But I also have qualms about letting the router connect 9p over the
> Internet to that Plan 9 machine, since I don’t know yet all the
> varieties of half-assedness to expect by default.  I think I have to
> try the Plan 9 network forwarding at some point though, see if the
> claim that it’s as good as a VPN really holds up.  But I have to learn
> enough about security before even trying, it seems.

for a while i was actually carrying around an ipad and connecting to
9front with vnc over ssh:

	ipad -> internet -> openbsd/ssh -> ethernet -> 9front/vncs

this probably worked better than any other remote internet setup i
ever tried.  of course, you get none of the local plan 9 benefits that
way.  and no sound.

sl