26 Mar
2017
26 Mar
'17
5:11 a.m.
I can't wait to see how you all fit remote procedure calls into a file
paradigm.
Noel
26 Mar
26 Mar
5:17 a.m.
New subject: Were all of you.. Hippies?
On 3/25/17, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
I can't wait to see how you all fit remote
procedure calls into a file
paradigm.
Noel
There are lots of RPC protocols that run over TCP which is for the
most part an unstructured byte stream, so there's no reason why RPC
couldn't be run over a local file transport in a similar way
(especially with one that preserves message boundaries, unlike TCP,
which requires application-layer protocols to implement their own
framing).
5:21 a.m.
New subject: Were all of you.. Hippies?
On Sat, Mar 25, 2017 at 11:11:22PM -0400, Noel Chiappa wrote:
I can't wait to see how you all fit remote
procedure calls into a file
paradigm.
By making the file endpoints available to the remote side and doing a
regular procedure call.
I'm still fuzzy on why "read" and "write" are somehow too
specialized
for you, but this is rapidly getting off-topic for TUHS, so if you want
some pointers on where to read more about this stuff I guess you can
email me off-list.
khm
5:49 a.m.
New subject: Were all of you.. Hippies?
On Sat, Mar 25, 2017 at 11:11 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
I can't wait to see how you all fit remote
procedure calls into a file
paradigm.
I don't mean to sound flippant, but isn't that exactly what every RPC
protocol implemented on top of sockets has done for the last 30 or so years?
I feel like saying otherwise conflates two tangentially related things:
namespaces to name IPC endpoints in a "file" like manner, and an API to
deal with file-like objects as a byte stream on which one uses operations
like read and write. Certainly there is no REASON that sendto() et al can't
be implemented in terms of write(), but arguably the plethora of such as
*system calls* stems from the inability to name them in a way accessible to
open().
The plan9 model is imperfect but serves as the existence proof that it
*can* be done.
- Dan C.
5:55 a.m.
New subject: Were all of you.. Hippies?
On Sat, Mar 25, 2017 at 8:11 PM Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
I can't wait to see how you all fit remote
procedure calls into a file
paradigm.
https://www.usenix.org/legacy/event/sec02/cox/cox.pdf
6:26 p.m.
New subject: Were all of you.. Hippies?
On Mar 25, 2017, at 8:11 PM, Noel Chiappa
<jnc(a)mercury.lcs.mit.edu> wrote:
I can't wait to see how you all fit remote procedure calls into a file
paradigm.
For a simple example, see http://plan9.bell-labs.com/magic/man2html/4/ftpfs .
This uses the usual filesystem interface to the network stack to manage the underlying TCP
connections. The FTP protocol is implemented inside the ftpfs fileserver process which
itself exports a directory into the filesystem namespace. Fileservers are the natural
representation of RPC protocols in plan9, and they work quite well.
Of course, not everything will naturally map to a filesystem namespace. But a
surprisingly large number of things will, given some thought to the problem.
http://plan9.bell-labs.com/sys/doc/names.pdf is a must-read to appreciate the nuances of
how this works.
--lyndon
P.S. A fun example of the simplicity of the plan9 network API is this implementation of
rlogin: http://plan9.bell-labs.com/sources/contrib/rsc/rlogin
6:40 p.m.
New subject: Were all of you.. Hippies?
On Sun, Mar 26, 2017 at 09:26:00AM -0700, Lyndon Nerenberg wrote:
P.S. A fun example of the simplicity of the
plan9 network API is this implementation of rlogin:
http://plan9.bell-labs.com/sources/contrib/rsc/rlogin
So while that is really neat, I personally think that's part of why Plan 9
didn't take off. It's too clever, at least for me. I know the rlogin
code pretty well and if you showed me that code and asked me what it was,
without the comments, I don't think I would have put it together. On
the other hand, show me the C code and I'd be able to figure it out.
It's perhaps because I'm not the sharpest tool in the shed, but I really
like how blindingly obvious a lot of the original Unix code was. Not saying
it was all that way, but a ton of it was sort of what you would imagine it
to be before you saw it. Which means I understood it and could bugfix it.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
8:35 p.m.
New subject: Were all of you.. Hippies?
On 26 Mar 2017, at 17:40, Larry McVoy
<lm(a)mcvoy.com> wrote:
perhaps that was a rather extreme example, you can write rlogin in shell script, but
con(1) is more typical - in C.
http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/con/con.c
perhaps this is closer to what you would expect.
The network stuff is all wrapped up in the dial(2) library func, but note rawon and rawoff
are pretty neat.
-Steve
On Sun, Mar 26, 2017 at 09:26:00AM -0700, Lyndon
Nerenberg wrote:
P.S. A fun example of the simplicity of the
plan9 network API is this implementation of rlogin:
http://plan9.bell-labs.com/sources/contrib/rsc/rlogin
So while that is really neat, I personally think that's part of why Plan 9
didn't take off. It's too clever, at least for me. I know the rlogin
code pretty well and if you showed me that code and asked me what it was,
without the comments, I don't think I would have put it together. On
the other hand, show me the C code and I'd be able to figure it out.
It's perhaps because I'm not the sharpest tool in the shed, but I really
like how blindingly obvious a lot of the original Unix code was. Not saying
it was all that way, but a ton of it was sort of what you would imagine it
to be before you saw it. Which means I understood it and could bugfix it.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
10:05 p.m.
New subject: Were all of you.. Hippies?
On Sunday, March 26, 2017, Larry McVoy <lm(a)mcvoy.com> wrote:
On Sun, Mar 26, 2017 at 09:26:00AM -0700, Lyndon
Nerenberg wrote:
A lot of original UNIX code was simple, but we ended up with 272 lines of
bloat in echo.c[1]. That bloat started to creep in already in the
beginning
when Rob Pike formulated his famous presentation on cat(1)[2]. I also
think that sockets implementation was the turning point.
Plan 9 was probably the last truly dedicated effort to keep it simple using
the UNIX way of doing things. I much prefer reading its code than GNU
or FreeBSD. I think the world really needs a Unix operating system which
is as simple and elegant as Plan 9.
[1] http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/echo.c
[2] http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
--Andy
P.S. A fun example of the simplicity of the
plan9 network API is this implementation of rlogin:
http://plan9.bell-labs.com/sources/contrib/rsc/rlogin
So while that is really neat, I personally think that's part of why Plan 9
didn't take off. It's too clever, at least for me. I know the rlogin
code pretty well and if you showed me that code and asked me what it was,
without the comments, I don't think I would have put it together. On
the other hand, show me the C code and I'd be able to figure it out.
It's perhaps because I'm not the sharpest tool in the shed, but I really
like how blindingly obvious a lot of the original Unix code was. Not
saying
it was all that way, but a ton of it was sort of what you would imagine it
to be before you saw it. Which means I understood it and could bugfix it.
2795
days inactive
2795
days old
8 comments
9 participants
participants (9)
-
Andrew Warkentin -
Andy Kosela -
Dan Cross -
jnc＠mercury.lcs.mit.edu -
Kurt H Maier -
Larry McVoy -
Lyndon Nerenberg -
ron minnich -
Steve Simon