1 |
Grant Edwards wrote: |
2 |
> Whenever I see a write-up of Gentoo, it's describe as a system |
3 |
> similar to BSD "ports" where you build packages from source. |
4 |
> The main benefit claimed for this approach is that you get |
5 |
> better performance because all executables are optimized for |
6 |
> exactly the right instruction set. |
7 |
> |
8 |
> Where did that bit of apocrypha come from, and why is it |
9 |
> parroted by so many people? |
10 |
> |
11 |
> AFAICT, the "performance" benefit due to compiler optimization |
12 |
> is practically nil in real-world usage. |
13 |
> |
14 |
> In my experience the huge benefit of source-based distros such |
15 |
> as Gentoo is elimination of the library dependency-hell that |
16 |
> mires other binary-based distros. |
17 |
> |
18 |
> For many years I ran RedHat and then Mandrake. After a year or |
19 |
> so, they became impossible to maintain because of library |
20 |
> version conflicts. Every time I tried up upgrade an RPM package |
21 |
> to fix a bug or security hole, it required a handful of |
22 |
> libraries to be upgraded, but doing that would break a bunch of |
23 |
> other RPMs for which upgrades weren't available. The solution |
24 |
> was always to start building stuff from sources. Once you |
25 |
> started doing that, the package manager would get upset because |
26 |
> it doesn't know about some stuff that's installed (unless you |
27 |
> built from source RPMs, which had another set of problems). |
28 |
> |
29 |
> The second benefit is that with Gentoo, upgrading a system |
30 |
> actually works over the long-run. With RedHat/Mandrake, things |
31 |
> would gradually deteriorate to the point where the system was |
32 |
> unmaintainable, but attempting to upgrade between major |
33 |
> releases was always futile. I've had Gentoo machines that have |
34 |
> been upgraded for 4-5 years without any significant problems |
35 |
> (failed hard-drives don't count). |
36 |
> |
37 |
> The third main benefit I've seen is that there are vastly more |
38 |
> packages available for Gentoo. Putting together and |
39 |
> maintaining an ebuild appears to take a lot less work than |
40 |
> putting together and maintaining a binary RPM package. I've |
41 |
> had far fewer problems with third party ebuilds than I did with |
42 |
> third-party RPMs (on the rare occasions when I found one for |
43 |
> some obscure application I wanted to run). Again, the solution |
44 |
> was always "build from sources". |
45 |
> |
46 |
> Are the real benefits of Gentoo too hard to explain to the |
47 |
> unwashed masses, so instead they're told the fairy tale about |
48 |
> imporoved performance? |
49 |
> |
50 |
> |
51 |
|
52 |
Being a metadistribution, the concept of higher performance isn't quite |
53 |
that much of a fairy tale. If you can easily configure your system to a |
54 |
specific purpose, that would ideally lead to better performance, whether |
55 |
it be due to the specialization of the system or at least a placebo |
56 |
effect on the user. Gentoo is honestly my first linux system, so I don't |
57 |
really have the experience of library conflicts of binary distros. |
58 |
People in general will usually just want confirmation that something has |
59 |
benefits over what they currently have, irregardless of evidence of |
60 |
exactly why it is better, so that may be part of why so many supporters |
61 |
"parrot" the same view regarding Gentoo. On the other hand, I just take |
62 |
a lot of it as peace of mind in that all the responsibility for how my |
63 |
system is running is directly mine, as opposed to being able to blame |
64 |
someone who made a bad RPM. I like knowing any little factor of my |
65 |
system and what it's doing. |