I’ve read that containers are preferred for development, but they aren’t persistent and it doesn’t seem like files such as /etc/fstab can be accessed through them when running distrobox (I enjoy editing such files using vim).

It’s also a bit annoying having to enter a specific container to run something like btop.

Are you supposed to layer them with rpm-ostree?

  • Eggymatrix@sh.itjust.works
    1·
    1 minute ago

    If you want to go play with /etc/fstab and you have a concept of "everyday cli tools"an immutable distro is not for you. An immutable distro is made for people that do not use a computer but use a browser.

  • Holytimes@sh.itjust.works
    9·
    8 hours ago

    This is the exact reason the entire concept behind a immutable distro is beyond dog shit

    Unless your use case is something like a console where modifications are not intended to happen expect as an extreme outlier. They fucking suck, they make no fucking sense, and just create endless problems if you want to do anything with your hardware.

    Its basically re fucking inventing the exact problem that shit like ios has.

    You don’t own a computer with an immutable distro. Your distro is assuming your a child too ignorant and stupid to be trusted to do anything with it.

    Its security for the sake of protecting idiots from them selves.

    • PerogiBoi@lemmy.ca
      2·
      1 hour ago

      Pretty strong and judgemental opinions. Also incorrect 😀

      Immutable distros are great for the overwhelming majority of all computer users. Most people want a computer that lets them web browser, game, consume media, and do application based productivity like editing (documents, photos, illustrations, video, etc.). In fact, that was too generous of a description because most people just consume content.

      If your distro requires cli for regular usage and requires manual maintenance, it’s only suitable for computer adepts, which is a small minority of all computer users. You are not the average computer user. No one on this site is. If you can’t see that then you aren’t in touch with reality.

    • TaintTaul@programming.dev
      7·
      6 hours ago

      Just to be very clear: the name “immutable distro” is unfortunately a misnomer. In practice, the restrictions found on so-called “immutable” atomic distros are very tame.

      For example, on Fedora Atomic[1], it’s mostly a paradigm shift. That is, you can achieve (almost) everything that you can on a traditional distro, the only difference being how.

      So, if we would take OP’s query as an example, they are not able to do sudo dnf install vim btop. Instead[2], they have to do brew install vim btop. Additionally, these changes persist, as you’d expect. Please note that this is just one of the ways/methods you can achieve this on Bluefin (and other Fedora Atomic derivatives). Other methods include:

      • Install within a distrobox and export it.
      • Simply layer it.
      • Make a custom image that installs these by default and switch to said custom image.
      • Install as a sysext.

      As you’d expect, each one of these comes with its own set of tradeoffs.

      1. The atomic distro I’m most familiar with. ↩︎

      2. Knowing that they’re on Bluefin, a derivative. ↩︎

    • Strit@lemmy.linuxuserspace.show
      4·
      8 hours ago

      To be honest. Immutable distros are not for everyone. Tinkerers especially would not be suited to use them, because of all the “restrictions” in place.

      Better to find another distro in that case.

      • utopiah@lemmy.ml
        3·
        7 hours ago

        I’m not sure.

        I’m a professional tinkerer and I run Debian stable. OK ok it’s not an immutable distro but my point is that I do tinker, just NOT with my main OS.

        I’ll tinker in containers, in VMs, in my ~/bin etc but NOT in what hosts all that.

        So I would argue that what’s important for tinkerers is to establish clear boundaries on what they want to tinker on and what they do NOT want to tinker on, what can change vs what should never.

        • Strit@lemmy.linuxuserspace.show
          1·
          6 hours ago

          But a simple thing like “install a random cli tool to run on host” is often not easy on immutable distros, so it’s usually just more convinient with an oldschool distro in those cases.

          • utopiah@lemmy.ml
            2·
            6 hours ago

            I don’t think it actually is. It’s only like that the very first time when you haven’t you this specific distribution itself. Once you know how the few extra step and understand the core principle, it’s trivial.

            PS: I did tinker with NixOS, SteamOS and ROCKNIX.

  • ms.lane@lemmy.worldEnglish
    2·
    10 hours ago

    That’s the neat part - You don’t! (unless you want incredibly long update times as every new util is a new overlay!)

    • nutcase2690@lemmy.dbzer0.com
      9·
      20 hours ago

      Yup. I use brew if there is a package already, otherwise you can install in distrobox and use distrobox-export to make an alias easily in your host system

  • MalReynolds@slrpnk.netEnglish
    4·
    16 hours ago

    Layer things that genuinely need (often in boot sequence) low level access like filesystems (e.g. I have mergerfs+snapraid on my desktop). If you’re OK with a longer rpm-ostree update, you can layer some self contained things like btop with little risk, perhaps also your preferred shell. Also anything you want in TTYs if something breaks.

    vim edit /etc/fstab works fine from within a distrobox, you just need to do sudo vim /run/host/etc/fstab or distrobox-export the binary to your main shell, which means that the container will start, but you don’t have to enter it. If you fire a terminal profile into the container by default at login you won’t need to start the container when you use an exported command.

    Embrace the distrobox experience for development and generally mucking around, use Arch’s AUR, archive entire environments, there’s lots going for it.

    Linux brew is coming along nicely, use it first if there’s a formula, but I’ve been fine with flatpak, distrobox and layers (in that order) for a couple of years now.

    • ms.lane@lemmy.worldEnglish
      2·
      10 hours ago

      ie. “The Gnome Way”* exported to the OS as a whole.

      * Strip all features but allow them back as plugins that aren’t supported or secured.

  • jokeyrhyme@lemmy.mlEnglish
    5·
    18 hours ago

    I switch back and forth between bazzite and bluefin quite often

    on these and other immutable distributions, /usr is read-only, and the recommended is to use installation methods that write to your HOME (or to /var which is where docker and flatpak --system save files)

    i really should muck about with container-based development flows

    my current preference is flatpak, then whatever per-language package tooling (e.g. cargo for tools written in Rust, npm with a custom HOME prefix for tools written in Node.js, uv for Python projects, etc) when there’s no flatpak, then homebrew, then rpm-ostree as a last resort

    for editing files in /etc my recommendation would be to set the EDITOR environment variable to point at whatever you like, installed however you like, and edit with sudoedit /etc/fstab, because then your editor is not running with root permissions

    you could also point EDITOR at a custom script that mounts the target file into a container running your desired editor

  • curbstickle@anarchist.nexusEnglish
    10·
    21 hours ago

    Full caveat - not personally into immutable, 90% of the time I’m in Debian or a derivative. 9% arch or derivative. 1% work requirements made me have to use something else.

    So I’m less making a rec on method and more commenting on this:

    I’ve read that containers are preferred for development, but they aren’t persistent

    They absolutely can be, thats the point of mounting volumes. I don’t want to do the same thing more than once, so whether I’m playing with something stupid at home or I’m doing something critical at work, I’m going to make a spot for any and all changes I might want to make to use it again elsewhere, without much effort. That could mean mapping a directory to a volume, setting specific variables in my compose/kompose, having a container grab data from elsewhere every time it starts, or whatever, but the parts I want persistent are, the parts I want variable are.

    Keeping whether or not containers are the “right” way on an immutable distro aside, what isn’t persistent for you that should be?

  • Telorand@reddthat.com
    1·
    20 hours ago

    There’s a way to create aliases to the programs in the containers so that you can run them on the host as if they were installed. Look into the Boxy app (should be able to find it as a flatpak) for a GUI way to do it, but you might also look into nix to set up different dev environments. If it’s not already a ujust recipe, look into how you can layer it and how to load up different nix configs for your different environments.