Immutable OS, flexible experience. #Aeon uses #Flatpak for apps and #Distrobox for workflows, so you get stability and control. It’s the future of the #Linux desktop. #oSC25 talk. #openSUSE https://youtu.be/hh4gnNCG7dM?si=W2R0O5rKdEzh54uv
#Distrobox
Получилось запустить #КуМир на Debian Buster через #Distrobox. Теперь надо разобраться, как сделать ярлык.
To be honest I'd been thinking of replacing #tmuxinator for a while anyway, as I'm trying to reduce my reliance on the #AUR.
Where I can, I'm switching to alternatives in #ArchLinux's repos. If that's not possible, I'll see if it's in another distro's repos and run it in #Distrobox (for example, pdf2djvu in an Ubuntu 24.04 LTS container). Finally, as a last resort, I'll use a #Flatpak.
DistroShelf: Distrobox wird bunt
https://fed.brid.gy/r/https://linuxnews.de/distroshelf-distrobox-wird-bunt/
DistroShelf: Distrobox wird bunt
https://linuxnews.de/distroshelf-distrobox-wird-bunt/ #distrobox #distroshelf #container #virtualiiserung #linux #linuxnews
I've been using #bluefin #fedora #linux since May 2024 and I am sold on the #atomic 'cloud native' mindset.
Now after running a #nix overlayed custom image for a few weeks I am getting this tingling sensation of whether to turn the approach around and switch to #NixOS with an optional #distrobox and #flatpak environment.
A fully declarative system seems like the next logical step after atomic linux. OCI containers start to feel clunky after having experienced nix flakes.
Buscando, por cierto, maneras de instalar aplicaciones en distribuciones inmutables, en OpenSuse Aeon y Kalpa recomiendan el uso de #DistroBox, una forma de crear contenedores realmente sencilla, donde, por ej, puedes ejecutar una app de otras distribuciones como si fuese nativa del sistema.
Por cosa como ésta amo linux.
Este videotutorial explica su funcionamiento básico para cualquier usuario habitual de linux.
Curious how #Aeon handles dev tools or #CLI utilities on an #immutable system? That’s where #Distrobox shines. Run your favorite distros, package managers, and scripts without breaking the base. Check out the #oSC25 talk. #openSUSE #Linux https://youtu.be/hh4gnNCG7dM?si=W2R0O5rKdEzh54uv
Getting kinda frustrated with #DistroBox. I've installed it on my #SteamDeck using the instructions found on the distrobox.it website, but every time I reboot my machine I cannot reenter the images I've made. My only solution is to delete everything and start again...
Not the end of the world, just a slight annoyance before anytime I sit down to do programming...
Today was the first time #ChatGPT actually helped me with something instead of suggesting useless shit I've already tried. Now I know you need libxcursor to make java applications show a proper cursor inside of #distrobox.
How do you people use #distrobox or #toolbx?
Do you create one container per project/topic you are working on?
Or do you have your #containers named like their base image and install your stuff just wherever it is easiest?
Do you reuse your home dir for each container or create a private one for each?
Do you have a "default" container or do you work on the host if you open up your terminal?
Where do you install #tmux (host, default container, in each container)?
Nice article at @lwn
"Distrobox is a project that is designed to bring the cross-distribution compatibility to the desktop and allow users to mix-and-match Linux distributions without fussing with dual-booting, virtual machines, or multiple computers."
I haven't tried Distrobox yet, but I've bookmarked this great review by @jzb for when I do:
@pheonix As it happens I just wrote about using Bazzite and Distrobox for @lwn. Literally just hit publish on the Distrobox article, the Bazzite piece went up yesterday.
You can use a terminal emulator like Ptyxis to "integrate" with a Distrobox container -- just set it to open right into a Distrobox of your choosing -- and operate like that's the host. For me, it's not much different than just running a package-based system -- I hardly notice any difference.
I've also gone a bit off the deep end and am building my own custom Bazzite image with niri. If I'm ever satisfied with it I may post a link to it for others to use if they like. There's also Spacefin which might suit folks who want niri or Cosmic right now...
tl;dr -- I don't think it's too much friction, if you just embrace using a single Distrobox as the default environment for new apps, etc. YMMV of course. #LWN #Distrobox #Bazzite #Fedora #bootc
Interesting. In parallel, I set up a Docker container "exactly" as a Distrobox container to get ROCm running on Bazzite. And in the Docker container I get
> Memory critical error by agent node-0 (Agent handle: 0x5578c3d90580) on address 0x7f851f8a1000. Reason: Memory in use.
when running `clinfo` after "Max work group size" while in the Distrobox container it works without this error. It would be nice if I could find out what the differences are between them, as both use Podman. But these container techs are so opaque in contrast to LXC or systemd-nspawn :-/
@passthejoe because it's the default on whatever it is you're running? I think #distrobox is probably a better option for a desktop usecase, but #toolbx is perfectly cromulent for a server, where you're basically just using #microOS or #coreOS for a container host, it doesn't need to be fancy.
weird but #distrobox is not in the @VoidLinux repos. tho it's easy to install, i created this simple project to build an xbps package automatically
https://git.ralen.top/ralen/distrobox-xbps/
if you want to uninstall it, you can use uninstall.sh after packaging, tho simple "xbps-remove distrobox" should be enough - the official script does not seem to contain any different logic for removing containers etc
now i can play factorio and windows games from my void installation through distrobox! lutris doesn't work on #void, tho i could manage to run one of my #wine games with void's wine, but other return some wow64 errors and can only be run with prepackaged proton with umo... so i run them from #lutris from distrobox instead.
had to create user services to run #podman as a user, by default it comes with /etc/sv/podman to be linked to /var/services/podman, starting podman as root, so i *copied* the services' scripts to ~/.config/sv and linked to ~/.config/service/, and now podman runs from my user, and i can access it fine with podman-tui
so #runit services are just sets of scripts, basically you need the /var/service/name/run (~/.config/service/name/run) - executable sh script which starts the needed daemon as soon as the file is detected, and /etc/sv (~/.config/sv) is a directory where these scripts are stored
/etc/runit contains scrpts that are run at startup and shutdown, it's easy to create a custom script. for example, i have a script hx /etc/runit/shutdown.d/6-save-backlight.sh which has only 2 lines: mkdir and brightnessctl get > file, and /etc/runit/core-services/12-restore-backlight.sh that set's the brightness with brightnessctl if the file exists. and it just works! #systemd really overcomplicates things, runit is much more intuitive and easy, and everything i need is working just fine
#linuxgaming #voidlinux
@dottorblaster@fosstodon.org @89luca89@fosstodon.org this project is just so magnificent -- thank you, wonderful Devs! :purple_heart:
#Distrobox
Another mighty release for #distrobox: we solved a bunch of regressions and delivered tons of fixes to tiny issues that maybe affected you, beloved users 😬
Also @89luca89 noticed this was the first release with a commit of his own _at all_ LOL
Coming soon to your friendly neighborhood distro of reference!
Client Info
Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst