Hacker News Reader

Comment by mikece | Hacker News Reader

"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.

View on HN

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.

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.

Is that why you commercialised ksplice?

Ksplice was never owned by Ubuntu...

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.

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

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

FWIW I am very surprised to hear that lxd depends on snapd. There are surely lxd users that predate that dependency.

It doesn't. The LXD team does make and support the snap, but LXD itself doesn't depend on it at all.

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.

Does Google participate in LXD development/maintainership? Or does it just happen to fit perfectly for their uses?

What does it even use LXD for? I thought Crostini was crosvm?

It is used for Crostini. Specifically, ChromeOS uses corssvm to run a virtual machine in which it runs LXD and then creates containers inside of that VM through it.

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.

Can you elaborate on how the manner in which software is distributed has nothing to do with the software?

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.

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.

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.

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?

It's quite right that commercial entities tend to focus on commercial imperatives. But Canonical is unusual - I founded it precisely to support a more open approach to open source than I was seeing from the other enterprise Linuxes in the early 2000's. We have a nearly 20 year track record of balancing community and company interests in Canonical and Ubuntu, in part because I have sufficient control of the company to stay true to that original vision.

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 :)

> "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?

Reply on news.ycombinator.com