response 26 of 127:

Oct 13 16:58 UTC 1994

To keep the system running we need money and technical expertise.  Our
income is increasing, but the expertise part is less easily expandable,
I think.  There aren't that many people who are willing, on a volunteer
basis, to put in the kind of work that you and Greg have been putting
into the system.  There aren't that many people with the
qualifications, period.  If you and Greg were to be run over by, say, a
truck, Grex would be in dire straits in the hardware and technical
troubleshooting departments.  Where would your your replacements come
from?

So since new money seems to be an easier commodity for Grex to acquire
than new technical expertise, I'm wondering if a switch to the more
ubiquitous 486 platform wouldn't be a favorable trade-off for us --
more off-the-shelf solutions to problems (and consequently less of a
need for home-grown technical expertise) -- despite somewhat higher
costs.


Maybe it's not something we can do immediately, but perhaps it should
be part of our longer-term thinking.

response 28 of 127:

Oct 13 21:26 UTC 1994

I would hope that if STeve and Greg were run over by a truck, we would
have more concerns than just who would maintain the system.

response 30 of 127:

Oct 13 23:08 UTC 1994

After a helluva a wake and suitable period of mourning and reminiscing,
we'd limp along until the hardware crashed and no one could bring it
back up (due to lack of expertise).  
 
In another item, I've brought up the idea of a staff mentoring program.
If it could be brought about to train new staff and improve the already
knowledgeable staff, it would help with our expertise shortage (or
actually, concentration, rather than shortage).  I'd hope that whatever
Unix system knowledge exists at Grex, and which can be passed on,
would be useful as well on a 486 Unix system.  Any comments on this
idea?

response 32 of 127:

Oct 15 16:33 UTC 1994

The problem isn't that this is Sun technology, the problem is that this is
*antiquated* Sun technology.  Hence, software patches are difficult to
obtain or are unavailable, peripheral equipment may have problems (!!),
and capacity may be difficult to increase.

The migration to SPARC or Intel technology would require similar 
administration efforts.  Both of these have modern SVR4 Unix environments
available.  Both have multiple vendors competing, which keeps prices down.
However, there is a much wider array of hardware products for the Intel
platform, and there are even excellent freeware Unix environments, such
as Linux.  Whether Linux or other freeware Unix clones can support 
our large multi-user requirements with stability is open to question.

If one is considering SPARC, one also needs to consider other competing
RISC technologies as well.  SPARC has the lion's share of the market,
today, but there are constant leapfrogs in the RISC industry.

If we change technologies, due solely to price/performance of two-year old
technology -- I recommend Intel be given a very close look.

response 34 of 127:

Oct 16 05:05 UTC 1994

Ummm, except the for this moment - after this itme I did a    check to
see what else tocatch up on. Whoops .....
  
You are not a member of jellyware
You are not a member of sexuality
  
Like hell i'm not ....... the disk problem may not be fixed
yet ??????

response 36 of 127:

Oct 16 14:37 UTC 1994

Sorry, Greg, but you're looking at this from the wrong end of the telescope.
SVR4 is better than SVR2 or SVR3, precicely *because* BSD features were
added.
 
The issue of migration from BSD to SVR4 is what keeps many long time
BSD administrators away from SVR4.

Sorry you feel Solaris is a "crock."  I happen to find it a  stable,
easy to administer environment.  (At release 2.2 and 2.3.)

response 38 of 127:

Oct 16 16:40 UTC 1994

Sorry, Josh, but I disagree. I have *considerable* experience with:

1.) Generic BSD 4.3(and now some 4.4) on a 386/486 platform,
2.) SVR3 on 386/486 platform,
3.) SunOS 4.1.* on various Sun-3 and Sparc hardware,
4.) AIX 2.* on IBM RT's.
5.) Ultrix on various DEC hardware,
6.) SVR4 on 486 hardware,
7.) And one frustrating encounter with Solaris (aka: Sun's port of SVR4)

After this, it is my considered opinion, and also that of most, if not all,
of the system managers that I know, that when you weigh SVR*'s advantages
against it's disadvantages relative to BSD, that comparison comes up as
a "lose" for System V.

One of System V's biggest failings is it's attempt to build all sorts of 
nifty system administration tools that distance the user from the data actually
being manipulated. While on the surface this appears to be a Good-Thing,
because it makes the job initially easier, it the final analysys, it is
actually a Bad-Thing because you end up with an entire cadre of sysadmin
people who are dependant on these tools and have little idea of what to do
when the tool breaks or they need to do something out side the envelope
of the tool's capabilities. They know nothing about *where* and *how* the
data actually lives so that they can manipulate that data by hand if the
need arises.

SVR3's "kconfig" utility is a particularly odious example of this scenario,
and the *entire* AIX 2.* environment was this philosophy on drugs.

response 40 of 127:

Oct 16 17:12 UTC 1994

Right, and then too there's this "shadow password" stuff...  :)

Getting back to the issue at hand -- at some point we'll need to move
on to newer technology.  Here's a hypothetical question:  If somebody
donated to Grex *today* a 486/33 EISA system with fast SCSI-2, 0.5 gb
of disk, and a CD-ROM drive, which would folks prefer -- stick with the
SUN-3 until we can afford new Sun technology, or make the switch to 486
at this point?  Granted there'd be expenses involved with such a
switchover -- besides the staff time and effort, we'd have to spend
money on an OS (BSDI, for instance), additional serial capability to
handle multiple dialins, and probably some other things.  But would we
want to switch if we were gifted with a 486 system such as the above?

response 42 of 127:

Oct 16 17:28 UTC 1994

Can't we have both?

response 44 of 127:

Oct 22 22:07 UTC 1994

The 1000 may not be supported under SunOS 4, Steve.  I'm not 100% sure,
but I think that's the case -- though this is an academic discussion.
 
I'd go with a SparcServer rather than Station; we don't need the monitor
and 3.5" diskette drive, among othe reasons.

Getting back to commercial Unixes for a moment -- and leaving Solaris
emotional issues aside -- would you consider an operating environmnet
desinged for symettric multiprocessing?  Perhaps a pair of cheap 486s
or older Sparc technology could advance the performance of Grex's 
environment without too much money?

response 46 of 127:

Nov 26 12:59 UTC 1994

This sound's like the perfect time to split the processes off the main machine
onto simmilar, or different hardware, eg. If you took the Mail,Usenet stuff off
the main machine and put it onto another, then you can spead the load. The
system can them talk over etherne. This is what Monochrome have done on spark
stations! and there is no problem with accessing the system, even with the bbs,
the mud etc.... going all at once. (neutron.city.ac.uk)

Mike

response 48 of 127:

Nov 26 19:16 UTC 1994

I think Mike is right about splitting the load.
There are a lot of details to be worked out, but the staff is going
to be discussing some of the possibilities. If we can figure out a plan,
we'll be back here to talk about it. Despite the differences between
various unix ports, I think it largely won't matter if 486s or suns are
used for the different components, though.