On Mon, 14 Sep 1992 11:00:49 EST Nick Laflamme said:
>On Mon, 14 Sep 1992 09:48:42 CDT Natalie Maynor said:
>>> FTP is great if you are looking for an excuse to twiddle your thumbs 15
>>> minutes at work while reading the paper.
>>
>>What does this mean? I don't understand what ftp has to do with thumb-
>>twiddling.
>
>If I use FTP to retrieve a package, I can't do anything with that
>session until the file is retrieved. If there's a slow TCP/IP link
>between me and the FTP server, that can take a while, leaving me to
>twiddle my thumbs unless I'm using a multi-tasking OS, which excludes
>CMS for now.
True, but if one is communicating with CMS by a single session 'dumb'
(or not too smart :) terminal, there won't be very many occasions for
ftp of really large files.
>On Mon, 14 Sep 1992 09:02:16 PDT Richard Childers said:
>>If one has a workstation, . . .
>
>Followed by Paul Ribeiro's query:
>>And if you don't?
>
>Followed by Eric's:
>>What if one has access to a BITNET system instead - statistically not a
>>unix machine? The cost-per-Joe-user of a workstation is much higher than
>>that of a share of a mainframe, which itself is a bit higher than the
>>cost of a PC (I am talking real cost here, not hardware purchase price).
I typically run CMS in a window on a Macintosh. I've done so using a
Mac Plus with a nine inch screen. Given a terminal program on the Mac
that handles hardware handshaking one can crank up a file transfer, hide
the terminal window in the background, and do anything except format a
floppy disk (I think Apple's next system update is supposed to make such
tasks cohabit better with background tasks) without disrupting the
transfer. Two years ago, I it took nearly four hours to download
Apple's System 7 from CMS (we now have a LAN connection that is many
times faster), but it didn't keep me from getting other work done.
My point is, if one can transfer in a Window on the slowest cheapest
Macintosh still in use, surely it can be done on a cheapo PeeCee clone
running Windows as well. We're on the verge of an era when folks who
know next to nothing about the nitty gritty details can use intuitively
obvious software such as Fetch (requires a Mac, but is otherwise free;
and I'm told there's a PeeCee equivalent <hardly surprising>) to
transfer in background and other slick things that only the pocket
protector crowd used to know how to do :)
>And Natalie Maynor's
>>Huh? I'm an English teacher with an ordinary PC. But now that most of us
>>are being connected to the campus net, we can have multiple logins. I just
>>hit alt-a to open another session. As I said earlier, though, it has never
>>entered my mind to do that while ftp'ing since ftp'ing usually takes no more
>>than a few seconds.
True of NET3270 and other LAN software, I'm sure, but it supposes that
you've something else to do on the mainframe host while a session is
tied up in a transfer. The best of all worlds (in this context) is a
LAN connection and a GUI running software capable of opening multiple
host sessions within windows of a local environment. Of course you soon
need a window manager to navigate around all those windows ;-)
This thread wandered away from the original question - if Internet; why
BITNET. We've only recently (14 months) moved from a 9.6Kbps BITNET
only link to a T1 Internet. Although I'm on the appropriate policy
committee, I haven't asked in a year or so about the relative costs, but
I doubt that the situation is very different from what it was.
Compared to the cost of an Internet T1 link, CREN (BITNET) is dirt cheap
(order of magnitude smaller). Given a T1 connection, the BITNET traffic
"piggybacks" on it for a marginal cost that is negligible (we used to
lease a 9.6 line to Yale for BITNET; we now pay MUCH more for the T1
line, BUT dropping BITNET would not lower our current line costs. As
far as I know, our cost of maintaining CREN membership is 1) the
membership fee, which relative to the total computing budget is smaller
than the rounding error, and 2) some person hours to keep track of
nodentry updates and other administrative minutiae (which given the not
too smart way our budgets are handled probably is a MUCH larger problem
than the fee).
No one has suggested dropping BITNET (we don't run a LISTSERV and
therefore probably wouldn't be missed :) to the computing committee that
I belong to, but if it does ever come up I'd guess the rational would
focus on administrative rather than membership costs. However, I have
the impression that the administrative overhead for our expanding
Internet domain is an order of magnitude at least greater than the
attention demanded by CREN.
In short, I've approached the question from the opposite direction. Why
not stay on BITNET? Would what you save by dropping it amount to much?
If you're running a LISTSERV, don't local users benefit sufficiently to
continue providing that service (it's kind of cheeky to expect someone
else to take care of it for you isn't it--pardon the comment, from
someone stuck on a host that has not to my knowledge made much of an
effort to help out others; our policies are at least consistent, local
users get a lot of "can't," "don't," and "won't" also)?
Neither SENDFILE nor ftp does what most of my colleagues really want to
do. The typical academic is output oriented and wants the technology to
be entirely transparent. What they'd like is an intuitive mail client
with an "attach" file feature that would let them stick a Word Perfect,
Word, Word for Windows, or what have you document to it. They also want
a file format that preserves formatting without depending on the
recipients word processing software (or even platform--that is our Word
Perfect 5.1 users don't want to have to worry that their coauthor
halfway around the world is using Word on a Macintosh. Actually, the
capability is well within the state-of-the-art, but actually getting it
done on most hosts without mumbo-jumbo and incantations isn't possible.
If BITNET really wants an undisputed advantage then transparent word
processing file transfer and similar useful services is a way to go.
/s Murph Sewall <[log in to unmask]>
|
