5 ms·

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

by Klonoar 4y ago

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.
    - diffeomorphism 4y ago
      That is very much missing the point. They were not "stuck", they explicitly asked to keep using that version and get support for it. Same reason Windows ltsc exists and is popular with such customers.
    - goodpoint 4y ago
      That's a feature not a bug. People use LTS because they need stable platforms they can rely on.
  - 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.

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.
  - diffeomorphism 4y ago
    That is very much missing the point. They were not "stuck", they explicitly asked to keep using that version and get support for it. Same reason Windows ltsc exists and is popular with such customers.
  - goodpoint 4y ago
    That's a feature not a bug. People use LTS because they need stable platforms they can rely on.
- 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.