On Wednesday 25 August 2004 03:50 pm, [EMAIL PROTECTED] wrote: > On Wed, 25 Aug, 2004 at 03:13PM -0400, John Check spake thus: > > On Wednesday 25 August 2004 02:41 pm, [EMAIL PROTECTED] 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!