8 ms·

Canonical LXD forked by former project leader stgraber

130 points by loloquwowndueo 3y ago

wingmanjd 3y ago
Does anyone know how the latest changes/fork affect downstream software like Proxmox, or is it too soon to tell?
- aaronius 3y ago
  Proxmox VE is using LXC for the containers directly. But no LXD.
rlpb 3y 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.
- catchnear4321 3y 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…
  - BossingAround 3y 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.
    - byteknight 3y ago
      Tell me you don't read everything without telling me you don't read everything. That doesn't answer why he would clone a fork of his project and not just contribute to the main project
      - Timon3 3y ago
        Because the project got taken over by Canonical. The README states why it was forked, and contributing to a community-led version of a project swallowed by a commercial entity makes a lot of sense to me.
        catchnear4321 3y ago
        what’s interesting is just that, the big name is contributing. not leading. at least not officially. at least not yet. this is a signal, an unusual one worthy of hn.
      - birdyrooster 3y ago
        Because they don’t want their repo cluttered with PR branches. It’s maybe not obvious, but in a public project anyone could branch and submit a PR which leads to a mess. This is how it’s done in many large companies as well, not just OSS. It saves you from scratching your head wondering if deleting this year old feature branch is actually throwing good work out. The news is that this person is working on the project, this clone is evidence of that.
    - catchnear4321 3y ago
      [flagged]
      - 3y ago
- rmu09 3y ago
  stgraber made a bunch of commits on this fork already.
- justinclift 3y ago
  > It looks like it was actually forked by someone on GitHub with the username cyphar Interestingly, cyphar appears to be a SUSE employee.
  - cyphar 3y ago
    That does indeed appear to be the case. :P
    - justinclift 3y ago
      Does that mean SUSE will likely be using your fork from here on? :)
      - cyphar 3y ago
        We don't ship LXD in SLES, I'm the package maintainer for LXD on openSUSE (though this does mean you get access to it in SLES through the PackageHub). I am not yet sure how I want to tackle the migration issue, and obviously I have my hands full with other things at the moment :D. 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).
- rlpb 3y ago
  Having said that, there are a pile of issues at https://github.com/cyphar/incus/issues https://github.com/cyphar/incus/issues that all look like high level project-type decisions that are filed by stgraber.
zoobab 3y ago
Let's hope it will get to docker 'oneliner' level. Last time I tried LXD it was not at that level.
- doubled112 3y 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.
  - happymellon 3y 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.
    - whyagaintango 3y ago
      Lets say one has a debian server with 256 cores and 100 users. If an user wants to run fedora it makes it possible. Not just build and run once but keep running for 365days and in that fedora give 200 user accounts or 200 webservers. It is possible with lxd. I know some hosting companies use it. Mix and match. All these run as non root. You can do ram/cpu/bandwidth/io controls everywhere.
      - happymellon 3y ago
        I already run all my containers as "non-root", I can run 200 Fedora images and I can do ram/CPU/bandwidth. 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.
    - cduzz 3y ago
      Docker and OCI containers with the layers and such are (in my experience) best used as a way to make any environment into a "static binary" in that you're pickling all the dependencies into a single artifact; the storage layers and network port stuff allow for abstraction. 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.
catchnear4321 3y ago
> i make this nice thing > then a company stole it > i fork this nice thing
- elderbarry 3y 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 3y 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 3y 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.
  - horsawlarway 3y 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.
BossingAround 3y 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 3y 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 3y ago
https://github.com/cyphar/incus/issues https://github.com/cyphar/incus/issues has a nice list of planned cleanups the fork will have compared to lxd
gbraad 3y ago
... And now ask Suse for a million dollars to keep it open. #sarcasm
stgraber 3y 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/ 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 3y ago
  Aleksa, and you are a powerhouse. Hope y'all do great things.
- leetnewb 3y ago
  Do you have thoughts on how to foster more community contribution to the fork than the canonical project got over time?
  - stgraber 3y 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.
    - akagusu 3y ago
      I think it would be nice to have Incus under the Linux Containers org.
      - cyphar 3y ago
        Ask and you shall receive ;) https://linuxcontainers.org/incus/ https://linuxcontainers.org/incus/
dsp_person 3y 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 3y 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.

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

aaronius 3y ago
Proxmox VE is using LXC for the containers directly. But no LXD.

rlpb 3y 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.

catchnear4321 3y 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…
- BossingAround 3y 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.
  - byteknight 3y ago
    Tell me you don't read everything without telling me you don't read everything. That doesn't answer why he would clone a fork of his project and not just contribute to the main project
    - Timon3 3y ago
      Because the project got taken over by Canonical. The README states why it was forked, and contributing to a community-led version of a project swallowed by a commercial entity makes a lot of sense to me.
      - catchnear4321 3y ago
        what’s interesting is just that, the big name is contributing. not leading. at least not officially. at least not yet. this is a signal, an unusual one worthy of hn.
    - birdyrooster 3y ago
      Because they don’t want their repo cluttered with PR branches. It’s maybe not obvious, but in a public project anyone could branch and submit a PR which leads to a mess. This is how it’s done in many large companies as well, not just OSS. It saves you from scratching your head wondering if deleting this year old feature branch is actually throwing good work out. The news is that this person is working on the project, this clone is evidence of that.
  - catchnear4321 3y ago
    [flagged]
    - 3y ago
rmu09 3y ago
stgraber made a bunch of commits on this fork already.
justinclift 3y ago
> It looks like it was actually forked by someone on GitHub with the username cyphar Interestingly, cyphar appears to be a SUSE employee.
- cyphar 3y ago
  That does indeed appear to be the case. :P
  - justinclift 3y ago
    Does that mean SUSE will likely be using your fork from here on? :)
    - cyphar 3y ago
      We don't ship LXD in SLES, I'm the package maintainer for LXD on openSUSE (though this does mean you get access to it in SLES through the PackageHub). I am not yet sure how I want to tackle the migration issue, and obviously I have my hands full with other things at the moment :D. 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).
rlpb 3y ago
Having said that, there are a pile of issues at https://github.com/cyphar/incus/issues https://github.com/cyphar/incus/issues that all look like high level project-type decisions that are filed by stgraber.

zoobab 3y ago

Let's hope it will get to docker 'oneliner' level. Last time I tried LXD it was not at that level.

doubled112 3y 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.
- happymellon 3y 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.
  - whyagaintango 3y ago
    Lets say one has a debian server with 256 cores and 100 users. If an user wants to run fedora it makes it possible. Not just build and run once but keep running for 365days and in that fedora give 200 user accounts or 200 webservers. It is possible with lxd. I know some hosting companies use it. Mix and match. All these run as non root. You can do ram/cpu/bandwidth/io controls everywhere.
    - happymellon 3y ago
      I already run all my containers as "non-root", I can run 200 Fedora images and I can do ram/CPU/bandwidth. 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.
  - cduzz 3y ago
    Docker and OCI containers with the layers and such are (in my experience) best used as a way to make any environment into a "static binary" in that you're pickling all the dependencies into a single artifact; the storage layers and network port stuff allow for abstraction. 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.

catchnear4321 3y ago

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

elderbarry 3y 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 3y 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 3y 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.
- horsawlarway 3y 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.

BossingAround 3y 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 3y 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 3y ago

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

gbraad 3y ago

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

stgraber 3y 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/ 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 3y ago
Aleksa, and you are a powerhouse. Hope y'all do great things.
leetnewb 3y ago
Do you have thoughts on how to foster more community contribution to the fork than the canonical project got over time?
- stgraber 3y 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.
  - akagusu 3y ago
    I think it would be nice to have Incus under the Linux Containers org.
    - cyphar 3y ago
      Ask and you shall receive ;) https://linuxcontainers.org/incus/ https://linuxcontainers.org/incus/

dsp_person 3y 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 3y 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.