response 74 of 203:

Mar 30 19:23 UTC 2001

Regarding #67.  It's been my experience that email can be a pretty big
resource hog.  It's not just the disk usage, but also the memory, CPU,
and network bandwidth which is consumed, as well as the load on the
I/O system's bandwidth for spooling and generally moving data around.
Consider, for instance, what happens if grex goes offline for a few
hours and then comes back on....  The load associated with the resulting
``mail spike'' is nontrivial.

(Note also that I'm not advocating turning off email access; just,
by default, making a little more inconvenient.

Csh and derived shells, when invoked as a login shell, will run a
``.logout'' file when a user logs out if it exists in the user's home
directory and is readable.  However, the user can ``turn this off''
by removing ~/.logout, and it's not entirely clear what would be in
it anyway.  For instance, does it do a find and look for common ``junk''
directory and file names?  What does it do then?  Wouldn't a ``normal''
user be kind of bothered if they had to sit there trying to log out
for 5 minutes while something walks their directory tree and does a ton
of stat(2) calls?  Do let it run in the background after the (On this
machine, I'm not sure that's unlikely even for a user with a relatively
small directory...).  shell has exited, and risk it being killed by this
``robocop'' program, possibly leaving the user's directory in a terribly
inconsistant state?

No, it's much better to run such things in a controlled way, via an
administrative program invoked by cron.

As for having login fork and run a program that invokes df and last,
what exactly does that do?  I'm confused.  :-)

Any sort of skulker script which looks around the filesystem and deletes
things could look for directories named things like eggdrop* (in addition
to files) and remove them.

As for the CPU cycles lost in people compiling things that just won't
run on grex.   Yeah, but what can you do about that, realistically?
You could disable the C compiler, but that seems overly harsh.  Maybe a
solution would be to move it to a directory that's not ordinarily in the
user path (Solaris puts it in /opt/SUNWspro/bin, but then the compiler is
an add on product under Solaris), and then put a note in the FAQ saying,
``if you want to use the C compiler, put the following in your PATH:
....''  That might solve a lot of problems anyway, but is a pain.

response 76 of 203:

Mar 30 21:34 UTC 2001

Regarding #75.  Joseph, I'm not sure what I said that made you think that
I was suggesting *requiring* someone to use one of the web based mail
services, and not allowing them to use grex for mail.  All I'm suggesting
is that, by default, a message pop up that enumerates alternatives and
waits a few seconds before proceeding so that the user is sure to see
that this isn't the *only* way.  Note also that I gave a very easy way
to turn off this ``mail inconvenience feature.''

To justify, and in the spirit of your point, I would humbly submit that
grex is a tool for computer conferencing, not providing free email.
Services like hotmail, on the other hand, *are* tools for providing free
email, and as such, are better for those seeking as much.

As for your assertion regarding web interfaces vs. more traditional MUAs.
Well, you're right; a web browser is a tool for displaying HTML...and
accepting form-based input from a user.  Note, however, that this is all
that Hotmail et al do.  That is, accept form input from a user and return
HTML which is rendered and displayed by the browser.  No violation of
single use principles there!  It's just that embedded within that HTML
is a user's email.

What's more, I've run across many users who have eschewed Unix-based
CLI-oriented MUA's for the free web-based services.  Their justification
is usually that they found the CLI-based MUAs too difficult to use.  If
this interface works better for them, then that's fine.  In other words,
``what makes a good email client'' is subjective.  If an application
running within the context of a web server works for someone, then who
am I to knock it?  I like using MH, and would be terrible if forced to
suffer the abomnible interface of pine, for instance.  Others might feel
(vehemently) different, however, and utterly rebel if forced to use MH.

So, to summarize, I'm not advocating forcing anyone to do anything, other
than wait a few seconds when reading email until they figure out how to
turn that ``feature'' off, or decide that there's a better alternative.

However, if email really isn't a significant load on the system, then
it's a moot point, right?

response 78 of 203:

Mar 31 02:57 UTC 2001

Dan, I read your suggestion in 64 to mean that people who just want to read
e-mail shouldn't do it here.  "Suggesting" a different tool, and then making
the preferred tool "inconvenient" is well down the road towards 'requiring'
them to use the tool you prefer they use.

And "form-based input" is a perversion of HTML.  HTML is a *markup* (hence,
display, i.e. output) tool.

Sindi, MH is the "Rand Message Handler", a collection of single-purpose
tools for converting e-mail messages into individual files for reading,
filing, deleting, etc.  (And single files aren't always one message, but
usually.)  Since each message is a separate file, all the standard Unix
file-manipulation tools work.  It's my preferred MUA (Mail User Agent),
but I use Pine to delete messages I don't want to reply to or otherwise
waste diskspace on.

response 80 of 203:

Mar 31 08:34 UTC 2001

Regarding #78.  Well, you are of course free to interpret what I say any
way you like.  However, I'm not sure you are really giving my suggestion
fair consideration.  In particular, the delay and message can *both*
be turned off, simply by removing a file.  Only the default is the
``inconvenient'' mode.  If a person really decides that using mail on
grex is right for them, then they simply ``rm ~/.mail_only'' and carry
on as before.  However, an assurance is made that they are at least
aware of alternatives.

I *really* don't see how this is ``requiring'' anyone to do anything
(other than possibly removing a file), and it fits in with Grex's mission
statement.  It's a gentle hint that free email isn't grex's main purpose
in life, and that other services are probably more suitable.

Regarding your feelings about web sites/HTML.  All I can say is, ``that's
your opinion.''  It's a completely valid opinion, but I think that you
need to bear in mind that 90% of the rest of the world disagrees with
you, including many, many users who have switched from more traditional
MUAs to a web based interface.

Also, if you're going to take the stance that grex ought to help people
get email, then why not advocate for a POP server?  Or even an IMAP
server?  That way, people could use clients on their desktop machine's to
get their cyberspace.org email.  For the vast majority of users, something
like Eudora is far, far easier to use than elm, pine, mailx, etc.

To me, a web browser is a colorful equivalent of an IBM 3270 terminal;
get screenful of data at one time, transmit a screenful of data at one
time.  Let a block oriented I/O monster on the other end deal with it.
This model really works for some people (obviously you're not in that
category; I'm not either :-), so how can you really knock it on an
absolute scale?

btw- I'm still curious as to how much of a load email places on grex.
If it turns out that the answer is, ``not much....'' then it's hardly
worth arguing about.

(oh, ps....Don't get me started on what a mess HTML and HTTP are, but
let's be realistic; a lot of people use them and like them.  Who are we
to judge?)

response 82 of 203:

Mar 31 13:23 UTC 2001

Agree.

Dan, are you suggesting mail doesn't fit with Grex's mission?  If so, I
disagree.  I would hate to see us only support projects which keep members
of a Club Grex talking to each other in conferences.  Free email and
public access to Unix are wonderful services that we are proud to offer. 
Some day things may change and we may have no alternative buy to eliminate
mail, open Unix, or even dialups.  But that would be a real shame.

response 84 of 203:

Mar 31 19:52 UTC 2001

Regarding #82.  Mary, no, I'm *NOT* suggesting that mail doesn't fit in
with grex's mission (sorry to shout, but I want to be absolutely clear
about this, since I feel that people keep misinterpreting what I'm saying.
Probably my fault for not explaining it well enough).

It's just that it's my understanding that ``free email for the the
world'' isn't what grex is all about.  I got that understanding from
reading from the following ``staff notes'' web page:

        http://www.cyberspace.org/staffnote/about.html

which has this to say about the matter:

        ``Grex doesn't run a POP server. Providing mail service to
          the universe is not our primary goal, even if it is much of
          what we end up doing.''

And then goes on to say,

        ``We want people to get involved in our virtual community,
          so we want them actually get on the system to get their mail.''

Which I interpret as, ``we provide free email for people who are
interested in an online community, but we're not hotmail.'' If I'm
mistaken, please let me know.

All I'm really saying is that, for people who are *only* interested
in free email, and not participation or potential participation in
a community, there are other, perhaps even better, alternatives, and
that if email was using so many resources that it was making the system
unusable for people, it might make sense to encourage those people to
explore those alternatives.  (And that that's a big if; I've not seen
any quantitative data on it pointing one way or the other, though Scott
has indicated that it's a fairly big load.)

Never have I suggested that offering email isn't a good idea, or that
grex get rid of email (or Unix shell access; I'm not sure where that
came from?).  On the contrary, I think they're great services, and I'm
glad that grex provides them.

I'm only offering suggestions for how to reduce disk usage, doing so
under the assumption that mail is one of the largest consumers of disk
resources.

response 86 of 203:

Apr 1 04:08 UTC 2001

Re #81:  Flogging free e-mail to people who can access *any* *other*
*email* *provider*, at the expense of other parts of Grex's mission,
probably isn't the best thing for us to do.  Hotmail and Yahoo and
Angelfire have the bandwidth to deal with ten thousand people shuffling
multi-megabyte attachments around all day.  We sure don't.  People who
want that and nothing more should definitely be directed elsewhere.
Anyone with a TCP/IP connection will be just as well off doing that.

Don't tell me that "we can do it".  There was a time not long ago when
Grex would shut down in the middle of the day to process mail backlogs.
Our "community" functions were being cut off to provide services to
people who had no interest in our community and gave no support.

Grex is best as a discussion forum and community, not a blind mail drop.
We can also provide mail service to people who do not have an ISP
(and thus do not come to Grex over TCP/IP).  There are a lot fewer of
those, but they are Grex's natural constituency.  Offering the rest
a little bit of encouragement to use more resource-laden providers
would make everyone's life better.

Speaking of logs, does ftp keep a log of what it transfers?  If all
we had to do to catch the worst disk hogs was to grep an ftp log
for .tar, .tgz, .gif, .jpg, .mp3 etc. and target them for early and
frequent cleanup, life would be a lot easier.

response 88 of 203:

Apr 1 15:00 UTC 2001

Calcified, eh?  Thanks a heap. ;-)

I don't use Grex mail as my primary email address.  But I'd be 
interested in hearing from folks that do depend on Grex for
mail service as to why they are here as opposed to, say, hotmail.com.

response 90 of 203:

Apr 1 16:21 UTC 2001

I use Grex as my primary email because
1. I can dial in without using up my alloted minutes with my ISP,
2. Marcus's spam filters do a good job of limiting my spam intake, and
3. I think it's good for the Grex Treasury messages I send out to come from
   an address at cyberspace.org.

response 92 of 203:

Apr 1 18:08 UTC 2001

        pine is a pain, and lynx wasn't even discussed. *sigh*

response 94 of 203:

Apr 1 18:42 UTC 2001

Grex is my primary e-mail address because...
 - I don't have TCP/IP net access here at home; grex is a local call
 (Neither my tight spending habits nor indifference to leisure-time
 web surfing incline me to go out and sign up with a much-pricier ISP.)
 - I'm here anyway for the community
 - Minimal junk-mail & no electronic diseases get through here
 - Cool e-mail address & warm feelings without the Big Brother marketing
 dept. or semi-competent staff issues of a commercial provider.

response 96 of 203:

Apr 1 23:18 UTC 2001

Regarding #87; Mark, thanks for letting me know that my interpretation
was correct.  I hear what you're saying about the problem my suggestion
has with possibly scaring off new users.  Hmmm....  I don't have a good
idea on how to address that.  Maybe the wording of the message could
be made as friendly as possible, or the verbage could be moved into
the user account creation process (someone mentioned that it might be
there already).  Then again, maybe it's best just to forget the idea
since it doesn't seem very popular.  :-)

btw- Regarding the user space disk versus the mail disk....  Programs like
elm, pine, and MH's inc all take mail out of the central spool directory
and place it into files in the user's home directory (typically into
``folders'' under the mail or Mail subdirectories).  So while the MTA
(eg, sendmail) dumps mail into /var/spool/mail it should be assumed that
at some point a good chunk of the data in that filesystem will migrate
itself over to /a and /c for ``permanent'' storage.

The df command tells me that there's about 1.1GB of data currently
in /var/spool/mail, but only about 300MB free between /a and /c.
Assuming that 70% of it will get deleted and thus not filed, there's
still not enough space on the user disks to hold mail + user files.  :-(

btw, here's another suggestion.  While there's only about 300 megs free
between the two existing user disks, there's somewhere on the order of
600 MB free on /var/spool/mail.  Most modern MTA's can be configured to
deliver mail directly to a user's home directory.  One way to get some
more usable space for user's might be to move mail delivery into the
user's home directory, and then reallocate the disk that /var/spool/mail
lives on to home directory space.

This would have the advantages of giving user's some more space, and
splitting the I/O load associated with both mail and user access over
more disks.  It would have the disadvantages of increasing the load
on user disks, and possibly affecting mail delivery if the user disk's
filled up (though there's no reason the mail disk couldn't fill up and
cause the same problem if enough people got enough mail in a short enough
time period).

Another suggestion would be to tune the filesystems to reserve less
space for cylinder group reallocations (ie, reduce the ``minfree''
parameter).  It looks like it's set to the default 10%, which is kind of
high considering the size of the user filesystems.  Setting it to 2% or
thereabouts would free up some space, and I don't think it would unduly
affect performance.  Taking the machine down into single user mode and
doing a ``tunefs -m 2 /dev/rsd..'' on a couple of key filesystems might
help some.

        - Dan C.