response 149 of 203:

Apr 18 22:15 UTC 2001

resp:148

(very much so.)  :^)

response 151 of 203:

Apr 20 02:28 UTC 2001

A fair number of people drag stuff over using Lynx or other web
browsers.  This is particularly popular for graphics, but it is also
common for software (it's easier to setup apache than ftpd), and of
course for vandal tools (httpd logs are generally not as useful.) I'd be
very surprised if even 50% of the bloat on grex comes via ftpd these
days.

response 153 of 203:

Apr 20 04:47 UTC 2001

I use ftp to get files OFF grex; I'd not appreciate losing access to it.

response 155 of 203:

Apr 20 15:01 UTC 2001

I'd suggested making incoming FTP operations drop altogether after a 
certain number of kilobytes, instead of just slowing down.  If most 
files are now coming in via lynx, that wouldn't help, though.  (And I 
suppose if we did limit FTP PUTs, lynx use would probably jump.)

I really think the only permanent, reliable solution to this would be 
disk quotas.  It's a classic disk quota situation.  That may need to 
wait until we get newer hardware and/or a newer OS, though.

response 159 of 203:

Apr 26 16:51 UTC 2001

NetBSD's kernel architecture is less advanced than SunOS: it doesn't yet
support even asymmetric multi-processing.  That means it won't make as
good a use of our current very cheap hardware.

response 161 of 203:

Apr 26 19:07 UTC 2001

Well, considering this decade is only about 4 months old, that means
expensive *new* hardware at close to list prices.  To get something
roughly equivalent to the current hardware, we'd be looking at SCSI disk
and ECC (or at least parity) RAM, and a non-intel instruction set CPU.
There are a number of fine makers of such hardware, but it would be a
stretch to make our budget cover any of them.

Keep in mind when comparing to the 3AM "act now" TV offer computer that
what you see on TV probably comes with one spindle of IDE disk, no tape
backup, virtual parity RAM, intel instruction set CPU, a lot of
software, video hardware, etc., that we don't need, and is generally
optimized to perform well as a slightly flakey computer for *one* person
who is probaby not doing a lot of multi-tasking.  Grex probably *could*
afford that system, but spares would be another question.

IDE disk is cheap, but doesn't do overlapped seeks - not a big issue for
IDE since it only supports 2 disks at most.  Grex has a history of
expanding to fill its disks - no upgrade path seems pretty dubious to
me, especially given that the excuse for this whole project is so we can
store an infinite number of copies of eggbots and graphics.

Backups - I think it goes without saying that these are important.  We
currently have a very nice SCSI tape drive, less than 1 year old.  We'd
certainly want to continue to use that if at all possible.

"no parity" ram works fine when it works.  Of course, you'll never know
when it doesn't.  We've already lived through flakey memory on grex, but
at least we *knew* it was causing kernel panics.  Memory that was
flakey, but *doesn't* crash the system.  Do we really need it?

"Intel instruction set".  Don't get me wrong.  I have a lot of respect
for Intel.  Nevertheless, the pragmatic fact is (1) intel does not have
a pristine bug record, and (2) *every* vandal under the sun is trying
exploits using intel machine language.  Using almost anything else will
buy us at least 2 months of time to patch holes, and completely dissuade
80% of the vandals out there.  Also, if you price out intel hardware
with SCSI disks, sufficient ECC RAM, etc., you start looking at prices
that are pretty comparable with the non-intel server market.

response 163 of 203:

Apr 27 03:44 UTC 2001

Actually, I offered to donate some Sun hardware to grex about a
month back, but, alas, I never heard back from anyone, and the
hardware is no longer available.  Specifically, I was offering a
Sun Ultra 2 with dual 170 MHz processors, 640 MB of RAM, and 40
GB of SCSI disk spread across two controllers.  I also offered
to throw in an Ultra 1 with 128MB of RAM and 22GB of disk, plus
a SPARCstation 5 and SPARCstation 2.  That would certainly have
mitigated some of these problems, and would have also provided
an upgrade path.  Plus, grex could have continued to use its
current tape drive.

I'm not sure why no one got back to me about any of this.  All
I asked was that grex pay for shipping from New York City.  Of
course, to effectively use the dual processor Ultra 2, grex
would have had to move to Solaris.  Perhaps that had something
to do with it.

Marcus, I'm not sure how you can rate SunOS 4 as more advanced
than, say, NetBSD, just because it lacks the hack multiprocessor
support of the former.  Consider that NetBSD has many features
that SunOS doesn't, such as large file and filesystem support, a
better VM system, soft metadata updates for UFS file systems
(which, IMHO, would be of huge benefit on grex), file flags, kernel
security levels, and more.  Not to mention active maintenance.  In
fact, I'm willing to bet that a single Sun Ultra 1/170 running
NetBSD would blow the doors off of the current Sun running SunOS
in all respects, would use less power, and only cost a few
hundred dollars.  I'll even help grex finance some or all of it,
if desired.

response 165 of 203:

Apr 28 01:25 UTC 2001

Continued very interesting technical discussions.

New/fast/sexy hardware for grex would be nice to talk about.

It would take at least hundreds of hours of staff time - time that
doesn't seem to be available - to get grex working on any new hardware.

Ergo, i don't think that new hardware is a viable strategy for dealing
with the disks-perpetually-filling-with-crud problem.

response 167 of 203:

Apr 28 04:22 UTC 2001

(Right; they just have to install GNU versions because that's what most people
use.)

response 169 of 203:

Apr 28 04:31 UTC 2001

I don't remember using GNU versions of df or ls on SunOS 4 systems, either.