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

[perpetually high]

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.

Appreciate it- thanks.

I checked out that reddit thread. It's one of the perks of running full tickless, separate from CacULE scheduler. isol_cpus, nohz_full, all cool tricks.

I recently noticed the kernel config now recommends full tickless over idle tickless (see screenshot below) since it does give you that added benefit. However, does come at a cost over using the simple tick as opposed to full tick.



So idle tickless leads to some better benchmarks due to less overhead, but full tickless can be advantageous for many use-cases, including gaming, if utilized properly.

On my 5800X, I added right now: nohz_full=1-3,5-15 to GRUB. I think that's correct? First core is 0 and 4 respectively for its hyperthreading partner (via htop), and the rest of the cores/threads will be tickless.

(edit: should actually be nohz_full=1-7,9-15)

Saw a noticeable improvement in osbench Launch Programs benchmark with this new setup. The other benches were the same and/or slightly slower vs idle tickless.

[oiaohm]

The different systems using different compiler options, lib versions and patches will make this much less of a win than you think. If you are using several of the exact same distros and versions, you can expect some savings, but otherwise don't bet on it.

Please note I said distribution enhanced version as in for the likes of debian where user might have stable, testing and sid installed. The reproducible build of debain does keep those compiler options down and there are quite common times that a package is the same between all 2 branches it is less common but does happen were a package is the same in the all 3 right down to patches and all.

I am not expecting the saving to exist crossing the distribution line. Yes I gave the example with debian because I know there are saving to be got with de-duplication. Other distributions installing multi branches may also have de-duplication that can happen.

Yes the case of needing the exact same distribution as host bar a few minor changes does happen as well. Like you are wanting to use the wine provide by debian and the wine provide by winehq and at the time they are in package conflict. In a case like this the system you will be wanting inside distrobox will be a 99% or greater match to the host.

So I would like something like distrobox that can basically have de-duplicate clone of your host OS as well. So we can finally put the end to dependency hell and let users install the programs they want.

[dragorth]

Really I do hope this distrobox comes successful and comes standard package in most distributions.

https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian

Yes Frankensteined distributions are very common. The pop os going suicidal on Linux tech tips is caused by them mixing repositories there are many other distributions where people do this. Yes there have been alterations to the package installers so when the graphical core is going to be uninstalled that the system will not allow it. This is still not going to be helpful to those attempting to install steam and due to their distribution being frankensteined with current fix refusing to install steam. So system does not explode it still does not do what the user wants either.

Yes the route of put a distribution in a container to use its applications is a safe option. Not the most disc or memory effective but its safe.

I would love to see distribution enhanced version of distrobox in time where there is de-duplication between containers by something like ostree or btrfs to reduce memory usage and disc usage. Not all the packages in debain stable, testing and sid with a complete install are in fact different.

Yes the old administrations guides for debian use to recommend using recommend using chroots but their integration was not that great.

Also there is a very good chance that distrobox has better performance than canonical snap legacy branch.

The different systems using different compiler options, lib versions and patches will make this much less of a win than you think. If you are using several of the exact same distros and versions, you can expect some savings, but otherwise don't bet on it.

[oiaohm]

Really I do hope this distrobox comes successful and comes standard package in most distributions.

https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian

Yes Frankensteined distributions are very common. The pop os going suicidal on Linux tech tips is caused by them mixing repositories there are many other distributions where people do this. Yes there have been alterations to the package installers so when the graphical core is going to be uninstalled that the system will not allow it. This is still not going to be helpful to those attempting to install steam and due to their distribution being frankensteined with current fix refusing to install steam. So system does not explode it still does not do what the user wants either.

Yes the route of put a distribution in a container to use its applications is a safe option. Not the most disc or memory effective but its safe.

I would love to see distribution enhanced version of distrobox in time where there is de-duplication between containers by something like ostree or btrfs to reduce memory usage and disc usage. Not all the packages in debain stable, testing and sid with a complete install are in fact different.

Yes the old administrations guides for debian use to recommend using recommend using chroots but their integration was not that great.

Also there is a very good chance that distrobox has better performance than canonical snap legacy branch.

[skeevy420]

I ran Kinoite for a month on my main desktop. With Distrobox I could almost use it or another immutable distro for my daily driver. The biggest gap I couldn't work around was a good remote desktop solution.

• VNC has a bunch of downsides beyond crap performance including general PITA configuration on multi monitor hosts, lack of screen locking when connected, etc.
• X2Go doesn't work for shit on current KDE or Gnome DEs
• XRDP can't connect to the local console session AFAIK

NoMachine is the best free option I've found for Linux, but it doesn't work on immutable systems. It tries to write logs to a directory under /usr (even with a different install target), so even if you manually fixed up all the service stuff which might not be trivial it still wouldn't work.

Has anyone found a great solution for remote desktop on immutable systems that solve for the above challenges? It would be nice if all distros had a good DE agnostic way of offering a good out-of-the-box experience for remote desktop a la RDP on Windows.

My biggest issue was my lack of familiarity with the underlying Fedora ecosystem and having to layer a bunch of stuff because I kept having issues with DRM content in Flatpak's Firefox. Trying to wrap my head around two different management systems at the same time took all the fun out of playing with different kernel patches and configurations. For a minute I considered going to Fedora to drop the immutable part and simplify things, but, honestly, them being like Debian about free/non-free software and needing RPMFusion repos was the deciding factor to not use it.

I haven't messed with remote desktop, VNC from desktop to phone, for a few years now.

[pWe00Iri3e7Z9lHOX2Qx]

have you tried installing it inside the per container?
I don't really know nomachine but if it works accessing xorg socket or pipewire it should still work inside the distrobox as those sockets are shared from the host

I think I tried this over a year ago in Toolbox when I first messed around with Silverblue and it didn't work. But I was going to install Kinoite on my kids computers and our HTPCs soon (ssh access is enough for me on those machines) so I'll give it a go again with Distrobox and update this thread. Thanks for the suggestion.

[89luca89]

NoMachine is the best free option I've found for Linux, but it doesn't work on immutable systems. It tries to write logs to a directory under /usr (even with a different install target), so even if you manually fixed up all the service stuff which might not be trivial it still wouldn't work.

have you tried installing it inside the per container?
I don't really know nomachine but if it works accessing xorg socket or pipewire it should still work inside the distrobox as those sockets are shared from the host

[pWe00Iri3e7Z9lHOX2Qx]

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).

I ran Kinoite for a month on my main desktop. With Distrobox I could almost use it or another immutable distro for my daily driver. The biggest gap I couldn't work around was a good remote desktop solution.

• VNC has a bunch of downsides beyond crap performance including general PITA configuration on multi monitor hosts, lack of screen locking when connected, etc.
• X2Go doesn't work for shit on current KDE or Gnome DEs
• XRDP can't connect to the local console session AFAIK

NoMachine is the best free option I've found for Linux, but it doesn't work on immutable systems. It tries to write logs to a directory under /usr (even with a different install target), so even if you manually fixed up all the service stuff which might not be trivial it still wouldn't work.

Has anyone found a great solution for remote desktop on immutable systems that solve for the above challenges? It would be nice if all distros had a good DE agnostic way of offering a good out-of-the-box experience for remote desktop a la RDP on Windows.

[89luca89]

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).

Just for information, on Silverblue, Kionite and MicroOS, /etc is NOT read-only, it's mutable so you can still add grub stuff or generally speaking do configurations

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?
[...]

Technically, just the kernel optimization. Each container has its own userland, libc and so on

It will be interesting the reverse, Clear Linux containers on normal distributions :-)

[89luca89]

Just for information, soon it will be possible to do the reverse, so clearlinux pet-containers on other distributions, that would be interesting for example to test performance differences like steam on clearlinux distrobox on ubuntu or fedora :-)