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

[oiaohm]

Just to update this thread as promised, trying to install NoMachine in a Distrobox toolbox didn't end well. The normal stuff fails like you would expect because I didn't have it set up in the container (e.g. CUPS, PulseAudio). But there were a bunch of errors just writing files from the installer. It may have been as simple as the directories it was trying to write to not existing in the container and the installer not attempting to create them. The systemd service install also bombed, so there was no service to export out of the container. Besides the NoMachine issues, Kinoite also didn't pick up the Windows install on another SSD on that machine. Maybe it just doesn't run os-prober even at install time? At this point I lost interest in trying to run those machines as immutable systems and just installed Fedora KDE (from the netinst) like normal and saved myself hours of dicking around with it.

https://github.com/89luca89/distrobo...n_distrobox.md

The systemd link up stuff is still as messy as.

[pWe00Iri3e7Z9lHOX2Qx]

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.

Just to update this thread as promised, trying to install NoMachine in a Distrobox toolbox didn't end well. The normal stuff fails like you would expect because I didn't have it set up in the container (e.g. CUPS, PulseAudio). But there were a bunch of errors just writing files from the installer. It may have been as simple as the directories it was trying to write to not existing in the container and the installer not attempting to create them. The systemd service install also bombed, so there was no service to export out of the container. Besides the NoMachine issues, Kinoite also didn't pick up the Windows install on another SSD on that machine. Maybe it just doesn't run os-prober even at install time? At this point I lost interest in trying to run those machines as immutable systems and just installed Fedora KDE (from the netinst) like normal and saved myself hours of dicking around with it.

[oiaohm]

which in the end risks to just become another XKCD 927

The reality with package management on Linux we are already well into XKCD 927 at this point what a little deeper.

[89luca89]

Desktop user is less likely to want a set and forget image.

Absolutely :-)
It's still an open problem for sure, in the future something like this would be great but as you said that would require an effort from all the package managers to support this

which in the end risks to just become another XKCD 927

[oiaohm]

On the other hand probably not if we're doing lots of `apt/dnf/zypper install` inside various containers, quite sure the FS level deduplication would work well (excluding the cost of it)

That is going to be a difference. As people are using distributions in containers on the desktop they are going to be installing and uninstalling more software. Yes lot more update requirements as well. So harder on file system deduplication that what the current deployments using docker and podman are.

about the integration with a package manager, who knows that would be something that should be first upstreamed in podman/docker as distrobox is not manipulating low level file system images, but merely using the container manager of choice to create easy to use pet-containers

This is where it gets tricky. Package manager intergration is more of a requirement with the usage case of distrobox.

The reality here ideal is mostly something like a dbus service that the package manager inside the container can talk to to say I am after X files placed here host do you already have them.

Other things is network not enabled container this is something a desktop user may wish to-do but the container still need to be able to update software.

This is why I see this as more distribution need patches as it alterations to the package manager so when its in a container the way it creates files is able to be done differently. Yes the bridge bit could possible be podman/docker neutral.

Desktop user is less likely to want a set and forget image.

[89luca89]

It does depend how its done. Everything shoved into image file this can fail. Yes having file system level de-duplication is good on one hand. Having something designed smartly to de-duplicate is better. Like using a reflink or hardlinks to straight up de-duplicate has some serous advantages.

https://btrfs.wiki.kernel.org/index.php/Deduplication


The online de-duplication in BTRFS and ZFS ends up having serous cost. So even with BTRFS and ZFS you really would prefer a item like Distrobox built to be distribution compatible to be smart enough to use reflink. XFS can gain from reflink as well. Yes distrobution compadible means using the package manager information to know when files should be duplicates and reflink or hardlinks it from the get go and be smart enough to be doing this. Yes if not on a file system that supports reflink there is hard links but this requires doing what flatpak and silverblue .... does where the file system alteration is highly restricted.

Basically file system deduplication provides the tools to make the outcome decent but to take most advantage of that you need cooperation so that duplicates are found and deduplicated in processing cost effective way.

I think that OCI images already do quite a good job at it, using stages that are in common and shared between other images

On the other hand probably not if we're doing lots of `apt/dnf/zypper install` inside various containers, quite sure the FS level deduplication would work well (excluding the cost of it)

about the integration with a package manager, who knows that would be something that should be first upstreamed in podman/docker as distrobox is not manipulating low level file system images, but merely using the container manager of choice to create easy to use pet-containers

[oiaohm]

Wouldn't something like ZFS/BTRFS FS level deduplication be already a big help on this?

It does depend how its done. Everything shoved into image file this can fail. Yes having file system level de-duplication is good on one hand. Having something designed smartly to de-duplicate is better. Like using a reflink or hardlinks to straight up de-duplicate has some serous advantages.

https://btrfs.wiki.kernel.org/index.php/Deduplication

Inband / synchronous / inline deduplication is deduplication done in the write path, so it happens as data is written to the filesystem. This typically requires large amounts of RAM to store the lookup table of known block hashes and adds IO overhead to store the hashes. The feature is not actively developed, some patches patches have been posted. See the User notes on dedupe page for more details.

The online de-duplication in BTRFS and ZFS ends up having serous cost. So even with BTRFS and ZFS you really would prefer a item like Distrobox built to be distribution compatible to be smart enough to use reflink. XFS can gain from reflink as well. Yes distrobution compadible means using the package manager information to know when files should be duplicates and reflink or hardlinks it from the get go and be smart enough to be doing this. Yes if not on a file system that supports reflink there is hard links but this requires doing what flatpak and silverblue .... does where the file system alteration is highly restricted.

Basically file system deduplication provides the tools to make the outcome decent but to take most advantage of that you need cooperation so that duplicates are found and deduplicated in processing cost effective way.

[perpetually high]

This command will do the trick and show what cores you need to set.

cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

For an 8 core I'd assume 0 and 8, nohz_full=1-7,9-15 based on how my 6 core is 0 and 6 and quad cores use 0 and 4.

Excellent, thanks. Will make the update on my end.

$ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
0,8

Super cool.

Had no idea about lstopo. On debian/ubuntu, it's the hwloc package and then you can run (for those interested) hwloc-ls to get below:



edit: skeevy420 you can use this command to verify the interrupts:



From left to right is 0 -> 15, and 0 and 8 are the ones getting the frequent 1000hz timer, others are not. It's nice (especially on a notebook), I'd imagine you'd get power savings. Puts into perspective how unnecessary it is for all the cores to have always have the timer running 1000 times a second. I had this before on my 4c Haswell, but I think it's time to revisit this even if there is a slight overhead over the idle tickless.

[skeevy420]

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.

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.

This command will do the trick and show what cores you need to set.

cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

For an 8 core I'd assume 0 and 8, nohz_full=1-7,9-15 based on how my 6 core is 0 and 6 and quad cores use 0 and 4.

You can also use lstopo and you'll get something like this (my pc) and you use the values under Core L#0.:
topo.png

I've been busy, haven't played a single game or ran a single test since doing that.

[89luca89]

Really I do hope this distrobox comes successful and comes standard package in most distributions.
https://wiki.debian.org/DontBreakDeb..._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.

Yes that is one thing this fixes for sure
Memory wise it's not that bad, a single container takes a surplus of about 50-60MB of ram (podman process, containerd in case of docker etc) so not THAT bad I'd say

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.

Wouldn't something like ZFS/BTRFS FS level deduplication be already a big help on this?

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

Yea :-) in the end this type of pet-containers are definitely more similar to chroots than "one process per container" style, the good thing is the wide variety of curated images that this approach enables vs the chroot or lxc route

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

Don't use a lot of snaps but after the very first launch (where the docker image is downloaded and initialized with base software) all the subsequent launches from cold are in the 1.5s neighborhood. The hot starts are under 350ms on my 7yr old low power laptop :-)