Sat Mar 21 21:49:51 CET 2009
A comment
Because I'm unable to just leave a comment on since I don't have an account on any of the third-party services
that are needed to leave a comment. Which is somehow very funny, but also extremely braindamaged.
Now the idea of doing the benchmarks himself wasn't that bad, but peper is using different configuration files for portage and paludis. So the comparison is quite ... uhm ... difficult.
What I do wonder now is why paludis would be slower when reading one set of config files. I don't want to commit to one package manager, so I can't just use an incompatible config, and I'm not going to work with three different sets of config files.
Also I do wonder how his portage timings are off by a factor of five or so from mine ... too many variables and too much unexpected behaviour happening there to get any useful data out of it. It looks like you must not use portage and paludis on the same system if you want any reasonable things happening.
Next benchmarks I'll try to get done when libportage has enough features to be used ...
Now the idea of doing the benchmarks himself wasn't that bad, but peper is using different configuration files for portage and paludis. So the comparison is quite ... uhm ... difficult.
What I do wonder now is why paludis would be slower when reading one set of config files. I don't want to commit to one package manager, so I can't just use an incompatible config, and I'm not going to work with three different sets of config files.
Also I do wonder how his portage timings are off by a factor of five or so from mine ... too many variables and too much unexpected behaviour happening there to get any useful data out of it. It looks like you must not use portage and paludis on the same system if you want any reasonable things happening.
Next benchmarks I'll try to get done when libportage has enough features to be used ...
Sat Mar 21 16:43:58 CET 2009
Benchmurks, again
So today I was a bit unmotivated again and though "Hmm, how do I waste an hour or two of time?"
And as usual some silly benchmarks happened. After all I need to know what my quadcore can do, right?
Since I had a spare chroot lying around I just took that and did the usual incantations:
How does one manage to be slower than portage by a factor of 10 out of the box?
And as usual some silly benchmarks happened. After all I need to know what my quadcore can do, right?
Since I had a spare chroot lying around I just took that and did the usual incantations:
# time pmerge -uDp sys-apps/portage * Resolving... [ebuild R ] sys-apps/portage-2.1.6.7 real 0m8.815s user 0m5.992s sys 0m2.264s # time emerge -uDp sys-apps/portage Calculating dependencies... done! [ebuild R ] sys-apps/portage-2.1.6.7 real 0m28.627s user 0m15.801s sys 0m9.689s # time paludis -ip portage: ( two million lines of random output scrolling by ) real 0m58.921s user 0m36.186s sys 0m19.345sHmm, that is ... unexpected. Let's try something else:
# time paludis -ip kde real 2m28.890s user 1m42.810s sys 0m38.902sOuch. Uhm.
# time emerge -up kde real 0m2.937s user 0m2.276s sys 0m0.068sOh, let's add -N -D to the options:
# time emerge -uNDp kde real 0m2.927s user 0m2.764s sys 0m0.120sAnd pauldis seems to check the distfiles too, so --fetchonly:
# time emerge -up --fetchonly kde real 0m13.603s user 0m10.305s sys 0m0.808sJust for reference:
# time pmerge -up kde real 0m1.270s user 0m1.180s sys 0m0.080s # time pmerge -uDp --fetchonly kde real 0m6.460s user 0m5.996s sys 0m0.188sSo ... uhm ... wow.
How does one manage to be slower than portage by a factor of 10 out of the box?
Sat Mar 21 10:11:11 CET 2009
Leaving, again, for real this time, honestly?
After a nice round of trolling on IRC in #gentoo-council the exherbo brigade decided to leave:
And just to make a point (again) Kloeri decided to bloooooog.
Now the funny bit ...
He retired from Gentoo in 2007. Quote: "I think it's finally time for me and Gentoo to go our seperate ways."
Then he might or might not have quit posting to the gentoo-dev@ mailinglist 3 months later.
Decided to quit using Gentoo another two and a half months later ...
... just to get banned from the gentoo forums half a year later
Then there's the announcement of the gentoo fork that isn't a fork
And finally, close to two years after deciding to leave the announcement to really honestly seriously leaving all gentoo IRC channels
It is really amusing to see people taking years to really really honestly leave that retarded stupid distro that is so badly mismanaged.
Or maybe it is actually quite awesome? How else do you explain people publically leaving, just to return quietly after some time, always sticking around and still claiming that it's all bad?
Ah well. Maybe one day they'll actually do what they say and just leave us be so we can do what we want without all the interference. It can only take a few more years ...
kloeri (n=kloeri@exherbo/developer/kloeri) has left #gentoo-council ("this is too fucking stupid for me")
spb (i=stephen@freenode/developer/exherbo.spb) has left #gentoo-council ("ditto")
ahf (i=ahf@irssi/staff/ahf) has left #gentoo-council ("bonsaikitten is an idiot..")
I bet they are back next week, but in the meantime they get to feel really good about showing us their resolve.
And just to make a point (again) Kloeri decided to bloooooog.
Now the funny bit ...
He retired from Gentoo in 2007. Quote: "I think it's finally time for me and Gentoo to go our seperate ways."
Then he might or might not have quit posting to the gentoo-dev@ mailinglist 3 months later.
Decided to quit using Gentoo another two and a half months later ...
... just to get banned from the gentoo forums half a year later
Then there's the announcement of the gentoo fork that isn't a fork
And finally, close to two years after deciding to leave the announcement to really honestly seriously leaving all gentoo IRC channels
It is really amusing to see people taking years to really really honestly leave that retarded stupid distro that is so badly mismanaged.
Or maybe it is actually quite awesome? How else do you explain people publically leaving, just to return quietly after some time, always sticking around and still claiming that it's all bad?
Ah well. Maybe one day they'll actually do what they say and just leave us be so we can do what we want without all the interference. It can only take a few more years ...
Sun Mar 8 16:27:23 CET 2009
A look back on bugday
Depending on your timezone and relative inertial frame this months' stealth bugday is more or less over. Due to various reasons noone seems to have
thought of sending a notification email to the relevant mailinglists and such, but still some users and quite a few devs managed to be present in
#gentoo-bugs to coordinate the assault on the open bugs.
Through spontaneous reorganization the EAPI2 battalion, lead by Betelgeuse, decided to exterminate as many built_with_use checks, replacing them with much more shiny use-deps. That means for users that instead of failing randomly after 3h of compiling with a message like "Rebuild package bar with useflag foo" portage will warn during dependency calculation and thus make it a lot easier to handle.
The process is not done yet, but the decimation has gone quite well so far - decimation might even be a precise description as not all categories are done yet.
Some overly motivated users started looking at ooooold bugs - the kind you filed back in '96 or so and which everyone seems to have forgotten. Closing those might look pointless, but it reduces the amount of open bugs and thus makes searching a lot easier. I spent quite a bit of time breaking things, but that is quite normal when you're finally unmasking packages that have been masked since May 2007 or so. And somehow there have been about as many new bugs as there were closed bugs, so at times it feels really futile.
In the last days I did notice a higher number of package bump request bugs than usual, so maybe some people have read my blog (putting the number of readers near 12) and are doing what I suggested. If any of you read this: Please get up from your chair, turn around three times clockwise and sit down again. Thanks.
Even if unannounced I think this bugday was quite successful. And maybe we'll all have time next month to try again, this time with mailing list notification and all those nice things. Or maybe we just try to make every day a bugday and try to get as much as possible fixed?
In the end you, the users, benefit from our efforts, so maybe you want to get involved and invest some of your time to keep gentoo the bestest distributionism in da hood. Right?
Through spontaneous reorganization the EAPI2 battalion, lead by Betelgeuse, decided to exterminate as many built_with_use checks, replacing them with much more shiny use-deps. That means for users that instead of failing randomly after 3h of compiling with a message like "Rebuild package bar with useflag foo" portage will warn during dependency calculation and thus make it a lot easier to handle.
The process is not done yet, but the decimation has gone quite well so far - decimation might even be a precise description as not all categories are done yet.
Some overly motivated users started looking at ooooold bugs - the kind you filed back in '96 or so and which everyone seems to have forgotten. Closing those might look pointless, but it reduces the amount of open bugs and thus makes searching a lot easier. I spent quite a bit of time breaking things, but that is quite normal when you're finally unmasking packages that have been masked since May 2007 or so. And somehow there have been about as many new bugs as there were closed bugs, so at times it feels really futile.
In the last days I did notice a higher number of package bump request bugs than usual, so maybe some people have read my blog (putting the number of readers near 12) and are doing what I suggested. If any of you read this: Please get up from your chair, turn around three times clockwise and sit down again. Thanks.
Even if unannounced I think this bugday was quite successful. And maybe we'll all have time next month to try again, this time with mailing list notification and all those nice things. Or maybe we just try to make every day a bugday and try to get as much as possible fixed?
In the end you, the users, benefit from our efforts, so maybe you want to get involved and invest some of your time to keep gentoo the bestest distributionism in da hood. Right?
Sat Mar 7 10:46:38 CET 2009
What the *, firefox?
Just found this gem in the firefox default config:
Another domain to add to the blacklist, and what kind of rootkit injection service is that?
I have not enough trust in Google to let my browser run any code they provide. Bad Mozilla Foundation!
On a sidenote, why on earth does the debian installer install popcon even if you tell it that no, you really absolutely positively do NOT want to be part of their datamining action?
Looks like I need a larger cluebat and more paranoia ...
user_pref("urlclassifier.keyupdatetime.https://sb-ssl.google.com/safebrowsing/newkey", 1237004239);
Another domain to add to the blacklist, and what kind of rootkit injection service is that?
I have not enough trust in Google to let my browser run any code they provide. Bad Mozilla Foundation!
On a sidenote, why on earth does the debian installer install popcon even if you tell it that no, you really absolutely positively do NOT want to be part of their datamining action?
Looks like I need a larger cluebat and more paranoia ...
Fri Mar 6 10:24:51 CET 2009
Caturday iz bugday!
In A.D. 2101, bug was beginning.
User: What happen ?
Bugwrangler: Somebody set up us the bug.
Portage: We get signal 11.
User: What !
Portage: Main screen turn on.
User: It's You !!
CATS: How are you gentlemen !!
CATS: All your bug are belong to us.
CATS: You are on the way to compile failure.
Captain: What you say !!
CATS: You have no chance to survive make your time.
CATS: HA HA HA HA
User: Take off every '-funroll-loops' !!
User: You know what you doing.
User: Bump 'zig'.
Portage: For great compile.
Almost is Caturday. Every grate Caturday be bugday, LOL. U can halp 2, n00b.
U fix boog and ceiling cat be smiling on you. Not fixing bug, ceiling cat maek u very sad.
#gentoo-bugs be it, on irc.freenode.net, where we r haeving teh fun.
User: What happen ?
Bugwrangler: Somebody set up us the bug.
Portage: We get signal 11.
User: What !
Portage: Main screen turn on.
User: It's You !!
CATS: How are you gentlemen !!
CATS: All your bug are belong to us.
CATS: You are on the way to compile failure.
Captain: What you say !!
CATS: You have no chance to survive make your time.
CATS: HA HA HA HA
User: Take off every '-funroll-loops' !!
User: You know what you doing.
User: Bump 'zig'.
Portage: For great compile.
Almost is Caturday. Every grate Caturday be bugday, LOL. U can halp 2, n00b.
U fix boog and ceiling cat be smiling on you. Not fixing bug, ceiling cat maek u very sad.
#gentoo-bugs be it, on irc.freenode.net, where we r haeving teh fun.
Wed Mar 4 16:09:14 CET 2009
Error handling. It's not optional.
Last login: Wed Mar 4 10:38:19 2009 Linux DUH-1 2.6.18-6-486 #1 Sat Dec 27 08:57:46 UTC 2008 i686 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. DUH-1:~# /etc/init.d/puppetmaster start Starting puppet configuration management tool master serverCould not start WEBrick: Address already in use - bind(2) failed! DUH-1:~# /etc/init.d/puppetmaster start Starting puppet configuration management tool master serverCould not start WEBrick: Address already in use - bind(2) failed! DUH-1:~# /etc/init.d/puppetmaster stop Stopping puppet configuration management tool master server. DUH-1:~# /etc/init.d/puppetmaster start Starting puppet configuration management tool master server.
Well DUH. Reminds me of that great movie Idiocracy ... somehow. Mwuehehehe. Heh.
(Hint: Checking if you are already started is not purely optional ...)
Tue Mar 3 22:51:32 CET 2009
Leadership and Vision
If you've been reading Planet Gentoo (Universe) or Planet
Larry you might be familiar with all the arguments about how Gentoo needs to be managed better / differently / by ciaranm / like Fedora.
I say that's silly. It's not so much a management issue. I mean, I really enjoy reading dberkholz's ramblings. But I think that's missing the point. We all want to do new shiny stuff. Everyone wants to be boss. But what use is the most brilliant battle plan if there are no grunts willing to pick up a rifle and die for their Vaterland?
If you look at it from that perspective it's not about making the best plan. It's about having enough grunts you can sacrifice in the trenches. The philosophical management decision becomes an economical issue. And instead of spending three weeks flaming each other on the mailinglists (which has close to zero real effects and is thus in general close to worthless) it becomes important to work with people.
Find them.
Motivate them.
Retain them (even if you have to break their legs to do it)
The goal of the whole operation, of course, being to make yourself redundant because there are enough others doing things so you don't have to. And then you can care about the shiny things again.
Innovation doesn't happen in thin air. Innovation happens when you have a solid base to build on. And as long as gentoo doesn't have the base it will be hard. There are great things like OpenRC and webapp-config and portage and all that. But what is the use of the greatest omg-shiny-wtf-lol bling when you can't install it because the toolchain is broken, the packages are outdated and patches won't apply?
That's why people like flameeyes are filing hundreds of bugs. That's why there are people crunching through whole categories, trying to get the bugcount down. That's why there are dozens of overlays that have a bit ov everything.
Build a solid foundation and people will build things on top of it. But at some point you will have to get your hands dirty and build that foundation. To motivate people you have to lead by example, not with great words.
As a wise person said, genius is one percent inspiration and ninety-nine percent transpiration. It won't be easy or pleasant, but if you have a goal and work towards it you'll get there sooner or later. Gentoo becomes what you make of it. Stop daydreaming. Start working towards a better future. Yesterday's future is today ... so that means tomorrow is next weeks' yesterday?
Either way I'll continue chiseling, one bug at a time, until maybe that rough slab of granite becomes a great statue one day. Feel free to join in, it's more fun when you work as a team ...
I say that's silly. It's not so much a management issue. I mean, I really enjoy reading dberkholz's ramblings. But I think that's missing the point. We all want to do new shiny stuff. Everyone wants to be boss. But what use is the most brilliant battle plan if there are no grunts willing to pick up a rifle and die for their Vaterland?
If you look at it from that perspective it's not about making the best plan. It's about having enough grunts you can sacrifice in the trenches. The philosophical management decision becomes an economical issue. And instead of spending three weeks flaming each other on the mailinglists (which has close to zero real effects and is thus in general close to worthless) it becomes important to work with people.
Find them.
Motivate them.
Retain them (even if you have to break their legs to do it)
The goal of the whole operation, of course, being to make yourself redundant because there are enough others doing things so you don't have to. And then you can care about the shiny things again.
Innovation doesn't happen in thin air. Innovation happens when you have a solid base to build on. And as long as gentoo doesn't have the base it will be hard. There are great things like OpenRC and webapp-config and portage and all that. But what is the use of the greatest omg-shiny-wtf-lol bling when you can't install it because the toolchain is broken, the packages are outdated and patches won't apply?
That's why people like flameeyes are filing hundreds of bugs. That's why there are people crunching through whole categories, trying to get the bugcount down. That's why there are dozens of overlays that have a bit ov everything.
Build a solid foundation and people will build things on top of it. But at some point you will have to get your hands dirty and build that foundation. To motivate people you have to lead by example, not with great words.
As a wise person said, genius is one percent inspiration and ninety-nine percent transpiration. It won't be easy or pleasant, but if you have a goal and work towards it you'll get there sooner or later. Gentoo becomes what you make of it. Stop daydreaming. Start working towards a better future. Yesterday's future is today ... so that means tomorrow is next weeks' yesterday?
Either way I'll continue chiseling, one bug at a time, until maybe that rough slab of granite becomes a great statue one day. Feel free to join in, it's more fun when you work as a team ...
Mon Mar 2 14:03:54 CET 2009
How you can help
Since ca. 2001 we've heard the meme ... "Gentoo is dying". And it's still
not really dead.
Most likely because there are still hundreds of devs and power users working on things, creating a massive amount of new bugs, bugfixes and version updates.
But this process is far from optimal. Currently there is a weak negative feedback cycle that keeps potential contributors away. The problem is, simply stated, that user feedback is often not good or completely absent. So a motivated user will file a dozen bugs, get a response on two or three of them ... and then watch the rest not getting fixed.
Next time that user has a problem he might not even care to file a bug, so the issue doesn't get reported in a reasonable timeframe and hits more users. One of those will file a bug in the end, but this is suboptimal.
That leads to the situation where devs have many bugs to work through, focus on the filed bugs and never see the issues that hit a few users. So they don't get fixed, which means the users have a bad experience and everyone is unhappy.
So what can YOU do to help?
(1) File bugs. Please try to file good bugs, but even things like version bumps can be forgotten by devs. File a bug whenever you think something has gone wrong.
(2) Try to get bugs fixed. Often some feedback (works for me, fails with this gcc, problem only happens with that useflag) helps a lot. Of course patches are even better, but we can't expect you to do magic ;)
(3) Give us feedback. Try to get involved. Set yourself a small goal and try to get it done (fix 5 perl bugs, test all python packages with python 2.6, ...)
(4) Bribe some devs so the things you need get done faster. Beer, cookies and other bribes are welcome!
Most likely because there are still hundreds of devs and power users working on things, creating a massive amount of new bugs, bugfixes and version updates.
But this process is far from optimal. Currently there is a weak negative feedback cycle that keeps potential contributors away. The problem is, simply stated, that user feedback is often not good or completely absent. So a motivated user will file a dozen bugs, get a response on two or three of them ... and then watch the rest not getting fixed.
Next time that user has a problem he might not even care to file a bug, so the issue doesn't get reported in a reasonable timeframe and hits more users. One of those will file a bug in the end, but this is suboptimal.
That leads to the situation where devs have many bugs to work through, focus on the filed bugs and never see the issues that hit a few users. So they don't get fixed, which means the users have a bad experience and everyone is unhappy.
So what can YOU do to help?
(1) File bugs. Please try to file good bugs, but even things like version bumps can be forgotten by devs. File a bug whenever you think something has gone wrong.
(2) Try to get bugs fixed. Often some feedback (works for me, fails with this gcc, problem only happens with that useflag) helps a lot. Of course patches are even better, but we can't expect you to do magic ;)
(3) Give us feedback. Try to get involved. Set yourself a small goal and try to get it done (fix 5 perl bugs, test all python packages with python 2.6, ...)
(4) Bribe some devs so the things you need get done faster. Beer, cookies and other bribes are welcome!
Sun Mar 1 19:00:36 CET 2009
Bugwrangling and how to make people happy
Every now and then it might happen that you are one of the lucky souls to
discover a bug in a gentoo package. Most people respond to that by cursing,
then slapping their computer around a bit. Obviously that doesn't fix the
issue, but at least it feels good.
Now you might want to get that bug fixed. Where do you start?
First of all you might wish to get everything up-to-date. Many bugs get fixed quite rapidly, so if you emerge --sync'ed last week there's a good chance your bug has been fixed already.
If it still fails have a look on bugs.gentoo.org. After all maybe someone has already filed a bug. That makes it a lot easier for you :)
Now if noone else has managed to break things the way you did you may want to actually file a bug. The worst bug you can file is "It si teh broke!". This doesn't tell us what is broken and how it is broken.
One step up is "app-misc/foobar fails". That is a subject that mentions the package and that it fails. Maybe you want to add the version that fails too so it is easier to see which versions are affected.
Now you still haven't given any information what went wrong. If it fails while building add the build log if you can. The last few lines are often not enough to see what happened, and if in doubt add everything. Worst case we'll just scroll to the bottom and see what went wrong ...
Any information how to reproduce is also good. Any special things (hardened, using overlays, using a prerelease gcc, having omgwtf CFLAGS) should be mentioned so reproducing it is easy. If I cannot reproduce I cannot reliably fix it unless I give you a patched ebuild, hoping that you know what to do ...
System information is very nice. "emerge --info" dumps most things that are of interest, including useflags, cflags, compiler version and a few others. Please add that to bugs - exceptions are manifest errors and missing patches, those don't need that info.
If in doubt add more information. Maybe it is redundant or silly, but it is better than less information :)
If you keep that in mind your bugreports will be much more pleasant to work with. Motivated devs mean more bugs fixed, which is also in your best interest.
Of course if you know how to do it there's something even better you can do: Try to fix the bugs. Maybe you find a patch somewhere. Maybe you can write one. Having a patch available means that I don't have to think about it and just have to do a tiny bit of code review instead of trying to understand another weird app. And then of course you can attach a patched ebuild to the bug to let the maintainers be even more lazy ;)
Thanks!
Now you might want to get that bug fixed. Where do you start?
First of all you might wish to get everything up-to-date. Many bugs get fixed quite rapidly, so if you emerge --sync'ed last week there's a good chance your bug has been fixed already.
If it still fails have a look on bugs.gentoo.org. After all maybe someone has already filed a bug. That makes it a lot easier for you :)
Now if noone else has managed to break things the way you did you may want to actually file a bug. The worst bug you can file is "It si teh broke!". This doesn't tell us what is broken and how it is broken.
One step up is "app-misc/foobar fails". That is a subject that mentions the package and that it fails. Maybe you want to add the version that fails too so it is easier to see which versions are affected.
Now you still haven't given any information what went wrong. If it fails while building add the build log if you can. The last few lines are often not enough to see what happened, and if in doubt add everything. Worst case we'll just scroll to the bottom and see what went wrong ...
Any information how to reproduce is also good. Any special things (hardened, using overlays, using a prerelease gcc, having omgwtf CFLAGS) should be mentioned so reproducing it is easy. If I cannot reproduce I cannot reliably fix it unless I give you a patched ebuild, hoping that you know what to do ...
System information is very nice. "emerge --info" dumps most things that are of interest, including useflags, cflags, compiler version and a few others. Please add that to bugs - exceptions are manifest errors and missing patches, those don't need that info.
If in doubt add more information. Maybe it is redundant or silly, but it is better than less information :)
If you keep that in mind your bugreports will be much more pleasant to work with. Motivated devs mean more bugs fixed, which is also in your best interest.
Of course if you know how to do it there's something even better you can do: Try to fix the bugs. Maybe you find a patch somewhere. Maybe you can write one. Having a patch available means that I don't have to think about it and just have to do a tiny bit of code review instead of trying to understand another weird app. And then of course you can attach a patched ebuild to the bug to let the maintainers be even more lazy ;)
Thanks!