Hacker News Reader

Comment by lillecarl | Hacker News Reader

It's really a you problem. The market share of Linux desktops is low enough that in reality it doesn't matter, and you're pulling the rug(binaries) from underneath a web browser (one of the most complex software projects known to man) and expect it to keep running flawlessly.

I'm using NixOS where every version of every dependency of every program I install will be saved until I cleanup the garbage (1 command) so I don't have your issue.

If this was Windows you wouldn't be able to update Firefox while it was running because Windows doesn't support overwriting open files (technically you can rename them and insert new ones with the same name, but that's not the point).

You're holding it wrong and blaming the project, close the software you update before you update and you might have more success.

View on HN

Yes. The market share of Firefox is low enough that in reality it doesn't matter. So very insightful. Thank you for showing me the light.

Also, I like that you think that Firefox's default settings is "holding it wrong." That's rather the point, isn't it?

It's not Firefox's default settings, It's a technical challenge that they haven't solved. But that I would argue shouldn't really be solved. _YOU_ chose to update your browser while it was running, you're on a non-mainstream platform (Linux Desktop) and you're unable to grasp that pulling binaries and replacing them with others could cause issues.

Reddit will have you back now.

No, Firefox's default setting is to upgrade even more aggressively than I'm experiencing. And, it's worth pointing out, the browser works fine, except that I'm prevented from opening a new tab. Sometimes I really don't want the interruption, and I just copy URLs and recycle tabs. That goes fine, it's just an annoyance considered by the developers to be a feature.

When the distro updates Firefox out from underneath it Firefox's options are; crash because API call does not match, detect the API incompatibility and prompt the user to do a clean restart, or spend a monumental amount of engineering work to maintain API compatibility while running mixed Gecko versions.

Using the Mozilla build in /opt, the Snap [1] or Flatpack [2] versions will avoid the distro updating Firefox out from underneath it.

[1] https://snapcraft.io/firefox [2] https://flathub.org/apps/details/org.mozilla.firefox

Linux also does not allow you to overwrite a running program; you'll get ETXTBSY.

The difference to Windows is that Linux allows you to delete (unlink) files that are in use. The inode actually owning the data continues to exist until the program is dead.

Yes the file still exists physically in disk, but if you were to execute the binary path again, would that give you the old or new result? I'm not sure how Firefox process isolation works, but it could be (armchair guess) that they just spawn the binary with inputs, which would be a possible cause of incompability.

Reply on news.ycombinator.com