Intro: This is not to be taken seriously, but some might think it is. Do not be fooled. This is meant to be humorous in the spirit of funroll-loops. I will, however, be attempting to write the first couple parts as though it were serious (and, of course, as though I were not me). Mostly, the point of this post is for humor, but also to show some people what not to do and how to not do it (covered in the third and final part).
---------------------------------------------------------------------------------------------------------------------------
This document will be broken down into two sections:"How to Rice"-In this section, you'll learn all about the intricacies of ricing from a seasoned veteran.
"How Not to Rice"-Here I'll cover how you can avoid having your system called slow or stable.

How to Rice:
Firstly, I think it's important to know what ricing is. Paraphrasing UrbanDictionary, a ricer is someone who makes cosmetic modifications to their car in order to make it go faster. They are descended directly from Julius Caesar, and have had a large impact on the automotive racing industry in general.
How can this venerable practice be applied to Gentoo? is what you're probably asking yourself right now. The answer is simple. CFLAGS, CXXFLAGS, and LDFLAGS. By setting the three of these in a simple combination much "like your average voodoo witch doctor" (A quote from developer ciaranm, proving that he's a ricer even though he opposes it constantly), you can boost your system performance by sixty to seventy percent. And the method couldn't be easier.
Why are you qualified to tell me how to be a ricer? I know what I'm doing! Maybe you do. But I've been on these forums for a while, and, as you can see from my large postcount and rank, I'm l33t. Not only that, but I work on several other projects which are designed to enhance your ricing experience. Therefore, I must know what I'm talking about.

Now that we have the basics covered, lets begin.
Your CFLAGS variable is a valuable asset to any attempt at ricing. Without it many of your applications will miss out on a massive speed boost, and you wouldn't want that. So here's what I would recommend:

-09
Optimize to the highest degree possible. -09 turns on all optimizations. Be warned that your binaries might be slightly larger as a result.

-march
This specifies the name of the target architecture. GCC uses this name to determine what kind of instructions it can emit when generating assembly code. This option can be used in conjunction with or instead of the -mcpu= option. Permissible names are i386, i686, athlon-xp, pentium3, pentium4, s6000.

-pipe
Use pipes rather than temporary files for communication between the various stages of compilation. Permissible values are 1-65536.

-funroll-every-loop
Unroll all loops, even if their number of iterations is uncertain when the loop is entered. This usually makes programs run much more quickly.

-mrice

-mabi=rice
Extend the current ABI with ricer-oriented ABI extensions. This does not change the default ABI, instead it adds the ricing ABI extensions to the current ABI.

-omg-optimized

--disable-all-instructions
Turn off any specification of a language, so that every file is handled accordingly to its file name suffix.

-DREENABLE_FAST_EXECUTION
Turns on all optional speedups related to the execution of a program. EXPERIMENTAL!

You may recognize some of these flags from either funroll-loops.org (a site devoted to Gentoo ricers) or the #gentoo-dev irc channel (I got as many as I could from there, but my xchat segfaults randomly for some reason...). As you can see, I've certainly done my research and even found a few ones that are UNDOCUMENTED IN THE GCC MAN PAGE BECAUSE THEY'RE SO GOOD!
Examples of these would be -mrice and -omg-optimized, both of which I found referenced several times on the gcc mailing list. I would post links to the relevant posts, but unfortunately the evil developers there caught on and deleted the thread. Clearly a conspiracy.
What I did find out though, was that -mrice disables a lot of the dumb gcc errors (ones that are just people being annoying with their coding), and -omg-optimized is an even more secret flag (hence the unusual name). -omg-optimized takes the source files and loops them through a special three-pass gcc optimization algorithm. I know it sounds weird, but this flag is what will give you most of your speed.

The next important thing are your CXXFLAGS, which optimize programs compiled from C++ code. For the most part, all of the same flags that you got from the CFLAGS section will work perfectly here, but you'll also want to add

Code:

-muse-gcc

in addition to the flags listed above. This tells the compile scripts to use gcc instead of g++, which results in faster compilation and faster code. Again, this might sound absurd, but trust me: there is no substitute for experience.

LDFLAGS are next, and you'll have to be really careful with these. If you screw up, you might end up like this guy who has broken his system because of a spelling error in his LDFLAGS variable. Tragic, but it can happen to anyone. So make sure you're copying everything exactly!

Code:

LDFLAGS="-04 -static -Rsymbols"

I'd post the pertinent ld man page clips again, but they're hard enough for me to understand, so I'll save you the trouble and paraphrase.

Quote:

-04
Optimizes the resulting file; acceptable values are 0-3.
-make-static
Links every file statically, eliminating startup lag that is caused by programs loading the libraries that they depend on.
-Rsymbols
Removes all unnecessary code from the source files, making the resulting executables smaller, thus giving them faster load times.

So as you can see, we're once again taking compile tools to the limit by going one step beyond the acceptable bounds because that's what we ricers do!
Optionally, you can skip the above LDFLAGS section and add

Code:

"-feverything-at-once -Wl,--wait-all"

to your CFLAGS and CXXFLAGS. This causes gcc to link things on its way, speeding up the compile process significantly.

somewhere in your make.conf. Failure to do so will result in UNOPTIMIZED glibc!!!!
Not only that, but compiling the binaries you'll be using on your computer is DEFINITELY the worst possible way to gain speed. Why? is what you're probably asking. As with most ricing tips and techniques, it's simple. The x86 architecture was created to be slower than other architectures, with one exception: the 8086 variant. This special processor was developed by scientists at Area 51, and was actually designed to only be used in government supercomputers (it's faster than a pentium4 at the same clock speed because it only has ONE pipeline!!!). Your compiler, gcc, supports it though! So all you have to do is make sure your CTARGET/CBUILD/CHOST are set as in the above, and your code will be optimized for the 8086 processor, guaranteeing that it will run approximately SIX TIMES FASTER on your computer!
An alternative to the 8086 arch is to use the "bmx" arch. This probably seems strange, and it is. Really, it's a hidden arch from the gcc developers. The key is that if you try using CTARGET="bmx-unknown-linux-gnu-speed", you have to add the "--no-brakes" option to your CFLAGS and CXXFLAGS. This causes all of the "brakes", or as I like to call them "speed traps", to be shut off, resulting in considerably faster executables.

Stealth Ricing:
Sometimes, you have no choice. You have to ask those pesky developers for help. But if you show them your awesome optimizations, they'll copy all the hard work you've done and start using them too. That's tantamount to plagiarism in the ricing world, but they won't care; developers think that they're above the law.
In order to avoid having your work copied. you need Stealth Ricing. This is the practice of subtly altering the output of "emerge --info" to conceal your best optimizations. Here's a sample emerge --info, with all the irrelevant parts snipped out:

This reminds me. You'll want to make sure that you set PORTAGE_NICENESS="-19" in your make.conf. This will devote more processing power to your compiling, resulting in much better binaries.
Anyway, as you can see, my system is totally tweaked out. I've got lots of special packages, including ultra-experimental versions of gcc, glibc, and even portage, all of which are way faster than the older versions. Besides that, I'm using a hidden portage profile under "beta-linux", which unmasks all of the good packages. On the same note, you'll want to symlink package.mask to package.unmask in /etc/portage like so:

Code:

ln -sf /usr/portage/profiles/package.mask /etc/portage/package.unmask

This guarantees that you'll get all the top sekrit super fast experimental ebuilds!
My cpu is overclocked as far as it will go; I needed to install liquid nitrogen cooling to get it to even boot up!
As I mentioned earlier, you won't want the developers (or probably even other ricers) to see something like this. I've kept a few of the REALLY good flags secret for myself, because you've gotta learn some stuff on your own! Here's the "Stealth Ricing" version which you can show to developers:

As you can clearly see, there isn't much for the developers to find fault with here. That's good, since the problems you're having will never result from using eXtreme CFLAGS/CXXFLAGS/LDFLAGS anyway. You'll probably notice that I didn't bother to include my USE variable in the "Stealth Ricing" version either. That's because your USE flags have absolutely no effect on anything. USE flags are a big conspiracy by the Gentoo developers to lock us out of features that we want. By enabling a USE flag, you're actually DISABLING a feature! Good thing you've got me to teach you all of this stuff, isn't it?

Another thing you'll want to watch out for is flag-filtering. This is when the Gentoo developers recognize that using a certain CFLAG will give an incredible speed boost, so they try to disable it to slow down the users. Clearly we wouldn't want this, so we're going to do something to remove it!

What this does is search through all the files in /usr/portage looking for ebuilds with 'strip-flags' or 'filter-flags', and comment those pesky lines out. Of course, some of the really big packages (xorg for example) still have a few safeguards against this. You'll need to manually edit the ebuild to get around these, but I won't spoil it for you. All good ricers are more than willing to invest time in a bit of trial and error.

The cron daemon can be a valuable asset to any ricer. By scheduling certain tasks to occur frequently during the day, you can ensure that your system is always on the cutting edge of speed. First off, you'll want to read through this guide to learn all about cron. Once you've done that you should be able to make your own cron tasks without any problems, so I'll just outline the basics. First, you need a task which will execute 'emerge sync' every ten minutes. By doing this, you can ensure that your portage tree is always as up-to-date as possible, thus enabling you to get the newest packages. Additionally, you will want to set another cron task to execute 'emerge -e world' every thirty minutes so that your packages are always as fast as they can be. You might be asking, Won't my world rebuilds run into each other if I'm only allotting a half hour for them? The answer, my friend, is no. My optimized system can rebuild every package in less than fifteen minutes.

Hard Drive Ricing:
Another little-known form of ricing is that of the hard drive. As many of you know, a hard drive is a mystical device that was created by Odin to aid mortals in the fight against Chaos. What you probably don't know is that there are tools you can use to make your hard drive run 80%-120% faster with no downside!

What you'll need is a program called hdparm which you can emerge because it's in portage. Once it's installed, edit this line in the file /etc/conf.d/hdparm:

Code:

all_args=""

to

Code:

all_args="-d2 -X99 -m1024 --speedread"

This does the following:
-d2 - turns on ultradma
-X99 - sudma10 mode, normally hidden away unless you buy a really expensive hard drive
-m1024 - moves blocks in very large chunks to speed up drive functions
--speedread - causes the drive to only read the middle of the data because it knows what the edges say anyway

Once you enable these settings, you'll probably feel like a rocket has been strapped to your computer!

That pretty much covers your basic ricing techniques. More advanced things that you should try include using the reiser4 filesystem, commonly known as "ricerfs" because of its amazing speed and stability. I would say that you should try using a better kernel than vanilla-sources or gentoo-sources, something like love or nitro, but they started to suck lately so you can't use them anymore .
Previously, the nitro developers used to get secret experimental patches from some of the head kernel developers. These patches made everything much faster because memory usage and disk/cpu schedulers were enhanced by them, but recently they've announced that they won't be including such things due to pressure from the Gentoo developers. ciaranm makes me so angry sometimes with his know-it-all attitude and anti-ricer propaganda...
Love-sources had a similar arrangement with a different group of kernel developers, but, as a result of recent hasslings from the Gentoo developers (grr...), they have been forced to remove all of the speed-increasing patches that are not freely available to everyone.

How Not to Rice:
Let's face it: if you're a ricer, you think that stability is for wussies. You aren't going to mind if something segfaults on you every once in a while, or if your computer crashes after a few weeks' uptime. It's all about getting the most out of the money that you put into your hardware.

Since you're trying to get the most out of your machine, it would be counterproductive to use the default settings. When ciaranm tells you to leave CFLAGS/CXXFLAGS/LDFLAGS unset in your make.conf, you clearly don't need to listen to him. After all, he's a developer; someone who works on stuff to make sure it's stable enough to use on servers. You aren't running a server, so anything he tells you is clearly irrelevant.

Another note of caution: do not EVER try and file a bug report on bugzilla while using nonstandard CFLAGS/CXXFLAGS/LDFLAGS. The people there won't understand what you're talking about, and they'll just get pissed off to try and cover up their lack of knowledge. Sad but true.

End ricing tutorial/End fake personality.
---------------------------------------------------------------------------------------------------------------------------
So what do you think? Might sound far-fetched to some, but I bet it isn't too far off from the truth. Oh, and to reiterate, none of the above statements are true. Anyway, here's the third and final section.

How to be a good Gentoo user:
In this section, I will teach you how to avoid the common Gentoo stereotype of "ricer". Not only that, I'll show you how to avoid trolling developers.

The first step, as in ricing, is your CFLAGS/CXXFLAGS/LDFLAGS. Leave them as they are; you aren't missing out on a whole lot. If you want proof, check this out. Here you can see several gcc (and even icc) benchmarks which use POV-Ray (For those who don't know what POV-Ray is, it's a ray tracer) as their test app. As you can see, the unoptimized "-O2" run is actually faster than several of the "optimized" runs.
Frightening, isn't it? Not only that, but even the fastest run ("-O3 -mtune=pentium4 -march=pentium4" for those of you who are too lazy to click the link) is only 8.7% faster than the regular "-O2" run. Not that I would use "-O3 -mtune=pentium4 -march=pentium4" since sse2 is still too sketchy for my liking.
Please note that the 8.7% speed gain is app-specific. POV-Ray is a purely math floating point operation intensive program, and very other few apps are. That means that while an 8.7% speed gain may be possible here, it is almost certainly much less in any other case. Plus, this is just a simple benchmark test. There is no mention of how stable POV-Ray was when used with these CFLAGS outside the boundaries of this test.
And where's -ffast-math? Definitely not in the "fastest" set of CFLAGS, and actually shows up in some of the slower runs. Even more in depth on -ffast-math, it makes things slower and can actually BREAK math functions. If you'll read this argument between Linus Torvalds and some gcc guys, you can see that an example of the broken code that -ffast-math produces can be seen in the function a/b/c. With -ffast-math, a/b/c is turned into a/(b*c). Clearly, they are not the same. Of course, some people will read this and go "OMFG that's Linus Torvalds! He says -ffast-math is usable, so I should use it!!1!!1!". Wrong. He's stating that it is usable for people who don't care AT ALL that their code will be broken.
"LDFLAGS=teh new OPTIMILAZIATIONS"
Wrong again. If you absolutely must set them, at least follow taviso's advice from this thread and use

Code:

LDFLAGS="-Wl,-O1 -Wl,--sort-common -s"

Maybe you'll notice the difference, maybe you won't. At least you won't be doing something completely insane though.
CTARGET/CBUILD should never be set, and CHOST should be left at whatever the default is for your system.
gcc cannot be used as a linker.

Crazy kernel patches: Experimental does not equal speed, nor were there ever any secret patches given to nitro/love maintainers as far as I know. If you want to use nitro/love, great. But don't go around telling others to use it. The point of those kernels is that they provide featuresets unavailable in any of the Gentoo-supported kernels, such as ck combined with vesafb-tng and fbsplash (nitro) or mm with vesafb-tng and fbsplash (love). As I've said before, there are no super-ultra patches that make them faster. Just regular stuff that you can find individually in Gentoo-provided kernels. If you don't need the extra features, you probably don't need to use them.

Bug reporting: If you're going to report a bug, do it the smart way: make sure you try compiling the packages with CFLAGS=""/CXXFLAGS=""/LDFLAGS="" before even considering it. There is also the possibility that your toolchain (gcc, binutils, ets) is b0rked from your *FLAGS. If that's the case, you'll need to recompile such things (or use a rescue tarball from avenj) before attempting to file a bug report. Gentoo developers waste a considerable amount of their time sifting through bug reports that are caused by unnecessary *FLAGS. That's why they get worked up and post angry comments on the forums.
Also, "Stealth Ricing" is illegal in many countries, the punishment being execution by means of angry penguins. Don't ask how, just acknowledge that it is painful and don't do it.

Crontab: Do not abuse the portage rsync servers by setting cron jobs to sync every fifteen minutes. This will most likely get you banned from certain portage mirrors, and you wouldn't want that. Aside from getting banned, you'll also be putting unnecessary stress on said mirrors. If you want to see what new packages are out, check this site. If you see one that you want, try downloading it manually and sticking it in your portage tree instead of using a sync to get a single file.
Not only should you not abuse 'emerge sync' with cron, but you shouldn't ever put 'emerge -e world' in cron. It's just...stupid.

Do not symlink package.mask to package.unmask. It's stupid. Think about it (but don't strain yourself).Do not try to disable flag-filtering or strip-flags. This happens for a good reason.

Dev trolling: Posting your insane *FLAGS in a visible place on the forums has two possible results.
1) Some unwitting user sees it and decides to use it, not knowing that it will break stuff. Eventually, this will probably lead to a bug report (try searching bugzilla for "cflags" and see how many "X package doesn't compile with X flag" or "X package filters CFLAGS" bugs you find).
2) You'll bait some developer (probably ciaranm since he patrols the forums quite frequently) into telling you that you're insane.
Avoid this by not posting your insane *FLAGS. If you have them, keep them to yourself. This way, everyone is happy.

Parting words: Ricing is for people who don't understand that speed isn't everything. You might have a working system now, but can you guarantee that it will remain stable?
Con Kolivas, the guy who makes the ck patchset (which nitro-sources is based upon) and staircase cpu scheduler, has this to say on ricing:

Con Kolivas wrote:

Well it's an interesting way to test the stability and functionality of weird and wonderful optimisation techniques, but ultimately futile because the performance gains are almost certainly non existent, yet instability and impossible to track breakage are almost guaranteed.

This is coming from the person who makes the "desktop-oriented" patchset and scheduler. I'd imagine that he wouldn't be "missing out" on ricing if it was worthwhile.

Credits:
I'd like to thank the guy who made funroll-loops.org for making such a funny site. I borrowed a couple of my fake CFLAGS from there, and I'd like say thanks for thinking of them in the first place.
Thanks to the Gentoo developers (in #gentoo-dev) for providing several other humorous things that I worked in here (ths, if you're reading this, ricerfs is a great name!) such as vapier's -mrice suggestion and dostrow for -mabi=rice.
Con Kolivas, for taking time to give me a quote on ricers.
GCC people for making a compiler even despite the acts of ricery that people commit daily with it.
wdreinhart, for reminding me about Stealth Ricing.
cokehabit, for informing me that CTARGET is essential to the speed of any system (but not really).
ciaranm, for package.mask symlinking genius and flag-filtering removal idea.
ebrostig, for cross-compiling goodness
pilla, for i8086 arch and bmx arch.
amne and vrln, for the cron stuff.
codergeek42, for using gcc as a linker.
timeBandit, for hard drive ricing.

Apologies:
Firstly, I need to apologize to ciaranm. While "like your average voodoo witch doctor" is a direct quote from him, it was actually used as a jibe against me. ciaranm is not a ricer. He is the most anti-ricer person you will ever meet, and he's probably trying to have me kicked out of the forums at this very minute for putting his name in the same sentence as "rice". My apologies, ciaranm, and I hope you can see the good that will come out of this document.
Next would be the writer of gcc documentation. Yes, I rewrote some stuff. As I said, everything in the "How (Not) to Rice" section is false. The gcc man page does not say any of those things; I did some rewording for comic value.

Lastly (for those who haven't caught on, or are going to deliberately attempt to misread this):
Do not attempt anything listed in the "How (Not) to Rice" section. It's a joke.

Having said that, if anyone wants me to add anything to the informational section (like what some other commonly abused CFLAGS do), PLEASE message me or post here. The same goes for any errors that you see. This is meant to prove that ricing is dumb, and that can only be accomplished if the information here is correct.

I have one nitpick with your tutorial: You forgot to instruct your readers on "stealth ricing". You should include a section on doctoring the output of "emerge info" to hide your super-optimized CFLAGS, bleeding-edge kernel version, and double-secret-beta GCC version from angry developers, just in case you run into a serious problem, and there is no choice but to file a bug report.

Other than that, it rocks. Good one.

Last edited by wdreinhart on Thu Mar 17, 2005 8:16 am; edited 1 time in total

I have one nitpick with your tutorial: You forgot to instruct your readers on "stealth ricing". You should include a section on doctoring the output of "emerge info" to hide your super-optimized CFLAGS, bleeding-edge kernel version, and double-secret-beta GCC version from angry developers, just in case you run into a serious problem, and there is no choice but to file a bug report.

Other than that, it rocks. Good one.

I can't believe I forgot that! I'll put it in right now.

Maybe if I'm lucky this will get stickied or something...

EDIT: Just finished the update. Thanks for the sticky-loops amne!_________________There is no substitute for experience.
Imperfection indicates a lack of effort.

Last edited by discomfitor on Thu Mar 17, 2005 4:54 pm; edited 1 time in total

Well, I just compiled firefox with -omg-optimizations and -O45 and I cannot believe it is running so fast. This is incredi..._________________The md5sum of the above post is 06280ccd85ef9deb49c336e7945f4b5c

Man, I can believe you sold out Darckness. You used to be so cool. But now you're all all talking pussy stuff like stability. They just ain't no such thing as heros no more.

Linux is all about the freedom. If I feel like submitting bug reports for some applications that I just complied using -O11 and -funroll-everything using a alpha copy of GCC that I swiped from some developers hard drive this morning then I'm going to do it and I'm not going to let one of the man's footsoldiers like Cinnaram tell me no.

I just finished tricking out my PC with a spoiler and a type-R sticker and I've just recompiled everything using LDFLAGS I just made up. Its smoking fast now or that might be the CPU getting a bit hot. Either way I'm running Linux to the extreme.

I cringe whenever I hear "ricer". It is a racist term directed at if not japanese people at least japanese-made cars. Even if the term has broadened a bit in usage to include Pontiac Sunfires with ludicrously large aluminum wings bolted to the trunk it's still not a great term to be using.

Unfortunately there is nothing else to describe that specific sort of misguided fanaticism.

All of that aside, my computer handles way better now that I lowered it 0.5" by getting aftermarket rubber feet from Eibach._________________ich bin ein seg fault

to be fair ciaranm should go to suse or mandrake, they compile stuff like he does.
i do not understand how a dev would want to take away one of, but not the, best part of gentoo.
tuning the system to your machine's hardware, i do not see the point of runing softeware compiled for a 386 while you run a pentium (insert number greater then 1 here) or a athlon xp (insert number here).

to be fair ciaranm should go to suse or mandrake, they compile stuff like he does.
i do not understand how a dev would want to take away one of, but not the, best part of gentoo.
tuning the system to your machine's hardware, i do not see the point of runing softeware compiled for a 386 while you run a pentium (insert number greater then 1 here) or a athlon xp (insert number here).

Lol. Isn't "ricing" the whole point of good developing/fast algorithm implementation though?

OH OH OH! I came up with a LOG(N) sorting algorithm! Who cares if the original ordering algorithm was N^2, I got a LOG(N) algorithm baby!!!!! *smirk*

*sigh* There is no general log(n) sorting algorithm.

I know I was just joking (well, partially; mostly thinking about quicksort under some cases ). That would of course be the holy grail of computer science if someone figured out that . There are specialized algorithms though which under certain cases do function in log(n) time though of course .

I know I was just joking (well, partially; mostly thinking about quicksort under some cases ). That would of course be the holy grail of computer science if someone figured out that . There are specialized algorithms though which under certain cases do function in log(n) time though of course .

Eh? No, a log(N) sorting algorithm is impossible (except in special cases where you know that, say, only the first item is out of place). Doing a guaranteed time n*log(N) sort is easy, and doesn't involve anything even remotely related to qsort. Going beyond log-linear in the general case is impossible.

Nice - Now I understand why I must run my desktop on vanilla Also Maybe official message to Con Kolivas , Nick Piggin and maybe J.Moilanen and P.Williams like " please don't do further version of Plugsched,Staircase, Nicksched ,SPA and genetics implementations " will be really good

Also I want to apologise myself for too much of ricing and every man who used love or vivid for the really bad stuff in it (maybe for my bad english too )

I leaving ricing friends I have really $$$$ Daddy who buing me new Ferrari.
Now I will be able to ricing in real People , buy also a new good Ferrari and compile vanilla instead of love and nitro

If You don't have money for new beaty Ferrari like me , then I can grant You latest "Need for Speed" game version .

Ohhh I forgot , please turn of the new superb boombastic fantastic most experimental " kernel like HAL 9000 " feature in latest love If You want to life - If You don't know yet who is HAL ? - then please go watch 2001: A Space Odyssey and then deactivate this feature

and in latest Vanilla is new much more superb than love and nitro feature " Mega`o`Warp-Speed feature" in Kernel Hacking. You have to insert coin to the cd-drom drawer ( can be a 10EURO ) close drawer , and now You can choose this feature and runnnnn with speeeddd , also for people Who don`t have this 10EURO is another secret feature even better than 40GB Stack in kernel and Boombastic Genetic Hal 9000 All in One Scheduler ....ohh my telephone ringing . I will tell You late

cheers._________________ "Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard

Nice - Now I understand why I must run my desktop on vanilla Also Maybe official message to Con Kolivas , Nick Piggin and maybe J.Moilanen and P.Williams like " please don't do further version of Plugsched,Staircase, Nicksched ,SPA and genetics implementations " will be really good

No, see, the difference is that those guys understand what they're writing, and they're quite clear that they're pushing out experimental code to be used on test systems by people who have a clue. Big difference between that and randomly applying patches that have cool-sounding names...

and even You don`t know what I really have in mind about this things. (random patchsets, ricing etc. )
I exactly know what I know and what I don`t know about these things ^^^

[not_a_joke_EDIT]

I must agreed that in this how-to ...everything is a true (as the sense of it )

more : this how-to can start new trend : a trend to non-ricing and way to stability and... non mass-full of features in patchsets like all the stuff from the world in the one pack. will be better.

I think this can work - required a some time only because -- most of things is a trend.

[/not_a_joke_EDIT]

cheers._________________ "Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard