Slashdot Mirror


Measuring The Benefits Of The Gentoo Approach

An anonymous reader writes "We're constantly hearing how the source based nature of the Gentoo distro makes better use of your hardware, but no-one seems to have really tested it. What kind of gains are involved over distros which use binary packaging? The article is here."

97 of 467 comments (clear)

  1. Misses the point by keesh · · Score: 5, Interesting

    The source-based thing isn't even why most people use gentoo. According to a recent poll on the gentoo-user mailing list, most people like it because of Portage (the package management system), with Customisation / Control coming in second (performance was third). Portage rocks. Even with the compiling, it takes less time to install some stuff (eg nmap) than it would take to locate the relevant .rpm. Of course, kde's a different matter, but with distcc compiling doesn't take too long.

    Having said that, it looks like the guys doing the testing got their CFLAGS wrong. Gentoo's performance should never be worse than Mandrake -- I reckon they forgot omit-frame-pointer. Also, the kernel compile is unfair, because gentoo-sources includes a whole load of patches that Mandrake and Debian don't.

    Finally, what's with measuring compile times? How is that a fair way of measuring performance? Hey, look, my distcc + ccache + lots of CPUs system with gcc3.2 can compile stuff faster than your single CPU gcc2 system... It's like comparing chalk and oranges.

    1. Re:Misses the point by ecchi_0 · · Score: 5, Insightful
      Finally, what's with measuring compile times? How is that a fair way of measuring performance? Hey, look, my distcc + ccache + lots of CPUs system with gcc3.2 can compile stuff faster than your single CPU gcc2 system... It's like comparing chalk and oranges

      Except in this case they all had the same hardware on each machine...

    2. Re:Misses the point by arkanes · · Score: 4, Interesting
      The key points to recognize from the article are: a) GNUmeric's performance sucks (8 minutes to open a file? I won't even think about the other version...) and b) that the CPU is not a signifigant bottleneck in modern systems. We all knew that. It's one reason why so many people are happy with binary packages, because the speed increase from saving some cycles generally isn't worth the extra time you lose compiling (as seen, in many cases it makes 0 difference).

      I would have liked to see some tests with things that are more CPU than IO bound, but, realistically, how often do you do those things in the normal case?

      If the main reason is to use portage for the convenience (same reason many people use debian), maybe they need to expand portage to support binary packages.

    3. Re:Misses the point by tweek · · Score: 2, Interesting

      Well in all fairness, ccache only does any good after the first compile. The distcc option however does make a difference.

      I will agree that the biggest thing for me with gentoo is actually being able to strip stuff out of an install with a simple USE flag. I actually prefere to build things myself but having a package management system that takes care of dependencies for that is a godsend.

      --
      "Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
    4. Re:Misses the point by aboyce · · Score: 2, Insightful

      first, I'd love to see a distro be faster than "up2date package_name" or even "aptget package_name".

      Next, they said right in the article that they used an identical copy of the kernel source on each machine, so patches shouldn't make a difference.

      Finally, its not that I dont agree with you, their tests did have flaws, it just seems that some of your facts are wrong in attacking them. There are some points that need to be examined, even if some of their conclusions are premature.

    5. Re:Misses the point by scotch · · Score: 5, Insightful
      Why the hell would you introduce a distributed computing tool in a discussion about evaluating the performance of a single machine/OS? Pure obfuscation. Typical gentoo-missing-the-point behavior. Either compiling the kernel is a fair measure of the speed of the system or it isn't. distcc doesn't play into it. Here's a fun analogy. You want to see which is faster a porche 911 or a chevy corvette. So some thoughtful guys put together a series of tests, one of which is a 1000 mile race. Then along comes user keesh (202812) who says "Bad test, I wouldn't drive 1000 miles, I would take the train."

      A hearty helping of wtf is in order. Some of your other points are ok, though ;).

      --
      XML causes global warming.
    6. Re:Misses the point by countvlad · · Score: 5, Informative

      Portage can be used to install binary (precompiled tbz2 packages of ebuilds).

      From emerge --help:

      --usepkg (-k short option)
      Tell emerge to use binary packages (from $PKGDIR) if they are available, thus possibly avoiding some time-consuming compiles.This option is useful for CD installs; you can export PKGDIR=/mnt/cdrom/packages and then use this option to have emerge "pull" binary packages from the CD in order to satisfy dependencies.

      --usepkgonly (-K short option)
      Like --usepkg above, except this only allows the use of binary packages, and it will abort the emerge if the package is not available at the time of dependency calculation.

      You can also, of course, emerge rpm and install any RPM packages. I'm not sure about debian .deb packages or slackware .tgz packages.

      Gentoo is also accept pre-orders for it's upcoming 1.4 release. Information can be found here, at the Gentoo Store.
      They even have precompiled packages optimizaed for Athlon-XP's - drool!

    7. Re:Misses the point by mickwd · · Score: 2, Funny

      "emerge is faster than up2date. one character less to type."

      Hehehe....and Mandrake's "urpmi" is one character shorter than that.....

    8. Re:Misses the point by keesh · · Score: 2, Funny

      alias e sudo emerge. I win.

    9. Re:Misses the point by antiMStroll · · Score: 4, Interesting
      What's missing in the article is the second half of Gentoo's compile options, the /etc/make.conf USE variables. CFLAGS determines CPU architecture, USE adds or removes the options for extra software support. In stock form Gentoo compiles binaries with a huge number off add-ons, including support for KDE, Gnome, framebuffer, etc. From make.conf: " USE options are inherited from /etc/make.profile/make.defaults." The list from a current Gentoo 1.2 looks like:

      USE="x86 oss 3dnow apm arts avi berkdb crypt cups encode gdbm gif gpm gtk imlib java jpeg kde libg++ libwww mikmod mmx motif mpeg ncurses nls oggvorbis opengl pam pdflib png python qt quicktime readline sdl slang spell ssl svga tcpd truetype X xml2 xmms xv"

      Without knowing what support Debian or Mandrake used to compile binaries, this is still an apple/oranges comparison. My notebook isn't configured to compile with KDE or Gnome extensions because the hardare is too old and I use Fluxbox. Mandrake and Debian may still turn out faster (the Gentoo Mozilla e-build was legendary for being slow), but that's not quiet yet proven.

    10. Re:Misses the point by scotch · · Score: 2, Funny

      'chsh -s /bin/emerge' I win.

      --
      XML causes global warming.
    11. Re:Misses the point by cperciva · · Score: 4, Interesting

      first, I'd love to see a distro be faster than "up2date package_name" or even "aptget package_name".

      FreeBSD Update. Ok, it only upgrades the base FreeBSD install, starting at binary releases, along the security branches; but it uses binary patches to dramatically cut down on the bandwidth usage (and therefore the time used). A typical install of FreeBSD 4.7-RELEASE (released in October 2002) has 97 files totalling 36MB bytes which need to be updated for security reasons; FreeBSD Update does this while using under 1.6MB of bandwidth.

    12. Re:Misses the point by buchanmilne · · Score: 4, Interesting

      Portage rocks.

      If you have a fast processor. My Duron 800 can keep itself busy for a weekend compiling OpenOffice.org ...

      Even with the compiling, it takes less time to install some stuff (eg nmap) than it would take to locate the relevant .rpm.

      This is on my Thinkpad 600X, which is a 500 PIII/192MB, with a pretty slow disk:

      [root@bgmilne-thinkpad mnt]# rpm -q nmap
      package nmap is not installed
      [root@bgmilne-thinkpad mnt]# time urpmi nmap
      installing /var/cache/urpmi/rpms/nmap-3.00-2mdk.i586.rpm

      Preparing...
      #some hashes replaced to fool the lameness filter#
      1:nmap
      #some hashes replaced to fool the lameness filter#
      5.34user 1.36system 0:26.76elapsed 25%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (1712major+8394minor)pagefaults 0swaps


      You would need quite a system to beat 26s I think.

      Also, the kernel compile is unfair, because gentoo-sources includes a whole load of patches that Mandrake and Debian don't.

      From the article:

      "The same 2.4.21 source was copied to all machines and compiled using the same options. However, it should be noted that the Debian system used gcc 3.3.1 whilst the Mandrake and Gentoo installations used gcc 3.3.2 ."

      I don't see the point of:
      -not using the default compiler on the system
      -if you don't use the default compiler on each machine, at least use the same compiler across them all

      But, otherwise, the comparison looks pretty fair.

    13. Re:Misses the point by Vellmont · · Score: 4, Insightful
      I think you're probbably right about the reasons for using Gentoo (though I admit I've never actually used Gentoo).

      However, I think that a kernel compile _is_ a fair measure of overall system performance. It involves lots of disk, memory, and processor access, so it's a decent indicator of across the board performance.

      As far as kernel compile versions go, from the article:
      The same 2.4.21 source was copied to all machines and compiled using the same options. However, it should be noted that the Debian system used gcc 3.3.1 whilst the Mandrake and Gentoo installations used gcc 3.3.2 .

      So the kernel source was the same, not Gentoo source.

      You say the performance problems are because they got the CFLAGS wrong. If this is the case it only seems to underscore how easy it is to screw up optimizations with Gentoo. It's great for people that know all the proper optimizations for a particular piece of hardware, but I think the majority of people just don't know this offhand.

      In any case I find it very interesting the big differences you can see in performance between distributions on the same hardware (and I'm assuming similar kernel versions).
      --
      AccountKiller
    14. Re:Misses the point by lspd · · Score: 4, Insightful

      It definitely is not unless they were using unpatched sources in all three systems. The Gentoo sources applies bunches of patches to the stock kernel which would affect compile time.

      RTFA. "The same 2.4.21 source was copied to all machines and compiled using the same options. However, it should be noted that the Debian system used gcc 3.3.1 whilst the Mandrake and Gentoo installations used gcc 3.3.2"

    15. Re:Misses the point by Sancho · · Score: 4, Informative

      One of my favorite uses for Gentoo is optimizing for size rather than execution speed. As you say, the CPU is rarely the bottleneck these days, but loading files from the disk can be a factor in a program starting up. I've done the benchmarks, and some rather large programs see significantly reduced load times when optimized with -Os.

    16. Re:Misses the point by dougmc · · Score: 5, Interesting
      the CPU is not a signifigant bottleneck in modern systems.
      Are you on crack? Even today, the CPU speed is a signifigant bottleneck for many operations.

      Now, the cpu speed has increased by a larger factor than memory speed and disk speed over the last few years, but it's still quite a large bottleneck in many operations, including the ones tested in this (admitedly lacking) test.

      Even the speed of a kernel compile, which is often given as a classic `disk I/O bound' process, is extremely CPU bound. How do I know? Running `top' on an idle box shows 0% cpu utilization. Once I start the compile, it goes to well over 90% cpu utilization and stays there until the compilation is done. (just to be complete, I'm testing this on a dual p3 700 box with SCSI disks, doing a `make -j2'. But even my 2ghz Athlon computer with IDE disks works similarly.)

      Perhaps I'll do some tests with adjusting the CPU multiplier on a given box, see how that affects compilation times. That would be an excellent test ...

    17. Re:Misses the point by nagora · · Score: 4, Informative
      but, realistically, how often do you do those things in the normal case?

      You obviously don't use GIMP or analyse OS mapping data much. I have the RAM to get the info into memory, IO is not an issue for much of my work.

      Having said that, portage is the main reason I've converted all my machines to Gentoo; it's just not a serious option to go back to RPM based systems after using it for a week or so.

      TWW

      --
      "Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
    18. Re:Misses the point by gibber · · Score: 4, Informative

      Changing the CPU multiplier will not give you what you are looking for as it will likely change your FSB speed and L1/L2 cache access rates. The most common bottlenecks on systems are heirarchical IO bandwidth related. For example, having scads of RAM for buffer/cache will help you with disk IO woes.

      Compiling binaries with optimization for a particular processor help with i-cache and d-cache utilization. The fewer instructions fetched (or the order in which they are fetched) makes a big difference in performance.

      Boosting CPU cache size (up to practical cache limits), increasing FSB speed and avoiding disk IO are much more significant than CPU M/GHz.

      Compilation, especially optimized (-0X) compilation is _VERY_ CPU intense. If you have enough RAM to avoid the disk thrashing caused by writing numerous intermediate files you will peg your CPU.

      Most user activities (aside from games) on computers are not bottlenecked by CPU but by various heirarchical IO constraints and hence the previous poster was correct that the CPU is not a significant bottleneck on modern systems.

    19. Re:Misses the point by arkanes · · Score: 4, Insightful

      You're right, I don't, and neither does anyone else. Even in your case, memory IO is likely to be as much of a bottleneck as the CPU, if not more. One of the reasons the new Mac walks over PCs in Photoshop benchmarks is massive memory bandwidth.

    20. Re:Misses the point by be-fan · · Score: 2, Interesting

      I second that. I don't use Gentoo because I think I can get a minscule 0.5% extra performance by compiling myself, but because of Portage, and the Gentoo community. Portage is awesome, and the source-based nature means that ebuilds come out extremely quickly, and are less subject to distro-specific "customizations" (read: quirks) than binary packages. All the ebuilds BreakMyGentoo.net, as well as the ebuilds posted to the bug tracker are a phenomenal example of how the power of portage allows a relatively small community to maintain a large software library. The Gentoo community is also one of the nicest out there (forums.gentoo.org, rocks).

      --
      A deep unwavering belief is a sure sign you're missing something...
    21. Re:Misses the point by loginx · · Score: 4, Interesting

      I've read the article very carefully and I've also looked at the people who wrote it...

      Real-world benchmarks is a serious matter, I don't even know why this article made its way into /.

      It's rather obvious that those people were not familiar with CPU optimizations and were not thorough with the benchmarking considering they didn't even bother to check for the version/revision of the base package of the distros they were working with even though they do admit that even minor revisions play a considerable role with performance.

      1) What are the version/revisions of GCC on those machines? A package compiled and optimized with GCC 3.3 or even the 3.4 beta will obviously offer much better performance than an old deprecated gcc 3.2 that will be installed by gentoo by default if you haven't set up your ACCEPT_KEYWORDS

      2) What hard-drive optimization did they set-up? Distros like Mandrake, Debian or Redhat set up HDParm optimizations after the first install, gentoo barely does... That would already make a big difference while opening a 32,000 lines spreadsheet...

      3) What are the versions/minor revisions of the Gnome window manager on all those boxes? and GTK? Those packages provide the controls and rendering for Gnumeric... having any difference in these is not fair-play either... (try to install the same version of Gnumeris on a redhat 9.0 and a redhat 7.2 and see if the performance is the same)

      To get back on the example of the sports-car race, this is kind of like benchmarking a porche and a ferrari, but you put diesel in the ferrari and forget to inflate your tires...

      Basically, if you don't have experience using gentoo on a system for a while and know how to optimize your system, don't go and say that the optimizations don't work... they work perfectly well for me but I couldn't see a difference in my first 2 weeks of using gentoo... it's something you have to learn... you can't just install it and pretend the distro will self-optimize for you...it's not even supposed to.

    22. Re:Misses the point by realdpk · · Score: 3, Interesting

      Try -static - on FreeBSD it can improve performance for very fast running binaries significantly (such as ones designed to run 100s of times/s). I dunno about on Linux (although I've noticed that Linux seems to prefer dynamic binaries for everything.)

    23. Re:Misses the point by Deadplant · · Score: 3, Insightful

      CPUs still aren't fast enough for me.
      maybe I'm not representative of 'most users'

      at work I do video processing and at home i play games and encode DVDs to mpeg4.
      Even 2.4ghz cpus take hours to encode entire movies... I can get a little better than realtime encoding to mpeg4, but when you add two-pass, and the fact that the videos are so damn long... I wish i could get a terahertz CPU...

      you try running a 2 pass encode on a 6 hour 720x480 DV video file and then tell me your CPU is fast enough.

      it always makes me chuckle when people say that 'this or that' part of the PC is as fast as it needs to be.
      There all sorts of things we can't do because our systems aren't nearly fast enough.

    24. Re:Misses the point by Arker · · Score: 2, Informative

      Actually I think the key sentence of the article was this:

      The Gentoo setup by Bill Kenworthy was compiled using the "stock" kernel source and the "-march=pentium3 -pipe -O3" compile flags.

      Doh! No wonder it sucked.

      O3 turns on things like inlining that are only worthwhile in certain circumstances, but are often counterproductive. So the results aren't surprising in the least.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
    25. Re:Misses the point by Arker · · Score: 2, Informative

      Seriously though, doubling the access speed of your RAM is likely to do more good on that sort of task than doubling the CPU speed.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
    26. Re:Misses the point by RzUpAnmsCwrds · · Score: 2

      "One of the reasons the new Mac walks over PCs in Photoshop benchmarks is massive memory bandwidth."

      Actually,
      No.

      Canterwood systems have a Pentium 4 with the 800 megahertz FSB and Dual DDR 400. Dual DDR 400 happens to have a total theoretical bandwidth of 6.4 Gigabytes a second, exactly the same as the P4's front-side bus. Plus, the busses are running synchronously so latency is lower.

      The Apple G5 has a 1Ghz FSB and Dual DDR 400. Hmmm... that extra 200 mhz of FSB doesn't really do much, does it? It's still limited by memory bandwidth. Moreover, that bandwidth is shared between both processors in a DP system.

      So, no, the G5 doesn't walk all over PCs in Photoshop because of two reasons:

      - Photoshop is more optimized for the Mac. Adobe designed the filter algorithms to run fast with Altivec and the PPC architecture, therefore, they are inefficent when run on an x86 processor
      - Apple ran the test, and therefore they chose which filters to run with which settings and how many times on which images. Clearly, Apple would choose tests that benefit them. According to their results, they used a 650MB test image.

      Here's why Apple's numbers don't mean shit:

      - They don't give the system configuration of the PCs. Or the Macs. We have no idea if they loaded the Mac with 8GB of memory and left the PC with 256MB. Hell, the default configruation of the Dell system with the 3Ghz P4 is 512MB of DDR - the high-end PowerMac (which they undoubtibly used) has 1GB. So, if they used the systems stock (as I suspect they did), the 640MB Photoshop image they did the test on would fit in memory on the Mac but have to be swapped on the PC.
      - Assuming 32-bit RGBA color on the image, that's a 160 MEGAPIXEL image. Why would they use an image so large? Perhaps it's because it fits neatly inside the PowerMac's high-end configuration's default memory allocation but not the high-end Dell's default configuration. Makes you wonder.

      The P4 with 800mhz FSB has JUST AS MUCH MEMORY BANDWIDTH as the fastest dual G5 system.

      A 2-way Opteron system, on the other hand, has Dual DDR 400 for each CPU. Twice as much bandwidth as the fastest Apple system. Of course, you need a NUMA aware OS to take advantage of this bandwidth.

    27. Re:Misses the point by GlassHeart · · Score: 2, Insightful
      it looks like the guys doing the testing got their CFLAGS wrong. Gentoo's performance should never be worse than Mandrake

      Makes you wonder how many Gentoo users actually get their compiler flags right, doesn't it?

    28. Re:Misses the point by Natalie's+Hot+Grits · · Score: 2, Interesting

      Seriously though, its not. MPEG4 encoding is SERIOUSLY cpu dependant, not bandwidth. Just look at the benchmarks of the opteron vs Pentium4 on 333MHz memory bus and you will see what I mean (in mpeg4 encoding). i'm not saying the opteron is inferior for mpeg4, but the fact that MPEG4 (at least on windows) processing is highly SSE2 optimized for the P4.

      (hint: P4 beats the opteron, even though the opteron has a higher real world memory bandwidth and less memory latency and larger cache)

      Yea, memory bandwidth is the bottleneck in just about everything every day users are doing. But for specific tasks such as video codecs, CPU speed is a huge bottleneck. Moreso than memory bandwidth.

      --
      Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
    29. Re:Misses the point by DrXym · · Score: 2, Insightful
      And it's binary patches which make it such a pain in the arse to keep Linux up to date. Really, everytime someone finds an exploit in glibc or the kernel which involves a few line patch, everyone is expected to download a 20Mb package!


      That's fine if you happen to be broadband but sucks if you don't. In an ideal world, everyone would be motivated to waste the hours to grab the update, but how many bother, especially with the workings of Linux becoming more opaque and the users less knowledgable? The consequence is lot more unpatched Linux machines with all that entails.


      Linux desperately needs binary patch support for this reason. I wonder how hard it might be to do. If someone has RH8 - i.e. a known configuration with RPMs of a certain version, it should be possible to produce incremental patches from that baseline that were a mere fraction of a full download. Instead of a 20Mb download, users would be faced with patches measuring in a few hundred k. Instead of hours to download, we're talking minutes at most. It even opens the possibilty to have an automatic download (and installation) functionality built into Linux, much like that found in MS Windows.


      But MS Windows only uses automatic updates for small hotfixes for the same reason that service packs are humungus. How long before MS produce incremental patches for their OS? Here is the chance for Linux to take the lead for once.

  2. Interesting, but I have to wonder. by Enahs · · Score: 2, Insightful
    I have to wonder what the reviewers consider to be a "default" install. For example, did the reviewers remember to build in support for their IDE controller (if that's what they use)? If so, is DMA enabled for the Gentoo box, and is it for the others? What kernel did they use? Did they use gentoo-sources or did they use another?

    Maybe to the uninitiated this seems informative, but to me it doesn't.

    --
    Stating on Slashdot that I like cheese since 1997.
    1. Re:Interesting, but I have to wonder. by BrookHarty · · Score: 2, Interesting

      My own experience has been that Gentoo outperforms Debian on my hardware, but only after I've done some tweaking on Gentoo. YMMV.

      How true, I wish we had a 3dmark type program for Linux, where we could test X performance in 2d/3d, audio, hd, cpu, mem and even latency for each area. Maybe even report performance and features for OpenGL, to see what the drivers do and dont support.

      A good benchmark program could be used to see if newer kernels are really faster (ie 2.6) or even those nice pre-emptive kernels patches.

      Thats one part lacking in Linux/unix, hardware testing/benchmark programs. Not counting FS benchmarks, there are handfuls on freshmeat.

      Thou, maybe a benchmark program would make Linux look slower to windows in the desktop area. (Any idea?)

  3. Slow? by peripatetic_bum · · Score: 5, Interesting

    Can this be correct. Debian turns out to he fastest?

    Anyway, I like the idea of gentoo, and I saw I a lot of Debian users head over to gentoo because the idea of controlling everything including the build was nice, however, I saw the gentoo idea also pretty much die, since a log of these users are power desktop users and not everyone could wait 3 days for X to build.

    What I like about debians packages is that if you do make a mistake you can always pretty much correct the package by fixing your souce list or goingt o packages.debian.org and getting the older working package and installing it manuaall with a simple dpkg -i old_package.deb.

    In gentoo, you had to rbuild to the whole thing, whihc with x coud take forever. And so what I saw gentoo suddenly doing was having a lot of pre-complied binaries start being provided by gentoo because they saw the problem with building taking forever, and so it kind of killed the whole idea of building for yerself, in which case, if you are going to stick with built pacakged why not have them maintained by some of the best developers around (ie debian)

    The othjer thing I noticed is that a lot of developers of software acutally use debian. I've noticed many a time that some cool software wa being made and the developers wouls provide source and they would provide a debian package and nothting else. Ie Debian appears to be the preferred developer's distro. In this I would like to hear discussion,.

    Thansk all

    --

    Sigs are dangerous coy things

    1. Re:Slow? by antiMStroll · · Score: 2, Insightful
      ....these users are power desktop users and not everyone could wait 3 days for X to build.

      Desktop power users on 386's are a rare breed nowadays. I don't know how long it took X to build on my P2 366 w/ 192 meg RAM because I started it before going to bed and it was done in the morning. Maybe these power users should consider hardware before choosing distros.

      And so what I saw gentoo suddenly doing was having a lot of pre-complied binaries ....

      Lots? OpenOffice has a precompiled option, Opera does because it isn't open-source, but which other packages do you mean? To the best of my knowledge almost all Gentoo packages are still source-based and more than a few have new options to pull the newest source directly from the CVS tree. Gentoo is expanding into more source-based options, not pre-compiles.

      None of this is to say that Debian isn't a better developer's platform, or faster than Gentoo. I wouldn't know, but your post is very misleading.

    2. Re:Slow? by ctr2sprt · · Score: 2, Interesting
      Yeah, I was a Debian user and tried Gentoo when it first came out. I'd used FreeBSD, so I knew and loved the ports library, so I was excited about Gentoo. Unfortunately, the initial releases seemed broken in several severe ways. Half the software in Portage wouldn't compile at all, and I didn't really feel like digging into the source to find out why. I'm not some idiot newbie, I'm a computer programmer and have been using Unix for nearly 10 years. I just wanted the install to work, and it wouldn't, no matter what I tried.

      Anyway, obviously Gentoo has improved since then, but this is a concern of their Portage system (developers accidentally breaking parts of it, and if those parts happen to be gcc, look out!). It happens in FreeBSD every now and then, but it's not as big a deal there since the BSDs use actual releases: the ports are all tested against a specific release and verified to compile, then the ports library is frozen until the next release comes out (which will be tested similarly). So here's a question buried in this rambling anecdote: does Gentoo provide a way of getting "stable" ports, or is the entire OS like the "unstable" branch of Debian?

    3. Re:Slow? by Rhone · · Score: 2, Informative

      Speaking as someone who used Debian ("unstable") for years and switched to Gentoo a few months ago....

      First of all, Gentoo has definitely improved since you tried it. It has worked quite well for me, and I can't recall anything failing to compile. I imagine that if something as significant as gcc were broken, the problem would probably be rectified rather quickly. I worry more about fringe programs that few people are using.

      Anyway, my answer to your question of whether Gentoo is like the "unstable" branch of Debian would have to be "yes and no".

      It's like the unstable branch in the sense that the newest versions of software are easily available to you soon after they are released. It's also like the unstable branch in the sense that you can try out that new software before it has undergone weeks or months of testing with the rest of the system, and like Debian unstable it is best for the geekier crowd who can deal with unexpected problems here and there (I'm being somewhat hypothetical here, because I haven't really had any such problems in Gentoo).

      It's also like Debian unstable in the sense that it's actually usually more stable than the released versions of many of the rpm-based distros. (Though it's been a while since I last used Mandrake or RedHat, so perhaps they have improved their stability as well?)

      It's unlike Debian unstable in the sense that you have more power to fix the problems that may come up (at least problems that can be blamed on the distro and not on the software itself). I felt kind of helpless with Debian unstable when dpkg would choke on a deb. You can't do much (that I know of) to edit an already packaged deb, and getting the src deb to try to find the problem seems like kind of a daunting task for a non-Debian-developer.

      In Gentoo, if there's a problem in an ebuild and you don't want to wait for it to get fixed... well, you have all of the ebuilds right there on your hard drive under /usr/portage. Ebuilds are fairly straight-forward; it doesn't take too long to learn how they work so that you can make simple edits, or even create your own. Also, ebuilds for old versions usually hang around for a while, so if a program is working fine for you and then there's a bug in a new version, you can downgrade easily.

      One of the features I like is that you can put your own ebuilds in /usr/local/portage, and they will be handled gracefully by emerge. And /usr/local/portage takes precedence over the stuff in /usr/portage, so you can use it to replace existing ebuilds in a way that won't be overwritten next time you "emerge sync".

      In Gentoo you are really never helpless.

    4. Re:Slow? by lewp · · Score: 2, Informative

      You very well may know this already, but Daniel Stone has an unofficial apt repository with XFree86 4.3.0 packages. I've been using them for months with great success.

      http://penguinppc.org/~daniels/xfree86/README

      If you just like compiling X, or have some other reason to, forget I said anything :).

      --
      Game... blouses.
    5. Re:Slow? by mcp33p4n75 · · Score: 2, Informative
      Yes. Whether or not you have stable packages depends on your ACCEPT_KEYWORDS setting in /etc/make.conf. Say, you want stable on x86, you do:
      ACCEPT_KEYWORDS="x86"
      Or, you want unstable packages (like me :):
      ACCEPT_KEYWORDS="~x86"
      It's pretty simple, really.
      As some worthless anecdotal evidence, I have never had a problem with the stable packages, and i've been using Gentoo for nearly a year. As for the unstable, most of the problems I have had are build/configuration errors.
  4. FreeBSD's ports by Anonymous Coward · · Score: 4, Interesting

    I don't use Gentoo (When I use Linux, I use Slackware), but I do use FreeBSD and its ports collection.

    Purported performance gains are one thing source packages give you (although I don't enable super optimizations because you never know when gcc bugs with -march=pentium4 -O3 or whatever will bite you).

    There are two major reasons I like installing from source, though. One is that you can customize the build to your system; lots of software packages have various compile time options, and when I have the source I can choose exactly how it's going to be built.

    Another thing is that when you install from source, you can hack the program to your heart's content. On my desktop box there are around 15 programs that I have to modify to get to act like I want (from simple things like getting cdparanoia to bomb immediately when it detects a scratch to halfway complex things like rewriting parts of klipper and XScreenSaver, which now picks a random screen saver on MMB and lets me scroll through all screensavers with the wheel =).

    I don't modify stuff on my servers, but I still get to choose exactly how things are built, which I very much enjoy.

  5. Remember the KDE mandrake/gentoo fiasco? by BrookHarty · · Score: 2, Interesting

    While the posts are starting, and people are saying Mandrake would never be faster. Lets go back earlier this year...

    Remember the KDE optimizations that where not included in the Gentoo source release? Everyone was wondering why KDE was faster on Mandrake. There where talk for over 2 months before people realized it was an option Mandrake was compiling with.

    Myself, Gentoo's biggest feature was the kernal compile options, adding patches for pre-emptive mulitasking, and improved responsiveness. I noticed the improvements on all my machines, but the compile times where a draw back. And sometimes the applications wouldnt compile.

    Mandrake while my favorite choice, doesnt include the best pre-emptive kernels. Which do make a noticable difference. So after installing mandrake, and putting a newer kernel on the system normally takes care of that.

    I'm just waiting till beta2 of mandrake cooker 9.2 with the 2.6 kernels, that should make Gentoo and Mandrake on par for speed.

  6. From a LFS perspective by shoppa · · Score: 4, Interesting
    I don't use Gentoo, but I do use Linux From Scratch, and I do see substantial improvements with command-line type activities: A kernel build on a Athlon is about 20 percent faster when I do it with a custom LFS build vs a stock RedHat installation.

    Most of the comparisons in the article were for X-related graphics applications, and while they were comparing the versions of the applications, they were not comparing the libraries underneath them (glibc, X11, and probably the window manager too come into play) and they should've compared versions there too. It becomes complicated because for a typical X11-based app there are probably several dozen libraries involved (in addition to all the configure-time options for them...)

    1. Re:From a LFS perspective by Sloppy · · Score: 2, Funny
      Unfortunately not all of us have oodles of time on our hands.
      Me neither, but my computer sure does. If it wants to compile stuff when I'm not around or when I'm asleep, that's fine with me.
      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  7. Why use it? by Realistic_Dragon · · Score: 2, Interesting

    I picked Gentoo because it was Free and free, and because emerge has IME one big advantage over APT - one well updated, consistant, all encompasing, repositry.

    OTOH my laptop runs RedHat, because I needed at least one machine running it to stay current with where they dump configs (it's the distro they use at work). Coupled with Apt-RPM it's competent enough, and I have no major problems with the performance.

    So yeah, I have to agree with the article - you may like it one way, others may want to do theit own thing. No matter what you chose, you (probably) have binary compatibility, so who gives a sh!t about the holy wars, just as long as you aren't running Windows :D

    --
    Beep beep.
  8. Gentoo similiar to *BSD? by jtotheh · · Score: 2, Offtopic

    I have never tried Gentoo but I ran FreeBSD for a while. With FreeBSD you have source for the whole system as well as for any "ports" you install. There are procedures for doing a "make world" that recompiles all of it. You can get the source changes to go to the next version and with a bit of chicken and egg stuff about compilers if that has changed, you can compile yourself the upgrade.

    I ended up bagging it because there is a fair amount of stuff for Linux that is missing in BSDs (or I wasn't willing to expend the effort to get to run through compatibility mode). Java, Flash, etc. no flames please, I know some people work these things out - I just got tired of the hassles with it when I could rpm/apt-get it with Linux.

    I thought the FreeBSD was really high quality though.

    Is Gentoo a similiar model? Has someone used both?

  9. The Mindcraft method, against itself by lavalyn · · Score: 4, Insightful

    Besides, before doing any comparisons on Debian vs. Gentoo they should have compared Gentoo vs. Gentoo on different optimizations. Like using -O2, -Osize, -mfp-math=sse. Comparing video drivers. Trying different filesystem types. And a whole gaggle of other configurables at compile-time.

    You'd be yelling bloody murder if Microsoft sponsored a study without doing this sort of research before pitting Windows vs. Linux.

    --
    Doing the Right Thing should not be preempted by making a buck.
    1. Re:The Mindcraft method, against itself by Arker · · Score: 3, Interesting

      The odd thing is that, from what I've read, a lot of Gentoo folk seem to be trying to compile everything with -O3. This is, frankly, bloody stupid. This turns on a lot of 'optimisations' that are only useful on a few programs and actually harmful for most, and is probably one of the reasons it looked bad in this test.

      O1 is the safe level of optimisation. Even O2 runs the risk of doing more harm than good, although it's a fairly low risk. O3 runs a very high risk of doing more harm than good. In many cases Osize is probably the best option anyway, because I/O is more commonly the bottleneck than cpu capability.

      And the processor optimisations can also be risky. Every processor out there is designed to run commercial i386 code as fast as possible anyway.

      The big wins in compiling yourself are control of configure options, not compiler optimisations. I think source-based distributions are a great idea, but I have to wonder if most people using them right now are getting the benefits.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
    2. Re:The Mindcraft method, against itself by Arker · · Score: 2, Informative

      -Os is stupid...
      Just try that on a P4.

      What exactly are you trying to say?

      -Os decreases cache misses, and that's just as important on a P4 as on any other CPU.

      If they really wanted to test performance, they would have used bzip2 -9. I don't even understand what they are testing. Are they testing how long it takes to start an app??? That can depend on where on the disk the files are stored. What a silly test.

      Opening applications is something most users probably do a lot more often than running bzip.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
  10. Re:right now by Rosco+P.+Coltrane · · Score: 4, Funny

    Using it. It rocks. Best Linux distribution yet.

    So are Debian, RedHat, SuSE and Slackware, according to Debian, RedHat, SuSE and Slackware users (respectively). I take it you're a Gentoo fan?

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
  11. Makes an excellent point by JanneM · · Score: 3, Insightful

    There are a lot of issues one can bring up with the test - not identical versions of various software; different X drivers, one distro will have patches missing in the others and so on. Clearly, that greatly influences the results.

    And that is a good point to take home. Optimizing compiles is _not_ the panacea for speed and responsiveness that - a minority, I believe - of source-based distros tend to bring up. There are so many other factors intimately involved in it that any benefits are generally lost in the noise.

    For some specific components, it can be a good idea - but for those, most distros tend to ship several optimized versions that the installer chooses between at installation time.

    Another domain that benefits are specialized, compute-intensive applications; things like simulators or other technical stuff. But then, those apps are generally tweaked and compiled by their users no matter what distro is used anyway.

    --
    Trust the Computer. The Computer is your friend.
  12. You still have dependency hell by grotgrot · · Score: 5, Interesting

    I tried Gentoo for a while and eventually gave up. The problem is that you still have dependency hell. Most packages look for stuff at compile time, and many have optional components. For example a video player may not include support for QuickTime unless the libraries are already on there at compile time.

    So the fun starts when you start installing stuff, they don't include support for other components because they weren't there at compile time, you then discover the missing support, have to install the missing libraries and then recompile every package.

    This is an especially big issue with multi-media stuff, and gets many layers deep as some libraries have optional components depending on other optional components.

    About the only way to guarantee a fully uptodate system is to keep doing complete recompiles of the entire system until there are no changes.

    1. Re:You still have dependency hell by GweeDo · · Score: 4, Informative

      Looks like someone failed to set their USE flag properly. If you have it set right you will get support for all you want. Or if you do "emerge -vp packagname" before doing an actual emerge you can see what optional flags aren't getting used. People that use Gentoo but don't read the portage/emerge/use documents are asking for this. Gentoo isn't for all, it is only for the willing.

      Please go here and reas as much as possible for installing Gentoo so you don't do something stupid.

    2. Re:You still have dependency hell by axxackall · · Score: 2, Informative
      People that use Gentoo but don't read the portage/emerge/use documents are asking for this. Gentoo isn't for all, it is only for the willing.

      I usually say: Gentoo is for users who can read.

      --

      Less is more !
  13. Matches my real world dual-boot experience by Captain+Kirk · · Score: 2, Interesting

    I dual-booted Debian and Gentoo thinking I would migrate completely to Gentoo for desktop use and Debian for servers. Galeon on Debian was way faster. In the end, I got fed up of compiling and re-compiling X and stuff trying various gcc switches. Debian is fast enough to make sitting about wiating for stuff to comlile a waste of time. And apt-get is every bit as good as emerge.

  14. Interesting, but I have to wonder. by Enahs · · Score: 3, Interesting
    For me, Gentoo is a great choice partially because I like the control and partly because I use crufty hardware that doesn't fall into any predefined (read: Intel) category.

    Try using binaries compiled for an i686 on a Via C3-1G, for example.

    Yes, if your entire reason for using Gentoo is to have control over how apps are built, starting from stage3 pretty much defeats the purpose, and yes, if you don't know what you're doing, then rebuilding X can be a real drag. However, I have to say that I appreciate the fact that Gentoo manages to avoid a lot of legal issues by having the user build the packages her/himself. Honestly, I'd love to be Ogg Vorbis-only for music on my computer, but when I own a portable MP3 player, an MP3-capable DVD player, an in-dash MP3 player, and use OS X at work where QuickTime Ogg Vorbis support is dodgy at best, I want lame. And I want lame support built into kdelibs or whatever lame support needs to be built into so that I can drag-and-drop 192kbps ABR MP3s from an audiocd:// ioslave window to my mp3 folder. ;-D

    My own experience has been that Gentoo outperforms Debian on my hardware, but only after I've done some tweaking on Gentoo. YMMV.

    --
    Stating on Slashdot that I like cheese since 1997.
  15. One more thing by Enahs · · Score: 4, Interesting
    From the article:

    Upon testing with hdparm, it was apparent that this machine was having troubles setting above udma2. Eventually this problem was traced to the HD cable, a salutary lesson in the variability of identical hardware setups.

    Very telling pair of sentences.

    --
    Stating on Slashdot that I like cheese since 1997.
  16. Unfair test by periscope · · Score: 5, Insightful

    There seems to be little attention given to the fundamental unfairness of this test presented.

    The distributions were running with different software versions initially and although this was corrected there seems to have been little consideration given to the minor tweaks given to each different installation used. Which services were running on each system? Were the kernel settings identical in use? Were the machines experiencing differences in performance due to the X setup causing X to add different loads?

    etc.

    Fundamentally this test was probably not complete enough to suggest anything in particular. Perhaps it would have been better to boot a single machine three times and perform the sequence of events exactly the same each time as this would have also ruled out some other potential factors.

    Jon.

    --
    http://www.jonmasters.org/
  17. Happy as a wet turtle Gentoo user by GweeDo · · Score: 3, Informative

    I have been using Gentoo for months now and will never turn back. Little of this has to do with performance and 99.9% of has to do with Portage. Package management, dependency checking and the lot are SO great. Secondly is where performance comes in. Without proper CFLAGS you might as well ignore this. On my Athlon XP 2800 I have this:

    CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -mmmx -msse -m3dnow"

    In some simple tests I have done I have seen this as worth while. I have two pages I have created that might be worth a read:

    CFLAGS Guide
    Is -mmmx and such worth it?

    Hope you enjoy these reads.

    1. Re:Happy as a wet turtle Gentoo user by GweeDo · · Score: 2, Informative

      -mmmx -msse -m3dnow That makes sure they are enabled :) - doesn't = turn off. It is actually a bit redundent since my -march flag turns them on anways :)

    2. Re:Happy as a wet turtle Gentoo user by Fnord · · Score: 4, Informative

      Your "Is -mmmmx and such worth it?" guide is a little unfair. Thing is, you notice that only -O3 really made much of a difference. Well, that's because each of your tests is just one big loop and -O3 does heavy loop unrolling. You basically chose the absolute optimal case for -O3 to win (besides possibly having a small function call inside that loop so that -O3 could inline it). And you didn't do any floating point multiplies or divides which is where -mmmx+sse and -m3dnow would help you.

      If anything you were also using a relatively small dataset. If you get a large enough data set (or code size) -O3 might actually hurt you (loop unrolling and function inlining will bloat both code and data size and make it much more likely to have a cache miss).

      Anyways, synthetic benchmarks are one thing but your is so synthetic as to be rediculous.

  18. Re:Remember the KDE mandrake/gentoo fiasco? by mickwd · · Score: 2, Informative

    It's not part of the main distro, but there is a kernel-multimedia-2.4.21.0.16mdk-1-1mdk.i586.rpm in Mandrake contribs. Check it out if you want a more responsive kernel.

  19. Ob. Translate-o-matic post by tempest303 · · Score: 4, Funny

    Here you go, the obligatory Gentoo Zealot Translate-o-matic reference!

    Enjoy!

  20. Photo views a little skewed? by SassyDave · · Score: 2, Funny

    Does it seem strange to anyone else that in the linked photo gallery, the only picture with a female has been viewed 3 times more than any of the other pictures?

    Sheesh.

    I guess there's just not much scenery to show off at distro day.

  21. ...and 11 hours later: by Anonymous Coward · · Score: 2, Funny

    OpenOffice.org!

  22. No. Gentoo is not a performance leader. by 0x0d0a · · Score: 5, Interesting

    Having said that, it looks like the guys doing the testing got their CFLAGS wrong. Gentoo's performance should never be worse than Mandrake -- I reckon they forgot omit-frame-pointer.

    Omit-frame-pointer is not a regular optimization. Working without stack traces to hand to a developer if you have a problem isn't really a reasonable optimization unless you're doing something like an embedded system, where you couldn't get at the stack trace anyway.

    This is *exactly* what the real tech-heads have been saying for years, what my tests confirm, etc. A minor change in a couple of compile flags above -O2 almost *always* makes very little difference. Compiling your own packages really just plain doesn't matter. Maybe if gcc really was incredibly tuned to each processor, but certainly not with the current compiler set.

    Also, the kernel compile is unfair, because gentoo-sources includes a whole load of patches that Mandrake and Debian don't.

    And perhaps the inverse is true, too?

    Look, the point is, Gentoo is not significantly faster than any other general distro out there. If you use it, it's because you like their tools or packaging scheme. You aren't cleverly squeezing out more performance.

    Oh, and last of all, I've seen compiler folks saying that it's not that unusual for -O3 to perform worse than -O2. When I was taking our cache performance analysis bit in university, cache hits and misses really *is* the dominant factor in almost all cases. Loop unrolling and function inlining can be a serious loss.

    Finally, compiling for different architectures generally makes very little difference on any platform other than compiling for i586 on a Pentium. The Pentium runs 386 code rather slowly. The PII and above will happily deal with 386 code.

  23. Catch 22 by Alethes · · Score: 4, Insightful

    It seems that the people that would benefit the most from a source-based distro and optimizing binaries specifically for their hardware are the ones with the slow hardware that will take too much time to get everything installed for it to be a worthwhile investment of time.

    1. Re:Catch 22 by stang7423 · · Score: 2, Interesting
      For those of you installing gentoo on slow hardware here are your installation instructions:

      1. %emerge system
      wait 24 hours...
      2. %emerge "all packages you want"
      wait 24 hours...
      3. Profit ??? your system is complete.

      For those of you that say compiling on slow hardware isn't a worthwhile investment of your time, stop watching every line of code compile. Your computer is a big boy and he/she can operate for hours on end without you looking over its shoulder.

  24. Re:Remember the KDE mandrake/gentoo fiasco? by Enahs · · Score: 2, Interesting
    0 is where it should be. Other distributions run X at a higher priority to make up for "vanilla" 2.4's crappy interactive performance. Once 2.6 is out, this won't be an issue anymore. Also Gentoo's gaming-sources and ck-sources (my personal favorite) have optimizations built in that improve interactive performance greatly, eliminating the reason for running X at a higher priority. Some people report having problems with X running at higher priority; I never have (some people have problems with soundcard starvation, among other things) but then again I don't have to worry.



    To be fair, I'm running RH9 until sometime tonight (have a chrooted Gentoo build waiting to be installed) but I'm running a Planet CCRMA kernel, which includes a number of the ck-sources patches.

    --
    Stating on Slashdot that I like cheese since 1997.
  25. No distro is the king for "developers" by 0x0d0a · · Score: 2, Insightful

    Yeah...my PII/266 definitely takes less than 24 hrs to build X.

    That being said, I'm dubious that blowing the time on compiling your ftp server with all optimizations every time you download a new version really is a worthwhile use of time and effort.

    Maybe xmame. Maybe glibc. Maybe the kernel. That's about it. Definitely not 99% of the software on the system.

    I don't really think any one distro is much better than the others for development. I happen to use Red Hat, which I do plenty of development on. I have a friend that uses SuSE and Mandrake, and another that uses Gentoo and Debian. All of us write software pretty happily -- all the tools we need are packaged or easy to build for whatever system we want to use. Most folks that I've seen that dislike a particular distro just plain don't know how to use the tools on that distro. I've liked just about every one I've tried, though they all have little things that one does better than the others -- RH shouldn't have shipped gcc 2.96, SuSE should put version numbers in their RPM names (actually, I believe they do these days), SuperRescue should be updated more often.

    Heck, the vast majority of Linux users, not so long ago, *were* developers. By that metric, SuSE, Debian, and RH would be the most favored developer distros, though I doubt that contains one iota of useful information. :-)

  26. Default Install = Stage1? by aSiTiC · · Score: 4, Insightful

    I didn't see anywhere in the story if the Gentoo installation was done from scratch stage1 or from stage3. I would think this would be a very important piece of information to mention.

  27. The Things that Really Matter in a distro by 0x0d0a · · Score: 4, Insightful

    It's not worth it. Moving from distro to distro for performance is pretty ridiculous.

    Here's what I'd consider, since this is where the biggest differences lie:

    * How frequently are new releases announced? Frequent new releases may be better for hobbyists, but a pain in the ass for servers sitting in a back room somewhere. (It's the reason RH can see an enterprise edition that's simply not released as frequently).

    * How do you like the packaging system? Try out apt, emerge, up2date (actually, don't -- up2date truly sucks. Everyone using RH who cares about automatic updating has long since started using apt or (IMHO, better) yum).

    * How do you like the config system? Most vendors have their own interface to let you configure the system. RH used to use linuxconf, and is now using Redhat-config. SuSE uses yast.

    * How much do you care about commercial support? A few widely used distros tend to get the only commercial support. Mandrake gets a little, but if you're going to be running packages that require support (especially binary-only), you're probably best off with Red Hat.

    * Which desktop environment do you want to use? Mandrake puts more work into KDE on their system, Red Hat into GNOME.

    Arguments about speed or features is really pretty meaningless -- common software is generally packaged for most of these, and rare software for none (use checkinstall to *make* packages -- you'll be much happier). It's still Linux with the GNU suite present.

    People that switch from distro to distro (or maintain *multiple* distros on their machine) are nuts, IMHO. It's a fair amount of work to relearn the quirks of each

  28. Those cflags are nowhere near optimized by SiliconJesus101 · · Score: 2, Insightful

    Looks to me like they compiled using pretty much generic flags. As an exaple, my cflags are as follows: CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer -fprefetch-loop-arrays -falign-functions=4 -funroll-loops -ffast-math -fforce-addr -mmmx -msse -msse2 -mfpmath=sse,387" Also, we may have to question their ability to properly compile a kernel. Possibly they did a generic kernel with everything but the kitchen sink thrown in. The idea of Gentoo is that you compile the kernel for YOUR system and not generically.

    --

    "The strong will do what they want, the weak will do what they must."
    -Thucydides

  29. I beg to differ subjectively by marienf · · Score: 3, Insightful

    Although I never actually *measured* anything, I have been moving all my boxen (except for one Duron on which I have found it quite impossible to compile Gentoo) to Gentoo 1.4rc4. I was actually in the process of building my own compile-in-place GNU/Linux called "Q-Gnu/Linux" when I discovered Gentoo did it all, and did it better. I was all RedHat before that (going so far as to wear a red fedora on parties - I have two of those). I find Gentoo as opposed to RedHat quite impressive, at least. My professional workhorse (on which I'm currently typing) is a Toshiba Satellite Pro 4300:

    model name : Celeron (Coppermine)
    stepping : 3
    cpu MHz : 597.077
    cache size : 128 KB

    ..with 384MB RAM.. and was becoming annoyingly slow in things requiring major GUI complexity, like OpenOffice, and at compiling many Java classes.

    Compiling Gentoo on there allowed the machine a third chance at life, the second one being when I got it (already old then) and installed RedHat on it, over that would-be-OS it came with. It just feels that much faster again. I am no longer annoyed by it at all. It took more than 4 days to compile all I wanted from the Gentoo 1.4rc4, but it was *well* worth it.

    I moved my personal little server, an Athlon Thunderbird, with the same impression. Currently running

    emerge system

    on my brand new Athlon XP 2600, expecting much from it.

    Bottom line: Nothing but Kudos for Gentoo, wondering what went wrong during the tests described, or whether somehow the subjective speedups I have experienced are just auto-suggestion. I think not. I have been staring at CRT's since 1980, thats 23 years folks! And I tell ya compiling stuff yourself is worth it. So if you have time on your side, go for LFS, which I did, and slowly ground into Q-GNU/Linux. If you have some time, but not *that* much time, go for Gentoo, if you have no time, you poor shmuck, either get a life, or install SuSe :-), and pretend.. :-) :-)..

  30. Re:right now by 0x0d0a · · Score: 4, Insightful

    If you invest a lot of time in learning a distro, you're terrified that it might not be the best, and will spend ridiculous amounts of time insulting the others.

    Hence, the distro wars.

  31. Re:Remember the KDE mandrake/gentoo fiasco? by buchanmilne · · Score: 2, Informative

    Mandrake while my favorite choice, doesnt include the best pre-emptive kernels.

    You mean like this one (from contrib for 9.1)?


    Name : kernel-multimedia-2.4.21.0.16mdk
    Group : System/Kernel and hardware Source RPM: kernel-multimedia-2.4.21.0.16mdk-1-1mdk.src.rpm
    L icense: GPL
    Packager : Danny Tholen
    URL : http://www.kernel.org/
    Summary : A preemptible Linux kernel, which reduces the latency of the kernel.
    Description :
    This kernel includes patches useful for multmedia purposes like:
    preemption, low-latency and the ability for processes to transfer their
    capabilities.
    The preemtion patches allow a task to be preempted anywhere within the kernel,
    using spinlocks as markers for non-preemptibility regions. The resulting
    system response is greatly increased, with measured average latencies under
    1ms. Andrew Morton's low-latency patches fix the remaining points in the kernel
    that cause latency. The setpcap patch allows suid root processess to transfer
    capabilities to non-root processess, and so making it possible for user
    processes to run with realtime priority.


    [some uninteresting fields removed in aid of the lameness filter]

    The next one for 9.2 contrib will most likely have the O(1) scheduler also.

  32. This article is flawed... by eWarz · · Score: 4, Insightful

    They optimized Gentoo for the p3 platform? Celeron 1.4 ghz and above is based on the p4 core.

  33. Re:Remember the KDE mandrake/gentoo fiasco? by trashme · · Score: 2, Informative
    Myself, Gentoo's biggest feature was the kernal compile options, adding patches for pre-emptive mulitasking, and improved responsiveness.
    Ahem. I'm guessing you are talking about the preemptive kernel patch. Linux, and every other modern OS, already have preemptive multi-tasking. Preempting the kernel is different from preemptive multi-tasking.

    Preemptive multi-tasking just means that a process can be interrupted at any point and another process, or the OS, can make use of the CPU. Preempting the kernel means that actual kernel code can be interrupted.

    There are other distributions that include kernel patches as packages. Debian, for example, let's you patch your kernel with a compile option passed to make-kpkg.
  34. Moore's Law by nagora · · Score: 2, Insightful
    The time to install from source halves every 18 months. Already, entry-level systems can compile a Gentoo desktop system up from stage1 to everything-except-OO in a day (and OO can be installed as a binary) and a server can be up and running in a couple of hours so compile time is not a big deal and gets less so every day.

    Given how much better Portage is than any of the other management systems, I'd say Redhat is going to suffer big loses at the hands of Gentoo (Debian would too but the effect will be drowned out by the damage Debian is doing to Debian).

    So far I've converted six machines to Gentoo, all from Redhat because I couldn't face upgrading with RPMs anymore.

    TWW

    --
    "Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
  35. Re:Mod this up by archen · · Score: 2, Insightful

    "I'm a real Linux user because I don't use Redhat or Mandrake"

    I think that additude is more because those distro's tend to hide a lot of the fundamental parts of really administering a Linux box. Mainly because there seems to be a growing ammount of people who can use Linux, and perhaps even get around okay, but have never even compiled/installed from source before.

    In some ways it is an elitist additude, and in some ways it's sort of a valid concern. It's also a problem because there's a lot of nice software out there with no binary form (rssh as one example). Not that it's hard to check an MD5, and read a readme file - but some have never done it and you wonder what other areas they're probably lacking in understanding as well. Like a windows admin who's never used regedit - using it may not be neccesary on a regular basis, but not knowing how to use it is probably shifty at best.

  36. Re:I use Mandrake..... by Sloppy · · Score: 2, Interesting
    The reason for getting away from RPMs is when you see some software that you want, download the RPM, and you can't install it because it wants some other RPM that you don't have. Or worse, it refers to an RPM for a package that you do have, but it's a different version.

    If you don't have that problem, then stick with what you have. Your life is good. Be happy.

    (Back when I used Mandrake and Red Hat, I had that problem all the time and it was very frustrating.)

    --
    As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  37. CFLAGS detection script by cosjef · · Score: 2, Informative

    Here's a script that helps you determines which CFLAGS are compatible with your CPU:

  38. Re:Diminishing returns by Rhone · · Score: 2, Insightful

    So when does the time taken to compile the app with extra optimizations exceed the time you save on tasks performed in that app?

    Does it matter when you're letting stuff compile overnight, or while you're at work/school/whatever? Or in the background during times when you're doing something that isn't CPU-intensive?

    I mean, it's not like Gentoo users sit in front of their computers twiddling their thumbs, just waiting for a compile to finish before they can move on with their lives.

  39. So is linux by r6144 · · Score: 2, Interesting

    Especially when you link to a lot of libraries, dynamic linking can often take a lot of milliseconds. Prelinking helps a bit, but static linking is the fastest. On my machine running a simplest program takes 5ms when dynamically linked, 3ms when statically linked, "user time" is 1.1ms vs. 0.4ms.

    1. Re:So is linux by pantherace · · Score: 2, Informative

      prelink can help with this. google for it and you should find out about it or look on gentoo.org under the docs section. Prelink support is built into portage :)

  40. Working with debs. by dmaxwell · · Score: 2, Informative

    debs are actually renamed ar archives that conform to a specification and have been renamed. I have come across guides on unaring a deb,altering it and then packing it back up. I've never had to do it but the guides on how to do it didn't seem too bad.

    I've never had a dependency problem I couldn't fix in Debian with a little noodling around with the system. On the other hand, I do sometimes recompile source debs to get options that I need. For instance, I deploy Netatalk with dhx authentication. I have to install the crypto devel libs and tweak the rules file to get it. Thankfully, I can build on one box and deploy the custom deb whereever needed.

    I suspect that I could get most of the benefit of Gentoo by rebuilding the kernel, glibc, and maybe the xlib source debs with i686 options. At some point, I would like to see where the most benefit is reaped from custom compilation.

  41. All this really shows is that these were bad tests by oobar · · Score: 4, Interesting

    When I see things like the program time going from 39m 08s to 11m 21s (when all that was changed was a minor version number) that just screams -bad testing-.

    You should repeat every one of the tests a number of times, and make sure that you get the same (or similar) results each time. You should not NEVER expect a 4:1 ratio of performace doing the exact same task on identical hardware. Bells should be going off that say "casual testing" when you see something like that.

    Besides, there are so many variables that have to be kept the same between the different installs - which services are running, how they are configured, what kernel options are set, what patches have been applied to the kernel, which modules are loaded... If you pick up Redhat 9 and do a "kitchen sink" install, you will hardly have the same amount of free RAM for caching, etc. compared to doing the "regular" install of some other distro that leaves out things. Hopefully it's obvious that such a comparison that would not be fair at all.

    In short, you should take a given kernel source, with a fixed set of patches, options, settings, modules, etc., and complile it with the default i386 options and then a second time with all the fancy optimizaions, then compare those. LEAVE EVERYTHING ELSE THE SAME! Repeat with glibc.

    The results in this article are just pathetic. They vary all over the place and are crying out for more rigorous testing methods and procedures. Making a good test is really a science, you have to design the test to specifically measure what it is that you're interested in. For all we know one of those tests could have already had a majority of the libraries loaded into the disk cache, resulting in the huge performance differences.

  42. And pentium 4 by r6144 · · Score: 2, Insightful
    I have heard that P4 runs code compiled for i386/P2/P3 rather slowly compared to code compiled for it. For example, P4 runs traditional (stack-based) FPU instructions rather slowly, while it prefers SSE/SSE2-based instructions. Therefore on P4 systems compiling with the right options may well give a significant speed boost.

    However, AFAIK PPro/P2/P3/Athlon runs these "legacy" code quite well, so relatively little gain can come from compiler option tweakings.

  43. Re:No. Gentoo is not a performance leader. by hoddi · · Score: 2, Interesting

    Once I set out to prove that wrong. My test was purely cpu bound, to see the real benfit from the omptimization. I have since lost my resaults ... but you can do it yourself ... Here is what I did time cat /dev/kcore | gzip -f > /dev/null My resaults showed that whith correct optimization I would gain upto 10% increse in throughput. But, in the real world, the gain would be less.

  44. Define 'same' by The+Monster · · Score: 4, Insightful
    Except in this case they all had the same hardware on each machine...
    That is frankly impossible. Even though the machines were supposed to be identical:
    Upon testing with hdparm, it was apparent that this machine was having troubles setting above udma2. Eventually this problem was traced to the HD cable, a salutary lesson in the variability of identical hardware setups.
    This is just the difference they caught. Who knows how many other subltle variations exist between nominally identical machines? An honest attempt to determine how fast 3 distros do the same thing would be to really use the same hardware, by running the tests on one or more machines with one distro, then wiping the HDs and installing the second and repeating the tests, then on to the third.

    The only way to have the same hardware is to use the same machine for each distro. Period.

    --

    [100% ISO 646 Compliant]
    SVM, ERGO MONSTRO.

    1. Re:Define 'same' by VPN3000 · · Score: 4, Informative

      Agreed. Back when I was a hardware tech in the early 90's, I recall building pools of identical machines for customer orders. For burn-in, I would loop benchmarks for 24 hours before shipping them out. There was typically 1-2% difference in identical systems.

      People tend to forget the complexity of a PC and the inevitable, microscopic differences each part made. Thus differences in resistance, heat generated, and performance.

  45. Re:right now by _Knots · · Score: 3, Insightful

    Of course, some realize that distros are good at different things and don't (seriously) insult any of them.

    I use Gentoo on my two main boxes, simply because I toyed with it and haven't found a good reason to switch away yet (two just so I have the same environment on my two main machines). That said, my router runs Debian-testing. I maintain Mandrake machines at work, know my way around a RedHat machine... etc. My 486 ran Slack 8 while it was up. My DECStation runs NetBSD (though that's a different issue entirely).

    I catch flack for using Gentoo, RedHat, Mandrake... my point is, it doesn't matter at all. Use the right tool for the job - that's what open source, and moreso just diversity in the computing environment, is good for! As long as everything speaks TCP+UDP/IP, who cares? ^^

    --Knots;

    --
    Anarchy$ dd if=/dev/random of=~/.signature bs=120 count=1
  46. If you're going to address the benefits... by GMFTatsujin · · Score: 4, Interesting

    The major benefit for me was that Gentoo was the first distro I'd used that gave me the slightest clue about what the operating system was doing, and how the software worked.

    I'd tried RedHat, Mandrake, and a few other distros that set everything up for me so I could "just use it." The problem was that in just using it, I had no idea what I was trying to use. I would go looking for software to do x, y, or z, and I'd either find nothing that seemed to do the job, or a jillion different apps that all did the job differently, and I didn't know why to pick one over the other. Add to that the sense of being at the wheel of an out-of-control car every time I wanted to make a change to a .conf file, and my Linux experience was pretty frustrating.

    Gentoo was a brilliant introduction into how to install a Linux-based OS. It started me off easy -- here's the command line, here are the commands to install the system, here are the .confs you can tinker with and what they do. It gave me flexability while keeping the results trim. The USE flag is the most amazing option I've ever seen.

    Installing Gentoo was more like playing with LEGOs than installing a system, and when I got done with it, I had a computer that I knew, really *knew*. I knew all the init.d services and what they did. I knew what module was controlling what hardware in my kernel *and* how to fix it if it didn't detect properly. I knew all the apps installed, even by their weird names and locations, and I knew what they were there for. I knew it because I built it that way. And I never had to hunt down a dependency or resolve a version conflict. NOT ONCE. Redhat and Mandrake just installed this mysterious Linux Stuff and threw the computer back at me when done. Gentoo got my hands dirty with building it up, but didn't make me jump through hoops to do it.

    The benefit was teaching me what my computer was doing when I used it.

    *THAT* is how I wanted my computer to run. And it does. Thanks, Gentoo team!

    GMFTatsujin

  47. Enough Already... by khyronmaetel · · Score: 5, Insightful

    Ok, I'm a gentoo user. I'll admit a sizable percentage of our ranks dont know what they're talking about, i'll even admit that most distro "speed" is in the users head. But most of you are missing the point. Many gentoo users (including myself) installed gentoo as an ongoing learning experience. Sure, there's really no difference between the "l337ness" of typing emerge foobar and typing rpm -ivh foobar. But those of us who have taken the time to understand the portage system have learned a great deal. As an aspiring programmer, this was my distro of choice because it enabled me to learn about gcc. Also, i like the idea of (although most install standard packages) being able to beta test bleeding edge applications. While there are a lot of phoney gentoo users who are under the impression that theyre furthering the opensource movement by emerging packages, gentoo's backbone a highly active community of volunteers who are really interested in Open Source. Basically, all i'm trying to say is that any idiot can probably get gentoo installed and working, but the real point is to understand the OS that you've built, and i've found that gentoo helps me and others do this better than package based distros.

  48. Re:No. Gentoo is not a performance leader. by 0x0d0a · · Score: 5, Interesting

    Look, Squinky86. I'm not simply pulling this out of my ass. I've had to cover this back in university. I'm not a gcc developer, but I have sat down and gone through generated assembly from the compiler, and have spent many hours tweaking software in every way possible to make it run at a reasonable rate on my old P2/266. There are a very few pieces of software for which arch flags make a measurable difference (as a later poster noted, gzip is one). As for individually specifying flags, I'd be facinated to know what you're trying to use above -O3. You can use -ffast-math. It's unlikely to provide particularly useful results. Approaches like this have been done for a long time (see libmotosh on the PowerPC) -- they can cause the rare, PITA to find problem, and any libs or programs that really need the speed increase have probably done custom work that's even faster than anything you're going to pull with ffast-math (libfftw, for instance). You *might* get some performance gains on povray...but most folks I know compile povray themselves anyway, since it isn't packaged by, say, Red Hat. -fstrict-aliasing is a *very* balsy flag to use if you haven't actually written the software yourself. It's a pretty safe bet that building a lot of unknown software with -fstrict-aliasing will break it. There's a good reason strict aliasing is off by default -- valid C programs (easy ones to write, too) will die with this option, occasionally and in odd ways. You're a damned fool if you use this on *any code* that you did not write or explicitly says that it was written to allow this optimization. I just finished talking to an optimizing compiler designer Thursday who reinforced my feelings about aliasing-dependant optimizations -- they're almost always a bad idea, since the small speedup isn't worth the random problems that you can very very easily induce. -fomit-frame-pointer can produce a small benefit, but surprisingly small, and makes tracking down any crashing bugs or requesting help with a crashing bug infeasible.

    If you know how to and properly configure your compiling flags, the speed gains are tremendous

    Bullshit. The vast majority of software I've run benchmarks on will never see less than a 10% performance gain (and that's being *very* generous...most will see no measurable change) with anything other than the default -O2 or -O3.

    Oh, hell. I was a lot like you not so many years ago, sure that I could speed things up if I just found the right ways to manipulate the code. The only cure for it is actually sitting down and benchmarking things yourself, since you're sure that everyone else is doing something wrong.

    Go ahead, you'll see what I mean. Try building libs that tie up a lot of CPU cycles in multiple apps like libjpeg -- that's where you're going to see your best payback for any optimizations. Time a couple runs.

    but if you just try gentoo, the learning experience and speed gains are very noticeable.

    I think I've adddressed speed gains. As for learning experience, Gentoo is not synonymous with compiling software from source (from that standpoint, Slackware and similar distros blow Gentoo away). I've never bought into the "learning experience" claims -- let folks start out on the GUIs their distro maker provides, and then, regardless of distro, you can quite happily find out what's going on.

    This is not to say that I don't think Gentoo is a worthy distro. I'm a bit of a package management aficiado, and emerge certainly interests me. However, the kind of sweeping claims I see the occasional Gentoo user make on Slashdot are ridiculous. The general-purpose Linux distros are all fairly close together. Distro fans tend to be produced when someone fails to understand how to properly use a different distro (or got accustomed to one), or has sucked down some false claims from other folks, or just don't want to consider that the distro they've sunk lots of time into learning isn't far better than any other choice.

    Now, if you happen to like Gentoo, go for it. But like it for the legitimate reasons, not inflated false ones. Don't make exaggerated claims WRT to it, because misinformation certainly doesn't help out Linux folks in the long run.

  49. Learning by xRelisH · · Score: 2, Insightful

    I must say, that Gentoo is a great Distro for actually learning some of the things of the Linux environment.
    Gentoo was/is my second distro (I tried redhat first), I was intrigued by the idea of doing everything from almost scratch.
    Starting from Stage 1, I was able to learn quite a few things that I probably would not have learnt till some time if I had not decided to do a Gentoo Stage 1 setup as you're somewhat forced to learn the basics and have a fairly good foundation to go learn more stuff yourself.
    Although I am sure there are other distros out there (including linux from scratch, if that's even technically a distro ) that are like Gentoo, but I find it to be a rather good Distro.
    However though, I may decide some time from now to try the "from scratch" route, and perhaps learn even more. Although, I think the think that will keep me with Gentoo, like others have said is Portage, I think it would be great if there was a well maintained Portage-like system for any distro, as a piece of software, even though it's probably possible to get portage working on other distros, but probably not without some major tinkering.

  50. Let's take a look at your claims by 0x0d0a · · Score: 4, Interesting

    They need a hardcore gentoo optimizer in there for the gentoo box, someone that knows what they're doing....Hence, I say the person doing the gentoo install is NOT informed on optimizing gentoo and thus renders this test invalid.

    [sigh] Nobody ever listens to me [Dark City].

    Okay, let's take a look at how informed you are. First of all, -mathlon-xp implies -m3dnow, -msse, and -mmmx. -O2 or -O3 is default already on most systems. The only differences -O3 produces is -frename-registers (which does essentially jack on the x86 line) and inlining (which tends to produce very minimal or negative benefits, given the fact that cache misses (which this aggravates) are far more of a timesink for most programs than setting up and returning from function calls). -pipe produces no runtime benefit, though I leave it in my own flags. -fforce-addr, -frerun-cs-after-loop, and -frerun-loop-opt are implied by -O2 or -O3 already. -falign-functions=4 is considered a slowdown for the Athlon line by the gcc team relative to the default (64 on current gcc). I haven't tested -maccumlate-outgoing-args, and I'm not familiar with what it internally does -- the only benchmark I could google for indicated a slowdown caused by it. -ffast-math is a decision of dubious value. Very little code uses floating point math, so ffast-math rarely has an effect. The code that does and actually cares about this degree of performance generally has native implementations that are faster than -ffast-math, since they're special-cased. This can cause software breakage. (We already saw the realization that these sorts of optimizations are of dubious value with Motorola's LibMotoSh for the PPC). -fprefetch-loop-arrays is implied by -O2.

    The overwhelming majority of code does *not* have an #ifdef __SSE__ with alternate code.

    Basically, the only seriously useful flag you used is that which all distros use -- -O3 (and I generally feel that -O2 is a better choice on modern processors, where cache is so critical). -march=athlon-xp can help, but it's unlikely to make a measurable difference on any but a very few pieces of software. Most distro vendors already benchmark and ship versions of software that benefits with a different arch -- look at RH's different RPMs. -fomit-frame-pointer is arguable -- but you're going to probably see *well* under a 10% performance difference, and you have no ability to track down crashing bugs or send in useful bug reports. -ffast-math can cause breakage, and provides little benefit for almost any package (one exception is povray -- it's a floating point heavy package that tries to be portable). I custom-build povray, but then RH doesn't package povray anyway, so that's not too much of a concern.

    Anyway, my point is not to criticize you. I spent my days with a three line CFLAGS string as well, sure that I was producing nicer and better code than anyone else. Then came my benchmarking days and a compiler class and some days picking apart gcc-generated assembly...and I realized that I really wasn't gaining anything.

    If you like Gentoo, do it for the legitimate features that it provides (like emerge), and not for some fanciful performance improvements.

  51. Valid tests, not likely; Gentoo's real calling. by mindmaster064 · · Score: 2, Insightful



    While it really isn't likely that Gentoo is more than 10% faster than other systems in any given operation there are reasons I don't feel these numbers reflect anything.

    First, the tests fail to mention kernel versions they're running or the filesystem of the machines (which has a big impact on processing efficiency, different fs being better or worse at different things) and they didn't even mention what version of X11 or gnome they're even running on these boxes. Are we testing Gentoo? Gentoo is portage, gentoo-sources (and the other modified kernels), ebuilds, prelink, evms, XFS, and a host of other features the others simply don't have.

    Second, no comparisions are made on i/o bound tasks (reading/writing/copying files). Things that do not stretch resources in linux may simply be preempted out of importance. (Linux puts higher priority on a soon-to-be-overstuffed disk buffer than the display/computation of a spreadsheets). It would be hard for ANY of these distros to even compete on i/o bound tasks mostly because of Gentoo's EVMS or XFS options. EVMS is simply the best Software RAID I have ever used. XFS seems to be one of the filesystems of the future as well due to it's i/o guarantees, journalling, and sickly-disgustingly-large filesizes.(I feel the jobs XFS will do simply cannot be done by anything else at this point).

    Thirdly, another advantage is simply not having 3-4 disks worth of iso install that you will NEVER need. Mandrake and Redhat (though not tested here) are completely bloatware. They don't install what you need and work properly, they install EVERYTHING or work poorly (because the distro makers hide some silly dependencies). Gentoo's "emerge -p packagename" is a whole hell of a lot friendlier. But, if you don't use the deep options it's possible to lose a lot of the "roll your own" advantages. Gentoo is subject to a high degree of user stupidity, it is possible to negate all of the advantages of source-based distro simply by being careless.

    Lastly, Gentoo's major advantage -- it's best.. the Gentoo users! That's right. Gentoo's forums are so good (and full of know-how types) that put virtually any goofy problem you can think of is within searching distance. I simply have found Gentoo's support forums probably the best repository of linux information on the net. I don't say that lightly either. Something to be said about being able to get problems resolved quickly and correctly -- and having it at your fingertips. I like to go to one place for answers, and likely you do to.

    As you can see, it's very hard to get a good feel for what Gentoo is by reading that review. I would encourage any techie freak to take her for a test drive. It's not for everyone and not even for most, but it's still a very different experience in comparison to other linux distributions. (I have used Redhat, Mandrake, and switched to Gentoo -- I have not had any need or thought of moving to something else; my own 2 cents).



    -Mind

  52. Re:No. Gentoo is not a performance leader. by 0x0d0a · · Score: 2, Informative

    Also, I don't recomend Gentoo for most users- I am not a fanatic, I just like configuring things myself so when something messes up, there's only one person to blame (go slackware!).

    I'm all for folks recommending things they enjoy. The only thing that upsets me is the repeated number of Gentoo users that come on Slashdot or Usenet and make claims that simply are not true about the benefits distro. I see a *ton* of Debian fans pushing their own distro, but usually it comes down to someone claiming an ideological difference or liking the distro's packaging policy -- you don't see a bunch of claims that Debian is much faster or more stable than other distros. It hurts all Linux folks to have a lot of false information floating around, and it really doesn't do Gentoo any more good than it does to have Linux folks making outrageous claims about Linux's capabilities.

    What you should note is that there ARE performance gains, though slight.

    [shrug] That's probably true. -fomit-frame-pointer, at the least is pretty sure not to hurt you aside from the inability to debug.

    I didn't know there were this many gentoo-haters out there, but I definitely see only good things from this distribution. No need to bash it nor me. That's getting a little childish.

    I don't think I was bashing Gentoo -- I specifically said that it was a "worthy distro". I may have been slightly harsh towards you, simply because of my frusteration with the behavior of a large number of Gentoo users on various forums, but I don't think it was particularly out of line, and I pointed out that I've been in the same boat WRT compile flags.

    What I was saying was Gentoo is definitely a distribution to try for new and intermediate users to get to know how their system works and what can be done (e.x.- what services are unneeded) to speed it up.

    [shrug] I'm not saying it's *bad* for them, though every distribution I know of (well, I don't know precisely how Debian deals with source, so perhaps not Debian) provides a pretty good learning system. On rpm based systems, you can just create ~/.rpmrc, modify buildarchtranslate, fill in an OPTFLAGS field, and then use rpm --rebuild on a SRPM to do the same rebuilds that you'd do on Gentoo.

    My other real irritation is the number of (a long time ago, mostly Slackware, now mostly Gentoo) users that run around telling would-be Linux gurus that any advanced users *clearly* use a system in which they build their own packages. This tends to put these people in a position of feeling that they need to use a particular distro to prove their tech balls. It's not a particularly friendly environment for any new users. (They ignore, of course, the fact that Linus uses KDE on SuSE, and Alan Cox GNOME on Red Hat -- and both of them seem comfortable).

    Does that make Gentoo bad at all? No. Of course not. I'd just like to keep the twin nastinesses of "Bob sucks, because he only uses distro X" and "Distro Y beats the shit out of other distros when it comes to performance/stability/other inflated claim" to a minimum.