3 ms·

> Debian 8 has support until 2017 Wow, really? That's nothing! No security updates after that? > Ubuntu 1404 LTS has support until 2019 That sounds more reas

by xyby 11y ago

> Debian 8 has support until 2017 Wow, really? That's nothing! No security updates after that? > Ubuntu 1404 LTS has support until 2019 That sounds more reasonable. But still a bit short. > RHEL 7 has support until 2024 (and Centos). Interesting. Now I understand why I hear "centos" so often lately. So far, I only know Debian based distros. I wonder how much work it would be to switch to one of these two.

kasabali 11y ago
> Wow, really? That's nothing! No security updates after that? First of all, it's 2018, not 2017. For the latter point, there is now a LTS project, which provides +2 year after offical support ends, but they only support squeeze for now (since wheezy is on offical support and jessie is not released) and AFAIK it's not decided yet if jessie will be supported by LTS or not. So it may extend to 2020. If you want certainty on this regard Ubuntu LTS is also a pretty good choice. On CentOS, I don't use it so I can't comment on it in depth, but beware that number of offically supported packages are much smaller compared to Debian, so make sure the packages you want to use are supported. (There are semi-offical/unoffical repositories, but they may not be maintained as well as offical packages.) (Actually that same point applies to Ubuntu also, as only main and restricted archives are supported by Canonical and universe/multiverse is where big number of packages reside in.)
digitalzombie 11y ago
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 11y 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 11y 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 11y 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 11y 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)
buster 11y ago
Keep in mind that you can upgrade debian and ubuntu pretty nicely to a new release but not RHEL, afaik. That's a major pain point. I'd go with Debian.

by xyby 11y ago

kasabali 11y ago

> Wow, really? That's nothing! No security updates after that? First of all, it's 2018, not 2017. For the latter point, there is now a LTS project, which provides +2 year after offical support ends, but they only support squeeze for now (since wheezy is on offical support and jessie is not released) and AFAIK it's not decided yet if jessie will be supported by LTS or not. So it may extend to 2020. If you want certainty on this regard Ubuntu LTS is also a pretty good choice. On CentOS, I don't use it so I can't comment on it in depth, but beware that number of offically supported packages are much smaller compared to Debian, so make sure the packages you want to use are supported. (There are semi-offical/unoffical repositories, but they may not be maintained as well as offical packages.) (Actually that same point applies to Ubuntu also, as only main and restricted archives are supported by Canonical and universe/multiverse is where big number of packages reside in.)

digitalzombie 11y ago

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 11y 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 11y 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 11y 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 11y 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)

buster 11y ago

Keep in mind that you can upgrade debian and ubuntu pretty nicely to a new release but not RHEL, afaik. That's a major pain point. I'd go with Debian.