3 ms·

Thanks for the warning. Really appreciate that. > you are now forcing your would-be customers to come up with a "Docker" infrastructure ... The use of Docker

Thanks for the warning. Really appreciate that. > you are now forcing your would-be customers to come up with a "Docker" infrastructure ... The use of Docker in our scenario is more like a VM (system container) than buzzwords like micro-service/service mesh/container cluster (application container). (check [1] for more comparisons) ... so setting up an Docker infrastructure should be as easy as installing the docker package in one of their Linux box. At least that's our plan. > You would create an artificial dependency ... Actually we have been delivering the product, which contains many Linux native binaries/libraries, to many different customers for many years. They all have different working environments, ranging from RHEL 5.2 to the latest release of Ubuntu. The solution we have been relying on is to build all the binaries as static-linked ones. To accomplish this, we have to maintain out-of-tree patches (some of the products are modified FOSS) to build scripts, which is a mess. So from our perspective, containerizing our product IS a direct way to eliminate the difficulty supporting varied environments and maintaining out-of-tree scripts at once. We do add some dependency about docker, but we can provide a unified environment which removes all legacy dependencies. It should be a plus. [1] https://containerjournal.com/2016/07/25/system-containers-vs-application-containers-difference-matter/ https://containerjournal.com/2016/07/25/system-containers-vs...

Annatar 7y ago
You should not need to build static libraries if you pick the oldest RHEL you can find among your customers: the GNU people claim that their libc is backwards-compatible, so your executables and libraries should work with the latest glibc. Building static executables, while convenient, opens your customers to security risk: where rebuilding one shared object library would suffice, now they need entire new binaries. There is a reason why for example Solaris and illumos do not deliver static libraries. That's the reason why, to prevent one from doing exactly what you are doing for the reason I described.

Annatar 7y ago

You should not need to build static libraries if you pick the oldest RHEL you can find among your customers: the GNU people claim that their libc is backwards-compatible, so your executables and libraries should work with the latest glibc. Building static executables, while convenient, opens your customers to security risk: where rebuilding one shared object library would suffice, now they need entire new binaries. There is a reason why for example Solaris and illumos do not deliver static libraries. That's the reason why, to prevent one from doing exactly what you are doing for the reason I described.