If I have a full-fledged linux system that I have configured with all the apps I like and such, is there any way to take the whole thing and make it run on another architecture by recompiling it all automatically or something?

I can't imagine there's any way to do such a thing easily. Afaik, already compiled binaries generally can't be transferred to different architectures, at least not without a lot of work. You have to use binaries that are specifically compiled for use on the new system.

Perhaps you could create a script that would take a list of all your currently installed programs and install (or build) the same ones on a new system (I believe some distros have the ability to snapshot an installation so that it can be easily duplicated on multiple machines, but I don't know how well that'd cross architecture boundries). If it worked, all you'd have to do is copy over the dot files in your profiles, and maybe a few select config files in /etc, to get a system very similar to your original.

But would all this be worth the effort? If all you're talking about is a single machine, it might take you as long to set such a thing up as to simply do everything by hand anyway. I'm not an expert on this though, so maybe there are others that know better.

I had this in the back of my mind aswell. I'm thinking of buying new hardware, Intel core architecture. It seems interesting to get the Intel C++ compiler and compile most of the OS when the system is still new and empty, with some basic optimizing on.

It's probably a hell of a job and not really suitable for a newbie, I fear.

Anyone an idea on this?

It also can be really heaviliy influenced by the distro.

This isn't just a useless plug for Debian, but I can get a list of all packages installed on Debian, and then put that same list on any machine of any architecture (as long as it is supported by Debian), install it all and be set.

As mentioned earlier, you might need some of your config files, and certainly most of your /etc directory, but the server distros will probably be much friendlier towards doing this than the more desktopish.

Peace,
JimBass

I suppose that any sensible upgrade in hardware will give me a 'faster' system than my current P4 without even changing the software. And a some point distro versions will be pretty much optimized for multi-core emt64 processors. Then there's the point of effort vs. reward: most systemtools won't benefit from re-compiling that much, I really don't need a 64 bit multi-core version of Emacs for example.
Candidates imho would be the kernel, windowmanagers, databases, graphical tools, etc.

So it's an intriguing idea to me.
I'd have to start with a bootable system with developers tools: GCC plus libraries. From there on I should step-by-step set up a new system, perhaps using existing binaries when it won't matter and compiling where it does.
Not sure if such a mix-up of different software will make a stable environment, how these new processors behave when they get 32 bit & 64 bit apps to deal with.

Edit: good points JimBass, thanks for the answers ^^ vv , peace too

That would be a major job. I have been running AMD 64 bit processors on multiple desktops/servers for about 18 months now. On some I installed 32 bit debian, some I did 64 bit. On the 64 bit, at a human level I see very little difference in its speed.

Also, the vast majority of programs don't have 64 bit versions yet, and many of those that do have them are things that see little if any benefit to the added capabilities, as you pointed out with emacs.

With my pure debian 64 bit install, when running the updater, apt-get, I still see plenty of package.all.deb files being downloaded, meaning I get the same one a 32 bit gets. The amd64 ones are named package.amd64.deb. All 64 bit distros still run many 32 bit apps.

If you really want to compile everything, you may want to use a distro like linux from scratch, or something along those lines. Gentoo is one of the more popular self-compiled distros, but I just installed that on a test machine the other day, and found out you can still use binaries for most everything, it just gives you the option to compile everything.

Keeping a system with self-compiled programs up to date will be work. Yum, apt-get, up2date and all of those have spoiled users by being able to update with a click or a few commands. Nothing notifies you that there are new versions of self compiled apps, and there is no dependency resolution either. If version 1.1 comes out and you're running 1.0, you can grap the tarball and try and install, but if you find 30 dependencies, you're downloading those and installing them all. Can it be done, most certainly. Will it be easy, hell no.

I would think for most folks the work involved would not be worth it, but it would be fun in a sense to see how linux/unix/BSD folks did things years ago.

Peace,
JimBass

There isn't really any way to do something like that terribly easily. Most of it's going to be simple, since C/C++ will usually change architectures without much of a fight. It's when you get stuff that was made in ASM that you start having to hand-code stuff.

A far easier solution would be to take a copy of all your relevant configuration files and move those.

Example: if you use KDE, copy your .kde folder. That should transfer all your configuration files. I'd make a backup of it as well, since there is the possibility that installing software will overwrite the config files.

I've never seen something of that nature. I did hear that someone used rsync or something clever like that to syncronize his configuration files between two computers he used. I thought that was quite clever.

If you want to invest some time into the problem, you can use Sync4J to update/merge/branch your configuration settings in much the same way you can with CVS, only without the advanced rollback and history features.

Nor am I. Generally, I find that it's really much easier to stick with most of the default settings and to not tweak things too much. Eventually I just get angry because I'm spending more time messing around with how junk looks rather than the important things.

For non KDE applications I know that a lot of configuration things are stored in ~/.<app> folders. Usually these are platform independent, which is nice because you don't have to worry about overwriting machine-specific information.

I hope you find a solution that works for you.

That doesn't sound like a big deal. Probably quite a bit of work though. On Slackware, as a first approximation, I'd start with something like:

Of course, you'd probably need to use various configure options which would mean finding out what options you (or your distro) used and feeding them in based on the package name (e.g. reading them from /tmp/pkg-config or something), and a few packages might need further tweaking...

Complex? Not really. Hard work? Definitely.