Re: [9fans] Essay: Is network transparency something bad?

Re: [9fans] Essay: Is network transparency something bad?

[Skip Tavakkolian]

He states a truism, makes it sound profound by using emphatic
hyperbole, then states his wrong conclusion as fact.  One shouldn't
expect less of the M$ PM mindset, even from a former one.

For example, he states "1.  Availability, 2.  Latency and 3.
Reliability" as the major differences between the local and remote
resources.  That difference would apply to any two different medium
like a pair of telephones and a pair of cans connected by a string.
Does that mean you couldn't say "hello" over both?

> The following essay, by the former program manager of Microsoft Excel
> Joel Spolsky, criticizes network transparency (among other ideas).
>
> http://www.joelonsoftware.com/articles/fog0000000041.html

Re: [9fans] Essay: Is network transparency something bad?

[Dan Cross]

> [...]  That difference would apply to any two different medium
> like a pair of telephones and a pair of cans connected by a string.
> Does that mean you couldn't say "hello" over both?

Can one *really* say ``Hello'' over two cans connected by a string, though?

	- Dan C.

Re: [9fans] Essay: Is network transparency something bad?

[Dan Cross]

>  > 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.
>
> Hmmm. I have been using Plan 9 over a wireless with a lot of delay
> today (for some strange reason I can't really understand). Hangups and
> timeouts are really painful. Things like importing /net on all your system,
> getting a big delay, a hangup, and getting all your applications blocked are the
> sort of things he talks about. This can happen in Plan 9. Importing
> /net is powerful, but when it bites, it bites hard!!!.

Oh, don't get me wrong; I'm not saying it can't be painful.  But the
salient characteristic is that you *know* you're doing it, and in the
example he gave, one might not.

	- Dan C.

Re: [9fans] Essay: Is network transparency something bad?

[Boyd Roberts]

Ram'on Garc'ia Fern'andez wrote:

> It would be nice if Plan9 interfaces were extensible, ...

I see no reason why 9P isn't.  Whether it's a good thing to
do is another problem.

Re: [9fans] Essay: Is network transparency something bad?

[Boyd Roberts]

Ronald G Minnich wrote:

>The question is, should you interrupt or not? It always struck me as a
>pretty hard question.
>
I agree.

Look at the mess that BSD was with its interruptable system calls.

The horror, the horror ...

Re: [9fans] Essay: Is network transparency something bad?

[Ram'on Garc'ia Fern'andez]

Russ Cox wrote:
 >
 > 	- people do stupid things with x
 > 	- let's not anyone do x
 >
 > and the fallacy is that if you know what you're doing
 > it's very useful to do x.  Why tie your own hands behind
 > your back just so that people have to find some other
 > way to do stupid things?
 >

Though I do not agree entirely with the essay, I think that
he has a point.

It would be nice if Plan9 interfaces were extensible, so that, say, when
a file belongs to a filesystem mounted over a network the application
reading the file could receive optional events regarding availability,
progress of the operation, and so on.

Ramon

Re: [9fans] Essay: Is network transparency something bad?

[Boyd Roberts]

John Saylor wrote:

>But I don't think there's a single right answer to this. As we perl
>programmers often say, "there's more than one way to do it."
>
Not using perl being one of them.

Re: [9fans] Essay: Is network transparency something bad?

[Fco.J.Ballesteros]

> For example, he states "1.  Availability, 2.  Latency and 3.
> Reliability" as the major differences between the local and remote
> resources.  That difference would apply to any two different medium
> like a pair of telephones and a pair of cans connected by a string.

Well, I've never seen a local procedure call suffer from any of them.
However, an rpc might do so.

I think we probably agree that one nice thing of Plan 9 is that you
(1) may control what comes from where (no transparency here), but then you
(2) may just use the resources always in the same way (here you got your
transp.).

I wouldn't like to loose 1 or 2; I just need both to keep things working
and simple.

Re: [9fans] Essay: Is network transparency something bad?

[paurea]

Skip Tavakkolian writes:
 > This is not an excuse, but if you are having connectivity problems
 > what difference would it make if /net is mounted locally or imported?

If /net is local you don't obtain hangups everywhere they are localized
(at least this is what I experimented this morning, things hanged all at once
and when I had  /net local they did so much more gradually. If the net channel
goes down all the net connectons hang.)

 > of a cpu server under the control of a professional getting paid to
 > maintain it -- as in an ISP or an enterprise setup -- would be much
 > higher than your average (desk|lap|palm)top.
 >

I am not discussing that.
--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] Essay: Is network transparency something bad?

[paurea]

Dan Cross writes:

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

Hmmm. I have been using Plan 9 over a wireless with a lot of delay
today (for some strange reason I can't really understand). Hangups and
timeouts are really painful. Things like importing /net on all your system,
getting a big delay, a hangup, and getting all your applications blocked are the
sort of things he talks about. This can happen in Plan 9. Importing
/net is powerful, but when it bites, it bites hard!!!.
--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] Essay: Is network transparency something bad?

[Steve Kilbane]

rog wrote:
> i think plan 9's approach is better than the more usual "network
> transparency" where a function or method invocation is turned into an
> RPC behind your back.

Or to put it another way: sweeping the problems under someone else's
carpet. In this case, the user's.

> it's interesting to see what *does* lock up when a file access takes
> an unexpectedly long time

Indeed. It's fun when the expected value for "a long time" changes by
many orders of magnitude. I once dealt with an OO database, where the
database transactions could last for many months between initiation and
commit rather than mere seconds. That changed a few working methods.

Re: [9fans] Essay: Is network transparency something bad?

[Skip Tavakkolian]

This is not an excuse, but if you are having connectivity problems
what difference would it make if /net is mounted locally or imported?

There are several remarks about "reliability" of a remote resources in
that article and hinted at here, but the fact is that the reliability
of a cpu server under the control of a professional getting paid to
maintain it -- as in an ISP or an enterprise setup -- would be much
higher than your average (desk|lap|palm)top.

> Hmmm. I have been using Plan 9 over a wireless with a lot of delay
> today (for some strange reason I can't really understand). Hangups and
> timeouts are really painful. Things like importing /net on all your system,
> getting a big delay, a hangup, and getting all your applications blocked are the
> sort of things he talks about. This can happen in Plan 9. Importing
> /net is powerful, but when it bites, it bites hard!!!.

Re: [9fans] Essay: Is network transparency something bad?

[Scott Schwartz]

| I think what Scott means is that the user ought to be able to interupt
| the connection.

Exactly.

Re: [9fans] Essay: Is network transparency something bad?

[Dan Cross]

> well, consider a true case that occurs on ham radio links (or did a few
> years ago). FTP sessions in some cases would block for a *day* and then
> start again.
>
> The question is, should you interrupt or not? It always struck me as a
> pretty hard question.

I think what Scott means is that the user ought to be able to interupt
the connection.

	- Dan C.

Re: [9fans] Essay: Is network transparency something bad?

[Ronald G Minnich]

On Thu, 24 Oct 2002, Scott Schwartz wrote:

> I just wish that they were interruptable.  Having something block forever
> just because a file server isn't answering can be painful.

well, consider a true case that occurs on ham radio links (or did a few
years ago). FTP sessions in some cases would block for a *day* and then
start again.

The question is, should you interrupt or not? It always struck me as a
pretty hard question.

ron

Re: [9fans] Essay: Is network transparency something bad?

[Scott Schwartz]

| at least in the plan 9 way, it is well documented that all system
| calls can potentially block for a long period of time,

I just wish that they were interruptable.  Having something block forever
just because a file server isn't answering can be painful.

| it's interesting to see what *does* lock up when a file access takes
| an unexpectedly long time (e.g.  accessing the dump fs).  for instance
| acme locks while it's opening a file; rio locks when plumbing a file.

That suggests a diagnostic tool: slowfs, which interposes between you
and the real filesystem and randomly delays for several seconds before
passing messages on.

Re: [9fans] Essay: Is network transparency something bad?

[rog]

> But I don't think there's a single right answer to this. As we perl
> programmers often say, "there's more than one way to do it."

i think plan 9's approach is better than the more usual "network
transparency" where a function or method invocation is turned into an
RPC behind your back.

at least in the plan 9 way, it is well documented that all system
calls can potentially block for a long period of time, and they have
error returns that can describe the arbitrary errors that can be
associated with network transfers.

so it's quite possible to write programs in the light of that
knowledge (a decent threads library makes that easier too).
i don't think it's so easy with, for instance, Java RMI
(but i'd be glad to be contradicted).

it's interesting to see what *does* lock up when a file access takes
an unexpectedly long time (e.g.  accessing the dump fs).  for instance
acme locks while it's opening a file; rio locks when plumbing a file.

  rog.

Re: [9fans] Essay: Is network transparency something bad?

[Dan Cross]

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.

Re: [9fans] Essay: Is network transparency something bad?

[John Saylor]

Hi

( 02.10.24 13:08 -0400 ) Russ Cox:
> Why tie your own hands behind your back just so that people have to
> find some other way to do stupid things?

Probably to prevent litigation.

But I like the thought of one interface to everything. Isn't part of
the plan9 design: 'everything is a file' [in the file system]? Actually
just today as I was browsing the web I was struck with the thought that
it should be all under one interface [local/remote files]. So playing
with plan9 is starting to have repercussions in all my computing time.

Also, the greedy b*stards at m$ have too much control of the computing
mindspace anyway. So I'll tend to look for ulterior motives or hidden
messages in their pronouncements. But this is my own paranoia, and I'm
happy to own it.

But I don't think there's a single right answer to this. As we perl
programmers often say, "there's more than one way to do it."

--
.--- ...

Re: [9fans] Essay: Is network transparency something bad?

[Russ Cox]

I had very little to do with the design of Plan 9, but...

I think the right statement of his complaint is that
systems should not ignore the difference between remote
and local resources.  Having different interfaces is
one way to force system programmers to keep the difference
foremost in their minds.  What he doesn't address is that
doing so limits the generality of your tools.

Typical Plan 9 configurations don't go and grab this
resource from that machine and on and on -- most resources
are local -- but when you _want_ to, say, replace your /net with
someone else's /net, it's really nice that all your tools
still just work.

I agree with the premise (that you shouldn't ignore the
difference), but not the conclusion that it's up to the system
designer to enforce discipline on the users and other
programmers.  The argument is something like

	- people do stupid things with x
	- let's not anyone do x

and the fallacy is that if you know what you're doing
it's very useful to do x.  Why tie your own hands behind
your back just so that people have to find some other
way to do stupid things?

Russ

Re: [9fans] Essay: Is network transparency something bad?

[Skip Tavakkolian]

> Can one *really* say ``Hello'' over two cans connected by a string, though?

"Hello" as a metaphor for 9P, and a link of 64kbps (ISDN) or better,
the answer is yes.

Literally,  yes also;  here is the obligatory link-o-credibility:
http://www.howstuffworks.com/question410.htm

Mostly though, people say hello over a can of beer.

[9fans] Essay: Is network transparency something bad?

[Ramon Garcia]

Hello,

The following essay, by the former program manager of Microsoft Excel
Joel Spolsky, criticizes network transparency (among other ideas).

http://www.joelonsoftware.com/articles/fog0000000041.html

It would be interesting to know the opinions of Plan9 designers.

Ramon