11 ms·

LXD is really great software. The majority of the contributions already come from canonical, so I doubt this will make much difference in the trajectory of the

LXD is really great software. The majority of the contributions already come from canonical, so I doubt this will make much difference in the trajectory of the project. I will say that I prefer running LXD on NixOS hosts where it isn't packaged as a snap. Hopefully canonical doesn't somehow break that.

v3ss0n 3y ago
Arch have it packaged as nonsnap too
- jamesponddotco 3y ago
  And openSUSE.
SkyMarshal 3y ago
> I will say that I prefer running LXD on NixOS hosts where it isn't packaged as a snap. Hopefully canonical doesn't somehow break that. Same, though it seems this acquisition is mainly about snaps, so we'll see. I wish Nix would package Kata, a hybrid of containers and VMs. I would migrate to that from LXD. https://katacontainers.io/ https://katacontainers.io/ It does have Firecracker and Ignite though, which I haven't tested but probably also suffice. https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/ https://github.com/weaveworks/ignite https://github.com/weaveworks/ignite
micahcc 3y ago
Why LXD over podman? I've found podman to be a pretty great docker lite.
- goku12 3y ago
  LXD isn't an alternative to podman. Podman is meant to run 'application containers', where each container has just one running process. LXD is meant to run 'system containers' where each container is a full Linux distribution with an init system and (possibly) multiple daemons. LXD containers are like light-weight VMs. Unlike VMs, LXD containers share the host kernel. You could run podman or other OCI containers inside LXD. I use LXD to test multi node K8s (K3s) on my desktop system.
  - v3ss0n 3y ago
    I gotta try multi node k8s setup for lxd
    - goku12 3y ago
      There are a few settings to figure out before LXD containers can host K8s. It's mainly about running the LXD containers in privileged mode. I have the settings written down somewhere. I think I should publish it somewhere, considering the expressed interest in it.
      - v3ss0n 3y ago
        might be previleged , nested , and one other setting i don't remmber.
  - btreecat 3y ago
    Where are you pulling these definitions/differences from?
    - goku12 3y ago
      https://ubuntu.com/blog/what-are-linux-containers https://ubuntu.com/blog/what-are-linux-containers I have used both lxd and podman.
      - alejo 3y ago
        In this context, would Kubernetes be an orchestrator for application containers or system containers? Or both?
        goku12 3y ago
        K8s doesn't support orchestrating LXC/LXD containers as far as I know. What I did was to use LXD containers as hosts/nodes for K8s. So, it was basically application containers/pods and K8s running inside system containers. In addition, there are orchestrators which can run LXC containers (LXD is a management layer over LXC). Hashicorp Nomad is noteworthy. Added later: K8s runs OCI containers. All OCI containers I have seen are application containers. I don't know if OCI specification supports system containers.
- v3ss0n 3y ago
  LXD use case is totally different from podman, k8$ , docker. It is like building your own digital ocean , for containers (and vms) . It can be used as a container host for docker/podman containers, virtual machine manager for qemu, it is like having your own VPS to put your servers in.
- bandrami 3y ago
  There's a bit of a Turing Tarpit here because they're both ultimately just namespaces under the hood so you can with effort get them to do equivalent things. The original idea behind LXD was to build packages in a system equivalent to your real system but without spamming your dpkg database and filesystem with all the required -dev files. The idea behind Docker (which podman is a better implementation of and extension to) was to be able to have three different versions of Apache ephemerally on your system to match the versions used by three different projects today. Ultimately you can do both with either (and I generally use podman to build packages, as an example) but if you do that you aren't playing to the project's strengths. Toolbox and distrobox are sort of middle grounds that do both of them well enough to be tolerable.
- zacksiri 3y ago
  If you use LXD you don't need Podman, the main difference between LXD and Podman is LXD runs System Containers while Podman runs Application containers. One advantage of having a system container is you can use a package manager to update your applications. With Podman, you have to replace the entire container, with LXD you can just "PATCH" the container. This results in much faster upgrade / lifecycle management. You can read about this on my blog post. https://zacksiri.dev/posts/why-i-created-pakman https://zacksiri.dev/posts/why-i-created-pakman

v3ss0n 3y ago

Arch have it packaged as nonsnap too

jamesponddotco 3y ago
And openSUSE.

SkyMarshal 3y ago

> I will say that I prefer running LXD on NixOS hosts where it isn't packaged as a snap. Hopefully canonical doesn't somehow break that. Same, though it seems this acquisition is mainly about snaps, so we'll see. I wish Nix would package Kata, a hybrid of containers and VMs. I would migrate to that from LXD. https://katacontainers.io/ https://katacontainers.io/ It does have Firecracker and Ignite though, which I haven't tested but probably also suffice. https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/ https://github.com/weaveworks/ignite https://github.com/weaveworks/ignite

micahcc 3y ago

Why LXD over podman? I've found podman to be a pretty great docker lite.

goku12 3y ago
LXD isn't an alternative to podman. Podman is meant to run 'application containers', where each container has just one running process. LXD is meant to run 'system containers' where each container is a full Linux distribution with an init system and (possibly) multiple daemons. LXD containers are like light-weight VMs. Unlike VMs, LXD containers share the host kernel. You could run podman or other OCI containers inside LXD. I use LXD to test multi node K8s (K3s) on my desktop system.
- v3ss0n 3y ago
  I gotta try multi node k8s setup for lxd
  - goku12 3y ago
    There are a few settings to figure out before LXD containers can host K8s. It's mainly about running the LXD containers in privileged mode. I have the settings written down somewhere. I think I should publish it somewhere, considering the expressed interest in it.
    - v3ss0n 3y ago
      might be previleged , nested , and one other setting i don't remmber.
- btreecat 3y ago
  Where are you pulling these definitions/differences from?
  - goku12 3y ago
    https://ubuntu.com/blog/what-are-linux-containers https://ubuntu.com/blog/what-are-linux-containers I have used both lxd and podman.
    - alejo 3y ago
      In this context, would Kubernetes be an orchestrator for application containers or system containers? Or both?
      - goku12 3y ago
        K8s doesn't support orchestrating LXC/LXD containers as far as I know. What I did was to use LXD containers as hosts/nodes for K8s. So, it was basically application containers/pods and K8s running inside system containers. In addition, there are orchestrators which can run LXC containers (LXD is a management layer over LXC). Hashicorp Nomad is noteworthy. Added later: K8s runs OCI containers. All OCI containers I have seen are application containers. I don't know if OCI specification supports system containers.
v3ss0n 3y ago
LXD use case is totally different from podman, k8$ , docker. It is like building your own digital ocean , for containers (and vms) . It can be used as a container host for docker/podman containers, virtual machine manager for qemu, it is like having your own VPS to put your servers in.
bandrami 3y ago
There's a bit of a Turing Tarpit here because they're both ultimately just namespaces under the hood so you can with effort get them to do equivalent things. The original idea behind LXD was to build packages in a system equivalent to your real system but without spamming your dpkg database and filesystem with all the required -dev files. The idea behind Docker (which podman is a better implementation of and extension to) was to be able to have three different versions of Apache ephemerally on your system to match the versions used by three different projects today. Ultimately you can do both with either (and I generally use podman to build packages, as an example) but if you do that you aren't playing to the project's strengths. Toolbox and distrobox are sort of middle grounds that do both of them well enough to be tolerable.
zacksiri 3y ago
If you use LXD you don't need Podman, the main difference between LXD and Podman is LXD runs System Containers while Podman runs Application containers. One advantage of having a system container is you can use a package manager to update your applications. With Podman, you have to replace the entire container, with LXD you can just "PATCH" the container. This results in much faster upgrade / lifecycle management. You can read about this on my blog post. https://zacksiri.dev/posts/why-i-created-pakman https://zacksiri.dev/posts/why-i-created-pakman