1. 18
  1. 5

    A specialized bootloader module then automatically selects the newer operating system and boots into it. […] If the upgraded version does not boot successfully, then the bootloader automatically falls back to the previous system partition, and you can try again later.

    I wonder what bootloader this is using. sd-boot, with its boot assessment?

    1. 4

      Ok, I didn’t know that sd-boot supported that.

      I need to get that integrated into NixOS. It sounds like it should be pretty easy to set it up so that after deploying with nixops it would automatically revert to the previous version unless nixops managed to SSH in and mark the boot a success. This should avoid locking you out for things as dramatic as bad firewall rules or a broken SSH config.

    2. 1

      The use of Arch as the base distro seems curious to me. Why?

      1. 2

        I agree, but reading further it seems like the read only rootfs with A/B upgrade mechanism might paper over possible inconsistencies in system state that come from rolling package upgrades. My guess is that they went with Arch to take advantage of the community’s prompt packaging of new versions of game dependencies.

        1. 1

          Considering they have the Steam runtime for games from Steam and Flatpak for everything else, I’m not sure of that.

          1. 1

            Revisiting this a little more caffeinated, I think I meant to say “system level dependencies”. Steam depends on system packaged dependencies like mesa, vulkan, etc and they mention in the article that they’re also packaging KDE for a normal desktop experience.

            1. 2

              I have never had a more disappointing Linux experience than SteamOS, and got rid of it pre-this.

              I think you’re right, in that they don’t have whatever it takes to actually maintain a distro, so they’re betting on Arch being stable enough that they can crowdsource/freeload all the hard work.

              Not sure if they’re snapshotting Arch versions, but if they do proper upgrades, they kinda have to. Hope they do at least some QA on it, but the debianish version fell into such abandon, I don’t trust any of this.

              1. 2

                Valve is definitely not the kind of company good at long-term unless it makes them a shitload of money.

      2. 1

        Someone commented on TFA:

        Any reason A/B updates approach was chosen over OStree?

        I don’t understand enough about OSTree, but I thought it was complementary to A/B updates. That is, you can have both, and the benefits don’t really overlap all that much (besides having an immutable rootfs).

        Can anyone weigh in on this? I feel like either I or the commenter I’m quoting are missing something serious.

        1. 4

          OSTree does A/B updates but on a single filesystem, rather than on a pair of partitions. The upsides include on-disk deduplication of the two versions: identical files between the current and rollback deployments are hardlinks to one another. But it means less isolation between the two deployments, and the need to mount the rootfs read-write (/usr is a read-only bind mount but the filesystem as a whole is writable).