[SLUG] "ports" v. "packages" distributions -- WAS: Galeon, may I have a dog, please?

From: Bryan J. Smith (b.j.smith@ieee.org)
Date: Sun Oct 10 2004 - 10:09:20 EDT


On Fri, 2004-10-08 at 11:09, Robert Snyder wrote:
> Galeon and emphany are pretty snappy to me so is firefox gotten
> extremely snappy with my vidalinux ( gentoo with gui installer)
> because everything is optimized for my processor which seems to make
> a difference.

We had a similar thread over on JAXLUG about optimizations (and
extensions, which one poster confused as the same).

http://mailman.jaxlug.org/pipermail/jaxlug-list/Week-of-Mon-20040927/011886.html
http://mailman.jaxlug.org/pipermail/jaxlug-list/Week-of-Mon-20040927/011888.html
http://mailman.jaxlug.org/pipermail/jaxlug-list/Week-of-Mon-20040927/011896.html
http://mailman.jaxlug.org/pipermail/jaxlug-list/Week-of-Mon-20040927/011890.html

I'm not questioning whether or not Gentoo (a "ports" distribution) is
faster, but there is more to a "ports" distribution over a "package"
distro (most are Debian or Fedora-based, even if based on a long-gone
Red Hat Linux release) than just "performance." And sometimes, "ports"
distros can be slower too. It all depends if you know what you are
doing, or the "ports"/"packages" maintainer did.

In a "ports" distro, you define a few options in a global file, then the
build process is up to the individual configure/Makefile or scripts by
the "ports" maintainers. Then _all_ packages get built to those
capabilities, if possible, although the "ports" maintainer must know how
to best build a package.

In a "packages" distro, you leave the optimizations up to the packager.
Although it _should_ be noted that many packages (at least in Fedora)
_can_ make good use of the "--target" option (RPM) including optimizing
well for Athlon. But _most_ major packages are built with _all_
extensions so they can make use of _all_ extensions available.

The latter is not quite the same as a completely optimized "ports"
build. But one mistake I see many Gentoo users claim is that they get
all "extensions" whereas "packages" don't. Not true. E.g., many Fedora
Core, Extras and Livna.ORG multimedia packages _are_ built with _all_
extensions, since MPlayer dynamically loads and uses extensions,
libraries, etc... as supported.

So the only difference between "packages" and "ports" there is that
Gentoo builds a smaller, more custom binary for your specific platform,
whereas Fedora includes more bloated, "everything included" packages.

Ultimately, if you rebuild from source "package" (be it RPM or Deb),
you're back to the same thing as a "ports" system. You rely on the
"maintainer" to make sure the build process is optimal for the package.

Just FYI, Fedora Core is built for i486 ISA with i686 optimizations.
That is close to with 5% of optimal performance on any modern i686 ISA
compatible processor (PPro, P2, P3, P4, C3, Athlon, etc...). Now there
are some additional optimizations for Athlon in GCC 3.1+, but they can
also create unstable object code (GCC 3.3+ improves this some though).

Also, any binary supports dynamic loading/use of extensions is built
with _all_ extensions in a Fedora (and probably Debian too) package. Do
not confuse ISA/optimizations with extensions support.

Heck, even that line is blurring. The new 2.6 kernel, when built for
i686 (Pentium Pro) can dynamically optimize better for the 9-issue
Athlon scheduler (although the Athlon itself uses various run-time
techniques to make up for its 2 additional pipes that the PPro-P4
doesn't have).

-- Bryan

-- 
Bryan J. Smith                                  b.j.smith@ieee.org 
------------------------------------------------------------------ 
"Communities don't have rights. Only individuals in the community
 have rights. ... That idea of community rights is firmly rooted
 in the 'Communist Manifesto.'" -- Michael Badnarik

----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:28:48 EDT