NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/os/mswindo/programm/win32/765

Text File | 1992-09-01 | 4.0 KB | 78 lines

Newsgroups: comp.os.ms-windows.programmer.win32
Path: sparky!uunet!news.mentorg.com!mentorg.com!pbrooks
From: [e-mail] (Phil Brooks)
Subject: Re: Looking for rshd, telnetd, ftpd etc.
Sender: [e-mail] (News User)
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1992 19:17:07 GMT
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: decoy.mentorg.com
Organization: Mentor Graphics Corporation
Keywords:
Followup-To:
Lines: 63

In article <[e-mail]>, [e-mail] (Alistair Banks) writes:
|> I expect ftp & nfs daemons, and uucp & nntp and more to be available in both
|> commerical and shareware versions - but I don't expec that people will
|> "telnet" or "rsh" into Windows NT so often. Windows NT doesnt implement
|> multi-user interactive access - so while a daemon could be written to respond
|> to the telnet protocol, and even re-direct stdin & stdout, the graphics
|> apps won't be remoted, and not all of the console APIs make any sense
|> with this paradigm. The multi-user security could be bolted "in" using
|> the standard security APIs, but I doubt if many of the main commercial
|> apps would work well in this environment.

Please understand that there are many many uses for remote access of this
type that don't require a GUI at all.  Don't let the fact that remote log in
doesn't look like you are sitting in front of a real Windows application with
its associated GUI.  There seems to be a lot of confusion in this area coming
from Microsoft.  In the Unix world, plenty of things are done over remote login
without taking advantage of X's remote networking capabilities.  NT should do
just as well at these.  Specifically, I find remote login access very useful
for the following tasks which should fit into a NT network just fine:

  Remote compilation/build - When very large systems are being built (i.e.
   hundreds of files) it is very useful to remotely log in to several systems
   and parallelize the builds.  There are even versions of make set up to handle
   this transparently.  Remote login services are needed to do this.

  Starting up remote servers - I may want to start a server or other program
   on a remote machine which doesn't run under a GUI.  I may access its results
   later on with a spreadsheet or regular editor etc.

  Modem Access - I may want to dial in from home on an old dusty VT100 terminal
   and read ASCII email (assuming that I have a character based Mail User Agent).
   While I am at it, I may want to take a peek at a build log from the build I
   started up before I went home.  If something went wrong, I can correct it, and
   fire off another try, saving myself a few hours in the morning or a trip in
   later that night.

These are real activities that I take advantage of quite often on Unix.  There
seems to be a common line of reasoning in the PC world that remote login and
support for terminal access are a throwback to the days of mainframes and
therefore are inherently bad.  I have found them to be an extremely useful,
although limited, set of capabilities which are especially valuable for software
development and administration and remote access.  They are less useful for
the casual user since there is some degree of complication in setting them up.

The "main commercial apps" are not of interest here.  Character based software
development, administration, etc are.

While these capabilities might be less useful on a 386 with 8MB, they will be
extremely useful (perhaps indispensable) on Sequent and NCR multiprocessor
boxes and on the DEC Alpha box.  I would imagine that a well configured Alpha/NT
system would do very well competing with IBM AS/400's in the minicomputer market.
It will need to deal with terminals, multiple concurrent users, and remote access
in order to do that though.





--
Phil Brooks, Mentor Graphics Corporation
([e-mail])
8005 SW Boeckman Road
Wilsonville, OR   97070-7777 [phone]