Ubuntu to Make Firefox Snap Default in 21.10

Condobloke

Well-Known Member
Joined
Apr 30, 2017
Messages
8,180
Reaction score
6,655
Credits
54,576
Ubuntu 21.10 will be released on October 14, 2021

Ubuntu is making snap the default installation of Firefox starting with Ubuntu 21.10


Firefox is currently distributed via the Ubuntu repos as a deb package. If this feature freeze request is granted users who install Ubuntu 21.10 next month will find the official Snap version of the vaunted web browser there, in its place.

Why? Mozilla asked for it apparently:

How does affect the presence of Mozilla/Firefox in Linux Distros ?
 


Here ya go.
 
I am not on *buntu, but I am liking Firefox as a Snap. It let's me use the Firefox Beta while having Firefox current installed from the Debian repos.
firefox 93.0b7-1

firefox:
Installed: 92.0-2
Candidate: 92.0-2

2021-09-21-222036_1920x1080_scrot.png
 
Because Mozilla's been going downhill due to their business practices, I'd love to see LibreWolf get more attention to show people there are worthy alternatives
 
The good people at Linux, decided that for security reasons they would not be implementing 'Snaps'

To be fair, users with a great deal of experience most likely dont fall foul of any security problems related to snaps.

however the greater number of people using Linux do not have that sort of experience, and are accordingly advised to not install snaps.

If anyone here has 'snaps' installed and wishes to be rid of them....

sudo apt autoremove --purge snapd
sudo rm -rf /var/cache/snapd/
sudo apt autoremove --purge snapd gnome-software-plugin-snap
rm -fr ~/snap
sudo apt-mark hold snapd


For the record, I do not have snaps installed.
 
I do not use snaps either - I use Firefox-ESR and added the Mozilla Team PPA
Code:
sudo add-apt-repository ppa:mozillateam/ppa
Code:
sudo apt update
Code:
sudo apt install firefox-esr
 
I am not on *buntu, but I am liking Firefox as a Snap. It let's me use the Firefox Beta while having Firefox current installed from the Debian repos.
firefox 93.0b7-1

firefox:
Installed: 92.0-2
Candidate: 92.0-2

View attachment 10319
Totally off-topic: What icon pack are you using, if you don't mind my asking?

Back on topic, I feel like I'm stuck between a rock and a hard place:
- Chromium = Google = bad.
- Firefox = support censorship (rationale: "protecting users") = fcking detestable
- Vivaldi = some closed + obfuscated code = untrusted
- ungoogled-chromium = unofficial = is it really stable enough?

Fck!

Falkon is about the best "alt-browser", but it ain't super configurable and don't seem to support standard plugins.

Suggestions? At this point FF is the safest IMHO, but I'm pissed at their very pro-left stance when tech is supposed to be neutral.
 
Totally off-topic: What icon pack are you using, if you don't mind my asking?

Back on topic, I feel like I'm stuck between a rock and a hard place:
- Chromium = Google = bad.
- Firefox = support censorship (rationale: "protecting users") = fcking detestable
- Vivaldi = some closed + obfuscated code = untrusted
- ungoogled-chromium = unofficial = is it really stable enough?

Fck!

Falkon is about the best "alt-browser", but it ain't super configurable and don't seem to support standard plugins.

Suggestions? At this point FF is the safest IMHO, but I'm pissed at their very pro-left stance when tech is supposed to be neutral.

Icons: ePapirus-Dark
Falkon hasn't been updated since 2019.
Sadly even Librewolf and Tor browser are based on Mozilla Firefox.
It is pretty much a choice of Firefox or a Chromium based browser.
Firefox is my main even though I can't stand Mozilla's politics. Nothing else matches Firefox's configs and add-ons.

That said I see nothing wrong with using flatpaks or snaps. That said Firefox and all the cruft it pulls in as a snap is the only snap I have installed.
 
Icons: ePapirus-Dark
Falkon hasn't been updated since 2019.
Sadly even Librewolf and Tor browser are based on Mozilla Firefox.
It is pretty much a choice of Firefox or a Chromium based browser.
Firefox is my main even though I can't stand Mozilla's politics. Nothing else matches Firefox's configs and add-ons.

That said I see nothing wrong with using flatpaks or snaps. That said Firefox and all the cruft it pulls in as a snap is the only snap I have installed.

Even though LibreWolf is based on FireFox, I don't mind using it because it's power is out of Mozilla's hands. They even included an anti-telemetry feature, so it can't even phone home to Mozilla's servers (as seen below).
librewolf-021_orig.jpg
 
FWIW, getting FF in Linux is fairly easy; just download the tarball from Mozilla's website https://www.mozilla.org/en-US/firefox/new/ or the beta https://www.mozilla.org/en-US/firefox/channel/desktop/#beta, extract(and optionally integrate it to your system's application launcher menu) and run. That's how I've been doing it for the past couple of years or so, and so far, so good. Also, running FF this way allows you to collect the necessary info when reporting bugs. I also use Chrome/Chromium, and to be honest they both are great browsers, offering some features their competitors do not https://www.howtogeek.com/755957/whats-new-in-chrome-94/ And there are plenty of choices out there:

I've tried all of those above, and actually have Vivaldi and Seamonkey too around in one of my systems. :)
 
Min is a pretty fun browser to toss into the mix:


Normally, minimal browsers kinda suck. This one is actually usable. I've played with it a bit, even leaving it open for a few specific tasks at times. One of these days, I'll get around to reviewing it - probably.
 
Icons: ePapirus-Dark
Thanks, using the Grey version.
It is pretty much a choice of Firefox or a Chromium based browser.
Firefox is my main even though I can't stand Mozilla's politics. Nothing else matches Firefox's configs and add-ons.
I know, it's been some time for Falkon (wow 2019, I must've really lost touch. Anyways, still works, but not really for browsing so I dedicated it to my router login and water/electricity purchase page (yes, we have prepaid water here in RSA). Yep, seems like it's one or the other. Well, unless I find the time to try LibreWolf anytime soon (non-repo = cautious).
That said I see nothing wrong with using flatpaks or snaps. That said Firefox and all the cruft it pulls in as a snap is the only snap I have installed.
My issue with flatpak and such is the security concerns. I prefer to stick with Debian official repos or source builds. I'm not saying the latter is perfect, and I know someone could slip a little unwanted code in, but at least there's pressure on the developers to be careful else their project and rep get shot. Plus some people will audit the code. I'll use appimages at a real push and I use them only from devs I know (have spoken to on forums/IRC/mail/etc.) and are an established brand. Even then, I always run them as an underprivileged second user. I'd apply the same to flatpak if I ever needed something. But none of those go on my production machine. My non-production machine is no big deal coz I can just wipe it and reinstall. I don't keep anything valuable or private on there.
 
Min is a pretty fun browser to toss into the mix:


Normally, minimal browsers kinda suck. This one is actually usable. I've played with it a bit, even leaving it open for a few specific tasks at times. One of these days, I'll get around to reviewing it - probably.
Yes Min is actually pretty nice.
 
In case you are wondering why Ubuntu is moving to snap packages. Here is an answer from AskUbuntu:
Top answer from the link above:
Snap attempts to solve one of the fundamental problems with Linux as a desktop operating system: software availability and software distribution. Snap is not intended to completely replace debs, however. Snaps and Debs work alongside each other.

I am a Linux enthusiast and a project manager of a Linux application. While I love Linux systems as a whole, I can't stand the current state of package distribution. Universal App Formats like Snaps aim to solve this fundamental problem.

In Linux, packages are specifically built for a single version of a single distribution. With a lot of tweaking, it is possible to make one .deb package that runs on all Debian based systems, but this is complicated and limits developers. It's also not practical at times due to version locking of dependencies.

If I create a deb package for Ubuntu 20.04, it will only work on that version. I also have to make a different package for 16.04, 18.04, 20.10 and so on. I already have to make four packages just for Ubuntu. I also need to make one for every Debian version, every Fedora version and every openSUSE version. RPM is more flexible in this regard but the locked dependency issue still gets in the way.

This means if I want to release a new version of my application, I have to create over 20 packages to cover the majority of Linux distributions, and that still won't cover every distro. A second possibility is to wait for distribution maintainers to add your package to the distribution but this usually takes an absurd amount of time. Moreover, then the distribution maintainers decide which version their users get instead of the software developer.

With Snap, a single package runs on every version of every distribution that supports snap. See Installing snapd for a list of many distros that support it.

Additionally, with Snap, the developer publishes and maintains the package, instead of the distribution maintainer. So I as a developer can release new a version to all my users without having to wait on anyone else.

Essentially, everything I hate about Linux package distribution is solved by Snap. Though it's important to note that these core issues are also being solved by Flatpaks & to a degree by AppImages. The discussion for which format is better is highly debated and a much longer conversation than makes sense for this reply. For now, I will say that I am fine with running any of the universal formats since they all work differently and thus do not conflict with each other making it possible to run all 3 and traditional packages at the same time.

TL;DR

Linux package distribution is awful for both developers and users. Snaps, Flatpaks & AppImages are intended to solve this fundamental problem with Linux based systems.

This question is really about why the move but if anyone is interested in learning more about what Snaps are and how they work. I created this video to explain the structure in-depth.



Snap software is also more secure because it is sanboxed:
Snaps are self-contained applications running in a sandbox with mediated access to the host system. - Source: Wikipedia.

How Sandboxes Are Essential For Security - Source How To Geek:
A sandbox is a tightly controlled environment where programs can be run. Sandboxes restrict what a piece of code can do, giving it just as many permissions as it needs without adding additional permissions that could be abused.
For example, your web browser essentially runs web pages you visit in a sandbox. They’re restricted to running in your browser and accessing a limited set of resources — they can’t view your webcam without permission or read your computer’s local files. If websites you visit weren’t sandboxed and isolated from the rest of your system, visiting a malicious website would be as bad as installing a virus.
 
Last edited:
Snaps also add their own service/daemon; snapd, which runs at boot. Snaps consume a fair amount of disk space, so do flatpaks. Both add a bunch of files scattered across the system. You have to learn and remember a new set of commands, which are fairly easy, but still. This is why I don't use any of them, I prefer appimages; 1 pkg = 1 app. No need to install anything, thus no need to remove anything, just the pkg and that's it, it's gone out of your system for good. Appimages are also easier to manage, since you can extract, inspect and even modify their contents.
 
I totes agree. As I said before, I prefer appimages if I absolutely have to use things off the edge of the map. Years back, Snap and Flatpak had an appeal, but AppImages, IMHO, are the future. In today's world, storage ain't an issue, so a 79MB AppImage is nothing. Basically also mounts a virtual FS, the difference being it's unmanaged. It's much easier, from my experience to sandbox/jail cozza this. All the advantages that apply to Snap and Flatpak apply to AppImage. Of course nothing's perfect, but at least I don't need extra daemons and a package manager. And conflict is virtually impossible (there's one case I can think of). They provide better per-user isolation, too. Example: If download A1.0 & A1.3 and I want A1.0 to be system-wide but A1.3 to be just for me and "select users":
- I shove both A's in /opt/<provider>/ (old fashioned, there's a reason though).
- I softlink A1.0 as /usr/local/bin/A so it is A by default.
- I softlink A1.3 to all select users' ~/bin/A-current (whether ~/bin is in their PATH is up to them). Still working on smoothing the naming out.
And I have this great system.
Now for the security-conscious like myself, I never make AppImages executable system-wide. I put links to ~/bin (I used to use ~/apps to be cool) and I don't include this in my PATH. So I have to invoke them by their path.
So, yeah, for me AppImages are the future: Download, +x, use.

In a perfect world, all distros would just change to PKGBUILDs but that's not going to happen cozza the work involved for non-Arch distros.

I agree that a universal package system should be in place, but I don't think distro-specific versions should be lost or even superseded. I don't want a "Winux" OS. I don't want upstream pushes to become more popular than stable repo packages to the point where a distro doesn't have distro-specific. There's a reason I run Debian "stable" on my production machines. I think if Snap/Flat/App became too much of a norm over traditional packages, it would be a problem. That package maintainer layer provides extra peace-of-mind. I know upstream devs wanna just push the latest and greatest, but I think AppImages are best for this because they're simpler.
 
I totes agree. As I said before, I prefer appimages if I absolutely have to use things off the edge of the map. Years back, Snap and Flatpak had an appeal, but AppImages, IMHO, are the future.
I recently had issues with one specific package from the AUR so I chose to use a Flatpak for that specific package instead of an AppImage. Because with Flatpaks you can manage your Flatpaks from the command-line and don't have to manually download it and place it somewhere. I looked around for a while and haven't come across any tool that allows you to manage AppImages from the command-line. Also having to download each AppImage application from the developers own website reminds of having to do the same for Windows but instead with exe/msi installers. Lastly having to manually download and manage software isn't very Linux like working when it comes to managing software. So until there is a command-line tool for managing AppImages I won't be trying them and I can't consider them to be an alternative source for running software on Linux.
 
I agree with a lot of what you're saying, hence my "Winux" remark in the previous post. Ideally, all distros would have PKGBUILD compat. But they don't, so we're stuck. Then there are devs who may include closed stuff, too. AppImages are not too different from Flatpaks in terms of getting stuff straight from devs. And they don't* carry stronger risks than Flatpaks, Snaps, and PPAs because they can be isolated. You never will have to manage them from the CLI like regular packages because they are not, strictly speaking, packages. They don't install anything. They just run (by making them executable or executing them via a shell/command). And they are not system-wide if you don't make them. As I said, I will avoid alien/closed software at all costs, but if I have to, I can't find a good reason other than philosophy not to use AppImages. Obviously one broke for you, but even official packages sometimes do.

Still, each to their own. It's more a question of philosophy, as I said. Really, no matter what, we're bringing alien stuff into our OS. And like stealing 40 cakes, that's terrible, lol.
*Edit: "don't" -- touch screen typing
 
Last edited:
I looked around for a while and haven't come across any tool that allows you to manage AppImages from the command-line.
I haven't used it, but there's this https://github.com/AppImageCrafters/appimage-cli-tool
Search, install, update and remove AppImage from the comfort of your CLI.
Features:
  • Search/Install from the appimagehub.com catalog
  • Install from github.com
  • Update using the appimage-update
  • Manage your local AppImage collection

Lastly having to manually download and manage software isn't very Linux like working when it comes to managing software.
Didn't people use to do that before package managers existed? Download and manage(compile) software?

EDIT: There's a .deb pkg, I just downloaded it:
Code:
dpkg-deb -c appimage-cli-tool_0.1.4-1_amd64.deb  
drwxr-xr-x root/root         0 2021-02-11 19:11 ./
drwxr-xr-x root/root 0 2021-02-11 19:11 ./usr/
drwxr-xr-x root/root 0 2021-02-11 19:11 ./usr/local/
drwxr-xr-x root/root 0 2021-02-11 19:11 ./usr/local/bin/
-rwxr-xr-x root/root 35820736 2021-02-11 19:11 ./usr/local/bin/app
drwxr-xr-x root/root 0 2021-02-11 19:11 ./usr/share/
drwxr-xr-x root/root 0 2021-02-11 19:11 ./usr/share/doc/
drwxr-xr-x root/root 0 2021-02-11 19:11 ./usr/share/doc/appimage-cli-tool/
-rw-rw-rw- root/root 1074 2021-02-11 18:25 ./usr/share/doc/appimage-cli-tool/LICENSE
-rw-rw-rw- root/root 986 2021-02-11 18:38 ./usr/share/doc/appimage-cli-tool/README.md
and
Code:
dpkg-deb -I appimage-cli-tool_0.1.4-1_amd64.deb  
paquete Debian nuevo, versión 2.0.
tamaño 35068216 bytes: archivo de control= 384 bytes.
0 bytes, 0 líneas conffiles
238 bytes, 9 líneas control
Package: appimage-cli-tool
Priority: extra
Section: checkinstall
Installed-Size: 35024
Maintainer: [email protected]
Architecture: amd64
Version: 0.1.4-1
Provides: appimage-cli-tool
Description: Package created with checkinstall 1.6.2

EDIT2: Ok, just installed it and tried to get an app with it, have no idea how since it keeps telling me
Code:
appimage-cli-tool: error: invalid target format
Maybe I'm doing it wrong, however, this should be easier to manage, or at least provide good help, because
Code:
app install --help          
Usage: appimage-cli-tool install <target>

Install an application.

Arguments:
<target> Installation target.

Flags:
-h, --help Show context-sensitive help.
--debug Enable debug mode.
It is not really useful at all. So, don't know, I wouldn't recommend it, but if you want to try ...
 
Last edited:
Who needs Snaps or PPAs?

Ubuntuzilla works, so you always have the latest versions of Firefox, Firefox-ESR, Thunderbird or Seamonkey.

"This repository should work on any APT-based distribution, including Ubuntu descendants, and Debian descendants. The project was born on Ubuntu forums, but despite the name is not really specific to Ubuntu."

It has its own Repository.

 

Members online


Latest posts

Top