9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Essay: Is network transparency something bad?
Date: Thu, 24 Oct 2002 13:36:14 -0400	[thread overview]
Message-ID: <200210241736.g9OHaEi23621@augusta.math.psu.edu> (raw)
In-Reply-To: Your message of "Thu, 24 Oct 2002 15:51:59 GMT." <slrnarful5.amn.ramon.n.0.spam@jl1.quim.ucm.es>

He was being polemical, and the context was different.  That said, I
enjoyed the article, but disagree with him on several points.

First, he was talking about a programming interface, not a system
interface.  Plan 9 integrates things like the network into the
filesystem, effectively making IPC endpoints look like local files and
the like, to enhance generality, and provide system-wide abstractions.
Everything looks like a file, and everyone knows how to deal with
files, so it makes things convenient.  But an important difference is
that a programmer still interacts with those abstractions explicitly.
You know that you're creating and manipulating a TCP connection when
you open the files under /net/tcp, or when you call dial(2).  Because
of that, you're congicent of the potential problems you might
encounter.  It's the psychological difference that matters here; the
point isn't to abstract things to the point of oblivion, but to
generalize the system interface and remove redundancies.  Just because
you do that doesn't mean you stop thinking about remote files versus
local files, it's just no longer the focal point.

Second, he was addressing specific issues in the Windows environment
that don't exist on other platforms.  We don't call ``CopyFile()''
under Plan 9; we invoke cp(1).  It doesn't ``halt your application,''
it pauses your shell (unless you background it).  There's no activity
indicator because there doesn't need to be: you can sweep another
window and use ls(1) to tell you if the file is getting bigger.  The
problems he's refering to go away, so finding a good solution to them
is a nonissue.  In exchange, we remove a *lot* of complexity (why do I
want every application that copies a file to know about FtpOpenFile?
Do I really insist that an FTP server be running every place I want to
copy a file *from*?), and the system is a lot more general.  Also, his
complaints about reliability are valid, but what happens if my FTP
server crashes?  Do I want to go back to having everything on one big
machine?  What if *that* crashes?  What's the point of a network, just
to transfer MP3's and images?

Anyway.  As Russ pointed out, he makes a few good points, but the
solution might not fit the crime here.  If he were exposed to a system
with a different type of interface, he might feel very differently.
But evidentally most of his experience is with Windows, which doesn't
have a particularly good abstraction for the network.  In Plan 9, as is
often the case with both Unix and VMS, the network plays a far more
central role in an installation.

	- Dan C.



  reply	other threads:[~2002-10-24 17:36 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-24 15:51 Ramon Garcia
2002-10-24 17:36 ` Dan Cross [this message]
2002-10-25  0:06   ` paurea
2002-10-25 14:40     ` Dan Cross
2002-10-25  9:03 ` [9fans] " Adrian Tritschler
2002-10-25 13:27   ` Boyd Roberts
2002-10-25 14:50     ` Dan Cross
2002-10-25 14:59       ` Boyd Roberts
  -- strict thread matches above, loose matches on Subject: below --
2002-10-25  7:24 [9fans] " Fco.J.Ballesteros
2002-10-24 21:49 Skip Tavakkolian
2002-10-25  2:04 ` paurea
2002-10-24 17:54 rog
2002-10-24 18:40 ` Scott Schwartz
2002-10-24 19:05   ` Ronald G Minnich
2002-10-24 19:25     ` Dan Cross
2002-10-24 19:32       ` Scott Schwartz
2002-10-25 13:10     ` Boyd Roberts
2002-10-24 22:09 ` Steve Kilbane
2002-10-24 17:08 Russ Cox
2002-10-24 17:16 ` John Saylor
2002-10-25 11:44   ` Boyd Roberts
2002-10-25 12:08 ` Ram'on Garc'ia Fern'andez
2002-10-25 13:31   ` Boyd Roberts
2002-10-24 16:43 Skip Tavakkolian
2002-10-24 15:09 Skip Tavakkolian
2002-10-24 18:58 ` Dan Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200210241736.g9OHaEi23621@augusta.math.psu.edu \
    --to=cross@math.psu.edu \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).