• taanegl@beehaw.org
    link
    fedilink
    arrow-up
    4
    ·
    6 months ago

    Bro, we are so close. Now if only someone can make the archiso tool that makes and installs ostree images, or some other system tool.

    It’s theoretically possible to rebase from Silverblue, Kinoite and uBlue variants, if the ostree image tool supplied was aware of rpm-ostree, and vice versa.

    At that point, we’ve started to take distro hopping to a new level lol

    • Samsy
      link
      fedilink
      arrow-up
      4
      ·
      6 months ago

      Distro hopping is so 2022. Today use an atomic/immutable build and add whatever distro you like in a toolbox/distrobox. It’s a new definition since all distros share the same DEs, it’s the box you use for different packed distros. If my atomic build is fedora and there is an app only available in the AUR or deb, then use a box. It’s that simple. If you get rid of that self created frankendebian with a strange .deb you needed, just remove the whole box.

      • taanegl@beehaw.org
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        6 months ago

        Maybe I was being too glib. Let me expand upon what I was saying.

        Silverblue and its derivatives (or “Fedora Atomic”) are literally immutable and use an image system to mount read only systems. It uses rpm-ostree to write ostree images. Ostree is an operating system image format developed by the GNOME project (of all folks) and allows you to keep a git-like tree where system images become sort of branches and tags. It’s cool because theoretically you only need to replace files that are updated, even though rpm-ostree will build everything and create an image from the collection of RPMS in ostree.

        Archiso does not do this, and I don’t know how they implement system images or if it’s even a system image solution and not just a dedicated volume or subvolume, but if it was ostree based in some way, you could probably rebase from Silverblue to this distro, without having to bootstrap a new system.

        In effect, toolbox, distrobox, Flatpaks, etc wouldn’t be touched, but neither would the previous system. It would be the previous image and you could just reboot into it if you’d want. If you could rebase from an rpm-ostree system, OpenSuSE’s weird imaging system, if nix suddenly adds ostree support, or even Debian, then at that point you wouldn’t need to reinstall the system at all. Just do a rebase and bam: completely different stack and distribution, with one reboot.

        Right now I can, with some gumption, I can rebase from Silverblue to uBlue, but because of how uBlue signs its images and deals with that in its own way, they recommend starting fresh. I don’t like that idea, because they took an image based system and almost instantly distanced themselves from Fedora Atomic. But I also understand why they need to use cosign.

        I mean if you run btrfs where the root is a subvolume, you could just delete that and create a new root subvolume, maybe just nuke the EFI partition and boot partition, bootstrap the sucker (or install the distribution) and you can switch between distributions fairly easily. Did it earlier this year, no problem. Very cool.

        But I don’t want to do that, even though I easily can. I want to be able to rebase and not distrohop. We’re not quite there, but we’re getting closer, and I’m hoping ostree will become the new standard so that we can easily just flip a switch and be in a different OS stack than the one we initially installed. It would really make Linux seem like one operating system, and if people could easily switch, I think that might make it easier to retain users on the Linux desktop.

        Oh and by the way, you can use uBlue as a basis to create your own immutable Fedora Atomic-based system, that you can distribute if you want :)