response 174 of 203:

Apr 28 20:33 UTC 2001

Regarding #173; Note that NetBSD comes with virtually all of the
software you mentioned (GNU tar, gcc, gzip, etc) already included in
the base system.  I'm not sure why one would need gcc or GNU make to
install gzip; I just did it as a test using Sun's SunPro C compiler and
/usr/xpg4/bin/make under Solaris 7, and it passed all tests.  As an aside,
I'm astounded that the uncompressed shell archive which makes up GNU tar
is 4.7MB in size, which speaks to the poor implementation of the package.
As far as shells go, tcsh has both of the features you mention, and
ksh can be coerced into doing both command recall and file/command name
completion (I don't know if it uses tab for the latter).

But, I'm less concerned with the merit or dismerit of any particular
package from GNU, and more with the maintainability of the system as
a whole.  Right now, it's not too good, from what I can see.

Regarding the kernel blocks and picospan; again, much of this
functionality can be assumed by other packages.  For instance, with the
hardware I wanted to donate, one could easily make, say, the Ultra 2 be
``grex'' and disable all outgoing network connections (except for http
and DNS or whatever is intentionally left open) using Sun's built in
firewall software.  Then, set up, say, the SPARCstation 2 as a machine
which only staff and grex ``members'' can login to, and which has no such
restrictions on outgoing network traffic.  This eliminates the need for
making any modifications to the kernel, and the machine could double as
something else, too (for instance, a web server).

Similarly, the functionality of picospan could be taken over by another
package.  Say, an NNTP server (NOT part of the USENET in general)
running on the Ultra 1 I wanted to donate, or by the notesfile package.
The former would have the benefit of allowing, eg, grex and m-net to
share conferences.  party could be replaced by a private IRC server
and specialized client.  Orville write by the zephyr messaging system.
Note that at this point, most services are being replaced by ones
which extend over a network, allowing grex to scale by moving from
a single big computer to a cluster of smaller ones (this is called
``Client/Server Computing;'' perhaps you've heard of it?  :-).  The DBM
password database could be replaced by the builtin DBM password database
in NetBSD, or it could be replaced by a secure LDAP server under Solaris.
Authentication could be handled by a dedicated Kerberos server (like the
SPARCstation 5 I wanted to donate, which could also do backups via the
AMANDA package [if AMANDA, which can use Kerberos authentication and do
network encryption of backup data during the dump process, incidentally]
ran on the Kerberos server, one could still get network backups while
minimizing the exposure of the Kerberos server).  The password hashing
scheme currently used would be a problem, but there are ways around
that, too.

Note that doing this *would* require some changes in the way that the
system was used, but I think that in the long run the added functionality
and ease of maintenance would be well worth the short term discomfort.

The overriding principle in doing any of this would be to come up with a
system that's more easily supported than the current one, while providing
the same or analogous functionality as the current one.  I have no doubt
that this could be done, and I'm somewhat disappointed to see grex NOT
take this approach.  I fear that much of the reason why has less to do
with technical feasability, and more to do with NIH.  That'd be a shame.

response 176 of 203:

Apr 28 22:08 UTC 2001

So is INN, c-news, the UIUC notesfiles implementation, and many, many
others.  What does picospan offer that these don't?  I'm really very
curious.

response 178 of 203:

Apr 28 22:15 UTC 2001

"Welcome to Grex, the Living Computer Museum!"  as I usually say in party.

response 182 of 203:

Apr 29 04:46 UTC 2001

Marcus has source to Picospan, and has done some stuff with it for Grex in
the past.  The problem, as I understand it, is that the current ownership of
Picospan is rather unclear, and the license that was transferred to Grex was
for the binary, not the source.

The OS debate, like many architechture issues, is an issue where there's no
clear, one size fits all, answer.  Most systems have plenty of advantages and
disadvantages, and plenty of advocates and critics.  Some points of view are
better thought out than others, and some ways of doing things are better than
others, but it's often very hard to agree on which is which, and often the
advantages to be gained from doing things the "right" way aren't nearly as
great as its advocates think.

Most of these decisions are actually made based on local factors.  The
strongest of those, in established organizations, is the legacy factor.  If
a system is already running, changing it can be a lot of work.  In addition,
if that system is working well, bugs introduced in the changeover can easily
make things worse, rather than better.  Another strong factor is that people
tend to use what they're familiar with, and that's not an entirely bad thing.
The best system in the world run by somebody who doesn't know what they're
doing probably won't work nearly as well as a bad system run by somebody with
a clear understanding of how to make it work.  All quality and even price
issues aside, this is a large factor in why so many companies hiring their
system administrators straight out of high school run Linux -- it's what the
kids have been playing with and gotten comfortable with.  The other free
Unixes tend to pick up smaller chunks of the same market, for the same reason.
People coming out of Solaris heavy institutions tend to use Solaris when given
a choice at a new job.  People who have been using Windows all along tend to
lean toward NT.  In Grex's case, it's original staff members were comfortable
with SunOS, and Grex started running SunOS.  Because Grex has always run
SunOS, it doesn't seem to need fixing, and both the older and newer members
of the staff have learned it and gotten comfortable, Grex continues to run
SunOS.  It's certianly not what I would do if I were in charge and starting
from scratch, but that doesn't necessarily mean it's wrong.

The bigger question, then, is whether the problems people here have been
pointing out with SunOS, override it already being known to the staff, and
override it already being up and running.  Would the improved quota support
in some newer systems be enough of a timesaver that it would save the staff
more time than it would take to implement it?  Would there be more good people
volunteering to be on the Grex staff if Grex were running an OS that more
people new how to administer?  That sort of thing.

response 184 of 203:

Apr 29 18:40 UTC 2001

I'd hate to see Picospan axed to turn Grex into yet another private 
USENET heirarchy.  I happen to like the Picospan interface, and I think 
it works better for the kinds of discussions we have here than a 
newsgroup heirarchy would.  I also haven't found a text-based news 
reader that was as easy and quick as Picospan's interface.  They're all 
either bloated, clumsy, cryptic, or all of the above.  tin used to take 
three minutes to start up, on my MTU account.

I actually alternate using Picospan and Backtalk.  If I'm going to go 
through all the new responses, giving my full attention, I use Picospan. 
 If I'm going to be more leisurely about it, I use Backtalk, because I 
can let it sit for 20 minutes while I do something else without timing 
out my connection.  It's a tribute to how well Backtalk is designed that 
I can go back and forth between it and Picospan with no problems.

response 186 of 203:

Apr 30 01:38 UTC 2001

Dan's new Sun's aren't available any longer?  Damn.  I know staff was
planning to take him up on that - life got in the way (in my case, a
broken clavicle.)

SunOS 4 had primitive multi-processor support in it.  SunOS 5 (aka
Solaris) has much less primitive multi-processor support.  Both of these
beat the multi-processor support in OpenBSD, which is zip.  This isn't a
really big issue, except that our current hardware has 4 slow processors
in it, so "upgrading" to OpenBSD would result in throwing away 3/4's of
our CPU.  Technically, the "more advanced" architecture of Solaris (or
the "newer" architecture of OpenBSD) doesn't really buy us much.
Solaris has kernel threads, a much more sexy user thread model, &etc -
and is somewhat notorious for being less efficient on the same hardware.
OpenBSD would give us source so we could port the tcp & fork bomb logic
forward more easily, leaving us with essentially the same capability we
have today.  In either case, we'd still have a *lot* of homework to do.
There isn't a quantum leap forward here that will give us anything we
don't have today.

response 190 of 203:

May 1 05:03 UTC 2001

The maintenance effort in terms of time, labor, and sweat all translates
into a cost, even if it's personal as opposed to financial.  All though,
we saw a grex staff person post in this very thread about she spent a
working day cleaning up grex's disks, thus leading to a realized loss
for her financially.

Many of the things which you list as making the job of moving to a newer
machine more complex are precisely the things which I think grex ought
to do away with in the interest of making its staff's lives easier.
The password database is a prime example; is it really that inefficient
on modern hardware to make use of whatever the system comes with?  In the
case of *BSD, I'm having a hard time believing that pwd_mkdb running
on a modern machine, with a modern disk subsystem, is going to be so
much less efficient than what grex currently uses as to be unworkable.
Also, how often would it be run per day?  Even 200 times, at 15 second
run times, is less than an hour a day.  The same holds true for passwd(1)
(besides, one would hope that grex would take this opportunity to move
to Kerberos and it's kpasswd program).

As empirical evidence that the Solaris password scheme is also workable,
it *appears* that the nether.net system, running on a Sun4d with 8 (!!)
processors uses the stock Solaris passwd subsystem (file and associated
commands, no dbm indexing).  It appears quite zippy, and supports twice
the number of entries as grex (large UID's would be another useful feature
of newer OS software).  Anyway, I'd think that a dual processor Ultra
2 would be comparable in performance to a SPARCcenter 1000.  ahh, yes;
each of those processors runs at 40MHz, a lot like grex's.  I'd put my
money on the Ultra.

This is reminiscent of a useful maxim in software engineering, about
optimization.  The first rule of optimization is this: Don't do it.  Why?
Because most of the time you don't need to, and it just makes maintaining
the program significantly more difficult.  A parallel can be drawn to
system administration.

OpenBSD on a uniprocessor UltraSPARC would be problematic, since there is
currently no Ultra port of OpenBSD.  I agree that it would be somewhat
of a challenge to move grex to other hardware, but I don't think it
*has* to be as complex as you seem to be making it.  In particular,
if you guys cut out a large amount of the custom software, particularly
in the ``hacks to the OS and associated subsystems'' arena, it becomes
signficantly easier.  I think that making a move now represents a good
opportunity to do just that.

Another useful software engineering maxim is this: Don't diddle the code,
find a better algorithm.  In my opinion, a lot of what grex has done to
fix problems in the system is akin to diddling code; moving those hacks,
which might very well have made sense on SunOS 4, to a new system seems
counter productive.  The kernel patches to restrict outgoing network
packets are a good example of this.  Instead of putting that logic
into a custom kernel hack, put it into rules in a vendor's existing
firewall offering, and then give members access to another machine
without those restrictions.  You never have to worry about ``porting''
the changes again.

I guess what I'm saying is that grex, in an absolute sense, probably
has far fewer special needs than it's users and maintainers believe it
does.  One can exploit that to ease the maintenance burden put on its
staff in moving to new hardware.

response 192 of 203:

May 1 12:58 UTC 2001

A seperate machine for members would also cause us to end up with something
like the mnet "reserved telnet ports" situation, with nonmembers waiting in
the telnet queue for their machine while members slip by into their own special
private box.  While that isn't really a problem, exactly, I've gotten the
impression that giving members that amount of special privilage isn't really
something Grexers have been comfortable with.

response 196 of 203:

May 1 18:05 UTC 2001

IP chains *was* what Linux used.  It was a replacement for ipfwadm, which
was deprecated because of some limitations it had.  Now they're apparently
replacing it with iptables, to make sure everyone's good and confused and
compatibility is all shot to hell. ;> I don't know what advantages iptables
has.  FreeBSD also used to use ipfwadm, I think.  I don't know what they use
now.

I kind of like OpenBSD's ipfw functionality.  At least it has *real* state
tables, instead of the user-space hacks you have to use with ipchains.

response 198 of 203:

May 3 23:55 UTC 2001

It would be nice to have the hardware/software/upgrade/etc. discussion
in the garage cf., instead of here, where i suspect that it just shuts
down discussion about the issue actually at hand.

Staff & board can handle the problem; it'd go better if they could get 
good user input beforehand.