Hacker News Reader

> The LXC team are trying to move the needle with LXD. It uses unprivileged containers by default (non root users can run containers, this is not capabilities drop) multi host management with a REST api so you can query the LXD daemon for container orchestration across hosts and live migration. These are big steps forward and they really do need the support of the community. They have been doing this for 7 years and is thanks to then containers exist.

I'm always surprised when people omit to point out that "the LXC team" is basically Canonical, the corporate sponsor behind Ubuntu (including the kernel bits).

People love to bash on the company, it'd be nice to acknowledge the achievements as well :)

Full disclaimer: I'm a Canonical employee. I hope that doesn't come out as a corporate shill, I genuinely love LXD.

I'm always surprised when people omit to point out that "the LXC team" is basically Canonical, the corporate sponsor behind Ubuntu (including the kernel bits).

Perhaps now, but historically you are very much incorrect. IBM funded it originally, and it was conceived and implemented (ie. as in they made it reach the "actually working and in-kernel" state) with the goal of segregating concurrently executing workloads on fat IBM-supplied mainframes.

They have been doing this for 7 years and is thanks to then containers exist.

Well, no, Linux containers have existed for longer, in the form of OpenVZ. I find it pretty funny that they are now considered "new" :)

Besides unprivileged containers, which I suppose can be useful for some use cases, what's the great advantage of LXD vis-a-viz OpenVZ, which is a more mature and well-understood technology?

Linux containers have existed for longer, in the form of OpenVZ.

Also Linux-vServer, yadda-yadda. Not only OpenVZ.

what's the great advantage of LXD vis-a-viz OpenVZ, which is a more mature and well-understood technology?

OpenVZ took approaches that meant it would never be accepted in to the Linux kernel. This means, frankly, that it is dying as people move to LXC, whose components are in the kernel. Claiming something is 'mature and well-understood' that is essentially destined to become a footnote in history may be correct, but it's also rather short-sighted and increasingly irrelevant.

The OpenVZ userspace already works with the same kernel components used by LXC; you can create, start and stop containers on both an OpenVZ and a regular kernel with the same commands.

The commands that don't work are those which don't have the underlying kernel feature to support them yet; as the upstream kernel gains such features, so will the OpenVZ userspace.

So there's not "short-sightedness". OpenVZ and its tooling will live beyond its kernel.

Meanwhile, LXC has already been abandoned by Docker (it's now using libcontainer by default), and others use systemd-nspawn, so what makes you think LXC isn't the short-sighted and soon-to-be irrelevant choice?

Last time I looked, and I did really look, the big picture was OpenVZ and Linux-vServer made it clear they were moving to work through cgroups and namespaces, same as LXC, and will essentially offer little delineation except edge-case features (freeze/thaw/migration/extra security stuff that breaks random programs or requires PhD's in syscall analysis/whatever). These features are questionable in many cases, and if they require custom kernels, they'll never take off as mainstream tooling, even if the projects survive.

By LXC I was referring to IBM's work in general (kernel work mostly) not just to the LXC userspace which has its issues but works mostly most of the time and is defacto standard, due to being first out the gate. Docker for all it's marketing budget can't change history, even with scores of people on its team.

I think Flockport is doing some amazing things. When I read the pagerduty bug-hunt post and saw that they were using ipsec between "hosts", I wondered if perhaps they used LXD with some of your services.