Immutable Distro Opinions
Immutable Distro Opinions
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!
You're viewing a single thread.
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)
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.
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.
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.
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…
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.
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.
ujust jetbrains-toolboxNo need for distrobox for that - it's a built-in
ujustcommand, put there by the creators of uBlue. It really has everything you need out of the box.More info in the docs: https://docs.projectbluefin.io/bluefin-dx#jetbrains
Yes, I got that running - but how do I then allow the Jetbrains tools to use CLI tools in the distrobox?
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/binAlternatively you could
distrobox enterfrom the Jetbrains terminal.I would generally use
brewfor installing system-wide CLI tools, and use a devcontainer if I want to have a specific dev environment for a project.
I do my main development with Bazzite. I use the Neovim flatpak for my editor and toolbox for builds and such.
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.
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.
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.
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.