Election Free-for-All

Dec 7 14:31 UTC 1998

Question #1:  It's quite possible that Grex will hit its operating 
system limit of 65,536 users during your term of service on the 
Board: if not in your original two year term, then in a re-election
term.  How do you propose this situation be dealt with? 
 
(There has been a public discussion of this in item:7, so I'll ask
that non-candidates limit themselves here to refining the question
and probing the answers from the candidates.)

response 2 of 44:

Dec 7 19:10 UTC 1998

Sorry Rane, but you're out of order. You're not a candidate, so
you're supposed to refine the question or probe for answers from
the candidates. You're not supposed to *give* the answer.  :)

Although I partly agree with what Rane is saying, I think there's
a hidden policy issue buried in Ken's question that merits the
users' attention. Namely, how big do we want to let Grex grow?
There are two approaches to dealing with the "65,536 barrier" --

(1) living with the limit and adopting measures to restrict the
total number of users (e.g. by a shorter account expiration
period), or 

(2) making technical changes in the system that would
accomodate a larger number of users (e.g. two grex machines
networked with shared disk, a different OS platform that
supports a larger user limit, etc). 

Once the users have made a choice between (1) and (2), the
staff can advise on how best to achieve the selected goal, and
the board can look at financing issues.

I'm of two minds about the choice.  I'd like to see Grex
continue to grow, but we have to realize that there are practical
limits in terms of resources -- money, staff time. And there's
the issue of the kind of community we're trying to create. So
at the risk of sounding wishy-washy, I'll say that we'll cross
the bridge when we come to it, and if I'm on the Board, I'll
listen real closely to what the users say.

response 4 of 44:

Dec 8 05:08 UTC 1998

   Given that we have space for future uid's, we do have some
amount of time to work on this.

   The more I think on this, the more I think that a Grex with
65,000 users is likely the largest Grex we can have, given our
one resource which isn't getting cheaper over time--staff.  If
we take it for granted that everything else is going to become
cheaper over time, it may well be the case that we decide that
such a size is optimal, and we teach newuser about "rationing"
accounts: as reaping is done, we have a certain amount of free
accounts ready to reuse.  Newuser then allocates a number for
local use, and another number of general net use.

   This would always guarantee that we're at a known point in
size, and we'd never go beyond it.  There is a certain comfort
in that, knowing that we couldn't then get 15.4 million accounts
here. ;-)

   That is likely the simplest strategy.  Others include

 - Moving to a new operating system, one that has whats called
   'long uids', such that essentially any number of accounts
   could exist.

 - Moving to the successor of SunOS, Solaris, which is a little
   easier than the above option, and would give us the ability
   to have infinate accounts.

 - Hack at the kernel and teach it about long uids.  Not for the
   faint of heart, not easy and probably not worth it.

However, we might not have to worry about this.  Let me explain
why.  Even two years ago the net was just enough different that
what Grex offered then was a little more 'valuable' than what it
is today.

There is a part of me that wonders if we might see two curves,
one going upwards and one downwards, eventually meeting.  Yes,
accounts are finite but I think it may be the case that the
number of new accounts might ramp downwards as there are
increasing other sources for things like email.  Already, we've
seen a proliferation of email services that are web based.  As
more people have even rudimentary net access, I wonder if Grex
will be viewed as obsolete, in terms of its email services, etc.

The flip side of course is that as more people find out about
us, we'll be even more widly popular, but that isn't quite as
sure a feel to me as it once was.

response 6 of 44:

Dec 8 12:08 UTC 1998

   Only if the spinoffs were to be completely seperate machines,
with their own uid-space.
   But even then, wouldn't people start taking out accounts on all
the different machines?
   I don't think that buys us much.

response 8 of 44:

Dec 8 21:04 UTC 1998

I don't know of any independent "Grex clones" per se, despite the fact 
that Grex has been around for 7 years and visible on the internet for 
most of those years. Maybe Chinet counts, at least to an extent. So 
whether many such things will ever sprout up is a big question mark.

It *is* true that online discussion forums are a big deal these days, 
as are mailing lists and other forms of computer-mediated communication. 
Prominent web sites often include forums as an adjunct. Maybe not 
exactly the Grex model - seldom member-governed, for example - but they 
do provide a format with conference/item/response structure. The 
explosive growth of this form of communication doesn't seem to be 
relieving the pressure on Grex one bit.

response 10 of 44:

Dec 8 22:42 UTC 1998

Hehe!  New User doesn't work on nether.net,  and I think the owner has other
plans for it.

response 12 of 44:

Dec 9 12:18 UTC 1998

Re way back there: I don't think we can decide which approach (limit number
of users, migrate to something supporting long UIDs) to take quite so much
as an abstract issue.  What would it take to limit the number of users?  If
it comes down to (say) reaping new accounts daily or hourly, we shouldn't do
it - just as an example.

response 14 of 44:

Dec 10 04:07 UTC 1998

Just being picky, as usual, I'm afraid.  Someone had suggested that
we decide whether limiting # of users or migrating (or other technological
fix, I think) is the policy we want to follow - and *then* discuss how to
implement the policy chosen.  (Maybe I have it wrong; I'm not going back
to find the posting.)  What I meant to say was this: we can't fully
judge those two policies without considering how to implement them, as
the implementations will have costs to Grex.  If we decide to limit
the number of users, the question of what we'll have to do (shut off
newuser?  reap accounts *very* frequently & quickly?) and how fast such
drastic measures might be needed (if they are) has a lot to do with
whether it's an attractive alternative.  How easy a technical fix to UID
numbers would be, ditto for *that* alternative.

Probably still not very clear.  Sorry.

response 16 of 44:

Dec 10 12:13 UTC 1998

Re resp:14 - I think I was the person who said something resembling
that. Didn't mean to imply that technical issues wouldn't play a role in
the discussions leading to a decision. My point was that there are
larger issues that everybody would need to be involved with, not *just*
the staff.

response 18 of 44:

Dec 10 18:03 UTC 1998

There would be tricky technical problems with simply re-using UID's
of canceled accounts, because programs use UID's to keep track of
who did what. For example, Picospan uses the UID to determine who
posted a response. If user 'foo' posts a response, then has his
account reaped, and user 'bar' runs newuser and happens to be
assigned the same UID, then bar would be able to expurgate foo's
response.

So we'll have problems when we hit the maximum UID *number*,
which will probably happen long before we're anywhere close
to the maximum volume of users.

The max UID number on our platform is 65535. The last account
created has UID 64011. Hmmm...

response 20 of 44:

Dec 10 19:12 UTC 1998

   Yes, we do reuse UID's, and have for quite some time, now.  We're on our
third "pass" through the passwd file.  What we've done when its time to
"rewind" the uid's is to create a new group for people in that next pass.
Originally, everyone was in group "people".  Then we created "people" and
then "beings".  We'll have to create another one soon, like next week and
then we're off on our forth pass through the passwd file.  When newuser is
run, it looks for uid "n" (whatever that is), and sees if it exists already
under an older group.  If it does, then it increments the number and tries
again.  Once a free number is found, that newuser gets that uid.

   What will happen, assuming continual growth, is that after we've gond
through the passwd file like 8 times or something, the "holes" in available
UID space will become smaller and smaller.  At that point, once we have 0
free uids (but in many different groups) we'll have to ration new user
accounts in some manner.

response 22 of 44:

Dec 10 20:17 UTC 1998

I didn't log in for around a year, but my loginid was preserved when I 
came back.  I had to ask the staff for my password.  I'm grateful that 
my account was kept.  Nevertheless, if there's a conflict between 
inactive people like I was, and new people coming in, I think it'd be a 
bad mistake to give preference to the inactive ones.  If a better 
solution doesn't become implemented, I see at least a 5,000 UID reapable 
buffer, and maybe 11,000 (room for 20-45% more additional growth).

response 24 of 44:

Dec 10 21:21 UTC 1998

   The design of the operating system.  On SunOS (and nearly all other
UNIX's from that era) use a 16 bit unsigned integer, hence the limit
of 65535.

   Some of the really old logins have been kept in the hopes that their
owners would come back. ;-)