In article <1jr3i9INN16d@gap.caltech.edu> toddpw@cco.caltech.edu (Todd P. Whitesel) writes:
[ ]
>
>[ in response to Derek, but I feel a need to step in here ]
>
>>TCP/IP based netwroks, which still largely use NFS.
>
>"still" ? What, pray tell, is going to replace it? Certainly not AppleShare.
>NFS has become _the_ defacto standard for file serving on IP networks.
>(I say IP here, not TCP/IP. NFS does not use TCP, rather it uses UDP which
>is no more than a switchboard/multiplexer for user level IP access.)
If you want to see why the world is confused have a look at the 3 offerings
for TCP/IP based NFS products for DOS and Windows in this month's Byte. I am
using their terminology and not your more exact one.
>
>NFS certainly has its problems, but the simple fact is that virtually every
>SPARCstation out there can become an NFS server in about five minutes of the
>superuser's time. That is about as close to "plug and play" as most unix
>facilities can get.
There's a massive shortage of programmers out there. There are very few
Sparcstations relative to the installed, and potentially installed, base of
computers. The fact that someone can turn a Sparc into an NFS server in 5
minutes is irrelevant. Server to what is the issue. Try putting a Mac on there
with a user that wants that sort of environment. Try sharing faxmodems, remote
dialin services, etc...all graphically. Unix, in my opinion, has missed the
boat. That is where you will find your 5 minute consultants. The installed
base of PC's and Mac's just keeps getting larger. I've been hearing that this
year is the year of Unix for the past n number of years. That year isn't going
to come in my opinion. And I don't see any of the major vendors basing their
networks on TCP/IP. Do you?
>
>FYI: NFS and AppleShare both suffer from the same performance problem: round
>trip delay on synchronous data exchanges of 4K or so of data. This keeps them
>simple but it not at all efficient compared to transferring an entire file
>with TCP. Since many programs need to seek around in files a lot, TCP based
>file serving that is transparent and mountable (as opposed to actual FTP
>utilities) is inherently not clean to implement and is still pretty rare.
>One implementation that I do know of is "touch" on the NeXT.
FTP will only get you very minimal functionality. It is not enough for what
smaller networks, even home ones, need.
>
>>You might well consider
>>the hassles of mail, which is a mess at the moment. Start adding sound, graphicsand other non-ascii information and you are really into a mess of problems.
>
>This is pretty irrelevant, really. AppleTalk vs. TCP/IP does not have anything
>to do with mail hassles. You forgot to mention line length, by the way; I see
>your last line here is way longer than 80 characters. I'm surprised it made it
>through intact.
It is not irrelevant. Getting a good mail system is a joy and rare. That's
why the NeXT is so nice to use, and why using Unix based editors for mail and
news is a pain (which is why you saw a long line-> due to vi on an Iris
running Unix and on the Internet). You can't imagine how far behind Unix mail
systems are when it comes to doing anything easy, interesting, etc...In
principle TCP/IP may have nothing to do with it. In practice, everything
surrounding Unix (and as a consequence anything (TCP)/IP based) is political.
>
>The problem of adding non-ascii information to a facility that traditionally
>supports only ascii data is universal. The only way to fix it is to do either
>of two things: adopt standards for encoding non-ascii data into mail (these
>exist, but not universally by a long shot), or CHANGE THE MAIL SYSTEM ITSELF.
>The lower level network protocols are irrelevant except in logistic terms,
>i.e. new software may at first be only implemented on a single protocol family.
The mail system is not going to be changed anytime soon. It took me a year to
get a proper reply to address. You keep talking in principle. That isn't the
point. In practice the people working as Unix administrators have a vested
interest in keeping the system a mystery to everyone but a few.
>
>>the networks I have seen are somewhat difficult to use and to maintain. In
>>particular, their problems can't be dealt with by having the occasional
>>consultant dropping in.
>
>I am willing to bet that if those sites had called in a consultant when they
>set things up in the FIRST place, they wouldn't be having so many problems
>later on!! To many people are content to hack until things seem to work, and
>do not attempt to understand what they are working with. This is stupid, but
>it happens far too often.
Maybe, but I'm talking about places that have permanent administrators. It's
political.
>
>> But, there is no need
>>for it just to link into the Internet. Here's a simpler way. Use an Appletalk
>>based network and one Mac with Apple's new Internet Router software, which
>>converts TCP/IP to Appletalk and vice versa.
>
>Yo, listen up. Apple's Internet Router doesn't automatically give me Telnet
>and FTP. Implementing TCP/IP on the Apple _does_. To actually talk to the
>Internet proper, I need a gateway of some kind no matter what. BTW, I would
>use something besides Internet Router, which ties up a Mac and is not as
>efficient as a dedicated box like a Shiva FastPath (the 5 is great, I'll
>swear by it) or a Cayman Gatorbox.
My Internet Router does not tie up my ci. The only thing I notice is that I
can't use virtual memory, which is neither here nor there in my case. Of
course a hardware router is better. It's also far more expensive.
>
>There is no such thing as "converting TCP/IP to AppleTalk". There is
>"converting TCP/IP to TCP/IP _inside_ AppleTalk (and back)" and also
>"converting AppleTalk into AppleTalk _inside_ TCP/IP (and back)". The former
>you use so you can use FTP and Telnet from an AppleTalk network, since the
>analogous facilities DO NOT YET EXIST in the AppleTalk protocol family (ADSP
>is only the first step). The latter is used to link two otherwise isolated
>AppleTalk networks via a TCP/IP capable network.
They may not exist yet, but they have been announced. They exist as much as
System 6.01 does. The only thing I care is that Appletalk based packets
reach my NeXT and they get back. This is done using Appletalk, and it's
trivial. I don't need to know about IP addressing, etc...Since there are
more networks than good administrators, this is important. Ease of use is
very important. People are simply not that interested in the problems of
networking. They want something that works and is easy to set up. There are
better hobbies than reading up on Unix networking.
>
>>though, as my network was set up without reading anything.
>
>I rest my case !! :) AppleTalk was designed specifically to be plug and play,
>but in doing so it lacks heavily in the scalability department. The internet
>protocols and administration have been designed so that the most complex
>administration is central and the simpler administration is distributed. This
>system is not perfect, but it has been very successful and will continue to
>be so, in spite of ignorance and cluelessness on the part of institutions.
My point all along has been that the plug and play aspect was more important.
So it would appear to me at least that you've just come down on both sides of
the fence.
>
>>The point is how to link small networks, not have one big one using the same
>>unfriendly software. The solution exists now. It is largely Appletalk based,
>>and if you insist on TCP/IP, you simply use a (software) gateway.
>
>This either makes no sense, or is totally obvious.
