4 ms·

It is still easier with static compiles if you ask me: "Make sure you're running Gogs 1.64.2 or above" "Make sure you're running Gogs 1.64.2, OpenSSL 1.2e, li

It is still easier with static compiles if you ask me: "Make sure you're running Gogs 1.64.2 or above" "Make sure you're running Gogs 1.64.2, OpenSSL 1.2e, libcrypt 3.73, leftpad 2.0..." Especially when the deployment of said binaries doesn't involve anything installed on the host OS.

raimue 11y ago
"Make sure you run Foo 1.7, Bar 2.1, Baz 2.3, ..." "Make sure you update to OpenSSL 1.2e and restart all services." If you think of more than one program using the same module, shared libraries make a lot of sense.
- chm 11y ago
  They do, but static linking means the developer actually does have control of the environment. What happens if you ship the latest and greatest binary but the shared libraries aren't updated by the user?
  - raimue 11y ago
    That is why libraries guarantee API/ABI compatibility within a version number (SONAME). The package manager of your distribution will be responsible for updating the required dependencies if needed. Of course, if the user chooses to install software outside of the package manager, it is their responsibility to upgrade dependencies accordingly.
- robmccoll 11y ago
  You do run into false dependencies causing needless headaches with dynamic libraries though. There's a vulnerability in hash X in OpenSSL. One (or worse zero) of my 15 installed applications that depend on OpenSSL actually uses hash X, but in order to upgrade, I have to carefully manage those 15 dependencies. With statically linked dependencies, the hash X code wouldn't be in any of the other binaries and I only update the one (or perhaps don't have to update at all).
  - raimue 11y ago
    What do you mean by managing dependencies? You upgrade to an OpenSSL version that fixes hash X and be done with it? I don't understand your point.
    - mikecb 11y ago
      Can't upgrade if the fix was dropping the hash because it's fundamentally flawed.
      - raimue 11y ago
        That would be an ABI incompatible change. These are only allowed when increasing the compatibility version (SONAME). You would immediately notice such a change. For the usual package managers that would even require to create a new package.
    - robmccoll 11y ago
      I guess under the assumption of everyone following sane versioning practices, maintaining alias symlinks, and/or really solid package management and compatibility testing, this isn't such an issue. If the system admin was compiling a lot of their own libraries and binaries that don't necessarily follow those best practices, it becomes more of a problem. The system admin doesn't know what functionality in the library is used by each binary and weather or not the upgrade is really necessary. If the binaries are self-contained and statically linked, the maintainer of the actual software can stay abreast of security updates in the libraries that they are using and ship updates only when vulnerabilities affect functionality that they use. The sys-admin then only has to download updated binaries if truly necessary and tracking any dependencies on the end-user system becomes unneeded. Not really arguing that it's a better setup. It does mean that software maintainers have to stay active and on-top of security patches. The complexity is inherent, it's just a matter of shifting it around onto different people.
incepted 11y ago
> It is still easier with static compiles if you ask me You'd be surprised how many users have no idea whether they are running the 32bit or 64bit version of their OS. For them, running a Go binary will be anything but easy.
- weberc2 11y ago
  You'll have the same problem with dynamic linking. It's even worse when your user has to know which version of Python/Java/etc they need to run your software on. The best case for your user is a static native binary behind a package repository.

raimue 11y ago

"Make sure you run Foo 1.7, Bar 2.1, Baz 2.3, ..." "Make sure you update to OpenSSL 1.2e and restart all services." If you think of more than one program using the same module, shared libraries make a lot of sense.

chm 11y ago
They do, but static linking means the developer actually does have control of the environment. What happens if you ship the latest and greatest binary but the shared libraries aren't updated by the user?
- raimue 11y ago
  That is why libraries guarantee API/ABI compatibility within a version number (SONAME). The package manager of your distribution will be responsible for updating the required dependencies if needed. Of course, if the user chooses to install software outside of the package manager, it is their responsibility to upgrade dependencies accordingly.
robmccoll 11y ago
You do run into false dependencies causing needless headaches with dynamic libraries though. There's a vulnerability in hash X in OpenSSL. One (or worse zero) of my 15 installed applications that depend on OpenSSL actually uses hash X, but in order to upgrade, I have to carefully manage those 15 dependencies. With statically linked dependencies, the hash X code wouldn't be in any of the other binaries and I only update the one (or perhaps don't have to update at all).
- raimue 11y ago
  What do you mean by managing dependencies? You upgrade to an OpenSSL version that fixes hash X and be done with it? I don't understand your point.
  - mikecb 11y ago
    Can't upgrade if the fix was dropping the hash because it's fundamentally flawed.
    - raimue 11y ago
      That would be an ABI incompatible change. These are only allowed when increasing the compatibility version (SONAME). You would immediately notice such a change. For the usual package managers that would even require to create a new package.
  - robmccoll 11y ago
    I guess under the assumption of everyone following sane versioning practices, maintaining alias symlinks, and/or really solid package management and compatibility testing, this isn't such an issue. If the system admin was compiling a lot of their own libraries and binaries that don't necessarily follow those best practices, it becomes more of a problem. The system admin doesn't know what functionality in the library is used by each binary and weather or not the upgrade is really necessary. If the binaries are self-contained and statically linked, the maintainer of the actual software can stay abreast of security updates in the libraries that they are using and ship updates only when vulnerabilities affect functionality that they use. The sys-admin then only has to download updated binaries if truly necessary and tracking any dependencies on the end-user system becomes unneeded. Not really arguing that it's a better setup. It does mean that software maintainers have to stay active and on-top of security patches. The complexity is inherent, it's just a matter of shifting it around onto different people.

incepted 11y ago

> It is still easier with static compiles if you ask me You'd be surprised how many users have no idea whether they are running the 32bit or 64bit version of their OS. For them, running a Go binary will be anything but easy.

weberc2 11y ago
You'll have the same problem with dynamic linking. It's even worse when your user has to know which version of Python/Java/etc they need to run your software on. The best case for your user is a static native binary behind a package repository.