Most other software should only update when specifically instructed to.
That's not a sane decision. Sane would be to update on closing.
Same way Windows offers to "Update and Shutdown" (you don't need the PC anymore why don't I under after you walk away) and not "Update on next Start up" (I'll wait until you need me to get in your way).
This presumes that shutting down is never a time-sensitive action. If I had a nickel for every time Windows decided it wants to spend a half hour installing updates when I'm trying to shut down a laptop so that I can put it in my bag and go somewhere with it, I'd be able to actually buy a Windows license instead of resorting to vlmcsd.
Perfect!
Quora always had reputation for being shit but I am impressed by how terrible that page is. I mean there are only two 2 types of answers there: "Window$ is BAD" and stuff that looks like generated by GPT-3( or straight up from those infamous "recipe sites" a.k.a. SEO farms).
Windows does sometimes get it correct.
Though I never seen it on Fedora or Windows, might be some quirks related to Ubuntu packaging.
On Windows, where no standard update mechanism exists, Firefox updates itself, so it does it only when it knows it's fully shut down (before it opens or after you close all windows).
And for Windows there is standard update mechanism - Microsoft Store - which also does the same sane thing.
So it's Ubuntu implementation problem, and not a Firefox one.
Do I understand correctly that it is based on systemd's offline upgrade mode, i.e. installation is done at the following boot? If so, you can do that on Ubuntu too. I'm not sure how (perhaps by invoking apt-offline?), but at least KDE Discover does it on Kubuntu.
Most software does fine, as long as it has already mapped in all of its libraries, those files can be unlinked in the filesystem, but will remain on disk in their current form. You do run into trouble if the software is part way through starting up and hasn't mapped all the libraries, or if you update the files rather than unlinking and copying new ones (at least, FreeBSD lets you update mmaped files and all processes will see the updates, which is usually not what you actually want when the files are code).
Windows makes it very hard to update program files while programs are running, so it's not surprising Firefox endeavors to do updates while it's not running.
This doesn't seem insane to me, but might not be an easy thing to fit in to the large body of code that's already there.
You still have issues if you're starting up during an upgrade, but that's a problem with anything dynamically linked.
I don't think so? As long as the main process is separate from the seed process, and the seed process is forked before specialization.
> It also makes address space layout randomisation less effective, because every forked process starts out with the same base memory layout, doesn't it?
Yeah, I think you're right. Not sure if you could maybe do some randomization post fork, but you're probably right.
Are you sure that originates in the update check? The update itself is downloaded asynchronously while the browser runs. The browser itself checks if an pending update has been downloaded when it is launched.
I don't think this is a fair decision. Virtually nothing requires such a forced update. And the browser should be sandboxed by the OS anyway.
That's not been my experience. I don't know what system you're using, but with Firefox on Ubuntu, I discover that Mozilla has put out another (goddamn) update (again, already, goddamnit!) when all my tabs suddenly crash, forcing me to restart the browser.