Mac Forum / General / Hardware / February 2005

Nope, you claimed something entirely different
You claimed that putting the apps for some workproject on a portable drive
would be difficult for windows, easy for the Mac and for linux "it's going
to be problematic, as well, because of all the different distributions.
You'd almost have to keep the source code on the hard drive and compile it
for each version"

Well, you have neither explained *why* it would be problematic, nor what
kind of apps would need to be recompiled. You may do so now. Be specific

Idiot

Hmm. Windows, with its registry, would make this tough (sticking an app
on an external drive and using it on multiple computers). Assuming the
app didn't *need* the registry, and/or recreated its registry values
when run, it could work. You'd probably want to put any required DLLs
in the same directory with the app. (God help you if it needs DirectX
or something, though.)

On the Mac, it's simpler because of the tradition of putting all
the apps files in one directory. (Makes some things easier, and
some harder - like making a separate partition for temporary files).
But OSX is Unix under the hood, and it's still possible there, so
that should be a hint that it can be done with Linux too.

Traditional Unix filesystem layouts lean against this a bit.
Different parts of apps (binaries, shared libs, config files,
temp files, etc.) tend to go in in different places on the system.
Plus some distributions are set up to prevent executing binaries
off of removable media (as a security precaution).

But even on Linux, it wouldn't be *terribly* hard. Most apps can be
compiled to be installed anywhere (take a look at the "PREFIX" and
"EPRIFIX" options to GNU autoconf, for example). Compile it statically
and you don't have to worry about shared libs at all.

If you don't have the source available, it's still not that big a
problem:

1. Run 'ldd' on the app, find out what libraries it needs.
2. Copy the app and the libs to the external drive.
3. Write a small wrapper script that sets up LIBPATH so the app
   can find the libraries when it runs.

That's one way. If you're root on the boxes involved, you can get
*really* clever, and play some 'mount' tricks to graft partitions
from the external drive into the filesystem on the boxes, so you
don't need to muck with the paths. Or just use symlinks. (No real
*need* to do this, just pointing out that there's more than one
way to do it.)

Note that most of this is only required if the necessary shared
libs aren't on all the boxes involved (and unlike Windows, there's
no problem with having multiple versions of a shared lib available
simultaneously). If, say, all of the boxes are the same distro,
you're golden.

Finally, there is one insurmountable problem that could torpedo
the whole thing. If you have Linux boxes on more than one hardware
platform (say, Intel, Alpha, PPC, SPARC, MIPS, ARM, 68K...) then
yeah, you have to recompile. But it's hard to argue that this is
a disadvantage of Linux until you can get Windows or Mac to run
on more than one hardware platform... :->

Dunno about him, but the complicated/confusing part of what you say for
me lies around compilation. Most packages come in RPM form and
installation is a no-brainer. The only package I've had to compile in
the last two years is Limewire (which is the same on every Linux), ie
./configure && make && make install. I think I compiled nano once too.