On Mon, 2004-12-06 at 01:54, Chad Perrin wrote:
> I recommend you adopt the same strategy in the future, Bryan. Pausing
> to consider each individual statement and your response for value to the
> list at large is probably going to help you also recognize when you're
> assuming the worst of my intentions when the worst is not applicable.
First off, I did cut out a lot of statements/responses. Secondly, I
think this doesn't solve the problem that about 80% of the total
correspondence was totally unnecessary. ;-p
> Do you know whether LILO supports it?
LILO doesn't support anything. It's a simplistic, LBA offset boot
loader, unlike GRUB. But yes, this means LILO _can_ boot a Linux
instance inside of a LDM disk label (partition table).
> I've noticed that trend.
The problem is that many don't stop to understand the technology.
In a "ports" distro, you're almost always building the software from
source (at least that's the main argument). But optimizations are still
going to be dependent on the Makefile.
In a "packages" distro, you have the option of rebuilding from source.
And, again, it's up to the Makefile and the options the package manager
allows through.
Most "packages" distros are built to a system-wide set of "common
defaults." But that doesn't mean packages won't take advantage of
extensions or other ISA enhancements. E.g., multimedia applications
like MPlayer is already modular, and the "packages" distro merely builds
it with _all_ extensions. Again, it still depends on the Makefile at
the time of build.
Most "ports" distros have a system-wide configuration file, it then uses
to build a system-specific set of software from source. Now the
software port gets built to a specific ISA and set of extensions. E.g.,
multimedia applications like MPlayer will only be built with the
required extensions, reducing overall size, but not necessarily being
faster than the "packaged" equivalent with all extensions built.
Of course, then we can get into the general GCC optimizations. If you
build with gcc -03, like many "ports" advocates do, you'll get far more
"aggressively optimized" code than any "packages" distro I know of.
Why? Because Debian and Red Hat build with gcc -O2. I would _never_
run a system myself where all packages were compiled with -O3.
> Why?
Using the SSE pipes of the P3/P4 processors should be carefully
considered. Not only do they lack the accuracy of the P3/P4 FPU, but
they also lack the precision too. -O3 aggressively uses the SSE pipes
to _replace_ FPU operations.
Additionally, -O3 also does some aggressive scheduling that could result
in an unforseen chicken/egg issue or other race condition. This is
especially the case of processors that already do chip-side run-time
optimizations like register renaming and out-of-order execution, such as
the Athlon.
In general, -O3 should be _sparingly_ used on _specific_ packages.
> Considering that I was more familiar with Red Hat Linux, Windows, and
> SuSE, and thoroughly UNcomfortable with Debian with my first hesitating
> attempts to make use of it, I think you've just said I reside within a
> 10% segment of humanity to which this statement of yours (that it's "not
> true at all") doesn't apply. It might be worth noting that I'm of the
> considered opinion that at least 90% of humanity qualifies as the
> aforementioned "friggin' moron" class of person. It looks like our
> numbers match up fairly well.
The options and distribution of the Fedora Project is radically
different than Red Hat Linux, even if Red Hat still offers "Fedora Core"
as the logical upgrade path.
> You keep seeing Debian and Fedora in the same sentence, though, and assume
> the worst.
Because you are comparing and contrasting Debian and Fedora.
Someone should have experience with _both_ before attempting such.
-- Bryan J. Smith b.j.smith@ieee.org ------------------------------------------------------------------ Beware of advocates who justify their preference not in terms of what they like about their "choice," but what they did not like about another option. Such advocacy is more hurtful than helpful.----------------------------------------------------------------------- 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 - 20:24:06 EDT