The quest for a ricer-free Gentoo

[ebfe]

Giving the ability to deal with tons and tons of switches and options, Gentoo attracts lots of ricers. IMHO those users hurt both the userbase and the developers as they consume "support-resources" in #gentoo/the forums and stress the developers.

I use this thread to outline some things that the general user shouldn't deal with, things gentoo can't do and things that have a high psnr; they appear in no specific order and I ask you to participate in this thread.

I might add other things to this list. These are the things that annoy me the most.

Update 10/16: http://planet.gentoo.org/developers/deathwing00/2006/10/16/just_another_0_day_bump_request
Update 10/23: http://planet.gentoo.org/developers/aross/2006/10/23/0-day-bump-requests

• The Gentoo saga
  
  
  
  • I compile, therefor I'm faster
    The impact of a compiling for your hardware on performance is a very general thing. Don't expect highly functional code like encoding or encryption to be any faster. What you can expect is an overall gain that might settle in things like time required to boot, load kde/openoffice and such. The binary distributions don't add any "--abacus-math --286-only" flag when compiling. They don't.
    
    
  • The kernel
    Your kernel is not faster than any other kernel. No, it's not. The fact that most gentoo kernels only contain the things that are really needed for the current hardware won't result in any performance difference. There is no point about a kernel image being only 1.2mb on a system with 2gb ram. In fact during normal operation the kernel code is executed very, very infrequently. You switched from CFQ to anticipatory? Great, you just lost all performance gain by reading this post not fast enough.
    
  
  
  
• make.conf options
  
  
  
  • The mighty -O (CFLAGS)
    Use -O2 or, if you know what you are doing, -Os. In general, -O3 won't produce faster code as highly functional code that could benefit from it is hand-optimized anyway. -O3 is slower for compilation, produces larger object files and might even break stuff.
    
    
  • The -f options (CFLAGS)
    You don't need them. No you don't. Most of the options you are thinking of right now are also controlled by the -O switch, enabling them explicitly won't change a thing. Check the gcc documentation about optimization flags. Some ebuilds even filter compiler flags (like -ffast-math) to defend evil dragons.
    
    
  • The -j option (MAKEOPTS)
    The -j option determines how many jobs the make process will run at the same time. In fact the number of concurrent jobs is LIMITED by this switch, giving you the ability to cap memory usage on large builds. Anything above -j(Cores*2)+1 won't give you any performance gain. If you have plenty of RAM, just apply "-j".
    
  
  
  
• Package versions
  
  
  
  • ACCEPT_KEYWORDS="~arch"
    Will break stuff. Unmasked packages in the unstable tree are known not to crash and burn your whole system. That's all you get. Most of the questions regarding "broken" packages in #gentoo come from users that are on ~arch and complain about xorg8 not compiling with gcc5. If you need single packages from ~arch, keyword the specific version - not the whole package - yourself by adding =cat/pckg-version to package.keywords.
    
    
  • Packages going stable
    There are reasons why the most recent versions of certain packages are not in the stable tree. Don't complain about things like java5 not being there yet (java5 went stable today *sigh*). Remember that there still might be problems with other packages that you didn't even know before, forcing your piece of candy into ~arch until the other(!) package is fixed. You CAN wait for things like x11, java, kde, gnome or mysql.
    
    
  • Version bumb requests on bugs.gentoo.org
    All work and no play makes Jack a dull boy. The package maintainers know that a more recent version is out there. The knew before you. Opening a version-bump-bug like 2 hours after a new version of some piece of software was released won't get the ebuild into the tree any faster.
    
  
  
  
• Tweaks
  
  
  
  • 'Preloading'
    Don't. The kernel will use all currently uncomitted ram either for buffering or caching i/o operations. "Pre-loading" certain files by forcing them into the i/o cache ('cat /usr/lib/mozilla-firefox/firefox-bin > /dev/null') might give you some apparent performance gain on loading time, but reduces cache efficency in the long term. Let the kernel decide what to cache.
    
    
  • 'Memory cleanup'
    Don't. There are scripts out there that consume huge amounts of ram, forcing old pages into the swap file, leaving a giant hole of (apperantly now) free ram. Some argument as above, there is no gain in the long term. If you care about free ram, see /proc/sys/vm/swappiness.
    
  
  
  

[Gergan Penkov]

You understand that all these rules hindern further development, no?
The problem is not the so attributed "ricers" - the problem are people, who don't understand what they are doing and bitching after that, one could resolve this problem with education and not with rules and prohibitions.
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack

[wynn]

Couldn't all problems be solved by education?

It's a nice idea but the whole of society is pushing in the other direction: faster, flashier, first-on-the-block <=> progress.
_________________
The avatar is jorma, a "duck" from "Elephants Dream": the film and all the production materials have been made available under a Creative Commons Attribution 2.5 License, see orange.blender.org for details.

[Corona688]

[Headrush]

[Corona688]

[Corona688]

[dleverton]

[ebfe]

http://www.mega.bz/rotfl/images/argue091204.jpg

[dleverton]

[Mousee]

[ebfe]

you got my point

[micko]

So what? Arguing over the Internet is still fun =)

Nice to see all gentooers aren't just ricers. Allthough there seem to be different views about what's ricing and what's not... I understand the term as http://funroll-loops.org/ and not as a person who really knows what he's doing.

[Bones McCracker]

Maybe you should switch to OpenBSD.

[gixer]

No no, I totally agree with this guy. Let's take the same mentality as American "Gun Control". Instead of getting rid of the idiots, let's get rid of the guns! While we are at it, let's ban dirtbikes, motorcycles, and scissors too. I believe that they are too dangerous and waste our 'hospital emergency resources'. OH and let's not forget to ban computers since those pesky 'hackers' keep using them.

Choice is what Gentoo is all about. All these 'bells and whistles' are there if you wanna mess with them. The average Gentoo user, I agree, probably doesn't need them. BUT that doesn't mean that they should NOT be available. Again, see above statement.

Idiot.

-Gixer
_________________
If you had to rebuild your car's engine on the freeway, every week, would that be ok? Then why would you use windowz?

[Bones McCracker]

Don't get me wrong; I use OpenBSD and I like it.

What I mean is that gentoo's flexibility comes at a cost. If you're looking for a tightly-wrought, idiot-proof distribution (as a means of freeing yourself of idiocy in your environment), there are other choices. As the French say, "a chaque un son gout".

This is a highly-configurable source-based "meta-distribution" to which many gnu/linux end-users also happen to be attracted because its FreeBSD-style automation of source distribution makes it feasible for use as a highly-customized end-user system.

Reducing flexibility might increase administrative efficiency and reduce community chaos, but it would also reduce gentoo's value as "meta-distribution" and as a highly-customized end-user system. We would be "cutting off one's nose to spite one's face".

The problem you point out does exist, but I think the solution is something else. "Behavioral modification" in some form.

Hack their user cp and add a "Ricer" badge as their avatar.

[NoZ]

[Earthwings]