8 ms·

In my experience binary compatibility on linux is a train wreck. Ever tried to get a binary compiled 5 years ago to run on a fresh install of linux? Good luck.

In my experience binary compatibility on linux is a train wreck. Ever tried to get a binary compiled 5 years ago to run on a fresh install of linux? Good luck. If you still have the specific version of every shared library that it loaded you might be able to get it to work. This isn't the fault of the kernel team though. It is probably to be expected on platforms in which distributing source code is the default option, but it makes the platform very hostile to closed source applications, particularly games.

MatthewPhillips 15y ago
It makes it hostile to abandonware.
- gaius 15y ago
  Hostile to people who use their machines for Real Work.
gaius 15y ago
Compare and contrast: http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779...
davidw 15y ago
If you want to be sure it'll work, you compile it statically, and waste a little bit of disk space and memory.
- protomyth 15y ago
  Trading security / bug fix updates in the process
muuh-gnu 15y ago
> This isn't the fault of the kernel team though. It is the result of having no unified platform and library release coordination, no long term plans, nothing, just chaos. Everybody just releases when he is in the mood for it. And since nothing is complete when released, devs further down the chain always go for the latest and greatest to get additional functionality. And to upgrade app1, you have to upgrade lib1 which triggers the updates of app2, app3, app4, lib3, etc. Sometimes you cant update a simple app without updating the whole desktop. The Linux dependency net appears nightmarish to everyone coming from Windows, where you have a reliable, stable base system which doesnt change for a decade and every app targets the same base system. Linux, the kernel, is only running that great because it has a dictator. But Linus' dictatorship ends at the kernel borders, he has little influence outside. The Linux desktop also needs a dictator to massively slow down the rate of uncoordinated changes and force-stabilize the ecosystem. I hoped that Mark Shuttleworth could be that man, but he then introduced Unity... but even with unity, Ubuntu is the only chance for the Linux desktop for having a single defined set of libs attractive and influential enough for app devs as a primary target so they can safely go with the library versions in Ubuntu, instead of constantly chasing the latest and greatest versions from the upstream.
- jiggy2011 15y ago
  Not sure why this was down voted so much, there is an element of truth to it. When you are dealing with different distributions that provide different versions of core libraries, different sound architectures , package managers and put things like executables and config files into different parts of the filesystem. I thought that the Linux standard base would be the way to solve this.
  - onli 15y ago
    Probably because though there is an element of truth in it, it just sounds plain wrong. After two sentences i thought "he probably works for microsoft or another big corporation", not because it's flame, but because of the attitude to regard this as pure chaos (and having no big plan as bad). I even looked up the profile. There is kind of a release-plan, not for the whole eco-system, but that's what stable distros are for. So the remark to Ubuntu is right. But it's wrong to mix library-stability with perceived frontend-issues with Unity. Ubuntu still fulfills that role for some apps. And besides that, it isn't necessarily wrong to write new programs against new libraries. They have new features and new bugfixes. I wouldn't want the ecosystem to stagnate right now. Or ever.
    - muuh-gnu 15y ago
      > not for the whole eco-system, but that's what stable distros are for The problem is that no app dev targets stable distros, but always goes for the latest and greatest from the upstream so distros are constantly forced to update libs and change the base system. So with a stable distro, you cant get a new version of an app, because the libs of your distro are too old, and you need to upgrade the whole distro just to be able to get that new app you want. The Linux ecosystem needs one distro (say Ubuntu) to become so influential, that app devs start to primarily target it instead of the upstream. Only then will the library space stop being a moving target for end users, and only then it will be possible to upgrade app1 without triggering an automatic update of app2, which both happen to depend on the same lib. Only then will these useless practices of "packaging" and "backporting" finally stop, and devs will be simply make packages themselves, like they do on windows or osx. Only then will users be able to install a distro once, and then be able to install new apps for 5-10 years without having to upgrade the whole distro every 6 months. > I wouldn't want the ecosystem to stagnate right now. Or ever. But with an ecosystem as unstable as the current one you wont get more than 1% of the market right now. Or ever. Normal users and especially businesses simply dont want to constantly update their systems. Force them to do that, and they simply walk away.
acqq 15y ago
There is a binary compatibility for kernel. Typically it's just the user-space dynamic libraries (in Windows speak: dlls not belonging to kernel) that you miss if you have a 5 year old binary and it won't run. Linus doesn't control user-space libs, just kernel. See how jwz shows you how to run a binary of Nestcape from 1995 (17 years old) on the latest Linuxen: http://www.jwz.org/blog/2008/03/happy-run-some-old-web-browsers-day/ http://www.jwz.org/blog/2008/03/happy-run-some-old-web-brows... Your major problem if you want to make a closed source application is that the user space dynamic libraries are mostly (L)GPL licensed, so you have to avoid (L)GPL libraries to have a legally fully-library-independent closed source application. LGPL license allows closed source linking only if you link dynamically to the LGPL library (meaning: your application must depend on the externally present library which can be replaced at any time). Which is really fair, IMHO. http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_Licen...
Thangorodrim 15y ago
Well, then, perhaps I am just lucky but just a few weeks ago I was able to get a fifteen year old binary running under both centos 6 and fedora 15. I did have to fish around a bit for an old version of curses and create a symlink. It only took a few moments though. Just a data point to consider.
ajross 15y ago
You're fumbling over the term "Linux". What you're describing is platform library incompatibility. What Linus is talking about is the kernel ABI. Not the same thing. The latter is a subset of the former, obviously, but Linus can't fix the fact that library authors don't care as much about the problem. The kernel is doing its job. Userspace, not so much. Though it's not nearly as bad as you think. In general, any desktop application compiled in the last 5 years will run unmodified on any modern distro. Really, it will, and I'd challenge you to find a counterexample. But I suspect you're talking about the dependency issue. Installing something with a bunch of dependencies (because modern software has a dependency graph that looks a lot like seaweed) requires finding and installing all that stuff on your modern distro. And package names have changed, and some have been dropped from the core distro, etc... And yes, this is a mess. But seriously: if you have a binary that works alone on, say, Ubuntu Dapper, it almost certainly will run on Fedora 16 or RHEL 6.2
- dhx 15y ago
  Even if you were to statically compile a software build from 5 years ago, it may require newer kernel features such as inotify (instead of dnotify). At some point of time the application authors (correctly) made a decision to throw out the old and go with the new. This is not a kernel issue (because old systems such as dnotify are still supported). But from a user perspective, it looks like the kernel is to blame, even if this assumption is incorrect.
  - ajross 15y ago
    From my Fedora 16 laptop: $ fgrep DNOTIFY /boot/config-3.2.9-1.fc16.x86_64 CONFIG_DNOTIFY=y Obviously it's true that dnotify is the old junk and inotify the new hotness. But it hasn't been abandoned, by either the kernel or the distros. Again, they take stuff like this very seriously. Old junk runs. Really, it does.
dfc 15y ago
What program from five years ago fails to run on debian/stable?
- dfc 15y ago
  I apologize for asking for specifics...
derleth 15y ago
> Ever tried to get a binary compiled 5 years ago to run on a fresh install of linux? I run older binaries on Linux all the time.
jff 15y ago
If we used static compilation for everything, this wouldn't be a problem. Our problem would then be higher memory consumption, but I can fix that for $50--at least until the next Ubuntu release comes out. Speaking of that, I wonder if there's some point at which dynamic libraries don't really help you that much. These days, even shared libraries don't seem to stop a GNOME desktop running a browser from sucking down a gig of memory; would it really kill them to have a couple more megs of static library in each program? With copy-on-write, I think things like Chrome which spawn many children would come out pretty well.
- josephg 15y ago
  Using shared libraries also decreases application startup time, because applications don't need to read as much code from disk. Even using an SSD I suspect the difference would be noticable for most applications.
- evanlong 15y ago
  One advantage to shared libs/dlls is that a security fix will be applied to all applications that depend on that. So if everyone statically links against insecure libA.a then all apps that depend on it need to ship a patch. Where as if libA is shipped as a shared library then one update needs to be applied. That's one advantage but maybe not the best.
  - im3w1l 15y ago
    What if we could have opportunistic dynamic linking, where an application uses a shared library, if present and compatible, and otherwise uses the bundled? Seems to get the best of both worlds, no?

MatthewPhillips 15y ago

It makes it hostile to abandonware.

gaius 15y ago
Hostile to people who use their machines for Real Work.

gaius 15y ago

Compare and contrast: http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779...

davidw 15y ago

If you want to be sure it'll work, you compile it statically, and waste a little bit of disk space and memory.

protomyth 15y ago
Trading security / bug fix updates in the process

muuh-gnu 15y ago

> This isn't the fault of the kernel team though. It is the result of having no unified platform and library release coordination, no long term plans, nothing, just chaos. Everybody just releases when he is in the mood for it. And since nothing is complete when released, devs further down the chain always go for the latest and greatest to get additional functionality. And to upgrade app1, you have to upgrade lib1 which triggers the updates of app2, app3, app4, lib3, etc. Sometimes you cant update a simple app without updating the whole desktop. The Linux dependency net appears nightmarish to everyone coming from Windows, where you have a reliable, stable base system which doesnt change for a decade and every app targets the same base system. Linux, the kernel, is only running that great because it has a dictator. But Linus' dictatorship ends at the kernel borders, he has little influence outside. The Linux desktop also needs a dictator to massively slow down the rate of uncoordinated changes and force-stabilize the ecosystem. I hoped that Mark Shuttleworth could be that man, but he then introduced Unity... but even with unity, Ubuntu is the only chance for the Linux desktop for having a single defined set of libs attractive and influential enough for app devs as a primary target so they can safely go with the library versions in Ubuntu, instead of constantly chasing the latest and greatest versions from the upstream.

jiggy2011 15y ago
Not sure why this was down voted so much, there is an element of truth to it. When you are dealing with different distributions that provide different versions of core libraries, different sound architectures , package managers and put things like executables and config files into different parts of the filesystem. I thought that the Linux standard base would be the way to solve this.
- onli 15y ago
  Probably because though there is an element of truth in it, it just sounds plain wrong. After two sentences i thought "he probably works for microsoft or another big corporation", not because it's flame, but because of the attitude to regard this as pure chaos (and having no big plan as bad). I even looked up the profile. There is kind of a release-plan, not for the whole eco-system, but that's what stable distros are for. So the remark to Ubuntu is right. But it's wrong to mix library-stability with perceived frontend-issues with Unity. Ubuntu still fulfills that role for some apps. And besides that, it isn't necessarily wrong to write new programs against new libraries. They have new features and new bugfixes. I wouldn't want the ecosystem to stagnate right now. Or ever.
  - muuh-gnu 15y ago
    > not for the whole eco-system, but that's what stable distros are for The problem is that no app dev targets stable distros, but always goes for the latest and greatest from the upstream so distros are constantly forced to update libs and change the base system. So with a stable distro, you cant get a new version of an app, because the libs of your distro are too old, and you need to upgrade the whole distro just to be able to get that new app you want. The Linux ecosystem needs one distro (say Ubuntu) to become so influential, that app devs start to primarily target it instead of the upstream. Only then will the library space stop being a moving target for end users, and only then it will be possible to upgrade app1 without triggering an automatic update of app2, which both happen to depend on the same lib. Only then will these useless practices of "packaging" and "backporting" finally stop, and devs will be simply make packages themselves, like they do on windows or osx. Only then will users be able to install a distro once, and then be able to install new apps for 5-10 years without having to upgrade the whole distro every 6 months. > I wouldn't want the ecosystem to stagnate right now. Or ever. But with an ecosystem as unstable as the current one you wont get more than 1% of the market right now. Or ever. Normal users and especially businesses simply dont want to constantly update their systems. Force them to do that, and they simply walk away.

acqq 15y ago

There is a binary compatibility for kernel. Typically it's just the user-space dynamic libraries (in Windows speak: dlls not belonging to kernel) that you miss if you have a 5 year old binary and it won't run. Linus doesn't control user-space libs, just kernel. See how jwz shows you how to run a binary of Nestcape from 1995 (17 years old) on the latest Linuxen: http://www.jwz.org/blog/2008/03/happy-run-some-old-web-browsers-day/ http://www.jwz.org/blog/2008/03/happy-run-some-old-web-brows... Your major problem if you want to make a closed source application is that the user space dynamic libraries are mostly (L)GPL licensed, so you have to avoid (L)GPL libraries to have a legally fully-library-independent closed source application. LGPL license allows closed source linking only if you link dynamically to the LGPL library (meaning: your application must depend on the externally present library which can be replaced at any time). Which is really fair, IMHO. http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_Licen...

Thangorodrim 15y ago

Well, then, perhaps I am just lucky but just a few weeks ago I was able to get a fifteen year old binary running under both centos 6 and fedora 15. I did have to fish around a bit for an old version of curses and create a symlink. It only took a few moments though. Just a data point to consider.

ajross 15y ago

You're fumbling over the term "Linux". What you're describing is platform library incompatibility. What Linus is talking about is the kernel ABI. Not the same thing. The latter is a subset of the former, obviously, but Linus can't fix the fact that library authors don't care as much about the problem. The kernel is doing its job. Userspace, not so much. Though it's not nearly as bad as you think. In general, any desktop application compiled in the last 5 years will run unmodified on any modern distro. Really, it will, and I'd challenge you to find a counterexample. But I suspect you're talking about the dependency issue. Installing something with a bunch of dependencies (because modern software has a dependency graph that looks a lot like seaweed) requires finding and installing all that stuff on your modern distro. And package names have changed, and some have been dropped from the core distro, etc... And yes, this is a mess. But seriously: if you have a binary that works alone on, say, Ubuntu Dapper, it almost certainly will run on Fedora 16 or RHEL 6.2

dhx 15y ago
Even if you were to statically compile a software build from 5 years ago, it may require newer kernel features such as inotify (instead of dnotify). At some point of time the application authors (correctly) made a decision to throw out the old and go with the new. This is not a kernel issue (because old systems such as dnotify are still supported). But from a user perspective, it looks like the kernel is to blame, even if this assumption is incorrect.
- ajross 15y ago
  From my Fedora 16 laptop: $ fgrep DNOTIFY /boot/config-3.2.9-1.fc16.x86_64 CONFIG_DNOTIFY=y Obviously it's true that dnotify is the old junk and inotify the new hotness. But it hasn't been abandoned, by either the kernel or the distros. Again, they take stuff like this very seriously. Old junk runs. Really, it does.

dfc 15y ago

What program from five years ago fails to run on debian/stable?

dfc 15y ago
I apologize for asking for specifics...

derleth 15y ago

> Ever tried to get a binary compiled 5 years ago to run on a fresh install of linux? I run older binaries on Linux all the time.

jff 15y ago

If we used static compilation for everything, this wouldn't be a problem. Our problem would then be higher memory consumption, but I can fix that for $50--at least until the next Ubuntu release comes out. Speaking of that, I wonder if there's some point at which dynamic libraries don't really help you that much. These days, even shared libraries don't seem to stop a GNOME desktop running a browser from sucking down a gig of memory; would it really kill them to have a couple more megs of static library in each program? With copy-on-write, I think things like Chrome which spawn many children would come out pretty well.

josephg 15y ago
Using shared libraries also decreases application startup time, because applications don't need to read as much code from disk. Even using an SSD I suspect the difference would be noticable for most applications.
evanlong 15y ago
One advantage to shared libs/dlls is that a security fix will be applied to all applications that depend on that. So if everyone statically links against insecure libA.a then all apps that depend on it need to ship a patch. Where as if libA is shipped as a shared library then one update needs to be applied. That's one advantage but maybe not the best.
- im3w1l 15y ago
  What if we could have opportunistic dynamic linking, where an application uses a shared library, if present and compatible, and otherwise uses the bundled? Seems to get the best of both worlds, no?