 Hello, everyone. I am Luca. I am a DevOps engineer. I would like to think of me as an open source. Today we will talk about this Dropbox. What is this Dropbox? This Dropbox is a tool written in POSIX Shell, very simple, which wraps podman or docker to have an abstraction of the complexities of these tools and create environments that simply integrate with the host. So it was born inspired by the great work of Federalist Toolbox. But I needed a solution that could work both with podman, docker or in the future with other container managers, for example. And so my solution also could be distribution agnostic both on the host side and the guest side. And generally speaking, something that could make easier to use software that wasn't packaged as flatpack or as an app. So how could we think of it? So if you think of flatpack as your app, which is unbound from the base operating system or docker as a service, which is unbound and isolated from the base operating system, this Dropbox or a pet container is an entire user space unbound from the base operating system, but still very integrated with the base host. You could think it seems like CH root with extra steps and you could be right, but actually not. So as I was saying, it uses container managers. So it's simpler to use than simple CH root. The CLI experience is a little bit more polished. And container managers are battle tests that they are used in the past years in the cloud environment and they are very, very, very reliable. And they integrate an easy-to-use image management system, and you can tap in the healthy ecosystem of container images for the cloud. So you can have a lot of various operating systems and versions, and most of the time they are even officially maintained by the main projects. So we have two, for now, just two container managers supported, which is Podman and Docker. Podman can run in rootless mode, no pseudo required, or can run in rootful mode if you need it. Docker can only run in rootful mode for now. They are much faster and lighter than VMs and the goal is to use them as a complete replacement for your CLI in the way they use. Optionally, they can even act as a separated system, having a separate system distance or unit distance, and even have complete graphical session. A word of warning, this is not a security enhancing tool. This is not like flat pack that send boxes to your stuff, so you are more secure. This is not less secure than your base operating system. So you have some advantages by using a rootless distro box using Podman, because even inside your container you can use pseudo, but you never are really root on the base operating system. You are still your user. So you have a little bit of an advantage there, but for a rootful distro box, root inside the container is root outside of it, so be careful. The integration is quite tight with base host. Obviously it shares the home directory of the user, but we have also integration with Rayland, audio, both pipe wire and pools, SSH agent, GPG agent. We have the user system D integration, so from inside the distro box you can just use sys and CTL dash dash user and use your host system D. You can use the host debug user session. Akses for removable devices, so slash dev. As I was saying optionally, isolated sys in the instance, it automatically generates desop entries for the containers that you create, so it's easier to access them. You have them tightly in your application list. And there is integration, so you can launch host command from the container and vice versa, so we can have tight integration both ways. The usage was thought to be as simple as possible, so the main goal was to abstract the complexity, so you have just some basic management commands, you have your create, enter, list, remove and stop for the containers. Everything can work without specifying any flag, any, anything. They are saying default, I think they are saying default. You have, you can choose your image, you can choose your name, you can even choose a custom home for the host, so you don't litter your home with dot files, for example. And I also add some utilities, one is the upgrade command, it will just cycle through all your distro boxes and use the package manager of each one to keep them updated like a center hub. You have the ephemeral distro boxes, which are basically similar to the docker or podman run dash dash rm, which will create, enter, and when you exit destroy the temporary container, which is very useful for testing or playing around. And there is the generate entry command to create desktop icons for your containers. So which are the use cases for this type of tool? Obviously, the immutable desktop is one of the use cases, I use one, so it's not really easy when you need the tool to just go install it because you need to reboot. So if you are on endless OS, Fedora, Silver Blue, or Kinoite, and Micro S, and lately I added support for the Steam Deck, you can have your mutable environment and play around with it. But even if you are not on an immutable operating system, you can have the advantages of diminishing the number of packages in the base operating system so you have less moving parts that can break, so updates are more likely to be successful. You have a user land that can be easily replaced and it's easier to make reproducible user lands if you distrohop a lot, for example. But talking of apps, some apps are specific to some distribution and maybe they are not tested on other versions of the same distribution or not supported in newer or older systems, or simply, yeah, they are not supported. Maybe you can use a tool like Alien to pass a dev to a RPM or vice versa, but then you have dependency that can cause the system breakage. And maybe for this app there is no flatpack, there is no snap, or this app is not packaged at all. Maybe it's only on the AOR, on copper, OBS, or on a PPA. Or generally speaking, you don't want to litter your system with a lot of stuff that maybe you don't use anymore. So this is useful. And another use case, which actually is why I started developing this, was having an enterprise laptop. And sometimes in enterprise you have some regulations that you have to follow and maybe you cannot be a super user on your laptop, but you need your tools to work. Maybe you are a DevOps engineer, a software engineer as his admin and you need your stuff to work. You can do that in your containerized environment. Or generally speaking, mix and matching distros. You may be on a LTS stable release and you want latest software for some reason, or you are on bleeding edge release and you need a very old software for some reason. And these sub boxes can ensure compatibility up almost ten year back in time. So the diversity of distribution are about 60, if we count combinations of permutations of version and distribution themselves, they go back to Debian 7, Ubuntu 14, or for the oldest on the list. You can go older if you have custom images, for example, because maybe the mirrors of the repo are not working anymore. But mainly if you go to back in time, like on Debian 6 and CentOSix, the libc is a little bit too old and won't work with kernels after 4.11. And you will need that grab-entry for the VCs code, but it's doable. And obviously there is support for all the latest distribution, Arch Linux, Fedoro-Rohai, Tumbleweed, Ubuntu, Debian and Stable. And you can mix and match however you like. Container side, the only dependency is really having a POSIX compliant BNSH and having one of the supported package manager. Why a package manager is needed? Well, if you take a cloud image, for example of Ubuntu, it's only 30 megabytes, and it's really, really small and lacks a lot of software that maybe you expect even on a minimal install. So what I do during the initialization of the container, I install all the basic stuff that user expects even for a command line environment so a package manager is needed. If something is not supported, just open a feature request, or if you want to help, open a pull request, every contribution is always welcome. Performance-wise, I did some tests using the Foranix Test Suite and it was on a Fedora 35 host using a Fedora 35 container and the Clare Linux container. And as you can see, the overhead of Fedora 35 container on top of Fedora 35 was really minimal. We were between 1% and 2% of the host performance, but the red part is the Clare Linux container. The Clare Linux container is consistently faster than the host itself because of the optimization that Clare Linux brings. So the overhead is low enough to reap the benefits of having something like that. So talking of apps, you don't want to always open your terminal, enter the distro box and launch your apps, maybe. So I've provided an export command that will integrate the applications from inside the container out to the host. The basic one, you can export apps, single binaries or user system deservices. We will see in a demo later. But for example, this is a simple arch container which has an atom installed inside. You want it outside of it. You just export dash dash app and you will have your atom or your app outside of the container easily accessible and it will be all automatic for the launch and it will be transparent for you. And same is for binaries and system deservices. System deservices will have prefix which will be the name of the container that is running that one, but you can just use it from your host. Same for the binaries, you just put them in your path and you can use them transparently, really. So let's show something. Maybe white is better. So let's do a normal terminal. So starting from here, let's do it. Starting from here, we can list our disturb boxes simply by listing them. There will be green if they are running, there will be yellow if they are not. And for example, an example of application I would like to show is Bitwig is a digital audio workstation. Actually Bitwig is distributed as a Debian package for Ubuntu 24 app or a flatpack. So obviously you can use the flatpack. But sometimes you cannot use the flatpack. For example, if you want to use Jabbridge, which lets you use plugins from Windows inside the Linux digital audio workstation. So to just install it, we can, I created previously an Ubuntu disturb box and just you enter the Ubuntu one. You can see it will, for the first time it will do some steps. The very first time you create the disturb box and launch it is a bit slow because there is the first step, installing basic packages obviously depending on your internet connection it has to go and fetch the packages. But the other times you enter it for example in our exit enter it again for the last time. So let's install the bitweek. I should have the command. Yeah. So this one is the command to install it from the between the documentation really enables the 386 architecture and installs it really. Hopefully, yeah. And as you can see there are some other outputs there are a series of hooks that disturb box implements inside the gas container to make it work with the host integration so you don't have like read-only paths or generally speaking you have maybe some type of conflicts. So let's launch it bitweek. So it's running what it's saying and yeah I mean okay it's on the other screen sorry there it is and it has full audio integration with the host I don't really see what I'm doing yeah so it's working as expected and you have an icon in the in the dock I will quickly change the screen sharing option just to show you no, not a good idea sorry for that yeah so I could show you how to integrate it but probably you won't see you won't see the icon but let's try anyway exit and if you disturb box export dash dash up bitweek so it was feedback that was exported you can see it in the local application you will see that there is a boon 2 24 bitweek.desktop so you have to trust me it's in my application list now you can export the binary of bitweek itself so if we go which bitweek so if I want to export it I can do this subbox export this one in I don't know local bin for example and if I exit the container so now I am on the host I can launch bitweek studio directly from the host it will be transparent so if you install other types of of binaries like I don't know ffmpeg or mpv something like that it will be like having it on the host itself and as I was saying we can also export services so we can I created a distro box for this service which is sync thing it's a synchronization file synchronization program if we install it this one will create a systemd service but you cannot really use systemd services inside the container if you don't create one with separate systemd so what we can do is distro box export service sync thing it will inform you that you have now this new service which you can just see like that now it's not running so you can restart it demo reload as you can see now it's running it's running inside the container but you access it from the host systemd and well it's available here simply so it's pretty transparent and you can simply access what it will be otherwise difficult to access really another example in this case on an immutable file system having the possibility of installing rootful containers is important for example list you can see I am running a libvert container let's enter it this one is analmalinics container which has a separate systemd instance this one is completely separate from the host and you can have your own services in your like libvert so this one is really useful in at least in my case because installing libvert and all the dependency it's quite demanding and it's a lot of stuff this is just simpler for me I open a container I can dnf or yum or whatever install whatever I need and then you can just use it as a normal distribution much more similar for example on lxc for example where you have a complete system inside and I can use virt manager to access it and virt manager itself is in another disrbox which is my main disrbox so it's working as expected and it helps availability it helps with the incompatibilities and with testing also because you can test on various type of environments much easier and you don't have the quirks of being maybe sandboxed you cannot launch a graphical application or you cannot launch I don't know some type of process so there are also ways to manage it graphically there is an emerging app called Atoms where this is from Mirko Bromlin and this lets you install from FlatHub this application and then you can manage it simply from this application you can have a console you can just add your terminal launch also application from here you can launch application from here so it's a very neat way I really like it way to manage them so you have your command line, your graphical applications and yeah you can even I will not demo this because it's a little bit complicated and unstable but you can have separate instances of GNOME for example this is a CentOS 7 machine where it's running the latest GNOME inside the distro box and you can just select it at login time you can do the same with KDE so it can be also useful in case you are stuck on another distribution to have access to one of the latest softwares this is a little bit experimental still the integration here is really advanced so there are still corner cases but it's double and yeah so, back to the so what are the next steps for the project one of the missing stuff is rootless docker and container D plus ctl support sadly I can still use them because it's missing an option for the username space kipid which is useful to map yourself inside the container so you don't have mismatching identities alternate becans there is cutman which is a CHROOT manager that I wrote and there is K Run VM to run micro VMs on top of this so you can for example have your CentOS 7 inside the micro VM CentOS 8 and the important thing is it's really useful for if you have to do kernel development for example adding a sandboxing mode which can seem a bit counter intuitive because until now I was talking how much it is integrated with base host but having the bare minimum integration just to have your graphical application working but having a sandboxing so you can trust it a little bit more is useful obviously adding more tests right now have cut some pipelines of github to continuously test the compatibility of all the distribution that I declare in the documentation having better CLI UX feedback is always welcome so TLDR these are books is a nice tool to enable both backward and forward compatibility in the software adds you the freedom to use whatever distribution you want and without having to restyle everything each time and generally speaking making you more comfortable with your own machine if you want to contribute it's on github and there is a contributing document that you can read and helps you to have the basics for the contribution report bugs, typos plenty of them improvements I'm always open to constructive criticism and improvements and if you feel like contribution the contribution is always welcome I'm listing here for whoever downloads the PDF there is a list of useful links on how to use it so there is the distrobox documentation I spent a lot of time on that so this should be quite exhaustive there is the benchmarks and there is a couple of videos by George Castro on how he uses on Fedoro Silver Blue and how he manages to integrate it with his own workflow thank you very much and yeah this was the distrobox we have 8 minutes for the questions so if you have questions I'm here sure there is a microphone here two questions first one do you have GPU support can you fully use for example NVR card yeah so the hardware is passed through the container obviously you have to install the drivers inside the container generally speaking for now I still don't install the Mesa drivers I was thinking of it so even the guys of Fedora Toolbox just today they pushed an update where they installed the basic open source drivers which is a really good idea and I want to implement it also which is a bit more difficult on my side because I need to have compatibility on all the range of distros so I mainly check what's the package name for the invidia part if you have drivers on the host and inside you can use that I have there is a matrix channel of distrobox and a telegram channel and some of the user have invidia cards and they use it inside the container because they install steam inside the container and they play from inside the container so it works and second question you told about removable usb devices can you add an usb device while the container is running? it's transparent when you plug it it pops generally speaking it's just mounting all slash dev inside the container so if something pops out in dev you see it in the container it's not a problem thank you any other questions? any questions from online? ok, I can close them thank you very much