|
|
|
|
|
|
by xorcist
1334 days ago
|
|
|
If it was that simple, why wouldn't the deb package work like this? There is no technical reason a new version of a software can't execute in parallel to the previous. Firefox can't do that. The simplest reason being that it is stateful and keeps records of history, bookmarks and whatnot which not only can't be accessed concurrently, but the specific storage model chosen can only be forward migrated. Accessing this data from two different versions of Firefox would inevitably lead to corrupt data, even when concurrency is not an issue. That's just the obvious reason with profiles. But there are also various other issues where Firefox interacts with the plugin system and other external data. All of these could probably be fixed, but it would require a radical redesign of the software which right now no one has stepped up to do. The least problematic method of using Firefox on Linux for most users is probably the official tarball. It's the trivial method of unpacking a software and running it from the destination folder. It has implications for freeness and DRM, and the obvious problems bundled dependencies bring, but Firefox is unusually well maintained software with the manpower to make it work. And containerization or producification on top of Firefox will only make it more complicated and worse supported than upstream is. |
|
|
i.e. you install a new firefox, the data on disk (i.e. file xyz) is no longer what the firefox version running expects and bad things happen. It could cache everything in memory (I guess) and never have to read anything from disk, after it starts up (relative to it, cache/cookies in local profile shouldn't matter in regards to disk).
so when you update the deb you are replacing file 'xyz' and old xyz no longer exists (as opposed to unlinking and replacing "/usr/bin/firefox" as even though unlinked it will still exist (for paging purposes) until every execution of it terminates and only then will it actually be removed from the file system.
this is where containerization can help on a "multi user" system, if everyone ran firefox in a container, every time they started it fresh, they would get the most up to date copy installed (in a non "multi user" setting, its less important, but can still have some value). (quotes because I mean multiple simultaneous desktop graphical desktop users, which if we're honest, most desktop linux users aren't doing).