Using Distrobox To Augment The Package Selection On Clear Linux, Other Distributions

[skeevy420]

But... that's not a systemd thing as well... It's a kernel provided ramdisk.

Per the Arch Wiki: glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for POSIX shared memory. Mounting tmpfs at /dev/shm is handled automatically by systemd and manual configuration in fstab is not necessary.

They make it sound like a systemd thing.

I have only heard of Distrobox for all of three hours and I'm already way more interested in it than the concept of immutable OSes like Silverblue and MicroOS, simply because I touch my root file system very frequently.

Same here. I didn't realize how much I messed with my root until I used Silverblue. Today I've tweaked /boot/grub/grub.cfg, /etc/default/grub, and /etc/default/cpupower for amd-pstate. Added amd_pstate.enabled=1 to the kernel command line and switched the governor over to schedutil since the docs mention amd-pstate is geared towards ondemand and schedutil (I was using performance).

It'll be interesting to see how Arch or Fedora packages perform on top of an optimized base like Clear. Will the Distrobox distribution pick up some of the optimized base's enhancements?

Thanks perpetually high. Your Phoronix posts are are some of the most informative places when Googling for amd-pstate right now. It's weird, dmesg never once showed mention of amd-pstate. For me on my Zen 2 Pro that has cppc in /proc/cpuinfo it didn't work until I removed amd_pstate.shared_mem=1 from my command line. That's when cpupower finally changed to amd-pstate...and I was running dmesg | grep amd as a catch-all.

Also added in some Cacule tweaks I found on Reddit when looking up CPPC information before I figured out shared_mem=1 was my problem. It's tsc=reliable nohz_full=1-5,7-11on my 4650g. Just thought I'd share that.

[89luca89]

I have only heard of Distrobox for all of three hours and I'm already way more interested in it than the concept of immutable OSes like Silverblue and MicroOS

Thanks :-)

I personally use it on a normal distribution, for work on an Ubuntu 20.04 LTS with a Fedora Rawhide distrobox for development and an Archlinux one for AUR softwares so yea it's useful also on non-immutable OSes for sure

[Sonadow]

Hi, author here :-)

The purpose of distrobox (and other pet container managers like fedora toolbx) it's not app distribution, but creating a highly integrated environment with your host distribution.
So for example in use with immutable OSes or if you want to use AUR but have Debian stable as you main system, etc etc

As explained before, think of it like a Bedrock Linux, but without having to use a dedicated OS for it.

The fraohical app integrations comes as natural conseguence of the host's integration
And not only the apps, it supports exporting also systems services and single binaries

Also it does not provide sandboxing like flatpak or snaps, right now the whole hosts filesystem is accessible from the container, and that's needed for the aforementioned integration

So different use cases that have some touch points in their Venn diagram :-)

I have only heard of Distrobox for all of three hours and I'm already way more interested in it than the concept of immutable OSes like Silverblue and MicroOS, simply because I touch my root file system very frequently.

[pWe00Iri3e7Z9lHOX2Qx]

This project is freakin' awesome. Since there were some questions about what it was all about, it, and some other projects like it are essentially nice wrappers around podman. They attempt to make doing a bunch of your work in containers as painless as possible. That kind of workflow is basically essential for immutable distros like Silverblue / Kinoite / MicroOS (unless you overlay everything which defeats the purpose and causes problems). But I say unto you my fellow Phoronixers, thou must not use an immutable distro to reap the benefits of Distrobox. Nay, bask in its glory on your distro of choice!

I'm on Fedora 35 using KDE (from the everything net installer). What if I want to try out a new version of some GUI app from Arch? What if you want to do it cleanly without what you install dumping garbage all over your home diretory?

distrobox-create --name arch --image archlinux:latest --home /home/foo/Containers/arch/

I've just created a container of Arch Linux and set a custom $HOME so the things I install won't litter all over my real $HOME.

distrobox-enter --name arch

I'm in my container.

echo $HOME
/home/foo/Containers/arch

Looks good, let's install some junk.

sudo pacman -S gedit

Package (110)                        New Version                 Net Change  Download Size

extra/adobe-source-code-pro-fonts    2.038ro+1.058it+1.018var-1    1.86 MiB       0.92 MiB
extra/adwaita-icon-theme             41.0-1                       22.41 MiB      10.67 MiB

(...chomp the other packages...)

Total Download Size:   106.32 MiB
Total Installed Size:  498.20 MiB

Gedit is installed. Launching it from the command line from the container works as expected.

gedit

Gui gedit app launches. Wouldn't it be cool if I could easily export the .desktop launcher out of the container for easier use from the host?

distrobox-export --app gedit

Gedit launcher with proper icon added to my host. I can remove it with

distrobox-export --app gedit --delete

And just nuke the whole container. Distrobox is phenomenal for playing with stuff. The dev is very responsive to issues, and I dare say thinks about what it should do in a far more product focused way than Red Hat is doing with Toolbox. He has already solved my two biggest issues with Toolbox.

• Being able to set a custom $HOME easily if desired
• Being able to export GUI .desktop launchers

It's also trying to be generally host/container agnostic, and it's written in POSIX compliant sh. Dope.

[Vermilion]

First cup of coffee...I meant /dev/shm

But... that's not a systemd thing as well... It's a kernel provided ramdisk.

[Ipkh]

Would be nice if Intel integrated some link to portage, so we can build our own optimized packages. It would be move to finally move to more optimized packages overall and not be forced to choose between Gentoo pain and Clear lack of packages. Even just an advanced Architecture mirror of Debian/Ubuntu/Redhat/etc to choose from.

[89luca89]

I kinda wonder why Distrobox hasn't been done years sooner. Things like Flatpak and Snap have their place, because they're a good way to guarantee results no matter what you use, but they also kinda defeat the purpose of using an optimized distro. I don't know exactly how tightly integrated Distrobox is, but at least it isn't causing more fragmentation in the Linux desktop, which has always been its #1 issue. Had Distrobox come out sooner, that may have been good enough to not need all these pre-packaged variants.

Hi, author here :-)

The purpose of distrobox (and other pet container managers like fedora toolbx) is not app distribution, but creating a highly integrated environment with your host distribution.
So for example in use with immutable OSes or if you want to use AUR but have Debian stable as you main system, etc etc

As explained before, think of it like a Bedrock Linux, but without having to use a dedicated OS for it.

The graphical app integrations comes as natural conseguence of the host's integration
And not only the apps, it supports exporting also systems services and single binaries

Also it does not provide sandboxing like flatpak or snaps, right now the whole hosts filesystem is accessible from the container, and that's needed for the aforementioned integration

So different use cases that have some overlap points in their Venn diagram :-)

[skeevy420]

That's not on systemd either. Both /tmp and /var/tmp are part of the FHS and presumably serve different purposes.

First cup of coffee...I meant /dev/shm

[Sonadow]

System32: So are y'all on the C drive or the D drive?

/boot: Urrmm....

/srv: Urrmm....

/tmp: Urrmm....

systemd:

/home: Urrmm....

/usr: Urrmm....

[Vermilion]

/tmp: Just shut up /srv. At least you're consistent. systemd likes to hide me at /var/tmp.

That's not on systemd either. Both /tmp and /var/tmp are part of the FHS and presumably serve different purposes.