Video summary

Replacing Native Apps With Snaps And Flatpaks? (Don't Do It!)

Main summary

Key takeaways

Technology

Tech/Product Concepts Covered

  • Containerized “non-native” app packaging formats: snaps, Flatpaks, and AppImages
    • Described as distro-agnostic and sandboxed.
  • Native packaging approach: Arch-native packages via Pacman plus a small number of AUR packages.

Experiment / Setup (3-month test)

  • The speaker performed a fresh Arch Linux installation on a workstation:
    • Wiped existing Arch, then installed “Cashew OS” with Qtile.
  • Added Niri (Wayland compositor) while keeping the system minimal:
    • Only Qtile and Niri as window managers.
    • Minimal additional software to test whether this improves stability/reliability.
  • Packaging rule:
    • Install only native Arch packages.
    • No snaps, Flatpaks, or AppImages, except one required AppImage that’s only available that way.
  • Package counts:
    • ~1,500 packages installed via Pacman
    • ~12 packages from AUR (small subset)
    • Example AUR items mentioned:
      • DMS Shell (“Dank Material Shell”) used on top of Neofetch
      • Some fonts installed from AUR (claimed not to affect runtime stability much)

Key Findings / Analysis

  • Performance:
    • Native packages launch faster than the “same” apps packaged as snaps/Flatpaks/AppImages.
    • The difference is described as noticeable when compared side-by-side.
  • Theming / visual integration:
    • Native packages better respect global system theming.
    • Sandbox/container formats may appear “alien/foreign” and may not integrate cleanly with the desktop’s look and feel.
  • Sandbox limitations / missing functionality:
    • Sandboxed formats can restrict access to hardware, and files/directories, causing missing features.
    • They may also ignore standard config file locations, leading to weird or inconsistent behavior.
  • Operational convenience:
    • Native packages simplify updates to one command:
      • sudo pacman -Syu
    • This avoids managing separate update workflows:
      • snaps (snap update)
      • Flatpaks (flatpak update)
      • AppImages (some auto-update; others require manual downloads of new versions)
  • Trust / provenance:
    • Arch repo packages are built/maintained for the distro, so the speaker argues they’re optimized and therefore more trustworthy.
    • For snaps/Flatpaks/AppImages, builder/distro assumptions are less clear, and may not be optimized for a specific distro.
    • Overall emphasis is on reliability and reduced risk from less-curated third-party packaging.

Conclusion: The speaker believes pure native packaging provides a more stable, consistent, and reliable Linux desktop experience, though they’re not ruling out using some non-native formats later.

Guides / Review / Tutorial Elements

  • Framed as a real-world experiment (“don’t do it” style evaluation) comparing results after switching to native-only packaging, with one AppImage exception.

Main Speaker / Source

  • Main speaker: the video’s creator (no external sources cited).

Original video