I recently took up Bazzite from mint and I love it! After using it for a few days I found out it was an immutable distro, after looking into what that is I thought it was a great idea. I love the idea of getting a fresh image for every update, I think for businesses/ less tech savvy people it adds another layer of protection from self harm because you can’t mess with the root without extra steps.

For anyone who isn’t familiar with immutable distros I attached a picture of mutable vs immutable, I don’t want to describe it because I am still learning.

My question is: what does the community think of it?

Do the downsides outweigh the benefits or vice versa?

Could this help Linux reach more mainstream audiences?

Any other input would be appreciated!

  • kylo@programming.devEnglish
    3·
    2 days ago

    Has anyone had good success with setting up a development environment in an immutable distro? I love the entire concept because it fits with a lot of my other software preferences, but the tools for containerized dev environments felt frustrating.

    Like, what do you do for your editor? vscode + devcontainers feel like the best option, but it’s rough when I need other IDEs (like I use some of the Jetbrains products). Stuff like toolbox works well too, but to get an editor in that, you have to install it in each one, or make a container that has it built in.

    Otherwise, I’ll stick with plain Fedora — I use flatpaks for all of my apps anyways (except my editor)

    • Discover5164@lemm.eeEnglish
      3·
      2 days ago

      i started learning rust with nixos, you can declare a shell.nix with everything needed for the environment, and those things will only be available in that folder.

      there are caveats and annoyances to this like building a python environment costed me some time, because python packages sometimes require compling and all the shared libraries in nix are not in the right path (because you can have multiple versions installed) so you need to set some env vars to patch this.

      nothing that gpt cannot solve.

    • marlowe221@lemmy.worldEnglish
      4·
      2 days ago

      Personally, I have found the developer experience on Bluefin-dx (the only one I’ve tried…) to be…. mixed.

      VSCode + Devcontainers, which are the recommended path, are pretty fiddly. I have spent as much time trying to get them to behave themselves as I have actually writing code.

      Personally, I’ve resorted to using Homebrew to install dev tools. The CLI tools it installs are sandboxed to the user’s home directory and they have everything.

      It’s not containers - I deploy stuff in containers all the time. But, at least right now, the tooling to actually develop inside containers is kind of awkward. Or at least that’s been my experience so far.

      I think the ublue project is fantastic and I really like what they are doing. But most of the world of developer tooling just isn’t there yet. Everything you can think of has instructions on how to get it going in Ubuntu in a traditional installation. We just aren’t there yet with things like Devcontainers.

      • asap@lemmy.worldEnglish
        4·
        2 days ago

        Using brew is the recommended method on uBlue, so you’re already doing the right thing.

        That being said, I use Jetbrains and devcontainers on Bluefin-DX and it’s been flawless for me, straight out of the box.

        • marlowe221@lemmy.worldEnglish
          3·
          2 days ago

          Hmmm, interesting. I like brew, for sure. And devcontainers worked ok for me when I was working on something by myself.

          But as soon as I started working on a side project with a friend, who uses Ubuntu and was not trying to develop inside a container, things got more complicated and I decided to just use brew instead. I’m sure I could have figured it out, but we are both working full time and have families and are just doing this for fun. I didn’t want to hold us up!

          Our little project’s back end runs in a docker compose with a Postgres instance. It’s no problem to run it like that for testing.

          Maybe a re-read of the documentation for devcontainers would help…

    • asap@lemmy.worldEnglish
      3·
      2 days ago

      I use Jetbrains, devcontainers, and distrobox on Bluefin-DX and it has been flawless out of the box. There’s a single command to install the Jetbrains toolbox, which let’s you then manage all their apps.

      Couldn’t recommend it enough, made my development lifecycle so easy.

      • FooBarrington@lemmy.world
        1·
        2 days ago

        How do you use the Jetbrains tools with distrobox? So far I’ve manually installed the toolbox inside my distrobox, but that doesn’t seem to be the preferred approach.

            • asap@lemmy.worldEnglish
              1·
              1 day ago

              For distrobox, you can export your CLI tools, then use them anywhere in your system:

              distrobox-export --bin /usr/bin/some_app --export-path ~/.local/bin

              Alternatively you could distrobox enter from the Jetbrains terminal.

              I would generally use brew for installing system-wide CLI tools, and use a devcontainer if I want to have a specific dev environment for a project.

    • ahal@lemmy.ca
      3·
      2 days ago

      I do my main development with Bazzite. I use the Neovim flatpak for my editor and toolbox for builds and such.

      • atzanteol@sh.itjust.worksEnglish
        3·
        2 days ago

        Running cli apps like neo vim from a flatpak is frustrating… “flatpak run com.something.neovim” is just the worst way to handle things. Complete deal breaker.

        • ahal@lemmy.ca
          1·
          2 days ago

          Why is it a bad way to handle things?

          I have an alias set up and SDKs enabled. The experience is indistinguishable from a regular install. But you could also layer it onto the os image or install it in user space if you don’t like flatpaks for the extra resource usage or something. That’s a complete non issue for me though.

          • atzanteol@sh.itjust.worksEnglish
            2·
            2 days ago

            I have an alias set up and SDKs enabled. The experience is indistinguishable from a regular install.

            That’s not indistinguishable - that’s you working around the problem of running flatpak run some.domain.IForget(which - BONUS is case sensitive which is awesome) to run neovim.

            Snaps install a binary you can run. Flatpaks make you remember the 3 part domain to run things. So you setup aliases after installing things to run them, and if you uninstall them you need to remove your aliases. It’s a complete own-goal by the flatpak developers that this mess exists and is completely unnecessary. Simply providing an option to create and manage a script in .local/bin or something would be all it takes to make flatpaks usable from the CLI in a way that isn’t obnoxious.

            • ahal@lemmy.ca
              1·
              2 days ago

              That’s a good point. I should have said “indistinguishable after some tinkering”. You raise a valid complaint, though it’s not a deal breaker for me.