4 ms·

In my experience, Linux platform compatibility boils down to a few things: - architecture (usually i686 or x86_64) - availability of the right library version

In my experience, Linux platform compatibility boils down to a few things: - architecture (usually i686 or x86_64) - availability of the right library versions in /usr/lib (however, you can combat this by "shipping" the versions you need with your app) - (rarely) kernel version - (even more rarely) glibc version In other words, most of the time, if it's an Intel binary, it seems to work pretty well. If a particular Linux distribution seems necessary, it usually just means that one of the above features of that distribution is important.

wheels 18y ago
It's really a lot more complicated than that on the packager's side. What you're seeing is likely the result of the person building the binaries already linking everything statically that's possible, using older compatibility versions of the shared libraries, and hoping for the best on the rest, being certain not to make use of recent or volatile features.
gaius 18y ago
It's getting to the point now that you might as well distribute your app in the form of a VM image.
- olefoo 18y ago
  I'm curious as to why that isn't more common, although you get a similar compatibility issue with your choice of vmware, xen or virtualbox; and there is some overhead; but yes, it sounds like a good idea to me. http://www.rpath.org/ http://www.rpath.org/ does something like that for server side software, and I know vmware supports that model.
- CUViper 18y ago
  A VM is great for trying out an app, but if I'm really going to use something, it becomes a PITA to have it in it's own sandbox. I don't want to deal with network sharing and all that just to move files between all my apps.
- jamesbritt 18y ago
  That's the JumpBox (http://www.jumpbox.com/ http://www.jumpbox.com/) people are doing.
cperciva 18y ago
I've had problems with inter-distribution linux compatibility in tarsnap due to * varying definitions of off_t (fortunately autoconf fixed this for me). * the linux 2.4 kernel returning EINVAL for the interaction of TCP_NODELAY and TCP_CORK (fixed by avoiding the problematic interaction on all linuxes). * the header files for openssl, zlib, and ext2fs/ext2_fs.h sometimes being installed and sometimes being part of packages with a wide variety of names (which I'm attempting to work around by providing a list of "the package you need should have a name something like this..."). I think there was a library version issue at one point too, but I can't remember what it was. Yes, I could avoid problems with header files if I only provided binaries; but even leaving aside the question of security, this would mean that I'd have to deal with the problem of packaging binaries in N different ways.

wheels 18y ago

It's really a lot more complicated than that on the packager's side. What you're seeing is likely the result of the person building the binaries already linking everything statically that's possible, using older compatibility versions of the shared libraries, and hoping for the best on the rest, being certain not to make use of recent or volatile features.

gaius 18y ago

It's getting to the point now that you might as well distribute your app in the form of a VM image.

olefoo 18y ago
I'm curious as to why that isn't more common, although you get a similar compatibility issue with your choice of vmware, xen or virtualbox; and there is some overhead; but yes, it sounds like a good idea to me. http://www.rpath.org/ http://www.rpath.org/ does something like that for server side software, and I know vmware supports that model.
CUViper 18y ago
A VM is great for trying out an app, but if I'm really going to use something, it becomes a PITA to have it in it's own sandbox. I don't want to deal with network sharing and all that just to move files between all my apps.
jamesbritt 18y ago
That's the JumpBox (http://www.jumpbox.com/ http://www.jumpbox.com/) people are doing.

cperciva 18y ago

I've had problems with inter-distribution linux compatibility in tarsnap due to * varying definitions of off_t (fortunately autoconf fixed this for me). * the linux 2.4 kernel returning EINVAL for the interaction of TCP_NODELAY and TCP_CORK (fixed by avoiding the problematic interaction on all linuxes). * the header files for openssl, zlib, and ext2fs/ext2_fs.h sometimes being installed and sometimes being part of packages with a wide variety of names (which I'm attempting to work around by providing a list of "the package you need should have a name something like this..."). I think there was a library version issue at one point too, but I can't remember what it was. Yes, I could avoid problems with header files if I only provided binaries; but even leaving aside the question of security, this would mean that I'd have to deal with the problem of packaging binaries in N different ways.