Re: [9fans] How Plan9 saved the world.

2016-09-17 Thread cigar562hfsp952fans
Jules Merit  writes:

> James Holmes, San Diego Colorado.
> Font BOLD enough for lib-ja.
>
> HMS Ole, multi-passaway, Olga!
> Alice Michael
> U be illin "chicKen" "RobKen" Dallas, PoPo MacDonald KenTucky fried.
> /JamesColeM.S.Anderson

Is this Navajo-code steganographic e-mail?  Or... perhaps we finally
uncovered evidence that, in order to understand Plan 9, you really DO
have to be stoned out of your mind...!



[9fans] httpd - first try

2016-09-17 Thread woplan9
Hello!  I just re-installed plan9 in a raspberry pi, and this time
around, i´m trying to play with the httpd web server, for creating a
small site.

I created /usr/web/index.html and tried to run ip/httpd/httpd which
produces the following error page (via browser, and for the intended
ip):

"
Object not found 
 
The object /usr/glenda/web/index.html does not exist on this server. 
errstr: '/usr/web/usr' does not exist 
uri host:  
header host: 192.168.1.100 
actual host: who cares
"
I also created /usr/glenda/web/index.html but the results are the
same.  I know that the /sys/lib/httpd.rewrite and namespace.httpd are
important files for configuring but i´m not sure how.  I didn´t, i´m
afraid, get less cofused by reading httpd man page, but i´m sure it is
my fault :).

My objective is the to run the web server for a index.html basic file
on a directory, somewhere in plan9.  Does anyone have any ideas where
the problem might lie?


Thanks!

João Reis




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

2016-09-17 Thread Jules Merit
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" <23h...@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.
>
>


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

2016-09-17 Thread hiro
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.



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

2016-09-17 Thread Chris McGee
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. Heres 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 UIs. 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 
doesnt accidentally run malicious software embedded in the service. 
Its 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 
dont have access to what they shouldnt. The process isnt 
automatic so it doesnt happen without user knowledge. Pop ups and such are 
not possible.

User wraps the connection in tls if they dont want any snooping. Sensitive 
services such as banking dont allow unencrypted sessions.

URLs are just relative paths, navigable using acme and plumber. Absolute 
links to sites dont 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 users control and not the service. The user ever 
only needs to remember one password or store their thumbprint in one place.

Thats all I have so far.

Chris

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

2016-09-17 Thread Marshall Conover
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


Re: [9fans] IP Multicast - Results

2016-09-17 Thread Chris McGee
I recompiled with the latest in hg. I'm still not having success with the 
multicast. I'm going to start adding debugging to figure out what's going on.

Chris