3 ms·

> ... build all my projects inside docker, using each language’s most recent stable release This has been my personal policy for the last 6 years, it works wel

by nickjj 5y ago

> ... build all my projects inside docker, using each language’s most recent stable release This has been my personal policy for the last 6 years, it works well in practice. You get the best of both worlds. A rock solid system with the flexibility to use whatever programming runtime versions you want.

user5994461 5y ago
I don't think that works anymore with the speed that languages are moving and breaking these days. If you tried to use Python 3.9.0 for example (released November 2020), it had changes in the C bindings and broke many libraries (like numpy), which was not noticed until after the stable release. That took months to fix and I'm not even sure if all packages have been fixed as of today (9 months later).
- mistrial9 5y ago
  side note - this is huge news to me that Python 3.9 broke numpy ! very interesting to hear this
- nickjj 5y ago
  > I don't think that works anymore with the speed that languages are moving and breaking these days. The beauty of this approach is you don't have to use the latest version if you don't want to, but the option is there if your app is compatible. You can still use Python 3.7.x or whatever you want. Docker has official Python images going way back.
KronisLV 5y ago
Agreed. This also has the opposite effect - if there is any old or outdated component or piece of software that you still need to be running for unfortunate reasons, there's always the possibility of putting it in a container with all of the packages and other environment configuration that it requires. That way you don't have to risk compromising the entire system and don't even have to run VMs with old OS releases, while at the same time only need to expose the ports that the software uses, if even those at all. In my eyes, access to devices and such could still use a few improvements in Docker and other competing container runtimes, but for the most part, the technology is a lifesaver! While i do think that it's nice if the same packages are also available outside of containers, for the OS of your choice, which i'm sure will also be the case for latest versions of PHP and other software, even if done by a third party shortly after Debian's new release, that's sadly not always the case. In those situations, containers indeed seem like a good choice.
Jenda_ 5y ago
From a sysadmin perspective, I'm afraid this would lead to containers lying around with random unsupported versions of various software -- you need to rebuild the container after every bug found, and upgrade the runtime (if it isn't LTS from the upstream) periodically, right? (however, I quit sysadmin job some time ago, so I'm not sure what the current trend is)

by nickjj 5y ago

user5994461 5y ago

I don't think that works anymore with the speed that languages are moving and breaking these days. If you tried to use Python 3.9.0 for example (released November 2020), it had changes in the C bindings and broke many libraries (like numpy), which was not noticed until after the stable release. That took months to fix and I'm not even sure if all packages have been fixed as of today (9 months later).

mistrial9 5y ago
side note - this is huge news to me that Python 3.9 broke numpy ! very interesting to hear this
nickjj 5y ago
> I don't think that works anymore with the speed that languages are moving and breaking these days. The beauty of this approach is you don't have to use the latest version if you don't want to, but the option is there if your app is compatible. You can still use Python 3.7.x or whatever you want. Docker has official Python images going way back.

KronisLV 5y ago

Agreed. This also has the opposite effect - if there is any old or outdated component or piece of software that you still need to be running for unfortunate reasons, there's always the possibility of putting it in a container with all of the packages and other environment configuration that it requires. That way you don't have to risk compromising the entire system and don't even have to run VMs with old OS releases, while at the same time only need to expose the ports that the software uses, if even those at all. In my eyes, access to devices and such could still use a few improvements in Docker and other competing container runtimes, but for the most part, the technology is a lifesaver! While i do think that it's nice if the same packages are also available outside of containers, for the OS of your choice, which i'm sure will also be the case for latest versions of PHP and other software, even if done by a third party shortly after Debian's new release, that's sadly not always the case. In those situations, containers indeed seem like a good choice.

Jenda_ 5y ago

From a sysadmin perspective, I'm afraid this would lead to containers lying around with random unsupported versions of various software -- you need to rebuild the container after every bug found, and upgrade the runtime (if it isn't LTS from the upstream) periodically, right? (however, I quit sysadmin job some time ago, so I'm not sure what the current trend is)