You must ship an internal Linux application to machines running several different distributions. How do a traditional distribution package (.deb/.rpm) and a bundled sandboxed format such as Snap or Flatpak differ as delivery models, and how would you decide between them?

## The real axis: who owns the libraries Everything else follows from this. A traditional distribution package declares dependencies on the distribution's own libraries and links against them at runtime. A bundled format carries its dependencies with it. That single difference propagates into security, size, update cadence, testing burden and operations. ## The traditional model Strengths: - **Someone else patches your dependencies.** When a critical vulnerability lands in a common TLS library, the distribution ships a fixed library package and every application on the host that links it is fixed at once. Your application does not need a rebuild or a release. - **Small artifacts and shared memory.** One copy of each library, shared across processes. - **Native integration.** Files land where the platform expects them, configuration lives in `/etc` where configuration management already operates, the init system supervises the service, and the host's inventory can answer "what version is installed?" through the same query used for everything else. - **One update path.** The machine's normal patch process covers your software too, including the change-control and maintenance-window discipline built around it. Costs: - **A matrix, not an artifact.** Each distribution family and each supported release is a separate build and test target, because the available library versions differ. - **Version constraints imposed on you.** If a release ships an older runtime than your application needs, you either vendor it anyway or drop support. - **Install-time privilege.** Maintainer scripts run as root by design, which is power but also a supply-chain surface. ## The bundled and confined model **Snap** distributes an application as a compressed filesystem image; installed revisions are mounted read-only rather than unpacked, so a host's mount list grows with the number of installed snaps. Its confinement mediates access to host resources through *interfaces* that must be connected before the application can use them, and it supports background services, so it is usable for daemons as well as desktop applications. Updates flow through channels from a store, and the daemon refreshes installed snaps automatically unless refreshes are held — behaviour that is convenient on a laptop and genuinely surprising on a server you thought was frozen. The ecosystem is designed around one default store operated by a single vendor, which matters for air-gapped or self-hosted distribution. **Flatpak** separates applications from *runtimes*: a shared base such as `org.freedesktop.Platform`, `org.gnome.Platform` or `org.kde.Platform` provides the common libraries that many applications build against, so bundling is partial rather than total and the runtime can be updated independently. Applications execute inside a sandbox built with bubblewrap, and access to the host — files, devices, the session — is either granted through declared permissions or mediated at runtime by portals, with per-application overrides available to the administrator. Repositories are content-addressed and de-duplicate shared objects between applications and revisions. Flatpak is squarely desktop-oriented: it assumes a graphical session and portal infrastructure, which makes it a poor fit for headless servers. **AppImage** sits at the extreme: a single executable file bundling everything, with no sandbox and no built-in update mechanism. Excellent for handing someone a build to try; a poor basis for a managed fleet. ## What you inherit when you bundle The security trade is the one senior candidates must name explicitly. Bundling moves CVE response from the distribution to you. When a vulnerability lands in a library you bundled, *you* must rebuild, re-release and get every installation to refresh — and the host's vulnerability scanner may not even see inside your bundle, so the exposure can be invisible to the people responsible for patching. Confinement partially compensates by limiting what a compromised application can reach, but confinement and patching defend against different things; one is not a substitute for the other. There is also an inventory question. "Which hosts run version X" is trivially answerable for distribution packages and needs separate tooling for bundled formats. ## How to decide Ask, in order: 1. **Is it a headless service or a desktop application?** Headless services belong in a distribution package published to an internal repository — or, if the platform is already container-based, in an image, which is the same bundling trade-off with better-established server tooling. Desktop applications across mixed distributions are exactly what Flatpak was built for. 2. **Who will patch the libraries?** If you have no team that can respond to a library CVE within your SLA, do not bundle. 3. **Do the hosts allow updates you do not control?** Automatic refreshes from a vendor store are disqualifying in many regulated or air-gapped environments; a frozen internal repository snapshot is the opposite discipline. 4. **Do you need an isolation boundary?** If the application must be confined from the rest of the machine, a sandboxed format gives you that with declared permissions — but check that the confinement survives the access your application genuinely needs, or you will end up granting broad host access and keeping only the costs. 5. **What does the audit story look like?** Whichever model you pick must be able to answer, fleet-wide, what version is installed and whether it is vulnerable. The honest summary is that bundling buys portability and isolation with maintenance ownership. That is a good trade for a desktop application shipped to unknown distributions, and usually a bad one for a server daemon on a fleet you already patch centrally.