Hubbry Logo
Snap (software)Snap (software)Main
Open search
Snap (software)
Community hub
Snap (software)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Snap (software)
Snap (software)
Snap (software)
View on Wikipedia
from Wikipedia
Snap
DeveloperCanonical Ltd.
Repository
Written inGo, C, Shell script, Python, JavaScript, NASL[1]
Operating systemLinux
LicenseGNU GPLv3 (Client & Runtime), proprietary (Backend)[2]
Websitesnapcraft.io Edit this on Wikidata

Snap is a software packaging and deployment system developed by Canonical for operating systems that use the Linux kernel and the systemd init system. The packages, called snaps, and the tool for using them, snapd, work across a range of Linux distributions[3] and allow upstream software developers to distribute their applications directly to users. Snaps are self-contained applications running in a sandbox with mediated access to the host system.

Functionality

[edit]

Configurable sandbox

[edit]

Applications in a Snap run in a container with limited access to the host system. Using Interfaces, users can give an application mediated access to additional features of the host such as recording audio, accessing USB devices and recording video.[4][5][6] These interfaces mediate regular Linux APIs so that applications can function in the sandbox without needing to be rewritten. Desktop applications can also use the XDG Desktop Portals, a standardized API originally created by the Flatpak project (originally called xdg-app) to give sandboxed desktop applications access to host resources.[7][8] These portals often provide a better user experience compared to the native Linux APIs because they prompt the user for permission to use resources such as a webcam at the time the application uses them. The downside is that applications and toolkits need to be rewritten in order to use these newer APIs.

The Snap sandbox also supports sharing data and Unix sockets between Snaps.[9] This is often used to share common libraries and application frameworks between Snaps to reduce the size of Snaps by avoiding duplication.[10][11]

The Snap sandbox heavily relies on the AppArmor Linux Security Module from the upstream Linux kernel. Because only one "major" Linux Security Module (LSM) can be active at the same time,[12] the Snap sandbox is much less secure when another major LSM is enabled. As a result, on distributions such as Fedora which enable SELinux by default, the Snap sandbox is heavily degraded. Although Canonical is working with many other developers and companies to make it possible for multiple LSMs to run at the same time, in 2020 this solution was still a long time away.[13][12][14]

Automatic and atomic updates

[edit]

Multiple times a day, snapd checks for available updates of all Snaps and installs them in the background using an atomic operation. Updates can be reverted[15][16] and use delta encoding to reduce their download size.[17][18][19]

Publishers can release and update multiple versions of their software in parallel using channels. Each channel has a specific track and risk, which indicate the version and stability of the software released on that channel. When installing an application, Snap defaults to using the latest/stable channel, which will automatically update to new major releases of the software when they become available. Publishers can create additional channels to give users the possibility to stick to specific major releases of their software. For example, a 2.0/stable channel would allow users to stick to the 2.0 version of the software and only get minor updates without the risk of backwards incompatible changes. When the publisher releases a new major version in a new channel, users can manually update to the next version when they choose.[20][21][22][23]

The schedule, frequency and timing of automatic updates can be configured by users. Users can also pause automatic updates for a certain period of time, or indefinitely.[24][25][26] Updates are automatically paused on metered connections.[27][28]

Snapcraft

[edit]
Snapcraft
DeveloperCanonical Ltd.
Stable release
8.12.0[29] / 5 September 2025; 49 days ago (5 September 2025)
Repositorygithub.com/snapcore/snapcraft
Written inPython, Shell script, C++, Go, Dart[30]
Operating systemLinux
LicenseGNU General Public License, version 3.0
Websitesnapcraft.io Edit this on Wikidata

Snapcraft is a tool for developers to package their programs in the Snap format.[31] It runs on any Linux distribution supported by Snap, macOS[32] and Microsoft Windows.[33] Snapcraft builds the packages in a Virtual Machine using Multipass,[34] in order to ensure the result of a build is the same, regardless of which distribution or operating system it is built on.[35] Snapcraft supports multiple build tools and programming languages, such as Go, Java, JavaScript, Python, C/C++ and Rust. It also allows importing application metadata from multiple sources such as AppStream, git, shell scripts and setup.py files.[32][36]

Snap Store

[edit]

The Snap Store allows developers to publish their snap-packaged applications.[37] All apps uploaded to the Snap Store undergo automatic testing, including a malware scan. However, the scan does not catch all issues. In one case in May 2018, two applications by the same developer were found to contain a cryptocurrency miner which ran in the background during application execution. In 2024, fake cryptocurrency wallets were uploaded that would steal the user's funds, and then when taken down by Canonical, simply reuploaded by a new account.[38] Although the Snap sandbox attempts to reduce the impact of a malicious app, multiple exploits have been found that allow malicious Snaps to escape the sandbox and gain direct access to the user's data.[39][40] Canonical recommends users only install Snaps from publishers trusted by the user.[41][42]

Support

[edit]

Snaps are self-contained packages that work across a range of Linux distributions. This is unlike traditional Linux package management approaches, which require specifically adapted packages for each Linux distribution.[43][44]

The command snap list here shows that Skype and IntelliJ IDEA have been installed

The snap file format is a single compressed filesystem using the SquashFS format with the extension .snap. This filesystem contains the application, libraries it depends on, and declarative metadata. This metadata is interpreted by snapd to set up an appropriately shaped secure sandbox for that application. After installation, the snap is mounted by the host operating system and decompressed on the fly when the files are used.[45][23] Although this has the advantage that snaps use less disk space, it also means some large applications start more slowly.[46][47]

Snap supports any class of Linux application such as desktop applications, server tools, IoT apps and even system services such as the printer driver stack.[48][49] To ensure this, Snap relies on systemd for features such as running socket-activated system services in a Snap.[50] This causes Snap to work best only on distributions that can adopt that init system.[51]

Adoption

[edit]
Screenshot of Spotify-EasyRPM installation script running on openSUSE Tumbleweed, the script downloaded the Spotify Linux Snap package from snapcraft.io, processed and converted the package into RPM, and installed the RPM into the system

Snap initially only supported the all-Snap Ubuntu Core distribution, but in June 2016, it was ported to a wide range of Linux distributions to become a format for universal Linux packages.[52] Snap requires Systemd which is available in most, but not all, Linux distributions. Other Unix-like systems (e.g. FreeBSD) are not supported.[53] ChromeOS does not support Snap directly, only through Linux distributions installed in it that support Snap, such as Gallium OS.[54]

Ubuntu and its official derivatives pre-install Snap by default, as well as other Ubuntu-based distributions such as KDE Neon, and Zorin OS.[55] Solus have currently planned to drop Snap, to reduce the burden of maintaining AppArmor patches needed for strict Snap confinement.[56] Zorin OS have removed Snap as a default package in the Zorin OS 17 release.[57] While other official Ubuntu derivatives such as Kubuntu, Xubuntu, and Ubuntu MATE have also shipped with the competing Flatpak as a complement, they will no longer do so beginning with Ubuntu 23.04, meaning that it must be installed manually by the user.[58]

A number of notable desktop software development companies publish their software in the Snap Store, including Google,[59] JetBrains,[60] KDE,[61] Microsoft (for Linux versions of e.g. .NET Core 3.1,[62] Visual Studio Code, Skype,[63] and PowerShell), Mozilla[64] and Spotify.[65] Snaps are also used in Internet-of-Things environments, ranging from consumer-facing products[66] to enterprise device management gateways[67] and satellite communication networks.[68][69] Finally, Snap is also used by developers of server applications such as InfluxDB,[70] Kata Containers,[71] Nextcloud[72] and Travis CI.[73]

Reception

[edit]

Snap has received mixed reaction from the developer community. On Snap's promotional site, Heroku praised Snap's auto-update as it fits their fast release schedule well. Microsoft mentions its ease of use and Snap being YAML-based, as well as it being distribution-agnostic. JetBrains says the Snap Store gives their tools more exposure.[74][better source needed]

Others have objected to the closed-source nature of the Snap Store. Clément Lefèbvre (Linux Mint founder and project leader[75][76]) has written that Snap is biased and has a conflict of interest. The reasons he cited include it being governed by Canonical and locked to their store, and also that Snap works better on Ubuntu than on other distributions.[77] He later announced that the installing of Snap would be blocked by APT in Linux Mint,[78][79] although a way to disable this restriction would be documented.[80]

On recent versions of Ubuntu, Canonical has migrated certain packages exclusively to Snap, such as Chromium and Firefox[81] web browsers.[82][37] The replacement of Firefox led to mixed reception from users due to performance issues with the Snap version, especially on startup.[81]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Snap (software)

View on Grokipedia
from Grokipedia
Snap is a software packaging and deployment system developed by for Linux-based operating systems, enabling the distribution of self-contained application bundles known as that include all necessary dependencies, libraries, and binaries. These packages are designed for cross-distribution compatibility, automatic updates, and sandboxed execution to enhance security through confinement mechanisms like . Introduced as part of efforts to simplify software management in heterogeneous environments, Snap supports desktop applications, servers, and IoT devices, with the snapcraft tool facilitating package creation. While Snap has facilitated broader adoption of universal packaging—allowing developers to target multiple variants without per-distro customization—it has drawn empirical scrutiny for tendencies toward larger file sizes and infrequent updates in distributed packages, as documented in analyses of over 1,000 showing average bloat exceeding native alternatives by factors of 2-5 times. metrics from user reports and benchmarks indicate startup delays of several seconds for some applications due to on-demand mounting and verification processes, contrasting with faster native package loading. Canonical's centralized Snap Store, which handles distribution and refreshes, has raised concerns over dependency on a single vendor for core infrastructure, despite the open-source nature of the packaging format itself. Nonetheless, integrations in distributions like demonstrate practical utility for maintaining consistent software versions amid fragmented ecosystem dependencies.

History

Origins and Development (2014–2016)

Snap originated from Click packages, which Canonical developed starting around 2013 for , its mobile operating system, to address dependency management and app isolation by bundling software with required libraries into self-contained .click files secured via read-only containers. This approach drew from earlier efforts to simplify app delivery amid Linux's fragmented packaging ecosystems, such as deb versus rpm formats, which often led to compatibility issues. On December 9, 2014, Canonical announced Ubuntu Core (initially termed Snappy Ubuntu Core), a minimal, immutable operating system for cloud and IoT devices that introduced "snappy" transactional updates for atomic, secure package installations with built-in rollback features. , as the packages were called, reused Click's store model, review processes, and confinement mechanisms but extended them to support kernels, runtimes, and full system images, targeting environments where traditional apt-based updates risked instability on resource-constrained hardware. Development emphasized cross-architecture compatibility and automatic security patching to mitigate risks from outdated devices in IoT deployments. Throughout 2015, Canonical refined the snappy infrastructure, releasing stable versions like snappy 15.04 in September, focusing on server and embedded use cases while integrating with for broader compatibility. By April 2016, with 16.04 LTS, Canonical elevated to a core packaging option, enabling developers to target multiple Ubuntu releases and distros without rebuilding for each, thus reducing fragmentation. In June 2016, the company expanded snap support to non-Ubuntu distributions like and Arch, positioning it as a universal format for sandboxed, dependency-free app distribution. This period's advancements prioritized developer ease, with tools like snapcraft emerging to streamline building from diverse source codebases.

Launch and Early Integration (2016–2018)

Snap packages were first integrated into the desktop variant of with the release of Ubuntu 16.04 LTS on April 21, 2016, enabling users to install and run snaps alongside traditional packages for delivering up-to-date applications. expanded development tools with the release of Snapcraft 2.9 on May 31, 2016, specifically tailored for building snaps on Ubuntu 16.04, which facilitated easier packaging of applications with their dependencies. On June 14, 2016, Canonical announced that snaps had evolved into a universal packaging format, with snapd—the core daemon for managing snaps—ported to distributions including , , , and openSUSE through collaboration with developers from those projects. This move aimed to reduce Linux fragmentation by allowing a single snap to run across diverse environments without modification, building on snaps' origins in the container-optimized Core. Early snap availability included over 250 packages for , such as Jenkins for , ownCloud for file syncing, and media players like VLC. During 2017 and 2018, integration deepened in releases, with snaps used for select server and IoT applications in 16.04 and 18.04 LTS, emphasizing automatic updates and sandboxing for security. released as a snap package on , 2018, providing a confined, auto-updating browser option that integrated with 's software center and addressed dependency conflicts common in traditional repositories. Adoption beyond remained limited in this period, as distributions like and openSUSE included snapd support but prioritized native packaging, reflecting varied community preferences for universal formats over established tools like .

Maturation and Expansion (2019–Present)

Snapd underwent significant technical maturation from 2019 onward, with releases introducing progressive update mechanisms for controlled deployments in critical environments, as enabled experimentally in May 2020. By 2021, Snapcraft 6.0 emphasized self-hosted development tooling packaged as snaps, streamlining workflows for maintainers. Security features advanced notably, including prompting for granular user consent on interface access in snapd 2.66 (November 26, 2024), and compliant variants for regulated sectors. New confinement options, such as session-lifespan prompts (snapd 2.71, August 14, 2024) and full-disk encryption controls via snap-fde-control interface (same release), enhanced sandboxing reliability. Platform support expanded to broaden ecosystem integration, with snapd packages tailored for , Amazon Linux, , , openSUSE, and Solus in version 2.62 (April 15, 2024). Hardware-specific interfaces proliferated, including driver libraries (opengl-driver-libs, etc., in 2.72, October 13, 2024), USB gadget support (2.71), and /ARM64 OP-TEE bindings (2.68, March 1, 2024), facilitating snaps on diverse architectures like IoT devices and embedded systems. ROS ecosystem compatibility grew, with ros-snapd-support interface added in 2.70 (July 10, 2024) and early ROS 2 Eloquent packaging guidance in December 2019. Canonical pursued desktop expansion through an immutable, all-snap variant announced in May 2023, realized with 24.04 LTS in April 2024, enabling atomic updates and factory resets for enhanced stability akin to server deployments. IoT applications matured via Core on , supporting industrial transitions from desktops since February 2019. By October 2025, silicon-optimized inference snaps simplified AI model deployment on , dynamically loading hardware-specific components to reduce dependency overhead. These developments underscore Snap's shift toward enterprise-grade universality, though adoption metrics remain opaque beyond Canonical's internal tracking of snap counts and error rates.

Technical Architecture

Packaging and Dependencies

Snaps employ a filesystem format to package applications, bundling executable binaries, runtime libraries, configuration files, and metadata into a single, read-only that ensures immutability and predictability. Upon installation via snapd, the mounts at /snap/<snap-name>/<revision>/, isolating the contents from the host system and enabling atomic updates by replacing revisions. The metadata, primarily defined in snap.yaml within the meta/ directory, specifies attributes such as the snap's name, version, applications, and interfaces for confinement, guiding runtime behavior without external configuration. To achieve distribution-agnostic deployment, snaps incorporate all necessary runtime dependencies directly into the package, circumventing conflicts arising from divergent host library versions or package managers. This self-containment extends to libraries and binaries, which reside within the snap's root, accessible via environment variables like $SNAP during execution. Developers construct snaps using snapcraft, dividing the build into "parts" that declare build-packages for transient compilation tools (e.g., gcc or pkg-config), which install on the build host but exclude from the final artifact, and stage-packages for persistent runtime components (e.g., libssl or git), which integrate into the snap. Build processes iteratively resolve unmet dependencies through debugging modes in snapcraft, pulling from repositories like Ubuntu's apt during staging. For efficiency in ecosystems with common resources, snaps support dependency sharing via the content interface, where a "producer" snap exposes directories or files through a slot, connectable to plugs in "" snaps, allowing runtime access to shared code, data, or libraries without redundant bundling. This mechanism, declared in snap.yaml under plugs and slots, requires explicit connections post-installation (e.g., via snap connect) and applies to scenarios like distributing base libraries or assets across related applications. Layouts in metadata further customize the execution environment, such as remapping paths for pre-compiled binaries reliant on external structures, though primary dependency resolution remains internal to the snap.

Sandboxing Mechanisms

Snap employs multiple layers of isolation to sandbox applications, primarily through its confinement model enforced by the snap daemon (snapd). Strict confinement, the default for most snaps, restricts access to system resources such as files, network, and hardware unless explicitly granted via interfaces, leveraging features for enforcement. This approach ensures that snaps operate in a controlled environment, minimizing potential impact on the host system. The core sandboxing relies on for , generating per-command profiles (e.g., snap.foo.bar) that mediate file reads/writes, execution of binaries, capabilities, and network operations. Violations result in EACCES denials and are logged for auditing. provides syscall filtering via an allowlist tailored to each snap command, denying unauthorized calls with EPERM (or SIGSYS in older snapd versions) and logging them. Namespaces isolate the snap's view of the system, including private mount namespaces with a dedicated /tmp directory and devpts instance per snap, preventing interference with host processes or filesystems. enforce resource limits (e.g., CPU, memory) and control device access through udev-integrated rules, returning EPERM on violations without logging. Traditional Unix permissions, including and ACLs, supplement these, denying access with EACCES. Snapd orchestrates this isolation using the snap-confine helper binary, which sets up namespaces and applies profiles before executing the snap's payload from its immutable container. Interfaces—plugs in the snap connecting to system-defined slots—dynamically extend policies, such as granting network access or remounting specific directories read-only. For instance, the home interface allows controlled file access in the user's home directory. Alternative confinement modes trade sandboxing for compatibility: classic confinement permits broad system access akin to traditional packages, requiring manual review and installation flags, suitable for software needing deep integration like system tools. Devmode applies strict rules but disables enforcement, logging violations for development debugging without restricting functionality. These mechanisms collectively provide a defense-in-depth strategy, though effectiveness depends on kernel support (e.g., AppArmor enabled) and proper interface configuration.

Update and Rollback Processes

Snaps employ a refresh mechanism managed by the snapd daemon, which automatically checks for available updates from the Snap Store four times per day by default. This frequency can be customized via the refresh.timer system option, allowing administrators to schedule checks at specific times or intervals, such as weekly on Fridays between 23:00 and 01:00. Updates, termed "refreshes," download and apply new revisions transactionally, ensuring atomicity: the process either completes fully or reverts to the prior state without partial changes. For individual snaps, refreshes occur independently unless configured for multi-snap transactions via snap refresh --transaction=all-snaps, which requires snapd version 2.55 or later and is useful for interdependent packages like kernels and gadgets on Core. Manual intervention is possible through commands like snap refresh <snap-name> to force an update or snap refresh --hold=<duration> to pause automatic refreshes for a specified period, such as 24 hours or indefinitely with forever. System-wide controls include refresh.hold to delay updates up to 90 days and refresh.retain to retain 2 to 20 previous revisions for potential reversion, with the default of 2 ensuring the current and one prior version are kept. Metered connections can be respected via refresh.metered to avoid data usage during refreshes. Channels (e.g., , beta) determine the tracked revision series, and refreshes pull from the configured channel unless overridden. Rollback, or reversion, to a prior revision is facilitated by the snap revert <snap-name> command, which by default restores the immediately previous revision while preserving user data in separate writable mounts. Specific revisions can be targeted with --revision=<number>, provided they are retained; older ones require manual snap file transfer if not cached. Reversion does not alter the tracked channel, so a subsequent refresh may reattempt the reverted revision unless a newer one is published. Transactional failures during refresh automatically revert changes, but application-level issues post-refresh necessitate manual snap revert invocation, as snapd does not detect functional breakage. Snapshots, generated via snap save, enable broader state restoration including multiple snaps and data, serving as a for complex rollbacks.

Core Features

Building and Publishing Snaps

Snapcraft, the primary tool for building snaps, is a command-line utility developed by that automates the packaging process by interpreting a declarative configuration file named snapcraft.yaml. This file specifies essential metadata such as the snap's name, version, summary, description, and confinement level (strict or ), along with definitions for parts, apps, and hooks. Parts in the outline how to retrieve or binaries, build them using plugins (e.g., nil for pre-built dumps, make for Makefile-based projects, or cmake for projects), stage dependencies, and prime the final snap contents, enabling across diverse environments. Developers initialize a with snapcraft init, edit the YAML to define these elements, and execute snapcraft or snapcraft build in the project directory to fetch dependencies via a remote build service or locally, compile parts in isolated stages, assemble the squashfs-based snap archive, and validate assertions like interface connections. The resulting .snap file encapsulates the application and its runtime dependencies, supporting cross-architecture builds since Snapcraft's integration with Launchpad builders in 2016. Publishing snaps involves registering a unique snap name via snapcraft register <snap-name> to claim ownership in the Snap Store, followed by authentication with snapcraft login using Ubuntu One credentials managed by Canonical. Developers then upload the built snap using snapcraft upload <path-to-snap.snap> or snapcraft push <snap-name> --release=stable to promote it to channels such as edge for testing, beta for wider review, or stable for production distribution. The Snap Store, a centralized repository operated exclusively by Canonical since its public launch in 2016, reviews uploads for compliance (e.g., confinement assertions passing), hosts metadata, and enables global discovery and installation via snap install <snap-name>, with support for automatic channel promotions and versioning tied to semantic release tags. Private snaps can be published to dedicated stores for enterprise use, but public publishing requires adherence to Canonical's terms, including open-source encouragement though proprietary snaps are permitted. As of 2025, over 10,000 snaps have been published, reflecting the ecosystem's growth driven by this streamlined workflow.

Distribution via Snap Store

The Snap Store, operated by , functions as the central repository for publishing and distributing snap packages to users across distributions. Developers build snaps using the snapcraft tool and upload them via the command snapcraft push, targeting specific channels such as , , beta, or edge, which allow for staged rollouts and testing before wider availability. Once uploaded, snaps undergo an automated review process for compliance with confinement policies, with verified publishers—those meeting Canonical's criteria for trustworthiness—bypassing manual scrutiny to expedite distribution. Users access the Snap Store through its web interface at snapcraft.io/store, which supports browsing by categories including productivity, development tools, games, and utilities, or via integrated search functionality for discovering by name or keyword. Installation occurs seamlessly via the snap install command, which fetches the latest version from the designated channel, or through graphical clients like the Snap Store application on supported desktops, enabling automatic dependency resolution and sandboxed deployment without system-level interference. The store emphasizes discoverability, with features like developer verification badges, user ratings, and descriptions to aid selection, though it centralizes control under Canonical's curation. While the official Snap Store handles public distribution for broad reach, alternatives exist for private or enterprise use, such as self-hosted stores via HTTP servers or dedicated services, allowing organizations to mirror snaps internally without relying on the public repository. This flexibility addresses scenarios requiring isolation, but the public Snap Store remains the default pathway, hosting snaps from itself, open-source projects, and third-party developers for universal compatibility.

Automatic Updates and Confinement

Snaps feature an automatic update mechanism managed by the snapd daemon, which checks for new versions from the Snap Store up to four times daily, applying refreshes in the background without user intervention unless configured otherwise. This process, termed a "refresh," downloads and installs the latest revision atomically, ensuring the application remains functional during updates and allowing to prior versions via snap revert if issues arise. Users can control refreshes using commands like snap refresh --hold to postpone updates or snap set system refresh.schedule to define specific timing windows, though automatic updates are enabled by default to maintain security and compatibility. Confinement in snaps enforces security through sandboxing, restricting application access to host resources via derived policies from snap metadata. Strict confinement, the default for most snaps, utilizes mechanisms such as profiles for file and network access control, filters to limit system calls, and device to isolate hardware interactions, providing isolation while allowing declared interfaces for necessary permissions like access. confinement, requiring explicit approval during installation (e.g., via snap install --classic), grants full system access akin to traditional packages, suitable for applications needing broad privileges but reducing sandboxing benefits. Devmode confinement, intended for development and testing, applies strict policies but logs violations without enforcement, enabling while highlighting potential escapes. These layers collectively aim to mitigate risks from untrusted code, though effectiveness depends on interface declarations and store oversight.

Adoption and Ecosystem Integration

Supported Distributions and Hardware

Snap supports installation via the snapd daemon on a wide range of distributions, primarily those using as the init system. Official documentation lists compatibility with (default support since version 16.04), (from version 9 onwards), (from version 24), and openSUSE (from Leap 42.2 and Tumbleweed). Additional distributions include , (from 7.6), OS, (version 8), elementary OS, , (from 18.2 to 22.1), , and (RHEL from 7.6 to 9.x). Enterprise variants like and EPEL-compatible systems (e.g., , ) also receive support through dedicated packages. While Snap aims for universal compatibility, installation on non-standard or non-systemd distributions may require manual configuration or lack official maintenance. Regarding hardware architectures, Snap packages are built and distributed for multiple processor types to enable cross-platform deployment. Core supported architectures include amd64 (x86-64), arm64 (AArch64), armhf (ARMv7 hard-float), and i386 (x86 32-bit), which can be targeted during snap creation using tools like Snapcraft. Additional architectures such as ppc64el (PowerPC 64-bit little-endian), s390x (IBM Z mainframes), and emerging ones like RISC-V 64-bit are supported via extended build environments, often through Canonical's Launchpad for cross-compilation. Snaps run on systems meeting basic Linux kernel requirements (version 3.10 or later with AppArmor or seccomp support for confinement), without strict hardware minima beyond the host architecture's compatibility. This multi-architecture approach facilitates deployment on desktops, servers, embedded devices (e.g., ARM-based IoT via Ubuntu Core), and cloud environments.

Usage Metrics and Developer Engagement

Developers snaps can access detailed usage metrics for their own packages via the snapcraft metrics command-line tool, which reports data such as active device counts, installation trends, geographic distribution, application versions in use, and operating systems. These metrics are aggregated anonymously by the Snap Store from client , enabling publishers to track adoption and refine releases, though aggregates but does not publicly release system-wide figures beyond developer-specific views. Public aggregate usage data remains limited, with Canonical's most recent comprehensive disclosure from October 2018 reporting approximately 100,000 snap installs per day across desktop, server, , , and IoT environments, alongside a 59% quarter-over-quarter increase in total installed snaps. No equivalent updates have been issued since, despite ongoing internal tracking for service improvement. Developer engagement centers on the Snapcraft build tool and Snap Store publishing platform, which facilitate cross-distribution packaging without reliance on native repositories. Canonical fosters participation through initiatives like the Star Developer program, launched in June 2022 to designate trusted maintainers of high-quality and encourage support via forums. Active development persists in forums and contributions to snapd, the runtime daemon, though proprietary elements in the store backend have drawn criticism for limiting decentralized alternatives. The ecosystem includes verified publishers such as , , and , indicating institutional involvement alongside independent contributors.

Criticisms and Controversies

Performance and Resource Overhead

Snaps have faced criticism for introducing performance overhead, particularly in application startup times, attributed to the use of compressed file systems that require mounting and decompression on initial launch. Cold startup times for Snap-packaged applications can be several seconds longer than native packages; for instance, tests with showed Snap versions taking approximately 3.8 seconds longer for initial playback of a video clip compared to the DEB equivalent. However, has implemented optimizations, such as parallel content mounting and caching mechanisms, reducing Snap startup times by around 50% as of 2022. Runtime performance penalties are generally minimal once loaded, with benchmarks indicating less than 1.5% slower execution for workloads like video playback in VLC or image processing in . Resource overhead includes increased disk space consumption due to bundling dependencies within each to ensure confinement and cross-distribution compatibility, leading to potential across packages that could share libraries in native formats. This self-contained design results in larger package sizes compared to traditional DEB or RPM packages, exacerbating storage demands on systems with multiple Snaps. Memory usage can also be higher in some cases owing to isolated runtime environments, though empirical tests show mixed results; Snap variants exhibited elevated CPU utilization (up to 208% versus 109% for DEB) and slightly higher resident set size during batch operations. The snapd daemon itself contributes minor background overhead, with user reports and discussions noting correlations with prolonged system boot times on mechanical drives, though quantitative evidence remains anecdotal and varies by hardware. Comparative benchmarks highlight Snaps' trade-offs: in rendering tasks like video encoding with or image generation in , Snap and variants lagged native packages by 20-50 seconds, while browser workloads (e.g., , MotionMark) showed Snaps performing within 2% of or equivalents. These overheads stem causally from Snap's emphasis on universal packaging and sandboxing, prioritizing isolation over optimized shared resource utilization, though ongoing refinements by aim to mitigate them without compromising core design goals.

Centralization and Canonical Control

Snap packages are primarily distributed through the Snap Store, a centralized repository operated and maintained exclusively by Ltd., the company behind . Developers must create a free account on snapcraft.io and register snap names through 's platform before publishing, with snaps pushed via the snapcraft push command to channels controlled by the store. This process enforces 's , which grant the company authority to review, moderate, or remove snaps at its discretion, including for policy violations or concerns, as operates the store as a for-profit entity. Unlike traditional package repositories, which are often community-maintained and decentralized across distributions, the Snap Store creates a single point of ingress and egress for software dissemination, potentially enabling to influence availability across all supported systems. Canonical's control extends to update mechanisms, where snaps installed via the store receive automatic refreshes by default, with the snapd daemon checking for updates four times daily and applying them without explicit user consent unless configured otherwise. Users can inhibit refreshes via commands like snap refresh --hold or system-wide timers, but this requires manual intervention, positioning automatic updates as an feature rather than opt-in. In , Canonical has leveraged this infrastructure to transition core applications—such as , which became snap-only starting with 22.04 in April 2022—to Snap format, bypassing traditional .deb packages and enforcing store-mediated delivery. Critics, including Linux distribution maintainers like those at , argue this fosters a "monopoly-like" dependency on Canonical, undermining the open, user-sovereign ethos of by centralizing software lifecycle management in a proprietary-controlled . This centralization has sparked debates on , with proponents noting it simplifies cross-distribution compatibility and rapid patching, while detractors highlight risks of store downtime, policy-driven , or Canonical's commercial priorities overriding community needs—evident in cases where alternative snap hosting requires custom setups outside the official store, which lack seamless integration. Empirical adoption data shows uneven uptake beyond , partly attributed to resistance against perceived overreach, as non-Ubuntu distros like prioritize alternatives to avoid . Canonical maintains that store oversight enhances trustworthiness through verification processes, but independent analyses question the transparency of these, given the company's dual role as developer and gatekeeper without mandatory open audits of moderation decisions.

Security Vulnerabilities and Store Management

Snap's security model relies on confinement mechanisms including profiles, filters, namespaces, and device cgroup isolation to restrict application access to host resources. However, multiple vulnerabilities have allowed snaps to escape these restrictions or escalate privileges. In August 2024, Canonical addressed issues in snapd (USN-6940-1) where a malicious snap could exploit improper validation to bypass sandboxing if installed by a user. Similarly, in May 2023, USN-6125-1 fixed a flaw permitting malicious snaps to invoke the with TIOCLINUX requests, evading restrictions. Privilege escalation bugs in snap-confine, the component handling sandbox setup, were disclosed in February 2022 by Qualys researchers, enabling local attackers to gain root access via race conditions or symlink attacks during mount namespace preparation (CVE-2021-44731). More recently, CVE-2024-29069 affected snapd versions before 2.62, where inadequate symlink destination checks during extraction allowed arbitrary file overwrites. CVE-2024-5138 enabled unauthorized actions via snapctl argument parsing flaws. Critics have noted that kernel-level exploits could further undermine confinement, as snaps share the host kernel without full isolation. Classic confinement mode, used by some snaps for compatibility, grants full system access akin to traditional packages, reducing security benefits. The Snap Store, operated by , centralizes package distribution, review, and updates, with snaps requiring upload for validation before availability. This includes automated security scans and developer notifications for detected vulnerabilities in published snaps, such as staged package flaws. However, the store's partial closed-source nature and Canonical's control have drawn criticism for creating single points of failure, potential risks, and dependency on a proprietary backend for distribution—unlike decentralized alternatives. Users cannot self-host mirrors, raising concerns about long-term access if Canonical alters policies or ceases operations. Canonical maintains that open-source snapd tooling mitigates these risks, but the model contrasts with repository-based systems allowing multiple independent sources.

Comparisons to Alternatives

Snap versus Flatpak

Both Snap and are universal packaging formats designed to simplify application distribution by bundling dependencies and enabling sandboxing across distributions, reducing compatibility issues inherent in traditional repository-based systems. They emerged as responses to fragmentation in Linux ecosystems, with Snap launched by in 2016 and originating from projects like GNOME's software efforts around 2015, aiming for cross-distro portability without reliance on distro-specific packages. However, their implementations diverge in , , and practical trade-offs, influencing developer and user preferences. A primary distinction lies in their distribution models: Snap relies on a centralized store managed by (Snapcraft/Snap Store), which facilitates easier maintenance and automatic updates but introduces dependency on Canonical's infrastructure and approval processes for snaps. In contrast, adopts a more decentralized approach, with Flathub as the primary community-driven repository but support for custom remotes and repositories, allowing greater flexibility for users and developers to host independent sources without a single gatekeeper. This centralization in Snap has drawn criticism for potential , as Canonical controls core services like the store backend, whereas 's model aligns with open-source principles of distributed control, though Flathub remains dominant in practice.
AspectSnapFlatpak
SandboxingUses for strict confinement by default, with mandatory interfaces for system access; enables finer-grained, developer-defined permissions but requires review for strict snaps.Employs bubblewrap and portal-based permissions, configurable at install or runtime via tools like Flatseal; sandboxing is enabled but often less restrictive out-of-the-box, relying on user overrides for access.
PerformanceSlower startup times due to on-demand mounting of compressed images, leading to measurable delays (e.g., seconds longer for apps like on mechanical drives); better suited for server/IoT where startup is infrequent.Generally faster launches via OSTree-based storage and shared runtimes, minimizing per-app overhead; benchmarks show reduced load times compared to Snap, especially on desktops.
Package SizeOften smaller due to full bundling without shared runtimes for all apps, but increases with snaps that include extensive dependencies.Larger initial sizes from runtimes (e.g., / bases), but efficiencies via sharing across apps reduce net disk usage in multi-app setups.
Adoption FocusStrong in ecosystems and -backed servers/IoT (e.g., core snaps for embedded); developer-friendly for building via snapcraft tool.Broader desktop uptake across distros like and ; community metrics indicate higher app availability on Flathub (over 2,000 apps as of 2024) versus Snap Store.
Security models reflect philosophical differences: Snap's enforcement provides robust, policy-driven isolation, touted as more advanced by proponents for preventing unauthorized escalations, though it demands trust in Canonical's confinement declarations. 's permission system offers transparency and user control via declarative overrides, but defaults to broader access in some cases, prompting extensions like Flatseal for hardening; empirical audits show both vulnerable to misconfiguration, with no conclusive superiority in exploit resistance. Performance trade-offs favor for interactive desktops, where benchmarks consistently report Snap's overhead causing 1-3 second delays in app launches, exacerbating issues on resource-constrained hardware. Adoption trends, per distro integration data, show gaining traction in non-Ubuntu environments due to its distro-agnostic design, while Snap benefits from Ubuntu's default integrations but faces resistance elsewhere over perceived dominance. Ultimately, choice depends on priorities: Snap for seamless Canonical-managed deployment, for flexible, community-oriented portability.

Snap versus AppImage and Native Packages

Snap packages differ from and native distribution packages in their packaging philosophy, bundling dependencies within a self-contained filesystem for cross-distro compatibility, whereas s fuse binaries and dependencies into a single executable file without requiring installation, and native packages rely on shared system libraries managed by distro-specific tools like APT or DNF. This bundling in Snap and resolves dependency conflicts but results in larger file sizes—often 2-10 times those of native equivalents—due to included libraries, contrasting native packages' efficiency in reusing system-wide components to minimize disk usage. In terms of installation and portability, AppImages offer the simplest deployment: users , make executable, and run without privileges or registries, enabling instant use across distributions but lacking automatic desktop integration or updates. Snaps require the snapd daemon for installation via Canonical's store, providing centralized discovery and automatic background updates, though this introduces daemon overhead absent in native packages, which install via distro repositories for seamless system integration but demand matching distro versions to avoid breakage. Native packages excel in ecosystem cohesion, leveraging distro-maintained repositories for rapid security patches and minimal setup, but developers face challenges supporting multiple distro variants, unlike the "build once, run anywhere" model of Snap and . Performance benchmarks reveal AppImages startup times closest to native packages, often within milliseconds, as they execute directly without mounting filesystems, while incur 20-50 second first-run delays from mounting and daemon checks, though subsequent launches improve; native apps load fastest overall due to pre-linked system libraries, avoiding bundling overhead. Runtime resource use follows suit: native packages share libraries for lower memory footprint, AppImages add minimal overhead from fused files, and ' sandboxing—enforced via —can elevate CPU and RAM by 10-20% in I/O-bound tasks compared to unsandboxed natives. Security models diverge sharply: Snaps enforce confinement by default, restricting app access to system resources via interfaces, offering isolation superior to native packages' full privileges and AppImage's lack of built-in sandboxing, though AppImages can integrate optional tools like Firejail. Updates amplify these trade-offs—Snaps automate via the store for timely patches without user intervention, AppImages demand manual downloads risking outdated versions, and native packages update through distro cycles, which are reliable but slower for bleeding-edge software. Developers favor Snaps for simplified multi-distro releases despite Canonical's store gatekeeping, AppImages for lightweight distribution without infrastructure, and natives for optimization but with fragmentation burdens.
AspectSnapAppImageNative Packages
Dependency HandlingBundled in Fused into single executableShared system libraries
Startup TimeSlower (mounting overhead)Near-nativeFastest
Disk UsageHigh (bundled libs)Moderate-highLow (shared)
SandboxingBuilt-in ()None by defaultNone
UpdatesAutomatic via storeManualDistro-managed
Distro CompatibilityUniversalUniversalDistro-specific
This table summarizes empirical differences from benchmarks and , highlighting native packages' for integrated environments versus universal formats' portability at a cost.

Broader Impact

Influence on Linux Standards

Snap's introduction of a self-contained, dependency-bundled format using SquashFS archives and AppArmor-based confinement addressed longstanding challenges in Linux , such as version conflicts and distribution-specific dependencies, thereby promoting the viability of universal application deployment across heterogeneous environments. Launched publicly in June 2016, this system enabled developers to target multiple distros with a single package, reducing fragmentation and encouraging a shift from reliance on native repositories like APT or DNF. By integrating automatic updates via a daemon (snapd) and supporting atomic transactions, Snap demonstrated scalable mechanisms for secure, rollback-capable installations, influencing parallel developments in alternative formats. For instance, adopted comparable sandboxing principles—though leveraging kernel namespaces over AppArmor's profiles—to achieve cross-distro portability, reflecting a broader industry response to Snap's emphasis on isolation from host systems. This has advanced universal packaging as a norm, with Snap's model informing features like runtime environments in subsequent tools. Despite these contributions, Snap has not precipitated formal standardization efforts akin to the defunct , partly due to its ecosystem's dependence on Canonical's centralized Snap Store for distribution and assertions. Instead, it has highlighted tensions between control and , prompting distros to enhance support for decentralized alternatives like while experimenting with hybrid models. Canonical's ongoing cross-distribution improvements, announced in January , underscore Snap's role in pushing for greater , though adoption remains uneven, with broader impact manifesting in heightened scrutiny of packaging security and developer workflows rather than unified protocols.

Long-Term Viability and Market Position

Snap maintains a entrenched position within the ecosystem, where has integrated it as the default packaging format for key applications, such as since Ubuntu 22.04 in April 2022, contributing to widespread use among Ubuntu's estimated 40 million desktop users as of 2023 reports. However, its market share beyond Ubuntu remains limited, with adoption primarily confined to Canonical-affiliated distributions and server/IoT deployments rather than broad community endorsement. Long-term viability faces challenges from persistent criticisms of package bloat and infrequent updates, as a 2025 analysis of over 1,000 Snap packages found them averaging 2.5 times larger than equivalent Flatpaks and updated 30% less frequently on average, potentially deterring developers and users prioritizing efficiency. Centralization under Canonical's Snap Store introduces risks, including dependency on a single vendor for distribution and potential service discontinuation, which could render installed Snaps inoperable without alternatives, as noted in community discussions on hardware deployments. While Canonical's ongoing investment in Snap for enterprise and embedded systems bolsters its niche resilience, desktop market trends favor decentralized alternatives like Flatpak, which saw increased endorsements in 2024-2025 surveys and forums for its multi-vendor repository support and faster startup times. Competitive pressures exacerbate viability concerns, with Flatpak's growth outpacing Snap in non-Ubuntu distros like and , where it serves as the preferred universal format due to community governance avoiding proprietary store lock-in. User backlash against Snap's performance overhead, including slower initial launches by up to 10 seconds for some apps, has prompted distros like to remove Snap support entirely in 2024 releases, signaling fragmentation in Linux packaging standards. Canonical's strategy of bundling proprietary elements, such as the store backend, contrasts with 's open model, potentially limiting Snap's appeal amid rising demands for vendor-neutral solutions, though its container-based security features retain value in regulated environments. Overall, Snap's future hinges on Canonical's financial health and Ubuntu's dominance, but without broader ecosystem buy-in, it risks marginalization as consolidates universal packaging leadership by 2025 projections.

References

  1. https://snapcraft.io/about
  2. https://snapcraft.io/docs
  3. https://arxiv.org/html/2507.00786v1
  4. https://maheshpalamuttath.info/index.php/2024/04/26/why-some-linux-users-refuse-to-use-snap-package-manager/
  5. https://brainnoises.com/blog/snap-controversy-linux/
  6. https://forums.linuxmint.com/viewtopic.php?t=345853
  7. https://phoenixnap.com/kb/snap-packages
  8. https://snapcraft.io/blog/snaps-how-we-got-here
  9. https://thenewstack.io/canonicals-snap-great-good-bad-ugly/
  10. https://ubuntu.com/blog/announcing-ubuntu-core-with-snappy-transactional-updates
  11. https://www.phoronix.com/news/MTg1ODM
  12. https://lwn.net/Articles/630660/
  13. https://lists.ubuntu.com/archives/snappy-devel/2015-September/001041.html
  14. https://canonical.com/blog/canonical-unveils-6th-lts-release-of-ubuntu-with-16-04
  15. https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on-multiple-linux-distros/
  16. https://www.neowin.net/news/ubuntu-1604-lts-will-bring-snap-packages-for-up-to-date-apps/
  17. https://www.opensourceforu.com/2016/05/canonical-launches-snapcraft-2-9-tool-ubuntu-16-04-lts/
  18. https://canonical.com/blog/universal-snap-packages-launch-on-multiple-linux-distros
  19. https://news.softpedia.com/news/snap-packages-become-the-universal-binary-format-for-all-gnu-linux-distributions-505241.shtml
  20. https://www.2daygeek.com/snap-became-universal-packages-on-linux/
  21. https://ubuntu.com/about/release-cycle
  22. https://www.omgubuntu.co.uk/2018/03/firefox-snap-package-available
  23. https://www.phoronix.com/news/Snap-vs-Flatpak-2018-Distros
  24. https://canonical.com/blog/experimental-feature-progressive-releases
  25. https://canonical.com/blog/snapcraft-6-0-is-around-the-corner
  26. https://snapcraft.io/docs/release-notes
  27. https://canonical.com/blog/how-to-build-ros-2-eloquent-snaps
  28. https://arstechnica.com/information-technology/2023/05/a-snap-based-containerized-ubuntu-desktop-could-be-offered-in-2024/
  29. https://canonical.com/blog/easy-iot-with-ubuntu-core-and-raspberry-pi
  30. https://canonical.com/blog/canonical-releases-inference-snaps
  31. https://forum.snapcraft.io/t/a-year-of-growth-in-numbers/11151
  32. https://snapcraft.io/docs/the-snap-format
  33. https://documentation.ubuntu.com/snapcraft/latest/how-to/crafting/manage-dependencies/
  34. https://snapcraft.io/docs/content-interface
  35. https://snapcraft.io/docs/snap-confinement
  36. https://snapcraft.io/docs/security-policies
  37. https://snapcraft.io/docs/system-architecture
  38. https://snapcraft.io/docs/interfaces
  39. https://snapcraft.io/docs/managing-updates
  40. https://snapcraft.io/docs/transactional-updates
  41. https://snapcraft.io/docs/channels
  42. https://forum.snapcraft.io/t/snap-revert-reverts-the-snap-revision-but-not-the-tracked-channel/36768
  43. https://snapcraft.io/docs/snapshots
  44. https://documentation.ubuntu.com/snapcraft/stable/reference/project-file/snapcraft-yaml/
  45. https://documentation.ubuntu.com/snapcraft/stable/reference/processes/snap-build-process/
  46. https://snapcraft.io/docs/get-started
  47. https://snapcraft.io/docs/releasing-to-the-snap-store
  48. https://documentation.ubuntu.com/snapcraft/stable/how-to/publishing/publish-a-snap/
  49. https://snapcraft.io/about/publish
  50. https://documentation.ubuntu.com/snapcraft/8.8.0/reference/snap-publishing-process/
  51. https://snapcraft.io/store
  52. https://canonical.com/blog/howto-host-your-own-snap-store
  53. https://documentation.ubuntu.com/dedicated-snap-store/
  54. https://snapcraft.io/blog/how-to-manage-snap-updates
  55. https://snapcraft.io/docs/distro-support
  56. https://snapcraft.io/docs/installing-snapd
  57. https://snapcraft.io/docs/installing-snap-on-linux-mint
  58. https://snapcraft.io/docs/installing-snap-on-red-hat
  59. https://snapcraft.io/docs/installing-snap-on-rocky
  60. https://documentation.ubuntu.com/snapcraft/stable/reference/architectures/
  61. https://forum.snapcraft.io/t/what-are-the-many-platforms-and-environments-that-snaps-can-will-be-used/43678
  62. https://snapcraft.io/blog/snap-usage-metrics-now-available-on-the-command-line
  63. https://snapcraft.io/docs/snapcraft-metrics
  64. https://documentation.ubuntu.com/snapcraft/latest/how-to/publishing/get-snap-metrics/
  65. https://snapcraft.io/blog/snapistics-snaps-in-numbers
  66. https://www.neowin.net/news/canonical-releases-statistics-showing-exceptional-adoption-of-snaps/
  67. https://forum.snapcraft.io/t/statistics-about-snaps-in-snap-store/38991
  68. https://snapcraft.io/
  69. https://canonical.com/blog/star-developers-are-here
  70. https://forum.snapcraft.io/
  71. https://snapcraft.io/blog/i-have-a-need-a-need-for-snap
  72. https://www.phoronix.com/news/Firefox-Snap-50p-Reduction
  73. https://machaddr.substack.com/p/snap-or-flatpak-on-linux-why-you
  74. https://lemmy.kde.social/post/4620380
  75. https://medium.com/@TechHutTV/flatpak-snap-appimage-linux-benchmarks-df2bc874ea0b
  76. https://snapcraft.io/blog/snap-startup-time-improvements
  77. https://documentation.ubuntu.com/snapcraft/8.8.1/reference/snap-publishing-process/
  78. https://forum.snapcraft.io/t/build-and-publishing-example/33078
  79. https://devprogramming.medium.com/why-i-dont-use-canonical-s-snap-4211c35e0d09
  80. https://ubuntuhandbook.org/index.php/2022/11/turn-off-automatic-updates-snap-apps/
  81. https://lwn.net/Articles/981629/
  82. https://linuxtldr.com/canonical-snap/
  83. https://www.reddit.com/r/linux/comments/17s6qyv/canonical_documents_how_to_use_snaps_without_the/
  84. https://forum.snapcraft.io/t/linux-mint-20-disables-deb2snap-packages-and-snaps-growing-external-adoption-problem/17913
  85. https://www.reddit.com/r/linux/comments/1bna66h/terrible_takes_in_the_linux_community_regarding/
  86. https://ubuntu.com/security/notices/USN-6940-1
  87. https://ubuntu.com/security/notices/USN-6125-1
  88. https://www.zdnet.com/article/multiple-vulnerabilities-found-in-snap-confine-function-on-linux-systems/
  89. https://ubuntu.com/security/CVE-2021-44731
  90. https://nvd.nist.gov/vuln/detail/cve-2024-29069
  91. https://nvd.nist.gov/vuln/detail/cve-2024-5138
  92. https://www.aquasec.com/blog/snap-trap-the-hidden-dangers-within-ubuntus-package-suggestion-system/
  93. https://unix.stackexchange.com/questions/493033/what-are-the-dangers-of-using-snaps-classic-confinement
  94. http://ubuntu.com/blog/where-eagles-snap-snap-security-overview
  95. https://merlijn.sebrechts.be/blog/2020-08-02-why-one-snap-store/
  96. https://linuxmint-user-guide.readthedocs.io/en/latest/snap.html
  97. https://forum.snapcraft.io/t/what-happens-if-canonical-decides-to-close-the-snap-store/22820
  98. https://www.zdnet.com/article/why-snap-and-flatpak-make-linux-a-better-os-and-how-theyre-different/
  99. https://itsfoss.com/flatpak-vs-snap/
  100. https://forum.snapcraft.io/t/sandboxing-how-secure-is-it/43792
  101. https://phoenixnap.com/kb/flatpak-vs-snap-vs-appimage
  102. https://www.linuxjournal.com/content/future-linux-software-will-flatpak-and-snap-replace-native-desktop-apps
  103. https://www.baeldung.com/linux/snaps-flatpak-appimage
  104. https://discourse.ubuntu.com/t/snaps-versus-debian-packages/55187
  105. https://www.linuxjournal.com/content/evolution-linux-package-management-and-its-impact-modern-computing
  106. http://www.linux-magazine.com/Online/Features/Universal-Package-Formats-and-How-They-Differ
  107. https://gamingonlinux.com/2024/01/cross-distribution-support-improvements-coming-for-canonicals-snap-packages/
  108. https://canonical.com/blog/infographic-snaps-in-numbers
  109. https://www.reddit.com/r/linux/comments/1hbdfqb/which_one_will_win_in_the_long_term_snap_or/
  110. https://forums.linuxmint.com/viewtopic.php?t=288004
  111. https://www.youtube.com/watch?v=hgup3Z7VpaA
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.