9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
@ 2016-10-01 20:17 Marshall Conover
  2016-10-01 20:21 ` Jules Merit
  0 siblings, 1 reply; 22+ messages in thread
From: Marshall Conover @ 2016-10-01 20:17 UTC (permalink / raw)
  To: 9fans

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

> I was browsing of my old plan 9 mail and this conversation from 2000 made
me think of your thread here:  https://goo.gl/PO85oD

That conversation was interesting! It seemed Matt was a pretty prescient
guy. The "supports the latest standards...whose?" bit gave me a chuckle.

There wasn't too much in the way of directed conversation about what
different implementations of the web could've been, sadly, though there
were some - more just how feasible it'd be to implement the web as it was
on plan 9. I'm sure whatever Rob's intern was working has been lost to time.

Thanks for finding it!

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-10-01 20:17 [9fans] Questions on the browser as a platform if plan 9 had gained marketshare Marshall Conover
@ 2016-10-01 20:21 ` Jules Merit
  0 siblings, 0 replies; 22+ messages in thread
From: Jules Merit @ 2016-10-01 20:21 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

"Whose?" white horse 112 1:19pm ring a bell?

On Oct 1, 2016 1:19 PM, "Marshall Conover" <marzhall.o@gmail.com> wrote:

> > I was browsing of my old plan 9 mail and this conversation from 2000
> made me think of your thread here:  https://goo.gl/PO85oD
>
> That conversation was interesting! It seemed Matt was a pretty prescient
> guy. The "supports the latest standards...whose?" bit gave me a chuckle.
>
> There wasn't too much in the way of directed conversation about what
> different implementations of the web could've been, sadly, though there
> were some - more just how feasible it'd be to implement the web as it was
> on plan 9. I'm sure whatever Rob's intern was working has been lost to time.
>
> Thanks for finding it!
>
>

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-10-01 15:03 ` James A. Robinson
@ 2016-10-01 15:05   ` James A. Robinson
  0 siblings, 0 replies; 22+ messages in thread
From: James A. Robinson @ 2016-10-01 15:05 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

Oh, and for anyone who hates web pages but were on the mailing list back
then, it is the "[9fans] Gecko based web browser" thread from 2000-07-18.
 :-P

On Sat, Oct 1, 2016 at 8:03 AM James A. Robinson <jimr@highwire.org> wrote:

> I was browsing of my old plan 9 mail and this conversation from 2000 made
> me think of your thread here:  https://goo.gl/PO85oD
>

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-17 15:19 Marshall Conover
  2016-09-17 16:23 ` Chris McGee
  2016-09-17 17:04 ` hiro
@ 2016-10-01 15:03 ` James A. Robinson
  2016-10-01 15:05   ` James A. Robinson
  2 siblings, 1 reply; 22+ messages in thread
From: James A. Robinson @ 2016-10-01 15:03 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

I was browsing of my old plan 9 mail and this conversation from 2000 made
me think of your thread here:  https://goo.gl/PO85oD

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-22 22:49       ` michaelian ennis
@ 2016-09-22 22:53         ` Chris McGee
  0 siblings, 0 replies; 22+ messages in thread
From: Chris McGee @ 2016-09-22 22:53 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Wow,

That sounds cool.

Thanks,
Chris

> On Sep 22, 2016, at 6:49 PM, michaelian ennis <michaelian.ennis@gmail.com> wrote:
> 
> Not exactly what you meant but Coraid did implement a something like this that had 9p on it.  Sort of.  It was an ARM based PCIe card spoke 9p over something like IL without the IP (bwc called it EL) using network ports on the card.  
> 
> Sometimes they appear on ebay as "coraid mass storage NIC" or some such.  Not the repurposed SuperMicro Cards but something that looks mor complicated with a SO-DIMM socket on it. 
> 
> The ARM CPU was also used for other services running on/for the platform that were performed by the card.  The card could be powered by POE so the chassis could be powered down and the card could still be accessed. The firmware on the card was, IIRC, not quite plan9 but constructed mostly from plan9.
> 
> Ian




^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-20 17:42     ` Chris McGee
@ 2016-09-22 22:49       ` michaelian ennis
  2016-09-22 22:53         ` Chris McGee
  0 siblings, 1 reply; 22+ messages in thread
From: michaelian ennis @ 2016-09-22 22:49 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

Not exactly what you meant but Coraid did implement a something like this
that had 9p on it.  Sort of.  It was an ARM based PCIe card spoke 9p over
something like IL without the IP (bwc called it EL) using network ports on
the card.

Sometimes they appear on ebay as "coraid mass storage NIC" or some such.
Not the repurposed SuperMicro Cards but something that looks mor
complicated with a SO-DIMM socket on it.

The ARM CPU was also used for other services running on/for the platform
that were performed by the card.  The card could be powered by POE so the
chassis could be powered down and the card could still be accessed. The
firmware on the card was, IIRC, not quite plan9 but constructed mostly from
plan9.

Ian

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-19 22:00 Marshall Conover
@ 2016-09-21  3:11 ` Chris McGee
  0 siblings, 0 replies; 22+ messages in thread
From: Chris McGee @ 2016-09-21  3:11 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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


> 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 have a couple of ideas in this area. If a more guided interface is needed then when you mount a service you can hook up a console to a file using "con" command allowing for interactive prompts such as "enter search criteria" and responses. Still no remote code required.

Another option is to provide a readme.txt file describing the service, relevant files, etc. Inside that document are examples of shell commands that you can run.

echo 'search cat pictures' >> ctl

Open the readme in acme, edit the examples, select and middle click on it and it runs the command. You learn how to use the service and again, there is no remote command execution other than what you selected and ran.

> 
> 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.

That's possible that an interpreted language would have taken off. With OS level sandboxing, hopefully people run these within the sandboxes, providing access the minimal set needed for the service.

> 
> 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.

I think that many GUI's were created to hide ugly, inconsistent and large layers underneath. I have a hypothesis that if you start with a small, well designed system with a simple interface that people can and will use it of the alternative is a system that is brittle, complex and allows accidental security breaches at the click of a button. Textual interfaces can good and usable, with a bit of learning. Add graphics only when the problem warrants it (eg. CAD) or it truly simplifies the interface.

> 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.

The bank may expose files, but it doesn't necessarily mean you can edit them like simple text files. Plan 9 has some really interesting paradigms with read only files, updating using control file protocols, append only files, file descriptors that return errors for invalid writes. I've only scratched the surface. It could be a really interesting project to write up how different paradigms work for certain scenarios.

Chris

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-20 16:48 Marshall Conover
@ 2016-09-20 19:46 ` hiro
  0 siblings, 0 replies; 22+ messages in thread
From: hiro @ 2016-09-20 19:46 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

It's all based on their new language go.

On 9/20/16, Marshall Conover <marzhall.o@gmail.com> wrote:
>>  Ken and rob are currently working at google trying to
> make sure it stays so - the idea being that if the stupid people that
> control the real OS can't be made to learn at least they'll make
> themselves an abstract environment that can hide the past and all the
> pain, to then work on interesting, more challenging ideas on the
> higher level (in the web) without distractions.
>
> So, to make sure I understand correctly, the idea is to leave the actual OS
> behind, and have all future development done entirely in the web, with the
> browser as an application platform/web services being the OS, and finding a
> way to make web services more composable? And this is being actively worked
> on by Rob and Ken? I'm tempted to somehow work in the 9front release title
> "Why not as a JS library?"
>
> Is there any more information on this? I'd be interested in seeing what a
> design like that would be like, and what challenges they're trying to
> address. The browser as a platform and the technologies around it seem like
> such a kludge after 20-some years of incremental, meandering progress, I'd
> think there might be a lot of difficulty trying to base a simple, solid
> system on them. Then again, I'm not a web dev, so I could be
> misunderstanding what goes on in that domain entirely.
>
> Thanks again!
>
> mars
>



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-20  6:16   ` David Pick
@ 2016-09-20 17:42     ` Chris McGee
  2016-09-22 22:49       ` michaelian ennis
  0 siblings, 1 reply; 22+ messages in thread
From: Chris McGee @ 2016-09-20 17:42 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I was thinking more along the lines of hardware implementation of 9P minus any OS. For example, a disk serves up a filesystem via 9P or an Ethernet device serving a /net with 9P.

Chris

> On Sep 20, 2016, at 2:16 AM, David Pick <D.M.Pick@qmul.ac.uk> wrote:
> 
>> On 19/09/16 21:55, Chris McGee wrote:
>> 
>> <snip>
>> 
>> Maybe 9P could be implemented in a SoC.
> 
> It already has: the Raspberry Pi is built round a SoC...
> ...all that's needed is to boot from SoC ROM instead of the SD card.
> 
> -- 
> David Pick
> Network Security Manager, IT Services
> Queen Mary University of London
> Tel: +44 (0) 20 7882 7079
> Mob: +44 (0) 7973 379 161
> E-Mail: D.M.Pick@qmul.ac.uk
> 
> Normal working days are Monday to Wednesday inclusive
> 
> Worried about Cyber Security? Check out the
> Cyber Security Information and Training described at
> http://connect.qmul.ac.uk/qmandyou/staff/items/2016/item177974.html
> 
> 




^ permalink raw reply	[flat|nested] 22+ messages in thread

* [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
@ 2016-09-20 16:48 Marshall Conover
  2016-09-20 19:46 ` hiro
  0 siblings, 1 reply; 22+ messages in thread
From: Marshall Conover @ 2016-09-20 16:48 UTC (permalink / raw)
  To: 9fans

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

>  Ken and rob are currently working at google trying to
make sure it stays so - the idea being that if the stupid people that
control the real OS can't be made to learn at least they'll make
themselves an abstract environment that can hide the past and all the
pain, to then work on interesting, more challenging ideas on the
higher level (in the web) without distractions.

So, to make sure I understand correctly, the idea is to leave the actual OS
behind, and have all future development done entirely in the web, with the
browser as an application platform/web services being the OS, and finding a
way to make web services more composable? And this is being actively worked
on by Rob and Ken? I'm tempted to somehow work in the 9front release title
"Why not as a JS library?"

Is there any more information on this? I'd be interested in seeing what a
design like that would be like, and what challenges they're trying to
address. The browser as a platform and the technologies around it seem like
such a kludge after 20-some years of incremental, meandering progress, I'd
think there might be a lot of difficulty trying to base a simple, solid
system on them. Then again, I'm not a web dev, so I could be
misunderstanding what goes on in that domain entirely.

Thanks again!

mars

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-19 12:44 Marshall Conover
  2016-09-19 17:25 ` Chris McGee
  2016-09-19 20:55 ` Chris McGee
@ 2016-09-20  8:09 ` hiro
  2 siblings, 0 replies; 22+ messages in thread
From: hiro @ 2016-09-20  8:09 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> Well, since everyone is trying to make the web the OS - see the chrome
> boxes, for example - why not cut out the middleman and just have the OS
> doing things? It seems like it's going to happen no matter what.

Well, it's happened, so now we have two shitty OS: chrome on top of
mac os x. Naturally interoperability between different programs from
the web and anything else (even other programs in the web) is
non-existent. Ken and rob are currently working at google trying to
make sure it stays so - the idea being that if the stupid people that
control the real OS can't be made to learn at least they'll make
themselves an abstract environment that can hide the past and all the
pain, to then work on interesting, more challenging ideas on the
higher level (in the web) without distractions.

Please correct me if I'm wrong, my googleinos :)



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-19 20:55 ` Chris McGee
  2016-09-20  6:16   ` David Pick
@ 2016-09-20  7:47   ` hiro
  1 sibling, 0 replies; 22+ messages in thread
From: hiro @ 2016-09-20  7:47 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> Also, external storage (hdd, ssd) with a built in filesystem exposed as 9P.
> UTF-8 file names, of course.

already exists, see coraid.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-19 20:55 ` Chris McGee
@ 2016-09-20  6:16   ` David Pick
  2016-09-20 17:42     ` Chris McGee
  2016-09-20  7:47   ` hiro
  1 sibling, 1 reply; 22+ messages in thread
From: David Pick @ 2016-09-20  6:16 UTC (permalink / raw)
  To: 9fans

On 19/09/16 21:55, Chris McGee wrote:

> <snip>
>
> Maybe 9P could be implemented in a SoC.

It already has: the Raspberry Pi is built round a SoC...
...all that's needed is to boot from SoC ROM instead of the SD card.

--
David Pick
Network Security Manager, IT Services
Queen Mary University of London
Tel: +44 (0) 20 7882 7079
Mob: +44 (0) 7973 379 161
E-Mail: D.M.Pick@qmul.ac.uk

Normal working days are Monday to Wednesday inclusive

Worried about Cyber Security? Check out the
Cyber Security Information and Training described at
http://connect.qmul.ac.uk/qmandyou/staff/items/2016/item177974.html




^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
@ 2016-09-19 22:00 Marshall Conover
  2016-09-21  3:11 ` Chris McGee
  0 siblings, 1 reply; 22+ messages in thread
From: Marshall Conover @ 2016-09-19 22:00 UTC (permalink / raw)
  To: 9fans

[-- 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 --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-19 12:44 Marshall Conover
  2016-09-19 17:25 ` Chris McGee
@ 2016-09-19 20:55 ` Chris McGee
  2016-09-20  6:16   ` David Pick
  2016-09-20  7:47   ` hiro
  2016-09-20  8:09 ` hiro
  2 siblings, 2 replies; 22+ messages in thread
From: Chris McGee @ 2016-09-19 20:55 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

If plan 9 had taken off I wonder if there would be peripherals with built-in 9P support.

For example, a network adapter that you can mount into /net/etherxyz over USB, PCI using a 9P connection. No driver needed, except to communicate with the bus.

Also, external storage (hdd, ssd) with a built in filesystem exposed as 9P. UTF-8 file names, of course.

Maybe 9P could be implemented in a SoC.

Chris



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-19 12:44 Marshall Conover
@ 2016-09-19 17:25 ` Chris McGee
  2016-09-19 20:55 ` Chris McGee
  2016-09-20  8:09 ` hiro
  2 siblings, 0 replies; 22+ messages in thread
From: Chris McGee @ 2016-09-19 17:25 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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


> 
> > You just mount search engine, route planning tool, or even shopping site and echo commands into the ctl file. 
> 
> I hadn't thought of this - was more thinking on the user union mounting, say, google.com/bin into their bin directory and running a google operation. The concept of just echoing into a ctl file is really interesting from a security perspective.

Right, in this case there is no remote code execution. Web users run all kinds of code they are unaware of today. It's a major problem.

It also helps to create a certain uniformity and expectation of how services should work.

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.

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-17 18:51   ` Jules Merit
@ 2016-09-19 17:11     ` michaelian ennis
  0 siblings, 0 replies; 22+ messages in thread
From: michaelian ennis @ 2016-09-19 17:11 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

On Sat, Sep 17, 2016 at 11:51 AM, Jules Merit <
jules.merit.eurocorp.us@gmail.com> wrote:

> Troff + net,
>
This spring (in the northern hemisphere) I had toyed with the notion of
using troff as an intermediate format for publishing public record data
sets.  This was however because I wanted to call a site "Troff the Crime
Blog."  True story.

Ian

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
@ 2016-09-19 12:44 Marshall Conover
  2016-09-19 17:25 ` Chris McGee
                   ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Marshall Conover @ 2016-09-19 12:44 UTC (permalink / raw)
  To: 9fans

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

Thanks, Chris! That was a lot more detailed than I had thought into it.

> You just mount search engine, route planning tool, or even shopping site
and echo commands into the ctl file.

I hadn't thought of this - was more thinking on the user union mounting,
say, google.com/bin into their bin directory and running a google
operation. The concept of just echoing into a ctl file is really
interesting from a security perspective.

> Multimedia documents with both pictures and text are compiled into self
contained files kind of like PDF without hyperlinks and arbitrary code
expectation... This rich format is for longer and more focused reading
sessions: studying a topic, leisure reading.

I had originally been thinking along these lines, but the more I think
about it, the more I think there would have been a lot of demand for flashy
displays, and so I think something like a library for a flash-like language
that users would execute would've popped up. While I think users could've
gotten used to normal text (and it actually may have been more intuitive,
especially for older, non-technical people who are distracted by flashy
things), I think the people paying for development would've wanted more,
including graphics and animations.

>Also, services are designed to be focused enough and standard enough that
they can be easily interact with other services using pipes, redirects,
etc. so that the user can combine them to suit their needs.

This would've been amazing.

> Single signon is achieved using symmetric encryption. If the service
recognizes your public key and you are able to sign a message using your
private key you can proceed. Not sure how much overlap there is here with
what is in tls and factotum. Something like factotum could be useful to
allow you to specify different keys (identities) for different services.

This would be interesting, as well, when combined with network+union
filesystems, for being able to do something like run a website like reddit
with pointers to files hosted by users themselves. The possible advantage I
was thinking about is that a user could post comments as files stored on
their local accounts with group permissions they can specify, allowing them
to only have their friends see those files; the 'reddit' site would only
host the file pointers, and people would only be able to see those comments
on the reddit reader-app if they had the correct permissions. Usrers could
then delete their comments at will without worrying about the site holding
onto them in old DB backups or the like.

Thanks, also, Hiro!

> There is nothing wrong with the web having a limited scope of features.

Well, since everyone is trying to make the web the OS - see the chrome
boxes, for example - why not cut out the middleman and just have the OS
doing things? It seems like it's going to happen no matter what.

> If they are on par, then why waste time with the web part?

Well, that's the point, isn't it? You can access applications from
anywhere, and you don't need a browser to act as a platform to do it. You
also don't need to install them using some wizard and registry and all the
other BS.

> security and privacy in the web is hopeless. it plainly was never a real
goal.

Would plan9 have made it reasonable to become one?

> popular things tend to drive people. doesn't say anything about the
technical or even educational qualities though.

I think this is a good point. I was also thinking that ease-of-entry would
likely have developed more on the application side if more people had been
using it.

> Plan 9 technically is just one small collection of more consistent
alternative building blocks, but the web has ignored, reinvented or
misunderstood most others, too.

Yeah, this is sort of why I've been thinking about this. I've almost begun
getting frustrated when I see all the redundant design in the browser that,
at least it seems, could've just been done with the OS. Every time a friend
or intern pings me with a web problem, it seems more and more like the web
is just a series of kludges from trying to make the newspaper man be a
song-and-dance man who gives you live television.

Thanks for the thoughts!

mars

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-17 17:04 ` hiro
@ 2016-09-17 18:51   ` Jules Merit
  2016-09-19 17:11     ` michaelian ennis
  0 siblings, 1 reply; 22+ messages in thread
From: Jules Merit @ 2016-09-17 18:51 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

Troff + net, I added ideas from vrml's for AR glasses I use for HUD
documents as I look off monitor still bashing the keyboard. Web proxy for
format translation.

On Sep 17, 2016 10:06 AM, "hiro" <23hiro@gmail.com> wrote:

> It's hard to have a technical argument about this, because technical
> consideration was never a big driver of web "technologies".
>
> > Web programming would have also have started off with far greater ability
> There is nothing wrong with the web having a limited scope of features.
>
> > Web games, video-streaming applications, etc. on par with local
> applications
> If they are on par, then why waste time with the web part?
>
> > waiting years for even simple things to be standardized
> They never actually did wait. What they implemented instead was always
> horrible, and the incompatible standards created after the fact just
> make it even worse.
>
> > cookies and other privacy issues
> > sandboxed
> security and privacy in the web is hopeless. it plainly was never a real
> goal.
>
> > beneficial to getting them into programming
> popular things tend to drive people. doesn't say anything about the
> technical or even educational qualities though.
>
> > [...] friends in web development, they
> > have expressed concerns about ease-of-use [...]
> In this case they are liars. i know no single web developer who cares
> about ease-of-use.
>
> > system languages did not [...attract] them.
> it's not for everyone to design systems. but they still managed (if i
> am to believe you against their will) to waste their time doing
> redundant system development, reinventing poorly what we already had,
> which they couldn't find enough motivation to learn about.
>
> "the plan 9 way" is often only used in the sense of being consistent.
> This, elegance and cleanness is rarely seen in software, hardly
> evaluated and only often demanded. But some principles are just
> polished unix ideas and many others did exist before.
>
> Plan 9 technically is just one small collection of more consistent
> alternative building blocks, but the web has ignored, reinvented or
> misunderstood most others, too.
>
>

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-17 15:19 Marshall Conover
  2016-09-17 16:23 ` Chris McGee
@ 2016-09-17 17:04 ` hiro
  2016-09-17 18:51   ` Jules Merit
  2016-10-01 15:03 ` James A. Robinson
  2 siblings, 1 reply; 22+ messages in thread
From: hiro @ 2016-09-17 17:04 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

It's hard to have a technical argument about this, because technical
consideration was never a big driver of web "technologies".

> Web programming would have also have started off with far greater ability
There is nothing wrong with the web having a limited scope of features.

> Web games, video-streaming applications, etc. on par with local applications
If they are on par, then why waste time with the web part?

> waiting years for even simple things to be standardized
They never actually did wait. What they implemented instead was always
horrible, and the incompatible standards created after the fact just
make it even worse.

> cookies and other privacy issues
> sandboxed
security and privacy in the web is hopeless. it plainly was never a real goal.

> beneficial to getting them into programming
popular things tend to drive people. doesn't say anything about the
technical or even educational qualities though.

> [...] friends in web development, they
> have expressed concerns about ease-of-use [...]
In this case they are liars. i know no single web developer who cares
about ease-of-use.

> system languages did not [...attract] them.
it's not for everyone to design systems. but they still managed (if i
am to believe you against their will) to waste their time doing
redundant system development, reinventing poorly what we already had,
which they couldn't find enough motivation to learn about.

"the plan 9 way" is often only used in the sense of being consistent.
This, elegance and cleanness is rarely seen in software, hardly
evaluated and only often demanded. But some principles are just
polished unix ideas and many others did exist before.

Plan 9 technically is just one small collection of more consistent
alternative building blocks, but the web has ignored, reinvented or
misunderstood most others, too.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
  2016-09-17 15:19 Marshall Conover
@ 2016-09-17 16:23 ` Chris McGee
  2016-09-17 17:04 ` hiro
  2016-10-01 15:03 ` James A. Robinson
  2 siblings, 0 replies; 22+ messages in thread
From: Chris McGee @ 2016-09-17 16:23 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

Hi,

I have been pondering the same kind of thing myself lately. In an alternate bizarro universe, what would the web look like that is modelled more around plan 9 concepts. Here&#39;s my fantastic take on this.

First, there is a focus on simplicity of implementation and interface over flashiness of UI. As a result, services are much easier to use directly rather than having to rely on html/js UI&#39;s. You just mount search engine, route planning tool, or even shopping site and echo commands into the ctl file. And you get back results as numbered files with simple text output. User doesn&#39;t accidentally run malicious software embedded in the service. It&#39;s all just 9P.

If a service is complex enough, due to complexity of the problem it is trying to solve (not invented complexity). Source code is posted on the service in C source code form. User runs mk, which is super fast because the compilers are optimized for this. They run the program in a rfork+rio sandbox. Users quickly learn how simple this is and do it regularly so that in trusted programs don&#39;t have access to what they shouldn&#39;t. The process isn&#39;t automatic so it doesn&#39;t happen without user knowledge. Pop ups and such are not possible.

User wraps the connection in tls if they don&#39;t want any snooping. Sensitive services such as banking don&#39;t allow unencrypted sessions.

URL&#39;s are just relative paths, navigable using acme and plumber. Absolute links to sites don&#39;t exist since the user can map their namespaces any way they choose. Instead, documents may give 9P connection information and locations. Cross site linking becomes very clear. To facilitate ease of navigation and discovery services pop up to curate documents with nice easy relative linking within that service.

Multimedia documents with both pictures and text are compiled into self contained files kind of like PDF without hyperlinks and arbitrary code expectation. Links between documents are relative paths as above. Users are accustomed to using simple text or even markup/markdown for most things. This rich format is for longer and more focused reading sessions: studying a topic, leisure reading.

Implementers of Internet services have a strong focus on simplicity of implementation and interface, but also in adopting common conventions. For example, a ctl file where you send commands and numbered directories with results of each invocation. Perhaps a new convention could be to include a readme file and maybe man page with details about how to use the service. Also, services are designed to be focused enough and standard enough that they can be easily interact with other services using pipes, redirects, etc. so that the user can combine them to suit their needs.

Services take advantage of the simplicity of plan 9 and 9P to easily sandbox, proxy and load balance their services. Also, commodity and mixed architecture systems are easily integrated for free or new services that are built with whatever hardware they can find.

Single signon is achieved using symmetric encryption. If the service recognizes your public key and you are able to sign a message using your private key you can proceed. Not sure how much overlap there is here with what is in tls and factotum. Something like factotum could be useful to allow you to specify different keys (identities) for different services. The point here is that authentication is in the user&#39;s control and not the service. The user ever only needs to remember one password or store their thumbprint in one place.

That&#39;s all I have so far.

Chris

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
@ 2016-09-17 15:19 Marshall Conover
  2016-09-17 16:23 ` Chris McGee
                   ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Marshall Conover @ 2016-09-17 15:19 UTC (permalink / raw)
  To: 9fans

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

Hi all,

   For context, I am a plan 9 novice - I've played around just enough to
add jury-rigged background-image support for rio (for better or worse),
implore sl - if I remember correctly - to add the ^B option to 9front's rc
that brings the cursor to the current input place, and, for what it's
worth, create this: http://i.imgur.com/6iiF3zi.png.

   I've been wondering about how the web - specifically, the browser as a
platform for applications - would have been different had plan 9 become a
significant influence in operating systems in the early 90s. I've come to
the point where I thought a discussion here might be enjoyable and
enlightening, hopefully even to the point of dispelling the playful ribbing
that this mailing list may or may not be dead. If this conversation has
already occurred, my apologies.

  The improvement I think plan 9 could have brought to the early web is in
allowing the browser to have remained, as I understand it to have been,  a
medium for mark-up text and images, and have the OS act as the platform for
web applications.

The process I'm thinking of would be, with the example of a banking
application: the user opens the bank's web page in a plan 9 browser; the
user clicks a 'login' link; that link is sent to the plumber, which detects
it as a web application link and directs it to a service which:
- sandboxes it, perhaps by using a 'web' user or just modifying the
namespace to show the process a limited set of information;
- sets the namespace to prefer any libraries that are on the remote bank
machine, allowing the application to always run with the environment the
application developers intended;
- sets the namespace to include any files the application needs from the
remote sandbox, e.g. a directory with the user's banking files.

As a result of this, it seems that much of the hooplah around flash, webGL,
javascript, etc. could have been avoided, and that web applications from
yesteryear could still run today (for better or worse), since they could
control their environment. Web programming would have also have started off
with far greater ability, instead of having being limited by the abilities
of its browser platform and waiting years for even simple things to be
standardized. Web games, video-streaming applications, etc. on par with
local applications could have been launched as soon as the infrastructure
could support them, as the providers could just program the application to
do whatever the OS allowed.

It also seems it would avoid cookies and other privacy issues, since
applications would be sandboxed to only know about the things they have
available to them.

That said, having had discussions with friends in web development, they
have expressed concerns about ease-of-use and their initial interest in the
field - if I understand correctly, they feel that html's ease of
modification and immediate gratification was beneficial to getting them
into programming, which - while my understanding of this community is that
here it's not a highly valued thing - is, I think an important point to
address. They are application developers, and the web had aspects system
languages did not which attracted them.

Again, if these thoughts are obvious, my apologies, and if it's deeply
flawed, my apologies - but I'd be interested in hearing why.

Thanks for your time,

Mars

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2016-10-01 20:21 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-01 20:17 [9fans] Questions on the browser as a platform if plan 9 had gained marketshare Marshall Conover
2016-10-01 20:21 ` Jules Merit
  -- strict thread matches above, loose matches on Subject: below --
2016-09-20 16:48 Marshall Conover
2016-09-20 19:46 ` hiro
2016-09-19 22:00 Marshall Conover
2016-09-21  3:11 ` Chris McGee
2016-09-19 12:44 Marshall Conover
2016-09-19 17:25 ` Chris McGee
2016-09-19 20:55 ` Chris McGee
2016-09-20  6:16   ` David Pick
2016-09-20 17:42     ` Chris McGee
2016-09-22 22:49       ` michaelian ennis
2016-09-22 22:53         ` Chris McGee
2016-09-20  7:47   ` hiro
2016-09-20  8:09 ` hiro
2016-09-17 15:19 Marshall Conover
2016-09-17 16:23 ` Chris McGee
2016-09-17 17:04 ` hiro
2016-09-17 18:51   ` Jules Merit
2016-09-19 17:11     ` michaelian ennis
2016-10-01 15:03 ` James A. Robinson
2016-10-01 15:05   ` James A. Robinson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).