> Getting the latest version with features and security fixes is key to having a good experience whenever you use Firefox. Now, our new APT repository is directly connected to the Firefox release process, so you will receive the latest updates whenever we make them available. Tip: you will still need to restart Firefox for the latest version.
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.
I’m not sure about these stable packages, but for the nightly packages they introduced recently they explicitly mention on [1] that you can keep browsing:
> 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.
Oh, that's great! Between that very clear statement and the fact that in this post they call out that "you will still need to restart Firefox for the latest version", it sounds like they've finally fixed it!
I expect this would still be a problem for this .deb. The package manger is doing the updating which is what causes the problem for Firefox.
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
I remember that it required me to restart whenever I opened a new tab, or I wouldn't be able to use that tab. Anything in already opened tabs still worked.
Then I switched from Ubuntu to Debian and I also installed the tar.gz from Mozilla. As you wrote, it updates itself.
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.
> I remember that it required me to restart whenever I opened a new tab, or I wouldn't be able to use that tab. Anything in already opened tabs still worked.
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 tar.gz build has exactly the same problem (it just doesn't complain about it): it needs to close the files from the old package and open the ones from the new package. Hence the restart. You can minimize the downtime by just restarting the browser and then using History | Restore previous session.
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.
> The tar.gz build has exactly the same problem (it just doesn't complain about it)
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.
> You can minimize the downtime by just restarting the browser and then using History | Restore previous session.
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).
That's a terrible user experience. I don't remember that happening when I used Firefox through .deb files or the Arch AUR packages. I don't want it actually updating in the background. I'm fine with it checking for updates and even pre-staging the update files for the next time I restart the browser. Swapping out the app files underneath a running browser process in the background, so no new content can be opened, sucks.
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.
> it has had this annoying habit of requiring me to restart my browser whenever it updates in the background
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.
It does that on FreeBSD as well yeah. Not a huge deal for me as I only install updates when I'm not in the middle of things. I love an OS that doesn't force me to do anything <3
This behaviour can be disabled by blacklisting Firefox from APT's unnattended upgrades. I wrote[0] something up on this last year if anyone is interested.
One of the benefits of kde offline updates is that this never happens, things are never updated while you are using them.
You need to restart from time to time though, I do it weekly.
Restarting your whole system is not necessary for the firefox flatpak though -- updates are installed in a parallel directory and applied the next time the user re-launches Firefox.
in the past, this was because firefox was very dynamic loadable (i.e. not keeping everything it needed in memory) so when you updated, you were overwriting data that it depended on.
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.
The snap package actually doesn't have this issue at all, it just waits for you to close the browser to switch to new version but you can keep using it for however long you want without Firefox complaining like it does if a package manager messes with some files while it is open.
I was already using the ~mozillateam PPA, because fuck Snap, but it'll be great to have an offical Firefox repository.
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.
You could also switch to Linux Mint, they have a very definitive anti-snap position. I would really like them to bring back an official KDE spin though..
With KDE Plasma 6 release just around the corner, it would be great to see more distributions providing KDE desktop environment as equal to GNOME, instead of "spin".
I'm using Debian Testing with KDE, after using Ubuntu with KDE, and it's basically just some lack of polish, and I also sometimes miss the PPAs. (I understand that it's technically possible to use software from Ubuntu PPAs in Debian, but as I'm getting older, I prefer officially supported ways of doing things, so that I can stay on the happy path as much as possible.)
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 think that Debian is lovely, but as a person with a hojillion scripts and configs, I don't know how Debian and Ubuntu have diverged over the years in terms of filenames, paths, package names. etc., and I'll have to find out (for example, Ubuntu's /etc/cloud/cloud.cfg.d/ vs Debian's /etc/network/interfaces).
I was also going to mention ufw, but I see Debian ported it, so that's one less concern!
Debian is my choice too! I run Debian testing and it is great! I have up to date packages, a ‘rolling’ release and now even Firefox straight from Mozilla
PopOS is basically Ubuntu without enforced snap and better driver support, including having real Firefox packages. I personally use flatpak firefox because it adds a few extra safety bits, but I know that firefox "native" is there if I want it.
As someone who is quite new to Ubuntu, and recently just ran an install. I've seen this "snap" word thrown around and for better or worse I consider the opinion of random HN users to be better than the average opinion elsewhere on the internet.
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?
Snaps are self contained packages of software. They are mounted as a separate isolated file system when they start.
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.
The concept is fine, but implementation is quite obnoxious.
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.
This is a welcome addition for Chromebooks, because now you can install latest Firefox (not ESR) in Crostini without using Flatpak.
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).
Hey, do you know a good resource to learn how to compile a binary for Linux Arm64 that works in a Chromebook? I would like to port some C code I have that I produce builds for x86 and Amd64 debian using GCC 4.8 and an old debian, I am curious what has to be done to produce a binary that would run the same in Chromebook.
You're not supposed to have to do anything at all. Crostini on an ARM Chromebook is literally just aarch64 Debian, pointed at the upstream apt repos for basically all of its binaries.
Since my Chromebook is not really powerful, yes, Firefox feels like a second class citizen. But I imagine in a better Chromebook it should work better.
I just use whatever is in debian testing or unstable, but it's trivial to download firefox _directly_ from mozilla which will then keep itself updated to the latest version.
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.
This is what I do with Firefox developer edition. It doesn't have that problem where it refuses to work if it's been updated in the background, it just adds a little green dot to the hamburger menu that indicates that it wants to restart at your leisure.
From what I can tell, the “Ubuntu Mozilla Team” does not consist of people from Mozilla but rather just people packaging Mozilla software for Ubuntu. The latest packages in that PPA have been uploaded by Rico Tzschichholz, who does not appear to be affiliated with Mozilla.
Get rid of your PPA package and use the official repo, it's 99.9% better in almost all cases. More details on google/youtube on how to do that, it's too much to type on HN and should be on the first page of google/duckduckgo. I would guess the people supporting the PPA will stop updating it after a while due to there being an official repo to use.
Debian/Ubuntu is also the sole chosen distro for Spotify and Signal first-party native packages.
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)
This is a great update from the Mozilla team! Please continue the hard work.
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.
> the infamous “We Need More Deplatforming (2021)”[1] article
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.
Readit News
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...
https://bugzilla.mozilla.org/show_bug.cgi?id=1609882
https://bugzilla.mozilla.org/show_bug.cgi?id=1850026
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.
[0]: https://hth.is/2023/01/10/blacklist-firefox/
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.
Kudos 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.