Portability and security of snaps - Was: Question about Snaps

[Ralf Mardorf]

Hi,

IMO this discussion requires clarification on this mailing list. IMO
users should stay with maintainng a clean Ubuntu/Ubuntu flavour install
from official repositories providing DEBs and perhaps carefully include
third party DEBs, but not focus too much on snaps.

I'm not per se against snaps and competitors, I just doubt that they
are matured and even if they already would be matured, I doubt that
they make much sense for many desktop PC users.

On Sun, 09 Oct 2016 16:15:40 +0200, Oliver Grawert wrote:
>so you think that a consortium handling the direction of snaps made up
>by many distros and upstream projects makes it "an ubuntu thingy" ?

What distros and developers are members of this consortium?

"Ubuntu's Linux 4.4 patchset < http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_4.4.0-21.37.diff.gz >"
as mentioned by the link I already provided by a previous mail,
https://wiki.archlinux.org/index.php/Snapd ,
makes it an Ubuntu thingy, as long as it doesn't make it into the
kernel mainline, https://www.kernel.org/ .

If I google, I only find this news from Ubuntu,
https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on-multiple-linux-distros/ .

"contributors to" and "Snaps now work natively on" are not the same as
an affirmation by those distros. Given that the kernel patch isn't
applied by upstream and at least Arch doesn't apply it for the already
explained reason, that Arch follows upstream and not the policy of
other distributions, even your claims regarding security are doubtful,
already without my counterarguments.

When I tested it, it wasn't easy to build a snap for QjackCtl. Even if
the QjackCtl snap I provided and you corrected should work (I stopped
testing, so never tested this snap), it would include jackd2 and
wouldn't allow to chose between jackd1, jackd2, jackdbus and
interaction between apps that require the jack sound server likely
still is an issue.

If I take a look at upstream providing binaries, IceCat, Rodent, Ardour
and many others, they install to /opt or provide DEBs etc., but I don't
notice a snap. I already read on mailing lists that developers consider
it as too time consuming to build snaps. Unfortunately searching
email's message bodies for "snap" leads to thousands of messages
including "snapshot", so I'm sorry, I can't provide links to mailing
list archives.

For portable devices that anyway can't be used for all domains, e.g.
audio production suffers from not provided real-time on Linux based
portable devices [1], snaps might work. For Linux user space including
all domains, I doubt that snaps are easy to use.

Perhaps one day snaps or a competitor to snaps will become a new
infrastructure for Linux user space, but to claim that they make sense
for desktop PCs at the moment is wrong.

Regards,
Ralf

[1]
An app I'm using on an iPad is available for Android, too, but the
developer confirms that it is not real-time capable on Android devices.
This is an issue for all Linux based attempts for portable devices. The
attitude behind the development for those devices doesn't take all use
cases into account. IMO this is true for snaps, too, not only related
to audio.

">Regarding Android devices I doubt real-time ability at all.
>I'm an audio engineer and Linux real-time audio user and noticed some
>of the Android discussions regarding the architecture and jackd.
>However, it's a long time ago and things might be improved nowadays.

Absolutely right. The situation hasn't improved, unfortunately." -
http://www.xewton.com/musicstudio/forum/viewtopic.php?f=12&t=7223