Linked by Thom Holwerda on Mon 23rd Jun 2008 16:51 UTC, submitted by sjvn
Linux Installing software on Linux. In the world of online minefields, this is the big one. Back in the day, you installed software on Linux by compiling it manually. Time-consuming, but assuming you had a decent knowledge of gcc, make, and maintaining library files, this could actually work. Later one came the package management systems that were supposed to make installing software on Linux a breeze: rpm, dpkg, and so on, and so forth. Since human beings have the innate tendency to assume that everyone else is wrong and only they are right, we are now stuck with 3453495 different Linux package managers. Denis Washington, a Fedora developer, is taking steps to resolve this issue.
Thread beginning with comment 319625
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: ...
by Michael on Mon 23rd Jun 2008 23:24 UTC in reply to "..."
Michael
Member since:
2005-07-01

Since when is there a problem with binary compatibility? The LSB pretty much solved that. Where it failed was on package management, mandating RPM which could be problematic (though not fatal) for dpkg based systems.

I still say the solution for third party software is to simply treat "/opt" like "C:/Prgram Files/".

Reply Parent Score: 4

RE[2]: ...
by IkeKrull on Tue 24th Jun 2008 01:51 in reply to "RE: ..."
IkeKrull Member since:
2006-01-24

Since... forever?

Try compiling a C++ app on one linux distro and running it on another. Doesn't work, unless the distros in question track the same core debian release or something.

Try running an old linux app - say an old commercial game from Loki like Simcity 3000 or Civ CTP.

Doesn't work.

Binary compatibility just doesn't exist in the Linux world.

For all the blather about open standards, the Linux community doesn't give a crap about them when it comes to it's own core systems. e.g kernel and binary APIs

Reply Parent Score: 4

RE[3]: ...
by leos on Tue 24th Jun 2008 03:37 in reply to "RE[2]: ..."
leos Member since:
2005-09-21

Try compiling a C++ app on one linux distro and running it on another. Doesn't work, unless the distros in question track the same core debian release or something.


Ha. Try compiling a C++ app on Windows and deploying it to another machine. Doesn't work. Unless of course you bundle all the runtime libraries for the compiler you're using into your installer. Guess what, the same thing works on Linux. Include all your dependencies with the app and binary compatibility is no problem.

The reason binary compatibility is harder on Linux is because Linux apps actually try to share libraries, instead of each app bundling everything they need and then loading X copies of it in memory. Bundling everything is easier, but not very efficient.

Reply Parent Score: 7

RE[3]: ...
by Michael on Tue 24th Jun 2008 10:43 in reply to "RE[2]: ..."
Michael Member since:
2005-07-01

Well, Mozilla Firefox, Adobe Acrobat, Macromedia Flash, Unreal Tournament 2004, Doom 3, Matlab and many more manage to be distributed as single binaries that runs anywhere.

I don't know what you're doing but as long as you're developing for at least the 2.4 kernel and a reasonably recent glibc (older versions should be available in your distro's repository) you shouldn't be having trouble.

Reply Parent Score: 3

RE[3]: ...
by anda_skoa on Tue 24th Jun 2008 12:05 in reply to "RE[2]: ..."
anda_skoa Member since:
2005-07-07

Binary compatibility just doesn't exist in the Linux world.


Well, it does, however vendors seem to prefer using distribution and version specific ABIs over the standard one.

Unfortunate but it's their decision. If they prefer rebuilding and repackaging, e.g. for very tight integration into the system, then that's what they are going to do

Reply Parent Score: 2

RE[2]: ...
by TemporalBeing on Tue 24th Jun 2008 16:39 in reply to "RE: ..."
TemporalBeing Member since:
2007-08-22

Since when is there a problem with binary compatibility? The LSB pretty much solved that. Where it failed was on package management, mandating RPM which could be problematic (though not fatal) for dpkg based systems.

I still say the solution for third party software is to simply treat "/opt" like "C:/Prgram Files/".


Since not everyone runs an x86 32-bit processor.

For instance, I had a lab where I needed to target Itanium, 64-bit x86, 32-bit x86, Sparc, and more. Simple binary compatibility would not work to target those systems.

Reply Parent Score: 1

RE[3]: ...
by anda_skoa on Tue 24th Jun 2008 17:04 in reply to "RE[2]: ..."
anda_skoa Member since:
2005-07-07


Since not everyone runs an x86 32-bit processor.


Nice thing is that the LSB actually specifies the interfaces for a couple of architectures:

LSB 3.2 (IA32
LSB 3.2 (IA64)
LSB 3.2 (PPC32)
LSB 3.2 (PPC64)
LSB 3.2 (S390)
LSB 3.2 (S390X)
LSB 3.2 (AMD64)

http://www.linuxfoundation.org/en/Specifications

Reply Parent Score: 2

RE[2]: ...
by Moonbuzz on Tue 24th Jun 2008 18:48 in reply to "RE: ..."
Moonbuzz Member since:
2005-07-09

I still say the solution for third party software is to simply treat "/opt" like "C:/Program Files/".

Only it's not their decision to make. Honestly, if I wanted third party developers to treat my computer like it was their own back yard, I'd use Windows.

Reply Parent Score: 1