4 ms·

> Today, with containers becoming increasingly the de facto means This assertion makes no sense at all and entirely misses the whole point of shared/dynamic li

> Today, with containers becoming increasingly the de facto means This assertion makes no sense at all and entirely misses the whole point of shared/dynamic libraries. It's like a buzzword is a magic spell that makes some people forget the entire history and design requirements up to that very moment.

ithkuil 7y ago
Sometimes buzzwords make sense, in the right context. This was the right context. Assuming you use containers, you're likely to not log into them and keep them up to date and secure by running apt-get upgrade. The most common workflow is indeed: build your software in your CI system, in the last step create a container with your software and its dependencies. Then update your deployment with a new version of the whole image. A container image is for all intents and purposes the new "static binary". Yes, technically you can look inside it, yes technically you can (and you do) use dynamic linking inside the container itself. But as long as the workflow is the one depicted above, the environment no longer has the requirements that led to the design of dynamic linking. It's possible to have alternative workflows for building containers: you could fiddle with layers and swap an updated base OS under a layer containing your compiled application. I don't how common is that, but I'm sure somebody will want/have to do it. It all boils down to whether developers still maintain control over the full deployment pipeline as containers penetrate the enterprises (i.e. whether re retain the "shift to the left", another buzzword for you). Containers are not just a technical solution, they are the embodiment of the desire of developers to free themselves from the tyranny of filing tickets and waiting days to deploy their apps. But that leaves the security departments in enterprises understandably worried as most of those developers are focused on shipping features and often neglecting (or ignoring) security concerns around things that live one layer below the application they write.
AnIdiotOnTheNet 7y ago
Shared libraries have largely proven that they aren't a good idea, which is why containers are so popular. Between conflicts and broken compatibility between updates, shared libraries have become more trouble than they are worth. I think they still make sense for base-system libraries, but unfortunately there is no agreed upon definition of 'base-system' in the wild west of Linux.

ithkuil 7y ago

Sometimes buzzwords make sense, in the right context. This was the right context. Assuming you use containers, you're likely to not log into them and keep them up to date and secure by running apt-get upgrade. The most common workflow is indeed: build your software in your CI system, in the last step create a container with your software and its dependencies. Then update your deployment with a new version of the whole image. A container image is for all intents and purposes the new "static binary". Yes, technically you can look inside it, yes technically you can (and you do) use dynamic linking inside the container itself. But as long as the workflow is the one depicted above, the environment no longer has the requirements that led to the design of dynamic linking. It's possible to have alternative workflows for building containers: you could fiddle with layers and swap an updated base OS under a layer containing your compiled application. I don't how common is that, but I'm sure somebody will want/have to do it. It all boils down to whether developers still maintain control over the full deployment pipeline as containers penetrate the enterprises (i.e. whether re retain the "shift to the left", another buzzword for you). Containers are not just a technical solution, they are the embodiment of the desire of developers to free themselves from the tyranny of filing tickets and waiting days to deploy their apps. But that leaves the security departments in enterprises understandably worried as most of those developers are focused on shipping features and often neglecting (or ignoring) security concerns around things that live one layer below the application they write.

AnIdiotOnTheNet 7y ago

Shared libraries have largely proven that they aren't a good idea, which is why containers are so popular. Between conflicts and broken compatibility between updates, shared libraries have become more trouble than they are worth. I think they still make sense for base-system libraries, but unfortunately there is no agreed upon definition of 'base-system' in the wild west of Linux.