Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sorry what? Lxd is NOT incus upstream. Incus was forked from lxd specifically to allow divergence and the licenses mean changes rather flow in the other direction. Not that canonical considers incus “upstream” - they’re just divergent forks at this point.


But unfortunately it pretty much is, at least according to the maintainers themselves.

They try to not diverge unless "necessary", and for most parts it's not necessary to them.


I forked Incus from LXD, and I would not describe LXD as Incus's upstream at all. In fact LXD, tends to take patches from Incus these days -- on the other hand, we can't take patches or even look at patches from LXD because they're all AGPLv3 now.

Most of the maintainers and contributors to LXD have moved to maintaining and contributing to Incus instead because it is community-oriented. Incus also has a lot of features LXD doesn't have (list is too long to enumerate, but one notable one is support for OCI images is Incus-exclusive).

Stephane was arguably the primary maintainer of LXD before the split and how now exclusively works on Incus. AFAIK the only LXD-related thing that is still shipped by Zabbly is the LXD web-ui (which I get the impression Stephane doesn't feel is worth maintaining separately since it's easy to just swap out the branding -- which is what he does). Ultimately an optional web-ui is not a particularly large part of the project...

(To be honest, I only learned about the web-ui when someone asked I package it for openSUSE a few months ago. Maybe I would've forked it too back when I forked Incus if I knew about it, though I'm not a web dev.)


Can you substantiate this?

The only time this held, vaguely to my recollection, true was prior to Incus 0.4 where both were cherry picking from each other but neither were upstream of each other


https://github.com/zabbly/incus/issues/89#issuecomment-30764...

I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending.

But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects.

And I swear I had a similar experience with regards to some other incus issues where there was a similar response about changes.


It's very very different between the UI and Incus itself :)

The Incus teams are low level system engineers who develop in Go or C. The UI is a pile of typescript which none of us really want to understand/touch any more than strictly needed.

The Incus UI is a soft fork (really just a small overlay) on top of the LXD UI to adjust for the API differences between LXD and Incus and for fixing the few big gripes we had with the LXD UI. Because both projects are under the same license, we can actually just follow what happen in LXD UI and pull in code from it.

Incus is a very different beast. The whole reason the project had to be started is because of Canonical's series of changes which eventually led to a re-licensing of LXD to AGPLv3. With Incus remaining Apache 2.0, none of us can even look at the LXD code without risking being "tainted". We cannot import any code from LXD since that license change and we never have. However LXD has no problem with importing Apache 2.0 code into an AGPLv3 codebase, which they have quite actively been doing.

In short Incus is a hard fork of LXD, we don't look at any LXD code or even at their issues or release announcements (mostly because it's not useful for those two). That means that everything that happened in Incus since December 2023 has been completely independent of LXD.

The Incus UI is a soft fork of the LXD UI, it's rebased every time they push a new version out and our goal is to keep the delta as small as possible as it's something we want to spend as little time on as we possibly can. It's also why we always package it as "incus-ui-canonical" to make it very clear as to what it is.

There are also other UIs out there that could be used, sadly last I checked none came close to the feature coverage of the LXD UI or they had dependency on external components (database, active web servers, ...) whereas what we want is a UI that's just a static javascript bundle which then hits our REST API like any other client.


> https://github.com/zabbly/incus/issues/89#issuecomment-30764...

> I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending.

This one is fair since Incus and Zabbly have had no desire to reimplement a web UI, they've instead opted to leave that to the community resulting in LXConsole for example.

Zabbly, for additional context, is Stephane Graber's company that he set up as a consultant service for Linux and Linux Container (both in terms of the Linux Container organization and the LXC project)

As a whole, the project has left the choice of web interface up to the user: https://discuss.linuxcontainers.org/t/incus-6-7-has-been-rel...

> But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects.

This is getting dangerously close to a mischaracterization of events surrounding the Linux Containers and Canonical split.

See: https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-unde... in addition to: https://linuxcontainers.org/incus/announcement/

EDIT: I read this part to suggest that former LXD team members that are now on the Incus team potentially have the same mindset, if this is wrong, please correct me.

> And I swear I had a similar experience with regards to some other incus issues where there was a similar response about changes.

So far from my two years of interaction (both as a lurker and commenter) on the forums and purveyor on the issue tracker, I've yet to see anything that resembles treating Canonical LXD as any form of upstream especially since the split.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: