5 ms·

The primary reason to use a stable/long term distribution is to avoid updates which break my workflow, not to avoid security holes. For Debian the most visible

The primary reason to use a stable/long term distribution is to avoid updates which break my workflow, not to avoid security holes. For Debian the most visible example of that is that in Debian Stable default repos you only have Firefox ESR, which helps avoid a lot of pain for the user. There are other examples, but nothing breaks my workflow as much as new Firefox releases.

bayindirh 5y ago
Moreover, Debian Stable has a 24H security fix deadline, which voluntarily forces them to fix a lot of security holes pretty quickly. Don't they back port security fixes to stable branch too? I'm a testing user, so I don't follow Stable's package updates very closely.
- 0xC0ncord 5y ago
  Most bugs that get backported to stable kernels only get backported if they are serious enough or have a CVE assigned to them. Many bugs with potential security implications go unfixed because of this.
  - bayindirh 5y ago
    Oh, OK. I learned something important today. Thanks a lot.
    - _joel 5y ago
      Yea, it's not just desktop either but having stable releases for server workloads is pretty much essential. If there's no need to update for any required feature in a later version then doing updates for the sake of it just creates churn and actually increases the risk of potential outages. Stable with backported fixes for security means that only updates for security need to be actioned.
      - bayindirh 5y ago
        I strictly run Debian Stable on my own servers but, they're low in numbers (office uses CentOS, because we need to), and I use unattended upgrades on these small servers. At the end of the day, I don't touch them unless I have to (because updates restart services most of the time anyway), but I understand your point completely. I'm not against only back porting serious security fixes only (since both time and resources are limited, and a good trade-off is always the best choice). Just it did occurred to me that I didn't wrap my head around the details of this particular subject.
        _joel 5y ago
        Yea, I used unattened-upgrades for everything not libc/kernel and then use the requires-restart stuff (you can do this on centos and debian based distros) just to make sure it's a bit more managed. Nowadays a lot more stuff I deploy is in immutable containers with health checks so tends to be less of a pain, but you trade that off in increase in complexity and overheads etc. Still have to reboot hypervisors too if not managed.
WhyNotHugo 5y ago
I feel this approach merely _accumulates_ breaking changes (breaking in the sense that they break your workflow, not that Firefox fails to start). When you update Debian to a new release, you suddenly get a huge influx of changes: new Firefox, new DE, new bash, new kernel, new email client, etc. Everything gets updated at once. It's likely that more than one thing will break your workflow, and you'll spend a significant amount of time dealing with all of those at once. Arch just spreads that over time. Instead of having to deal with ALL of these things at once every 6 months (or every two years), I deal with tiny changes very often. It's very unlikely that both the kernel AND Firefox will have changes that affect me on the same day. I also feel it's more sustainable to deal with small change once every couple of weeks, than huge changes twice a year. Arch is stable in that the changes per day ratio is constant over a long period of time, while's Debian is 0 changes for months, and then hundreds of changes at once.

bayindirh 5y ago

Moreover, Debian Stable has a 24H security fix deadline, which voluntarily forces them to fix a lot of security holes pretty quickly. Don't they back port security fixes to stable branch too? I'm a testing user, so I don't follow Stable's package updates very closely.

0xC0ncord 5y ago
Most bugs that get backported to stable kernels only get backported if they are serious enough or have a CVE assigned to them. Many bugs with potential security implications go unfixed because of this.
- bayindirh 5y ago
  Oh, OK. I learned something important today. Thanks a lot.
  - _joel 5y ago
    Yea, it's not just desktop either but having stable releases for server workloads is pretty much essential. If there's no need to update for any required feature in a later version then doing updates for the sake of it just creates churn and actually increases the risk of potential outages. Stable with backported fixes for security means that only updates for security need to be actioned.
    - bayindirh 5y ago
      I strictly run Debian Stable on my own servers but, they're low in numbers (office uses CentOS, because we need to), and I use unattended upgrades on these small servers. At the end of the day, I don't touch them unless I have to (because updates restart services most of the time anyway), but I understand your point completely. I'm not against only back porting serious security fixes only (since both time and resources are limited, and a good trade-off is always the best choice). Just it did occurred to me that I didn't wrap my head around the details of this particular subject.
      - _joel 5y ago
        Yea, I used unattened-upgrades for everything not libc/kernel and then use the requires-restart stuff (you can do this on centos and debian based distros) just to make sure it's a bit more managed. Nowadays a lot more stuff I deploy is in immutable containers with health checks so tends to be less of a pain, but you trade that off in increase in complexity and overheads etc. Still have to reboot hypervisors too if not managed.

WhyNotHugo 5y ago

I feel this approach merely _accumulates_ breaking changes (breaking in the sense that they break your workflow, not that Firefox fails to start). When you update Debian to a new release, you suddenly get a huge influx of changes: new Firefox, new DE, new bash, new kernel, new email client, etc. Everything gets updated at once. It's likely that more than one thing will break your workflow, and you'll spend a significant amount of time dealing with all of those at once. Arch just spreads that over time. Instead of having to deal with ALL of these things at once every 6 months (or every two years), I deal with tiny changes very often. It's very unlikely that both the kernel AND Firefox will have changes that affect me on the same day. I also feel it's more sustainable to deal with small change once every couple of weeks, than huge changes twice a year. Arch is stable in that the changes per day ratio is constant over a long period of time, while's Debian is 0 changes for months, and then hundreds of changes at once.