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…
Where are you pulling these definitions/differences from?
Kind of sucks to see LXD get pulled from Linux Containers. Stéphane's (and the rest of the Linux Containers team) work has been incredible, and honestly it gets slept on way too much. LXC containers have been incredibly powerful and useful for me, though I never bothered to learn LXD. I have this bizzare intuition that Canonical is watching Red Hat, and that there's a non-zero possibility of them aping the whole pay a subscription to get the source and distro thing Red Hat is currently engaging in.
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 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
I had numerous issues with it, like the inputs would not focus in firefox-esr. Unfortunately I had to install Ubuntu 22.04 which works fine but has all sorts of annoyances like snaps and text ads in apt. Ubuntu didn't even set up grub right after I used custom partitioning to avoid nuking my /home partition, it only booted after I did a manual grub-install.
I'm not hip to all the big names in open source development, but I know Lennart Pottering and Guido van Rossum both ended up at Microsoft, so they might be able keep a few other engineers around.
Very soon Microsoft will acquire Canonical for at least $40 billion. The reasons: * Ubuntu powers the overwhelming majority of Azure workloads (both customer and internal) * Nearly all Linux applications and tooling target Ubuntu first (or at the very least) * Github, VSCode. The missing piece is the actual runtime operating system. Ubuntu. * Canonical employs nearly all the remaining core enterprise open-source deve…
> Ubuntu powers the overwhelming majority of Azure workloads I expect this to shift. Some years ago `FROM ubuntu:something` was a go-to for Dockerfiles when I wasn't feeling fancy with `FROM alpine` or `FROM busybox` (or `FROM scratch`). Today if I need a generic distro base, I'm consciously going with Debian-based images and Ubuntu is never an option anymore (it used to be "Debian, but better", it became "Debian, bu…
Ha, it's the reverse for me.
I used to use Debian base image, but now switch to Ubuntu LTS base images almost exclusively due to them offering newer versions of most core libraries, and longer support duration.
> 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.
> 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.
Very soon Microsoft will acquire Canonical for at least $40 billion. The reasons: * Ubuntu powers the overwhelming majority of Azure workloads (both customer and internal) * Nearly all Linux applications and tooling target Ubuntu first (or at the very least) * Github, VSCode. The missing piece is the actual runtime operating system. Ubuntu. * Canonical employs nearly all the remaining core enterprise open-source deve…
> Ubuntu powers the overwhelming majority of Azure workloads I expect this to shift. Some years ago `FROM ubuntu:something` was a go-to for Dockerfiles when I wasn't feeling fancy with `FROM alpine` or `FROM busybox` (or `FROM scratch`). Today if I need a generic distro base, I'm consciously going with Debian-based images and Ubuntu is never an option anymore (it used to be "Debian, but better", it became "Debian, bu…
Generally agree: these days almost all of my images are either Alpine-based, or Debian-based. For example, the upstream _/ruby and _/python images offer both of those as the only base OS (well, aside from Windows Server Core apparently?) options, which alone makes up a huge chunk of Docker uses. (this is evidently because buildpack-deps offers Debian and Alpine bases, and these images both base from that to try to share layers, neat)
> 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…
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'
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:
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.
Stéphane made snaps too ? I hate them. I strongly dislike lxd too. If he isn’t a core person behind snaps he sure advocates hard for it.
He works for Canonical so I'd imagine he had to get on board with snaps, like it or not.
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…
Where are you pulling these definitions/differences from?