4 ms·
On the other hand, I repeatedly recommend that ordinary users do not install software from third party apt repositories unless they really really have to. Fund
by rlpb 4y ago
On the other hand, I repeatedly recommend that ordinary users do not install software from third party apt repositories unless they really really have to.
Fundamentally they're a hack, don't work right, and often result in latent packaging problems that cause future release upgrades to explode. People then unfortunately attribute those failures to the distribution rather than the broken hacks they themselves installed from third parties.
It is fundamentally impossible for a third party deb to correctly declare the necessary metadata to avoid breakages on a future upgrade. In distribution packaging this kind of thing is dealt with in metadata provided by the distribution packages being upgraded to, but third party debs don't have that luxury, even when using a third party apt repository. For example, a "Breaks" metadata declaration can only declared from one direction, so if a newer distribution package Breaks a third party package, then it cannot be declared on the third party side so ends up just not getting declared, resulting in breakage.
So apt/deb only really works in the curated distribution model where all your software comes from the distribution.
This doesn't work when users want software newer than their distribution release, or want to install proprietary software that cannot be curated by a Free Software distribution.
Further, third party debs have root on your system, which is terrible for modern security. Installing software from third party sources which aren't sandboxed should really be unacceptable from a security perspective nowadays. For example: do you really want some game to have access to your online banking session? How secure is that game's development infrastructure that will stop a bad update from resulting in you losing money?
On the other hand Snaps and Flatpaks actually provide app sandboxing.
That's the use case for these packaging formats. If you don't need them yourself, then that's fine. But it's disingenuous to declare that there's no need for them.
- tpoacher 4y ago> But it's disingenuous to declare that there's no need for them I didn't say there is no need for them. They are just horrible solutions. > I repeatedly recommend that ordinary users do not install software from third party apt repositories unless they really really have to Fair enough, I wasn't making the case for third-party repositories specifically; I was indeed making the case for distribution-curated repositories. In general if a version of a particular piece of software in the distribution's curated repository is older than the version I require, what I'm saying is that I will generally go to the project's website "a la windows style", and either download whatever binary they provide, or preferably if possible compile from source. My misc-updates package then simply checks for available updates, which is the main functionality missing when manually installing packages. Obviously this may not be the best solution for everyone else, but for my own needs I found it far more functional and usable than either flatpak or snap.
- rlpb 4y ago> what I'm saying is that I will generally go to the project's website "a la windows style", and either download whatever binary they provide, or preferably if possible compile from source. That is dangerous from a security perspective though. That third party binary, or your built binary, has permission to everything your user can, including exfiltration of your online banking sessions and so on. That's not appropriate in the modern computing environment. Apps that haven't otherwise been curated really need to be sandboxed, and if you have to go out of your way to arrange a sandboxed environment, well, that's what snaps do out-of-the-box, and we can't expect users to be able to stand that up manually any more than we can expect them to compile from source.