|
Grex > Coop10 > #118: Grex vs. Malthus, round Sixty-Five Thousand, Five Hundred and Thirty-Six |  |
|
| Author |
Message |
janc
|
|
Grex vs. Malthus, round Sixty-Five Thousand, Five Hundred and Thirty-Six
| 
Jul 9 06:18 UTC 1998 |
It appears that Grex is getting about 175 new accounts created every day.
We reap about 100 a day, so we gain about 75 users a day.
This growth rate is steadily increasing.
We currently have about 23,000 users.
STeve estimates that at this rate will reach about 65,000 users sometime in
the summer of 1999.
This is an interesting milepost because SunOS cannot handle more than
65,536 users. This is because all unix systems internally identify their
users not by their login names but by a number. For example, I am 2386,
and kerouac is 9304 (type !id to find out your account's number). Unix
uses these number to identify who owns files, and who owns each process
running in the system. The catch is that SunOS allocates only two bytes
to store the uid number in any of these places. Two bytes gives you
room for only 65,536 different users. We could have more logins than that,
but people would have to share their files and processes. Not a good idea.
So, if current growth continues, Grex will have to face in interesting
technological problem in about a year. There are solutions to this problems,
but none of them are easy (changing to a different version of Unix is
perhaps the most obvious). This conference probably isn't the place to
discuss that.
My intent with this item is to inform people that this issue is coming up,
and to collect people's reactions and ideas about this.
Should Grex attempt to limit growth? If so, how? Turn off newuser when
the user count exceeds some limit and turn it on again when it dips lower?
Expire accounts faster? Cut out some of our services?
Or should Grex's staff keep trying to keep ahead of growth, boldly going
where no gang of impoverished computer geeks has gone before?
|
| 74 responses total. |
davel
|
|
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!
|
aruba
|
|
response 2 of 74:
|
Jul 9 14:09 UTC 1998 |
Well, I think we could expire accounts sooner than 90 days after last use, if
it comes to that. That would increase the reap rate. But going to a new
version of UNIX seems like a good idea too.
|
jep
|
|
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.
|
cmcgee
|
|
response 4 of 74:
|
Jul 9 15:04 UTC 1998 |
jep, I assume you mean that a new program should be created that
differentiates between someone who creates a new login with newuser, and then
does not come back for 30 days, and someone else who logs in a 2nd time, and
then disappears for more than 30 days.
If we are simply talking about accounts expriring sooner than 90 days, then
I strongly urge that we go no shorter than 60 days. Or else we write a new
program called "dormant" that lets you protect your login ids when you think
you might be away from Grex for more than a month.
|
jep
|
|
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.
|
rcurl
|
|
response 6 of 74:
|
Jul 9 15:48 UTC 1998 |
We need to name this problem. Perhaps the "S64K" Problem?
|
krj
|
|
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.
|
krj
|
|
response 8 of 74:
|
Jul 9 16:37 UTC 1998 |
Also, it would be useful to have some input from the staff: guesstimates
on how much work it would take to convert Grex to an operating system,
or an architecture, in which the 65,000 user limit would not apply.
If a solution to allow Grex to grow over 65,000 users would take
a month or two to implement, then there is probably no need to take
steps to limit growth. If such a solution will take a year -- as the
installation of the new Sun 4/670 did -- then we had better get
serious about limiting growth, because a year is about all the time
we have at the current growth rate.
|
toking
|
|
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.
|
albaugh
|
|
response 10 of 74:
|
Jul 9 17:22 UTC 1998 |
In a certain way, it's good that grex is still running ole SunOS, with the
64K UID limit. That limit will keep grex from getting "overwhelmed" by the
resource drag required to create user home directories, user mail files, etc.
If a user can't create a user account one day, due to no available UIDs, then
grex displays a message saying so, asking the user to try again the next day,
when some UIDs will have become available due to reaping. Then if the user
ain't really interested, he won't bother to come back to create an account
that won't be used and get reaped anyway. If the user *is* interested, he
*will* come back the next day. Or, maybe, grex can create a "new account"
queue, yeah, there's the ticket! :-)
OTOH, grex some day is probably going to want to step up to Solaris for other
reasons than just breaking the 64K UID barrier. Yes, in the past staff types
have said "we can function without Sun support just fine, going to Solaris
would require a complete recompile of all grex software, etc." But sooner
or later...
|
albaugh
|
|
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.
|
atticus
|
|
response 12 of 74:
|
Jul 9 17:47 UTC 1998 |
IMHO lowering the reap period to 60 days is not going to help much.
Maybe we should find out the number of people who are dormant for 2
months and then log in during the third month. My guess is that it won't
be a significantly large number.
If we hit the limit, then we have no option but to block the creation of
new accounts. It will be nice if there is a provision for reserving an
account so that whenever there is a vacancy, the person can be informed
about it.
Is there any way to keep the BackTalk login database separate from
/etc/passwd? Will we be able to give more new accounts through BackTalk
in that case?
|