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

John Check j4strngs at bitless.net
Thu Aug 26 21:12:10 UTC 2004


On Wednesday 25 August 2004 03:50 pm, james at dis-dot-dat.net wrote:
> 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.

What I meant specifically was if you make binary packages on a build host and 
roll out updates that way it's the best of all possible worlds. 

>
> 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.
>

Other than being implemented in Python, I have to agree. I have no beef with 
Python per se, just it's appropriateness for the task.

> 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.
>

I dunno, it's on par with Debian. Good package management is one of the 
founding principals of Debian.
I can make a case for emerge world && emerge system being ways to address
compile time requirements, but that's about the only advantage I can think of 
for emerge.


> 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.
>

That's what I felt when I switched to Debian, but honestly, I'm not in that 
much of a hurry. ;)

> 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.

If it sucked, nobody would use it.

>
> > > 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!



More information about the Linux-audio-dev mailing list