this post was submitted on 27 May 2024
369 points (88.2% liked)

linuxmemes

21263 readers
900 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] Kazumara@discuss.tchncs.de 1 points 5 months ago (1 children)

    I’ve never seen any substantial evidence of a distro with outdated packages really being any more reliable than a rolling release.

    I think the fundamental issue here is that you conflate the concepts of reliablility and stability. Those are not the same. Stability in distros is a question of how much they restrict change during support cycles in order to not be a moving target for developers and system integrators. Fundamentally a rolling release can't be stable. It can absolutely be reliable to use, but you wouldn't use it as a basis for an embedded system you're trying to develop.

    [–] nexussapphire@lemm.ee 1 points 5 months ago* (last edited 5 months ago) (1 children)

    I've heard the counter argument from developers that jumping from a two to four years old codebase is an absolute nightmare to deal with and moving to a rolling release means not dealing with the burden of migrating over to a newer version and implementing small patches when needed.

    Entire fixes, features, and upgrades miss the deadline and have to wait because of a process like this. It's still a moving target but on a different scale. They try to roll the newest packages possible into the release meaning the majority of the bug fixing and testing happens mere months before release.

    It's also a burden on bigger teams especially when they build their own automations and tooling. why Google devs moved to a rolling release.

    It's a solid concept but so much changes all at once it's a big project to migrate to a newer version. It frontloads a lot of the work sometimes to the point of delaying support for the newer version. Unless you build for Debian unstable and work backwards from there (basically rolling) but doesn't guarantee back ports don't break the software.

    [–] nexussapphire@lemm.ee 1 points 5 months ago

    It only benefits users who need a set it and forget it solution. I chose it for my server because I don't want to touch it but I dread the day I have to upgrade the whole system and something small like the zfs filesystem, docker, or my samba setup suddenly has issues and makes it unbootable like that kernel update that bricked my Nvidia drivers a couple months ago. I'm hoping that's a fluke because it happened at the worst time for me.

    It's four years from now, I don't have to think about it yet.