Behold, Incus: Check out this fork of Canonical's LXD 'containervisor'
Lead dev Graber quits Ubuntu maker, helps out this new project
SUSE developer Aleksa Sarai has created Incus, a fork of Canonical's LXD code, with the backing of the now-former lead developer of the container-manager-cum-hypervisor.
A month ago, Canonical announced LXD would not be independent any more, and the Ubuntu maker was withdrawing it from the Linux Containers project and taking development in-house.
Soon afterward at least one potential reason for Canonical's move became public: the former lead engineer of LXD, Stéphane Graber, declared that he had left the Linux distro developer. He stated he planned to continue contributing to the project and will be working under the handle Zabbly:
I will definitely remain an active user of LXD and will likely still be filing issues and the occasional fix. However, I don't intend to ever sign Canonical's CLA, so should that become a barrier to contribution for the project, I will have to stop contributing to it.
Well, presumably, it did become a barrier, because now two new forks of LXD have appeared. One is Graber's own fork of Incus, and he was quick to point out was made to help with the development of Sarai's project.
So now we have Incus, forked from the upstream LXD codebase by Sarai, known online as Cyphar. There's already a list of a dozen issues with the new fork – notably, all created by Graber. These revolve around removing dependencies and hooks into other Canonical tools and technologies.
The ensuing discussion on Hacker News contains some interesting information. Graber himself said:
The majority of LXD users are actually on ChromeOS, which is Gentoo-based and uses a LXD ebuild package.
While he was still at Canonical, Graber described how to use LXD on ChromeOS, and others have gone into considerably more detail about how it works, as well as how to run other distros than the default Debian.
Canonical staff have previously stated that "the LXD snap produced by the LXD team is the preferred way to consume LXD."
Graber, however, continued, saying:
LXD however does need some special code to handle being run as a snap, that part can become a bit annoying to account for and test at times.
Although these have reportedly been fixed in more recent releases of LXD, as recently as last year, users reported problems around running Snap inside LXD containers, describing the workarounds as being "as hacky as anything."
Given the controversy surrounding Snap packaging, it is understandable that some people interested in trying LXD are not keen on using the Snap version.
- Canonical takes its LXD 'containervisor' back into the house
- FreeBSD comes to Amazon's lightweight hypervisor
- Red Hat releases RHEL 9.2 to customers, with buffet of rebuilds for the rest of us
Ubuntu founder and "self-appointed benevolent dictator for life", or SABDFL, Mark Shuttleworth has also commented in this discussion, stressing that:
We have no plans to drop support for any other distro. I like that open source serves more users and use cases than its creators imagined :) We've moved our development to the Canonical GitHub repos because that's the only way we can continue to set the policy for the project, but we have not lost interest in LXD, nor are we forking it (we're the upstream), nor are we opposed to contributions that enable other distros that we haven't got to.
Graber pointed out that natively-packaged versions of LXD are included in other distributions – as, to be fair, does LXD's documentation.
However, if that tick-list of removing integration with other Ubuntu functionality is any indication, this increased distance from Ubuntu could in time prove to be a significant differentiator for Incus – as well as boost its popularity. ®
Biting the hand that feeds IT
