I’m considering trying out an immutable distro after using Tumbleweed for the last 6 years.

The two major options for me seem to be Fedora Kinoite or uBlue Aurora-dx

My understanding is that universal-blue is a downstream of Fedora Atomic

So, the points in favor of Kinoite is sticking closer to upstream, however it seems like I would need to layer quite a few packages. My understanding is that this is discouraged in an rpm-ostree setup, particularly due to update time and possible mismatches with RPMFusion

uBlue Aurora-dx seems to include a lot of the additional support I’d need - ROCm, distrobox, virt-manager, libratbag, media codecs, etc. however I’m unclear how mature the project is and whether it will be updated in a timely manner long term

I’m curious what the community thinks between the two as a viable option

  • j0rge@lemmy.ml
    3·
    5 months ago

    I’m unclear how mature the project is and whether it will be updated in a timely manner long term

    ublue and bluefin co-maintainer here, we’ve been around for a while now (3rd birthday coming up!) and have been around in a more unofficial capacity for longer.

    Bluefin is feature complete and is in maintenance mode, it’s just going to get updated in perpetuity to 41, 42, etc. We invested in automation first so most of the maintenance is automatic and it doesn’t take much for our team to do it. Right now most of our major ticket items are waiting for things to finish landing in upstream Fedora, most of which are targetted towards F41. A good portion of the team have been around in OSS for a long time and a bunch of us work in the industry and depend on Bluefin for our jobs, so much so that we have a great working relationship with Framework, so we’re supporting those laptops as a community option for them.

    Aurora is relatively new, coming in just as Plasma 6 landed in fedora. Most reports with issues we get for it are things like it being a new major release, wayland/nvidia issues, etc.

    Hopefully that answers some of your questions, if you have more feel free to ask!

    • ozymandias117@lemmy.worldOPEnglish
      0·
      5 months ago

      Hey! Thanks!

      I’ve installed Aurora to my new drive based off the comments here so far, and it’s been pretty smooth bringing my configs over :)

      Immutable is new to me, so I’m wondering how you manage host daemons and cli applications, such as mpd for music and password-store for password management

      Is the best practice to keep one Fedora <current release> distrobox with them?

      Also, are there any issues with upgrading a distrobox to a new major release over time?

      So far my mindset has been make sure I don’t layer anything, but maybe some things like mpd do make sense to layer?

      I also see brew as another option. Perhaps that’s the preferred way for those types of tools? However, it seems like the system upgrade script updates distrobox and not brew?

      Sorry for the rambling question - just trying to understand best practices with an immutable distro 😅

      • cakeofhonor@lemmy.world
        2·
        5 months ago

        One thing you can check out is quadlet, which is podman containers running as systemd services. You just basically put the .container files in the right directory and sytemd will pick them up and run them for you. I have syncthing and zerotier running like this.

        I don’t really think you need to layer anything unless you’re doing virtualization, but I haven’t really looked into that yet.

        • ozymandias117@lemmy.worldOPEnglish
          1·
          5 months ago

          Thanks! That sounds like exactly what I’d want to run mpd. I’ll check it out

          For virtualization, I’m all good since I went with uBlue instead of Silverblue for now - the developer images come with lxc/lxd/qemu/libvirt :)

  • Fliegenpilzgünni@slrpnk.net
    1·
    5 months ago

    Short answer: use uBlue.

    Longer answer:

    Even though uBlue is technically “downstream”, it also isn’t. uBlue builds its’ packages automatically, and you are never more than a few hours (1 day max for huge updates) away from upstream. It feels more like “sidestream” (if that word exists?).

    One reason it exists is, as you already said, because layering takes quite some time.
    At least I personally don’t wanna use stock Fedora (Atomic) and would install some codecs, tweaks and such anyway, and uBlue does that already for me.
    Update time doesn’t matter anymore for me, because uBlue updates itself automatically in the background. Silverblue doesn’t do that afaik.

    Depending on how “custom” your system should be, you can take a look at the uBlue builder, where you can create your own image based on already existing ones if you like.

    The cool thing about Fedora Atomic is, that you don’t have to stick to anything. If you don’t like something anymore, you can rebase in less than two minutes without any hassle and jump from image to image, no matter if it’s an official one (e.g. Silverblue) or some obscure uBlue image.

  • boredsquirrel@slrpnk.net
    0·
    5 months ago

    uBlue f**ed up their site a while ago, they had a huge list of images.

    You can just use their kinoite-main image, which is what I do. It has Distrobox, homebrew and a few more things.

    Here is an archived site

    Use kinoite-main:latest and you will even get automatic version upgrades without a problem.

    You can still rebase, you know? I tried Aurora and it was not for me, back on normal Kinoite.

    But for sure it is a bit annoying to layer. But no issue. I layer 20 packages or so, 300 with dependencies, and all is fine.

    I dont know about ROCM, their hardware enablement to my knowledge is just about NVIDIA, Asus and other proprietary stuff.

      • boredsquirrel@slrpnk.net
        0·
        5 months ago

        Interesting.

        Give it a shot, Aurora is fine. May have some packages you dont need, but it is fine.

        They remove Firefox for whatever reason, which makes no sense. The Librewolf and Firefox Flatpaks are probably okay, the Librewolf RPM is completely broken

        • quarterlife@lemmy.sdf.org
          0·
          5 months ago

          We remove Firefox because having it on the image is a security hazard. You want your browser to update more often than your operating system.

          We prefer the flatpak, but if for some reason you need the RPM I would suggest installing it with distrobox.

          • boredsquirrel@slrpnk.net
            0·
            5 months ago

            a security hazard.

            Okay?

            You want your browser to update more often than your operating system.

            Then why do you base on Fedora and have daily auto updates by default?

            I shutdown my laptop every day and update every day. That is fine for me.

            Fedora Firefox has some hardening flags that official Firefoxn has not. It is built for Fedora and works really really good.

            I did benchmarks some time ago and it is also actually very performant.

            Flatpak Firefox does not have the ability to create user namespaces for tab process isolation. This is due to all Flatpaks using the same badness-enumerating seccomp filter, there is no additional hardening possible and they still block userns creation.

            Firefox can still isolate tabs via seccomp-bpf but this means it has 1 of its 2 security barriers removed when using a flatpak.

            Seeing browsers as an app, it is good to have additional security from the browser to the OS, by sandboxing via flatpak.

            But seeing the browser as a platform, passwords, bookmarks, credit card details etc may all be stored in there and a sandbox escape not necessary to steal peoples stuff.

            Removing Firefox prevents people from reinstalling it (due to the rpm-ostree bug), and apart from the tarball (which has no desktop integration and is some random binary ran from some random location, likely without SELinux protection (unconfined users)) it is the best browser on Fedora.

            installing it with distrobox.

            This makes no real sense.

            Pro

            • it can update separately from the OS
            • it works even with the current rpm-ostree bug
            • it is the Fedora RPM
            • it is kinda isolated from the root OS

            Con

            • updates are not automatic and need to be configured
            • not sure if it has access to user namespace creation because it already runs in a user namespace container
            • it adds additional boot time and constant RAM usage due to having a container
            • distrobox does not allow Fedora DNF system upgrades so you need to nuke it and reinstall on a version change (at least every 13 months)

            Using the tarball and placing it in /var/usrlocal/bin/ may be better. But still cumbersome.

            The solution, even if you want to remove it, is having these issues solved, or this rpm-ostree bug fixed.

            • quarterlife@lemmy.sdf.org
              0·
              5 months ago

              Distrobox updates automatically on Bluefin and Bazzite.

              In this case we disagree with Fedora, Atomic Fedora should not have Firefox in image. It does not matter to us what they do, we explicitly remove it.

              If you like the way Fedora builds their Firefox RPM, that’s all the more reason for you to use a fedora distrobox.

              I shutdown my laptop every day and update every day. That is fine for me.

              Irrelevant. Not everybody does. Some people pin an old image due to a bug and sit on a far older image. If you had it your way, they’d be using a week or month old build of Firefox – that’s unacceptable.

              Removing Firefox prevents people from reinstalling it

              Good. I can promise you if that gets fixed and I have a way to continue to prevent it, I will.

              Flatpak Firefox does not have the ability to create user namespaces for tab process isolation. This is due to all Flatpaks using the same badness-enumerating seccomp filter, there is no additional hardening possible and they still block userns creation.

              This is an issue for Mozilla. They are happy enough with the state of the Flatpak to not only verify it, but list it on their website. Unless you’ve got a CVE for the Flatpak version of Firefox I don’t see any point in even engaging with this argument.

              • boredsquirrel@slrpnk.net
                0·
                5 months ago

                Distrobox updates automatically

                True, forgot that you use topgrade

                Atomic Fedora should not have Firefox in image

                There are many relevant issues and it is not a clear choice.

                Irrelevant. Not everybody does.

                Yeah and nobody knows about user namespaces or seccomp filters. This is about at least 2 user groups and one is not necessarily more important than another.

                It is again not a clear choice.

                a way to continue to prevent it, I will.

                * in your opinionated images, I hope.

                You start to sound like a GrapheneOS dev. It makes no sense to prevent users from reinstalling removed packages.

                Which btw also include the Fedora Flathub repository.

                • quarterlife@lemmy.sdf.org
                  0·
                  5 months ago

                  Which btw also include the Fedora Flathub repository.

                  We no longer touch the repos as Fedora is now in agreement with using Flathub.

                  You start to sound like a GrapheneOS dev. It makes no sense to prevent users from reinstalling removed packages.

                  It’s for user security. I have no interest in debating this decision, my reasons are outlined.