3 ms·

Don't do it. Customers hate it when you don't deliver clean operating system packages for the platform they run and they consider anything less unprofessional.

Don't do it. Customers hate it when you don't deliver clean operating system packages for the platform they run and they consider anything less unprofessional. I'm talking about enterprises and governmental institutions, not web companies. Think of the consequences: while you might find "Docker" cool, by delivering your software as a "Docker" image, you are now forcing your would-be customers to come up with a "Docker" infrastructure just to be able to run your software. You would create an artificial dependency, because for OS packages they need neither additional software nor knowledge to install and run yours.

qlk1123 7y ago
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.

qlk1123 7y ago

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.