<rburton>
khem: it was server-focused constantly updating ia-specific
<rburton>
(also took some liberties with ethics to win benchmarks)
<paulg>
"...liberties with ethics..." ha ha, priceless.
* paulg
rotfl
prabhakalad has quit [Quit: Konversation terminated!]
<RP>
rburton: that is a good way to put it
<RP>
I am sad that we don't have some of the innovation that was able to happen from Intel :/
goliath has quit [Quit: SIGSEGV]
jmiehe has joined #yocto
druppy has joined #yocto
<khem>
it got lot of coverage on phoronix for some reason, so I kept reading some news about it in past, I remember they had cherry picked some of OEs glibc patches
thirdapocalypse has joined #yocto
<thirdapocalypse>
hello i'm having some trouble using cgroups in a yocto build. would anyone be able to help out with it?
<khem>
ask away if someone have answer they will respond
<thirdapocalypse>
great. i'm trying to enable cpuset but /proc/cgroups only shows cpu as an available subsystem -- not sure if i've configured something wrong or if i should be looking somewhere else
<khem>
thirdapocalypse: kernel is built with CONFIG_CPUSETS=y I suppose ?
<khem>
also try mount | grep cgroup
<khem>
if you see /sys/fs/cgroup then you have it configured I believe
<paulg>
I would think most common distros since the past 5-ish years would have it mounted by default...
<paulg>
Did gcc pull up in a white unmarked van, jump out and abduct your source code?
<khem>
RP: they are considering PR+issues and commits so this list is a bit flawed
<khem>
RP: there still are 379 PRs+Issues for YP on github I am surprised
<RP>
khem: I know, but this is how they're comparing projects :(
<khem>
give them API access into bugzilla and groups.io :)
<RP>
khem: I opened a ticket about groups.io
<RP>
they do already scrape bugzilla (since the kernel has that and they therefore are interested)
<khem>
ah the default sort seems to be ordered by number of commit authors
<khem>
sheet chart is interesting, YP is well below the curve
<khem>
paulg: GCC hardly segfaults on my code these days, because I dont use it as much
<paulg>
I don't think I've investigated a GCC internal error since gcc-2.x -- and yeah the ICE joke probably lands flat with an international audience.
<JPEW>
How is "rank" calculated?
<JPEW>
Also... is it "issues closed" or something?
kbo has quit [Ping timeout: 272 seconds]
<RP>
JPEW: the code is in that git repo...
<JPEW>
Oh, it's just "size" (sqrt(# of authors))
<JPEW>
I mean, if you want to spin that, we only generate 1 bug for every 21 commits, so that's pretty good
<RP>
JPEW: I like that :D
<JPEW>
It also "feels" about right to me anyway
<JPEW>
That is actually a used metric; you can get a rough feel for how well tested a large change set is by tracking how many bugs the authors found and comparing it to the average bug rate; if it's too low it's a sign it might not have been tested well
<JPEW>
But it can also be horribly abused :)
<RP>
I suspect that works as long as the people doing the work don't know how you're measuring it :)
<JPEW>
Right
<RP>
That kind of system has "challenge" written all over it to me :)
<RP>
JPEW: funnily enough I was wondering if anything still used multiprocessingpool the other day. I didn't want to get distracted though!