Today I picked this up indirectly. It's a quote from the Arch Linux people.

"
as you install APT updates, Snap becomes a requirement for you to continue to
use Chromium and installs itself behind your back. This breaks one of the major
worries many people had when Snap was announced and a promise from its
developers that it would never replace APT.

A self-installing Snap Store which overwrites part of our APT package base is a
complete NO NO. It’s something we have to stop and it could mean the end of
Chromium updates and access to the snap store in Linux Mint.

A year later, in the Ubuntu 20.04 package base, the Chromium package is indeed
empty and acting, without your consent, as a backdoor by connecting your
computer to the Ubuntu Store. Applications in this store cannot be patched, or
pinned. You can’t audit them, hold them, modify them or even point snap to a
different store. You’ve as much empowerment with this as if you were using
proprietary software, i.e. none. This is in effect similar to a commercial
proprietary solution, but with two major differences: It runs as root, and it
installs itself without asking you.
"

The Arch people have sensibly blocked default action of any package installing
snap. But if you really *really* want to do that manually you still can...
at your own risk of course.

--
Basic

On Wed, 7 Sep 2022 14:21:12 +0100, Folderol wrote:

> Today I picked this up indirectly. It's a quote from the Arch Linux
> people.
>
> "
> as you install APT updates, Snap becomes a requirement for you to
> continue to use Chromium and installs itself behind your back. This
> breaks one of the major worries many people had when Snap was announced
> and a promise from its developers that it would never replace APT.
>
To me this means that you should avoid Chrome like the plague and go back
to Firefox or install something like Brave.

I'm damned if I'll install anything that lets outsiders push updates to my
systems. Apart from anything else I like to synchronise backups and
updates, i.e. take a new backup and then immediately run the system
update, but any 3rd party push regime breaks that association.

--

Martin | martin at
Gregorie | gregorie dot org

On 07.09.2022 at 16:22, Martin Gregorie scribbled:

> On Wed, 7 Sep 2022 14:21:12 +0100, Folderol wrote:
>
> > Today I picked this up indirectly. It's a quote from the Arch Linux
> > people.
> >
> > "
> > as you install APT updates, Snap becomes a requirement for you to
> > continue to use Chromium and installs itself behind your back. This
> > breaks one of the major worries many people had when Snap was
> > announced and a promise from its developers that it would never
> > replace APT.
> To me this means that you should avoid Chrome like the plague and go
> back to Firefox or install something like Brave.
>
> I'm damned if I'll install anything that lets outsiders push updates
> to my systems. Apart from anything else I like to synchronise backups
> and updates, i.e. take a new backup and then immediately run the
> system update, but any 3rd party push regime breaks that association.

Ubuntu has always been the darling of various distro reviewers, and as
such also of the newbies, many of whom never even knew that there were
yet other GNU//Linux distributions due to Canonical's deliberately
refraining from ever mentioning that Ubuntu is indeed a GNU/Linux
distribution, which in turn was due to Mark Shuttleworth's ambition
of seeing himself as the third man on the scaffold next to Bill Gates
and Steve Jobs. Yet, I have never used Ubuntu, and I've never really
understood why people felt it was so great.

I've been using GNU/Linux — exclusively! — for well over two decades
already, and I've used several different distributions, including
Gentoo.

At present time — and for over three years already — I am using
Manjaro [*], which is Arch-based, but unlike Arch, Manjaro is a curated
rolling release. Updates are bundled together and rolled out on
average twice a month, with urgent security updates being pushed out
immediately. In all of that time, I've never needed to reinstall, and
although I have run into a few niggles on occasion, I've never
encountered any showstoppers.

Everyone's 1.6x-kilometerage will vary, and as a moderator at the
Manjaro forum, I am definitely not going to promote Manjaro as a
distribution for newbies — it's more user-friendly than Arch proper but
it's still Arch underneath — but as a 20+-year GNU/Linux veteran, I
consider Manjaro the ideal distribution for myself, and quality-wise
definitely superior to Ubuntu, Mint or whatever Distrowatch's
honey-du-jour is.

Manjaro has its own repositories, but also has access to the AUR, the
Arch User Repository, which contains build scripts for pulling in
user-submitted packages. In addition to that, Manjaro also supports
Snap, FlatPak and AppImage, but none of those are used by default.

The three official editions are XFCE, Plasma and GNOME. Next to that,
there are several community editions, such as MATE, Cinnamon, Budgie,
Deepin, Cutefish, i3 and OpenBox — there might be others yet, but their
availability depends on how much time their respective developer has —
as well as several spins put together by forum members.

Hardware-wise, Manjaro supports x86-64, ARM-64 and RISC-V — 32-bit was
discontinued, but the system supports multilib by default on x86-64.
Kernel-wise, you get a choice among all of the currently still fully
supported LTS kernels (i.e. as of 4.19), any of the still supported
mainline kernels, the current development kernel from upstream, and a
couple of kernels with real-time patches.

So, perhaps it is time for you to switch and join the Manjaruminati? ;)

Remember: Tux is watching you. Tux is ALWAYS watching you. :p

--
With respect,
= Aragorn

Folderol <general@musically.me.uk> writes:
> Today I picked this up indirectly. It's a quote from the Arch Linux people.

It’s from https://blog.linuxmint.com/?p=3906.

--
https://www.greenend.org.uk/rjk/

On Wed, 7 Sep 2022 21:04:42 +0200, Aragorn wrote:

> At present time — and for over three years already — I am using Manjaro
> [*], which is Arch-based, but unlike Arch, Manjaro is a curated rolling
> release. Updates are bundled together and rolled out on average twice a
> month, with urgent security updates being pushed out immediately. In
> all of that time, I've never needed to reinstall, and although I have
> run into a few niggles on occasion, I've never encountered any
> showstoppers.
>
> So, perhaps it is time for you to switch and join the Manjaruminati? ;)
>
Nah. I've been a RedHat user since around 1998, i.e. before Fedora was
hatched and I switched to immediately to XFCE when Gnome 3 plopped,
blancmange-like, on to the scene. I like Fedora's XFCE spin and regard its
slightly less hardboiled state and rapid update rate (and consequent
problem report submissions) as a fair price to pay for having a decent
Operating System available.

> Remember: Tux is watching you. Tux is ALWAYS watching you. :p

:-)

that a helluva lot better than having certain *other* tech entities doing
the spying and pocket picking ...

--

Martin | martin at
Gregorie | gregorie dot org

Folderol <general@musically.me.uk> wrote:
> Today I picked this up indirectly. It's a quote from the Arch Linux people.
>
> " as you install APT updates, Snap becomes a requirement for you to
> continue to use Chromium and installs itself behind your back. This
> breaks one of the major worries many people had when Snap was announced
> and a promise from its developers that it would never replace APT.
>
> A self-installing Snap Store which overwrites part of our APT package base
> is a complete NO NO. It’s something we have to stop and it could mean the
> end of Chromium updates and access to the snap store in Linux Mint.
>
> A year later, in the Ubuntu 20.04 package base, the Chromium package is
> indeed empty and acting, without your consent, as a backdoor by connecting
> your computer to the Ubuntu Store. Applications in this store cannot be
> patched, or pinned. You can’t audit them, hold them, modify them or even
> point snap to a different store. You’ve as much empowerment with this as
> if you were using proprietary software, i.e. none. This is in effect
> similar to a commercial proprietary solution, but with two major
> differences: It runs as root, and it installs itself without asking you.
> "
>
> The Arch people have sensibly blocked default action of any package
> installing snap. But if you really *really* want to do that manually you
> still can... at your own risk of course.

snap makes some kind of sense when there isn't any other plausible option
than staying on the continuous updates train. Chromium is a good example:
there isn't really any LTS for Chromium: to stay current with security
updates you *have* to run the latest version. Similarly Electron apps for
various web services need to keep up with their websites, otherwise they
will eventually break.

The traditional apt packages for such things never really worked out: it was
a lot of work on behalf of the package maintainers just to emulate something
like snap using apt. The advantages described above never really applied -
a new Chromium comes out every 4 weeks so, while you could theoretically
build your own, you'd have to join a constant treadmill of maintaining your
forked version, or else run outdated insecure versions.

snap is essentially a whole other distro - all the files go in /snap, and
each app packages the libraries it needs. So it's fairly easy to separate
off from the rest of your system: it only 'pollutes' insomuch as things from
/snap may end up on your PATH.

OTOH snap is very handy when you want to install an app that is not in your
distro: it's better than digging around for a random PPA. snap has a
protection model that prevents the app from accessing files outside the
sandbox, whereas the random ppa is installed with root privilege and has no
protection.

Flatpak is another take on a similar idea. The one thing snap does right in
comparison to flatpak is the CLI interface. For snap, you run an app via:

$ fooapp

but with Flatpak, it's:

$ flatpak run com.example.FooApp

The latter is unusable, IMHO.
(not least, app names are mixed case and case sensitive)

The points about being bounced into snap by transitional packages are valid,
but the alternative would be losing access to apps.

Theo

On 07/09/2022 20:14, Richard Kettlewell wrote:
> Folderol <general@musically.me.uk> writes:
>> Today I picked this up indirectly. It's a quote from the Arch Linux people.
>
> It’s from https://blog.linuxmint.com/?p=3906.

Which also says:

"First, I’m happy to confirm that Linux Mint 20, like previous Mint
releases will not ship with any snaps or snapd installed. Second, to
address this situation we’ll do exactly what we said we would:

In Linux Mint 20, Chromium won’t be an empty package which installs
snapd behind your back. It will be an empty package which tells you why
it’s empty and tells you where to look to get Chromium yourself.
In Linux Mint 20, APT will forbid snapd from getting installed."

So someone seems to have some sense.

>

--
Mike Scott
Harlow, England

Theo <theom+news@chiark.greenend.org.uk> wrote:
> snap makes some kind of sense when there isn't any other plausible option
> than staying on the continuous updates train. Chromium is a good example:
> there isn't really any LTS for Chromium: to stay current with security
> updates you *have* to run the latest version. Similarly Electron apps for
> various web services need to keep up with their websites, otherwise they
> will eventually break.

It's not always just needing continuous updates, sometimes software has
a lot of very specific dependencies which might be too new or too old
for your install, or dependencies that are incompatible with some other
large & picky software you need to run; thus some kind of self-contained
blob is useful.

I'm still not a big snap fan, though, even if there is a certain
practicality to it.

#Paul

#Paul <news20k.noreply@threeformcow.myzen.co.uk> wrote:
> It's not always just needing continuous updates, sometimes software has
> a lot of very specific dependencies which might be too new or too old
> for your install, or dependencies that are incompatible with some other
> large & picky software you need to run; thus some kind of self-contained
> blob is useful.
>
> I'm still not a big snap fan, though, even if there is a certain
> practicality to it.

I tend to view snaps and flatpaks as the Linux equivalent of mobile apps:
you get a big bundle of software, but the level of integration with the rest
of the distro is minimal. That means there's no worries about having to
align all the versions of .deb packages to have the app work, which takes a
lot of the headache of packaging. This is mostly for GUI apps rather than
system tools, so such apps tend to sit at the top of the dependency tree,
rather than be depended on by many other packages - traditional packaging is
much better for that.

The software is run in a sandbox so certain things are limited. I don't
think quite as limited as a mobile app, but more so that a PPA. I would
still exercise caution in choosing which apps to install.

The main complaint is about the auto-updating feature, and I agree certain
leeway might be useful here. However developers don't want to be dealing
with issues from the version 5 years ago, because that's whatever got baked
into a LTS distro. There is some merit in insisting LTS versions exist but
letting developers not distribution maintainers pick them.

In summary, the way distros maintain packages is good for stability, but
it's a massive work multiplication for developers and the result is that
distros are often stale and missing apps. snap and flatpak aim to simplify
the distribution model to make publishing apps much smoother and more
timely, hopefully resulting in more and better software.

Theo