On Aug 10, 2008, at 7:30 AM, Ceri Davies wrote: > It could be a matter of education, or the project could choose to make > the problem go away and have an advantage over the competition. I'm > not > sure why we wouldn't choose the latter. I'm hoping that the Linux > familiarity project doesn't extend to bug compatibility for its own > sake.
Personally I don't really care that much, it'll work either way[1]. I'm just curious to hear what is the "problem" for the case where the uid owns either no files or files with content which isn't interesting to share. Proof by assertion isn't terribly convincing so I remain curious. You describe this as a bug in Linux (Debian, really; I haven't looked how the other distros handle it) but I'm not aware of a movement to change it (could well be I don't follow the right lists though) so doesn't seem to be a problem. If someone is copying fooserver.pid files to other hosts, they have problems beyond just the uid owning the file so that's not a convincing use case to me ;-) I took a quick look at one of my Debian servers and out of the 14 daemon uids added by package installations over time, only 4 had a filesystem presence containing real data, files which I could envision copying to a different host. So those 4 are good candidates for a theoretical <100 pre-registered uid. The other 10 (71%) had either no files at all or files of interest only on localhost (like .pid files). No reason to use up fixed uid slots (or go the extra work of a registration process) for any of those. Letting the package system assign them any available uid is adequate, less work and less process/coordination. [1] But a fixed system does limit OpenSolaris to never being able to have more than N (N=100|N=1000) packages among all available (current & future) repositories which require their own uid. If N=1000 that's probably not an issue in practice; still, I'm not a fan of arbitrary ceilings which could easily be engineered away instead of saying "it's ok, we'll never hit it" (how many times in the history of software have we heard that one!) With dynamic assignment the ceiling is having N of those packages actually installed on one host, which is an orders of magnitude less likely scenario.
