[linux-audio-dev] Hello - FYI - intro

[james at dis-dot-dat.net]

On Wed, 25 Aug, 2004 at 03:13PM -0400, John Check spake thus:
> On Wednesday 25 August 2004 02:41 pm, james at dis-dot-dat.net wrote:
> > On Wed, 25 Aug, 2004 at 01:48PM -0400, John Check spake thus:
> > <snip multiple levels of replies>
> >
> > > YES. This is a much better argument. If it wasn't for having to keep a
> > > source respository (maybe it's optional) that would save disk space. I
> > > used to mount the cache on an NFS share (only had a 20GB disk).
> >
> > I was going to say you could have a cron job that ran when nobody's
> > likely to be using the machine that first checks to see if anything's
> > being emerged and then deletes the source cache.  But then I realised
> > two things.
> >
> > Thing 1: People will moan "But a newbie wouldn't want to mess..."
> 
> Newbie is beside the point. If somebody wants to make some tunage,
> it gets in the way of getting started.
> 
> >
> > Thing 2: Now that I think about it, I think there may be an option to
> >         remove source tarballs when they've been used.  I don't
> >   worry about disk space, so I've never looked into it.
> >
> > > Now if I had an office full
> > > of clones and a build host, that's as good as it gets.
> >
> > If you're anything but a total newbie (and I doubt you are) then you
> > can get some serious improvement in emerge times by using distcc.
> >
> > Does that sound complicated?  Here's how you do it.
> >
> > 1. Emerge distcc and configure it with distcc-config.  It's easy,
> >    honest.
> 
> apt-get install distcc
> 
> Took < 30 seconds. ;) 
> There's no way to get around it; To get all the advantages, you have to
> invest significant time to reach peak performance.
> Not to mention it blows the "software is free to produce" meme.
> It takes a lot more energy to compile a binary than it does to copy it.
> I'm not a tree hugger, but you can't argue with the physics.

No, and I haven't.  This was just a response to the previous post
about needing multiple machines to get serious gains.  Distcc does
make a difference, though not necessarily enough to warrant the
effort.  I don't even use it myself, although I have played with it.

Anyway, I don't really want to sound like I'm advocating any of the
tricls.techniques for more speed.  What I erally wanted to say when I
started all this Gentoo discussion is this: I think it has the best
package management system for linux there is.  Debian comes second,
for reasons I've already stated a couple of times.

I also think that apart from the installation, Gentoo is the easiest
system to use.  And by use, I mean installing/removing software,
updating and such - after that, all distros are pretty much identical.

This is just my opinion.

I also think Gentoo is faster.  Again, for the reasons I've already
stated - namely, not because it's source compiled, but because you
have what you want and need, not what you might need, possibly, some
time in the future.  This also means you only upgrade what you need,
unlike on a, say, redhat/fedora system, where all that extra software
might get updated too.

Really, a gentoo system is like a record of its user - all the
software installed has been installed because the user wanted it, or
needed it.  There isn't really any chaff.

> > 2. In /etc/make.conf, add -jN to your MAKEOPTS.  N is the number of
> >    simultaneous compilings you want.  It is suggested you use 2C+1,
> >    where C is the number of CPUs you're using.  This goes for
> >    non-distcc systems, too, unless you have old hardware.
> > 3. In the same file, add "distcc" to your FEATURES variable.
> >
> > A more detailed how-to: http://www.gentoo.org/doc/en/distcc.xml
> >
> 
> Yawn. I used to hack 2.0 kernel makefiles to speed the build up the same way,
> but N was RAM-8/8. Either way, if the number of things that can be build 
> concurrently is =< N , higher get you nothing.
> The real irony is the machines that could benefit most are the most expensive 
> ones to build on.
> 
> In their own doco, they say it's a build system (a damn fine one IMO) and IIRC 
> they'd like to see it used for tasked tuned distro production.
> 
> > I used this for a while, but my other machine is too noisy to leave
> > on (It's a HP Kayak xeon thing - the chassis is made of lead or
> > something I think, and the fans sound like a vaccum cleaner) and my
> > GF insists on using Windows.  Not just any old windows, either -
> > Windows ME.
> >
> > <ricer>
> > Maybe when I'm rich and have a herd of boxen, I'll do it again.  If
> > for nothing else than to stand in the middle of the room and scream
> > "The POWER!  The sweet intoxicating POWWWWEEEEEER!".
> > </ricer>
> >
> > > > Personally, I don't bother, but that's where the real speed
> > > > differences come from.  Absolutely nothing is installed unless you
> > > > need it or asked for it.  No daemons floating around "just in case".
> > >
> > > Also a cogent point.
> > >
> > > > Anyway, I think I'll stop now.  If anyone knows where that article
> > > > about the two emacs users comparing their systems is, please send me
> > > > a link.
> > > >
> > > > James
> > > >
> > > > > Erik
> > >
> > > Me Too!
> 

-- 
"I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb.  Thank you."
(By Vance Petree, Virginia Power)