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.

response 25 of 74:

Jul 12 05:02 UTC 1998

oops, the link I typed in resp:21 exposed a backtalk bug. It should have 
worked and pointed to resp:12 . I am fixing the bug, which was caused by 
the comma following the link, and the link will work once a new backtalk 
is installed here.

picospan users please ignore - sorry for the drift - 

The backtalk strategy of providing access to users without requiring an 
account was well thought out, I believe. Asking people to take out an 
account poses a barrier for many people. With this feature, they can see 
what might be in store for them if they take out an account. They are 
urged to do so. It was not so much intended to reduce the number of 
abandoned accounts (wlthough it should do that) but to attract people 
who would otherwise not come in.

response 27 of 74:

Jul 12 15:30 UTC 1998

I'd recommend saving your pennies and just buying some big fancy PC,
setting up some sort of *BSD on it, that you have full sources to,
and do it that way.  1) Replacement hardware is easy to find 
2) Full source to OS and all its drivers is great for doing local hacks
3) despite (insert marcus paranoia about someone hardware hacking system),
   there quickly come out OS patches for stuff like the 0xf00f stuff that
   prevent any such attack.

response 29 of 74:

Jul 15 18:05 UTC 1998

I just entered a long response, and it appears it didn't get posted.
Mebbe I'll have the energy to re-type all that tomorrow, if it doesn't
find its way out of the bit-bucket.

response 31 of 74:

Jul 16 19:34 UTC 1998

I like your suggestion in #23, valerie!

response 33 of 74:

Jul 17 19:58 UTC 1998

correct.  kerberos is just a way to do user-auth, and it's os independent,
which means janc is correct.

as for marcus, and his paranoia, i'd be more concerned for solaris than
for intel.  count the number of show-stoping hardware bugs in intel hardware
where the os is free.  count the number of show-stoping hardware bugs where
the os is expensive, support is expensive, and you have to pay for some
patches, and you don't get src without boku bucks.

basically, all your paranoia about solaris and all can be taken care of by
getting OpenBSD or something, and spending a weekend reading the source,
hacking what you need into it over the next week or two, then anything
new that comes out you can patch against yourself, or use vendor
patches, rather than *having* to wait for sun to come out w/ a patch.

sun hasn't realized how to code yet and avoid buffer overflows.  nor
have many people actually, they're not sgi, which by definition,
if you have an account, you have root, but they don't lock down on stuff
like openbsd does.  (Note, i don't even run openbsd, but
they ara paranoid security folks, see http://www.openbsd.org/security.html)

response 35 of 74:

Jul 18 16:46 UTC 1998

correct.  the PC platform is the next logical choice for you to move to.

response 37 of 74:

Jul 19 14:30 UTC 1998

oh yeah, once they find the "holy grail" instruction, sure, the world is
over, but ya know what, instead of being paranoid about that, i'd be more
concerned about some stupid userland program or libc bug that allows
that because of poor bounds-checking.

and with your holy-grail paranoia, when is it going to be found in the
sparc platform?  ultrasparc?  68030, everything.. ack!!!! lets let my
paranoia drive me away from any platform.  that's the bright move.

The other thing you can do (oh no, another not-well-tested platform),
is use a Dec Alpha, those can take the same PCI bus cards as intel
(and the PCI Ultrasparcs), and have better handling of things such as no
video card, which intel boxes can't handle well, and it has a real
rom monitor.  This would actually be a good choice also.  The problem
with intel hardware is the fact that it's designed to have a monitor
and keyboard all the time.  Although you can boot without them, if
your cmos becomes corrupted, you won't boot until someone gets back
there and fixes it.  this can be avoided with headless boxes such as
sparcs, and alphas.
(yes, there are others that do headless well, but i'm not going to go
much further there).