response 75 of 127:

Dec 16 15:30 UTC 1994

Wowza!  We will be looking for volunteers to help hang drywall and
stuff in early January.  I think we'll be able to find enough people
locally that you don't *need* to drive up from St. Louis, but if
you'd like to do it to be social and to help out, you'd be welcome.

I need to post a dungeon update, and dates and times when we'll next
need volunteers.

response 77 of 127:

Dec 16 22:49 UTC 1994

It's wired.

response 79 of 127:

Dec 17 17:17 UTC 1994

The important dates or Jan 14,15 for painting, and Jan 21 for the move.
The Jan 21 date is quite uncertain. We will probably move on the day before
if Ameritech won't switch the phone lines on a Saturday.

response 81 of 127:

Dec 18 10:31 UTC 1994

Is the drywalling already done?  I guess painting sounds cool though, too.

response 83 of 127:

Jan 16 17:10 UTC 1995

This item was once a discussion about a possible hardware upgrade...  <ahem>

response 85 of 127:

Jan 16 22:49 UTC 1995

Hi Mark, you can pick up on the discussion over in planning/finances.  It
is a rather good discussion I think.

response 87 of 127:

Jan 19 00:09 UTC 1995

In the other, Mark, a broader range of things are discussed along with 
the faster 486.  Grex News conf was my idea of having a place to read 
articles about these volumes so one doesn't hav wade though volumes.  I Know
I went through all this one night but I must have fallen asleep with my
eyes open ;-) "my idea" doesn't mean it was my idea ;-)

response 89 of 127:

Feb 19 18:25 UTC 1995

  This item has quieted down a bit, and some staffers lean toward Sun
upgrades, but until the is final decision is made, I think it's a good
idea to keep considering the options as the market changes.
 
  With Pentium prices around $500 more than 486's and falling, I think
the 486 vs. Sun discussion should really be about Pentium vs. Sparc.
 
  Advantages of Suns/Sparcs over Pentium systems that people have offered
in co-op: Pentiums are more prone to compatibility glitches, they're
slower, they're not as rugged, they're more susceptible to low-level
security hacking, they cost more to start out with (can't use our current
parts), they cost more used, and a picospan port would be harder.
 
  I don't know a lot about Suns/Sparcs or Unix hardware in general, but I
do know a fair amount about Intel-based hardware, so I'll share what I know.
 
  Not all Intel-based systems are built flimsily.  Industrial PCs are made
to withstand harsh environments (corrosive chemicals, high heat, air
pollution, vibration), and "super-server" PCs are usually designed with
built-in redundency (dual power supplies and motherboards, duplexed RAIDs,
etc.).  But they're priced sky-high.  Mass-marketed PCs definitely aren't
as sturdy.  However, in my experience, if a cheap PC survives a brief
burn-in period, it's common for it to go several years between hardware
failures, even running continuous duty as a file server.  It helps to have
a clean, quiet, cool environment with a good U.P.S. (true for any computer).
 
  Getting things up and running, with compatibility issues resolved, can
definitely be a chore, moreso with Unixes and other less common O/S's for
PCs.  Generally speaking, interface cards cause more problems than
motherboards (though I've heard with some Unixes the motherboard matters).
Certain components (disk controllers, net cards) should be from well-known
companies.  Video controllers are probably the trickiest to get running,
but since Grex doesn't need any flashy graphics, it shouldn't be an issue.
However, if Grex did decide to go the cheap PC route, it should try to get
things up and basically tested within return policy limits (usually 30
days), in case of "irreconcilable differences." :)
 
  Below are some prices based on mail order components for a general Grex
overhaul.  It would definitely take some serious fundraising and work!
 
Grex
 
  Migrate the Sun to recent Intel technology.
 
    90MHz Pentium w/PCI bus................. $1050
      (floppy disk, mono monitor, serial port, no ram)
    32Mb ram (w/o parity chips).............. $900
    Adaptec 2940 PCI SCSI2 interface......... $200
    3Com EL-III 16-bit ISA ethernet card..... $100
    Software (PD Unix, yapp license)........  $150?
    Shipping.................................. $50
    ----------------------------------------------
    Total................................... $2450
 
  * RAM: Grex currently has 64Mb ram, so 32Mb would be a step back, but
    virtual memory would be much faster.  Add 12% for parity chips on the
    SIMMs, which detects memory failures, but memory doesn't fail often.
 
  * Disks and Tape: Grex's current three disks and the tape drive, being
    SCSI peripherals, should all be usable with this system.
 
  * Ports: Grex has a 16-port serial interface.  If we wanted that for
    this system, it would cost around $900 new (or $500 for an 8-port,
    barely meeting current needs).  However, Grex wants a terminal server
    in the long run anyway, whether using a Pentium or a Sparc, so this
    would be a better choice.  I didn't include it above, since it should
    be purchased for either style system.  $800 used for a 16-port T.S.?
 
  * Ethernet: There are PCI ethernet cards for $100, but I haven't seen
    any name brand PCI ethernet cards, so I'd advise sticking with 3Com
    (or another common one) for now, unless it's a major bottleneck.
 
  * Software: I'm not sure what the software needs would really be: if a
    free Unix would be adequate, if picospan could be retained, if free
    tape drive drivers are available, etc.
 
Usenet Server
 
  Convert the current Grex Sun system into our Usenet server.  It's familiar,
  which may ease setup, and it has 64Mb of ram.  And with only one disk, the
  current disk problem might disappear.  I don't know what it would take to
  get the communications/newsfeed part of this working, but below are some
  other likely requirements.
 
    2Gb SCSI2 disk........................... $650
    Two cheap 28.8 modems.................... $300
    Communications/newsfeed.................. $???
 
Combined
 
    Usenet Server...... $950? + comm costs
    Grex Pentium...... $2450?
    Terminal Server.... $800?
    ------------------------
    Total............. $4200? + comm costs (+ a big time commitment! :)

response 91 of 127:

Feb 19 20:22 UTC 1995

  I accounted for the serial input and extra disk in the "combined estimate,"
which is not optional for getting the Grex part working (see the note on
"* Ports").  The pricing is just split up since the other things will likely
be purchased regardless of whether or how Grex's CPU is upgraded.
 
  I figured a SCSI CD-ROM drive is just needed during installation, and could
be borrowed.  But 64Mb of paritied RAM instead of 32Mb would add an extra
$1100, and BSDI binaries another $200, so I'd boost the estimate by $1300.
 
  Personally, I don't think the price is depressing, just challenging! :)
I think Grex could raise a fair amount of money if it had an attractive plan.
(Not that this is necessarily the most attractive one, of course!)

response 93 of 127:

Feb 19 22:35 UTC 1995

Your price on 4Mb SIMMs is about right, but one 16Mb SIMM is often less than
four 4Mb SIMMs...bulk discount I guess :).  AmRam, Memory Source, and Shecom
sell 4Mx36 72-pin SIMMs for between $525 and $529, which is what I used.

response 95 of 127:

Feb 20 00:36 UTC 1995

  Original pricing was for 32Mb unparitied RAM.  After STeve's suggestion, I
said add another $1100 to make it 64Mb paritied RAM.  Which actually should
have been $1200...I misadded the update.  It should be 4 x $525 = $2100.
(A neuron must have flipped in my head, and it didn't have a parity neuron).
 
  By the way, would a 16-port Digiboard make more sense than a terminal
server for this system?  The estimate for a new Digiboard is near the same
as for a used t.s....I was just thinking t.s. since Grex wanted one anyway.

response 97 of 127:

Feb 20 09:41 UTC 1995

One of the things to keep in mind with the pentium/bsd option is that it
was not really designed for our type of environment at all.  This
applies to all levels of the design, not just the case & motherboard.
Basically, PC's were designed for home and office use by one person.
For such a use, an occasional crash once a week, or even once a day, is
not a major concern.  I've had a windows programmer assure me, in all
seriousness, that all windows users reboot their machine at least once a
day, "just because".

Unfortunately, if you take that "one crash a day" statistic, and impose
the type of load that grex creates (almost flat out through at least
half the day), you aren't talking about one crash a day day anymore.
You're talking about dozens of crashes a day.  Now, you and I know that
pentium systems are, in fact capable of better reliability, but --
BUT!!!  That doesn't come by buying the cheapest possible system,
tossing it quickly together, and hoping it all works.  [ and, we've
proven it - with the router! ]

My concern extends to more than just the hardware.  Take freebsd, for
instance.  Freebsd is a wonderful product.  Not only is it worth every
penny we paid for it, it's even worthy competition for OS's that cost
hundreds, or even thousands of dollars.  Nevertheless, it, too, was
fundementally designed for "occasional" by one person.  There are
tradeoffs in the design that make this clear.  Some of them are pretty
esoteric - like it doesn't save %fs & %gs in the kernel.  Some of them
are surface things -- the script to add users to the system is obviously
not intended for adding 20-30 people at once (or the kind of automated
account creation we do here on grex.) Some of them are kind of scary -
like the X software allows anyone to "steal" the console tty.  That
feature is easy to find (it's a configuration option) - but there's
another X support feature that's not nearly so obvious - the console
driver supports an ioctl to permit the selected task to access any input
or output port.  That permits the X server to manipulate the graphics
hardware.  But!  It also allows any process that's executed this ioctl
full access to *ANY* I/O port - including the interrupt controller, disk
controller, etc.  That certainly gives any amateur cracker the ability
to crash the system, at will.  It would probably give any cracker with
some patience and brains, the ability to crack root.  Now, one of the
nifty features of freebsd is that it comes with full source.  So, with
time and patience, we can find these problems.  And, of course, they're
not a big problem on the router - where we don't expect to joe random
user accounts on it.  I took freebsd only because it was handy.  The
same risk exists in any other product, from SCO Unix to BSDI.  The only
difference is, it may be harder to find.

All of the above are at least things that, given sufficient patience
(ie, a *lot* of staff time!), we can find.  But, there are even more
basic issues where I'm even more pessimistic.  The Pentium is, in fact,
a *very* complicated chip.  It's far more complicated than the 286, 386
or even 486.  Nevertheless, even in these simplier chips, Intel has made
fundemental mistakes in the protection model.  Some mask levesl of some
chips include features "similiar" to the X server support I described
above - but buried into the CPU chip, so they can't be patched or
disabled in software.  Some features are so wide-spread that they've
become market opportunities for clever 3rd-party software houses.  For
instance, "paged" real mode doesn't exist, officially - but there's a
way to trick most 386/486's into doing it.  Paged real mode is actually
sort of useful; so I'm not at all sure why Intel decided to "fix" it on
the 586, instead of documenting it as a new feature.

The above are, of course goofs by accident.  On the pentium, however, we
have the possibility of "goofs on purpose".  There is, for instance, a
secret "appendix H", which is only available to selected vendors who
have paid big bucks to intel and signed non-disclosure documents up the
wazoo.  That means us ordinary peons have no idea what's in that
appendix.  That means we don't know if it's just boring junk about
instruction scheduling, or if there are nifty ways to speed up VM
performance - and if the latter, we don't know if any of those ways
poses new security risks - or if there are bugs in those new ways that
would pose a risk that even Intel doesn't know about.

The pentium is a *very* complicated chip.  Another possibility is an
unauthorized undocumented trap door coded in by a clever intel engineer.
This is not necessarily a far fetched idea; about 10 years ago, it was
*very* customary to find trap doors coded into video games that would do
something neat.  It might just be the name of the author, or it might be
a testing mode so that the engineer didn't have to become a hot shot
user in order to debug the advanced levels, or it might be something
else.  Hardware chip designers have often done similar things that are
generally not at all obvious except under the microscope - putting their
girl friend's name in silicon or whatever.  With the pentium, and its
successors, we now have a similar opportunity in microcode.

Naturally, if intel were to find such a bug in the pentium, I think it's
been conclusively proven we'll never find out about it until it's too
late.  The floating point debacle makes that pretty obvious.  So, the
question to ask is- what is the chance that the guy who created
"spamalot" and "pyrus" here on Grex will find out before staff does?

response 99 of 127:

Feb 20 21:50 UTC 1995

Marcus, I think the problem here is Windoze, not an inherent problem in
PC based hardware. I think you've gotten a skewed view of PC hardware based
on the fact that all you've seen run on it is Windows and DOS.

Where I work, we have 2 486/50 EISA based machines with several SCSI drives
each. They both run Interactive SysVr3 UNIX. We do 24 hour a day EDI
transaction processing on those machines. 10's of thousands of transactions
every day. The disk drive lights rarely go out. And yet, with all that load,
we have uptimes for both boxes measured in *months*. They are very stable.

Crappy software does not produce crappy hardware. Like someone said above,
I've also seen Netware run for months and months and months with no
downtime on various 386 and 486 servers.