[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