4 ms·

The comments here seem to break down into 2 camps, who can't understand each other. It would be nice if someone could actually justify the HN position instead o

The comments here seem to break down into 2 camps, who can't understand each other. It would be nice if someone could actually justify the HN position instead of just trying to cancel any dissent. I'm in the minority here on HN, I can't stand the fact that something I use daily on Windows[1] and can continue to do so forever (because it's a compiled program, and the binaries will likely work for decades) can't run the same code in Linux, where the source is in python, and both it and wx_windows have made breaking changes. For me, and my camp, it seems silly to simply write off all the code that conformed to the standards of the time, and doesn't properly bow to the changing fashions of the day. It would be like declaring all HEX wrenches and tools to be obsolete one day, and insisting that everything was either 7 sided or heptalobe instead, for "reasons" It seems completely irrational that Python 2 is excluded. This isn't like a web site where there is an active party supporting the other end, this is code written in a language that had risen to popularity based on how well it was supported. And that support has been arbitrarily withdrawn, and the HN crowd seems to cheer it on. I submit that this is part of why the year of the Linux Desktop just keeps receding into the future. [1] https://wikidpad.sourceforge.net/ https://wikidpad.sourceforge.net/

waste_monk 4y ago
>For me, and my camp, it seems silly to simply write off all the code that conformed to the standards of the time, and doesn't properly bow to the changing fashions of the day. It is not about fashion, it is about resources and manpower. Supporting Python2 is not free, especially post-EOL, and a huge amount of community effort has gone into supporting it. It is not fair to demand that Debian ensure that vendor-unsupported legacy software continue working indefinitely, especially given the environment it would be running on is a moving target that will only diverge further from what was contemporary with Python2 with each release. >This isn't like a web site where there is an active party supporting the other end This is exactly like that. The "active party" in this case just happens to be the Debian community. If you wish to continue using Python2, either stick to running it on an outdated environment such as Debian Buster that supports it natively (and accept the security consequences of doing so), take on the burden of porting it to modern Debian yourself, or seek out one of the commercial support options that exist for post-EOL Python2. You are not entitled to indefinite free labour.
- mikewarot 4y ago
  What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023. I don't understand why the Python community doesn't just run python2 syntax with a flag, similar to the std=c89 flag in gcc.
  - waste_monk 4y ago
    Debian should not ship broken software. They would need to test Python2 and make sure it works. As the environment grows increasingly divergent from what was supported in Python2's time this will become an increasing burden. Debian does not plan to maintain support for unversioned python commmands [1]. As much Python2 software assumes this is the case, continuing to provide these packages would become an ongoing burden. Python2 has not had a security update since the EOL version 2.7.18. I am not aware of any current CVE's against this version but if one were found Debian would either have to withdraw the package or patch it for any stable versions of Debian. This includes maintaining the build infrastructure for Python2 to be able to patch it if required, bug tracker, etc. as long as Python2 is offered. > What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023. I do not have numbers for this, but as the commercial Python2 support I was looking at (Activestate) is "inquire for pricing" I would imagine the equivalent community manpower/resource cost is significant. Just hosting the .deb in the APT repos is cheap - everything else around it is the expensive part. So it is not so much "the cost of removing it" and more "the cost of keeping it around". [1] https://www.debian.org/doc/packaging-manuals/python-policy/index.html#unversioned-python-commands https://www.debian.org/doc/packaging-manuals/python-policy/i...
    - mikewarot 4y ago
      So the best option seems to be to avoid any Python dependencies, as this is likely to happen again with Python 4. The idea of having to test a language seems weird, either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it? Also, why does an interpreter need security updates? That's the job of the operating system, not applications, languages, or compilers. You should be able to run any random program in a safe and secure manner, no matter how evil it is. It's the lack of capability based security that is the real problem with Linux.

waste_monk 4y ago

>For me, and my camp, it seems silly to simply write off all the code that conformed to the standards of the time, and doesn't properly bow to the changing fashions of the day. It is not about fashion, it is about resources and manpower. Supporting Python2 is not free, especially post-EOL, and a huge amount of community effort has gone into supporting it. It is not fair to demand that Debian ensure that vendor-unsupported legacy software continue working indefinitely, especially given the environment it would be running on is a moving target that will only diverge further from what was contemporary with Python2 with each release. >This isn't like a web site where there is an active party supporting the other end This is exactly like that. The "active party" in this case just happens to be the Debian community. If you wish to continue using Python2, either stick to running it on an outdated environment such as Debian Buster that supports it natively (and accept the security consequences of doing so), take on the burden of porting it to modern Debian yourself, or seek out one of the commercial support options that exist for post-EOL Python2. You are not entitled to indefinite free labour.

mikewarot 4y ago
What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023. I don't understand why the Python community doesn't just run python2 syntax with a flag, similar to the std=c89 flag in gcc.
- waste_monk 4y ago
  Debian should not ship broken software. They would need to test Python2 and make sure it works. As the environment grows increasingly divergent from what was supported in Python2's time this will become an increasing burden. Debian does not plan to maintain support for unversioned python commmands [1]. As much Python2 software assumes this is the case, continuing to provide these packages would become an ongoing burden. Python2 has not had a security update since the EOL version 2.7.18. I am not aware of any current CVE's against this version but if one were found Debian would either have to withdraw the package or patch it for any stable versions of Debian. This includes maintaining the build infrastructure for Python2 to be able to patch it if required, bug tracker, etc. as long as Python2 is offered. > What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023. I do not have numbers for this, but as the commercial Python2 support I was looking at (Activestate) is "inquire for pricing" I would imagine the equivalent community manpower/resource cost is significant. Just hosting the .deb in the APT repos is cheap - everything else around it is the expensive part. So it is not so much "the cost of removing it" and more "the cost of keeping it around". [1] https://www.debian.org/doc/packaging-manuals/python-policy/index.html#unversioned-python-commands https://www.debian.org/doc/packaging-manuals/python-policy/i...
  - mikewarot 4y ago
    So the best option seems to be to avoid any Python dependencies, as this is likely to happen again with Python 4. The idea of having to test a language seems weird, either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it? Also, why does an interpreter need security updates? That's the job of the operating system, not applications, languages, or compilers. You should be able to run any random program in a safe and secure manner, no matter how evil it is. It's the lack of capability based security that is the real problem with Linux.