Debian/Gentoo ponderings
I use Gentoo a lot, or rather i break gentoo a lot.
I have a stack of old boxen (200MHz and 64Mb ram is typical) that i use for random applications (kitchen radio, random database/beb/app servers for dev use etc). They tend to run debian.
One of the old boxen is a fairly slow PII, and i use gentoo packages built on a rather faster PII SMP box. It seems more responsive and to use less ram then the debian jobby.
It has been my intention to use debian on this forthcomening linode, however I've been wondering about maybe building some of the more critical packages from source to take proper advantage of the Xeons the linodes run.
Does anyone have any experience of cross-compiling packages for debian in this way or know of any tools to automate this? I doubt i'd be popular if I used the linode for compiling big packages. Or is there a repository of more specifically compiled debian packages?
I know the easy answer is to use gentoo, but I can just see a package getting broken and a bunch of angry metalheads hammering on my door (don't ask).
TIA
4 Replies
I stumbled upon pbuilder
Which raises the question of cross-compiling, both across distros, across different processors, and across versions of gcc. I remember getting into awful trouble after gcc/glibc upgrades when I forgot to recompile my kernel.
Does anyone have a setup that works particularly well, or know anything that I'm likely to stumble on that might break horribly and/or inexplicably?
Linodes do not bottleneck at the processor, but rather at memory and/or IO depending on your use.
Compiling programs for a specific processor only helps if your processor is the performance bottleneck. Some compiler optimizations even cause programs to be larger in size, thus using more memory and IO, causing them to run slower on a Linode.
I would suggest Slackware if you're interested in the leanest and fastest distro possible.
However careful and considered use of -Os and other flags to REDUCE code size can help with RAM and I/O issues, and work particularly well on systems that have a LOT of proceses going on, and on crowded virtula systems.
Additionally newer versions of gcc tend to produce smaller and faster code than older versions although there are a few exceptions.