3 ms·

I worked for a company which paid for RH licenses (they don't do it anymore). Being conservative is nice, if it comes with stability, but during RHEL6, 6.4 was

by takeda 7y ago

I worked for a company which paid for RH licenses (they don't do it anymore). Being conservative is nice, if it comes with stability, but during RHEL6, 6.4 was the first version that was actually stable. As for breaking your stack, this actually is not that hard. All you have to do is not tie your application to the system. Since we're talking about Python, if you use RedHat or CentOS, I highly recommend IUS repo[1] in there you can pick which version of Python you want to use (older if you want to ensure stability, newer if you need cutting edge), you also can install multiple versions side by side, and your application is no longer tied to the OS, that means switching underlying OS or upgrading to next major version (for example to RHEL8) is no longer that should affect your application. [1] https://ius.io https://ius.io

colechristensen 7y ago
>As for breaking your stack, this actually is not that hard. All you have to do is not tie your application to the system. My point is the opposite, I want to tie my application to a reliable system so I don't have to deal with something else (pip, gem, npm, mvn, etc.) because those things break, I can't rely on them being available, I can't rely on packages always being there, I can't rely on the security of what is out there. I can rely on the system python and associated packages, I can trust that security issues will be patched, and I can trust that compatibility will be maintained. Doing that I would be stuck with an aged and aging upstream perhaps blocking adoption of new technologies, but it buys me stability and peace of mind. There are tradeoffs, for sure.