What Software Should Be on What Machines?
Mathnet/PICnet consists of a lot of machines controlled by various sets
of users, who have a variety of needs. The major user sets are:
- Office Staff
- Applied profs and grads
- Pure profs and grads
- NFS grant supported profs and grads
- Statistics (not for long)
From the administrative point of view, we would like to have the
machines be as uniform as possible. Each user constituency would like
to have the software they need to do their work. We need to balance
The machines are differentiated by purpose, and by
architecture. Presently we have four incompatible architectures: Sparc
(Solaris 5.5 and 5.6), i386-Solaris, i386-Linux (SuSE and Red Hat), and
i386-WinNT. For the most part this discussion is about UNIX, but to
some extent it applies to Windows also.
By purpose, there are desktop workstations, home directory servers, compute
servers, and system servers (e.g. Fern, Arachne). The distinction between
these roles is vague for these reasons:
- Desktop machines tend to be newer and hence are more powerful than
the homedir servers. If a user has a desktop machine we prefer
that he keeps it busy rather than burdening a general department
resource. Powerful desktop machines are our best compute servers.
- Many users have X-terminals or hunk-of-junk desktops; hence all
functions appropriate to the desktop machine must also be
provided from the homedir server.
- If a person can be convinced to run jobs on a compute server
(leaving aside the issue of PBS), he will want to do program
development there also, read mail, etc. And it's a purely
arbitrary decision to try to push such usage elsewhere, and
incidental interactive use will be of no consequence to getting
compute jobs through, particularly if the compute server is
- While we're moving toward dedicated system servers, traditionally we
have used the servers (Malibu, Julia) as homedir servers as
well, and the load caused by either function doesn't have a
significant impact on the other. Security is the primary force
pushing us toward dedicated system servers.
- In any case, system staff need to be able to login to any machine
and do administrative work, using tools they are comfortable
The conclusion is that a basic suite of software should be provided on
every machine, regardless of architecture or purpose, which will support
basic desktop-type work, and which will support compute server types of
activity. The key point, though, is what should this basic software
From the opposite direction, we have a large number of software packages
which are specialized, large, expensive or used by only a small subset
of the users. We have traditionally set these up on one machine and
then let all the others NFS mount it. This works well. However, now
that we're branching out to i386 Solaris/Linux architectures, there may
be some requests for specialized packages there. Here are some
- If the package is related to the mission of the requester's group,
and they have a lot of machines of that architecture, make an
effort to install the package. Example: pvm or lapack on
- Otherwise, tell the user to use it on Sparc architecture (or whatever
it's already installed on). Example: Macaulay. Example: gimp,
which would be on Linux, not Sparc. Except apparently we installed
it on Sparc as well.
We shall have to deal with several administrative issues connected with
packages that are not present on all machines:
- Each package should be installed on at least two fileservers, and
perhaps more for high-use packages like TeX. We need an auto
failover mechanism for when one server is down. A suitable
automount map is recommended: for example, /warez/macaulay might
be mapped to /u/bach/m1/Macaulay-94.09 with a fallback to the
same directory on Sonia.
- It's important to audit the multiple copies for being identical.
We need a more flexible tool than the present rdist scheme.
- Architecture is important. The package links and/or automount map
needs to be architecture dependent.
- For most packages we install the whole thing for each architecture.
But for many packages, like PBS and TeX, the major portion is data and
configuration files, which are architecture independent. We need a
standard strategy for using architecture-dependent executable
programs and shared data.
Basic Desktop Software
Now as for the basic software to be provided: Most of this is actually
already on the Sparc systems, but a few items are prospective. I trust I
haven't left out anything :-)
- Authentication. The same loginID and password should identify the
user on all Math/PIC systems, whatever the architecture and
administrative group. Our user should be able to authenticate
himself with high security. As far as the operating systems permit,
a user authenticated on one machine should be able to execute on
another without giving the password again.
- Connectivity. Our user should be able to initiate a TCP/IP
connection to anywhere on the Internet, and we should avoid
configuration issues that make ourselves unacceptable to outside
partners. Our user when abroad should be able to initiate a
connection to a reasonable subset of the Math/PIC machines.
If at all possible, some compute servers should be outside the
firewall so users abroad can go direct to them.
Office staff require tn3270.
- Security. We should not require, and probably should not allow,
authentication through clear-text passwords whether globally or on
the local subnet. Our users should be able (and perhaps be
required) to use encrypted connections both incoming and outgoing,
which shall interoperate with encryption software generally used by
- Mail. Users should be able to send e-mail and to read their system
mailboxes, which our server will maintain for them. We support these
mail clients (on Unix): Berkeley mail, Pine, a web mail interface,
and an X GUI mail reader. All but Berkeley mail can be, and perhaps
should be, configured to work through an IMAP server.
Presently the web mail interface and X GUI reader are vaporware.
But such programs exist and could be installed. Mail readers on
Windows are major security problems.
- Data Processing. We support a spreadsheet program and a database
client. Users shall have some means to create their own
databases (tables) in their own home directories.
Presently all of this paragraph is vaporware, but I feel it's
important for users to have this capability outside of Windows. Star
Office is supposed to be able to provide this capability.
- Program Development and Execution. Specifically:
- Editing files using vi, Micro-Emacs and Gnu Emacs.
- Compiling in "C", C++, Fortran-77 or Fortran-90. On Sun
systems, both Sun and Gnu compilers are provided for each
language for which they are available.
- Libraries of mathematical or computational functions such as
BLAS and Lapack, and also statistical packages.
- Long job execution using a POSIX-compliant queuing system such
- Parallel computation (on compute servers only, but every machine
is potentially a compute server.)
We do not have, and long ago should have installed, a
Fortran-90 compiler. I don't know if Fortran-90 is available from
Gnu; I believe not.
- Word Processing. Specifically:
- TeX. Faculty and grad students use this exclusively to prepare
theses and math papers. The LyX front end to TeX is said to be
good as a pseudo-WYSIWYG tool, but I haven't used it.
- Simple word processing. The Star Office imitation of Microsoft
Word is what I have in mind here, for cases, like correspondence,
where TeX is overkill. But word processors tend to suffer from
- Printing. From any machine we should be able to print any of these
formats, and we should also be able to preview them:
- Plain text (with ``less'' as the previewer)
- PostScript (with GhostScript, driven by Ghostview, as the previewer)
- PDF (by Adobe Acrobat; and we also need to be able to create them)
- TeX DVI files.
- Web Browsing. A text browser should be available (lynx) as well as a
reasonable GUI browser. As much as I hate Netscape, and as much as it's
supect from a security point of view, our users will demand it. We should
investigate Opera for Sparc, with the possibility of a site license. Other
freeware browsers like Amaya and Mozilla could also be checked out.
- Calendar maintenance, including sync with Palm Pilot.
Presently this is vaporware, though Star Office is said to have
a calendar program that syncs with Palm.
- Symbolic Mathematics. It is not practical to provide symbolic math
packages on all systems, but these are the most often used application
packages, and pan-architecture support will eventually be demanded.
The major packages we support are Matlab, Maple and Mathematica, as well
as specialized ones such as Macaulay and Russell.
- Graphics and Visualization.