26 Mar
2017
26 Mar
'17
3:35 a.m.
From: Ron Minnich
There was no shortage of people at the time who were
struggling to find
a way to make the Unix model work for networking ... It didn't quite
work out
For good reason.
It's only useful to have a file-name _name_ for a thing if... the thing acts
like a file - i.e. you can plug that file-name into other places you might use
a file-name (e.g. '> {foo}' or 'ed <foo>', etc, etc).
There is very little in the world of networking that acts like a file. Yes,
you can go all hammer-nail, and use read() and write() to get data back and
forth, and think that makes it a file - but it's not.
For instance, files, as far as I know, generally don't have timeout
semantics. Can the average application that deals with a file, deal reasonably
with the fact that sometimes one gets half-way through the 'file' - and things
stop working? And that's a _simple_ one. How does a file abstraction match
to a multi-cast lossy (i.e. packets may be lost) datagram group?
For another major point (and the list goes on, I just can't be bothered to go
through it all), there's usually all sorts of other higher-level protocol in
there, so only specialized applications can make use of it anyway. Look at
HTTP: there's specialized syntax one has to spit out to say what file you
want, and the HTML files you get back from that can generally only be usefully
used in a browser.
Etc, etc.
Noel
26 Mar
26 Mar
3:45 a.m.
New subject: Were all of you.. Hippies?
On Sat, Mar 25, 2017 at 09:35:20PM -0400, Noel Chiappa wrote:
For instance, files, as far as I know, generally don't have timeout
semantics. Can the average application that deals with a file, deal reasonably
with the fact that sometimes one gets half-way through the 'file' - and things
stop working? And that's a _simple_ one.
The unwillingness to even attempt to solve problems like these in a
generalized and consistent manner is a source of constant annoyance to
me. Of course it's easier to pretend that never happens on a "real"
file, since disks never, ever break.
Of course, there are parts of the world that don't make these
assumptions, and that's where I've put my career, but the wider IT
industry still likes to pretend that storage and networking are
unrelated concepts. I've never understood why.
khm
4:49 a.m.
New subject: Were all of you.. Hippies?
On Sat, Mar 25, 2017 at 6:35 PM Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
There is very little in the world of networking that acts like a file. Yes,
you can go all hammer-nail, and use read() and write() to get data back and
forth, and think that makes it a file - but it's not.
The plan 9 networking stack, in use for over 25 years now, begs to disagree
with you. The model works wonderfully well in practice and even in theory.
To take one part of your note, can file reads time out? Well, yeah. We live
in a networked world and anything we can do with anything can time out. But
even in a pre-network world, assuming that "file I/O doesn't time out"
wasn't even true when -- and especially -- in the days of RK05 disk drives.
ron
5:01 a.m.
New subject: Were all of you.. Hippies?
On 3/25/17, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
Just because an OS provides unstructured files as its primary or only
IPC primitive doesn't mean that you can't run a structured protocol
over them (after all, the IP protocol suite provides only unstructured
transports - byte streams or unconnected datagrams - to the
application layer). That's what I'm planning to do in UX/RT. Services
that don't fit into an unstructured file model will run a structured
protocol over the file transport (UX/RT will provide a
message-boundary-preserving special file type specifically because
it's easier to implement RPC-like and other structured protocols over
such a transport). And just because such services will be harder to
use with tools like ed, cat, and the like doesn't mean there aren't
other advantages to having them in the filesystem. In UX/RT, the main
advantages of the file-oriented architecture for services using
structured protocols will be the unified security model and the ease
of overriding such services with filter servers (e.g. UX/RT's fakeroot
will be a pure server rather than an unreliable LD_PRELOAD hack, and
in a similar vein, jails in UX/RT will be able to virtualize as much
or as little as desired rather than being pretty much all-or-nothing
like in a lot of other OSes).
From: Ron
Minnich
There was no shortage of people at the time who
were struggling to
find
a way to make the Unix model work for networking
... It didn't quite
work out
For good reason.
It's only useful to have a file-name _name_ for a thing if... the thing
acts
like a file - i.e. you can plug that file-name into other places you might
use
a file-name (e.g. '> {foo}' or 'ed <foo>', etc, etc).
There is very little in the world of networking that acts like a file. Yes,
you can go all hammer-nail, and use read() and write() to get data back and
forth, and think that makes it a file - but it's not.
For instance, files, as far as I know, generally don't have timeout
semantics. Can the average application that deals with a file, deal
reasonably
with the fact that sometimes one gets half-way through the 'file' - and
things
stop working? And that's a _simple_ one. How does a file abstraction
match
to a multi-cast lossy (i.e. packets may be lost) datagram group?
For another major point (and the list goes on, I just can't be bothered to
go
through it all), there's usually all sorts of other higher-level protocol
in
there, so only specialized applications can make use of it anyway. Look at
HTTP: there's specialized syntax one has to spit out to say what file you
want, and the HTML files you get back from that can generally only be
usefully
used in a browser.
2795
days inactive
2795
days old
3 comments
4 participants
participants (4)
-
Andrew Warkentin -
jnc＠mercury.lcs.mit.edu -
Kurt H Maier -
ron minnich