PROJECT ATHENA
NEWSLETTER
-----------------------------------------------------------------
VOLUME 2, NO. 7
THE OFFICIAL PUBLICATION OF MIT PROJECT ATHENA
JULY 17, 1985
-----------------------------------------------------------------
In This Issue:
-----------------------------------------------------------------
**July System Changes
*Online Consulting System
*Mail Address Change
*Emacs Bug Fix
*Printer Default Changes
*Tftp and Tftpd
*New Mail System
*New Chsh and Chfn
*New Scheme Release
*X Window System
*Domain Name Server
**Project Proposal Deadline
**Change in Project Account Names
**More Athena Projects Funded
**Deployment Briefs
**Projects Book Available
-----------------------------------------------------------------
-----------------------------------------------------------------
PROJECT PROPOSAL DEADLINE
The proposal deadline for new projects requesting funds and
projects whose funding ends in January 1986 will be October 1,
1985. A copy of ``Guidelines for Proposals'' that explains
funding procedures can be obtained by calling Connie Donaghey at
(25)3-1300.**
-----------------------------------------------------------------
JULY SYSTEM CHANGES
During July, Project Athena will release a new version of the
system to user machines. This release will contain some new
software systems, upgrades to some existing packages, and many
minor improvements. This release will adhere to standard Athena
policy and be ``upwards compatible.'' This means that user
programs will work with the new system. For example, in the new
release of the mail handler (MH.5), there will still be a command
called comp. In general, we try to keep the names of basic
commands the same in a new system. Note, however, that this does
not mean all commands will be the same; their funtionality may
have been changed to make them work faster or more efficiently.
The list of changes scheduled so far is itemized below. These
items are covered in greater detail in separate articles in this
Newsletter.
MH.5 This is an updated version of the present Mail
Handler (MH) system. The basic mail commands
(such as comp) will remain the same. There will
be some new commands and more options resulting
in a more powerful system.(p. 5)
Mail Address The new mail addressing protocol, as discussed in
the last Newsletter, is already in use. Detailed
use of the chhome command,
X X is a window system that allows a user to create
windows on a bit-mapped graphics screen. It
works only on VS100's (xterm's) at this time.
Unlike the old, experimental window system, X
will now be supported.(p.8)
VS100 Change The VAXstation 100 graphics terminals will no
longer be vs100 to the TERM environment variable.
The new name for the terminal is xterm.(no
article)
Emacs The Emacs text editing system's
``autologout''variable will be unset. Some users
have not been able to save their files if they
had not used any shell commands, such as "save,"
for over 60 minutes. With the autologout off,
this will no longer happen.(p. 5)
Printers The default printers will be changed to impact
line printers for some clusters in order to
alleviate the load on the laser printers.(p. 5)
Tftp There is a working version of the ``Trivial File
Transfer Protocol''program that allows file
transfer between IBM PC/AT's running Unix to PC's
running DOS and vice versa.(p. 5)
chfn and chsh These programs allow you to change the default
shell and user information on all machines you
have accounts on in one step, much in the way
that passwd works now.(p. 7)
Scheme There is a new release of Scheme including a new
compiler.(p. 7)
Name server A version of the gethostbyXXX library functions
will be available that take advantage of the
Internet Domain Name System. Most system
programs have been relinked to use these
functions. Because there are some subtleties
associated with this change, programs that use
these functions will still get the old version
(that uses /etc/hosts) at least until January.
To get the new version the resolv library should
be included when programs are linked (by ending
your cc line with a -lresolv.(p. 9)
OLC The Online Consulting System is officially
released.(p. 3)
Landscape Print It is now possible to get output "sideways" on
the ln01 laser printers, printed the long way on
8 1/2 x 11 paper in so-called "landscape" mode.
(The default is "portrait.") To get the sideways
print, add the -c option to the lpr command.(no
article)
Gnuemacs This updated version of Richard Stallman's Emacs
is available under /usr/unsupported/xemacs. It
is undocumented. Its keybindings are different
from the current Emacs, e.g., arrow keys will not
work. To invoke it, type
/usr/unsupported/xemacs.(no article)
SCHEDULED DOWNTIME
We plan to release the new system during the middle of July.
Because we now have so many machines, the release will not occur
at the same time on all systems. Instead, there will be a sort
of ``rolling blackout'' from cluster to cluster. We expect, in
the best case, that each cluster will be out of service for about
one day, from about 9am to 9pm. If we encounter difficulties,
the cluster may be down for a longer period of time. This is
more likely to occur in the first clusters we convert than in
later ones.
WARNING!
The schedule below is subject to change. There may be a delay of
up to two weeks. Furthermore, as of this Newsletter's deadline,
not all of the features mentioned above had completed final
testing. If we discover that a piece of software doesn't work
properly, we will withdraw it before the actual release. An
addendum to this Newsletter will be published in August should
there be any last minute changes.
You will be able to tell that the system has been installed
because the banner that you get after logging in will read
``Athena Unix #3-something'' instead of ``Athena Unix
#2-something'' as it displays now.
If you have any problems with the new system or its software,
contact a student consultant. Do not call the Hardware Hotline
or the Athena main offices. If a consultant is not available in
your cluster, try using the Online Consulting System by typing
olc at your terminal, or call the Consultant's Office (11-124d)
at (25)3-4435. The downtime schedule is as follows:
Wednesday, July 17 Stud. Cent.
Thursday, July 18 Bldg. 66
Friday, July 19 Bldg. 38
Monday, July 22 Bldg. 1
Tuesday, July 23 Bldg. 11
Wednesday, July 24 Cleanup
_______________________________________________________________________
ONLINE CONSULTING (OLC)
ANNETTE RAHM, ATHENA CONSULTANT AND
ONLINE CONSULTING ADMINISTRATOR
The Online Consulting system (OLC) is now available on all
Project Athena machines, and will be officially released with the
July system changes. OLC enables users to get help from
consultants in other clusters from their terminals, automatically
connecting a user with a question to an available consultant. If
a consultant is not available, OLC holds the question until the
next person comes on duty. Documentation on OLC is in each
terminal room on bright yellow pages near the other
documentation. You can also read the manual page online by
typing man olc.
To use the OLC system, simply type olc at the Athena prompt. The
program will prompt you for a topic and then ask you to type your
question (when you are done typing it, type ^D (control-D) or a
dot, '.', on a line by itself). Once you have entered your
question, OLC will try to find a consultant to help you. If one
is not immediately available, you may leave olc temporarily, if
you wish, using the quit subcommand, and OLC will connect you a
consultant as soon as one is available. Or, you may end your
question by typing cancel, which withdraws the question, or done,
which indicates that you are satisfied with the answer. If you
leave olc using the quit subcommand, you may continue your
question by typing olc again at the Athena prompt. OLC will not
be disconnected until you specify either done or cancel.
OLC keeps transcripts of all conversations for review by
consultants. These logs are for internal use by consultants and
Athena staff members only; they are not public.
BE AN OLC VOLUNTEER
At this time, the only people answering questions are Athena
consultants. However, we feel that there are users who are
capable and willing to help out their peers by answering
questions (and we know that there are already people out there
doing so!). In order to promote a more friendly user community,
we hope to recruit those interested and qualified to be
volunteers. For more information on becoming a volunteer, please
send your name and phone number by mail to oconsult and we will
get in touch with you.**
______________________________________________________________________
MAIL ADDRESS CHANGE
DAVE GRUBBS, SYSTEMS PROGRAMMER
Until recently, mail within the Athena system was usually
addressed to user@machinename. The old mail system would route
mail to the specified machine only. If no machine name was
included in the address, the computer would first check the
/usr/lib/aliases file for the user's machine. It would search
through the file repeatedly, sending mail to every machine the
user has an account on. If the computer cannot find the user in
the aliases file, it would check the /etc/passwd file to see if
the user is on the sender's machine. If not, the sender would
get a "unknown user" message.
As announced in the June Newsletter, the addressing system has
changed. The new addressing system in already in use; users
should have received online messages to that effect.
Now, users choose one home machine at which all their mail will
be received. Mail to anyone in the Athena system is addressed
simply as username. No machine name is necessary because the
mail is automatically routed to the user's home mail machine. If
a machine name is specified, it is ignored. All mail goes to the
athena host machine which looks in its database for the user.
This database is updated nightly and contains the home mail
machines of every Athena user.
Also, all mail from the outside world should be addressed to
user@mit-athena, as opposed to user@mit-machinename. If mail is
addressed to user@mit-machinename as before, you will get the
mail eventually, but it will also take much longer, so you should
notify your netmail friends about this change. You should also
tell them to check if they have changed to the Domain Name Server
scheme. If they have, the correct address would be
user@athena.MIT.EDU. See the "Name Server" article in this issue
for more information about outside mail addressing.
To find out what your assigned home mail machine is, type chhome.
At the present time, new users are not being assigned home mail
machines. This will eventually be fixed, but for now, new users
should use chhome to choose a home machine (see below). If you
do not specify a machine, you will not get any mail.
If you have accounts on more than one machine and would like to
change your home mail machine, or if you have not been assigned a
home machine at all, you should type chhome newmachinename. Note
that you must have an account on the machine you specify in order
for this to work, and you must specify an Athena machine.
Listing a machine at MIT but not within the Athena system will
not work. Changes made before 9 pm will be in effect by 6 am.
Changes made after 9 pm will not be logged until the next day.
Note:
If you have a .forward file on your home machine, and it contains
a line: you@samemachine, an infinite loop will occur. You do not
need a .forward file just for routing to Athena machines. If you
are using your login name as a mailing list, place yourself in
your own .forward file as \you.**
-----------------------------------------------------------------
LOOK! PROJECT PEOPLE!
CHANGE IN ACCOUNT NAMES
CECILIA D'OLIVEIRA,
USER SERVICES MANAGER
Effective August 5, 1985, all Athena accounts containing the dot
character "." will be renamed. Dots in account names have proven
problematic under Unix for activities such as sending and
receiving mail. Therefore, we will discontinue the use of dots
in account names and will substitute it with the underscore
character "_". For example, the account 1.d004 will be changed
to 1_d004, and the account 14.01 will be changed to 14_01.
This change will affect all existing accounts with dots in the
account name including central project accounts assigned to
Athena development projects, MIT courses and student groups. The
primary effects will be a change in the account name (which will
affect login) and a change in the name of the project directory.
For example, if the project account is now named projacct.num,
you would instead login as projacct_num and the new directory
name would be /projects/projacct_num. Therefore, all Unix
scripts referring to your project directory will have to be
changed as well.**
_________________________________________________________________
AN EMACS BUG FIX
DAVE GRUBBS, SYSTEMS PROGRAMMER
Some users have complained that after a long period of editing,
Emacs was unable to save the file. This turned out to be a
problem with the "autologout" variable in the C shell.
The problem occurs when a user spends more than 60 minutes typing
in text between commands which access the auxiliary C shell,
usually commands to save the editor buffer to disk.
When Emacs starts up, it starts both the Emacs program and an
auxiliary shell which evaluates shell variables and uses of "~"
(indicating home directory). The average user accesses the
auxiliary shell only when saving the file to disk. As in all
other invocations of the C shell, the default value of the
"autologout" variable is 60. This is interpreted by the shell as
the number of minutes to wait after the last activity by the
shell before logging the shell out.
Most users do not place "unset autologout" into their ".cshrc"
files, which is read at shell start up time. Doing so will keep
the shell from logging out at all. There is good reason for
having normal login shells log out automatically, so unsetting
the "autologout" variable is not advised, in general, but for an
auxiliary shell, such as the one started up by Emacs, it is a
good idea to keep the shell around until Emacs itself goes away.
Emacs has been changed to unset the "autologout" variable in its
auxiliary shell. This will keep the shell from exiting until
emacs does. This action will not affect any other shell
invocation.
-----------------------------------------------------------------
TFTP AND TFTPD
JOACHIM MARTILLO, SYSTEMS PROGRAMMER
The Unix command tftp and the program tftpd implement the Trivial
File Transfer Protocol (Arpanet RFC 783). This allows a user to
transfer files to and from remote network sites. Its main purpose
is to transfer files between the Unix system and DOS which is
currently running on the IBM PC/AT workstations. It is similar
to the Unix ftp command, however, there is little (compared to
the ftp command) that a user of tftp can do besides read and
write files. Further, Project Athena has restricted the server
program (tftpd) to only permit transfers if the other machine is
on the same subnet of the same Local Area Network (LAN). This
means that tftp should be used primarily for moving files between
Unix and DOS on the workstations, although it is possible to move
files between other remote machines.
Therefore, a user can only read a file from the remote machine if
his machine is on the same subnet of the same LAN and if the file
is readable and if all directories in the pathname of the remote
file permit access. As an added restriction, a user cannot
overwrite a file on the remote machine. A special flag permits
automatic overwrite of files on the local machine if the tftp
user is reading from the remote machine onto his local machine.
To write a local file onto a remote machine, the user starts tftp
via the command:
tftp put local-file-name remote-machine-name full-path-name-
remote-file opt.
Opt is either netascii or octet. If a user is transferring an
executable or some other non-text file, the transfer should be
made in octet mode. The default, however, is netascii. Netascii
is used for transferring text files. Operating systems typically
have various and conflicting conventions for specifying EOL (End
Of Line) or EOF (End Of File). In netascii, the Unix conventions
are translated into network conventions. The server on the
remote machine was informed by the tftp program that the transfer
occurs in netascii mode. The server on the remote machine knows
then to translate the network conventions into the conventions of
the remote machines operating system. The user may specify image
rather than octet. The two words are synonymous and signify that
the transfer is to be made byte by byte with no translation of
byte sequences in any way shape or form (hence the alternate name
image).
To read a remote file onto a local machine, the user invokes tftp
via the command:
tftp get local-file-name remote-machine-name full-path-name-
remote-file opt
If the tftp program notices that the local file already exists,
the user will be prompted:
File already exists; unlink?
If the user wishes the transfer to proceed, the user must type y,
otherwise the transfer will be immediately aborted. If the local
file cannot be deleted, the transfer will also abort. If the
user knows, before starting the transfer, that the local file
already exists and that he wishes to overwrite it, he may specify
the flag -o. The tftp program will silently unlink the existing
file and replace it with the remote file if this is possible. If
the local file cannot be unlinked, the transfer will be aborted.
Note this is a dangerous procedure, because if the file does not
exist on the remote machine, the local file will be removed, and
a zero-length file of the same name will be created in its place.
The server reads the file on the remote machine and translate the
remote operating system conventions into network conventions.
The client program (the one being run by the user) translates the
network conventions into the local operating system conventions
(in this case Unix conventions). Note: if the transfer is made
from one Unix system to another, whether the transfer takes place
in octet or netascii makes no difference. However, if one of the
operating systems is not Unix (e.g. DOS), a transfer of a text
file in a mode other than netascii will produce ill-defined
results. Further, if the user is transferring between Unix
systems, the user need not worry about setting up a server on the
remote machine. The daemon program inetd will do this for the
user. But if the remote machine is not Unix (e.g. DOS), the user
will probably have to set up the server on the remote machine
(e.g. via command tftp serve for DOS).
_________________________________________________________________
PRINTER DEFAULT CHANGES
JOHN KOHL, STUDENT SYSTEMS PROGRAMMER
As all users, especially those using the W20 cluster, are well
aware, the default ln01 laser printers are overused and
frequently break down. This is because they are running way over
their intended capacity. It is becoming harder and harder to get
the printers repaired. As a temporary solution to the problem,
we have changed the default printers from the ln01 laser printers
to the lp26 or la120 impact line printers in every cluster that
has a line printer available. We hope this will reduce the load
on the laser printers and reduce the number of breakdowns.
In the past, the computers decided what printer to use by
checking the PRINTER environment variable located in the .login
file of every user. In order to effect the change outlined
above, instead of changing everyone's .login or .cshrc file, we
have made the PRINTER variable obsolete and created a new
variable called APRINTER. The computer now looks at APRINTER for
the default printer. The default setting is determined by
consulting the clustertab database (type man 5 clustertab for
more information).
The default printers in each cluster beginning in July are as
follows:
Cluster Default Printer
-----------------------------------------------------------------
1: lp26 line printer
2: ln01 in bldg. 6 (no change)
6: ln01 laser printer
11: ln01 laser printer
38: la120 line printer
66: la120 line printer
E40: ln01 laser printer
W20: lp26 line printer
Now, if you type lpr filename, the output will appear on the
default printer as listed above. Most line printers should be
located next to the laser printers. If you need help changing
paper on the line printers, call a consultant. There will also
be signs put up at the printers to tell you how to do it
yourself.
To print output on the ln01 if your default is a line printer,
type:
lpr -Pln filename
Important!
If your default printer has been changed to a line printer,
please do not switch to the laser printer every time you print
out material. The line printers will produce Scribe formatted
output as (continued)
_________________________________________________________________
NEW MAIL SYSTEM
TONY DELLA FERA, DEC SOFTWARE ENGINEER
The Mail Handler (MH) system is the Athena supported mail system.
The July 1985 Unix release includes a new version of the MH
system called MH.5. MH.5 is very different from the previous
version of MH that is currently in use on Athena systems. Most
Athena machines are running an enhanced version of MH.2 (three
versions behind the latest revision!). New users are encouraged
to read the Athena Essential Mail document first before trying to
use the Mail Handler.
If you are a casual MH user, you probably won't notice any
changes -- though you should notice that the new MH works faster.
It is useful to mention that all commands now support a -help
option that prints out a brief synopsis of the command, as well
as the version number of MH that you are running.
Nonetheless, since so many changes have been made between MH.2
and MH.5 it is advised that you examine the man pages of all the
commands that you have regularly used under previous versions of
MH before using the equivalent command in MH.5. For example, the
inc command's -noupdate option has been changed to -nochangenum.
When you run an MH.5 command for the first time two things may
happen (depending upon the previous version of MH that you were
using). The first thing that MH.5 will do is to rewrite your
~/.mh_profile file so that it will be in MH.5 format (type man
mh-profile if you are interested in more information about the
new format for the ~/.mh_profile file). The second thing that
MH.5 will do is rearrange your ~/Mail directory slightly to clean
up old MH data files that are no longer used.
PLEASE NOTE: None of the MH.5 bboard facilities that are
documented in the MH.5 manuals are supported on Athena systems!
Some of the new basic facilities are:
- More complete ~/.mh_profile support with better syntax.
- Full subfolder hierarchy support.
- An msh MH subshell system for those people who don't
like using MH from the shell.
- A message marking system for identifying messages
(read, unread, new, old etc...).
For the more advanced user, many new commands and message filing
utilites have been included. Some new advanced facilities are:
- Full user-defined message sequence support.
- Full draft folder support for unsent messages.
- Background mail processing on send and comp.
- Relative folder addressing.
- Folder "stack" support.
- MHL message display and formatting system.
Some new commands are:
ali List mail aliases.
anno Annotate messages.
mark Mark a message.
mhl Produce formatted listings of MH messages.
mhpath Print full pathnames of MH messages and folders.
msh MH shell.
packf Compress a folder into a single file (UNIX mail
format).
sortm Sort messages (chronologically).
whom List the person(s) a message would go to if
sent.
For a brief introduction to the Mail Handler system, please see
the Athena Essential Mail document. For detailed information on
any MH.5 command or facility please see the appropriate man page
or the MH.5 Users' Manual (available soon).
_________________________________________________________________
NEW CHSH AND CHFN
WARREN MADDEN, STUDENT SYSTEMS PROGRAMMER
The Unix command chsh allows users to change their default login
shell. Chfn allows users to change personal information such as
name, office address, office phone and home phone, which is
displayed by the finger command. In the past, only the machine
on which these commands were run logged the change temporarily.
As a result of the July release, information on the machine on
which you run the command as well as information on all other
Athena machines on which you have accounts will be changed,
automatically, by the following day. This is because the old
versions of these commands changed the /etc/passwd file on a
particular machine. The new versions change the central Athena
user database, whose information is propogated to each machine's
local /etc/passwd file every night.
Also, chfn will now allow you to enter more information. In
addition to the fields mentioned above, you will be able to enter
your nickname and home address.
See the man pages for more information on how to use these
commands.
It may be a good idea for users to run these programs and
verify/correct the data.**
-----------------------------------------------------------------
NEW SCHEME RELEASE
MARK LEVINE, ACTING MANAGER OF
APPLICATIONS SOFTWARE DEVELOPMENT
Athena has received a new release of Scheme from the Scheme Team
at Tech Square. The new release incorporates some bug fixes and
other changes. The most visible ones for the casual user are:
- The command scheme now starts up the student band of
scheme every time. This allows scheme to start much
faster. The old version took optional arguments for a
band name or syntaxed intermediate file and allowed you
to set various parameters; this will no longer work.
If you need a customized environment, you will need to
use cscheme, which does support command line options.
- The Emacs interface has been changed to use process
control. The (emacs) function can no longer take a
filename argument to edit and/or load. (emacsl) has
gone away. However, you can suspend the child emacs
and return to scheme. Calling (emacs) again restarts
the suspended emacs, so new emacs instances do not have
to be created over and over again within scheme.
- We are also releasing the scheme compiler, called the
"liar" compiler.
Documentation is now available on how to make a band, cross
syntax a file, and use the "liar" compiler. These documents are
located in /usr/doc/scheme as cross.txt, liar.txt and bands.txt.
Additional information may be obtained from Mark Levine (mail to
yba or phone 253-1528).**
_________________________________________________________________
X WINDOW SYSTEM
TONY DELLA FERA,
DEC SOFTWARE ENGINEER
The July 1985 release of the X Window System Version 9 brings
with it many new utilities and a new C Language interface
library. Users who have been using the old, unsupported window
system should take note of the information below. For users who
have never used a window system, it is a set of programs which
allow you to section off parts of a screen on an advanced
graphics terminal (such as the VS100, now called xterms) into
"windows." Since you can run jobs in each window, it is possible
to actually "see" several jobs running which are running
concurrently.
The following utilites will be supported:
xterm Allows you to create windows that emulate a
regular DEC VT 102 or a Tektronix 4010. (Formerly
xpty)
xwm X System window manager that allows you to move
windows around with the mouse and change window
size and shape.
bitmap Tool for drawing X bitmap pictures in C include
file format that other programs can use. The
drawing is somewhat like making pictures by
shading in squares on a graph paper.
xclock Analog or digital clock.
xhost Utility for specifying who can create windows on
your terminal by X server access control.
xload Monitors system load by displaying it versus time
as a bar graph.
xset Utility for setting X user preference options.
xwininfo Tool for reporting X window information.
The following utilites are not yet supported but are available
and may be supported in the near future.
xdemo X Window System demo's.
xperfmon Graphic system performance monitor.
There are man pages available for every command. To learn how to
use X, the best way to start is to read the man pages for xterm
and xwm.
Users of the old window system, please note that the old xpty
terminal emulator command has been replaced by the new xterm
terminal emulator. Xterm includes Tektronics 4010 support as
well as support for the DEC VT 102 terminal.
We have introduced an access control system that denies remote
access to your X server (display) unless you explicitly grant
such access via the xhost program.
We have also introduced a user preference specification system.
By specifing default values for X system-wide or program-specific
parameters in a preference file, the user will be able to make
his/her preference settings available to any X application that
uses the preference system.
In general, many utilities have been modified and, as such, we
encourage you to examine the man pages associated with utilities
that you have been using or are likely to use in the near future.
New with this release of X is a supported C Language interface
library called "Xlib" that is useful if you are interested in
writing your own window programs. Xlib contains routines for
accessing and manipulating local and remote X Window System
servers. While this library is fully supported, many sections of
it are still under development.
Xlib currently provides the following facilities:
- Display/server access control.
- Window creating, deleting and manipulation.
- Full color support on color workstations.
- Full text output support (padded, variable/fixed
width).
- Full graphics output support (vector and line drawing).
- Full mouse support.
- Full window system event support and control.
- Cursor support.
- Icon support.
- Error reporting and capturing.
- User preference file access.
- A system for associating X resources with user data
structures.
_________________________________________________________________
DOMAIN NAME SERVER
JEFF SCHILLER, TELECOMMUNICATIONS
In July, Project Athena will be changing the way we manage our
host name tables.
The major effect will be a change in the way you address network
mail to and from machines outside the Athena system. All
computers connected to the campus data network have associated
with them a 32 bit Internet host address. This address
identifies each computer uniquely within the network and also
contains some information about how the computer is reached from
other computers on outside networks. Normally, users don't need
to know the host address of the systems they are using. Users
just need to know the name of the host itself. Host names are
just the English names that we use to designate systems (e.g.
mit-athena, mit-louiswu).
Within the system there is a table (the file /etc/hosts) that
uses system software to translate host names into host addresses
when needed.
This table currently has several thousand hosts known to it
(several hundred here at MIT, the rest are Internet hosts at
other universities and government establishments). Maintaining
the accuracy of this information is a real headache. The
information is constantly changing. Host addresses change if a
system is physically moved from one location to another and new
systems are constantly being added to the network. When this
information changes, EVERY HOST IN THE ENTIRE WORLD has to update
its table. With the current size of the network and its rate of
growth it will soon be impossible to keep up.
Because of these problems, all users of the Internet will be
installing software that uses a distributed database to translate
host names into addresses. MIT will only have to maintain a table
of computers that are located at MIT. If an MIT computer needs
the address of a computer at Stanford, a request will be made
over the network to a special "name server" host at Stanford
which, using tables resident only at Stanford, will perform the
translation. In order to determine which name server to use when
"resolving" a host name, the names themselves now have some
structure to them. Such a structured name is called a "Domain
name.
Domain names have the form:
MACHINENAME.ORGANIZATION.PARENTORGANIZATION
So, for example, mit-louiswu will soon have the name:
louiswu.MIT.EDU
This name indicates that louisuw is in the MIT "domain" which in
turn is part of the EDU (for Educational) domain, which is a
"top-level domain".
Thus, with the new release you will occasionally see names of
this new form. These names should be usable everywhere you use a
hostname today. Furthermore if you use a hostname which is not
domain structured (i.e. has no periods in it) the system will
assume it is in the "MIT.EDU" domain and look for it there. As a
temporary hack, if it cannot find the host in the "MIT.EDU"
domain, the system will look in the top-level domain "ARPA." All
currently known machines will be registered in the "ARPA" domain
temporarily until all (or at least most) hosts on the network are
using the new domain name software. However, this domain is
generated from the table stored by the ArpaNet Network
Information Center in California and therefore may often be out
of date.
If you send and receive electronic mail only within MIT you don't
really need to worry about domain names (though you may notice
that host names in the "From" field of messages will have the
domain syntax). Only a username need be given when sending mail
among Project Athena machines. (see "Mail Address" article --
ed.)
If you send mail off-campus you will need to know the domain name
of the systems you communicate with. You should ask the people
you communicate with to ask their system managers what their
domain name will be.
Because of an earlier change to the Athena mail system all mail
is now routed through the host mit-athena (soon to become
athena.MIT.EDU). Therefore when someone from another university
(or from a non-Athena system at MIT) asks you for your electronic
mail address you should tell them that you receive mail at
athena.MIT.EDU. For example, a person with username "sample" who
has an account on mit-louiswu (soon to become louiswu.MIT.EDU)
would tell his friends at Stanford that he could be reached as:
sample@athena.MIT.EDU
and athena.MIT.EDU will route his mail to louiswu.MIT.EDU.
EDITORIAL POLICY
The Project Athena Newsletter is the official publication of
Project Athena, a five-year experiment in the use of computer
technology to improve the education of students at the
Massachusetts Institute of Technology. Newsletter articles
present the general purpose, philosophy, technical development,
and direction of Project Athena, specific news items about
Project Athena facilities and projects. We encourage article
submissions, article suggestions and feedback from the community
and publish contributions whenever possible.
If you have any comments of questions on the Newsletter, contact:
Ayami Ogura
Student Editor
Project Athena Newsletter
MIT E40-426d
Cambridge, MA 02139
(617)253-0110
-----------------------------------------------------------------
MORE ATHENA PROJECTS FUNDED
Since its birth in May 1983, Project Athena's principal goal has
been to integrate modern computer and communications capabilities
into all phases of the educational process, helping students to
learn more creatively and fully in a wide range of disciplines
and aiding instructors to improve and refine teaching methods.
This goal is being pursued through a diverse set of educational
projects, involving the design and development of educational
software and the application of computers to the curriculum.
As a result of the lastest round of proposal reviews, Project
Athena will be funding 12 new projects and renewing support for
10 others. A list of these projects appear on page 13. Every
department has at least one Athena-related project in progress
and there are also several Interdepartmental and Academic Support
projects using Athena resources.
Project Athena, itself, has been made possible by major grants
from Digital Equipment Corporation and IBM Corporation, totaling
nearly $50 million over five years. MIT, for its part, has
embarked on raising $20 million to support the Project, the
majority of which will be spent on curriculum development.
Support funds are being made available to allow faculty time to
work intensively on their projects. In some cases, this support
is provided by the faculty member's department. Often, however,
the support must come from funds specially allocated to Project
Athena. We expect about $10 million of such special funds will
be used for educational projects over the five-year duration of
the Project.
The allocation of these resources is the responsibility of two
Athena Resource Allocation Committees whose members are faculty
and students from across the Institute. These committees
solicit, review and grant Athena support to faculty proposals two
to three times a year.**
_________________________________________________________________
DEPLOYMENT BRIEFS *
One of the more important Project Athena efforts this summer is
the completion of deployment of some 160 IBM PC/AT workstations.
To date, just over half the systems are in place, with the
remainder scheduled for installation by the beginning of the Fall
semester. The majority of the AT workstations are equipped with
professional graphics adapters to support high resolution
graphics, as well as a special software installation to ensure
compatibility with the MIT network.
These workstations represent the first wave of new hardware and
software that eventually will flow into the Institute at a rate
of 50 to 100 systems per month. Long-range projections are for
deployment of more than 2000 DEC and IBM workstations by Spring
1988.
Project Athena is also participating in an advisory capacity in
the renovation of Senior House. Although there are no immediate
plans to deploy workstations to Senior House (or any other living
group), the site preparation model may serve as a useful
prototype for other living groups. Extensive planning and
negotiation by House residents during the Spring semester laid
the groundwork necessary to include space for Project Athena
workstations in the overall renovation plan. Solutions to power
requirement, ventilation, physical layout and security questions
are some of the issues that should be of residual benefit to the
Project as a whole.
The formal planning process, including site surveys, for other
living groups will take place this Fall on a schedule to be
arranged in consultation with each living group.**
-----------------------------------------------------------------
*Deployment Briefs is a monthly column.
-----------------------------------------------------------------
PROJECTS BOOK AVAILABLE
A Faculty/Student Projects Book is now available. It describes
all projects funded by, or using the facilities of, Project
Athena as of the Spring term of 1985. Copies of this booklet
have been sent to all MIT teaching staff. Other interested
people can also obtain one by calling (25)3-1300.
-----------------------------------------------------------------
ATHENA FUNDED PROJECTS FOR FALL 1985
Investigators Department Project
-----------------------------------------------------------------
Profs. J. Ferreira, P. Purcell, Urban Studies
F. Miller and Planners
Profs. E. Murman, S. Widnall, Aero/Astro
J. Kerrebrock, J. Baron
M. Markow Civ. E. An Interactive, Multi-Actor
Infrastructure
Profs. J. Slater, J. Connor Civ. E.
Engineering
Prof. L. Gould EE/CS Revision and Port of the 6.
Prof. J. Kirtley EE/CS Computer Aided Electromagne
Profs. J. Szekely, T. Ring Materials Science
Prof. D. G. Wilson, S. Tsutsumi Mech. E.
Prof. A. Schor, S. Free Nuc. E.
Power Plants (DSNP) as an E
49
Nuclear Engineering
Prof. J. Milgram Ocean E. Project Athena Laboratory I
Prof. D. Yue Ocean E. Enhancement of 13.201
Prof. G. Saloner Econ. Applications of Game Theory
Dr. R. Perry Women's Studies Which Gender is Lee?
Prof. H. Alker Poli. Sci. Playing and Analyzing Seque
Prof. L. Bloomfield Poli. Sci. CASCON-AL
Prof. J. D. Sterman, R. Waring Management
Approach
Prof. J. I. Steinfeld Chem.
Profs. L. Royden, K. Hodges Earth and Planetary
Science
Profs. F. Morgan, A. Mattuck Math.
Prof. H. Rogers Math. Computer-Based Exercises on
Complexity in Elementary Nu
Profs. G. Strang, D. Kleitman Math.
R. Rosales Linear Algebra and Applied
Dr. E. Taylor Physics Computer Displays for Speci
51
-----------------------------------------------------------------
NEWSLETTER DEADLINES
There will be no regular August Newsletter. An addendum to the
July Newsletter will be distributed in August containing changes
to the July release and other announcements.
The deadline for the September issue will be Friday, August 16.
Articles should be sent by computer mail to newsletter or
sent/delivered to E40-426d. Call 253-0110 if you have any
questions.
_________________________________________________________________
END.