|
|
|
|
|
|
by iofj
3899 days ago
|
|
|
Software engineers often have a need to have their package work on multiple distributions - or even OSes, which they may know little about. They maintain the program, and try really hard not to care what it runs on. They need the SSL bug fixed on both redhat, debian and mac os X. Hence the "static linking" solutions where all the packages are controlled from the program, like virtualenv/pip. System engineers are charged with keeping various programs running on (usually) a fixed distribution/OS. They need to have a way to update SSL when there is a security issue, for all applications. They need to be able to update various libraries and have programs transparently use new or otherwise fixed versions of libraries. They also very much need the ability to uninstall packages. OS level packages are a solution written to serve the need of sysadmins. But software engineers don't care, because maintaining the correct package list and versions for 4-5 distributions is horrible. So they don't. What I don't get is why docker isn't the ideal solution for both groups. Assuming, of course, sysadmins have both ability and the inclination to insist on the sources. |
|
|
For some things, Docker is a great solution for both groups, but that requires that your organization and application meet a list of requirements. Is the application only going to be run by you, as a server? If it's going to be run elsewhere, you may not have the option to require it run on Docker or if it's going to be run as a client then you definitely don't have the option.
The conflicting goals come from the System Engineers goal of making it run on all platforms vs the System Administrators goal of making it run on this platform. System Engineers want a solution that makes it easier to abstract away the platform, System Administrators want a solution to make it easier to install on this platform. OS packages are easier as a System Administrator because it all ties into a central source of authority. Each package knows which other packages are installed on the system and which packages it needs. Fragmenting the environment makes it more difficult because you've got distinct sources of authority. Pip package A needs version 1.2 of OS package B, but pip package C needed for pip package D needs version 1.3 of OS package B. All of which you'd have no idea about until it all crashes and burns and you have to go figure out why.
OS packages are usually better in terms of installation, but pip packages are easier to create. Ubuntu's new packaging system is meant to address this, though we'll see how it goes.