3 ms·

If you have a good CI pipeline, "patching" is all automatic. A security bugfix just got pushed for Go 1.5. Since all my apps are dockerized based on the offici

If you have a good CI pipeline, "patching" is all automatic. A security bugfix just got pushed for Go 1.5. Since all my apps are dockerized based on the official golang image and are built by CI, as soon as the fix was published it was included in the next commit and pushed as part of that build. No intervention required. Similarly all dependent packages are pulled as part of the build so patches/fixes in them are automatically updated as well (note that vendoring would break this).

notacoward 11y ago
"as soon as the fix was published it was included in the next commit and pushed as part of that build" Lovely for your developers, or if you're deploying it yourself as part of a service. Not so hot for people who are actually running the code you shipped them last week, on their own hardware. Monolithic statically-linked blobs aren't doing them any favors.
- matt_wulfeck 11y ago
  I would heartily disagree, as a guy that runs the code. One of the benefits of these statically compiled binaries is that they are not coupled to each other. Everything doesn't have to be upgraded at the very same time.
  - notacoward 11y ago
    There's good coupling and there's bad coupling, and a semi-famous quote about learning the wrong lesson. "If a cat sits on a hot stove, that cat won't sit on a hot stove again. That cat won't sit on a cold stove either." It sounds like you've been burned by bad coupling. Sure, upgrading one thing and having something else break sucks. However, having to upgrade a hundred things because that one thing that's statically linked into all of them (like your SSL library) had a bug also sucks. It's like Scylla and Charybdis. They're both bad, but it is possible to steer between them. The dual nature of this problem was recognized decades ago. It's why we came up with things like API versions and even the symbol versioning that you probably don't realize is already supported by your system's loader. Responsible developers can use these things to make sure that compatible fixes take effect where they need to without relinking, while incompatible changes affect only new code compiled and linked with the new header files etc. That's good coupling - the kind that reduces risk and total work. Unfortunately, responsible developers are in short supply. Worse, faced with a plethora of irresponsible developers who don't know how to make a change without breaking stuff, a lot of people are reaching for the ugly workaround - static linking, including the kind that's disguised as containers - instead of solutions that will last. They've veered away from Scylla, right into Charybdis's maw. I made that mistake once myself once - perhaps more than once - until I realized I was getting just as burned by the "solution" as I was by the original problem. I suppose more people will have to go through that same process before the situation really improves.
    - matt_wulfeck 11y ago
      > Responsible developers can use these things to make sure that compatible fixes take effect where they need to without relinking, while incompatible changes affect only new code compiled and linked with the new header files etc. That's good coupling - the kind that reduces risk and total work. I admit I do not know very much about this. Thanks for sharing! I admit I'm definitely not the most competent developer but I try.
nyan4 11y ago
I've yet to see any organization that is planning to be around for more that 10 years buying into this. > all my apps are dockerized That might be true in a 2-years old startup with 5 employees. Technologies change every few years. Linux distributions managed has been providing upgrade paths for software for two decades by unbundling components and tracking dependencies.

notacoward 11y ago

"as soon as the fix was published it was included in the next commit and pushed as part of that build" Lovely for your developers, or if you're deploying it yourself as part of a service. Not so hot for people who are actually running the code you shipped them last week, on their own hardware. Monolithic statically-linked blobs aren't doing them any favors.

matt_wulfeck 11y ago
I would heartily disagree, as a guy that runs the code. One of the benefits of these statically compiled binaries is that they are not coupled to each other. Everything doesn't have to be upgraded at the very same time.
- notacoward 11y ago
  There's good coupling and there's bad coupling, and a semi-famous quote about learning the wrong lesson. "If a cat sits on a hot stove, that cat won't sit on a hot stove again. That cat won't sit on a cold stove either." It sounds like you've been burned by bad coupling. Sure, upgrading one thing and having something else break sucks. However, having to upgrade a hundred things because that one thing that's statically linked into all of them (like your SSL library) had a bug also sucks. It's like Scylla and Charybdis. They're both bad, but it is possible to steer between them. The dual nature of this problem was recognized decades ago. It's why we came up with things like API versions and even the symbol versioning that you probably don't realize is already supported by your system's loader. Responsible developers can use these things to make sure that compatible fixes take effect where they need to without relinking, while incompatible changes affect only new code compiled and linked with the new header files etc. That's good coupling - the kind that reduces risk and total work. Unfortunately, responsible developers are in short supply. Worse, faced with a plethora of irresponsible developers who don't know how to make a change without breaking stuff, a lot of people are reaching for the ugly workaround - static linking, including the kind that's disguised as containers - instead of solutions that will last. They've veered away from Scylla, right into Charybdis's maw. I made that mistake once myself once - perhaps more than once - until I realized I was getting just as burned by the "solution" as I was by the original problem. I suppose more people will have to go through that same process before the situation really improves.
  - matt_wulfeck 11y ago
    > Responsible developers can use these things to make sure that compatible fixes take effect where they need to without relinking, while incompatible changes affect only new code compiled and linked with the new header files etc. That's good coupling - the kind that reduces risk and total work. I admit I do not know very much about this. Thanks for sharing! I admit I'm definitely not the most competent developer but I try.

nyan4 11y ago

I've yet to see any organization that is planning to be around for more that 10 years buying into this. > all my apps are dockerized That might be true in a 2-years old startup with 5 employees. Technologies change every few years. Linux distributions managed has been providing upgrade paths for software for two decades by unbundling components and tracking dependencies.