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.
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!
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.
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.
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.
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.
We need to name this problem. Perhaps the "S64K" Problem?
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.
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.
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.
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...
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.
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?
I think a combination of the tactics suggested above would be the best
approach. Rewrite the reap program to reap accounts as follows:
* Accounts created by newuser and used on that day, but not used
again for 30 days.
* Accounts less than 90 days old which have not been used for 60
days.
* Any account for which membership dues are not currently paid and
which has not been used for 90 days, except by special arrangement with
staff.
Also, disable newuser at 65,000 users, with a notice saying that
Grex is so popular that it has reached its capacity of 65,000 user
accounts, and would you please try again tomorrow, as old accounts are
deleted every day, making new openings.
re #7: It *would* solve the problem if the reap period was set quickly enough. The question is, how quickly do you have to reap existing unused accounts in order to cause growth of the number of loginids to happen at the desired rate? Currently, we get 175 new user accounts per day and reap 100 accounts. The 100 have been unused for 90 days. If you reap accounts after 75 days, you will be reaping some negligible number of more accounts per day. Set the reap period at 60, and it will be less negligible. Set it at 30, and I'll bet it's pretty substantial. Set it at some level, and it will reap 75 more users per day. The question is, where do we have to set the reap period in order to either stop growth in the number of users, or at least keep it from getting to 65,000? When we find out the answer, we can decide if it's a good idea to change the reap period. I'll bet someone on the staff can determine the answer to that question.
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.
dynamic uid generation
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.
Do you think it would really be fun offering a free e-mail service? Why not just drop that and keep just the full-shell and computer conferencing for "those that really want it"?
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.
Is there some way to try out grex once without creating a user id? I telneted to some conferencing system in Iowa and had to sign up to use it and then never went back. Can people just look at the conferences using Backtalk before they sign up?
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.
People who take out accounts once and then never come back don't really cost grex much in terms of resources. Our current policy is that we may delete such accounts as soon as one month after creation. It was a pretty deliberate decision of mine early on, with m-net, to give people their own unique full-function account immediately upon signing up, rather than setting up any sort of 'guest' account. My reason was that I didn't want to create any barriers towards those people jumping in and responding, because there are already more than enough "natural" barriers in people against doing that sort of thing. If there's a "guest access" provision, then a lot of people who might otherwise become participants will only observe, and never participate, because they'll know how to observe, and they'll just never "get around" to registering. Since this is exactly what backtalk currently offers, it would be interesting to test my hypothesis against real data from backtalk usage. We already offer free e-mail. What I described amounts to making us less "special" and attempting to streamline the service so that it uses less resources.
This response has been erased.
I think that wording would do a good job in newuser. This is a bit techie, but does the file system have room in its structures for longUIDs? We would have to mkfs anyway. But would we have to create custom file system drivers?
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.
If we were going to stick with sunos, we'd have to do a *lot* of hackery. However, Solaris 2.6 does in fact share a "compatible" on-disk filesystem layout with SunOS. The trick they use is they store the long UID & GID at offsets +116, +120 in the on-disk inode, & store 0xffff,0xffff at offsets +4, +6, the old short uid/gid slots. One of the many bits of kernel hackery that we'd have to do to sunos would be to do something about the code in SunOS that *does* use these slots for something else--"i_delaylen" and "i_nextrio". openbsd shares very similar filesystem code with sunos, and may be very nearly compatible. It, too, has support for long uids, but they're stored in +112,+116, and there doesn't seem to be any kernel code to deal with "old" filesystems. Instead, fsck contains logic to copy the old UIDs to the new spots (apparently, without even asking.)
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.
You've a lot more faith in intel than me. Nevertheless, I would agree it's likely grex will be on pci-bus in 1-2 hardware generations, and it *may* be the case that linux a/o bsd will be secure enough at that point. Given the # of really scary solaris bugs I keep hearing about, I certainly don't feel especially comfortable in sticking with that.
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.
What about Kerberos? Would that solve our uid problem?
I like your suggestion in #23, valerie!
I don't think Kerberos will have any effect on the UID problem. The limitation is in the kernel, not in the passwd file.
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)
Though there are sparc versions of OpenBSD, and, according the the developers "can be quite reliable depending on the configuration". However, it does NOT run on Sun 4/600 systems.
correct. the PC platform is the next logical choice for you to move to.
I agree the openbsd folks sound quite promising. My reservations regarding intel based hardware still remain however. Just the other day I saw some sort of *new* linux program that seems intended to cause some sort of hardware exception (and crash the machine). This is where the i386 really shows its weakness: the i386 has an extremely complex architecture, and all of these loose ends show up in the exceptions you need to be able to handle. Just to add insult to injury, the intel documentation is nearly useless in terms of decoding all these exceptions--you basically need to try them all out yourself, and see what happens, and this is the very worst sort of kernel debugging to do, because you're basically dealing with the machine where it gives you the least clues as to what went wrong. I have *never* seen any intel OS that wasn't fairly trivial to crash. I never made a concerted effort either, these were just things I *ran into* doing quite different other stuff. With SCO Xenix (yup, it's *ancient* history) -- I could crash it by doing a "return from interrupt" with the wrong stuff on the stack (reti *is* a legal instruction, even from so-called "user mode" (which doesn't really exist on the intel, but that's a whole 'nuther story.). With freebsd, I could crash it by trying to do a "ptrace" with a word that crossed a page boundary. I don't know about the "reti" case, but I see that the ptrace bug, at least, is fixed in openbsd. For a while, I had mklinux running on a Macintosh (until the hard disk died). This was an early version of mklinux - so it was missing the years and years of experience everyone has had with the intel platform. It was also more stable than any of the intel versions I've used. *This* is the difference a clean architecture makes. I'm still waiting for the vandals to find the "holy grail" bug in the pentium series - the instructions that allow any "user mode" program to read/write "kernel" memory. I'm confident it's only a matter of time.
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).
The thing is, the 68030, sparc, powerpc, etc., platforms *are* different than intel. *All* of these cpu's have much more modern design methodology in them. The intel design methodology basically dates from about 1960 -- the chip architecture is pretty obviously pre-GPR, and even the IBM 7094 has a more regular instruction set. It's worse than that even -- until the pentium II, intel processors weren't microcoded, but used "random logic" to implement the instruction set. I've heard that the famous intel FP bug wasn't an actual logic bug, but was in fact an analog layout glitch. There are also PCI bus powerpc machines, and PCI bus sparc machines. (In fact, I have one of each in my office now...) That's why I said it was a pretty safe bet that grex would end up on PCI bus at some point.
It's worth noting that with the 0xf00f bug, most the the PC Unix systems had patches out to trap the instruction within a few days, before people had time to do major damage with it.
With the FP bug, intel *sat* on the bug for a year. After the bug was popularized, intel was pretty recalcitrant about replacing the affected CPU's. There is no patch for the FP bug.
I like the way marcus brings up when you're doing scientific divison in this item. Yes, intel replaced those chips only because of a class-action suit against them. I'm sure of that. But what percentage of the public was really affected by this bug? Less than .01%, those were the folks that should have really been getting the swapped cpus, not kids playing doom. And what CPU number was the pentium for intel? the FP+0xf00f bugs are the only ones i know of. Want me to start listing the bugs that have to be coded around in the sparc cpus? I can go dig up a list, we can really start comparing, marcus. Maybe we could use one of those as your "holy grail" bugs in the right way. It's more likeley to have a bug not be found in the sparc CPUs because of lack of exposure. We can't really say that about the intel ones, I think they get a *little* more exposure than the others. How many people are using your powerpc, 680x0 cpus in direct ratio to intel x86 based cpus? Not many in comparision.
It appears that netbsd will support the 4/600; I guess openbsd doesn't. I have not seen any convincing argument of why anyone would prefer openbsd over netbsd (openbsd claims to care more about security, but I haven't seen any solid evidence that in practice openbsd is more secure than netbsd). (It has certainly been my experience that netbsd is more immune to cracker attacks than debian.) As far as I can tell, the people working on netbsd are probably more competent in general than the openbsd people.
Let me just say that I have found out FreeBSD handles a LOT better than Linux. Linux is fine for a home box where you won't have a lot of traffic, it's what I use on my home PC. But, Jared can tell you, when he switched nether from Linux to FreeBSD (without changing the computer itself, he only changed OS) it made a BIG difference. It could handle tons of users online at once just fine. Also, I've heard that anything newer than Red Hat v4.2 isn't good at all-- and I could get practically NOTHING to compile under RedHat 5.1 ..
(5.1 has a hacked pre-release version of the 2.0.34 kernel. Get a real version and everything compiles fine.)
Well, that explains how RH got the 2.0.34 kernel onto their CD's so quickly after it was released. By the time I got my CD though 2.0.35 was out, and I tried using that but didn't really fool with compiling stuff under it. I like Slackware better.
Has a non-paying user I would like to express that I would like to still use this system to email and bbsing Because right now I have very little money. I like to go on party because talking to people on m-net and grex is mighty fun I don't think that tell people that you need to pay to email is a good idea 60 days is good idea, after then reap them It's to bad if they don't relogin again after 60 days 90 days is to long.
I like the concept of 90 days. I could be gone for a summer (e.i. I am talking about the students) and they could come back still with their account.
90 days is good for establishd members. I sometimes am unable to get to a 'Net-capable computer for nearly that long.
IT IS NOW THE END OF SUMMER '99. STeve was wrong; we are nowhere near 65k users... in fact, our latest new user (Johnny (hype404) Tron), is the 27636th user according to /etc/passwd (now the staff knows why I've been dicking around in there, reading it multiple times). Grex doesn't seem to be growing too much, definately not 175 new users a day. I'd guess we have another 5 years or so until we get to the limit, which gives people lotsa time to work on it. Grex will probably have a completely new system by then anyway. C'est la vie.
Unfortunately, don, i don't think it's quite that simple....
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).
We already reached User ID (UID) numbers near enough to 65k. That doesn't mean 65k users, though.
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).
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.....
If you have duplicate uid's, yer in a world of hurt, since
getuid() and getpwname() are based on them.
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?
It's all the fault of the Chinese.
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.
And the verdict isn't in yet on my being an idiot.
so what about inactive users? Could someone with the same uid go through and say....scribble all the posts of an old user?
Hrmm... Good point.. Username match? damn..
Sheesh, people! I mean "active" uid's by there being an account assigned to them! Of course uid's aren't gonna be doubled!
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.
PicoSpan/Backtalk does not use UID. Login IDs, however...
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.
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.
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.
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.
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.
My point exactly.
So, is letting the uid counter reach 65k a problem, or not? I'm not clear.
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.
OK, thanks.
Actually, the problem is deciding what group to use for the new accounts.
You have several choices: