LXD is a faster tool that offers various configurations, such as allowing an app to run as root even when you're not, and mounting host directories inside containers like Docker/Podman. LXD is also unprivileged by default and uses the same Linux kernel features as other tools. We have different tools available for end users, and I prefer running Docker inside LXD for development purposes because it keeps my $HOME clean. Additionally, tasks like Nvidia GPU (such as ffmpeg, or AI) can also be run inside LXD, providing extra security on my dev box while keeping $HOME clean where you may need to use the `curl ... | sudo bash` syntax when downloading random stuff from the Internet.

>LXD is also unprivileged by default

The last time I tried it (a few years ago) you needed to either run `lxc` as root or be a member of the `lxd` group which is equivalent to having root privileges. At that time the ability to launch and enter container instances as an unprivileged user (without a root backdoor like the docker or lxd group) was one of Podman's advantages. Have things changed since then?

LXD uses unprivileged containers (user namespace) with the setup done by the root user. All containers run in unprivileged mode by default. However, specific config that only a privileged user can do (mount disks/partitions, setup network devices, allocate more complex mappings for the user namespace etc.) on LXD using the root user or LXD group. Even rootless Podman needs root access in many cases. For example, to open port < 1024, mount EFS/NFS inside; in other edge cases, you can't use rootless Podman. These are Linux kernel limitations last I checked and are sometimes caused by various distros applying other security patches to their kernels too.

LXD supports (all of these have pros and cons, and you must choose one of the type that solves your problem):

1. Privileged containers.

2. Unprivileged containers as an unprivileged user.

3. Unprivileged containers as root.

One frustrating issue is that many developers and IT professionals are reluctant to use Podman due to certain unique situations and edge cases. Docker is more commonly used and tested, making it the preferred option despite Podman's beneficial features.

> The difference here is, your home directory is tightly integrated.

lxd supports this too, as well as configuration profiles and a default configuration profile. So the only difference is in default configuration and perhaps ease of configuration.

> The difference here is, your home directory is tightly integrated. This is something most (all) all virtualization solutions try to avoid.

This isn't really true - almost any virtualization or container solution will do this, in the case of containers it's typically just a local volume mapping. Of course the default is typically an isolated execution, that's one of the key tenets of containers or virtualization, but it's usually minimum effort to expose whatever local directory you like. I guess its nice this tool cuts out a small step to make the process convenient, but its not a must install for me personally vs my existing container runtime.

Mapping my entire home directory to a volume is a pretty rare use case for me too - i'm far more likely to just map a project directory to a working dir in the container. I don't think I have ever mapped my whole home folder to a container volume in my career, and can't imagine doing so in future either. This is a bunch of nice shell-scripting to do what you could already do with docker/podman a little quicker.

> This is a bunch of nice shell-scripting to do what you could already do with docker/podman a little quicker.

This is absoulutely what it is. The project does not try to hide this fact nor am I.