I’ve been running Tumbleweed for a few years now. It’s great, but it’s not 100% autopilot, updates often require manual intervention (resolving small problems) or updates try to add 50 packages I don’t need (recommends) all the time despite them not being in a pattern. I’ve been looking for a distro on which I could set up automatic updates and forget mostly about it, while still having recent packages; reliability and peace of mind while being on the bleeding edge. Due to having an NVIDIA GPU, LTS distros are a no-go. I’ve debated on the following

  • Debian: packages too old, ideal for my server though.
  • Ubuntu 24.04: Plasma 6 not available until next release. Snap is still a problem.
  • Fedora/Ublue: DNF is painfully slow. Immutable variants are interesting but download full GBs worth of images
  • Arch: insanely fast package manager, but can require manual intervention. Automatic updates aren’t recommended for arch. It also lacks my printer driver on the repos (only available on the AUR). One of the only distros that can truly satisfy my minimalist itch.
  • KDE Neon: Snaps, no nvidia graphics
  • NixOS: Never tried it but apparently the unusual file structure causes many problems

So I ended up trying again OpenSUSE Kalpa. I had completely forgotten about it, and I really like the concept. It’s like the Fedora immutable variants, but instead of downloading whole GBs of images, it creates BTRFS snapshots between normal zypper updates. So you can have the benefits of offline updates without having to wait at boot or at shutdown. Just like silverblue, the concept is to try to install everything through flatpak/distrobox and avoid adding anything unnecessary to the base, so that system updates can be snappy and unproblematic.

I was really tired of opening my laptop, updating everything and then rebooting. I just want to open my pc, have all updates automatically applied in the background through systemd units so that the next time I boot, I have an updated system. No “updating” during next boot. I finally found a distro perfect for me in that regard, and for everyone else who’s tired of babysitting their linux desktops, you should give a shot to Kalpa/Aeon.

  • swooosh@lemmy.world
    link
    fedilink
    arrow-up
    14
    ·
    8 months ago

    Speed of a package manager should never be a major concern nowadays. It’s not like you have to build packages from source slow. You install packages once, even if it takes minutes, just do something else. Updates happen in the background.

    Same for huge updates. For one, are you sure it downloads the whole image? Downloading an update of fedora atomic is very fast on my device. Even then, games are huge, 4k movies are huge. An OS updates is small. I don’t care about that size. That is nothing of importance.

    The real question is: image vs snapshot. What do you think about that question?

    • 柊 つかさ@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      8 months ago

      Speed of a package manager should never be a major concern nowadays.

      I would like to disagree with this. It’s not just updates. Sometimes I add and remove a bunch of packages back to back to test stuff out or check soft dependencies or pull/remove dependencies for projects I am checking out and compiling or switch between prepackaged/compiled versions. For example I was once testing the difference between wine and wine-stable-ubuntu in combination with winetricks installed/uninstalled. That is four configurations and you might visit each one more than once. I once saw a classmate use the fedora package manager in real life and I thought it was quite slow. I am happy with pacman, it really rips through packages which is convenient.

      • Unskilled5117@feddit.de
        link
        fedilink
        arrow-up
        8
        ·
        edit-2
        8 months ago

        That sounds like a usecase for distrobox or toolbx, and not something an average user would need to consider for choosing a distro

        • boredsquirrel@slrpnk.net
          link
          fedilink
          arrow-up
          1
          ·
          8 months ago
          1. Agree that this is not typical use
          2. But also agree that doing this is very slow and sometimes nice for testing
          3. But this is not about dnf but rpm-ostree, which is slower. Note though that there is an --apply-live setting to not need a reboot
          4. Distrobox / toolbox are intended for that, Distrobox is way better for UX. Not everything works here but most.
      • swooosh@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        8 months ago

        I am speaking of day to day use of a computer.

        In your case it matters. it always matters if it’s the main task. even in your case you do the comparison once. And a task that is performed once, shouldn’t be the main focus. I wouldn’t use atomic for tinkering with the system.

        • boredsquirrel@slrpnk.net
          link
          fedilink
          arrow-up
          1
          ·
          8 months ago

          I also disagree with some Fedora devs that “development should be done in containers”. This works well for apps, but results in duplication and does not allow editing the OS itself.

    • Fredol@lemmy.worldOP
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      8 months ago

      Snapshots are a lot more flexible. You can make any modifications to your system without issue. Layering packages on image based distros is slow and annoying, to the point UBlue OS was born out of that annoyance.

      Speed of package managers did matter in my original search, because my workflow was to open my pc, update everything, reboot, start working. But with Kalpa snapshots, my updates are started in the background then silently and promptly applied on next reboot, I don’t even have to think about it. It’s like offline updates but without the wait.

      • swooosh@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        8 months ago

        I’m not that knowlegable why ublue was created in the first place but ublue has incredible advantages besides not having to layer packages. You can create your own custom distro and ship it to many comouters without major knowledge, time or effort. Can you do the same with opensuse’s?

        Layering packages shall be annoying. As with other installs, you do it once. Because it’s annoying you do it only if it is important. You do not layer random malware downloaded from the internet. You shall not tinker with the system, that’s why it is immutable. If you want to tinker, use a traditional installation method, or simply use distrobox

        • Fredol@lemmy.worldOP
          link
          fedilink
          arrow-up
          2
          ·
          8 months ago

          Ublue is indeed fantastic tech, I don’t deny that. For my own purposes, I would have to spend too much time curating my own custom OS if I used it, so I prefer Kalpa.

          • boredsquirrel@slrpnk.net
            link
            fedilink
            arrow-up
            2
            ·
            8 months ago

            This is due to the fact that Kalpa is a traditionally package-managed OS. On image based Atomic Fedora there is a base image, and the overlays are always added on top.

            If these overlays are always the same, like ublues “hardware enablement” then it makes way more sense to use the base image and apply these changes once. Doing that workload once, minimizing randomness between users and doing unstable stuff like proprietary NVIDIA drivers, rpmfusion, custom kernels etc. on a single repo. The issues will occur there and can be fixed centrally.

            The slow process it not ostree, but doing the changes on every update. But tbh when updates are automatic it doesnt matter than much anymore.

      • boredsquirrel@slrpnk.net
        link
        fedilink
        arrow-up
        4
        ·
        8 months ago

        Snapshots are a lot more flexible. You can make any modifications to your system without issue.

        The issue is the lack of any versioning and control. It works “without issue” just as it works on traditional distros, it works until suddenly you have strange errors, devs tell you “I cant reproduce this here and btw modifying the base OS is not a supported use case” (it actually isnt) and as there is no way to revert the “issueless changes” you need to fix them manually or reinstall the OS.