2 ms·
> shouldn’t protect against differences between that version and a new OS version What does "should" in this context even mean? They don't, because they're not
by seba_dos1 5y ago
> shouldn’t protect against differences between that version and a new OS version
What does "should" in this context even mean? They don't, because they're not meant to do that. They can be used to shield you from some differences, and for many use cases that subset is all that matters, but they don't and can't shield you from all of them.
- SilasX 5y agoI was asking to clarify what your very confusing sentence meant. Because it seemed to be saying that, if I define a VM to use OS 1.2.3, because I know my app will work with that version, then my app on that VM should cease to work when 1.3.0 is released. And that seems dubious.
- seba_dos1 5y agoYou seem to confuse containers with virtual machines. Those are very different concepts that solve different problems. You can't rely on containers alone if your goal is to ensure that your app will work on future operating systems. That's not something containers do. They only let you provide your own user space to run in a quasi-isolated environment, no more than that. You're still using the host's kernel which can still screw you up in multitude of ways (which is exactly what I said in my earlier comment), and you're still limited by API guarantees that the tools you use to make containers are providing you.
- hedora 5y agoThis can definetly happen in both directions (kernel too old, app too old). For example, apache can no longer run with SSL enabled on current synology NAS's docker environments.