5 ms·

I hate to sound overly pessimistic, and I really appreciate the nice idea of having a more intelligent binary format. But I really cannot see the point of havin

by cnvogel 17y ago

I hate to sound overly pessimistic, and I really appreciate the nice idea of having a more intelligent binary format. But I really cannot see the point of having "fat" binaries. Programs under Linux (and other unixy operating systems) already come in package files (debs under Debians, pkg under xBSD, rpms under RedHats etc.). The distinction about which binary to install could easily be done at install time, with a suitably extended package format. This would be much easier to accomplish, and wouldn't need changes to core components. And while I see the geek-value of having a multi-platform bootable CD (USB-stick, harddisk, ...) it's hardly news: AFS (the network filesystem) had "magic" symlinks that make /afs/your.site/bin and .../lib point to a architecture-specific directory for a long time. So if needed it could easily be solved by that, or some of the emerging userspace or merging filesystems available under Linux and the BSDs.

blasdel 17y ago
The majority of the value is in dealing with the i386 / x86_64 bifurcation of libraries, which is handled abysmally by the extant binary package management systems.
makecheck 17y ago
The problem is that packages aren't as useful as they should be; I actually prefer solutions that fall outside of package managers, because I am forced to rebuild from source (without the package manager) more often than I'd like. For instance, I usually need to ignore packages whenever I can't be root, or when I need more than one version of something at a time. While many packages "can" handle these things, it is often a matter of improperly maintained packages (e.g. RPMs might be relocatable, but not all of them are; it is too flaky to rely on this ability).
antonovka 17y ago
I'm not so convinced that a centralized distribution authority that introduces a significant turn-around time (months or even years), patches the software as they see fit, and enforces their own licensing ethos is the best model for programmers to get their software to end-users/consumers. Of course, there are two good reasons 'fatelf' has not been implemented before, and it has nothing to do with packages: http://www.google.com/patents/about?id=b3wiAAAAEBAJ&dq=5432937 http://www.google.com/patents/about?id=b3wiAAAAEBAJ&dq=5... http://www.google.com/patents/about?id=MQQnAAAAEBAJ&dq=5604905 http://www.google.com/patents/about?id=MQQnAAAAEBAJ&dq=5...
- fungi 17y ago
  run your own repo or distribute your own packages from your own website, no need to be centralised.
  - antonovka 17y ago
    That's way, way, way more complicated than: 1) Build a binary, put it on a DMG 2) User clicks download link, drags to any directory they want. Trying to build packages that continue to work across releases and as libraries get updated and packages change -- and operate in a compatible manner with the built-in packages -- is surprisingly difficult. Why don't more people do it? The only 3rd-party packages I come across are RedHat RPMs, and half the time, they're broken. I almost never come across 3rd party apt/yum repositories run by corporations, and the few times I have, they've been very broken (remember Ximian? http://en.wikipedia.org/wiki/Ximian http://en.wikipedia.org/wiki/Ximian)

by cnvogel 17y ago

blasdel 17y ago

The majority of the value is in dealing with the i386 / x86_64 bifurcation of libraries, which is handled abysmally by the extant binary package management systems.

makecheck 17y ago

The problem is that packages aren't as useful as they should be; I actually prefer solutions that fall outside of package managers, because I am forced to rebuild from source (without the package manager) more often than I'd like. For instance, I usually need to ignore packages whenever I can't be root, or when I need more than one version of something at a time. While many packages "can" handle these things, it is often a matter of improperly maintained packages (e.g. RPMs might be relocatable, but not all of them are; it is too flaky to rely on this ability).

antonovka 17y ago

I'm not so convinced that a centralized distribution authority that introduces a significant turn-around time (months or even years), patches the software as they see fit, and enforces their own licensing ethos is the best model for programmers to get their software to end-users/consumers. Of course, there are two good reasons 'fatelf' has not been implemented before, and it has nothing to do with packages: http://www.google.com/patents/about?id=b3wiAAAAEBAJ&dq=5432937 http://www.google.com/patents/about?id=b3wiAAAAEBAJ&dq=5... http://www.google.com/patents/about?id=MQQnAAAAEBAJ&dq=5604905 http://www.google.com/patents/about?id=MQQnAAAAEBAJ&dq=5...

fungi 17y ago
run your own repo or distribute your own packages from your own website, no need to be centralised.
- antonovka 17y ago
  That's way, way, way more complicated than: 1) Build a binary, put it on a DMG 2) User clicks download link, drags to any directory they want. Trying to build packages that continue to work across releases and as libraries get updated and packages change -- and operate in a compatible manner with the built-in packages -- is surprisingly difficult. Why don't more people do it? The only 3rd-party packages I come across are RedHat RPMs, and half the time, they're broken. I almost never come across 3rd party apt/yum repositories run by corporations, and the few times I have, they've been very broken (remember Ximian? http://en.wikipedia.org/wiki/Ximian http://en.wikipedia.org/wiki/Ximian)