Wack Playstation Sup! ๐Ÿ™Š ๐Ÿ‡ฎ๐Ÿ‡ธ ๐Ÿ is a user on mastodon.xyz. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

So, Fediverse!

Flatpak? Snaps?

Which one deserves space in my limited brain?

@HerraBRE neither, use tarballs that adhere to the FHS. Then it's super easy to use fpm to create standard distro packages from.
@HerraBRE that is, create tarballs that you can just unpack them into /usr inside the package.

@kurisu That's only realistic for trivial apps with no "interesting" dependencies.

I'm considering this for , which is well outside the complexity that a binary tarball can handle.

@HerraBRE what do you mean be interesting dependencies?
@HerraBRE just looks like a python app to me, what's special?

@kurisu Dependencies on compiled Python libraries. And Tor. And GnuPG, ideally a specific version so I don't have to worry about the shifting API.

@HerraBRE wow, thats a heavy set of dependencies. Static compilation with musl should fix the python libraries, but hard-depending on tor and gnupg seems like more of an architectural problem and probably layering violation.
@HerraBRE developers should be creating quality packages which integrate with the rest of the system, instead of boxing themselves away and including a second copy of everything, I think.

If you've made your application so difficult to package that it'll never be included in distro repositories because it has unmanageable dependencies, that's *your* problem, and flatpak and snaps are just ways that developers push that problem on users.

@kurisu Hi, I asked for opinions, but now you're just lecturing.

Thanks for your input, please stop now.

@HerraBRE my bad for lecturing.

I hope you see that users really do dislike appimage, flatpak and snaps though. Dismissing users expressing their opinion as just being smug is unhelpful imo.

@kurisu Yes, I see that opinionated people who don't know what I'm dealing with or what I've already considered, are still quite eager to preach and tell me my question is wrong.

I hear that people don't like it, but honestly, every tech has haters. Saying you dislike something has almost zero signal, it's just noise.

Tell me WHY, and I'll listen. If you just tell me something sucks, I probably won't.

@HerraBRE @kurisu here's why: both take all of the worst parts and none of the best parts of static linking, all of the worst parts and none of the best parts of package repositories, and combine that with empty promises of security and a ticking timebomb of actual security problems

@sir @kurisu The security problems depend on how good a job I do shipping updates. This is indeed a concern.

The security benefits of sandboxing are very real and I disagree with you on that point.

But thank you for having a real opinion! ๐Ÿ˜„

@HerraBRE @kurisu that's the problem, you're shipping security updates. You're a random. I trust my distro package maintainers WAY more than I trust random applciation developers.

@sir @kurisu Later in the app's lifecycle, I fully expect the distros to take over.

At this early stage though (the app is honestly a bit shit and will need frequent fixing), I expect being able to ship updates faster than the distro release cycle has a lot of value to my users.

So I'm considering what options I have for doing that.

@HerraBRE @kurisu people who want fast updates should use fast distros

@sir @HerraBRE shipping fast updates is still possible on a slow distro once you run the package repositories. And as long as you're not packaging the dependencies yourself, that's fine.
Wack Playstation Sup! ๐Ÿ™Š ๐Ÿ‡ฎ๐Ÿ‡ธ ๐Ÿ @HerraBRE

@kurisu @sir This is what I am doing now, for Debian derived distros.

And from a security POV, I feel REALLY bad about it. Once you add my repo to your apt sources, I can update any package on your system. I can do so selectively based on your IP address.

Shipping a Snap or Flatpak does imply bloat and does put the onus on me to rebuild and ship when dependencies have security flaws - but at least I can't replace your /usr/sbin/sshd.

Everything has pros and cons.

ยท Web ยท 0 ยท 0