Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Marshall Conover <marzhall.o@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3631 bytes --]

> Mounting a bin directory from some remote servers is a potential vector
for malicious code and requires all services to provide binaries for all
platforms (arm, x86, riscv,...). Instead, serving the source code and
mkfile allows for audit ability (what did I just run?) and support for
their own platform. Plan 9 compilers were designed not just to produce
optimal code but also for speed of compilation.

Would this be fast enough for what we experienced back then with early
websites, however? What with the stats on how people close or click away
from a tab within N seconds if it hasn't fully loaded yet, I'd think that
having to compile at all could've been prohibitive to people taking this
route vs. web forms. Though, I'm not sure how user behaviors or
expectations of speed were back then for the web.

I was thinking what may have eventually happened would have been an
interpreted language would pop up that would be what web applications were
written in, sort of like java applets, except not embedded in the browser,
and hopefully in a simpler language. Early web applications were also very
simple 'put info in textbox and hit enter' forms, if I remember correctly,
so a small, expandable runtime that would be quickly started up in a
sandbox might have been on equal footing with html, assuming it was indeed
able to start up and run quickly (or maybe just fork a running one into a
new namespace?). Ideally, developers could then write their own libraries
(in C or whatever they like) that the web language would hook into that
could do more powerful things - and those libraries might be the time to
provide source and makefiles, or binaries if they wanted to keep things
close to the chest.

Thinking more on the 'writing to a ctl file' idea, which I'm really getting
into, I was thinking users may have ended up making their own graphical
interfaces for web services; UIs that abstracted away the actual writing to
ctl files and put it in a GUI for less advanced users. It'd've been
interesting to see a competition in UI design among OSS interfaces for web
services, sort of like what we see today with apps for reddit on phones
(except hopefully they wouldn't all be awful). Or, maybe everyone would
just use the service-provider's provided interfaces.

Do you think there would've been fewer large databases if things had gone
this way? Just thinking on my banking example, it seems like it'd be
easiest to just have a /bank.com/users/<username> folder with the relevant
files in it that users could union-mount, since you're not forced to show
things through a web interface. Though, I suppose a bank could just expose
that folder as an interface for what's actually a DB running in the
background.

> This was however because I wanted to call a site "Troff the Crime
Blog."

I chortled.

I was wondering if maybe today a similar thing could be done with docker or
the rocket containers, but I'm not familiar enough with them; it seems like
they're somewhat baked images, not just namespaced folders with the
relevant things union-mounted inside them, so it might not be easy or fast
to just union mount the things you need for the web-app you're loading in a
new docker instance. Also, they have no UI support, thought it seems like
you can dynamically link an X socket into them to draw to an X session on
the parent machine with some extra work.

Let me know if this conversation is not really appropriate for this mailing
list at this point, by the way. I don't want to be a nuisance.

I appreciate the discussion so far - thanks!

mars

[-- Attachment #2: Type: text/html, Size: 4028 bytes --]