Hacker News Reader

Comment by OnAndOnAndOn | Hacker News Reader

What has constantly bothered me about LXD is how heavily tied it is to Ubuntu. With Docker, you do not need to worry about moving to another major distro like Fedora, CentOS, Debian, etc. - it's officially supported and readily available. The LXD answer to this is "snaps", which are a whole extra packaging system and yet another Ubuntu technology you have to invest in - making you start to wonder if you're swallowing a spider to catch a fly.

What then increases my concern is that the two other major technology pushes Ubuntu has made into the wider ecosystem - Upstart and Mir - have both failed to take off.

Adopting a niche technology - especially for something as fundamental as a hypervisor - is already a hard choice. The LXD team is making adoption even harder by not offering official repos for the major distros.

View on HN

As a user you should be unaffected by the packaging of software as long as it works.

A Linux distribution can repackage LXD in their native packaging format and some distributions are doing it already (Debian, Alpine, Fedora, etc). If you are familiar with packaging, you can help promote those packages to the official repositories.

Debian: https://wiki.debian.org/LXD

Fedora: https://copr.fedorainfracloud.org/coprs/ganto/lxd/

Alpine: https://git.alpinelinux.org/cgit/aports/tree/testing/lxd?h=m...

As a user, you should be unaffected, in an ideal world. However that is not the case. You should always be concerned about the security of your supply chain, and should always be pulling packages from official sources only (official by the standards of the distro and/or developers you trust).

LXD is available as a package on many distributions. While they do recommend snaps (because they can push you updates faster than the distribution), that's not the only way of getting it.

Also, while the main development team are Canonical employees, LXC existed long before the lead developer was hired by Canonical -- and predates many projects. It's not going to be going away soon -- I'd bet that the development team would just move to a different employer if Canonical wanted to stop supporting its development.

Indeed, as an upstream project, maintaining packages in several distributions is extremely time consuming and near impossible when like us, you're doing monthly releases.

We welcome distributions packaging LXD directly themselves and tend to recommend that they stick to the LTS releases for that as they move at a much more manageable pace.

As noted, there are native packages for several distros out there, I'm currently aware of Fedora, Alpine, Arch and Gentoo.

The snap, makes us, the upstream, able to easily build and test a package that will work identically on many popular Linux distributions and releases. This also makes it possible for us to release fixes and new releases at the exact same time to everyone and be able to very easily reproduce any issue that gets reported to us.

We have CI in place for a lot of distributions that can use the snap package and do not let anything reach users until it's green on all of them: https://jenkins.linuxcontainers.org/job/lxd-test-snap-latest...

Docker will not be officially supported in RHEL 8, fwiw.

LXD offers snaps, which work on a wide variety of distributions. As somebody who has packaged LXD for Void Linux, I can tell you it is not a simple piece of software to package. It requires a patched version of SQLite, for example.

Reply on news.ycombinator.com