Live data from Hacker News

LXD is now under Canonical

linuxcontainers.org

81–90 of 224 posts

Re: LXD is now under Canonical

#81
post #46
post #28

Earlier quoted context omitted.

Yeah I'm setting up a Debian 12 Bookworm machine right now after ~13 years of being an Ubuntu user So far it's very snappy! My Ubuntu 18.04 machine somehow "rotted" in ways that previous installs didn't -- everything became slow and janky, sorta like Windows And I specifically installed 18.04 in 2021, to avoid Snaps But now it looks like Debian will work great

As a stepping stone out of Ubuntu, Pop_OS! has been pleasant and snap-free.

The thought of people going to Pop to escape snap has me crackling.

Re: LXD is now under Canonical

#82
post #4
post #3

"the team behind Linux Containers regrets that decision"

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

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

Re: LXD is now under Canonical

#83

Stéphane Graber's work is fantastic and LXD had a lot of potential. But Canonical managed to drive me away from it with that abomination called Snap and its auto updates that could bring down a cluster without warning.

Yeah, snaps can go to hell. In addition to what you already mentioned, they are extremely complicated to debug when things go wrong.

The left column of my Ubuntu machine is filling up with useless directory icons from pseudo file systems that contain Canonical's "snaps".

Re: LXD is now under Canonical

#84
post #80

Earlier quoted context omitted.

Where are you pulling these definitions/differences from?

https://ubuntu.com/blog/what-are-linux-containers I have used both lxd and podman.

In this context, would Kubernetes be an orchestrator for application containers or system containers? Or both?

Re: LXD is now under Canonical

#85

Earlier quoted context omitted.

Me too. Turns out alpine is better for server vms for my use case and cachyos is better for desktop for my use case as wrll (at least possibly until i figure out nixos)

Do you use alpine for the host os as well as the vms? Been concerned that musl would prove a handicap. Also, can confirm void is amazing on the desktop.

I would expect musl to be less of a problem for the host than guests, though, since a VM/container host only needs to run packaged software from the distro's official repos (mostly libvirt/docker, probably). What problem would you expect to hit?

Re: LXD is now under Canonical

#86
post #52
post #41

Earlier quoted context omitted.

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

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 insi…

How can I run podman inside LXD? Last time I tried exactly that didn't work.

Re: LXD is now under Canonical

#88
Ubuntu is already the major contributor to LXD. What's peoples aversion to snaps in the thread? For me it makes for a stable system that allows me to run the latest version of apps in a confined space, it's actually perfect

Re: LXD is now under Canonical

#89
post #84
post #80

Earlier quoted context omitted.

https://ubuntu.com/blog/what-are-linux-containers I have used both lxd and podman.

In this context, would Kubernetes be an orchestrator for application containers or system containers? Or both?

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.

Re: LXD is now under Canonical

#90
post #76

Earlier quoted context omitted.

> 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…

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.

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...

Post reply on HN