response 1 of 74:

Jul 9 10:25 UTC 1998

Expire accounts every 4 hours!  Those who really want to be on Grex should
stay logged in all the time ... just as they should attack-telnet once we get
rid of the telnet queue!

response 3 of 74:

Jul 9 14:54 UTC 1998

Reaping accounts more quickly seems reasonable to me.  Isn't there a 
large percentage of Grex accounts created by newuser and then never used 
again?  I see no reason for keeping all those accounts for more than 30 
days.

response 5 of 74:

Jul 9 15:38 UTC 1998

I have benefitted from Grex's long reap-free period; there have been
months when I didn't log in, and I would have been reaped if Grex reaped
accounts more quickly.  I appreciate that I got to keep my loginid.  I'm
userid 1020; I've been here since Grex first opened to the public, and
I've been 'jep' for 12 years on here and M-Net.  I wouldn't want to lose
my loginid due to reaping.  I really would hate it if someone else got to
be 'jep'.

However strongly I feel about that, it would be worse for me to disappear
for a year or two, and during that period block some new user from coming
on-line and getting to try Grex, than for me to have to take a chance of
losing my loginid.  If I was going to be away for a long period of time,
but expected to come back, I'd send a message to 'staff', and I imagine
they'd do what they could to accommodate my circumstances.

The preservation of old loginids is nice, but if it's a system problem (as
#0 says it soon will be), then I think we need to look at the bigger
picture.  If it's a choice between allowing new users and retaining former
old loginids, I hope Grex chooses the new users.

A reap program that gets rid of people first who came here once, looked
around, and never came back would be great.  I don't know if it's
possible.  If not, well, a quicker reap period will very likely alleviate,
and maybe even *solve*, the problem caused by the 64K user limitation.  If
it's needed, so be it.

response 7 of 74:

Jul 9 16:15 UTC 1998

Changing the reap period would buy some time in an emergency, 
but I don't think it would buy *much* time.  We'd still be adding 75 
users per day.
 
What are all these newusers doing?  They aren't active conference 
participants; are they lurkers?  I had always assumed that they were 
mail users, but janc said in party last night when this topic came up
that he didn't think most of them were mail users.

response 9 of 74:

Jul 9 17:06 UTC 1998

a question:

would it be possible to have a program that checks to see how long the
account has been around and then decide wether or not to reap it?

for example:

sillykid creates an account, logs on a couple times, then never comes
back. The program sees that his account is less that 90 days old and has
been innactive for more than 30 days, so the sillykid account gets
reaped.

another example:

olduser has been around for ages, but for some reason or other he hasn't
been able to log on for a couple of months, the program sees that his
account is more than 90 days old and doesn't bother to see if it's been
innactive for more than 30 days, but checks to see if it's been
innactive for more than 90 days. If the account has been innactive for
more than 90 days then it gets reaped.

I don't know much of anything <O.K.  I don't know anything> about how
the current system works, but that's my two cents.

response 11 of 74:

Jul 9 17:32 UTC 1998

Oops, sorry, #10 should have said that grex *ought* to tell the user that he
can't create an account today, please try atain tomorrow.

response 13 of 74:

Jul 9 17:51 UTC 1998

        I think a combination of the tactics suggested above would be the best
        approach.  Rewrite the reap program to reap accounts as follows:
        
        * Accounts created by newuser and used on that day, but not used
        again for 30 days.
        
        * Accounts less than 90 days old which have not been used for 60
        days.
        
        * Any account for which membership dues are not currently paid and
        which has not been used for 90 days, except by special arrangement with
        staff.


        Also, disable newuser at 65,000 users, with a notice saying that
        Grex is so popular that it has reached its capacity of 65,000 user
        accounts, and would you please try again tomorrow, as old accounts are
        deleted every day, making new openings.

response 15 of 74:

Jul 9 19:43 UTC 1998

I think we shouldn't get bogged down in arguments about reap scheduling 
and policy.  
 
As I understand the situation: this is oversimplified a bit, but every day 
we create 100 Grex accounts which will eventually be reaped, and 75 
accounts which will stick around.   On a 90 day expiration cycle, 
this means that we have a bank of 9000 sure-to-be-reaped accounts.
We could go to a 30-day reap cycle and immediately reclaim 6000 accounts
from that bank: but that's a one-shot deal.
 
Recovering those 6000 accounts will only buy us 80 days of growth if we 
keep adding 75 long-term users per day.  That will be useful in an 
emergency, but it won't solve our long-term problem.
 
Our choices are:
   1) commit to whatever it takes to remove the 64K limit on the number 
      of Grex users -- if this is even possible in the time remaining
   2) accept that there will be periods, starting next year, in which 
      "newuser" is going to be shut off.  These periods will get longer 
      and longer, if we keep adding 75 long-term users each day "newuser"
      is open, and eventually there will be essentially no new users.
   3) Be willing to decide that some uses of Grex are more important than 
      others; start steering away Grex users who are only here for the 
      services we deem less important. 
 
Hmm, let me rephrase option #2 vs. option #3:
   2) Allow Grex to fill up on a first-come, first-served basis, 
      and shut the doors to latecomers for all our services -- 
      ** including conferencing **
   3) Take pro-active steps to shape the Grex community in the belief
      that our community-building services are the most important ones.

response 17 of 74:

Jul 10 07:52 UTC 1998

I think it's a bit premature to assume grex is just automatically going
to run out of UID's sometime next year.  Another important limiting
constraint is the number of users we can support online at one time, and
the kind of performance we can offer those users.  I think it's highly
probable that before we run out of UID's, we'll run out of network
capacity, telnet ports, CPU, or so other load bottleneck.  It's worth
keeping in mind, too, that with our current text-only operation and no
global media advertising, there are limits to the % of people who might
be interested in us, or who might discover us.

So far as an upgrade path goes, there are a number of interesting
choices.  We could continue to go with sun hardware, and run Solaris
2.6, which *does* support long uid's.  Or, we could migrate to RS/6K's
and AIX, which has long supported long uid's.  Or, we could choose to
run openbsd, and adapt it to run long uid's, perhaps even on the current
hardware.  Each has different costs, performance, and security risks.

Another issue to consider in terms of upgrades, of course, is the kind
of computing environment we want to end up in.  The kind of "server"
technology that grex is running on is getting relatively scarce.  What
is much more the norm is to use "workstation" technology for servers -
and to run services distributed across several such workstations.  The
next generation of sun server hardware after the 670 is probably the Sun
Enterprise server 1000, of which I happen to know of 3 in the A^2 area.
The equivalent "workstation" technology would be the SparcStation 10 or
20, of which there are probably at least a thousand in the A^2 area.

It's certainly worth looking at the services we offer.  A *substantial*
chunk of the service we currently offer is definitely free e-mail.  I
don't think we've done any studies, but it's highly possible that 50-90%
of those "75 new permament users every day" will only ever be using grex
for mail.  Perhaps we should resign ourselves to competing with hotmail,
and deliberately set up a number of machines dedicated *solely* to pop
mail, with their own separate arrangements for UIDs and such, and shift
mail to that arrangement.  We could then issue "pop-only" mail to the
unwashed masses, and separate full-shell and computer conferencing
access to only those that really want it.  We could also probably shove
the mail servers behind some sort of network throttling gateway if they
prove *too* popular, although hopefully hotmail and other free mail
giants, with their big budgets, have a sufficient head start on us that
we won't be serious competition.

response 19 of 74:

Jul 10 15:26 UTC 1998

Another possibility is to advise people that they can get free e-mail on
hotmail and other free e-mail providers and sing the parises of those other
providers more loudly.  Then we hope that if e-mail is all they want, they'll
find it elsewhere...

I don't want to completely stop offering free e-mail -- but if we could find a
way to limit it that would be no bad thing.

You're right Rane, that offering free e-mail is not a particularly fun thing
for Grex to be doing -- but it is valuable to some people and worthwhile.

response 21 of 74:

Jul 11 03:06 UTC 1998

Yes you can look at conferences in Backtalk without signing up. In some
conferences, the author may invoke an option which renders his.her posts
unreadable that way, but most things should be readable. Users will have no
participation file, and will not be able to post.

I agree with Ken Josenhans that adjusting the reap policy doesn't buy much.
I strongly urge grex not to reduce its 90 day reap policy.

I agree with Marcus that STeve's projection doesn't take into account other
factors, and thus I too expect growth to slow. With 23000 accounts and a max
of about 80 users on simultaneously, we still have 299 users not logged in
at that time for every one who is. I doubt that this ratio can be forced much
higher. The telnet queue will get too long and people will lose interest.

In answer to atticus in resp:12, backtalk users need to own files too,
because their conference participation file is in their account. therefore, it
is not possible for backtalk users to use backtalk on Grex without consuming a
UID. Note: It *is* possible, but it requires configuring backtalk differently,
and in that mode it could not share conferences with picospan, which is why I 
say it really isn't possible.