Question about Snaps

[Ralf Mardorf]

On Sun, 09 Oct 2016 14:40:32 +0200, Oliver Grawert wrote:
>On So, 2016-10-09 at 05:43 +0200, Ralf Mardorf wrote: 
>> > except that the handfull of the bigger desktop apps on linux do
>> > exactly this today already, firefox, thunderbird, chrome/chromium,
>> > skype, steam all build, link and ship their complete set of
>> > depending libs today inside their deb, libreoffice does this
>> > partially ...   
>> 
>> And especially those apps are very often listed as being
>> vulnerable.  
>
>and so you prefer to run them with full access to your system, all your
>data and files, instead of having a restricted snap where only you as
>the user can control which data they access on your system through the
>interfaces you allow ?

In my email headers you usually will read

X-Mailer: Claws Mail 3.14.0-2-ge48b73
(GTK+ 2.24.30;x86_64-ubuntustudio-linux-gnu)

or

Claws Mail 3.14.0-2-ge48b739
(GTK+ 2.24.31; x86_64-arch-linux-gnu)

resp. another version of this MUA, very seldom you'll read that I use
another MUA. Sometimes I indeed use a heavy weight MUA, but it's not
Thunderbird, it's Evolution and I'm not using Evolution on an Ubuntu
install.

>[1] appstream, Arch, debian, elementary, KDE, Ubuntu, VLC, Fedora

I'm to lazy to provide the Arch general mailing list related discussion
about something similar to snaps, that is much more welcome than snap
is, but anyway will never become the way Arch will go, instead I'll
quote the Arch Wiki:

"Warning: snap-confine is built with the --disable-apparmor option;
full confinement relies on an AppArmor enabled kernel with Ubuntu's
Linux 4.4 patchset applied and a related profile for the snap." -
https://wiki.archlinux.org/index.php/Snapd

"Reasons for not being a feature
    [...]A package which does not use Fedora, Ubuntu or some other
    community patch. Patches should be submitted upstream." -
https://wiki.archlinux.org/index.php/Reporting_bug_guidelines#Reasons_for_not_being_a_feature

It's easy to build a patched kernel and to build snap-confine with
apparmor enabled, due to ABS,
https://wiki.archlinux.org/index.php/Arch_Build_System#What_is_the_Arch_Build_System.3F ,
but no, never ever it will be a way Arch will go and there are not many
developers using snaps either. The claim Arch does use snaps is wrong,
it's just supported in the sense that it's available.

In the Linux universe a lot of software is available by binary packages
that install to /opt/, e.g. IceCat, Rodent and especially software for
niece domains such as pro-audio. Binaries that install to /opt/ are
much more wide spread and even PPAs for Ubuntu are much more wide
spread, than snaps ever will be for desktop computers. Many coders are
simply not interested in wasting time to learn how to build complicated
snaps. Ubuntu might go this way, but using snaps with different
versions of libraries has nothing to do with a rolling release
approach. A rolling release does use the most current stable version of
a library, that was released by upstream and not several older
versions, too. A rolling release only could stay stable, if it does use
stable releases from upstream, since a patch could make such a release
from upstream already unstable. Rolling releases and even release model
distros often suffer from instability because they don't follow
strictly upstream. Sure, there are a few exceptions when patches make
sense and are even applied by Arch maintainers.

On Sun, 09 Oct 2016 14:50:32 +0200, Oliver Grawert wrote:
>so you say that when an app has a huge amount of users it does need
>less attention to vulnerabilities in the bundled libs ?
>thats a weird statement to make.

This is a misinterpretation. However, it becomes much to off-topic and
time consuming to continue this discussion. Everybody is free to use
snaps. I'll only point out that most likely snaps aren't the way much
Linux distros will go. It's an Ubuntu thingy and much likely with
portable devices in mind and not the Linux desktop PC user.

Regards,
Ralf