On Sun, Sep 11, 2005 at 06:01:26PM +0200, Andrea Arcangeli wrote: > On Sun, Sep 11, 2005 at 07:35:02AM +0200, Sven Luther wrote: > > and report data ? If so, you may look into the popularity context package ? > > Does that work for all distro out there? Could you post the url of > the equivalent of a klive.cpushare.com chart so we can compare? (google > pointed me to the package, not to the chart)
Nope,; it works for debian packages. But you can match that to kernels. > > > If you can improve this regexp (which seems the way to go for now) > > > you're very welcome: > > > > > > 'Debian' : > > > re.compile(r'^(\d+)\.(\d+)\.(\d+)(?:-git(\d+)|\.(\d+)|-rc(\d+))?-(\d+)-(?:[3456]86|k7|generic|amd64-k8)') > > > > > > Right now I only added the basics to catch the most frequent archs in > > > klive unknown listing, it's true I can't catch all 12 archs if somebody > > > would be running klive on top of them. > > > > Well, i guess i would not do it like you do ? Why have only a single regext, > > instead of a case switch for example, or better yet two case switches, one > > matching uname -m, and then going for uname -r. > > Why should I go for uname first? I want all archs to fit in the single > uname -r. If you click on 2.6.13 it will show internally all different > archs. Because debian flavours are not unique among all arches, so ... > If you're interested in a single arch just click the filter at the top, > click on x86-64 and you'll see the stats only for x86-64 (see NR going > down etc..). > > Why should I care about uname -m, when I've the filter at the top? Well, if you search for a debian kernel, you can get the uname -r output, and then match it again all the flavours, but it is easier to match them on a per arch basis, especially as it might be that two flavours on two different arches share the same name. Not sure if this is the case right now. > > I still think you are taking the wrong approach here, maybe you shouild > > propose a speacial patch, which each distribution could apply and fill a > > data > > with distribution info, and which would then appear in /proc/version, and > > not > > try to get distributions to polute the version namespace. > > That is a fine solution too. I proposed to "polute the version > namespace" first because that sounded the right thing to do to me, > despite you didn't like it. I will let others comment, i think. > I'd rather keep it separated from /proc/version but that's just an > implementation detail. but it would be the lest obnoxious way of doing this. > > Notice also, that on a debian system, you may find the exact sert of patches > > applied in : /usr/src/patches :) > > Sorry but I'd rather not depend on people not messing /usr/src and more > important I'd rather avoid distro dependent details. All files outside of /usr/local and /home/<user> are per policy to be left to the package manager. Even if some do not follow policy, and unpack linux kernel trees in /usr/src, i can guarantee you that they will not mess with the /usr/src/path subrdir provided by the debian-patch packages. > > > Since the ubuntu kernel seems to be very different from debian kernel, I > > > wonder how I can detect it with uname -r, I guess I can't right now. > > > > Like said, wrong approach. > > Keep in mind this was written for the mainline kernels running on all > sort of userland (where most people normally don't mess with > localversion before compiling), what you see online (i.e. probably > mixing ubuntu and debian) seems the best thing I can do right now. Well, possibly, but i have some doubt of the values of it. Actually, there is a sure way of doing this, you could simply get a database of all the ubuntu or debian kernels out there (they are all archived), and then simply match their md5sum against the md5sum of the installed kernel (which is /boot/vmlinu[zx]-`uname -r`). That way, you have no doubts ay all :) > > Well, i even doubt it will work well for mainline, since people can and will > > modify the version to suite them best, or apply a random set of patches. > > well, as a matter of fact it works pretty well already, count the number > of mainline entries compared to the number of unknown entries. It's > possible somebody patched the kernel, but it doesn't need to be perfect, > and even if they patched the kernel, they're still testing the 2.6.13 > codebase so it's not that bad (just like what Andres said about debian, > that you don't apply many patches, so ideally you could be accounted > like mainline kernels, but for ubuntu this is not the case and currently > I can't even detect the difference between ubuntu and Debian ;). Assume debian by default :) I am not sure, but i guess ubuntu and debian use another set of flavours even, but if you really want to do it right, the most sure way is the md5sum database. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
