21.10 - Firefox as snap?

[chimak111]

Ubuntu plans to make the Firefox Snap the default version for new installations of Ubuntu 21.10.

"Per Canonical's distribution agreement with Mozilla, we're making the snap the default installation of firefox on desktop ISOs starting with Ubuntu 21.10."

For now, Ubuntu flavours are not affected by this switch, nor downstream distros like Linux Mint who rely on the repo version. The Firefox deb package will remain available in the repo until the transition takes effect.

[Bings]

No thank you. Glad that you can just download it from the site and run it from an unpacked folder if needs be.

[claydoh]

No thank you. Glad that you can just download it from the site and run it from an unpacked folder if needs be.

What is the real difference, really, in real life?

tbh (without presenting an opinion + or -) despite all the supposed (and potential) downsides, things like Chromium and FF, already essentially self-contained (ie no DE-specific libraries needed), are good use cases for containerization. Browsers are also good candidates for sandboxing.



Y'all are slacking, i expected this topic to show up here yesterday


Now, waiting for the dooom-and-gloom ............

[Fred47]

Some times my Firefox updates on it's own and sometimes I get a update from Discover. Doesn't seem to matter, but I would just prefer one way for all updates. 20.04 LTS

[GreyGeek]

I'm running the latest KDE Neon User Edition, having decided to take a ride on the wild side!
That included keeping snap and anything else that is default in the distro. Just for grins.
Discover is offereing FF 92.0 as either a flatpak or snap install. I took the flatpak install because it was on top.
The mount command shows, among others:

/var/lib/snapd/snaps/core20_1081.snap on /snap/core20/1081 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/obs-studio_1258.snap on /snap/obs-studio/1258 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core18_2128.snap on /snap/core18/2128 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core_11606.snap on /snap/core/11606 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-28-1804_161.snap on /snap/gnome-3-28-1804/161 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gtk-common-themes_1515.snap on /snap/gtk-common-themes/1515 type squashfs (ro,nodev,relatime,x-gdu.hide)

:~$ systemd-analyze
Startup finished in 3.154s (kernel) + 8.074s (userspace) = 11.229s
graphical.target reached after 8.060s in userspace

My boot time has increase only about 5 seconds.
Both the snapd and the flatpak-system-helper daemons are running.
I also installed muon because it is faster and easier to use. I've noticed that some packages show up in Discover but can't be found using muon. I don't know if the reverse is true.

All in all, except for not being able to install EXE's using wine or any of its helper apps, Neon is running great and the Plasma 5.22.5 desktop is awesome! It came down yesterday with a 390 package update.

EDIT: that first quote box kept appearing in this and some previous posts. Attemps to remove it fail.

[Bings]

What is the real difference, really, in real life?

tbh (without presenting an opinion + or -) despite all the supposed (and potential) downsides, things like Chromium and FF, already essentially self-contained (ie no DE-specific libraries needed), are good use cases for containerization. Browsers are also good candidates for sandboxing.



Y'all are slacking, i expected this topic to show up here yesterday


Now, waiting for the dooom-and-gloom ............

I don't use Snap. I tried it and it made lots of "Loopback" drives clutter. Snap devs also admit (it's in the article) that it increases load time so it seems stupid to pointlessly increase the loading time of the most used program on the system. Also, I already use flatpak for other programs and can use that instead of Snap for installing firefox.

[claydoh]

Some times my Firefox updates on it's own and sometimes I get a update from Discover. Doesn't seem to matter, but I would just prefer one way for all updates. 20.04 LTS

Firefox does not update itself, it can't.
However, Ubuntu do install security updates automatically, if there was a bad exploit that was fixable by patching Firefox - without needing a new version - it would be installed automatically, same as all security-specific updates

Discover handles updates for native packages, Flatpaks, Snaps, and even Plasma theming bits and other KDE Store addons.

If you do not like having security updates installed automatically, this can be changed in the Software Sources tool in Discover's Settings section.

[jlittle]

I had to reinstall snapd (after purging it years ago) to run authy (an authenticator app) , which only comes as a snap.

I grudgingly admit that for a security-focused app that syncs across devices a snap makes sense.

The first time run delay, about 8 s, is annoying, is this 2021?

The loop device clutter was one of the reasons I uninstalled snaps back then, but Linux has grown lots of other clutter so I use "findmnt --real" and I've added "-t nosquashfs" to that.

[Beerislife]

Shrug,

I'll just download the tarball from Mozilla and extract it to /opt/firefox

and get on with things. I did the same with Thunderbird with no problems.

If I put it in ~/.opt/firefox it would update itself but it's easy to update it with Krusader...

[SuperSapien64]

I wonder how this will work with Firejail?

[GreyGeek]

I had to reinstall snapd (after purging it years ago) to run authy (an authenticator app) , which only comes as a snap.

I grudgingly admit that for a security-focused app that syncs across devices a snap makes sense.

The first time run delay, about 8 s, is annoying, is this 2021?

The loop device clutter was one of the reasons I uninstalled snaps back then, but Linux has grown lots of other clutter so I use "findmnt --real" and I've added "-t nosquashfs" to that.

On 20.04 I did the same thing with snapd for the same reason. On Neon I decided to play with snap & flatpak and see how thing go.
Snap.service and/or and/or mand.service and/or dev-sda1.device adds a 9 second penalty to my boot time, which used to be 5.6 seconds.

:~$ systemd-analyze blame
9.412s snapd.service
9.374s dev-sda1.device
7.990s man-db.service
6.499s NetworkManager-wait-online.service

but I'm not going to quible about 5 or 10 seconds. It takes me that long to enter my password.

As far as snap and Discover goes, I am unimpressed. Many catagories are empty, and many offerings, like the VM, are incomplete or require manual intervention after being installed. Muon is much better. Flatpak isn't much better. I much prefer AppImages.
So, sometime this week I will probably disable and mask snap and flatpak and see how many apps break and have to be replaced with opens source apps

[claydoh]

I wonder how this will work with Firejail?

There is a much reduced need for firejail - snaps and flatpaks are sandboxed already, with some access restrictions enabled by default, and more, depending on the specific package setup. This is one of the arguments against it, from some. Restricting access to files outside of $HOME is a common one for complaints.

I believe that Snaps use similar tools as those used by firejail for this, plus others, such as [url-https://en.wikipedia.org/wiki/Cgroups]cgroups[/url].

The nerdy bits:
https://ubuntu.com/blog/a-guide-to-s...and-interfaces
https://snapcraft.io/docs/interface-management


https://www.omgubuntu.co.uk/2018/07/...ssions-manager


Permissions on Snaps can be modified from Discover, though probably not on 20.04's version.

[claydoh]

As far as snap and Discover goes, I am unimpressed. Many catagories are empty, and many offerings, like the VM, are incomplete or require manual intervention after being installed. Muon is much better. Flatpak isn't much better.

Discover is not a package manager in any way, and is not intended to be one. I think any GUI software that are missing when searching may be from packages lacking the needed metadata (probably mainly from the unsupported Universe segment of the archives). I know it has improved in Discover itself since Plasma 5.12, though being an old hand I only use it for system updates, firmware updates, and KDE Store addon/theme updates.

[dequire]

...I only use it for system updates, firmware updates, and KDE Store addon/theme updates.

This is truly Discover's greatest asset. I really love the KDE Store integration. For most any other sitch I use QApt package manager, Muon, or pkcon.

[claydoh]

This is truly Discover's greatest asset. I really love the KDE Store integration. For most any other sitch I use QApt package manager, Muon, or pkcon.

Well tbh I have not used and actual package manager in a few years at least. Other than for testing and screenshot purposes.

I don't use pkcon either. Why use a cli tool that uses the native cli tool to do cli things

Sent from my LG V60 using Tapatalk