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 :-)
Announcement
Collapse
No announcement yet.
Using Distrobox To Augment The Package Selection On Clear Linux, Other Distributions
Collapse
X
-
Originally posted by skeevy420 View PostSame 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).
Originally posted by skeevy420 View PostIt'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?
[...]
It will be interesting the reverse, Clear Linux containers on normal distributions :-)
- Likes 4
Comment
-
Originally posted by skeevy420 View PostSame 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).- 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
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.
- Likes 2
Comment
-
Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post
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.
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
- Likes 1
Comment
-
Originally posted by 89luca89 View Post
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
- Likes 2
Comment
-
Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post
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
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.
I haven't messed with remote desktop, VNC from desktop to phone, for a few years now.
Comment
-
Really I do hope this distrobox comes successful and comes standard package in most distributions.
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.
- Likes 1
Comment
-
Originally posted by oiaohm View PostReally I do hope this distrobox comes successful and comes standard package in most distributions.
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.
Comment
-
Originally posted by dragorth View PostThe 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.
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.
- Likes 1
Comment
-
Originally posted by skeevy420 View PostThanks 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.
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.
Last edited by perpetually high; 10 January 2022, 10:03 AM.
- Likes 2
Comment
Comment