Snaps are good. Forcing it on people is very bad.
4 Likes
You know. The way you put this. Well said!
4 Likes
SNAP-based is geared to “sandboxing” of Apps, purely from a security standpoint.
But they went further to point out “benefits” unrelated to security. They came up with the idea that the nature of SNAPS make them stand-alone, meaning that they can freeze an image and let everyting else change around the Apps, without impacting the Apps, because of the “self-contained” architecture, which creates the bloat which is a negative from a single-User standpoint, but irrelevant from a multi-User Administrator’s viewpoint where one image is shared widely.
So, even for the isolated independant Contractor, if a “frozen” (a.k.a. semi-immutable) App is performing as desired, even if “fenced-in”, that may be the Contractor’s security system ensuring business continuity by shielding those Apps and related processes from unwanted effects from “bad actors”.
As a retired individual, with a career-long exposure to UNIX (then Linux), I don’t feel the need to add the complexity involved from implementing a SNAP-based (or other) sandboxing approach.
So, basically, it comes down to individual preference regarding
-
unifying the approach to Package Management (i.e. just one process for Apt-based Debian packages),
-
ease of implementing system modifications (no need to “tweak” to bypass the SNAP sandboxing gatekeeping configurations), and
-
portability of a unified approach when going from one computer (distro) to the next (already an issue with different package-management systems dependant on the underlying distro, RedHad vs Deb etc.)
The only sane way to look at it all is to say
- Welcome to chaos manor … where YOU control the degree of chaos you are comfortable with!
5 Likes