Usually you would have a desktop system and run most of your very common desktop applications from within the desktop. For example, it makes sense to run your browser and office suite from your desktop.
Some other desktop applications can be run from within a container, or a VM. You would decide that case-by-case. Note that you can run either a application in a container or a new desktop. The former is easier and more common.
Steam. This one makes sense to run in a container (not VM for performance reasons). When installing, it adds all sort of i386 packages and you would rather not want to pollute your desktop system. I used to run Steam in a container but havenât tested it recently. They change things in Steam often, therefore you may need to perform some debugging.
Multiple apps that normally support a single account. Example: Viber. You can run a single account in an instance of Viber. By putting Viber in containers, you can have multiple accounts on your desktop system.
Testing desktop software. You create expendable GUI containers, install the desktop software, try, and decide whether to keep or incus delete --force gui15.
You could run a completely headless system, and then use incus console on a laptop (say) to access it remotely - or even the incus web interface.
If you want to do this on a single machine, then I think the âbaseâ OS has to be a desktop, and then from within that you can use the incus client to connect to the desktops of incus VMs - which is similar to what you get with Virtualbox.
Note that containers donât support console --type=vga. Graphical desktops would only be available from VMs, unless you create a container with say a VNC Xserver and connect to that.
Or were you thinking of trying to run a single desktop container, and pass all the graphics hardware directly through to it? That sounds very tricky. I also canât see how youâd share the keyboard and mouse with the base OS (although I guess you could connect a second keyboard and mouse, and pass those though).
If the idea is for security - running different isolated desktops alongside each other - then youâre essentially trying to reimplement Qubes-OS, and you might be better off using that instead.
Thanks to @simos tutorials, I was able to get IBM Notes application to run as different users concurrently which I need for legacy infrastructure⌠it too is 32-bit and is a pain to get working on 64-bit so very happy with it in a container. in the screenshot, they are like normal apps and the desktop UI you see is my actual desktop, not the one in the container.
Thanks, I still plan to run entire operating systems.
Awesome, that sounds exactly as what I want to do. Thanks
I generally like to:
Have one, headless NixOS. Then run at least one KaOS, so a completely normal Linux desktop system, as container on top of it. System container, in this case.
I expect it to be able to access certain files from the host system, and obviously also to use all peripherals, just as normal.
That is when I use the setup on one machine.
Host and container would run on the same device.
And when I want to access the container from outside, I should be able to do that.
I assume, this would be possible with the same setup, using a thin client to operate the desktop.
Thanks a lot, that sounds promising. Will definitely look into that.
Why? If I login to the host via incus console, and then start the container from there, why would the host need to be a desktop system?
Do I need UI, to do any of this? Is the CLI not enough?
I meant âif you want the [GUI] client and the container(s) to be on the same machineâ
If the machine where youâre running the incus client is a text-only machine, then text is all youâll be able to do (e.g. serial console access) - I suppose unless you were able to pass through a whole graphics card to one container.
I absolutely assumed I would pass the GPU - why would I not do that?
That is supposed to be easy, based on what I read in the documentation.
The GUI profile from above also contains this, thankfully.
The GUI profile assumes you have a regular graphical desktop on the host. It allows applications inside containers to access the hostâs Wayland and xWayland / X11 sockets.