Another win for snaps

[Robert Heller]

At Sun, 15 Sep 2024 08:22:00 -0400 "Ubuntu user technical support,? not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:

> 
> gene heskett writes:
> 
> > Sam, as a user still struggling to understand AppImage's, snap's etc, where  
> > can I find the definitive description of exactly what each of these  
> > represents?  Something that explains and possibly compares the advantages of  
> > each?
> >
> > ATM i have a bunch of python vpn's, and snap's all over my arm64 stuff cuz  
> > I'm into 3d printing. Then on this intel machine, its AppImages that seem to  
> > have proliferated. The only snap I think is firefox.
> >
> > Thanks for any clarifying links.
> 
> I don't have any links to share, but these things are all alternate  
> variations of the same thing. A native binary has direct dependencies on  
> specific shared libraries. If they don't exist the binary does not run. Also  
> the application will have indirect dependencies as well. It might contain  
> Perl scripts that require specific modules (debs, from what I can tell, only  
> declare dependencies on shared libraries and debhelper does not encode  
> dependencies on individual Perl modules).

Actually, they can and do.  Many Perl modules exist as debs 
(libperl_mod<mumble>-version),  Deb files declare dependencies on other deb 
files (or what deb files declare what they provide).

> 
> snaps, appimage, etc, package the application together with all dependencies  
> that it requires. That's the basic idea. A native firefox package will have  
> dependencies on a large number of shared libraries. They're all bundled into  
> the snap, appimage, etc., and the theory is that you don't need to worry  
> about installing dependencies, they're all in there.
> 

What happens with LTS releases (Ubuntu, Debian, RHEL, etc.) is that the major
versions of libraries are fixed for a period of years. But a lot of
third-party software is built against more bleeding-edge libraries. Also some
software depends on various other modules that most users might not otherwise
have any reason to install. Like Tcl/Tk, various obscure Perl or Python
modules/libraries, etc.

> The differences between snaps, appimages, et. al., lie in secondary  
> properties. They may or may not also end up running the application in  
> various kinds of containers and virtualized environments. Snaps have the  
> snap store. I don't remember if it's appimages, or one of the other  
> alternatives that attempt to minimize the number of duplicate libraries and  
> dependencies from multiple installs.

Right. There are various ways to bundle the dependencies. Tcl/Tk StarKits and
appimages are just virtual file systems. StarKits use an internal feature of
Tcl that implements its own self-contained VFS system. Appimages use FUSE.
Snap uses its own deamon to implement its own sandboxed virtualized
environment or containers and manages dependencies across multiple
applications.  It *might* be fine for some use cases, but can be problematical 
for some users, in that the sandboxing can be intrusive and overly 
restrictive and sometimes snap fails to handle things as gracefully as it 
could/should.

> 
> 

-- 
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller at deepsoft.com       -- Webhosting Services