|
Grex > Coop10 > #118: Grex vs. Malthus, round Sixty-Five Thousand, Five Hundred and Thirty-Six |  |
|
| Author |
Message |
| 25 new of 74 responses total. |
i
|
|
response 50 of 74:
| 
Aug 26 00:28 UTC 1999 |
Unfortunately, don, i don't think it's quite that simple....
|
don
|
|
response 51 of 74:
|
Aug 26 01:37 UTC 1999 |
So how is it not simple? STeve said we'd have 65k users, and we only have
27.8k users. Ergo, we don't have to worry about the problem for many years
to come (note that there were only 2 responses in the past year).
|
scott
|
|
response 52 of 74:
|
Aug 26 11:10 UTC 1999 |
We already reached User ID (UID) numbers near enough to 65k. That doesn't
mean 65k users, though.
|
don
|
|
response 53 of 74:
|
Aug 26 14:30 UTC 1999 |
Exactly. When we get to 65k uid, we simply make another gid and rewind the
uids again. Problem quickly solved with very little headache (most times
none).
|
i
|
|
response 54 of 74:
|
Aug 26 23:17 UTC 1999 |
Uh...do you realize, don, that two users with identical uid's but
different gid's present some problems? Our computer system is
just slightly designed around the assumption that a uid # is all
that's needed to securely and uniquely identify who's entering the
command to change a file, who really owns (and is allowed to change)
the file, etc.....
|
pfv
|
|
response 55 of 74:
|
Aug 26 23:20 UTC 1999 |
If you have duplicate uid's, yer in a world of hurt, since
getuid() and getpwname() are based on them.
|
don
|
|
response 56 of 74:
|
Aug 26 23:30 UTC 1999 |
Maybe you two are idiots, maybe I didn't speak clearly enough. What I meant
was that the old uids that are chucked along the way get recycled when we hit
the 65k uid limit. Of course they don't use active uids!
The whole point of my original response was that it's summer of 99, and we're
nowhere near 65k users. Anyone have an idea why it hasn't happened yet?
|
mdw
|
|
response 57 of 74:
|
Aug 27 02:10 UTC 1999 |
It's all the fault of the Chinese.
|
janc
|
|
response 58 of 74:
|
Aug 27 02:33 UTC 1999 |
The number of users didn't continue growing linearly. It hit
equilibrium. Changes in the system or the world may cause that
equilbrium to shift to another equilbrium, but there is no danger in the
forseeable future.
|
pfv
|
|
response 59 of 74:
|
Aug 27 07:51 UTC 1999 |
And the verdict isn't in yet on my being an idiot.
|
toking
|
|
response 60 of 74:
|
Aug 27 13:42 UTC 1999 |
so what about inactive users? Could someone with the same uid go through
and say....scribble all the posts of an old user?
|
pfv
|
|
response 61 of 74:
|
Aug 27 13:54 UTC 1999 |
Hrmm... Good point.. Username match? damn..
|
don
|
|
response 62 of 74:
|
Aug 27 16:37 UTC 1999 |
Sheesh, people! I mean "active" uid's by there being an account assigned to
them! Of course uid's aren't gonna be doubled!
|
toking
|
|
response 63 of 74:
|
Aug 27 16:59 UTC 1999 |
Think about it Don, Someone logs in, creates an account, remains active
long enough to post various and assorted items, then up and disappears.
Three months later their account is reaped. After a while their recycled
uid is picked up by someone else, that person discovers that they can go
through and wipe out a couple items.
Granted, it wouldn't be a huge thing (if it would even work like that, I
don't have the faintes idea, that's why I asked)
So, if I'm misunderstanding what you mean by recycling uids, kindly
explain it differently.
|
scott
|
|
response 64 of 74:
|
Aug 27 18:28 UTC 1999 |
PicoSpan/Backtalk does not use UID. Login IDs, however...
|
pfv
|
|
response 65 of 74:
|
Aug 27 18:53 UTC 1999 |
Oy, geezus.. It never occured to me.. This is Not A Good Thing
(tm), yet.. I don't seehow the hell you can solve it short of
paying attention to uid, name and some sorta' flag indicating
a reaped & reallocated uid/name.
|
don
|
|
response 66 of 74:
|
Aug 28 00:05 UTC 1999 |
Okay, Joe, I get what you're saying. The thing is that usually files
related to the former person gets deleted when they're reaped or otherwize
delete their account. You *may* be right about uids being used for picospan
ownership, but you'l notice that uids are recycled every year or so, and
nothing's gonna happen if a ridiculously old message gets scribbled.
Besides, I'm not *advocating* recycling (although we would be in pretty deep
shit if we didn't recycle and haven't upgraded our 16-bit os), I'm simply
saying that it's already a policy *in place*, so we don't ever have to worry
about the uid counter reaching 65k, we only have to worry about 65k users.
The whole purpose of my first response was to say that a) STeve was wrong
about impending doom, ergo b) We have a hell of a long time to fix this, so
all of the original (read, ridiculously old messages that might as well get
scribbled) arguments against trying to upgrade are now null and void, and we
have to wonder if this 65k problem will ever actually be a problem (it's gonna
be kinda hard for 65k people to want to be on grex when only 85 can be on at
the same time); right before the long-term plan item went dormant again, I
had raised this issue as one of the things we would need to do once we started
upgrading. Then again, we'll probably have to upgrade to a new OS anyway for
multiple reasons, and we can be pretty sure that it'll be 32-bit, which means
we can have 4,294,967,296 users. That is enough for every man, woman, and
child who will be in a position to have access to a computer for at least
a decade.
|
jerome
|
|
response 67 of 74:
|
Aug 28 02:56 UTC 1999 |
I'd have to argure that there is in fact a problem when the uid counter
reaches 65k -- when that happens the gid counter is incremented, and a
new name must be created for this new group. The problem is there are
just so many, many, interesting names to choose from... :-)
Fortunately there's an item in this cf that takes care of that.
|
janc
|
|
response 68 of 74:
|
Aug 28 19:11 UTC 1999 |
Um, Picospan uses both uid and login name. If someone gets reaped, and
you wait about a year until that uid is about to be assigned again, then
you could create a new account using the same login name and getting the
same uid number. Then you could go and censor that user's postings (now
about a year old). Copies would all be put in the censored log, so it
could be fixed if anyone noticed that someone else was censoring these
year-old posts. Basically, I don't think this is a big enough problem
to worry about.
|
davel
|
|
response 69 of 74:
|
Aug 29 01:11 UTC 1999 |
To do that someone would have to watch UIDs being assigned, run newuser at
just the right time, & not collide with anyone else running newuser at the
same time. It's not impossible, but I'm with Jan. We have *real* problems
to worry about.
|
don
|
|
response 70 of 74:
|
Aug 29 22:57 UTC 1999 |
My point exactly.
|
lilmo
|
|
response 71 of 74:
|
Sep 11 00:25 UTC 1999 |
So, is letting the uid counter reach 65k a problem, or not? I'm not clear.
|
janc
|
|
response 72 of 74:
|
Sep 11 04:27 UTC 1999 |
No problem. Only problem is if we let the number of accounts that exist
at any one time exceed 65k. This isn't going to happy any time soon.
|
lilmo
|
|
response 73 of 74:
|
Sep 13 21:23 UTC 1999 |
OK, thanks.
|
davel
|
|
response 74 of 74:
|
Sep 16 10:55 UTC 1999 |
Actually, the problem is deciding what group to use for the new accounts.
|