3 ms·

If you don't have glibc in each app bundle, it won't run everywhere. Different distros have different versions of glibc and it's very easy to end up in a situat

If you don't have glibc in each app bundle, it won't run everywhere. Different distros have different versions of glibc and it's very easy to end up in a situation where you use some symbol that's not defined in the system one.

probonopd 11y ago
Which is why you want to build on a system that is using an older version of glibc than the systems you want to run your software on. Assuming that glibc does't break backward compatibility, which it really shouldn't (and in practice, rarely ever did). Or use https://github.com/probonopd/AppImageKit/tree/master/LibcWrapGenerator https://github.com/probonopd/AppImageKit/tree/master/LibcWra...
inopinatus 11y ago
This makes a mockery of shared libraries. The technical debt will accrue and run unfathomably deep. Security failures due to currency issues are simply the most obvious. The insoluble mystery bugs of mismatched dependencies will plague application developers that choose this distribution strategy.
- _hyn3 11y ago
  Yay for hyperbole ;) Shared libraries are most useful when matched within a specific distribution's package/version chain. Tying a third-party distributed package to a given shared library, on the other hand, is less helpful than just supplying the expected, tested, and supported library upfront and still let knowledgeable operators do what they will on their chosen platform. No technical debt is accrued if the libs are truly interchangeable anyway, but especially if they are not, this stands a better shot at fixing it.
  - inopinatus 11y ago
    Your suggestion amounts to advocacy of tight coupling, which massively dilutes the long-term benefit of shared libraries and leads developers under pressure of expediency into a tangled thicket of anti-patterns. This is an illustration of how technical debt is accrued, and I've seen it umpteen times, never to the good.
chei0aiV 11y ago
If you don't have Linux in each app bundle, it won't run everywhere. Linux breaks userspace ABI sometimes.

probonopd 11y ago

Which is why you want to build on a system that is using an older version of glibc than the systems you want to run your software on. Assuming that glibc does't break backward compatibility, which it really shouldn't (and in practice, rarely ever did). Or use https://github.com/probonopd/AppImageKit/tree/master/LibcWrapGenerator https://github.com/probonopd/AppImageKit/tree/master/LibcWra...

inopinatus 11y ago

This makes a mockery of shared libraries. The technical debt will accrue and run unfathomably deep. Security failures due to currency issues are simply the most obvious. The insoluble mystery bugs of mismatched dependencies will plague application developers that choose this distribution strategy.

_hyn3 11y ago
Yay for hyperbole ;) Shared libraries are most useful when matched within a specific distribution's package/version chain. Tying a third-party distributed package to a given shared library, on the other hand, is less helpful than just supplying the expected, tested, and supported library upfront and still let knowledgeable operators do what they will on their chosen platform. No technical debt is accrued if the libs are truly interchangeable anyway, but especially if they are not, this stands a better shot at fixing it.
- inopinatus 11y ago
  Your suggestion amounts to advocacy of tight coupling, which massively dilutes the long-term benefit of shared libraries and leads developers under pressure of expediency into a tangled thicket of anti-patterns. This is an illustration of how technical debt is accrued, and I've seen it umpteen times, never to the good.

chei0aiV 11y ago

If you don't have Linux in each app bundle, it won't run everywhere. Linux breaks userspace ABI sometimes.