12 ms·

The original model is that software developers don't package their software for distributions at all, at best they provide helper scripts that the distribution

The original model is that software developers don't package their software for distributions at all, at best they provide helper scripts that the distribution maintainers can use to do that. That's why distributions are typically either giant volunteer-run organizations like Debian or companies like RedHat or Canonical.

Klonoar 4y ago
This model doesn't necessarily work for software that developers don't want others shipping for them.
- koolba 4y ago
  Or you end up with useless packages like ancient versions of nodejs sticking around for half a decade.
  - lelanthran 4y ago
    At which point was nodejs five years older than the distro it shipped on? Not being facetious, genuinely curious.
    - koolba 4y ago
      > At which point was nodejs five years older than the distro it shipped on? https://askubuntu.com/questions/1259840/why-an-old-nodejs-version-is-installed-on-my-ubuntu-machine https://askubuntu.com/questions/1259840/why-an-old-nodejs-ve... Nodejs v4.x was "new" when Ubuntu 16.04 LTS came out. It was added to its apt repos, LTS releases are supported for 5+ years, and LTS policy is not to update major versions of software within a release. So while nodejs was pumping out new major versions every 6-months, people running Ubuntu 16.04 and installing "apt-get install nodejs" were stuck on the same ancient version.
      - indymike 4y ago
        This is what is expected on LTS releases and is what is expected by people that highly value long term support releases. That said, I think modern security and modern software development practices have obsoleted a lot of the thinking behind LTS releases.
        JohnFen 4y ago
        Sadly, modern software development practices have neutered a lot of LTS releases -- but the need for real LTS releases is stronger than ever.
        indymike 4y ago
        > but the need for real LTS releases is stronger than ever Actually, I think the LTS mentality is one of the bigger problems in security right now. The hardest problems I've had to deal with in tech all stem for LTS: * Getting an not-substantial budget to update an essential but forgotten server with custom software and an unpatched heartbleed problem. * Convincing developers to even look at old web services that have massive SQL injection and were built with libraries with known (six years ago) exploits, all running on some 13 year old version of RedHat. * Inevitable meetings where you try your best to avoid saying "I told you so" when a disclosure, cryptolocker or malware infestation happens because of the above. These are no fun because they quickly devolve into career-end bingo.
        JohnFen 4y ago
        (This entire comment is about my use of my own machines, not about the use of machines in an enterprise setting. In the enterprise, much of this is very, very different) From a security point of view, yes, you have a point. But I blame the problem on the industry shift to lumping security and feature updates together. I hate, and prevent, automatic software updates because I don't want feature changes to happen except if/when I'm ready for them. Feature updates are very disruptive, and sometimes break things horribly. If I could just get security updates, I'd allow those to automatically happen without thinking twice. LTS releases were a (poor) compromise to accomodate those of us who can't, or won't, take on random feature updating. Sadly, the LTS time periods are getting so short that they're often not effective for this purpose anymore -- so in those cases, I resort to blocking updates entirely until I'm ready for them. That's also a bad security place to be. I just don't see any other way to handle it aside from separating security and feature updating, like we used to do. But that's not going happen. So all I'm left with is LTS releases and blocking updates.
    - deleted 4y ago
      [deleted]
- sdsssss 4y ago
  [flagged]
- sdsssss 4y ago
  You can
- dTal 4y ago
  Setting aside that those developers are not good team players / open source citizens, they always have the option to ship a regular tarball with everything inside, a la Blender / Firefox / VSCode / Arduino etc... I resent having to install and maintain another package manager, and another set of base runtime libraries. I won't do it. Give me standalone binaries, give me source that compiles, but don't give me a link to some third party app store thingy.
  - attractivechaos 4y ago
    I wish all software could provide portable binaries. However, compiling portable binaries is hard. Not many developers have the skill.
    - dTal 4y ago
      Indeed. This seems like a tooling issue, and one that strikes me as more worthy of community attention than reinventing the package manager for the nth time.
      - veeti 4y ago
        Yes, and once we have the tooling to build portable .tar.gz application packages someone should come up with a tool to automatically upgrade them.
        dTal 4y ago
        Perhaps. Extrapolating the idea that .tar.gz application packages should be standalone, a better system than an external updater might be that the aforementioned build tooling includes an "update" script inside the .tar.gz. Then the user can run them at their own convenience. This is similar to how Firefox's updater works, except Firefox itself does double duty as the update script.
    - deleted 4y ago
      [deleted]
  - 4y ago
- bayesian_horse 4y ago
  Or that distributions don't want to ship. Or don't want to ship/maintain as frequently.
- goodpoint 4y ago
  Good, then we stay away from such software.
  - Klonoar 4y ago
    That sounds mutually beneficial. :)
- cardanome 4y ago
  Just use AppImage then. Or create a good old tarball. Problem solved. These should be absolute exceptions, not the rule, anyway.
- JohnFen 4y ago
  Such developers can stand up their own repository and distribute their software there, where they have complete control. And users can still install and update that software as normal.
zorr 4y ago
The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Or start messing with alternate repositories for each distro they want to support. The old model works for established software, but breaks down a little now that it becomes easier to write software applications. Personally I use my distro packages for foundational stuff (DE, systemd, tools and utilities) but I use an alternative package manager (flatpak) for most other applications. What Flatpak, Snap and AppImage try to achieve is to limit the packaging burden for both distro maintainers and application developers, so that end-user applications can become immediately available on a wide variety of distros.
- dTal 4y ago
  AppImage is not like the other two, it is fundamentally just a way to make a self-contained binary directory into a single runnable file - a way to avoid having to tell the user to extract a tarball and run a particular file inside. Convenience, nothing more. The other two define entire alternate runtimes.
  - bionade24 4y ago
    No, an Appimage still ships a dynamically linked executable + lots of dynamically linked libraries, that only link against system libraries when strictly needed, e.g glibc and libGL. Those files are bundled in a squashfs and have a script setting a custom LD_LIBRARY_PATH to the squashfs content for the binary. Snap does use this technique, too, but does more, for worse. AppImages are not comparable with statically linked binaries.
    - dTal 4y ago
      I can't make out what you're disagreeing with - you seem to be arguing against something I didn't say? The point is that the contents of an AppImage - "a dynamically linked executable + lots of dynamically linked libraries" - works just as well without all the squashfs backflips. If you can ship an AppImage, you can ship a regular ol' tarball with a binary named "RunMe" inside. The purpose of an AppImage is simply to condense such a tarball to a single runnable file, for convenience - nothing more. Meanwhile, Snap and Flatpak are package managers - what's more, they're invasive heavyweights with permanent costs that are even worse than distro package managers. Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck! They are both trying to impose some dubious vision of sandboxed apps that require bureaucracy to communicate with each other, instead of just tackling the core issue of software distribution. Maybe you even like sandboxing! But I've seen no justification why that should be co-mingled with package management.
chupasaurus 4y ago
> That's why distributions are typically either giant volunteer-run organizations like Debian or companies like RedHat or Canonical Quite a few maintaining teams are the exact same people in Debian and Ubuntu.
circuit10 4y ago
That works for big important software like Firefox or GCC, but less well for someone’s niche hobby project that maybe 5 or so other people will use
jen20 4y ago
For me, the "stop the world" distribution model is pretty broken, compared to FreeBSD Ports or similar. I don't ever want a maybe-years-old version of software, even with random security patches applied to it.
- account42 4y ago
  There are rolling release and hybrid (stable base + rolling apps) Linux distros as well.
  - jen20 4y ago
    I know - those ones don’t suffer from the same problem, typically.
intelVISA 4y ago
x86_64 ELF (SYSV) is a pretty good lingua franca, why pollute my machine with some crappy pauper?

Klonoar 4y ago

This model doesn't necessarily work for software that developers don't want others shipping for them.

koolba 4y ago
Or you end up with useless packages like ancient versions of nodejs sticking around for half a decade.
- lelanthran 4y ago
  At which point was nodejs five years older than the distro it shipped on? Not being facetious, genuinely curious.
  - koolba 4y ago
    > At which point was nodejs five years older than the distro it shipped on? https://askubuntu.com/questions/1259840/why-an-old-nodejs-version-is-installed-on-my-ubuntu-machine https://askubuntu.com/questions/1259840/why-an-old-nodejs-ve... Nodejs v4.x was "new" when Ubuntu 16.04 LTS came out. It was added to its apt repos, LTS releases are supported for 5+ years, and LTS policy is not to update major versions of software within a release. So while nodejs was pumping out new major versions every 6-months, people running Ubuntu 16.04 and installing "apt-get install nodejs" were stuck on the same ancient version.
    - indymike 4y ago
      This is what is expected on LTS releases and is what is expected by people that highly value long term support releases. That said, I think modern security and modern software development practices have obsoleted a lot of the thinking behind LTS releases.
      - JohnFen 4y ago
        Sadly, modern software development practices have neutered a lot of LTS releases -- but the need for real LTS releases is stronger than ever.
        indymike 4y ago
        > but the need for real LTS releases is stronger than ever Actually, I think the LTS mentality is one of the bigger problems in security right now. The hardest problems I've had to deal with in tech all stem for LTS: * Getting an not-substantial budget to update an essential but forgotten server with custom software and an unpatched heartbleed problem. * Convincing developers to even look at old web services that have massive SQL injection and were built with libraries with known (six years ago) exploits, all running on some 13 year old version of RedHat. * Inevitable meetings where you try your best to avoid saying "I told you so" when a disclosure, cryptolocker or malware infestation happens because of the above. These are no fun because they quickly devolve into career-end bingo.
        JohnFen 4y ago
        (This entire comment is about my use of my own machines, not about the use of machines in an enterprise setting. In the enterprise, much of this is very, very different) From a security point of view, yes, you have a point. But I blame the problem on the industry shift to lumping security and feature updates together. I hate, and prevent, automatic software updates because I don't want feature changes to happen except if/when I'm ready for them. Feature updates are very disruptive, and sometimes break things horribly. If I could just get security updates, I'd allow those to automatically happen without thinking twice. LTS releases were a (poor) compromise to accomodate those of us who can't, or won't, take on random feature updating. Sadly, the LTS time periods are getting so short that they're often not effective for this purpose anymore -- so in those cases, I resort to blocking updates entirely until I'm ready for them. That's also a bad security place to be. I just don't see any other way to handle it aside from separating security and feature updating, like we used to do. But that's not going happen. So all I'm left with is LTS releases and blocking updates.
  - deleted 4y ago
    [deleted]
sdsssss 4y ago
[flagged]
sdsssss 4y ago
You can
dTal 4y ago
Setting aside that those developers are not good team players / open source citizens, they always have the option to ship a regular tarball with everything inside, a la Blender / Firefox / VSCode / Arduino etc... I resent having to install and maintain another package manager, and another set of base runtime libraries. I won't do it. Give me standalone binaries, give me source that compiles, but don't give me a link to some third party app store thingy.
- attractivechaos 4y ago
  I wish all software could provide portable binaries. However, compiling portable binaries is hard. Not many developers have the skill.
  - dTal 4y ago
    Indeed. This seems like a tooling issue, and one that strikes me as more worthy of community attention than reinventing the package manager for the nth time.
    - veeti 4y ago
      Yes, and once we have the tooling to build portable .tar.gz application packages someone should come up with a tool to automatically upgrade them.
      - dTal 4y ago
        Perhaps. Extrapolating the idea that .tar.gz application packages should be standalone, a better system than an external updater might be that the aforementioned build tooling includes an "update" script inside the .tar.gz. Then the user can run them at their own convenience. This is similar to how Firefox's updater works, except Firefox itself does double duty as the update script.
  - deleted 4y ago
    [deleted]
- 4y ago
bayesian_horse 4y ago
Or that distributions don't want to ship. Or don't want to ship/maintain as frequently.
goodpoint 4y ago
Good, then we stay away from such software.
- Klonoar 4y ago
  That sounds mutually beneficial. :)
cardanome 4y ago
Just use AppImage then. Or create a good old tarball. Problem solved. These should be absolute exceptions, not the rule, anyway.
JohnFen 4y ago
Such developers can stand up their own repository and distribute their software there, where they have complete control. And users can still install and update that software as normal.

zorr 4y ago

The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Or start messing with alternate repositories for each distro they want to support. The old model works for established software, but breaks down a little now that it becomes easier to write software applications. Personally I use my distro packages for foundational stuff (DE, systemd, tools and utilities) but I use an alternative package manager (flatpak) for most other applications. What Flatpak, Snap and AppImage try to achieve is to limit the packaging burden for both distro maintainers and application developers, so that end-user applications can become immediately available on a wide variety of distros.

dTal 4y ago
AppImage is not like the other two, it is fundamentally just a way to make a self-contained binary directory into a single runnable file - a way to avoid having to tell the user to extract a tarball and run a particular file inside. Convenience, nothing more. The other two define entire alternate runtimes.
- bionade24 4y ago
  No, an Appimage still ships a dynamically linked executable + lots of dynamically linked libraries, that only link against system libraries when strictly needed, e.g glibc and libGL. Those files are bundled in a squashfs and have a script setting a custom LD_LIBRARY_PATH to the squashfs content for the binary. Snap does use this technique, too, but does more, for worse. AppImages are not comparable with statically linked binaries.
  - dTal 4y ago
    I can't make out what you're disagreeing with - you seem to be arguing against something I didn't say? The point is that the contents of an AppImage - "a dynamically linked executable + lots of dynamically linked libraries" - works just as well without all the squashfs backflips. If you can ship an AppImage, you can ship a regular ol' tarball with a binary named "RunMe" inside. The purpose of an AppImage is simply to condense such a tarball to a single runnable file, for convenience - nothing more. Meanwhile, Snap and Flatpak are package managers - what's more, they're invasive heavyweights with permanent costs that are even worse than distro package managers. Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck! They are both trying to impose some dubious vision of sandboxed apps that require bureaucracy to communicate with each other, instead of just tackling the core issue of software distribution. Maybe you even like sandboxing! But I've seen no justification why that should be co-mingled with package management.

chupasaurus 4y ago

> That's why distributions are typically either giant volunteer-run organizations like Debian or companies like RedHat or Canonical Quite a few maintaining teams are the exact same people in Debian and Ubuntu.

circuit10 4y ago

That works for big important software like Firefox or GCC, but less well for someone’s niche hobby project that maybe 5 or so other people will use

jen20 4y ago

For me, the "stop the world" distribution model is pretty broken, compared to FreeBSD Ports or similar. I don't ever want a maybe-years-old version of software, even with random security patches applied to it.

account42 4y ago
There are rolling release and hybrid (stable base + rolling apps) Linux distros as well.
- jen20 4y ago
  I know - those ones don’t suffer from the same problem, typically.

intelVISA 4y ago

x86_64 ELF (SYSV) is a pretty good lingua franca, why pollute my machine with some crappy pauper?