Greg> 0. To be realistic, we must assume that there never will be substantially more
Greg> funds for MIT academic computing than there are now, and that continued slight
Greg> decline is likely, so that doing big new things requires current things to
Greg> change.
I agree with the implication that doing big things requires current
things to change. But I wouldn't write off the possibility of getting
more, well, if not funds, then at least equipment through donations
and joint programs with companies, on the model of HP donations of the
6.001 lab, and the effort that started Athena itself. For example,
a couple of us have been brainstorming with Motorola about supplying
wireless service to campus. What is true, is that we can't count on
new funds to support our current "bread and butter" service, but there
may be opportunities for sufficiently imaginative things.
Greg>1. [discussion of more powerful machines ...]
I would prefer that IS be "Information Services" rather than
"Computing Services." What I mean by this is that supplying keyboards
and monitors (or even computing cycles and disk storage) should not be
a major part of what the central service does. I would much rather
see specialized computing resources paid for and maintained by
individual departments and laboratories, where they will have to
complete with other academic needs and where there will be a much
greater opportunity for synergy with research computing facilities,
and real integration into departmental programs. I realize that this
will lead to some duplication, but I think that eliminating the
overhead of central planning and administration will more than make up
for this.
greg>2. [students should own computers]
I agree. There need to be some details fleshed out. (Do students need
to own printers? What about file space and backup storage?)
greg> first 3. [network drops and machines for faculty]
I agree
greg> second 3. [Use of clusters]
I think we should move to reduce the size of the clusters. We should
keep a few machines for backup and convenience (e.g., I occasionally
use the clusters when I am across campus to log in on my office
machine). One place I disagree is with the implication that we should
be "outlawing" various modes of use, or assigning priorities to
modes of use. Given that students should be doing course work on their
own machines, I don't know what the "high priority use" of a public
cluster is.
greg> 4. A reduction in basic document processing, programming, and network-service
use of public Athena workstations should permit us to reduce dramatically the
number of "Athena" seats devoted to traditional, generic workstations capable
of everything, perhaps by about half.
I agree. Perhaps even by 2/3.
greg>5. We can then replace the no-longer-necessary half of the traditional Athena
seats with fewer but specialized machines, which may mean more expensive and
....
I disagree. Specialized machines should be the responsibility of the
departments. Remember that today's high-performance machines are next
year's ordinary machines and 1997's semi-obsolete machines. High
performance machines also generally require less generic software, which
Academic computing should not be burdened with supporting. I greatly
prefer the 6.001 lab model, where an advanced facility begins within a
department, closely tied to a course, with technical support leveraged
on research funding, and where the facility gets ported to generic
machines and operating systems as these mature.
greg> 6. [additional complexity of heterogeneity]
The way to deal with heterogeneity is to adhere to standards, so that
the difficult problems will be addressed by the vendors. IS should
get out of the operating system business. The reason that the Athena
environment is so hard to port is that the original Athena project
didn't have this view. Layered Athena is a good move -- we should
have made it 4 years ago, and we should be allocating more people to
it now. We should discourage things that rely on hooks in the OS
kernel, that conflate computing with user-interfaces (such as the
Athena dashboard) and that move us away from industry standards. (For
example, moving to AFS was a mistake -- let's not compound that by
moving to DFS.)
greg>7. [all this must happen incrementally]
I agree. There are a lot of implications about priorities for system
software development. Someone needs to put this list together.
Two things that are not on Greg's list:
We need a long-term strategic plan. For example, when do we need to
rewire the campus to support a high-speed network? How much will this
cost?
We need to understand (and perhaps redraw the turf lines) between
Academic Computing, IS, and the rest of the information dukedoms on
campus. For example, the current situation with the MIT directory is
stupid. The current situation with the libraries is bad but
improving, the current situation with the registrar's office is scary.
As for purchasing and such, I won't dwell on things like EREQ
passwords going over the net in the clear.
One reason to put Academic Computing under a high-level standing
committee of the faculty is to give these priorities some clout, not
only within IS, but across the Institute.
-- Hal