6 ms·

Not really. Go doesn't use shared libraries (yet), so you're only really recompiling the end binaries. If you're using Go, you should already have the infrastr

Not really. Go doesn't use shared libraries (yet), so you're only really recompiling the end binaries. If you're using Go, you should already have the infrastructure to do this. Everything we have gets rebuilt for each go release anyway, so this is no different, just a little more immediate.

eropple 11y ago
> If you're using Go, you should already have the infrastructure to do this. Unless you're using packages in an APT or Yum repo. You instead get to wait for packages to come downstream, almost certainly not in anything approaching synchronicity. Awesome. We got away from statically linked monoliths for a reason.
- bliti 11y ago
  Feeling your pain right now. I have a service running in go that runs in multiple machines and this will keep me busy for the night. Worst is that I can't have a sysadmin do the whole process. Now QA has to sign off on it... It's no wonder things stay broken for a long time. It is a lotnif work. Sorry for the rant. :)
  - helper 11y ago
    Isn't that what automation tools are for?
    - bliti 11y ago
      You can't blindly trust automated tools. They also don't replace protocol.
      - ownagefool 11y ago
        That's why you write tests. Not that always works either, but it's not like a qa team of point and clixkers running over a manual set of those same tests will always get it right.
    - deleted 11y ago
      [deleted]
- tptacek 11y ago
  This is a problem with relying on APT for security fixes anyways. It's been particularly bad in the past for things like nginx, where we've known about memory corruption bugs for multiple days and had clients who were incapable of patching because they only had infrastructure for downloading packages. You should have tools in place to build, from source, anything that might be a significant security issue.
  - eropple 11y ago
    If my clients would pay me for it, I certainly would. But `package 'foo'` is a lot cheaper than that, turns out. And while I 100% agree about the optimal case, in practical terms you're going to see a lot better turnaround from the maintainers of Debian's OpenSSL than, say, the third-party Docker repo. A sane system not reliant on static linking 'til the cows come home is not a cure-all, but it's better than the Go situation, and is a part of why I'm super not thrilled with Go-as-infrastructure. (Go-as-app, whatever, people take that problem on themselves.)
  - xorcist 11y ago
    The problem isn't really with APT (or deb). Building a package from source is trivial. Anyone can do it, and it's completely automated. Building software from upstream source can be a lot more daunting.

eropple 11y ago

> If you're using Go, you should already have the infrastructure to do this. Unless you're using packages in an APT or Yum repo. You instead get to wait for packages to come downstream, almost certainly not in anything approaching synchronicity. Awesome. We got away from statically linked monoliths for a reason.

bliti 11y ago
Feeling your pain right now. I have a service running in go that runs in multiple machines and this will keep me busy for the night. Worst is that I can't have a sysadmin do the whole process. Now QA has to sign off on it... It's no wonder things stay broken for a long time. It is a lotnif work. Sorry for the rant. :)
- helper 11y ago
  Isn't that what automation tools are for?
  - bliti 11y ago
    You can't blindly trust automated tools. They also don't replace protocol.
    - ownagefool 11y ago
      That's why you write tests. Not that always works either, but it's not like a qa team of point and clixkers running over a manual set of those same tests will always get it right.
  - deleted 11y ago
    [deleted]
tptacek 11y ago
This is a problem with relying on APT for security fixes anyways. It's been particularly bad in the past for things like nginx, where we've known about memory corruption bugs for multiple days and had clients who were incapable of patching because they only had infrastructure for downloading packages. You should have tools in place to build, from source, anything that might be a significant security issue.
- eropple 11y ago
  If my clients would pay me for it, I certainly would. But `package 'foo'` is a lot cheaper than that, turns out. And while I 100% agree about the optimal case, in practical terms you're going to see a lot better turnaround from the maintainers of Debian's OpenSSL than, say, the third-party Docker repo. A sane system not reliant on static linking 'til the cows come home is not a cure-all, but it's better than the Go situation, and is a part of why I'm super not thrilled with Go-as-infrastructure. (Go-as-app, whatever, people take that problem on themselves.)
- xorcist 11y ago
  The problem isn't really with APT (or deb). Building a package from source is trivial. Anyone can do it, and it's completely automated. Building software from upstream source can be a lot more daunting.