4 ms·

If you're running Debian Stable or RHEL, updates aren't buggy hell. If you're running Arch, Gentoo, or Alpine: of course updates are buggy hell, that's what you

by alrs 5y ago

If you're running Debian Stable or RHEL, updates aren't buggy hell. If you're running Arch, Gentoo, or Alpine: of course updates are buggy hell, that's what you signed up for.

errantmind 5y ago
Anecdotal, but I haven't had problems with Arch updates, even with a lot of Aur packages.. yet. Maybe I've been lucky.
- alrs 5y ago
  "Arch on my laptop" != "Arch on 2000 production systems."
nicce 5y ago
Arch at least is super stable in terms of bugs. The problem comes with changes in software versions. Too often people think that stability means only bugs. I would even argue that Arch has even less bugs than Debian.
- vaylian 5y ago
  Arch and Debian user here. I find that hard to believe. I love using Arch and I am fine with the occasional (though rare) update problem, because I'm the only user of my system and I'm learning something when something stops working. But Debian stable is really stable, because other Distros ironed out the bugs before the version came into stable.
  - nicce 5y ago
    I can count myself as hardcore user as well. Mainly using Arch Linux, but for servers and some build environments using Debian and Alpine. It is always Debian which has a package with a bug and it is not updated for some reason. I work with quite complex systems like using libguestfs and somehow it has always broken dependency in some narrow use case. These are often fixed on Arch already, but in Debian you might need to wait a year for official fix.
    - doublepg23 5y ago
      Based on my time with Arch, I’d agree. The fact is bugs exist even given N amount of time to find them, what matters is how quickly they are fixed - and it doesn’t get much faster than Arch.
josephcsible 5y ago
That's the theory, but in practice the opposite often turns out to be true. Consider this: https://bugzilla.redhat.com/show_bug.cgi?id=1633932 https://bugzilla.redhat.com/show_bug.cgi?id=1633932 Here's a summary of what happened: Firefox got a new password database format. Originally, it would write the new database file and use it if present, but leave the old one there indefinitely. A little while later, people realized this was a security vulnerability: if you create or change your master password, the old database will still let attackers in without one or with the old one. The vulnerability was fixed by having Firefox delete the old database on startup. The code to read and write the new password database was a new feature, so Red Hat deemed it unworthy to add to their "stable" distro. The code to delete the old password database was a security fix, so Red Hat cherry-picked it into their distro. But now the problem should be obvious: Red Hat's version of Firefox now deleted the old password database on startup, but lacked the code to write out the new version of it. As a result, as soon as you started Firefox, your saved passwords would be completely wiped from disk. This problem was inherent to the "stable" model that RHEL uses, and would have never happened with distros that just take new upstream versions and avoid cherry-picking patches, like Arch.
- RedShift1 5y ago
  > but in practice the opposite often turns out to be true One backwards compatible issue in how many years, builds and packages? I would say _often_ is highly exaggerated. I've had many more issues with rolling release distros than I've ever had with CentOS, I can basically do a yum upgrade and reboot with my eyes closed and not have any issues.
  - josephcsible 5y ago
    One issue that eats your data is worse than 100 issues that just take up your time to fix. And sure, you can say backups are important, but we know that in practice, a lot of people don't keep good backups. And besides, it isn't just one issue. https://bugzilla.redhat.com/show_bug.cgi?id=2039993 https://bugzilla.redhat.com/show_bug.cgi?id=2039993 is another example of a problem caused by incorrectly cherry-picking a security patch: OpenSSL was affected by CVE-2021-3712, which they quickly and correctly fixed upstream. But RHEL still uses OpenSSL 1.0.2, which has been EOL for more than 2 years, so Red Hat had to backport the patch themselves. When they did so, they made a silly typo (forgot the "!"), which made Web servers all crash with a double free error very shortly after every startup. https://bugzilla.redhat.com/show_bug.cgi?id=1861977 https://bugzilla.redhat.com/show_bug.cgi?id=1861977 was yet another, in which trying to fix a Secure Boot-related vulnerability rendered computers unbootable. A fourth one, which I unfortunately don't remember the bug ID for, was when a patch added to NSS in a security update made programs hang when you tried to use a smart card. To be clear, I didn't go searching for these problems. I know about them because I was affected by them all.

by alrs 5y ago

If you're running Debian Stable or RHEL, updates aren't buggy hell. If you're running Arch, Gentoo, or Alpine: of course updates are buggy hell, that's what you signed up for.

errantmind 5y ago

Anecdotal, but I haven't had problems with Arch updates, even with a lot of Aur packages.. yet. Maybe I've been lucky.

alrs 5y ago
"Arch on my laptop" != "Arch on 2000 production systems."

nicce 5y ago

Arch at least is super stable in terms of bugs. The problem comes with changes in software versions. Too often people think that stability means only bugs. I would even argue that Arch has even less bugs than Debian.

vaylian 5y ago
Arch and Debian user here. I find that hard to believe. I love using Arch and I am fine with the occasional (though rare) update problem, because I'm the only user of my system and I'm learning something when something stops working. But Debian stable is really stable, because other Distros ironed out the bugs before the version came into stable.
- nicce 5y ago
  I can count myself as hardcore user as well. Mainly using Arch Linux, but for servers and some build environments using Debian and Alpine. It is always Debian which has a package with a bug and it is not updated for some reason. I work with quite complex systems like using libguestfs and somehow it has always broken dependency in some narrow use case. These are often fixed on Arch already, but in Debian you might need to wait a year for official fix.
  - doublepg23 5y ago
    Based on my time with Arch, I’d agree. The fact is bugs exist even given N amount of time to find them, what matters is how quickly they are fixed - and it doesn’t get much faster than Arch.

josephcsible 5y ago

That's the theory, but in practice the opposite often turns out to be true. Consider this: https://bugzilla.redhat.com/show_bug.cgi?id=1633932 https://bugzilla.redhat.com/show_bug.cgi?id=1633932 Here's a summary of what happened: Firefox got a new password database format. Originally, it would write the new database file and use it if present, but leave the old one there indefinitely. A little while later, people realized this was a security vulnerability: if you create or change your master password, the old database will still let attackers in without one or with the old one. The vulnerability was fixed by having Firefox delete the old database on startup. The code to read and write the new password database was a new feature, so Red Hat deemed it unworthy to add to their "stable" distro. The code to delete the old password database was a security fix, so Red Hat cherry-picked it into their distro. But now the problem should be obvious: Red Hat's version of Firefox now deleted the old password database on startup, but lacked the code to write out the new version of it. As a result, as soon as you started Firefox, your saved passwords would be completely wiped from disk. This problem was inherent to the "stable" model that RHEL uses, and would have never happened with distros that just take new upstream versions and avoid cherry-picking patches, like Arch.

RedShift1 5y ago
> but in practice the opposite often turns out to be true One backwards compatible issue in how many years, builds and packages? I would say _often_ is highly exaggerated. I've had many more issues with rolling release distros than I've ever had with CentOS, I can basically do a yum upgrade and reboot with my eyes closed and not have any issues.
- josephcsible 5y ago
  One issue that eats your data is worse than 100 issues that just take up your time to fix. And sure, you can say backups are important, but we know that in practice, a lot of people don't keep good backups. And besides, it isn't just one issue. https://bugzilla.redhat.com/show_bug.cgi?id=2039993 https://bugzilla.redhat.com/show_bug.cgi?id=2039993 is another example of a problem caused by incorrectly cherry-picking a security patch: OpenSSL was affected by CVE-2021-3712, which they quickly and correctly fixed upstream. But RHEL still uses OpenSSL 1.0.2, which has been EOL for more than 2 years, so Red Hat had to backport the patch themselves. When they did so, they made a silly typo (forgot the "!"), which made Web servers all crash with a double free error very shortly after every startup. https://bugzilla.redhat.com/show_bug.cgi?id=1861977 https://bugzilla.redhat.com/show_bug.cgi?id=1861977 was yet another, in which trying to fix a Secure Boot-related vulnerability rendered computers unbootable. A fourth one, which I unfortunately don't remember the bug ID for, was when a patch added to NSS in a security update made programs hang when you tried to use a smart card. To be clear, I didn't go searching for these problems. I know about them because I was affected by them all.