David Brownlee <abs@anim.dreamworks.com> wrote:
> [probability of failure arguments]
>
> This is rather simplistic as it assumes all failures are equally
> disruptive [...]
   
   They are not. The system would be blown out only if the disk/mail server
were to fail, and that's the same as a single box.
   
> [...] but it does illustrate the point.
   
   Because of the above argument it doesn't.
   
   A secondary note. Where have you got the idea that if you use Pentiums
or SPARCs you need only a single box? INS has perhaps 60 machines, each of
them is either a Pentium running BSDI or a SPARC running SunOS. Of these
only a few Pentiums serve the users (two serve CWRU users telnetting from
inside CWRUnet, one serves community users dialing in, and two serve
everyone telnetting from outside CWRUnet). Nonetheless, whenever any of the
other machines crash (and they do that all the time), everyone is locked
out. Why? Because in their paranoia, they have set up a shitty
authentication system that requires a half dozen different servers to
approve a user login. When you dial in, the terminal server box asks you
for your username and password and sends them to a special server which
then must respond positively for the user to log in. If you get this far,
you can telnet to the UNIX box. There you will be confronted by a special
hacked login program. In addition to requiring the Kerberos server's
approval, it uses a proprietary protocol to ask a special server whether
you are a student, faculty, or what. You see, they want to be damn sure
that a bull doesn't try to use a resource reserved for Jupiter himself.
Finally, after passing the login program you get a highly restrictive shell
substitute. That program requires some configuration files that are NFS-
mounted from yet another server, even though they are seldom updated and
could be kept locally. If that machine is down, you are out of luck. If the
program can't find its configuration files, it logs you out.
   
   Remember that my goal is to match INS in performance and reliability
while providing a normal UNIX shell instead of the fascist, paranoid, and
useless restrictive menu system. Given how deeply INS sucks, this should
not be a problem even with VAXen.
   
> Since your machines are locked away from the users all they see is
> the software interface, be it on a Vax or an Alpha.
>
> You are arguing two points here - the hardware and the software.
> The hardware _only_ matters to you - the users only care about it
> if it is slow or down. (The software has been covered in a different
> email)
   
   Jacob H. Suter <jsuter@intrastar.net> wrote:
> I seriously doubt that is going to be better than a semi-modern x86 or 2
> or 3 running a common free Unix system (FreeBSD is what I would
> recomend).  Something like FreeBSD or NetBSD has a lot of people
> supporting it, with BSD4.4 you find a hole you're on your own...
>
> Its not that "proper ARPA Internet access" is a bad thing, but
> technology moved on.  Security holes were found, things were sped up,
> and it all just works.
   
   and
   
> Now, the truth is you seem to just be setting up a secondary "elite
> vanity" service for your school.  Noble, but not terribly professional
> unless you can beat money out of someone/people for it.  When people
> pay, they bitch, welcome to the real world.  As long as its free its
> pure vanity.
   
   I have discussed these very issues at length when I first joined this
club. See <http://sclwww.scl.cwru.edu/~mxs46/intro1.txt> and
<http://sclwww.scl.cwru.edu/~mxs46/intro4.txt>.
   
> With multiple stand alone boxes you can have complete hot standby
> systems.
   
   As I have explained many times, stand-alone boxes, especially multiple
ones, are a nice idea in theory which is unimplementable in practice. How
are you going to let the users access their home directories and mailboxes
regardless of where are they logged in?
   
> Although I am interested in seeing what you make of this 4.4BSD "pure"
                                                           ^^^
> stuff you speak of.
   
   Have you read my discussion with Ty Sarna (archived at
<http://sclwww.scl.cwru.edu/~mxs46/bsd10.txt> and
<http://sclwww.scl.cwru.edu/~mxs46/bsd11.txt>)? There I describe why
4.3BSD-* is a much more appropriate base for this work than 4.4BSD
(primarily because the 4.4BSD sources won't compile on a VAX :-)).
   
> I'll slap it on a vax here to see someday when/if you ever do it.
                                            ^^^^^^^^^^^^^^^^^^^^^^
   
   Help this happen by helping me find copies of 4.3BSD-Tahoe and 4.3BSD-
Reno!
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu