Good tools are those that help users accomplish something while mostly staying out of their way.
Browsers should be such tools, and there are many of them to choose from.
Sadly however there are effectively only two browser engines available. Those would be the engines behind Google’s Chrome and Mozilla’s Firefox. Name me any fairly mainstream browser and there are overwhelming odds that either one of those engines is powering it.
Due to this fact (and stubborness) I’ve been sticking with Firefox over roughly the last decade and a half. It is free and open source, as well as the underdog in the browser world. It has pretty much every functionality required by me in a browser, as well as having many extensions that I like using.
And on most days it functions pretty well, and does not get in my way.
However there are are times when I absolutely loath using it.
My daily driver is Ubuntu. Yes, Canonical’s distro is another tool that could have a post like this written about, but that is not for this time.
Being a Debian based system, the most promenant ways that Firefox can be installed is either a .deb file (now only available via Mozilla’s PPA as the Firefox-ESR) or a snap package (the only way to get Firefox via the standard repositories). However, installing via either one of these will cause the browser’s updates to be automatic, which when it happens results in the browser becoming unusable and prompting the user with the following when attempting to open up a new tab or browsing to a new url:
Having forced updates to a piece of software as a default setting is not something I am against in theory.
What I am against is the inability of the browser to gracefully handle background upgrades without completely breaking down and requiring a full restart of it self. That is just sloppy design and inexcusable.
Also inexcusable is the fact that the browser it self does not allow a common user to choose the update behaviour that suits them, rather taking control away from the user and making the decision for them. In the case of installing Firefox via a .deb or snap those users with less knowledge of the underlying system have no clear control over when the package is updated:
No amount of internal about:config changes can make a dent in this behaviour.
The sheer amount of posts on forums such as stackoverflow, askubuntu and others asking how to disable this forced update behaviour should be a clear sign to Mozilla that this was a bad design decision from the start.
Flatpak Link to heading
Now I could go the route of installing Firefox via Flatpak which does not exhibit this behaviour.
But I will not.
After thoroughly testing Flatpak for a few months, it became apparent that it is not ’the future of apps on Linux’ as they claim. Needing to download multiple instances of the same multi hundred megabyte packages just to run a few small utility applications?
Edit: It turns out that I had been looking at the individual package sizes for the runtime environments that Flatpak application packages can require an update for, when in fact I should have been watching the resulting runtime size on disk. It turns out that Flatpak uses a technology called OSTree which functions in a similar fashion to Git, except for binary files. Using OSTree Flatpak is able to deduplicate the resulting size of the runtimes that get downloaded, leaving them much smaller on disk. I first became aware of this from Alexander Larsson’s blog post about it (and old one from 2017), and have since read more in Flatpak’s official documenation. And so I stand corrected! Flatpak may just be a future for Linux application packages.
Solution Link to heading
My rant now being out of the way, what would be the solution?
As my tower is undergoing major reconfiguration these days, my previous setup for Firefox got wiped and I had simply forgotten about this behaviour and how the packages were managed via the unattended-upgrades feature. Only when the first instance of forced updates hit me did it jog my memory.
By simply modifying the /etc/apt/apt.conf.d/50unattended-upgrades file, specifically the Unattended-Upgrade::Package-Blacklist block to blacklist Firefox, the obnoxious behaviour can be stopped:
Unattended-Upgrade::Package-Blacklist {
"firefox*";
}
This does however require manual upgrade of the package, which is exactly what I want.
To test the changes, perform a dry run with a debug flag. This will simulate the updates without making any system changes.
sudo unattended-upgrades --dry-run --debug
If for some reason you get an error indicating that you machine is running on battery power (when in fact it is not), just set the following flag in the /etc/apt/apt.conf.d/50unattended-upgrades file:
Unattended-Upgrade::OnlyOnACPower "false"
Conclusion Link to heading
This is all a fairly advanced solution to something that should really be a non-issue, and should surfaced to the user in a much easier way to control.
My plea to you if you make software (any software), please just leave your paternalism out of it. Give the user the power to use your software on their terms.
Because frankly your terms do not matter, and will more likely than not drive users away.