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/dea ... mp_request
Update 10/23: http://planet.gentoo.org/developers/aro ... p-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.

[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.

[Corona688]

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 hell they don't. Gentoo livecd's come configured for i386. That's so obsolete it won't even work with the new profile. Not to mention the sole advantage of using gcc4x over 3x doesn't come enabled in the default flags.

[*] 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.

True, removing modules won't make it faster. Fortunately, there are plenty of other things you can do to optimize your kernel's performance. Just because kernel code doesn't execute often doesn't mean the scheduler's not of fundamental importance.

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.

-O2 is pretty good, yes.

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.

First thing you've said I flat-out agree with.

The -j switch (MAKEOPTS)
The -j switch 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

By itself, i.e. just -j, it won't limit the number of jobs. Look it up.

ACCEPT_KEYWORDS="~arch"
Will break stuff. Unmasked packages in the unstable tree are known not to crash and burn your whole system.

People don't often use ~arch on a lark, they do so because they have to, since supposedly "stable" packages are also "old" hence not always properly maintained. Many times I've seen devs bump a version when fixing build failure, leaving unbuildable versions to fall out of portage instead of marking them broken.

Most of the questions regarding "broken" packages in #gentoo come from users that are on ~arch and complain about xorg8 not compiling with gcc5.

And you answer them? Seriously, the last time I checked out #gentoo I was told that I couldn't expect people to acknowledge my existence if I wasn't using the dev-sources kernel. dev-sources was broken at the time. ...I didn't spend long there.

Besides. Where do you think stable comes from?

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.

Can you? I know I had to add patches way ahead of the mainline to fix mysql on my application at work.

[*] 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.

Really? They keep in mind all 10,000+ of them? They should have been telling me off, instead of saying "thank you" when I point out a version of something they forgot about is 2 years old?

[*] 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.

Agreed. If preloading worked worth a damn, Windows users wouldn't froth at the mouth when they get another "speedlaunch" in their taskbar, startup folder, profile options, registry, or any of the other 5,000 ways Windows helpfully provides to do this.

[*] '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.

This has been useful in some few, specific applications, like software suspend. Get crap out of RAM so there's less to suspend.

[Headrush]

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.

Ditto.
My guess is if you are a ricer, you don't need a dev to bump a ebuild for you, you just do it yourself in your overlay.

Corona688, I could be mistaken, but I don't think any of the LiveCD comes compiled i386 anymore.

ACCEPT_KEYWORDS="~arch"
Will break stuff. Unmasked packages in the unstable tree are known not to crash and burn your whole system.

People don't often use ~arch on a lark, they do so because they have to, since supposedly "stable" packages are also "old" hence not always properly maintained. Many times I've seen devs bump a version when fixing build failure, leaving unbuildable versions to fall out of portage instead of marking them broken.

Although I agree at times some ~arch packages may be needed, from my few years experience helping people with Gentoo, I have found the majority of time noobies are using ~arch for no apparent reason other than its newer and they assumed it was better somehow, or someone in the forums gave them faulty info and said they had to.
(Easy fix for some people rather than solving problems correctly. )

People complain a lot about needing certain versions marked stable in portage, but those those changes also introduce different problems for other users and other packages, so how do you decide who you please?

[Corona688]

Corona688, I could be mistaken, but I don't think any of the LiveCD comes compiled i386 anymore.

gleep. Good thing 2005.1 still works for nearly everything.

[Corona688]

(Easy fix for some people rather than solving problems correctly. )

The way I've seen fixes happen, is they get put in ~arch, then marked stable later. This sounds good in theory, but leaves stable, not, and testing, tested. Often enough I've "fixed" a problem by building it in ~arch.

[dleverton]

Corona688, I could be mistaken, but I don't think any of the LiveCD comes compiled i386 anymore.

gleep. Good thing 2005.1 still works for nearly everything.

http://thread.gmane.org/gmane.linux.gen ... ocus=43084

By the way, the stage1 tarball and Minimal InstallCD are both built as "i386" and will remain that way for the foreseeable future.

[ebfe]

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

[dleverton]

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

Why?

[Mousee]

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

So basically you're saying, you're wrong, and you posted this only to piss people off.
Good job... not.

[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

[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]

As the French say, "a chaque un son gout".

I would rather say : "Les goûts et les couleurs." That's better.

[Earthwings]

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

Which gets you banned for a personal attack, see the guidelines.
ebfe, please don't post links to pictures like the above in any forum except Off The Wall, if at all. Locking the thread due to that and the other off topic posts. Everyone else, please keep friendly.