One day someone untrustworthy will be in charge of the FSF, and ‘or later’ is suddenly going to be #awkward. Linus made the right call there, for sure.
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.
They can only make these patches because large enterprises wanted them and were willing to pay for them, and they have found a nice way to make the patches available free to you and me. If they made them free for large enterprises too, that funding would go away and we would all lose them.
Also, the extra security work on universe means there are more people who can handle the main repo even better. So even non-Pro users have benefitted.
You get a free personal subscription which can be used on up to 5 machines that you personally own.
Canonical are letting home users, community, power users and small businesses benefit free of charge from the extra security work that much larger enterprise customers had asked for, and funded. If Canonical made it free for the large enterprises, they would stop funding it and we would all lose the best and broadest security coverage in the market. Also, the Canonical security team has grown a lot to do this work, so the security coverage of Ubuntu ‘main’ which has always been there is now even better.
So this is pure win for you, me, and everybody else on Ubuntu too.
If you don’t change anything, you get more free security fixes in Ubuntu than any other Linux you could pay for, for 5 years, and that keeps improving as more big companies use Ubuntu Pro. With a free subscription you get personal / small biz coverage that’s miles better than any other enterprise offering. And if you are a large business, Ubuntu Pro is an incredibly cost-effective way to get full coverage and things like FIPS and FedRAMP coverage while letting your developers use any of the tens of thousands of Ubuntu packages. It’s 3-4% of the cost of the cloud VM, a total no-brainier for any CISO.
There is a reason the fast-moving companies are building new stuff on Ubuntu.
Several commenters here say they have fewer bugs with MicroK8s, makes sense since it’s less of a modification than k3s. Slightly bigger since it keeps api and worker processes as separate binaries albeit in a single package.
The new format does seem much nicer to my eyes but I suppose tastes vary. A pain to have to change but it looks like good work and a new release is usually required some pressed Hackett anyway.
It’s easy enough to configure motd to pull your own notices for a company, and useful too. Nothing there seems particularly weird to me in this day and age, and Ubuntu has a much better track record of actual security maintenance over the long term.
The database in question, dqlite, is raft-around-sqlite, and that’s just about the most widely used sql database anywhere, albeit pretty thin. Recovering files on disk won’t be an issue with dqlite. It would be interesting to see a jepsen analysis of dqlite to assess resilience in the face of trouble.
K8s is sophisticated software that offers a wide range of options because people want to use it in a wide range of scenarios. But you probably don’t need most of those options. Start with something like microk8s which is on rails, add knobs only if you need them.
Snaps with a reasonable rationale for it can be unconfined (they require the user to acknowledge that with —classic on install). Think a config management system, which needs to be able to read and write all over a traditional file system. That would work for you, and be cross platform, but the snapcraft community would need to be convinced that it’s not a Trojan horse vector.