5 ms·

Rolling out a new binary is a happy path process that gets used all the time; what's the problem here?

Spivak 6y ago
Yeah, I don't really understand the hate containers get for this. If the people who run your software aren't updating it you're screwed anyway. I promise you'll be way more disappointed if you assume that the system libs in the wild will be patched and up to date. Like if building a pet app is your company/team's job then containers more than fine. If you're a distro maintainer that has thousands on thousands of packages then sharing libs starts to make a lot more sense.
- deleted 6y ago
  [deleted]
- naniwaduni 6y ago
  > If the people who run your software aren't updating it you're screwed anyway. They're screwed. Hopefully you aren't. Hopefully.
- cbmuser 6y ago
  > Like if building a pet app is your company/team's job then containers more than fine. If you're a distro maintainer that has thousands on thousands of packages then sharing libs starts to make a lot more sense. The problem is that distributions get their software from upstream developers. And if upstream decides to go static or use embedded code copies, the maintainers have much more work trying to untangle everything. In my experience, packaging Go software for Linux distributions is very frustrating and tedious because of that. Packaging Python or C/C++ software is much easier.
  - dgoldstein0 6y ago
    is it really that bad to distribute statically-linked go binaries in a distro? Or rather, perhaps the better question - what's the dynamic linking benefit that a distro can't live without? Wondering since the application developers I know seem to prefer static linking.
    - cygx 6y ago
      Security fixes, for one. It's more convenient to rebuild one shared library instead of having to rebuild all downstream consumers.
      - dgoldstein0 6y ago
        hm, fun. That seems understandable given the status quo. I can't help but wonder if we'd all just benefit from better build systems, so that "rebuilding all downstream consumers" wouldn't be hard.
  - Carpetsmoker 6y ago
    This is ironic, because Go in much easier to build than C or C++, especially since the introduction of Go modules. Perhaps this "untangling" isn't the best idea, at least not always?
    - m4rtink 6y ago
      Unbundling is often necessary due to these issues: - the bundled things might have unclear licensing - bundling stuff that is available in the repos is sub optimal, as the repo version will be updated for security issues while the bundled version will not - you can use some mechanism to mark what stuff is bundled in a package, but then you need to make sure the bundled thing is patched and rebuild each thing bundling it, where with system wide dependency you just update that and you are done
      - Carpetsmoker 6y ago
        It's pretty rare there are parts with "unclear" licensing. Does it happen? Sure. But "often"? I'm fairly sure that almost all projects are receptive to updates for dependencies with security issues; I don't see why a distro needs to "untangle" anything for them. > with system wide dependency you just update that and you are done Unless the system-wide update won't work with your program. The entire point of the Go tooling is that you can reliably and consistently build your software, and replacing random parts to create a weird unsupported (by the actual developers anyway) version is something the Go tooling was never designed to support: it goes exactly against what it was designed to do. Hence my previous comment: perhaps this isn't the best of ideas.
        m4rtink 6y ago
        This talk (from 2011 but still very relevant today) mentions some if the licensing and other issues package maintainers have to face: https://www.youtube.com/watch?v=fRk97h1FLow https://www.youtube.com/watch?v=fRk97h1FLow
  - AnIdiotOnTheNet 6y ago
    The just leave it out of your distribution's repo. If it is a static binary then it is already easy to distribute so no one needs the repo.
- vmchale 6y ago
  containers aren't for binaries/reproducible builds. Actually they're quite bad for it and make caching hard.
adrianN 6y ago
Maybe for software that runs on computers that you manage. But what about end-user software?
- spenczar5 6y ago
  Isn't that still broken if code is dynamically linked? If you don't control the end-user platform, you're out of luck anyway; static builds neither help nor hurt.
- caymanjim 6y ago
  Do you think it's easier for end-users to update Python packages on their own, or just install the latest version of the app that they know about?
  - drran 6y ago
    For Linux, it's easier to just perform update. For half-developed OS'es, it's easier to download installer, then Next, Next, Agree, Next, No, Next, wait, Finish.
    - young_unixer 6y ago
      The irony being that in the fully developed OS I experience: - Outdated packages - Having to build from source when the package is not in the repos - Failed builds for no good reason - Unability to have many versions of that same packages - having to install log(n) build tools if I want to build n packages - etc while in half-developed OS'es everything just works (application-wise, at least)
  - dragonwriter 6y ago
    Since either can be automated in the distributed software itself, I'd say they are both equally easy for the end-user, if the developer really cares.
- pas 6y ago
  You can pre-build the static bin for the target platforms, you know exactly what are the bits in the blob on the user's box, and you can ship a binary diff and do incremental evergreen auto-updates. Probably faster and less brittle than testing/shipping and keeping Python up to date on the user's box.
cbmuser 6y ago
The problem is that you need to keep track of all the binaries on your system which have embedded code copies.
- hnarn 6y ago
  This is a solved problem, its why apt and yum and all the other package managers exist. And/or use something like Ansible.

Yeah, I don't really understand the hate containers get for this. If the people who run your software aren't updating it you're screwed anyway. I promise you'll be way more disappointed if you assume that the system libs in the wild will be patched and up to date. Like if building a pet app is your company/team's job then containers more than fine. If you're a distro maintainer that has thousands on thousands of packages then sharing libs starts to make a lot more sense.

deleted 6y ago
[deleted]
naniwaduni 6y ago
> If the people who run your software aren't updating it you're screwed anyway. They're screwed. Hopefully you aren't. Hopefully.
cbmuser 6y ago
> Like if building a pet app is your company/team's job then containers more than fine. If you're a distro maintainer that has thousands on thousands of packages then sharing libs starts to make a lot more sense. The problem is that distributions get their software from upstream developers. And if upstream decides to go static or use embedded code copies, the maintainers have much more work trying to untangle everything. In my experience, packaging Go software for Linux distributions is very frustrating and tedious because of that. Packaging Python or C/C++ software is much easier.
- dgoldstein0 6y ago
  is it really that bad to distribute statically-linked go binaries in a distro? Or rather, perhaps the better question - what's the dynamic linking benefit that a distro can't live without? Wondering since the application developers I know seem to prefer static linking.
  - cygx 6y ago
    Security fixes, for one. It's more convenient to rebuild one shared library instead of having to rebuild all downstream consumers.
    - dgoldstein0 6y ago
      hm, fun. That seems understandable given the status quo. I can't help but wonder if we'd all just benefit from better build systems, so that "rebuilding all downstream consumers" wouldn't be hard.
- Carpetsmoker 6y ago
  This is ironic, because Go in much easier to build than C or C++, especially since the introduction of Go modules. Perhaps this "untangling" isn't the best idea, at least not always?
  - m4rtink 6y ago
    Unbundling is often necessary due to these issues: - the bundled things might have unclear licensing - bundling stuff that is available in the repos is sub optimal, as the repo version will be updated for security issues while the bundled version will not - you can use some mechanism to mark what stuff is bundled in a package, but then you need to make sure the bundled thing is patched and rebuild each thing bundling it, where with system wide dependency you just update that and you are done
    - Carpetsmoker 6y ago
      It's pretty rare there are parts with "unclear" licensing. Does it happen? Sure. But "often"? I'm fairly sure that almost all projects are receptive to updates for dependencies with security issues; I don't see why a distro needs to "untangle" anything for them. > with system wide dependency you just update that and you are done Unless the system-wide update won't work with your program. The entire point of the Go tooling is that you can reliably and consistently build your software, and replacing random parts to create a weird unsupported (by the actual developers anyway) version is something the Go tooling was never designed to support: it goes exactly against what it was designed to do. Hence my previous comment: perhaps this isn't the best of ideas.
      - m4rtink 6y ago
        This talk (from 2011 but still very relevant today) mentions some if the licensing and other issues package maintainers have to face: https://www.youtube.com/watch?v=fRk97h1FLow https://www.youtube.com/watch?v=fRk97h1FLow
- AnIdiotOnTheNet 6y ago
  The just leave it out of your distribution's repo. If it is a static binary then it is already easy to distribute so no one needs the repo.
vmchale 6y ago
containers aren't for binaries/reproducible builds. Actually they're quite bad for it and make caching hard.

adrianN 6y ago

Maybe for software that runs on computers that you manage. But what about end-user software?

spenczar5 6y ago
Isn't that still broken if code is dynamically linked? If you don't control the end-user platform, you're out of luck anyway; static builds neither help nor hurt.
caymanjim 6y ago
Do you think it's easier for end-users to update Python packages on their own, or just install the latest version of the app that they know about?
- drran 6y ago
  For Linux, it's easier to just perform update. For half-developed OS'es, it's easier to download installer, then Next, Next, Agree, Next, No, Next, wait, Finish.
  - young_unixer 6y ago
    The irony being that in the fully developed OS I experience: - Outdated packages - Having to build from source when the package is not in the repos - Failed builds for no good reason - Unability to have many versions of that same packages - having to install log(n) build tools if I want to build n packages - etc while in half-developed OS'es everything just works (application-wise, at least)
- dragonwriter 6y ago
  Since either can be automated in the distributed software itself, I'd say they are both equally easy for the end-user, if the developer really cares.
pas 6y ago
You can pre-build the static bin for the target platforms, you know exactly what are the bits in the blob on the user's box, and you can ship a binary diff and do incremental evergreen auto-updates. Probably faster and less brittle than testing/shipping and keeping Python up to date on the user's box.

cbmuser 6y ago

The problem is that you need to keep track of all the binaries on your system which have embedded code copies.

hnarn 6y ago
This is a solved problem, its why apt and yum and all the other package managers exist. And/or use something like Ansible.