4 ms·

Which OS / package manager are you using? I haven't noticed this behaviour on my Linux (Kubuntu) or macOS installs -- both Firefox Dev Edition though.

swebs 8y ago
Ubuntu 18.10 using APT.
vetinari 8y ago
Under linux with apt/dnf. These package managers update Firefox while it is running. On MacOS or Windows (maybe even Linux with the Mozilla updater, never tried it), the updater does the update on the next restart.
- cmurf 8y ago
  Exactly. The package manager method of updating stomps on the in-use libraries for the running application. The built-in Mozilla updater knows better, downloads an update payload but doesn't apply it until the user relaunches and on "first run" it actually does the update rather than launching, and after that completes it launches the updated application. It's the same on macOS, Windows, and Linux. Chrome on macOS and Windows keeps itself up to date; for whatever reason Chrome on Linux installs a google.chrome repository, uses the distro package manager, and clobbers the running binary. shrug
  - paavoova 8y ago
    > for whatever reason Chrome on Linux installs a google.chrome repository, uses the distro package manager Because that's the proper way to do things instead of each application bypassing the package manager and downloading updates and whatever else behind your back. How would you track and control updates if each application you use decided to do its own thing? Secondly, if installed to system directories, applications cannot write there without superuser privileges.
  - vetinari 8y ago
    > The package manager method of updating stomps on the in-use libraries for the running application. This is not a problem on Unix-like systems, actually. Any running process, that has some file open, will keep the original file open, even if the filename points to another file now. Only processes that open the file after the change will get the new version. I suspect that the protocol that multiple processes of Firefox used to communicate together could change between version and the mismatch between old and newly launched processes caused the problem. So it is versioned now, and if the versions are mismatched, warning is being shown. > for whatever reason Chrome on Linux installs a google.chrome repository, uses the distro package manager, and clobbers the running binary As others have said, it is actually the right approach. The custom updaters for Firefox and Chrome under Windows and MacOS are there, because they are lacking any system for centralized package management. Flatpak solves this in a third way: it doesn't clobber the current tree, it creates a new, separate one and signals the application, that it was updated, and can restart into a new version, when it is convenient. It gets the best of the custom windows/mac updaters (not overwriting running apps), together with the best of linux package managers (centralized management).

swebs 8y ago

Ubuntu 18.10 using APT.

vetinari 8y ago

Under linux with apt/dnf. These package managers update Firefox while it is running. On MacOS or Windows (maybe even Linux with the Mozilla updater, never tried it), the updater does the update on the next restart.

cmurf 8y ago
Exactly. The package manager method of updating stomps on the in-use libraries for the running application. The built-in Mozilla updater knows better, downloads an update payload but doesn't apply it until the user relaunches and on "first run" it actually does the update rather than launching, and after that completes it launches the updated application. It's the same on macOS, Windows, and Linux. Chrome on macOS and Windows keeps itself up to date; for whatever reason Chrome on Linux installs a google.chrome repository, uses the distro package manager, and clobbers the running binary. shrug
- paavoova 8y ago
  > for whatever reason Chrome on Linux installs a google.chrome repository, uses the distro package manager Because that's the proper way to do things instead of each application bypassing the package manager and downloading updates and whatever else behind your back. How would you track and control updates if each application you use decided to do its own thing? Secondly, if installed to system directories, applications cannot write there without superuser privileges.
- vetinari 8y ago
  > The package manager method of updating stomps on the in-use libraries for the running application. This is not a problem on Unix-like systems, actually. Any running process, that has some file open, will keep the original file open, even if the filename points to another file now. Only processes that open the file after the change will get the new version. I suspect that the protocol that multiple processes of Firefox used to communicate together could change between version and the mismatch between old and newly launched processes caused the problem. So it is versioned now, and if the versions are mismatched, warning is being shown. > for whatever reason Chrome on Linux installs a google.chrome repository, uses the distro package manager, and clobbers the running binary As others have said, it is actually the right approach. The custom updaters for Firefox and Chrome under Windows and MacOS are there, because they are lacking any system for centralized package management. Flatpak solves this in a third way: it doesn't clobber the current tree, it creates a new, separate one and signals the application, that it was updated, and can restart into a new version, when it is convenient. It gets the best of the custom windows/mac updaters (not overwriting running apps), together with the best of linux package managers (centralized management).