Snap and modern software (was: Remove /snap directory)

Ralf Mardorf kde.lists at yahoo.com
Wed Dec 14 07:16:45 UTC 2022


On Tue, 2022-12-13 at 23:56 -0600, Keith wrote:
> With the installation of the of snapd and the snapcraft framework, you 
> can theoretically even create, build and publish snaps to the snap store 
> from CentOS, RHEL, OpenSuse, etc. I don't know if there's any of those 
> in the store now, but one goal of containerized applications is the 
> ability to distribute them across distros.

Hi,

this is purely hypothetical and is most unlikely going to happen.

> > Old libraries and programs are a problem, but Snap is not solving that problem.
> 
> Yes, it does.

No, it does not, it adds a bunch of security issues. Actually it's no
problem to provide 1001 old or new different versions of a library by
regular packages. Providing several versions of a shared or not shared
library is seldom done, due to several concerns, including security
concerns. Adding a bunch of security issues, isn't the same as solving a
problem.

>  > If it is the intention of the Snap folks to provide an entire mirror
>  > of the base system in /opt/snap (or wherever it puts artifacts), then
>  > the team may as well provide a Snap Linux distro derived from Ubuntu
>  > that is a rolling release.
> 
> I dunno about rolling release, but containerizing more and more 
> applications is the direction where this is going and not just with Ubuntu.

Please, mention a few distros taking the step in this (wrong) direction.

This approach suffers from countless pitfalls. Even Apple is unable to
get the countless pitfalls under control, hence it results in extra
effort and expense for coders to workaround the pitfalls.

What works quite alright for averaged apps, is a PITA for hi-tech apps.

While Apple provides real-time abilities, Android completely fails in
this domain. I dread to think what an absolutely poorly conceived
concept, such as snap would do to Linux.

Regards,
Ralf



More information about the ubuntu-users mailing list