Aether on Linux Mint 20

Will there eventually be a PPA for Aether since Linux Mint 20 dropped snapd?

I like Aether, but I won’t migrate away from Linux Mint.

I don’t really want to install snapd as I guess it will clutter up the Software Center as other distros’ Software Centers are. I’d like to wait until the PPA is created.

Give me a glimmer of hope that this will eventually happen, if it might.

Well, you are definitely not the first person to ask this, but most of the conversation happened within Aether, so let me reuse this thread to document it here.

  • Snap has always been a pain in the butt and was never the first choice. Our first choice was AppImage, which we had released some early versions on. Ultimately it did not work, and had quite a few issues. We also had some developers of AppImage itself try to make it work and it did not. This was about a year ago, I hope they have improved it since then, but I don’t see evidence in favour of that on the internet.

  • Our second option, Flatpak, ended up carrying most of the downsides of Snap without the upside of being available by default on most popular distros. It also is quite arcane, from what I remember trying to make it work.

  • Snap was the third and the least favoured option, but it was the only one that actually worked. So we started to ship with Snap.

Here are my problems with Snap, as a developer:

  • It is very tightly tied to an App Store model. If you noticed, in the Linux download instructions, we have to tell you to install it with the flag ‘—dangerous’. This is terrible behaviour on snap’s part, because all that flag actually implies is that the snap was downloaded outside their App Store. There is nothing dangerous or weird or otherwise uncommon about Aether compared to other snaps than the fact that it was not downloaded from the Snap store. Even Apple doesn’t do that, on Mac OS, you can install non-app-store apps just fine, without resorting to command line flags.

  • Because Aether is installed with a dangerous flag, on Linux, we can’t do version updates without specific directions to save the user’s private keys and profile, because deleting the snap also deletes those by default. The user needs to remember to move the user keys out before installing the new version and put them back in. That’s very error-prone and can cause key loss.

  • Because of Snap, on Linux, you can’t open aether:// links because Snap’s deep linking support has been broken since forever. They only just fixed it after 1.5 years and it’s going to take forever for that to get downstream. I consider that a fundamental, stop-the-world UX issue, and Snap developers seemingly disagree. On my part, it does not inspire confidence in their priorities.

  • Because is snap enforces its own virtual file system, Aether on Linux is slower than Windows and Max OS.

And here are the positive things about Snap that I like:

  • It actually works, in that it does what it says it does.
  • The code base and developers are high caliber and they are responsive.

Here’s where I stand:

  • We want to move off snap, but we have to do it in a way that does not create an extra maintenance burden
  • We use electron-builder as our build pipeline, so we are limited by the options it provides
  • The maintenance burden constraint means there can really be only one ‘first party’ way of shipping for Linux for me
  • That said, there’s been some interest in the community for packaging aether for their own distros. I know there is at least the Arch Linux one being prepared to track official releases right now
  • Starting next release, I’ll be starting to provide the ‘unpacked’ Linux versions as well, this should make it easy for you to package it for your own distro or make it easy for someone else to provide that
  • The reason we can do the unpackaged release is that it actually is something that is already generated by our build pipeline in order to create the snap. Now that I know it’s valuable I can automate it so that that intermediate artefact generated will also be zipped up and shipped as an end result. So offering unpacked should not add to the release burden.
  • As for changing the official primary Linux release, the options are again Flatpak, Snap or Debian package. The last one is for me the nicest but it precludes quite a few non-Debian based systems unnecessarily. Snap has well known issues. I’ll take another look at Flatpak. Ultimately what we can adopt is only what we can automate and what electron-builder supports, so the real solution here is for the community to come up with package maintainers for the most popular distros. I don’t use Linux myself as a desktop environment (my preferred flavour of UNIX is Darwin) so here more than anywhere else I need to rely on some experts stepping up.

Hope that makes more sense, I’d love to get some more input on this as well. Apologies for the typos, I just wrote this on my phone.

That was a lot to read. Well, shoot. I won’t blame you guys for not having another solution.

Yeah, unfortunately we’re hard limited by maintainer time, and the fact that I’m not using a linux desktop. It would be best if we would have packaging people who are responsible for releases of software for their own distros.