July 2022 - MicroOS - openSUSE Mailing Lists

Distrobox by default on MicroOS Desktop
by Dario Faggioli 01 Aug '22

01 Aug '22

Hello everyone, So, the TL;DR here is that I think that distrobox [1] is a better fit than toolbox [2] for MicroOS Desktop (and _only_ for Desktop), and we should switch to that. There are some things that I'd like to make happen, however, before we do that, one of which is us having an official distrobox container image (reason explained below), like we have for toolbox [3]. It could be something like this one: podman pull registry.opensuse.org/home/dfaggioli/images/container/opensuse/tumbleweed-d… https://build.opensuse.org/package/show/home:dfaggioli:images/tumbleweed-di… Does anyone know what's the process for making it live in something like opensuse/tumbleweed-distrobox:latest rather than in my home/dfaggioli/images/container/opensuse ? Another thing. For actually putting Distrobox there, I think I should add `Requires: distrobox` to the "desktop-common" section of the patterns-microos.spec. But how do I get rid of toolbox in a way that it's not installed only for Desktop flavors? (Actually, I don't even see any Requires: for toolbox in that spec file. Anyone knows what brings it in? I would not like to go and make distrobox and toolbox conflict. Sure, we do want only one there in MicroOS, by default, but it's entirely possible that someone wants to use them together... --- Now, the long part. distrobox is better for Desktop, IMO. It is born for that purpose, it has some very nice features, for when one is inside of the container, like distrobox-export and distrobox-host-exec, it has the nice bonus added feature that it gives the user the chance to use a wide range of other distro's images [4]. In particular for GUI apps (yes, I know, flatpaks; but if a flatpak is not available or does not work well, it's really handy to be able to run GUI stuff in a toolbox/distrobox), the out-of-the box experience is awesome, as you just install the app inside of the distrobox, and it works. While in toolbox, it's all a bit meh, and a few tricky steps are necessary. In fact, all the things I mentioned are possible with toolbox too, either already or they can be implemented. But they'd made toolbox quite a bit more complex, and it would be just duplicating the effort (or someone may say triplicating, considering there's Fedora toolbox too). Distrobox also has an active and vibrant community, new features are continuously added (and bugs are being fixed, of course), it is (rightfully) getting a lot of attention in the news and at conferences and it has some _awesome_ documentation [5]. Toolbox, on the other hand, is perfect for the debugging and tweaking use-cases. The "user mode" that I added a while back is IMO still very useful, even in that case (if you even have a !root user in the system), and I plan to continue working on and maintaining it. It is super simple to understand and to hack and it is super fast and very lean, e.g., in terms of how small the image we use for it is. And these are pretty much the reasons why I propose that we go for distrobox in Desktop and toolbox in !Desktop. If we do, we'd be the first distro integrating it by default, at least as far as I'm aware of. Now, the only problem distrobox has it that the first time that one uses it, it needs to: - pull down an image - start an container, out of that image - "prepare" this container a little bit This is common to both toolbox and distrobox, of course. For toolbox, we use a special image, derived from TW, but with some (debugging oriented) packages included already. It's very small, which means it's fast to pull. During the "preparation" phase, we don't do much. We do check if some packages are there, and potentially install them, but it's just a few, and the process is still very quick (which was the actual goal). On the other hand, however, if the user really wants to use toolbox as his/hers own everyday environment, quite a bit of tweaking is necessary. Of course, we could put some of this tweaking either in the image or in the preparation phase, but that would make the image larger and/or the first setup of the container slow. Which is, in fact, the case of distrobox. :-) With distrobox, once the container is created, is already ready for everyday usage. Right now we don't have a special image for distrobox, so all that it's necessary for making it so, needs to happen in the preparation phase. This includes installing quite a few packages, which takes time. Let's look at some numbers: * Toolbox: time toolbox run -c test-tw whoami real 1m27.740s So, not too bad. * Distrobox: time distrobox enter -- whoami real 5m27,693s So, really slow. To the point of being unacceptable... :-/ Let's also check what happens when we try to use such containers, though, sticking to the example of a GUI app. * Toolbox: time sudo zypper --non-interactive in gedit real 2m43.442s And, please, consider that after doing this, gedit *will* *not* start, printing some super weird errors, which are rather tricky to understand and get around. _If_ you remember to do `zypper in --recommends gedit`, that will probably work (but takes longer, as more packages are installed). * Distrobox: time sudo zypper --non-interactive in gedit real 0m29.143s And gedit works! In summary, distrobox is super slow when creating the container the first time, but then it's fast and all is working. Toolbox is fast when starting, but then normal operation might be a bit slow and tricky. In my opinion, this makes distrobox a preferable. It'd be awesome, however, if we could make the first time setup faster. As a metter of fact, we can, with a custom image for distrobox, here's what we get: time distrobox enter -n test-dbx -- whoami real 2m32.939s Which is quite fine, as it's only 1 minute slower than toolbox. And in return we get all the features and all the benefits of a fast and fully functional out-of-the box environment. The custom image I'm using for these experiments is this one: https://build.opensuse.org/package/show/home:dfaggioli:images/tumbleweed-di… Note that this is just a first attempt. There are high chances that the image can be further optimized (and both me and Luca will look into that), hence reducing the first time setup time even more. This means that we can achieve a combined effect of first time creation time of 2m30sec (or less), and quick and 100% working out of the box experience (gedit installed and working in 30secs). And this is why I'm asking whether it would be possible to make it official, published under something like: registry.opensuse.org/opensuse/tumbleweed-distrobox:latest And, if yes, what's the process for getting it there? Thanks and Regards [1] https://github.com/89luca89/distrobox [2] https://github.com/openSUSE/microos-toolbox [3] https://registry.opensuse.org/cgi-bin/cooverview?srch_term=project%3D%5Eope… [4] https://github.com/89luca89/distrobox/blob/main/docs/compatibility.md [5] https://github.com/89luca89/distrobox/tree/main/docs -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)

3 2

Introduction
by Marc H. Balmer 15 Jul '22

15 Jul '22

Good day I (ab)use the change of the mailing list to introduce myself. Long time Unix developer from Switzerland, former BSD developer and kernel hacker. I bought to HP 380 servers and I plan to install 6 VMs on each to run microOS and host Kubernetes, using k3s. So on each server two k3s controller and four worker nodes. - Marc

1 0

First Discussion
by Richard Brown 14 Jul '22

14 Jul '22

This email is just really to check if the mailinglist is working, as all previous test emails seemed to vanish and never showed on the archive. Hopefully this one will, then I'll start telling people about the list -- Richard Brown Linux Distribution Engineer - Future Technology Team SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman

2 1