Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site scgvaxd.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!scgvaxd!kvc
From: kvc@scgvaxd.UUCP (Kevin Carosso)
Newsgroups: net.college
Subject: Re: Free and undirected campus computing facilities - Not at Waterloo
Message-ID: <238@scgvaxd.UUCP>
Date: Mon, 26-Nov-84 00:06:56 EST
Article-I.D.: scgvaxd.238
Posted: Mon Nov 26 00:06:56 1984
Date-Received: Wed, 28-Nov-84 13:12:05 EST
References: <457@utcsrgv.UUCP> <649@watdcsu.UUCP>
Reply-To: kvc@scgvaxd.UUCP (Kevin Carosso)
Organization: Hughes Aircraft Co., El Segundo, CA
Lines: 147
Summary: 

Tony, for once we are in agreement with you! However, you will be pleased to
know that people can still hack at Harvey Mudd; they just have to pick a better
system than muddcs. As you know, we (Ned and Dan) are the managers of the ymir
machine, which is operated by the Mathematics Department at HMC. I cannot speak
for muddcs, but to illustrate how our system is run we would like to answer
Steve Roth's criticisms of muddcs insofar as they apply to ymir:

(1) "Users have no access to source code for any commands."

  ymir runs VMS, which does not include full source to the operating system.
  There are times that the source would sure be handy but we can't do much
  about it; a source license is way too expensive. In reality though, this
  does not hinder hacking, since its pretty easy to add all sorts of bells
  and whistles to VMS. We have been happily hacking without source for
  several years and don't miss it all that much.

  Listings of the VMS source are available on microfiche, so you can at least
  see how things work. We have a microfiche reader to read them. The
  microfiche themselves are kept under lock and key (not a good policy in our
  opinion, but they do cost a lot) but students can borrow them for limited
  periods of time.

  Sources to locally written programs are all user readable. When we have
  source to various vendor software packages such as Template, TeX, SLATEC,
  SMP and TCP/IP, we protect it as little as our license agreements allow.

  Unlike the other systems at HMC, the help files for all system programs,
  including the "dangerous" ones, are readable. We figure that it makes no
  difference if you know how to use system utilities like AUTHORIZE, SYSGEN
  and DISKQUOTA. We think it is preposterous to try and hide such things --
  which other system managers around here do -- its like a cat trying to
  cover up its mess on a linoleum floor. A student can, after all, buy VMS
  documentation themselves straight from DEC and learn more than they
  would ever want to know about these things.

(2) "Users have no write access (and little read access) to anything
    outside their own directories."

  On ymir the default is for all files to be group readable, so people can
  read the files of other people in their own group (which are likely to be
  the ones they are interested in). Of course, some users protect their own
  files -- they do have a right to their privacy. I (Ned) personally leave all
  my personal crap world-readable on the off-chance it might be useful to
  someone nosing around. When users have a reason to write something somewhere
  that somewhere is probably not protected -- the UUCP spooling areas are such
  a place. We maintain this policy in spite of several rather nasty abuses
  that have occurred in the past; we feel that the cure of protecting the
  system to the hilt is worse than the disease.

(3) "Users have no access to networking facilities for the other
    machines on campus."

  All ymir users can access DECnet, TCP/IP and UUCP, which covers all the
  networking stuff we have. We don't have netnews. This means you can send
  mail to systems outside HMC and you can access all other systems on campus.

(4) The final question -- free access.

  We routinely give accounts to any student who asks for one. Accounts have
  reasonable amounts of disk space, and disk allocation can be easily increased
  (a simple verbal request usually does it). User accounts are not granted any
  special privileges, but when someone is interested in writing privileged code
  they can request any privileges they need and they will usually be granted;
  we do have to clear such privileged users with the management of the other
  computer systems on the network. This is part of our agreement with the
  management of the other systems (including muddcs). We must protect the
  network from "unauthorized access", or we will be thrown off it ourselves. We
  don't like it, but the network is not under ymir's jurisdiction and access to
  it is not controlled by ymir policies.

As you can see, we are a small group of hackers working within a much larger
political structure. We don't particularly like the structure, but it is a
compromise that we have learned to live with. It is reality, and we are sure
that it is not much different from situations that have surrounded hacking
elsewhere. This sort of thing sure existed back in the days of the KA-10 that
Tony recalls with such fondness! We have done what most hackers have to do and
carved ourselves a workable, stable niche from which we can hack with impunity.

Steve is not the only one who has chafed under the muddcs management policies.
Here are a couple of our own beefs:

(1) muddcs cannot be taken down for system work except on Saturday mornings.
    By contrast, ymir has no fixed system downtime policy. If we have to do
    something, we find a time when few people are using ymir, we warn the
    users and then we do it. We are considerate to users but not to the point
    of hamstringing ourselves. Like muddcs, we do have a lot of classwork and
    so on that is done on ymir, but such inflexible policies are unnecessary
    even so. (Note: Comparing average interactive usage data seems to indicate
    that ymir is used about the same amount as muddcs.)

    We once got in quite a bit of trouble once for taking down muddcs without
    permission. When we were writing the VMS end of our TCP/IP network (as
    requested by the management of muddcs) we had to take down muddcs in order
    to restart their networking software. The system was completely idle at the
    time, but from the trouble it caused you might have thought that we killed
    an active system and cost dozens of users many weeks of work.

(2) Access to the ymir machine room is available to everyone who needs it. For
    example, the four muddcs Gods Steve mentions have always had access to our
    machine room. By contrast, despite our need to get into the muddcs machine
    room (we share a tape drive with them) we are denied access unless a God is
    present. No doubt we intend to crash their machine again.

(3) Although we expect users to behave reasonably on ymir, we do not subject
    people to the indignity of having to sign a document saying they will be
    nice. We do not assume people are irresponsible. muddcs requires such a
    signature prior to giving anyone an account.

Russell Schilling points out that "the needs of the many outweigh the needs of
the few", i.e. classwork on muddcs necessitates a lot of system restrictions.
With all due respect, Russell, that's a load of bull. Sure, some restrictions
are needed, but its a question of degree. I have been working on computer
systems at HMC for about seven years now and I have never seen a system as
restrictive as muddcs. Even the old DEC-10, which was used for administrative
work including student accounts and grades, was nowhere near as restrictive as
muddcs despite the sensitive nature of the data it contained. Student hackers
were given quite a bit of freedom on that machine.

This whole attitude becomes even more ludicrous when you consider where a lot
of the software that all those classes use comes from. Hackers, that's where!
It has always proved to be in our own best interest to encourage exploration
and exploitation of the machines at HMC.

The thing that peeves me (Ned) the most is that the original hype we were fed
about muddcs when it was originally set up was to the effect that it was to
be the "hackers machine", where people who disliked the management policies
of the other campus machines could gain the freedom they needed. UNIX, God's
gift to operating systems, would allow all users to make OS modifications with
no problems, everyone would coexist in peace and harmony, etc. Now we find that
the truth is not so pretty. And it is all so unnecessary. Protect your system
with your own knowledge, not with the ignorance of your users. By the time a
user learns enough to circumvent a hacker they will BE a hacker.

The math department at HMC has a long tradition of hackers associated with it
that has been firmly in place since 1971. It has been a long and profitable
liason that has been challenged countless times over the years by just about
everybody -- HMC administration, the other departments (especially Computer
Science) and even outsiders. The math department has backed hackers at every
turn, protecting them from the wrath of others and in many cases taking
punishments on itself. We hackers owe them a hell of a big debt for this.
We repay it by making ymir into a superior system. This arrangement is
alive and well today and shows no signs of breaking down.

------------------------
Ned Freed (HMC '82)	scgvaxd!ymir!mathmgr   engvax!ymir!mathmgr@CIT-VAX
Kevin Carosso (HMC '82) scgvaxd!engvax!kvc     engvax!kvc@CIT-VAX
Dan Newman (HMC '85)	scgvaxd!ymir!dan       engvax!ymir!dan@CIT-VAX