4 ms·

> Ubuntu Flavors Agree to Stop Using Flatpak Yayy!!! > And to focus their efforts exclusively on deb, Yayyy!!! > and snap. ... oh. Honestly I avoid flatpa

• 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.
• sebazzz 4y ago
  Docker snap is basically broken out of the box and you need to uninstall it and install a Docker deb from Docker itself to get a working Docker installation. (Insert facepalm)
• Brian_K_White 4y ago
  This. I cannot stand that an app comes bundled with it's own os. I already have an os, and I only use containers and vms when I specifically need to. The sales pitch advantages exist, but are not more valuable than the disadvantages. If an app has such an insane build setup that the only possible way to ship the app is just ship the entire system, then the problem is the developers of that app, and perhaps it's only correct that people just avoid that app in favor of one that is built more thoughtfully, instead of papering over and hiding the hideous spaghetti monster by stuffing the whole mess into a box and pretending the box is the app. It's a response to a problem, it's just a shit response. What about "it's easier for developers to ship updates"? I do no want every random developer who are mostly none of them thoughtful systems engineers and integrators to be able to update my system. I'll pull down the same updates from their git or my distro, and in either case have some form of downstream sanity check rather than give them essentially a key to my system that I wouldn't have given any other rando. Also this plea of being easier for developers to ship is akin to "everything would be much smoother and more efficient if everyone else would just do what I say" It would be, for them, but I'm not sympathetic that tgey can't be assed to make their software generic and portable. I speak these opinions as all 3 of user, sysadmin, developer myself. A bundled system is fine for a reference implementation, not something you're supposed to require every user to run in a container.