Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Users Search
Help Dashboard Sign In Sign Up
Q&A Meta
Q&A
Posts Tags Edits
Ask Question

Post History

71%
+3 −0
Q&A Why/how can distro support lifetimes exceed the lifetime of their dependencies (such as Python)?

When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as ...

posted 2mo ago by alx‭  ·  edited 2mo ago by alx‭

Answer
#5: Post edited by user avatar alx‭ · 2024-03-31T20:27:11Z (about 2 months ago)
  • When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.
  • You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project. Also, one packager tends to be responsible for decades or hundreds of packages, which is not ideal. As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug. (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)
  • It can make sense because some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes. You could say that a version in those projects is EOL the day after the release.
  • In some other cases, upstream may support stable branches, but for a time that the distribution considers too short. For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total. Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.
  • Why do it? Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky. Of course, it's also risky to use an outdated version that might have bugs that were (sometimes accidentally) fixed in newer versions and nobody noticed that the old versions should be patched. And it also costs money to support old versions. But it's a balance where doing it might be worth it.
  • For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers. As long as you trust the distributors to not break those versions too often that they're unusable. I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.
  • If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.
  • When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.
  • You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project. Also, one packager tends to be responsible for hundreds of packages, which is not ideal. As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug. (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)
  • It can make sense because some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes. You could say that a version in those projects is EOL the day after the release.
  • In some other cases, upstream may support stable branches, but for a time that the distribution considers too short. For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total. Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.
  • Why do it? Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky. Of course, it's also risky to use an outdated version that might have bugs that were (sometimes accidentally) fixed in newer versions and nobody noticed that the old versions should be patched. And it also costs money to support old versions. But it's a balance where doing it might be worth it.
  • For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers. As long as you trust the distributors to not break those versions too often that they're unusable. I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.
  • If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.
#4: Post edited by user avatar alx‭ · 2024-03-31T20:26:29Z (about 2 months ago)
  • When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.
  • You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project. As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug. (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)
  • It can make sense because some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes. You could say that a version in those projects is EOL the day after the release.
  • In some other cases, upstream may support stable branches, but for a time that the distribution considers too short. For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total. Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.
  • Why do it? Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky. Of course, it's also risky to use an outdated version that might have bugs that were (sometimes accidentally) fixed in newer versions and nobody noticed that the old versions should be patched. And it also costs money to support old versions. But it's a balance where doing it might be worth it.
  • For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers. As long as you trust the distributors to not break those versions too often that they're unusable. I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.
  • If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.
  • When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.
  • You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project. Also, one packager tends to be responsible for decades or hundreds of packages, which is not ideal. As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug. (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)
  • It can make sense because some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes. You could say that a version in those projects is EOL the day after the release.
  • In some other cases, upstream may support stable branches, but for a time that the distribution considers too short. For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total. Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.
  • Why do it? Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky. Of course, it's also risky to use an outdated version that might have bugs that were (sometimes accidentally) fixed in newer versions and nobody noticed that the old versions should be patched. And it also costs money to support old versions. But it's a balance where doing it might be worth it.
  • For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers. As long as you trust the distributors to not break those versions too often that they're unusable. I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.
  • If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.
#3: Post edited by user avatar alx‭ · 2024-03-31T20:25:17Z (about 2 months ago)
  • When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.
  • You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project. As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug. (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)
  • It can make sense because some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes. You could say that a version in those projects is EOL the day after the release.
  • In some other cases, upstream may support stable branches, but for a time that the distribution considers too short. For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total. Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.
  • Why do it? Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky. Of course, it's also risky to use an outdated version that might have bugs that were (accidentally) fixed in newer versions and nobody noticed that the old versions should be patched. And it also costs money to support old versions. But it's a balance where doing it might be worth it.
  • For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers. As long as you trust the distributors to not break those versions too often that they're unusable. I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.
  • If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.
  • When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.
  • You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project. As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug. (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)
  • It can make sense because some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes. You could say that a version in those projects is EOL the day after the release.
  • In some other cases, upstream may support stable branches, but for a time that the distribution considers too short. For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total. Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.
  • Why do it? Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky. Of course, it's also risky to use an outdated version that might have bugs that were (sometimes accidentally) fixed in newer versions and nobody noticed that the old versions should be patched. And it also costs money to support old versions. But it's a balance where doing it might be worth it.
  • For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers. As long as you trust the distributors to not break those versions too often that they're unusable. I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.
  • If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.
#2: Post edited by user avatar alx‭ · 2024-03-31T20:24:09Z (about 2 months ago)
  • When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.
  • You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project. As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug. (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)
  • It can make sense because in some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes. You could say that a version in those projects is EOL the day after the release.
  • In some other cases, upstream may support stable branches, but for a time that the distribution considers too short. For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total. Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.
  • Why do it? Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky. Of course, it's also risky to use an outdated version that might have bugs that were (accidentally) fixed in newer versions and nobody noticed that the old versions should be patched. And it also costs money to support old versions. But it's a balance where doing it might be worth it.
  • For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers. As long as you trust the distributors to not break those versions too often that they're unusable. I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.
  • If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.
  • When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.
  • You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project. As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug. (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)
  • It can make sense because some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes. You could say that a version in those projects is EOL the day after the release.
  • In some other cases, upstream may support stable branches, but for a time that the distribution considers too short. For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total. Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.
  • Why do it? Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky. Of course, it's also risky to use an outdated version that might have bugs that were (accidentally) fixed in newer versions and nobody noticed that the old versions should be patched. And it also costs money to support old versions. But it's a balance where doing it might be worth it.
  • For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers. As long as you trust the distributors to not break those versions too often that they're unusable. I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.
  • If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.
#1: Initial revision by user avatar alx‭ · 2024-03-30T11:01:59Z (about 2 months ago) 
When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.

You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project.  As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug.  (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)

It can make sense because in some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes.  You could say that a version in those projects is EOL the day after the release.

In some other cases, upstream may support stable branches, but for a time that the distribution considers too short.  For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total.  Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.

Why do it?  Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky.  Of course, it's also risky to use an outdated version that might have bugs that were (accidentally) fixed in newer versions and nobody noticed that the old versions should be patched.  And it also costs money to support old versions.  But it's a balance where doing it might be worth it.

For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers.  As long as you trust the distributors to not break those versions too often that they're unusable.  I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.

If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.