Poettering: Revisiting how we put together Linux systems

When I want to use python I can't rely on distro python at all. I can't use any of the packages they use internally.

The apache servers we use are not distro provided. The java tomcat installations are not the ones provided for distributions. I can't rely on distro provided dependencies for any of the software I want to use because distributions do not provide the versions I need, and even if they did they wouldn't maintain it in a way useful for me...

And this is not a small problem. I deal with hundreds of applications, several thousands of servers. All of it is a mixture of in house software and external software. I have to deal with data that gets exchanged between dozens of different applications made by half a dozen different application development groups. Languages that get used range from C++, to Java, to Node.JS, python, ruby, and a massive amount of perl and shell... Some of the stuff has been under development for almost 20 years, some of it is brand new following latest trends, some is stuff that hasn't been touched in 7 years, but is still expected to work as well as the first day it was deployed on a secure OS on modern hardware. The complexity is mind boggling sometimes.

What do I do about it in Linux? I can deal with it and make it work, but it's not easy. It needs custom ways to setup environments, custom ways to deploy application configs and metadata... lots of perl, lots of puppet, lots of custom packages.

(Oh, and I came from Ops background first.)

Business/Users needs dictate how applications behave and are written. How applications are written dictate the environment that needs to be provided by the OS. If you think that it's proper that the OS should dictate how applications look and behave you are looking at things completely backwards; The job of the OS is to make it as easy to develop and run applications as possible...

Distributions really have only two choices in this sort of situation, long term. Either embrace it and get their inputs into the design by contributing upstream, or see themselves minimized as users realize there is better tools to solve their problems. I have no doubt that the containerized approach will eventually find acceptance, though. It's just a better way.