[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pros/cons of installing from source



On Thu, 2007-05-03 at 13:10 -0600, Javier Vasquez wrote:
> >> For every report of "Woot! Compiling from source kicks butt. Why
> didn't
> >> I do this earlier", I can find 1 that disagrees with you and 1 that
> says
> >> "maybe it is worth it for max performance, but WOW, 196 hours to
> get a
> >> workable complete system, I'm not so sure"
> ...
> >> The reason I say this, is even if you get 1%-5% improvement in
> >> performance, are you really going to see (really and truly "feel")
> it?
> >> The answer is: no.
> ...
> > Biggest contenders for optimisation are the kernel and libc. Most
> > applications are mainly a series of calls to these two so won't
> directly
> > benefit from by being compiled with *magical* flags.
> > Debian supply both optimised kernels and to a lesser degree
> optimised
> > libc packages. Use of SIMD extensions etc is something totally
> > different, and compiler flags aren't going to do all that much there
> > really...
> >
> >
> > Think of all the dolphins that will die because of the electricity
> > wasted pointlessly compiling packages. ^^
> 
> 
> Well, I have no experience whatsoever with gentoo, but I have
> experimented with sourceMage.

well, I just got done doing a FULL install starting with the 50MB
install disk. Doing a full emerge of the kernel source (inside the
chroot). Then did a full configure for a non-initrd kernel and
specifically built it for this ONE machine. An XP3200+ Athlon with 2GB
of memory and SATA-150 drives and DVD+-RW and a DVD-Reader, an nVidia
5950, a VIA chipsets (KT880 for AthlonXP chips and not Athlon64s).

I did a full on build of the entire system. Libraries, Kernel, Desktop
Environment (GNOME) with FireFox, OpenOffice.org 2.2, many tools I use
everyday, plus some things I just like to have available should I need
them. I used the full optimizations for "ultimate power" in the right
places, like libc and the kernel and a few other areas that are
sensitive to tweak, like encoders and decoders. Along with the entire
two phase build process and the final stripping and other such niceties.
The machine finally was done after 166 hours.

> And I have most things compiled for the systems I need, and it
> doesn't' take that much time as I've heard about gentoo (no discussion
> it requires quiet more time to build a system than to install it).
> The most time I've spent is to learn about the new packaging system
> for the sources (taking care of dependencies, automatic download,
> testing/stable, etc, not that much though), and also about what is
> really required and what is not for a package (this requires the most
> time for me, since I'm used to just "aptitude install" what I need).

emerge is very simple tool to use, especially if you just hunker down
and use it. Selecting the right architecture and listings (I used
"current" snapshots) is a big factor. I had everything up and running as
soon as it stopped compiling and installing. 

> BTW, the kernel is a good example not for optimization flags, neither
> dependencies, but for configuration.  The stuck kernel supplied by
> debian is compiled to work for most systems, and supports a lot of
> hardware one might not need.

I will bet you that my Stock Debian kernel will run *JUST* as fast as
your kernel will on the same exact hardware, once booted.

You know why? I have Debian on the same machine I have Gentoo on. Both
are reasonably close to each other in versions of most things.  The only
places I've seen REAL performance enhancement is in encoding of files.

> A bit of optimizations can be granted by correctly selecting the cpu
> also, and by tuning the configurations as well (example, one might
> want to select pentium M for cpu architecture and the like).  Of
> course this doesn't require a source based distro though, debian
> provides pretty good kernel compiling/packaging/installing tools.

Again, specifics pointed out. Pentium M is still a sub-arch of another
arch. K7 is effective an i686, but slightly better instruction set for
"a few things"

> Also It's not only compiler optimizations what you get from source
> base distros, it's dependencies control.

Dependency controls... like what apt or aptitude does?

> There are things one might compile against, that others might think as
> irrelevant.  On binary based distros one can't control how the
> packages are compiled, thus one need to comply with the dependencies
> set by the developer.  Which is OK for the most part, except if you
> want customized systems (whether lighter or even more blotted).

The way things are done and the speeds at which processors run, you will
not feel the "difference" on a package compiled additionally against
xlibs as ones without that compiled option. I dare you to REALLY show me
qualitative and empirical proof that you get "3 more cycles per second"
of processing time for something like the "gd" package. You'd have to be
doing MOUNTAINS of processing to even being to show the difference. But
then, an apparent 3 more cycles might be coming from your recent change
in Apache to cache more... so more IO is available from the disks.

> It all depends on one's tastes and necessities.  I for example am
> trying sourceMage in some machines, and found it amazingly easy and
> fast enough for the building part, and still I have debian installed
> in some others.  I have to recognize that things given by granted on
> debian, need to be sometimes carefully looked on sourceMage though.

Yes, Debian is really all about getting things done and making them
work. These Source based Distributions are passe. Yes, passe. I think
that many of the people that use them "long" for the "Good Ole days" of
swapping 32 diskettes on a machine and taking 20 hours to get a basic
machine to get on the w3c and download  other tarball sources to compile
and get X to run properly with you NEW mach8 512KB video card.

Me, I really look back and say, look how far we are now, not having to
ask Patrick to stop including that broken detection package on his CDROM
that always LOCKED most non-Packard-Bell machines (the new PCI standard
thing).

> Any ways, it's true that if you're planning to try a source based
> distro, you need to save time for that purpose, not just because of
> compilation time though, but also for learning about some packages and
> their lots of optional dependencies offered.  If you still have
> doubts, you need to try, and then generate a personal criteria.

I've goth the same criteria for both type of systems. Gentoo does
document well, so does Debian. They both have relatively easy package
management systems to learn to use.

There is however a major difference that kills Gentoo for me, Written
Package Policy and the "balls" to follow through on it. That Single most
important reason to use Debian.

> You asked for pros and cons.  I think the cons are very clear, but I
> wanted to complement the pros, because IMHO it's not just the
> optimizations flags what gets provided...

Your pros are subjective, though they are the "normal pros" always
given. There are however, any number of fallacies with either side.

> BTW, you might still use a binary distro, and compile some critical
> things, as implicitly suggested by a previous post.  The best example
> for such thing, as stated in a previous post is the kernel.  Maybe
> others...

Re-compiling a kernel these days is just something that doesn't need to
be done. Unless you want to goto a NON-Modular and/or NON-Initrd Kernel.
This does not guarantee you a faster machine. It just makes it so that
you will have a hard time moving the "hard drive" to another machine if
the current one breaks. Though some argue a non-modular kernel is more
secure... I beg to differ on it, but that is another argument for
another time.
-- 
greg, greg@gregfolkert.net

Novell's Directory Services is a competitive product to Microsoft's
Active Directory in much the same way that the Saturn V is a competitive
product to those dinky little model rockets that kids light off down at
the playfield. -- Thane Walkup

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: