[2597] in SIPB-AFS-requests
Re: New AFS server status
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Sat Dec 28 23:14:17 1996
From: mhpower@MIT.EDU
To: jhawk@MIT.EDU
Cc: ghudson@MIT.EDU, sipb-afsreq@MIT.EDU
In-Reply-To: "[2596] in SIPB-AFS-requests"
Date: Sat, 28 Dec 1996 23:13:57 EST
> * jhawk has suggested that it might be nice if we could go to
> Solaris for AFS service. ...
>It's not clear to me that Ops is going to move away from SunOS as a
>platform in the near future. I think that we ought to move sooner
>rather than later.
As I mentioned in [2559], I'm opposed to use of Solaris as a SIPB
server platform. I think we should be heading toward use of free
operating systems as server platforms. Until there's more general
agreement that any available free operating system for the sun4m
hardware is sufficiently stable for this, I believe that SunOS 4 is
the right operating system to use on our Sun server machines. The main
reason for this is that, although there isn't widespread (legitimate)
free access to SunOS source, the source is sufficiently similar to BSD
source in enough cases that looking at the BSD source (perhaps along
with the Sun object code) is often sufficient to figure out what's
going on in various situations. This is much less often a feasible
approach to solving problems with Solaris.
I think it's also relevant that there's a lot of work involved in
moving to Solaris, and I believe this effort would be misspent if our
eventual goal is to use free operating systems.
Presumably decisions within IS on choice of server platform will be
affected by their own internal source-code access, and because of that
shouldn't necessarily have any major effect on SIPB's decisions.
>None of these are not a colossal pain to do under SunOS, but require
>applying kernel patches (ipmulti 3.5 and bpf).
I'd be in favor of applying at least the bpf patches.
>Our dependance on using Ops binaries has always struck me as kind of
>wrong. If we cannot use stock transarc binaries, we should consider
>doing our own builds, ...
I agree with this as well. I think what's prevented it is that few
people find it worthwhile to go to the effort of understanding the AFS
build system, perhaps because it's mostly only applicable to that
specific proprietary software, and understanding it isn't a virtue
that's easy to apply to other software development.
Use of "virtue" in the context of AFS is, of course, intentional.
Matt
