And the very fact that there’s a million forks doesn’t make it better
Yeah I try to steer folks around the Popular Distro Of The Month because this is the kind of shit that invites. You get some minor gimmick in exchange for several janky reimplementations of software that worked perfectly fine (often package manager GUIs) and significantly poorer googlability when something goes wrong.
Several of the cheese holes* in the YES DO AS I SAY fiasco did exist are because System76 couldn’t leave well enough alone.
The bug was actually in the .deb package itself, not the software in it. The dependency data was made in such a way that if it didn’t see one of the normal, standard Linux GUIs, it would threaten to uninstall the entire GUI. This worked fine on Gnome, KDE, Cinnamon, xfce, LXDE, MATE and Unity, but Pop-Desktop was a weird mutant form of Gnome that didn’t quite match. So this bug pretty much only effected Pop!_OS users. APT is designed to detect something strange like that and offer a very stern warning, and GUIs built on top of APT usually detect that warning and automatically say no and just throw an error message to the user.
This happened to a number of Pop!_OS users, who saw and reported the error to…probably both System76 and Valve. A patched version was released which worked.
The Pop!_Shop was one of those janky reimplementations of software that worked perfectly fine. For some very Apple scented reason, the Pop!_Shop doesn’t do an apt-get update when launched. I’m not sure why they made that decision, if they were relying entirely on the update routine to do it on a schedule, but in most Debian-based systems it’s typical do do an apt-get update before upgrading or installing anything. And that it doesn’t happen at any point during the install process, it means that between a fresh install and a scheduled check for updates you could have an apt cache that was last updated when the installer ISO was packaged, which may have been weeks ago.
That’s what happened to Linus. The bugged version was in his apt cache, and neither he nor the system performed an apt update before he started installing stuff.
What is Linus’ fault is how he reacted to that error. What would happen if some Windows setup.exe had failed? Would he have opened up Powershell and tried to force it to go? No, he’d google “SoftwareName failed to install on windows” and find instructions pertinent to his problem. So why didn’t he do that here? He didn’t google “failed to install steam on popos” which would have turned up discussions of the problem and the correct solution of updating and trying again. Instead, he copped an attitude about how Linux GUIs don’t work (it did; it detected a potential catastrophe and prevented it) and instead googled “How to install steam in terminal”. The page he found, he either skimmed a bit too fast, or was faulty. Because most instructions for installing something on .deb based systems will instruct you to do an apt update and apt upgrade first, which would have prevented the problem. But either someone wrote it wrong, or Linus skipped that part, did an apt install, ignored the dire dire warning, and watched X die.
Now. Remember a few paragraphs ago when I called the Pop!_Shop “Apple scented?” In another episode of LTT, Linus was reviewing a set of AirPods. They were playing audio out of sync, and needed a firmware update. The process for performing this firmware update was to pair them to an iPhone (no other Apple device would do, ONLY an iPhone), put them in their case with the lid open, on the phone go to into the settings to the version number page for the AirPods, and wait, they should update. Linus, and me, bitched about that. At the time, the only way to manually perform an apt update through the GUI was to launch the Pop!_Shop, go to the Installed tab, and wait. No “Check for updates” button. So even if it occurred to you to try, it wasn’t apparent how.
*The Swiss cheese model of accident analysis works like this: for an accident to occur, usually multiple factors have to line up just right, like the holes in random slices of Swiss cheese.
Yeah I try to steer folks around the Popular Distro Of The Month because this is the kind of shit that invites. You get some minor gimmick in exchange for several janky reimplementations of software that worked perfectly fine (often package manager GUIs) and significantly poorer googlability when something goes wrong.
Several of the cheese holes* in the YES DO AS I SAY fiasco did exist are because System76 couldn’t leave well enough alone.
The bug was actually in the .deb package itself, not the software in it. The dependency data was made in such a way that if it didn’t see one of the normal, standard Linux GUIs, it would threaten to uninstall the entire GUI. This worked fine on Gnome, KDE, Cinnamon, xfce, LXDE, MATE and Unity, but Pop-Desktop was a weird mutant form of Gnome that didn’t quite match. So this bug pretty much only effected Pop!_OS users. APT is designed to detect something strange like that and offer a very stern warning, and GUIs built on top of APT usually detect that warning and automatically say no and just throw an error message to the user.
This happened to a number of Pop!_OS users, who saw and reported the error to…probably both System76 and Valve. A patched version was released which worked.
The Pop!_Shop was one of those janky reimplementations of software that worked perfectly fine. For some very Apple scented reason, the Pop!_Shop doesn’t do an apt-get update when launched. I’m not sure why they made that decision, if they were relying entirely on the update routine to do it on a schedule, but in most Debian-based systems it’s typical do do an apt-get update before upgrading or installing anything. And that it doesn’t happen at any point during the install process, it means that between a fresh install and a scheduled check for updates you could have an apt cache that was last updated when the installer ISO was packaged, which may have been weeks ago.
That’s what happened to Linus. The bugged version was in his apt cache, and neither he nor the system performed an apt update before he started installing stuff.
What is Linus’ fault is how he reacted to that error. What would happen if some Windows setup.exe had failed? Would he have opened up Powershell and tried to force it to go? No, he’d google “SoftwareName failed to install on windows” and find instructions pertinent to his problem. So why didn’t he do that here? He didn’t google “failed to install steam on popos” which would have turned up discussions of the problem and the correct solution of updating and trying again. Instead, he copped an attitude about how Linux GUIs don’t work (it did; it detected a potential catastrophe and prevented it) and instead googled “How to install steam in terminal”. The page he found, he either skimmed a bit too fast, or was faulty. Because most instructions for installing something on .deb based systems will instruct you to do an apt update and apt upgrade first, which would have prevented the problem. But either someone wrote it wrong, or Linus skipped that part, did an apt install, ignored the dire dire warning, and watched X die.
Now. Remember a few paragraphs ago when I called the Pop!_Shop “Apple scented?” In another episode of LTT, Linus was reviewing a set of AirPods. They were playing audio out of sync, and needed a firmware update. The process for performing this firmware update was to pair them to an iPhone (no other Apple device would do, ONLY an iPhone), put them in their case with the lid open, on the phone go to into the settings to the version number page for the AirPods, and wait, they should update. Linus, and me, bitched about that. At the time, the only way to manually perform an apt update through the GUI was to launch the Pop!_Shop, go to the Installed tab, and wait. No “Check for updates” button. So even if it occurred to you to try, it wasn’t apparent how.
*The Swiss cheese model of accident analysis works like this: for an accident to occur, usually multiple factors have to line up just right, like the holes in random slices of Swiss cheese.