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?
Use homebrew for Linux.
Install them in your $HOME
For example $HOME/MY_CLI_TOOLS
Add it to your $PATH
That’s the neat part - You don’t! (unless you want incredibly long update times as every new util is a new overlay!)
Incredibly long update time? Yeah… No. Definitely not something in had any issues with due to layered packages.
And to create your own image, you need half the repo as dependency and a 20 steps chain.
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/fstabor 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.
brew install btop vimhttps://docs.projectbluefin.io/command-line/#installing-applications
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
dockerandflatpak --systemsave 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 permissionsyou could also point EDITOR at a custom script that mounts the target file into a container running your desired editor
Distrobox is pretty shrimple
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
I think you’re supposed to use
brewon uBlue.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.
I don’t think you understand the point of an immutable distro.
Wow, I always thought it was MacOS only, how interesting!
I’ve done this, like with gping. It’s great.
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?
what isn’t persistent for you that should be?
They don’t actually know
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
nixto set up different dev environments. If it’s not already aujustrecipe, look into how you can layer it and how to load up different nix configs for your different environments.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.
You seem really angry about a concept you clearly do not actually understand.
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 dobrew 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.
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.
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.
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.
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.
Sure. But you have to figure that out first.
I’m just saying. It’s not for everyone. I feel too limited when trying immutable stuff, so I stick with my classic. 😀
I feel too limited when trying immutable stuff
Is this rooted in experience? Or mostly just on vibes?
Seems anything you have to “figure out first” is no beuno.
