# Concerns about use of Snap for linux installations

**URL:** <https://discourse.processing.org/t/concerns-about-use-of-snap-for-linux-installations/47185>\
**Category:** Processing\
**Created:** [September 22, 2025, 1:48am UTC](https://discourse.processing.org/t/concerns-about-use-of-snap-for-linux-installations/47185 "2025-09-22T01:48:06Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![desk](https://avatars.discourse-cdn.com/v4/letter/d/a9a28c/32.png) [@desk](https://discourse.processing.org/u/desk)\
**Post date:** [September 22, 2025, 1:48am UTC](https://discourse.processing.org/t/concerns-about-use-of-snap-for-linux-installations/47185/1 "2025-09-22T01:48:06Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![stefterv](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/stefterv/32/21678_2.png) [@stefterv](https://discourse.processing.org/u/stefterv)\
**Post date:** [September 22, 2025, 3:14am UTC](https://discourse.processing.org/t/concerns-about-use-of-snap-for-linux-installations/47185/2 "2025-09-22T03:14:26Z")

</div>

Yes this is in the works

> <https://github.com/processing/processing4/pull/1204>
>
> Out of caution we kept the Ant GitHub Actions in the repository, this PR will re…move them and introduce a revised version of the Gradle based GitHub Actions, providing the following.
> 
> \- Setup specific to Processing is now stored in a shared action, this will cut down on repeated configuration, if anyone knows a good way to clean up the matrices I would like to know.
> \- This PR pulls the configuration files out of Gradle and places them into \`app/linux\` similar to macOS and Windows.
> \- This PR separates the different platforms in the release action, originally they were done with a matrix but it started to have too many exceptions and platform specific flow that I decided to have a unique job for every platform still with a matrix on the architectures.
> \- This PR adds support for flatpak (not yet flathub) and add the .deb file to the release which is used by flatpak and snap.
> 
> Closes https://github.com/processing/processing4/issues/890 
> Closes #1211 
> and includes #1202 
> \### TODO
> \- \[\] Include the new SVG-based icons for every platform
> \- \[\] Separate out Windows signing
> \- \[\] Separate out macOS notarisation
> 
> 
> \### Follow up tasks
> \- \[\] Separate out the macOS notarisation step for a future macOS App Store Release
> \- \[\] Flathub Submission

---

<div class="post-metadata">

**Author:** ![desk](https://avatars.discourse-cdn.com/v4/letter/d/a9a28c/32.png) [@desk](https://discourse.processing.org/u/desk)\
**Post date:** [September 22, 2025, 3:21am UTC](https://discourse.processing.org/t/concerns-about-use-of-snap-for-linux-installations/47185/3 "2025-09-22T03:21:10Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![stefterv](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/stefterv/32/21678_2.png) [@stefterv](https://discourse.processing.org/u/stefterv)\
**Post date:** [September 22, 2025, 3:21am UTC](https://discourse.processing.org/t/concerns-about-use-of-snap-for-linux-installations/47185/4 "2025-09-22T03:21:57Z")

</div>

We also have portable releases on GitHub which do not use any sandboxing

> **[Release Processing 4.4.7 · processing/processing4](https://github.com/processing/processing4/releases/tag/processing-1307-4.4.7)**
>
> You can now access the forum, and report issues from the Help menu, thanks to first time contributor @lassevonpfeil! 💙 🎉 ✨
> Minor bug fixes, and refactors.
> We addressed a long standing issue where t...

---

<div class="post-metadata">

**Author:** ![desk](https://avatars.discourse-cdn.com/v4/letter/d/a9a28c/32.png) [@desk](https://discourse.processing.org/u/desk)\
**Post date:** [September 22, 2025, 3:24am UTC](https://discourse.processing.org/t/concerns-about-use-of-snap-for-linux-installations/47185/5 "2025-09-22T03:24:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![scudly](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/scudly/32/5597_2.png) [@scudly](https://discourse.processing.org/u/scudly)\
**Post date:** [September 22, 2025, 3:29pm UTC](https://discourse.processing.org/t/concerns-about-use-of-snap-for-linux-installations/47185/6 "2025-09-22T15:29:31Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![GoToLoop](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/gotoloop/32/86_2.png) [@GoToLoop](https://discourse.processing.org/u/GoToLoop)\
**Post date:** [September 22, 2025, 5:24pm UTC](https://discourse.processing.org/t/concerns-about-use-of-snap-for-linux-installations/47185/7 "2025-09-22T17:24:27Z")

</div>

Also consider adding an AppImage option, given it’s kind of a self-contained portable format:

> **[AppImage](https://en.wikipedia.org/wiki/AppImage)**
>
> AppImage (formerly known as klik and PortableLinuxApps) is an open-source format for distributing portable software on Linux. It aims to allow the installation of binary software independently of specific Linux distributions. As a result, one AppImage can be installed and run across various GNU/Linux distributions without needing to use different files. It aims to be a format that is self-contained, rootless, and independent of the underlying Linux distribution.
> Released first in 2004 under the ...

> **[AppImage](https://appimage.org)**
>
> Linux apps that run anywhere

---

<div class="post-metadata">

**Author:** ![desk](https://avatars.discourse-cdn.com/v4/letter/d/a9a28c/32.png) [@desk](https://discourse.processing.org/u/desk)\
**Post date:** [September 23, 2025, 12:08am UTC](https://discourse.processing.org/t/concerns-about-use-of-snap-for-linux-installations/47185/8 "2025-09-23T00:08:22Z")

</div>

I believe AppImages also avoid some of the sandboxing issues, but I’m not sure about the downsides for users that would emerge.