As great as flatpaks are for providing sandboxing, the problem with them is that they are upstream software. When Audacity added telemetry it only affected binaries downloaded from them, not distro-compiled binaries. When firefox stops you from loading your own extensions, that's because you're using a binary downloaded from them, not distro-compiled binaries. A decade ago I used to think distro package maintainers were unnecessary middlemen who were just introducing failure points (like the Debian openssl fuckup), but today they are truly the last line of defence from malicious upstreams.
Even if something sneaks into a distro package it's possible to convince the distro package maintainer to disable it, because the maintainer's interests are aligned with you and not upstream.
1. My point was about using upstream software, not about the Audacity flatpak specifically. Audacity binaries downloaded from upstream's website have the problem I mentioned.
2. The Audacity flatpak is maintained by a Flathub dev only because Audacity upstream has not expressed an interest in maintaining it themselves, not because of some Flathub policy to reject telemetry etc. If they wanted to maintain the flatpak themselves they would be allowed to do that, since Flathub policy is to have upstream developers maintain their flatpaks. And that would lead to the problem I mentioned.
But you can get alternatives which have the telemetry removed. Like VSCodium and some Firefox forks. And instead of every distro needing to do those patches themselves, they can share the effort.
Maintaining a firefox fork is a much bigger job than putting `--with-unsigned-addon-scopes=app --allow-addon-sideload` in the package build script.
Distros already share effort implicitly because maintainers of distro X often look at what distro Y is doing for that package. Also users compare distros frequently and will tell the maintainer of distro X that the same thing works with distro Y.
I misremembered. The effect is that you don't get the "Restart required" message, but the implementation is that they just postpone applying the update until your next re-open.
> We also are not trying to force you to install updates before you can keep using Firefox. Firefox's update mechanism downloads updates while it is running and installs them at startup. ... In the case of Bug 1705217, the package manager updates Firefox's files on its own schedule that is outside of Firefox's control ... Firefox had no intention of forcing updates to be installed at an inconvenient time.
That is not a difference in behavior between distro packages and upstream Firefox. If an update gets installed then FF requires you to restart it. So just like the upstream binary's updater doesn't install the update while you're still running it, you shouldn't update the distro package while you're still running it either.
No, if you update upstream Firefox you'll see a prompt inviting you to restart when you want. If you update distro Firefox you'll see a page blocking everything telling you you need to update now.
That's because upstream Firefox separates out downloading and applying the update.
> Correct. And that's what I'm telling you to do with your package manager as well.
Please inform me how to automatically have my distro package manager download updates and install them on the next open. Note that it's critical here that the install is perceptively instant: it means I'm never waiting for my browser to be available.
Now why would I do that? You originally asserted "Conversely Debian broke Firefox's ability to update without requiring a restart" and now you know that Firefox doesn't have the ability to update without requiring a restart. Any further shifting of your goalposts is your problem, not mine.
I did shift the goalposts once because I was wrong. In my second post I expressed that Firefox's built-in update manger still did something much better than the distro package manager.
You asserted that was not the case, so I asked you to prove it. If you don't want to you don't have to, but I'll assume you admit that the distro package manager is in fact inferior.
This doesn't make *any* sense. Even in the example you gave, Mozilla really wanted to block you from using extensions, they will just remove the entire store.
It doesn't make sense because you need to read carefully. I said "loading your own extensions", ie loading extensions not from their store but by dropping a .xpi in /usr/lib/firefox/browser/extensions that you made running `zip` and changing the filename.
Even if something sneaks into a distro package it's possible to convince the distro package maintainer to disable it, because the maintainer's interests are aligned with you and not upstream.