Canonical LXD forked by former project leader stgraber
github.com
github.com
The actual fork is at: https://github.com/cyphar/incus/
I've just been helping out getting it to actually be functional and providing a bit of a laundry list of things I'd do differently should I be starting LXD from scratch now, which a fork like this now makes possible.
So achieving similar level of contributions to a fork would already be pretty nice. It's hard to predict the community reception of the fork though and whether that will lead to more contributions than has been seen in the past when the project was backed by Canonical or if there being two active codebases will result in a reduced set of contributors to both.
I'd love an actually up to date RPM compatible with the RHEL family.
For example, the README.md links to cyphar's repository, not stgraber's, and this page says it was forked from cyphar's repository.
The existence of this page merely suggests that stgraber is contributing, or intends to contribute, to the fork. Not that he forked it himself.
Perhaps he did fork it, or does intend to be involved in maintaining this fork, but I think the editorialized HN headline "forked by former project leader" is highly misleading unless there's actually something that demonstrates that stgraber is intending to run a fork, and this page isn't it.
the fork is already one hoop more than should be needed, so this adds one for an unknown reason. cloning doesn’t even indicate intent to contribute - just desire to have a copy of code for yourself. which, it’s his code, so, why…
Clone of a fork is necessary to open PRs when you don't have the permission to contribute to the main repository.
this is a signal, an unusual one worthy of hn.
Interestingly, cyphar appears to be a SUSE employee.
We will be making some cli-related changes that would make "alias lxd=inc" not work, so I suspect we will need to package incus separately and provide a mechanism to migrate. But nothing is set in stone quite yet. But once incus is ready to start being packaged, I will package it for openSUSE (and possibly come up with a multi-package setup using the Open Build Service to build and host all of the packages in one place).
Okay... but was the Single Commercial Entity actually doing anything to harm the project? Or is the assertion that the presence of Single Commercial Entities in the Linux space a bad thing? I could see forking the project and keeping pace with changes being made just in case the Single Commercial Entity did something that was not in the best interest of the open source community but to proactively fork the project seems both premature and dilutes the pool of talent contributing to the overall project.
Canonical have done most of the work for LXD (including directly employing the main developer for years). Until now, they've been doing it under an umbrella project that was specifically not Ubuntu focused (to quote linuxcontainers.org: "The goal is to offer a distro and vendor neutral environment").
Now they've moved the project directly under Ubuntu, why?
The answer to me seems to be that they still going to do development, but they will no longer try to support anything but Ubuntu (and really, my guess is it will go the route of microk8s and become snap only/first, so more of a middle ground).
And I don't really blame them for that - they're doing the work, they can focus on themselves. But it does mean there is now a need for someone to do the work to become the packager for other distros. That development has to happen somewhere else now.
That may well be this repo, it might not.
If you use commercially-led software, you have to trust the publisher to stay aligned with your interests for the entire duration of you using it. This might go okay, but it might not - and there isn't any commercial entity who won't start squeezing when they feel necessary. So why expose myself to the whims of someone who might flip at any second?
Of course, things may change at Canonical if I am no longer involved. That's a reasonable risk to think about and have a plan for. Some paranoia is constructive. One of the nice things about open source is that you can fork it if you want to. But to do so just because Canonical might in future take a different view than we have to date seems like its paying too high a price for that paranoia :)
Canonical is likely looking to bolster LXD integration within Ubuntu and drop support for other distros.
Which... is fair, in my opinion. They've done most of the maintenance and work, they are allowed to prioritize their use-cases.
But it also means there likely does need to be a fork available to make sure that wide distro support happens, and LXD doesn't become a snap store special for Ubuntu.
In the best case - They'll both cooperate nicely and canonical can focus on primary LXD development like they were, while other folks can pick up the tab for non-ubuntu packaging/testing/support.
We've always tried to be at the forefront of new kernel capabilities - especially security and container tech - and it helps that Ubuntu generally has very modern kernels. On Ubuntu we can make releases of the kernel and LXD that line up nicely. Other distros with older kernels have always been supported as well as possible, and I don't see why that would not continue. There is certainly no plan at Canonical to inhibit that.
Okay, but that's a "you" problem, not anything related to the actual software.
The majority of LXD users are actually on ChromeOS which is Gentoo based and uses a LXD ebuild package. Debian has a native .deb package too, so does ArchLinux, Alpine, OpenSUSE and a few others.
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.
What does it even use LXD for? I thought Crostini was crosvm?
Google has sent the occasional bugfix, usually for pretty complex issues (hard to hit race and the like) but weren't involved in project maintenance or even very actively talking to us. We'd usually bump into the Crostini folks at conferences once or twice a year and just talk over dinner.
Let's suppose this fork is successful and replaces the original. Wouldn't it be SUSE, another single commercial entity, who's now in charge?
Second point. It looks like lxc is also having issues with resources dedicated to it too. It's also suffering from cannnibalization from lxd. Try to search lxc stuff and what you get will be lxd and its commands rather than that of plain lxc. This might be more of a search engine thing but it's noticeable.
```
lxc launch ubuntu ubuntu-vm --vm -c security.secureboot=false
lxc exec ubuntu-vm -- /bin/bash
```
> then a company stole it
> i fork this nice thing
It was funded by Canonical, quite separately from LXC.
The tech lead asked for and got permission to host LXD alongside LXC, arguing it would attract significant contributions, which it did not. Now that tech lead has left the company. Canonical will continue their work, which is the vast majority of LXD code, in their own Github repo, just as you would for something you designed and are investing in. The company hasn’t stolen anything, don’t be drawn into the pitchforks and torches brigade.
This mob madness is why we can’t have nice things in open source. I like LXD and it’s obvious to me that its future releases depend, just as past releases, on continued investment by Canonical. Wishing otherwise is self-defeating.
Is it me or are we reading way too much into it?
Last time I tried LXD it was not at that level.
LXD is meant to run system containers in LXC. It's meant to feel like a virtual machine in the sense that you log in, install software, maintain it, etc.
A similar concept might be images from TurnKey Linux. They're at least available in Proxmox, and are prebuilt system container images, but I can't see them being very popular compared to Docker itself.
I can also put that users home on the SAN so their data is retained if the container has to move servers. I'm unclear what that has to do with being an LXD advantage.
LXC is best thought of as a way to make a VM, but each of your VMs shares a kernel and filesystem cache. Each of these "VMs" can have a unique IP address, and even a totally different userland, but is otherwise best thought of (For better or worse, depending on your needs) as a VM / computer on its own.
LXD is an orchestration mechanism to provision / manage these LXC containers -- it's like but not really like nomad or kubernetes.
For stateless things, I tend to use docker / OCI containers; for stateful things I tend to use LXC because the volume mounting abstractions in OCI containers just get in the way.
But that's me. I'm sure I'm doing it wrong in a variety of ways.
I "can" do what they are describing in OCI, but it's bad practice.
I don't do it manually.
I've since moved away completely, just before the recent moves by Canonicle. Most of if not all of my reasons to move away from LXD relate to Snap or other sides of Canonicle leadership.
Out of curiosity, why? Wouldn't it be easier to give them a URL and tell them to execute "docker run ..." to get the same environment?
Either if someone wants to run something as an internal service (logging, ect) which should not depend on their desktop being online, or they need beefy HW.