[veidr]

Woah I notice that the signatures on that include Stéphane Graber.

It's rather hard to imagine LXD continuing as a going concern without him. Does this mean he regrets the decision, but is going to keep working on LXD, or... does this mean LXD is fucked?

-- concerned LXD user

[botanical]

Canonical already has the most number of commits in the LXD repo, so I doubt much changes.

[re-thc]

> does this mean LXD is fucked

It is either way. Docker / kubernetes is eating it up. There aren't as many LXD users as they'd hope.

Oh and he does work for Canonical.

[MrPowerGamerBR]

> Docker / kubernetes is eating it up

Is LXD's purpose the same as Docker/Kubernetes? I use both LXD and Docker and to me they are tools that use the same technology (containerzation) but for different purposes. Docker is for stateless containers, used to containerize services. LXD is for stateful containers, used to containerize operating systems. LXD can also run VMs while Docker can't.

I think about LXD as a sort of Proxmox alternative (because you can manage LXC containers and VMs with it) instead of a Docker/Kubernetes alternative. In fact, I actually have migrated my systems from Proxmox to Ubuntu Server with Docker, for stateless applications, and LXD, for when I need to containerize an entire OS or VMs for my friends.

[veidr]

Exactly, we migrated to LXD from Proxmox for stateful containers for various servers (DNS, Zulip, Mastodon) as well as user desktops (e.g. Ubuntu Desktop, Fedora, etc).

LXD is nice because it has a nice management layer. It is really easy to migrate an instance (container or VM) and its state from one physical machine to another on the LAN, even if you don't want to bother with setting up an actual cluster.

[MrPowerGamerBR]

I think that LXD as a Proxmox alternative is a very underrated idea to be honest.

Don't get me wrong, Proxmox is a pretty good piece of software, but if your workload isn't tailored to VMs + you have private links between your clusters + you have shared storage, you end up adding way too much complexity to your stack even tho you aren't using the real useful features that Proxmox provides.

So if you are in the "I just want to run my services" crowd, an Ubuntu Server (or any other distro, really) running Docker on baremetal + LXD for anything that can't run on Docker is way simpler to manage. Especially because running Docker on Proxmox is not fun (too cumbersome to run it within a LXC container + ZFS, running a big fat VM with Docker defeats the point since you can't backup individual containers with Proxmox anymore, and running Docker on the hypervisor is a big no-no)

At the end of the day, nothing in Proxmox has a special magic sauce that makes it tick, and sometimes that complexity may be super cumbersome when you just want to run some dang Docker containers for your swifty new app. https://mrpowergamerbr.com/us/blog/2022-11-20-proxmox-isnt-f...

[laxis96]

Please note that Docker and LXC (and LXD by extension) are essentially the same technology packaged differently, with different yet overlapping use cases; in fact, early Docker Engine was based on LXC before they switched to containerd.

Therefore I don't think there is anything that can run on LXC/LXD but not on Docker (and vice versa); it's more a matter of preference, whether you want a long-lived persistent virtual system (LXC/LXD) or ephemeral single-application containers with optional persistence (Docker).

Still, nothing stops you from using LXC/LXD for ephemeral containers and Docker for long-lived systems, but you'd be using the non-optimal tool.

[deviantintegral]

This summarizes it well. Sometimes you run into apps that don’t ship Docker containers because they expect to not be behind a reverse proxy. For example, while there are third party Docker containers for the Unifi controller, they only support using their apt repos. The controller expects to be able to send low-level discovery packets and not just HTTP. Lxd makes that really easy.

Also, from a development standpoint sometimes a long-lived container environment is easier. I run zigbee2mqtt inside of lxd because if I want to try a PR, it’s `git checkout … && npm ci` and not building a whole container each time.

For the home NAS and server case, I’ve been really happy with Ubuntu server with zfs + lxd + docker. And, a lxd VM for Home Assistant OS. Basically, the right tool for each job and no worries trying to force software into an environment their developers don’t expect.

[nine_k]

Since Linux containers are just namespace tricks, a kind of glorified chroot, what does it mean that you run VMs from within containers? Sincerely curious'

[justinclift]

https://ubuntu.com/blog/lxd-virtual-machines-an-overview

[veidr]

I don't think OP means running VM from within containers (although, who knows, I mean I guess you could). LXD provides a management layer that treats containers and VMs (libvirt/KVM/QEMU VMs) mostly the same.

So commands like this work on both containers and VMs:

   lxc start fedora-desktop
   lxc mv pi-hole other-machine:pi-hole

etc

[unixhero]

Yes they are. And they work very well and can be used in production

[re-thc]

> Is LXD's purpose the same as Docker/Kubernetes?

It did occupy the same space including Proxmox.

Back then KVM, Proxmox, VMWare, OpenVZ, LXD, etc were all ways of virtualization.

Whilst it's not exactly the same purpose most companies have or have been shifting to docker and kubernetes and in the cloud vs running their own VM infrastructure.

> Docker is for stateless containers

Tell that to people that run databases with docker and kubernetes. It is a thing and even commercial products are built that way.

[MrPowerGamerBR]

> Tell that to people that run databases with docker and kubernetes

To be honest my original message wasn't clear enough: What I wanted to mean is that I like using Docker when I have a container image ready to run, "stateless" in the meaning that the image itself is unmodifiable and any changes to the image will be lost after a restart. (This doesn't include bind mounts, and stuff like that)

[solarkraft]

Hey, I'm looking for a Proxmox alternative!

But how do I use LXD on Debian without Snap?

[radiator]

He no longer works for Canonical, it seems.

[v3ss0n]

That confusion makes lxd underrated. LXD isn't like docker or k8s. It's totally different use case.lets see this way If docker and k8s are fighter jets and bomber role , LXD is the aircraft carrier.

[rcxdude]

which is a shame, because it works a lot better if you just want lightweight VMs without 5 billion layers of stuff crammed on top.

[softirq]

The point of them owning LXD is to give them total control of the underlying technology they are using for Snaps. Snaps is the play… has nothing to do with kube/docker. It’s actually more of a synonym of ostree and flatpaks.

[psanford]

Snap is not built on top of lxd.

[justinclift]

Sounds like it might go that way though.

[rascul]

Could it be?

[type0]

Should it be?