On Friday 06 June 2003 12:30, Nadav Har'El wrote: > > Very logical. Don't forget that the main idea of Gentoo is optimization. > > Am I the only one that finds this whole Gentoo approach extraordinarily > silly? > > You spend 24 hours compiling your optimized version of KDE, which needless > to say will come out exactly like your neighbor's optimized version of KDE, > only to save a total of 10 CPU seconds over the lifetime of that software?
Optimization for the sake of speed is not the primary goal. Or at least not the sole primary goal. There are other things a from-source package manager gives you which are at least as important. I'll refrain from writing about gentoo philosophy in general (which has more aspects than what I'll mention here), just the benefits stemming from it being source-based: Customizability: cf. use flags. You can compile your apps with exactly the compile-time settings you want. A binary distro ends up making most if not all of these decisions for you, and you can't change them without compiling things. Want your apps not to install or use gettext-style .po files? Enable alsa, nas and arts support but not oss or esound? Choose between widget libraries for apps with multiple exclusive interfaces? These aren't very easy to do in a binary distro. Portage is also, well, portable: easy to port to new a architecture or system. That's why Gentoo is called a 'metadistribution': it's intended for other projects to be based on top of it, and all or very nearly all of them can live together in the same central tree. I don't know how hard this would be with a well-designed binary distro. But if we had to maintain binary packages for all our architectures, multipled by several versions per package, and update them all fairly quickly whenever new versions and security patches were released, we'd need a _lot_ of computing time and manpower just for this. But now, we have everything in a single tree, and the amount of architecture-specific code is vanishingly small compared to the amount of the shared code. We've so many architectures now I don't even remember all of them offhand :-) At least x86, ppc, sparc 32/64bit and alpha, with WIP on arm, mips, hppa and x86-64 (the amd kind). How many binary distros support such a range of hardware, including embedded stuff? This isn't limited to architectures: many things are based on portage. Gentoo isn't limited to Gentoo Linux. There's a gentoo-hardened project, which is now demoing its first Gentoo SELinux stuff. There are ongoing projects for Gentoo Hurd, Gentoo BSD, and Gentoo OSX which is planning an iPortage GUI for emerge. People have been known to use portage on top of other (binary) linux distributions, to. Other projects like the livecd, and the derived gamecds Gentoo Games uses, are also built on top of portage. These CDs are built for any architecture portage supports by a script. Many of our architecture ports and subprojects started out with a user doing the initial work himself, before presenting it to us. That's the Gentoo vision of being a metadistribution at work. Take things like the propolice stack protection in gcc. It only requires a change to gcc (maybe also glibc, I'm not sure about the details), but it affects all packages you compile. With a binary distro, a user simply couldn't maintain support for such a feature without help from upstream, because he'd have to distribute modified rpms of _all_ packages in the distro to other users. With gentoo, he only has to distribute modified ebuilds for gcc and glibc. (Yes, he could distribute changes to srpms, but how many average redhat users are willing to rebuild their whole system from srpms?) About CFLAGS: these are useful for far more than optimization for speed. To begin with, there's the option of compiling for different architectures. Then there's optimization for size, for older/smaller/embedded systems. Or optimization for generic 386 or 486 systems, which some newer binary distros don't support. Finally, optimization for speed does have its justified uses. Newer processors like the p4 and athlon-4 can gain as much as 20 or 30% in performance when some apps are compiled for them and not generic i586. Right now that's not very visible because gcc has some p4 and athlon-4 optimization bugs, and so the gentoo install guied tells people to optimize for p3 and athlon, but I'm told most of these issues are fixed with gcc 3.3 and once we switch to that things should look better. This only applies to some apps that can fex. benefit greatly from sse2. Think povray here. You definitely won't see a big improvement from optimizing kde, because it doesn't use the processor much in the first place. Things like prelinking are much more useful there. > > As someone who used to compile free software on Sun and DEC Alpha machines > for years (including gcc, X-Windows, KDE, etc.) and spent dozens of hours > on these things (both my time and CPU time in the background), I was very > happy when precompiled free software, like Redhat, came along. It was so > convenient and time-saving, that nowadays I only rarely need to compile > free software. With cheap hard-disks, it's easier to compile a program > with every feature turned on than to spend an hour reading the INSTALL file > and compile-in only the features you're interested in (vim and emacs are > good examples of this), so distributions like RedHat have no trouble > suiting the needs of everyone with their precompiled software. "Suiting the needs of everyone"? I'm leery of one-size-fits-all solutions. Even if I had no immediate use for portage's cusomizability, I'd apreciate its being there. Some programs have mutually exclusive features. Like gtk and qt interfaces. Others have features that if enabled will pull in heavy deps only a few people want. Binary distros that enable everything by default can't accomodate either scenario easily. Also, it's not true that binary distros always enable every single feature. I remember someone complaining on this list not long ago that his distro compiled vim (or possibly something else, I don't remember what exactly) without Hebrew support and he didn't want to recompile it. This demonstrates my point: when your distro takes decisions for you, you might gain a little time as long as you would have taken the same decisions, but you lose a lot when you want to go against its defaults. Also, in gentoo, figuring out which features are optional and enabling/disabling them only takes a moment and no docs reading. Most of the time you don't even do it manually/explicitly, because you have global use flags set (or unset) which apply to many packages. And the defaults depend on what you already have installed, they aren't fixed in stone. Finally, gentoo does have support for binary packages. It's not perfect, because it's a secondary goal and not a high priority, but it's being improved. There's more sophisticated binary package support in the works, and an uptodate set of GRP packages will be a part of the 1.4 release. Right now there's a somewhat outdated set of GRP packages, and you can also create binary packages from ebuilds yourself and give them to other people (fex for build once, install everywhere setups). (GRP is the Gentoo Reference Platform - a standard set of CFLAGS and USE flags for which the binary packages are built. An unpleasant thought. But you can recompile any package with custom cflags/use flags after installing.) > > Can anyone educate me why Gentoo users find 24 hours of compilation of > KDE worthwhile? Or why they think Gentoo is actually suited for beginners? The Gentoo installation process is not suited for complete beginners, true. The install guide leads you by hand and tells yo exactly what to do, but you still need to be willing to create partitions etc. by hand. Those who do go through it though learn a lot :-) There are various plans/projects in the works for GUI or ncurses installers, but I don't know of any that is nearing completion. A recent improvement that we do have on our latest CDs though, is 99% automated hardware detection and initialization, to the point of auto-launching X11 with the right drivers, trying to dhcp for a network address etc. We also don't provide any hardware or software configuration interfaces. So right now it's a perfect system for moderately knowledgeable people. Being a metadistro, I expect people will add all of these parts sooner or later. -- Dan Armak Matan, Israel Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key
pgp00000.pgp
Description: signature
