|
|
| Author |
Message |
| 20 new of 44 responses total. |
rcurl
|
|
response 25 of 44:
| 
Dec 11 05:06 UTC 1998 |
I guess I don't know enough about OS's - so I'll ask why there can't be
an A series and a B series....
|
krj
|
|
response 26 of 44:
|
Dec 11 05:24 UTC 1998 |
That UID number is used to associate things in the system, such as
files, with a specific user.
|
steve
|
|
response 27 of 44:
|
Dec 11 12:08 UTC 1998 |
Right. A uid (user id) is the essential identifier in the unix
operating system to differenciate each user.
And the B series of SunOS is called Solaris, which has long
integer uid's, capable of handling either two or four billion
users.
|
davel
|
|
response 28 of 44:
|
Dec 11 12:25 UTC 1998 |
And eventually there'll be a system that has to worry about using all *those*
up. I kind of hope it'll be Grex. 8-{)]
As far as STeve's statistics go: do those include as having logged in people
who post to conferences via Backtalk, even if they don't actually log in?
|
steve
|
|
response 29 of 44:
|
Dec 11 12:59 UTC 1998 |
Ah... do people who log in get updated in the lastlog file? Thats
what I base my stats on. Hmm. I should know the answer to that, but
I don't.
|
remmers
|
|
response 30 of 44:
|
Dec 11 13:16 UTC 1998 |
Hm, not quite sure what I was thinking when I posted #18, as I knew
about the new groups and the UID recycling. Memory must be getting
faulty in my advancing middle age. (Grex must be one of the only Unix
systems in the world that has to resort to that kind of stuff.)
|
aruba
|
|
response 31 of 44:
|
Dec 11 15:42 UTC 1998 |
Rane: The reason UIDs can't be bigger than 65535 = 2^16-1 is because that is
the largest number that can be stored in 16 bits = 2 bytes. The system, and
a lot of programs that run on it, only reserve two bytes for UIDs, so if the
UIDS got bigger than that (or if we tried to append a letter, and distinguish
between 23456A and 23456B) they wouldn't fit. Does that make sense?
|
remmers
|
|
response 32 of 44:
|
Dec 11 18:39 UTC 1998 |
(It's kinda like the Y2K problem...)
|
robh
|
|
response 33 of 44:
|
Dec 11 18:50 UTC 1998 |
Except that we know exactly when that problem is gonna hit us. >8)
|
richard
|
|
response 34 of 44:
|
Dec 11 22:51 UTC 1998 |
would it be feasible to change the reaping prog. so inactive accounts
are reaped after two months instead of three?
this would solve this right?
|
steve
|
|
response 35 of 44:
|
Dec 11 23:03 UTC 1998 |
No, it wouldn't.
It would free up a chunk of users upfront, thats true. but over time
we'd see the passwd file grow again.
If there are more new people than reaped ones, we grow in size. The
frequency of reaping would change things at the beginning, but if people
are going to look at the system and decide they don't like it, then it
doesn't matter if we reap them at 60 or 90 days. They're still going to
go. At the very end when we had like 63,000 users faster reaping would
matter a little, but only for a small portion of uid space.
I think we should keep the 90 day rule; it's saved many accounts in
the past, when people have become busy in their lives and haven't been
able to get here for a while.
|
rcurl
|
|
response 36 of 44:
|
Dec 12 00:25 UTC 1998 |
I was thinking that one could program a larger user database, but I
can see it getting very slow, with all the lookups that occur. Isn't
the limit really in being able to do it in the CPU? Could id's be
swapped in and out of the OS, since a lot of people aren't on much?
|
scott
|
|
response 37 of 44:
|
Dec 12 00:33 UTC 1998 |
It would be like swapping engines in your car on a more-than-daily basis.
|
rcurl
|
|
response 38 of 44:
|
Dec 12 00:38 UTC 1998 |
Would it really? What fraction of all the uids are essentially idle?
Just hogging OS space? If they were swapped out and then swapped back
in at the users time expense when called upon, there could be more uids.
The questions would seem to be balancing expanding the possible number
of uids at the cost of slight speed decrement - and exactly where that
balance occurs.
|
scott
|
|
response 39 of 44:
|
Dec 12 00:40 UTC 1998 |
The programming involved would dwarf the effort to move to an OS with more
UIDs.
|
aruba
|
|
response 40 of 44:
|
Dec 12 03:08 UTC 1998 |
Re #38: You would still have a big problem, Rane, if two users shared the
same UID. They could delete each other's files, and what happens if they're
both on at the same time?
|
rcurl
|
|
response 41 of 44:
|
Dec 12 03:28 UTC 1998 |
Oh...they couldn't be told apart in the OS...down in flames and back to
the drawing board... 8^{
|
scg
|
|
response 42 of 44:
|
Dec 12 03:42 UTC 1998 |
Right. There are a number of things that UIDs are used for. One of those
is that every file on the system has the owner's UID associated with it. For
example, when you do an ls -l and see the list of files with their owners,
ls is actually reading off the disk a list of files and UIDs, and then looking
up the UIDs to see which user is associated with them before displaying the
listing.
|
mdw
|
|
response 43 of 44:
|
Dec 12 04:22 UTC 1998 |
It would be *much* easier to switch OS's than to try to engineer a
32->16 bit UID mapping scheme. It would be possible, and I spent a lot
of time thinking about this for UM, but it's really not worth it for
grex.
|
krj
|
|
response 44 of 44:
|
Dec 12 04:54 UTC 1998 |
Rane's resp:38 leads me back to thoughts of the 1970's Control Data
NOS operating system, as modified by MSU... we do NOT want to get
into operating system customization any more than we need too...
(ah, nostalgia...)
|