I didn’t find an immediate answer to this question and wondered about this for a long time now.
Why the decision to only publish snap packages? With deb packages I never had a problem but snap, where do I begin …
Auto updates break the systems on a regular basis
Where are the logs found again?
$HOME not in /home/$USER … (╯°□°)╯︵ ┻━┻
Not that it was my decision to change this, but if you are lucky enough to get a company supported linux env, those are the things you have to deal with.
As lxd uses a global database downgrades are not possible anyway, so no need to use multiple versions
My point is, I to use lxd and it’s a fantastic piece of work. However, snap sometimes makes it barely usable.
The metrics point really doesn’t matter, we almost never look at those, we get far better metrics from image downloads.
The rest is all correct. We welcome other packages and many distributions have very good maintainers publishing native packages for their distro. So far nobody stepped up to maintain a reliable PPA or similar deb archive for Debian/Ubuntu.
As far as upstream is concerned, packaging can take a LOT of time and we’d much rather spend our time developing LXD itself. The snap package gives us something which:
Works on many distributions and versions of those distros (biggest bang for the buck)
Can be very quickly updated (no multi-week red tape as happens for most native packages on common distributions, pretty useful when you release monthly)
Complete control of all our dependencies (makes testing and handling support requests pretty easy)
So from an upstream point of view, it’s a pretty ideal tool and allows us reaching users on distributions we’ve never even heard of without having to put a single extra minute of work on our side.
This are all valid arguments the big draw back I see is that currently the end user experience of snap is awful. I basically don’t build new things on LXD because of snap.
Let’s hope snap gets better I guess. or someone has time to package LXD for debian/ubuntu
Sure, snap makes it easy for developers to deploy and easy for users to find applications.
This convenience comes at a cost:
server side proprietary code
centralized authority
There is more, but other disadvantages are rather technical. These should be twisting your guts though. What I hear from you, is that you appreciate the convenience that snap gives you. If you follow the argumentation of convenience you’ll end up with a system that is neither free for users nor for developers.
Snap is not even open source.
Someone invented the analogy of a wild animal discovering a cage with a piece of cake inside. The cage would be snap, the cake is convenience and the wild animal is you. Chances are that you’re willingly going to hop behind the bars to enjoy the soothing rush of sugar before you notice that the cage door closes.
Anyways, enjoy your cake. I rather want to live in a world where wild animals are wild and open source software is open source.
That argument is always a bit of a weak one to me.
We rely on the snap store as a blob delivery mechanism, much like any of the very many CDNs out there.
The bits that matter:
LXD itself
Snap packaging
Snap build tooling
The tool that installs the snap
Are all open source and all build operations happen in the open.
The only bit that’s not is the part that takes that .snap squashfs we produce and distributes it so you can quickly download it on your machine.
Really doesn’t feel any different than using Github for code hosting. We produce the bits, we sign them and they’re just being distributed verbatim to others at no cost to us, effectively free specialized CDN.
Or you can build LXD yourself, or build the snap yourself or build whatever package you want yourself, all fine with us
Small update on this thread, as snap was such an unusable pain for us, I started to repackage lxd as a debian package. This is mostly ‘works on my machine’ effort but it seems more stable than the snap deployment at least for us …
to use lxd and it’s a fantastic piece of work. However, snap sometimes makes it barely usable.
or someone has time to package LXD for debian/ubuntu