Hacker News Reader

Comment by nixcraft | Hacker News Reader

Interesting. I always used LXD. It supported many distros too. You can quickly spin up an LXD container that matches the desired cloud instance type. I can create EC2-like t2.micro instance on local Ubuntu/Debian and see how my app would behave on a cloud instance locally on my workstation. LXD also supports GUI apps and NVIDIA GPU acceleration. I will test this one.

View on HN

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

With support for running GUI applications, this becomes a viable solution for running apps from other distros, running an app as root when you aren't, and being able to install apps into a system that is immutable.

It is also a lot really really fast to enter that session. (It uses podman or docker rather than lxc like with LXD)

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.

LXC is another option. Less automated than LXD, but doesn't require a privileged daemon, and allows any user to create unprivileged containers.

I've been using LXC on my Chromebook; it's what Crostini uses, ChromeOS's environment for running a Linux distro in a container. It works pretty well!

this lxd approach sounds cool -- do you have a blog post or youtube video showing it or one that you would offer as a goto?

Yes, please see "How To Install LXD on Debian 11 Linux" [0] and search for AWS or GUI examples. FYI, upcoming Debian 12 will install LXD via APT and you no longer need snaps.

[0] https://www.cyberciti.biz/faq/how-to-install-lxd-on-debian-1...

Thank you!

In [1] Stéphan Graber, lxd project lead, regularly demos new features.

https://www.youtube.com/@LXD https://linuxcontainers.org/lxd/introduction/

Reply on news.ycombinator.com