I was put off by the immutability too, as a long-time Linux user, but it turns out it doesn’t really make much of a difference. You just install things slightly differently, the biggest drawback so far are the interoperability issues with flatpaks, 'cause, you know, sandbox and all, but it’s really minor tbh.
On the other hand it’s very polished and convenient for most things, so much it converted me after an eternity on Fedora.
my thing is that it becomes hard to automate things. you install a package in a toolbox, then if you want to use that package in a script you must first enter the toolbox manually. I wish there was a way to enter the toolboxes programmatically for scripting.
You can, and should do that. Here’s what that looks like: toolbox run -c <toolbox-name><command>
All of my development tools are in a toolbox, including my IDE (Sublime Text). I created a standard .desktop file so that I can launch it like any other application, and it works perfectly, with a proper Icon and everything. Example:
[Desktop Entry]
Version=1.0
Type=Application
Name=Sublime Text
GenericName=Text Editor
Comment=Sophisticated text editor for code, markup and prose
Exec=/usr/bin/toolbox run -c devel /opt/sublime_text/sublime_text %F
Terminal=false
MimeType=text/plain;
Icon=/home/user/.local/share/applications/SublimeText.png
Categories=TextEditor;Development;
StartupNotify=true
StartupWMClass=sublime_text
To run something on the host from inside a toolbox, you can use flatpak-spawn:
$ toolbox enter ...
$ flatpak-spawn --host <command> <args>
You can even use that to (awkwardly) run something in another toolbox using the same command above:
flatpak-spawn --host toolbox run -c <other-container><command>
Sublime text specifically has support for custom build commands. Sometimes, I’m using it to develop something in a different toolbox than the one sublime is installed in. So in my custom build script for the project, I add a check to enter the correct toolbox before executing the build. Here’s what that looks like:
TARGET_TOOLBOX=example
source /run/.containerenv
if [ "$name" != "${TARGET_TOOLBOX}" ]; then
echo "SWITCHING CONTAINER $0 $@";
flatpak-spawn --host toolbox run --container ${TARGET_TOOLBOX} /usr/bin/env zsh -c "$0 $@";
exit 0;
fi
#proceed with build...
This container/toolbox workflow is far superior to anything else, as it makes it trivial to quickly test whether your code works on a different distros/versions. It all just works with your existing tooling/local workflows once you learn how to work with the tools. There really is nothing you can’t do.
…and that’s for development, which is the most difficult scenario for this type of thing. For regular every day users, immutability just works without requiring people to learn anything new besides reaching for flatpak instead of apt/dnf/pacman/etc.
Same, tried installing obs and it was so convoluted I decided to go back to Fedora.
Now I’m on Cachy and it’s so much better, only use a Windows partition for Mp3Tag, MusicBee (mostly to organise files, but I do miss the file explorer/UI) and the Adobe programs… Maybe if I get a game that doesn’t run in my pc, but so far it’s been great.
I’m here on Arch btw for my main gaming and work rig (same desktop PC), and gaming works beautifully, running Niri. I love Niri for gaming, because of how fast I can switch side to side between discord, browser, the game, etc. No weird “alt-tabbing” business. The most gaming friendly compositor I’ve come across.
The only thing with Niri seems to be that when I’m running Steam Link, the opened game doesn’t seem to get focus, which is a bit wonky. I have to go over from my TV to the PC and focus the game window. 😄 But otherwise great, if I’m by the PC itself. 👌
Seconding, Niri is amazing. Have you messaged the matrix chat about the attention? I feel like I remember reading a solution there for windows forcing focus/mouse capture that might help.
You mean the issue where the window doesn’t get focused after opening the game via Steam Link? I haven’t, I’ve never used Matrix before, actually. Wouldn’t GitHub be a viable communication platform for stuff like that?
It’s gamer-friendly in the sense that it comes with all you need for gaming by default. You can game on any major distro without problems.
Personally I’m not a fan of bazzite because of its “immutable” approach but that’s a personal preference.
I was put off by the immutability too, as a long-time Linux user, but it turns out it doesn’t really make much of a difference. You just install things slightly differently, the biggest drawback so far are the interoperability issues with flatpaks, 'cause, you know, sandbox and all, but it’s really minor tbh.
On the other hand it’s very polished and convenient for most things, so much it converted me after an eternity on Fedora.
my thing is that it becomes hard to automate things. you install a package in a toolbox, then if you want to use that package in a script you must first enter the toolbox manually. I wish there was a way to enter the toolboxes programmatically for scripting.
edit: I was incorrect, see below comment
You can, and should do that. Here’s what that looks like:
toolbox run -c <toolbox-name> <command>All of my development tools are in a toolbox, including my IDE (Sublime Text). I created a standard .desktop file so that I can launch it like any other application, and it works perfectly, with a proper Icon and everything. Example:
To run something on the host from inside a toolbox, you can use
flatpak-spawn:You can even use that to (awkwardly) run something in another toolbox using the same command above:
flatpak-spawn --host toolbox run -c <other-container> <command>Sublime text specifically has support for custom build commands. Sometimes, I’m using it to develop something in a different toolbox than the one sublime is installed in. So in my custom build script for the project, I add a check to enter the correct toolbox before executing the build. Here’s what that looks like:
This container/toolbox workflow is far superior to anything else, as it makes it trivial to quickly test whether your code works on a different distros/versions. It all just works with your existing tooling/local workflows once you learn how to work with the tools. There really is nothing you can’t do.
…and that’s for development, which is the most difficult scenario for this type of thing. For regular every day users, immutability just works without requiring people to learn anything new besides reaching for flatpak instead of apt/dnf/pacman/etc.
you’re a lifesaver!! I swear I looked pretty hard on the internet for this exact solution without success. my apologies!!
thanks for the info!!!
Well, there’s homebrew too as an option
Same, tried installing obs and it was so convoluted I decided to go back to Fedora. Now I’m on Cachy and it’s so much better, only use a Windows partition for Mp3Tag, MusicBee (mostly to organise files, but I do miss the file explorer/UI) and the Adobe programs… Maybe if I get a game that doesn’t run in my pc, but so far it’s been great.
Weird. I installed it from flatpak and it just worked straight away
I’m here on Arch btw for my main gaming and work rig (same desktop PC), and gaming works beautifully, running Niri. I love Niri for gaming, because of how fast I can switch side to side between discord, browser, the game, etc. No weird “alt-tabbing” business. The most gaming friendly compositor I’ve come across.
The only thing with Niri seems to be that when I’m running Steam Link, the opened game doesn’t seem to get focus, which is a bit wonky. I have to go over from my TV to the PC and focus the game window. 😄 But otherwise great, if I’m by the PC itself. 👌
Seconding, Niri is amazing. Have you messaged the matrix chat about the attention? I feel like I remember reading a solution there for windows forcing focus/mouse capture that might help.
You mean the issue where the window doesn’t get focused after opening the game via Steam Link? I haven’t, I’ve never used Matrix before, actually. Wouldn’t GitHub be a viable communication platform for stuff like that?