In the past when I've installed Firefox through a .deb, it has had this annoying habit of requiring me to restart my browser whenever it updates in the background. I'll be going about my day and all of the sudden every URL will redirect me to about:restartrequired [0] and I'll have to shut everything down to keep going.
It's not clear from this announcement if they've fixed that or not. If they haven't, I'll probably just continue to install Firefox from the .tar.gz files they provide [1]. If you drop them in a directory you have write permissions to, Firefox can auto-update itself the same way it does on Windows, without any forced interruptions.
[0] https://otechworld.com/wp-content/uploads/2022/04/restart-fi...
[1] https://support.mozilla.org/en-US/kb/install-firefox-linux#w...
> Following community discussions, we have updated the post to highlight that Firefox can continue browsing after an APT upgrade, allowing people to restart at their convenience.
[1]: https://blog.nightly.mozilla.org/2023/10/30/introducing-mozi...
The restart notice provides a way for Firefox to signal to the user that the binary on disk doesn't match the binary running. Without the warning Firefox used to randomly crash when creating new processes. The warning allows the user to perform an orderly restart (not great but neither are crashes).
As the parent states the tar.gz will avoid the problem as it uses Mozilla's update process that is used across platform. A minimum set of steps to use the tar.gz are
* Extract tar.gz to somewhere like /opt/firefox/
* Set the permissions so that the user or a group can read, write and execute /opt/firefox/
* Create or copy a Firefox.desktop file [1] and place it in the correct folder [2] so it shows up in your launcher
[1] https://specifications.freedesktop.org/desktop-entry-spec/de... [2] https://specifications.freedesktop.org/menu-spec/latest/ar01...
As a welcome coincidence I checked the version right now and the Help, About Firefox dialog showed me an updating status. There is a updates/0/update.status file in Firefox directory that had the "downloading" content. It's "applied" now. The update.version file contains "122.0" and there is a 20 MB file names "update.mar". The file "last-update.log" contains many "PREPARE PATCH", "EXECUTE PATCH", "FINISHED PATCH" lines on shared libraries file and other files. Apparently the new version is waiting in the updated/ directory.
The About dialog still reports 121.0.1 and has a "Restart to update Firefox" button. I'll wait to see what happens and how long I can keep using the current version before having to switch to the new one.
That might have been the case. I almost invariably open every link in a new tab, so for my use case it would have felt the same as nothing working.
The flatpak build avoids this problem by keeping both versions on the disk, up until you stop the app. Only at this time, the old version is removed, and the next start will be the new version.
This is the key point. I'm assuming that it downloads the update and then waits for me to agree to install it, but however it works it doesn't interrupt my browsing while I'm in the middle of something.
You're mixing up two problems here. There's "please restart to update" that you can ignore/postpone, and there's "I have already updated and now going to sites is mostly broken" that you can't.
I hated the required restart with a passion when they first started it because restoring the previous session often failed. Once that worked, it was merely miserable (you still have to log in to all your sites).
Maybe I didn't use the .deb files and just used the .tar.gz. I could see that. I know I used .deb files for Chrome but I can't recall for Firefox, now that I'm thinking about it maybe I did just use the .tar.gz. I remember having to create and edit .desktop files for it. Seems counterintuitive to have a better update experience through a manually managed .tar.gz unzipped directory than through a package file actually meant to be managed through a more formal package manager.
This happens because Firefox detects that its files have changed underneath it while its running—this can cause problems due to, I guess, the multi-process architecture and sandboxing not liking mismatches between what is running and what it might start. The built-in updater performs updates in a way that doesn’t cause this. Package managers that do not update Firefox in-place (e.g. Nix) do not have this problem either.
As noted in a sibling comment, this new package does not seem to have the issue either. I wonder what they changed.
So reliably that from time to time, when I want to restart for some reason, I'm killing it with all 9es from some already running htop.
Klicking the icon. Yah yah yadda yarr yarr, all new, no I don't wanna sync, no tour, FO! (meanwhile disabled all that shit)
Every tab there as it was before.
I argued that this was a positive reason for snap (updating the image behind the scenes and only getting the new version when you restart). However, snap designers (in my not so humble opinion) missed the boat (to put it politely), as one can only upgrade a snap image when the application is not running. So one has to exit, update, wait, restart. This is missing one of the primary benefits of container based delivery for desktop applications.
Ubuntu, if you're listening: fuck Snap. I'm never going to use it. I stripped from all my Ubuntu machines. If you try and force it upon me, I'm moving to Debian, no matter how much hurt that causes me.
So all in all, not much of a hurt, for me at least. My home server integrations, my software and my games work just as well.
I was also going to mention ufw, but I see Debian ported it, so that's one less concern!
What do you dislike so much about snap? Also any tips on how one goes about purging it from their machine if they too also decide they don't like it?
The good: Snap packages run on almost any Linux distribution, so they're an easier target. Distribution specific packaging can be tedious, and often involves a distro having to maintain packages themselves by repackaging the "upstream" package or software. With software that updates frequently, snaps theoretically mean a lot less work for distro package maintainers, because one package works on every distro. Snap packages are also sandboxed and have less access to the host system.
The bad: In practice, they don't work very well. Snap programs are slow to start up. Because of their sandboxing and universal nature, their integration into the distribution can be lacking.
For example, when I upgraded to Ubuntu 22.04, I was automatically moved to Firefox snap. It is painfully slow to start. Instead of the normal Ubuntu file browser when I went to upload or save a file, it uses a jarringly different file browser. I switched back to using the firefox PPA, and now this new package directly from firefox.
I also moved to the Slack snap, which also works terribly. I apparently can't upload and download files from it reliably, so I have to open it in my browser to do so. There appears to still be an official deb package, but they've hidden it on their site because they want you to use the snap.
Snap started as a method of packaging applications for servers, and that's still where they're most useful. Slow startup time and issues with desktop integration are not concerns for server side snap packages. For desktop graphical applications, Flatpak will likely be a much more useful universal package system.
You'll have crap in your mounts list, process list, home folder, etc. As a reward for putting up with all that you'll have slower to start applications!
PPA, flatpack, and even "make install" are much more polite when you need a newer version of something, with good performance.
I recommend Mint these days. Easier than decluttering Ubuntu after every install.
Sadly Mozilla still doesn't offer `aarch64-linux` builds for Firefox in their official channels, so for those that have a ARM64 Chromebook will still need to use something else to get Firefox running (I use Nix, but it needs some complicated setup to work with hardware acceleration, for example, using nixGL).
So just target Debian 11 and 12 arm64. If you compile on an older version of Debian it should work fine too.
This just chucks firefox in /usr/local but its straightforward to edit and use ~/, opt, etc., just make sure the created symlink is somewhere in $PATH. Desktop integration will depend on your DE/WM, but should be pretty simple to figure out if not automatic.
wget -O firefox-latest.tar.bz2 \
"https://download.mozilla.org/?product=firefox-latest-ssl&os=linux64&lang=en-US"
tar xjf firefox-latest.tar.bz2
sudo rm -rf firefox-latest.tar.bz2 /usr/local/bin/firefox /usr/local/firefox
sudo mv firefox/ /usr/local/
sudo ln -s /usr/local/firefox/firefox /usr/local/bin/firefoxKudos to open source maintainers, the hidden heroes who make your life easier while expecting nothing in return.
I try to use Fedora whenever possible so have noticed that Debian tends to be the first choice, even for "client" type software, which makes sense considering the popularity and cross compatibility of Ubuntu+Debian.
(You can generally still get stuff on Fedora - they do their own Firefox package of course, Signal is a flatpak, etc)
I don't know about present, but in the past their .deb packages were updated later than the snap ones.
The only thing missing is a continued commitment to privacy and liberty.
What has changed since the infamous “We Need More Deplatforming (2021)”[1] article by CEO Mitchell Baker? I absolutely can not move past this and I think Mozilla needs to make a strong commitment to our civil rights.
1. https://blog.mozilla.org/en/mozilla/we-need-more-than-deplat...
That seems a misquote; the title of the article you link is "We need more than deplatforming", and it isn't apparent to me that it advocates for deplatforming at all.
Allows you to
sudo apt-get purge snapd
I personally don't see a good reason to opt out of security changes for any longer than strictly necessary and that's exactly what you do when using ESR. First they get backported by Mozilla. That's after normal users receive them. This takes time. Then testing takes place because they don't want to push out a hasty fix for ESR. This takes more time. And then third party packagers need to pick up the changes and repackage (which is mostly pointless and adds more time). And then eventually it rolls out days/weeks/months after normal users have long received the patches. I don't seen any good reason for such lengthy delays for normal users. In some big companies where they manually review updates for workstations it's a compromise between the extra work and stability. But the tradeoff is timely access to security fixes; which ESR simply doesn't provide.
Note, the "normal users" you describe are involuntary testers who got forced into the role because keeping testers on the payroll is so last century.
As for Debian's standard response to using non-Debian packages, they have the following wiki entry:
Most companies don't prioritize legacy support, so there is no point in developing for Firefox ESR.
On the other hand, the more legacy you support, the larger your potential customer base is. Also, if everyone else in the sector only supports the most recent release of only two browsers, you might have that extended customer base all to yourself.
> you would better develop your app using the latest dev tools and targeting the latest web specifications only.
That is one school of thought.
Another is that you should regularly use the oldest platform (hardware, OS, browser) that you want to support. That way you won't get to two weeks before release, decide you ought to test on a dual-core 4Gb machine like you were planning on supporting, and realise that although it technically runs, it's so frustratingly slow that no-one would want to, but there's not enough time to make the changes you'd need to get it working "acceptably". OTOH, if you were using it on hardware where it ran like a dog for you from the 3rd sprint, you'd probably have got round to making the changes for it to be acceptable on that era platform.
This way, I get the official Firefox package without Mint adding their own stuff on top of it, I get the official Firefox icon and not Mint's icon theme variation of it, I don't need to edit keyring files or import GPG keys, and it updates automatically without forcing me to restart the browser.
[1] https://github.com/sandov/sc/blob/master/install_scripts/fir...
My only wish would be that they finally propose official Linux/aarch64 builds, for example for Asahi Linux.
I didn't see those builds on your link, only android/windows/osx aarch64 builds, what am I missing ?
Ubuntu likes to replace installed debs with snaps without consulting the user and you need to configure it not to do so.
And the profile folder for the snap is in a different place than for the deb, so make a copy of it etc.
I'm not going into full detail as these things are easily found via Google as long as you're aware of them.
Step 5: Set the Firefox package priority to ensure Mozilla’s Deb version is always preferred. If you don’t do this the Ubuntu transition package could replace it, reinstalling the Firefox Snap:
This happened to me and it wasn't as part of a dist upgrade.
I don't see what the point of this is.
Processing indexes: [PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPapt-mirror: can't open index packages.mozilla.org/apt//dists/mozilla/main/binary-amd64/Packages in process_index at /usr/bin/apt-mirror line 891.
deb https://packages.mozilla.org/apt mozilla main
clean https://packages.mozilla.org
Tempted to switch (maybe I can remove my system’s Snap infection), but redoing bookmarks and extensions (and getting my ublock config and OneTab bookmarks) is a pain. And I’ll have to figure out how to not lose my passwords this time.
What a pain.
~/snap/firefox/common/.mozilla/firefox
~/.mozilla/firefox/I ended up exporting everything and then re-importing. But it was not as annoying as I expected. I think I was mostly dreading it because I’d lost passwords in the past to this sort of thing, because I wasn’t expecting it, so I didn’t export beforehand. Just bad associations in my brain.
Edit: a sibling commenter just made me aware of the config for the "snappy" version actually resides in another directory. That said you can manually copy the files to the standard place
Snaps allow for the base system to be stable while having the latest version of an application in a sandbox.
That's just an example; the blog is probably referring to PGO and/or LTO: profile-guided optimization and link time optimization, which require some fiddly setup that I believe third parties have traditionally not bothered with.
And yes, it's all open source. You can see all of the bits that go into producing that .tar.bz2. You can even see the full build log if you like, eg by going to https://treeherder.mozilla.org/jobs?repo=mozilla-release&sea... . Pick your platform, click on Bpgo, click on B, select the "log" link down in the lower left.
There are plenty of Mozilla-related things to complain about, openness of the browser development process is not one of them.
2. Add the repo's public key
3. apt-get update
4. apt-get install firefox
What 3 steps am I missing?
* Recently (well, in the last 2-4 years) to boost the uptake of Canonical's "snap" packaging system, Ubuntu switched to only distributing Firefox as a snap.
* There are a lot of snap haters around. Not least because canonical fucked up the update mechanism in the first year or two, had a bunch of performance problems (now mostly solved?), and made a bunch of weird broken snaps for things like docker.
* An unofficial firefox package for Ubuntu was then created, so people who didn't want to use the snap could avoid doing so.
* By some accounts, Mozilla is keen on controlling the entire release channel, so security updates don't have to wait on volunteer maintainers. (IDK if this is true or not, but I've heard second-hand claims)
* This new package lets Mozilla release to users directly, and lets snap haters avoid snap without using unofficial packages.
Ed: actually, yes, that makes me hate SNAPs
What Mozilla is calling out here is a seperate, Mozilla-direct repo. This means you skip the official repos.
Everyone should think carefully about what this means.