Canonical LXD forked by former project leader stgraber

https://github.com/stgraber/incus

by loloquwowndueo • 3 years ago

130 63 3 years ago

github.com

wingmanjd• 3 years ago

Does anyone know how the latest changes/fork affect downstream software like Proxmox, or is it too soon to tell?

aaronius• 3 years ago

Proxmox VE is using LXC for the containers directly. But no LXD.

rlpb2• 3 years ago

It looks like it was actually forked by someone on GitHub with the username cyphar, and stgraber merely has a clone on his GitHub account, which of course is common for anyone who contributes to any project.

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.

catchnear43213• 3 years ago

having a “clone of a fork of what you originally made” is almost more interesting.

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…

BossingAround4• 3 years ago

Tell me you don't contribute to OSS without telling me you don't contribute to OSS :))

Clone of a fork is necessary to open PRs when you don't have the permission to contribute to the main repository.

rmu09• 3 years ago

stgraber made a bunch of commits on this fork already.

justinclift2• 3 years ago

It looks like it was actually forked by someone on GitHub with the username cyphar

Interestingly, cyphar appears to be a SUSE employee.

cyphar4• 3 years ago

That does indeed appear to be the case. :P

rlpb2• 3 years ago

Having said that, there are a pile of issues at https://github.com/cyphar/incus/issues that all look like high level project-type decisions that are filed by stgraber.

zoobab• 3 years ago

Let's hope it will get to docker 'oneliner' level.

Last time I tried LXD it was not at that level.

doubled112• 3 years ago

I'm not sure what is meant by oneliner level here.

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.

happymellon3• 3 years ago

Considering I can run Docker containers, log in, install software manually and then snapshot the images, I'm not sure what I get from this other than a terrible sounding workflow.

martinmunk2• 3 years ago

I've been a big advocate for LXD. Running multiple servers at work where I set up containers that I gave collegues access to and such. I find that the "VM's but not" approach quite nice.

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.

BossingAround4• 3 years ago

Running multiple servers at work where I set up containers that I gave collegues access to and such. I find that the "VM's but not" approach quite nice.

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?

catchnear43213• 3 years ago

i make this nice thing
then a company stole it
i fork this nice thing

elderbarry• 3 years ago

Wait, stop. LXD was conceived at Canonical, and not by anyone driving this fork.

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.

mikece• 3 years ago

"The main aim of this fork is to provide once again a real community project where everyone's contributions are welcome and no one single commercial entity is in charge of the project."

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.

freedomben• 3 years ago

This comment touches on something I've noticed in our community over the last few years that is greatly accelarating. It's not without reason either as the corporate belt-tightening brought on by covid and high interest rates has led to corps making decisions that aren't in the users' interests. But swinging the pendulum all the way to the side of "only community stuff, no corporate" is not a good solution. It makes a whole lot more sense to just judge the project and the commercial entity by its merits: is it actually doing harm to the project? if they're being good stewards, I see no reason not to support (and even praise) them for their open source work.

horsawlarway2• 3 years ago

Eh - the world is never black and white, just shades of gray.

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.

Timon32• 3 years ago

I'm not sure I agree. Any project run by a commercial entity can be broken beyond recognition by said entity trying to squeeze out every ounce of money. This danger is not present with a community-led version. Sure, development might slow down or stop, but the same will happen once the commercial entity loses interest.

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?

horsawlarway2• 3 years ago

My take, given the optics of the change:

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.

markshuttle3• 3 years ago

That speculation is simply incorrect. We've never had a discussion about dropping support for other distros. Open source is better when more people use it, and that means its better to have it used on other distros.

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.

mkj• 3 years ago

Canonical only having snap releases was harmful to adoption. I liked using lxd, but uninstalled snapd (forgetting lxd used it), and my vms obviously stopped. Snap wouldn't reinstall properly (various inscrutable errors), so I moved it all over to libvirt. I'd still be happily using lxd if it weren't for Canonical's snap-pushing. That's my anecdote of one.

arbitrage• 3 years ago

> I [...] uninstalled snapd (forgetting lxd used it)

Okay, but that's a "you" problem, not anything related to the actual software.

BossingAround4• 3 years ago

"The main aim of this fork is to provide once again a real community project where everyone's contributions are welcome and no one single commercial entity is in charge of the project."

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?

BossingAround4• 3 years ago

TL;DR: Someone made a fork on their personal account and former project lead forked that.

Is it me or are we reading way too much into it?

goku12• 3 years ago

The fork seems to be a hard fork with a new name and diverging priorities from the original. I think the attention is warranted.

0x006A• 3 years ago

https://github.com/cyphar/incus/issues has a nice list of planned cleanups the fork will have compared to lxd

gbraad• 3 years ago

... And now ask Suse for a million dollars to keep it open. #sarcasm

stgraber4• 3 years ago

As mentioned, this isn't my fork, it's a fork made by Aleksa who's been the long time LXD packager for OpenSUSE as well as someone very involved within the container space, both userspace (runc, umoci, containerd, ...) and in the Linux kernel space.

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.

sargun• 3 years ago

Aleksa, and you are a powerhouse. Hope y'all do great things.

leetnewb2• 3 years ago

Do you have thoughts on how to foster more community contribution to the fork than the canonical project got over time?

stgraber4• 3 years ago

The LXD project had over 300 contributors over the years which while not up to par with insanely large projects like Kubernetes or Linux is still pretty respectable.

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.

MBCook• 3 years ago

Would you be willing to post or give a summary of that list? I’d be curious to know what you would change with more experience.

dsp_person• 3 years ago

I found on arch linux, LXD is a pretty great option for running VMs (--vm option) without root, being able to immediately execute commands or get a console, and is a good qemu-based alternative to virtual-box-focused Vagrant.

```

lxc launch ubuntu ubuntu-vm --vm -c security.secureboot=false

lxc exec ubuntu-vm -- /bin/bash

```

dizhn• 3 years ago

A few points I'd like to mention. LXD is good. It running lxc containers real easy and has a good interface. I think it's a good idea to make sure it's not deeply entengled with Snapd. A lot of people won't even try it because they've already decided they don't want snaps. Opensuse was already distributing it as traditional rpm packages. (This is pretty new. They might have had a plan to fork already when they started distributing packages) I support this initiative. Although suse seems to be spread pretty thin in terms of resources, they are (imo) trustworthy.

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.

Canonical LXD forked by former project leader stgraber

Related Stories