3 ms·

There was an article complaining on how RHEL support a flavor of python that is very old but it doesn't work with any other popular python libraries. (update: R

There was an article complaining on how RHEL support a flavor of python that is very old but it doesn't work with any other popular python libraries. (update: RHEL 5 and below is stuck with Python 2.4 apparently) Long term support is great and all but Red Hat can only support so much, the libraries and any other ecosystem that is part of that software or programming language will be dropped by group that are responsible for it. That was my take away from the post/user comments. In general Debian is pretty rock solid imo and as a good system admin you should stay a version or two behind and you should be pretty set imo. Waiting until 2024 is crazy in term of updates and such, I rather go OpenBSD route if you want to go that long.

lmz 12y ago
It's hard to blame RH for that. Last time I checked, 2.5 was just released a few months before the first release of RHEL 5. Now they have software collections (https://www.softwarecollections.org https://www.softwarecollections.org) as a workaround, providing optional newer components.
- zokier 12y ago
  > Last time I checked, 2.5 was just released a few months before the first release of RHEL 5 "Few months" being almost 6 months (Python 2.5 was released on September 19th 2006[1], Red Hat Enterprise Linux 5 (Tikanga), 14 March 2007[2]) [1] https://www.python.org/download/releases/2.5/ https://www.python.org/download/releases/2.5/ [2] http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_5 http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_5
  - lmz 12y ago
    I'm not sure if you're implying that 6 months is too long or just providing more info. I don't think it is too long given that most distributions have stabilization periods where no new versions will be accepted e.g. Debian 8 was frozen on November 5 last year.
- kasabali 12y ago
  I agree Red Hat is hardly the guilty one. I mean, RHEL based distros have a lot of plumbing and utilities written in Python, so it is unacceptable to upgrade system Python. Now, notice it's the system Python, the main reason of Python's existence in RHEL is the system utilities written in Python, providing Python language to customers is secondary to that. So there's no wonder nobody wants to touch it for reasons other than patching security issues, and users who try to run all the shiny Python libraries and frameworks using it should be banned from using Python ever again :) Just use a newer version for god's sake (and it's not that there isn't a dozen different way of getting a newer version). (That being said, if obsolete version in RHEL fits the purpose of the user, that's great, and there is no reason for getting a new version, but it's wrong for those people to pressure developers for supporting old versions, and it's immoral for foss developers to continue supporting 10 year old releases at the expense of holding back progress. there was a post regarding that point lately, I'll try to find the link)
  - lmz 12y ago
    Yes, the problem is mostly with the users. The last time I was using CentOS 5 there were alternate repositories (e.g. IUS) providing non-conflicting newer versions of stuff. Alternatively, there's always pkgsrc.
tete 12y ago
The OpenBSD route? OpenBSD has ends support for old releases as soon as the new one comes out.

lmz 12y ago

It's hard to blame RH for that. Last time I checked, 2.5 was just released a few months before the first release of RHEL 5. Now they have software collections (https://www.softwarecollections.org https://www.softwarecollections.org) as a workaround, providing optional newer components.

zokier 12y ago
> Last time I checked, 2.5 was just released a few months before the first release of RHEL 5 "Few months" being almost 6 months (Python 2.5 was released on September 19th 2006[1], Red Hat Enterprise Linux 5 (Tikanga), 14 March 2007[2]) [1] https://www.python.org/download/releases/2.5/ https://www.python.org/download/releases/2.5/ [2] http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_5 http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_5
- lmz 12y ago
  I'm not sure if you're implying that 6 months is too long or just providing more info. I don't think it is too long given that most distributions have stabilization periods where no new versions will be accepted e.g. Debian 8 was frozen on November 5 last year.
kasabali 12y ago
I agree Red Hat is hardly the guilty one. I mean, RHEL based distros have a lot of plumbing and utilities written in Python, so it is unacceptable to upgrade system Python. Now, notice it's the system Python, the main reason of Python's existence in RHEL is the system utilities written in Python, providing Python language to customers is secondary to that. So there's no wonder nobody wants to touch it for reasons other than patching security issues, and users who try to run all the shiny Python libraries and frameworks using it should be banned from using Python ever again :) Just use a newer version for god's sake (and it's not that there isn't a dozen different way of getting a newer version). (That being said, if obsolete version in RHEL fits the purpose of the user, that's great, and there is no reason for getting a new version, but it's wrong for those people to pressure developers for supporting old versions, and it's immoral for foss developers to continue supporting 10 year old releases at the expense of holding back progress. there was a post regarding that point lately, I'll try to find the link)
- lmz 12y ago
  Yes, the problem is mostly with the users. The last time I was using CentOS 5 there were alternate repositories (e.g. IUS) providing non-conflicting newer versions of stuff. Alternatively, there's always pkgsrc.

tete 12y ago

The OpenBSD route? OpenBSD has ends support for old releases as soon as the new one comes out.