5 ms·

It's not just FreeBSD. It's everything. Do you ever think about your toaster? No of course you don't. It turns on when you need it, toasts the bread, and then

It's not just FreeBSD. It's everything. Do you ever think about your toaster? No of course you don't. It turns on when you need it, toasts the bread, and then turns off. It doesn't require your attention. Ever. Then you look at your computer and wonder what buggy hell you'll end up with if you roll the dice with the latest updates. Something is fundamentally wrong about how we are using computers.

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.
tryauuum 5y ago
I understand your feelings about modern software, but comparing computers to toasters sounds pointless to me
- nicce 5y ago
  Well, in these days even toasters can be computures to be fair, and I don’t like it.
- dijit 5y ago
  I’m not sure I agree. Computers as appliances used to be more true than it is today on significantly worse hardware. The “instant on”- of a commodore64 is a distant thing of the past but it needn’t be. One of the major reasons for systemd coming to prominence was boot times, so people do care. If your machine could start and stop in 500ms flat then it would fundamentally change the way you interact with it.
  - oblio 5y ago
    The Commodore 64 could do maybe 0.005% of what my PC can. Power comes with complexity. Simple power is genius and it's hard to scale that.
  - doublepg23 5y ago
    It seems like we went around boot times and went with sleep time. When was the last time you rebooted your phone?
vorpalhex 5y ago
Well, now your toaster is slowly getting wifi modems and processors so it can be "cloud connected" and require a subscription. So don't worry - the same excitement you have updating your computer today will soon come to your toast and bagel situation.
- deleted 5y ago
  [deleted]
- queuebert 5y ago
  This is causing a type of PTSD.
xyproto 5y ago
An operating system dedicated to toasting bread would be fully possible to make in a way that did not need updates or attention, as long as it had enough testing first.
- queuebert 5y ago
  Why the eff would toasting bread need an OS?
  - froh 5y ago
    there are toasters and toasters, here is one with microcontroller: https://www.youtube.com/watch?v=LxTP6yxoCrw https://www.youtube.com/watch?v=LxTP6yxoCrw you bet this thing has some little RT-OS on it, like FreeRTOS maybe?

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.

tryauuum 5y ago

I understand your feelings about modern software, but comparing computers to toasters sounds pointless to me

nicce 5y ago
Well, in these days even toasters can be computures to be fair, and I don’t like it.
dijit 5y ago
I’m not sure I agree. Computers as appliances used to be more true than it is today on significantly worse hardware. The “instant on”- of a commodore64 is a distant thing of the past but it needn’t be. One of the major reasons for systemd coming to prominence was boot times, so people do care. If your machine could start and stop in 500ms flat then it would fundamentally change the way you interact with it.
- oblio 5y ago
  The Commodore 64 could do maybe 0.005% of what my PC can. Power comes with complexity. Simple power is genius and it's hard to scale that.
- doublepg23 5y ago
  It seems like we went around boot times and went with sleep time. When was the last time you rebooted your phone?

vorpalhex 5y ago

Well, now your toaster is slowly getting wifi modems and processors so it can be "cloud connected" and require a subscription. So don't worry - the same excitement you have updating your computer today will soon come to your toast and bagel situation.

deleted 5y ago
[deleted]
queuebert 5y ago
This is causing a type of PTSD.

xyproto 5y ago

An operating system dedicated to toasting bread would be fully possible to make in a way that did not need updates or attention, as long as it had enough testing first.

queuebert 5y ago
Why the eff would toasting bread need an OS?
- froh 5y ago
  there are toasters and toasters, here is one with microcontroller: https://www.youtube.com/watch?v=LxTP6yxoCrw https://www.youtube.com/watch?v=LxTP6yxoCrw you bet this thing has some little RT-OS on it, like FreeRTOS maybe?