Hi all,
I rarely post here, but I was surprised not to see more pushback on this. The Linux download page now offers Processing only as a Snap.
Snap works for some people, and I get why the maintainers like it: one build, automatic updates, no dependency headaches. The problem is that a large slice of the Linux world either can’t or won’t use Snap. Many distributions don’t ship it; others disable it outright. Even where it’s available, people are reporting issues with system integration due to the sandboxing.
A plain .tar.gz (or an AppImage) would sidestep all of this. It’s what we used for years: download, unzip, run, no root, no daemon, no store account. If bandwidth is an issue, park it on GitHub releases and link from the main page; mirrors will spring up overnight.
Could we please list one non-Snap option alongside the current button? It’s a change that would make Processing welcome again on the distros most of us actually use.
Thanks for considering
Yes this is in the works
Those would certainly by better options for me, but non Debian based distros may still run into issues related to the sandboxing in Snap or Flatpak. This is why I suggest AppImage or the old archive format. But, as I said earlier, for my own selfish reasons I’m perfectly happy with deb and flatpak on the distribution I use.
We also have portable releases on GitHub which do not use any sandboxing
Yes, that’s what I’ve been having my students use, but it’s not very visible on the main download page and leads to confusion and concerns among them. It would be more inclusive to make that an equal install option for the wider community.
There is no indication on the Linux download page that any other packaging option exists other than snap. There are links to other OS platforms and also to older versions, but none of the text even suggests that the portable version exists. Linux Mint is one of the most popular distributions and it discourages the use of snap. Snap should not be the default or, indeed, ONLY download option presented.
Please make the portable (ideally including the older install script) the default with text explicitly offering the availability of alternate packaging methods on the link to the github downloads. Better yet, list all the packaging links directly on the download page so people don’t have to jump through the link chain.
Also consider adding an AppImage option, given it’s kind of a self-contained portable format:
I believe AppImages also avoid some of the sandboxing issues, but I’m not sure about the downsides for users that would emerge.