Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flatpak Is Not the Future

ludocode.com

Post reply on HN
Print view View original

111–120 of 410 posts

Re: Flatpak Is Not the Future

#111

Post by oleg_antonyan »

zohch wrote: post #100
oleg_antonyan wrote: post #78

Earlier quoted context omitted.

This works both ways: Why would you rather install some random flatpak from someone you don't know as opposed to a rpm? The trust is outside of the scope of package managers

Because installing an rpm allows you to run arbitrary code as root. Installing a flatpak does not. I mean there are many more reasons but that should be en.

It's explained in the article, security section: b/c installing flatpak can also run arbitrary code as a user. And I won't argue that running malicious code as a user is always harmless. Regardless of root access if you're installing flatpak and its author want to pwn you - they can do it even without root access

Re: Flatpak Is Not the Future

#112

Post by kaba0 »

krkoch wrote: post #86
kaba0 wrote: post #77

Earlier quoted context omitted.

Nah, AppImage still won’t run on all distros. The only thing I think actually solves packaging is nix.

Hm, I've some problems with nix and desktop apps that needs opengl or similar machine-specific libraries. There are some hacks, and I also think nix comes very close to a good solution, but it's not 100% yet.

That’s mostly due to video drivers not being under nix’s control deliberately (if packages would depend on them as well, instead of a stub, there would be exponentially more build for each driver). On nixos this is solved by a specifically-placed stub, while it will be distro specific elsewhere, so it may not work for a random distro (that’s where “hacks” come into the picture, choosing a non-nixos distro specific lib as the stub and it will work just fine)

Re: Flatpak Is Not the Future

#113

Post by AnIdiotOnTheNet »

drran wrote: post #101
alkonaut wrote: post #38

Earlier quoted context omitted.

Is there any difference in trust between package maintainers and flatpack packagers? If anything, isn't the flatpack situation better in that regard because the end user is more likely to have a sandbox?

Maintainers are not developers, they are users, so the developer cannot push unwelcome changes, such as ads, trackers, trojans, backdoors, keyloggers, etc. directly to users because the maintainer will refuse to accept that.

On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software, and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained"), which reflects poorly on the developer in the mind of the user.

I personally see no upside to shoving an unpaid third party between user and developer.

Re: Flatpak Is Not the Future

#114

Post by faho »

> How much progress could we make if Steam deprecated their runtimes, abandoned containerization for new games, and let all new games just use the native system libraries? How loudly do you think gamers would complain if a distribution upgrade broke their favourite game?

If the steam runtime didn't exist, most gamedevs would only target the most popular distro - probably the current Ubuntu LTS, and you would have to recreate the runtime on your distro of choice.

And once there's a new Ubuntu release you would also have to recreate it there (or the game updates and now you'll have to recreate it on the now-old version).

The choice isn't between steam runtime and a utopia, the choice is between the steam runtime and something much worse. Linux libraries simply aren't stable enough in API and ABI.

Re: Flatpak Is Not the Future

#115

Post by AnIdiotOnTheNet »

sandGorgon wrote: post #20

The short (but polite) rebuttal to this is - OSX. DMG files are similar sized and proven to be very successful. For e.g. - firefox ( https://www.mozilla.org/en-US/firefox/all/#product-desktop-r... ). Win64 installer is 50mb. MacOS installer is 130mb. Linux 64-bit is 70mb. Same is the case with Chrome - https://chromeenterprise.google/intl/en_US/browser/download/... . Windows MSI is 79mb. OSX PKG for the same is 195mb…

Yeah, really. OSX DMG's contain AppBundles, a concept OSX inherited from NeXT. NeXT wasn't the first implementation of the idea either, in fact pretty much every non-unix desktop OS ever released used some variation of the concept including DOS and the original Mac.

Sadly, it seems the Linux world just can't wrap its head around the idea of managing applications with the same simple mechanisms we use to manage regular every day files. It would seem that Linux Desktop users just love having inflexible management tools do it instead. Well, there is AppImage, but unfortunately its use is not wide spread.

Re: Flatpak Is Not the Future

#116

Post by david_draco »

Re security: This is probably best fixed by packaging apps with SELinux rules, which are enforced and cannot be disabled, plus responsive maintainers. There could be more than one app version to allow different SELinux rule strengths, per-app.

Re disk space: no mention of Nix? That also solves updateability for security issues. Another solution is Gentoo's -- deliver the sources and recipes, (re)build as needed. That could also work in userspace.

It would be nice to be able to 1) distribute Linux GUIs 2) let friends install them easily 3) have the friend edit the GUI app logic and run the modified version. AFAIK, this is currently only possible with apps based on interpreted languages (e.g., Python+GTK), but even there you'd need to guide your friend to install the required packages.

Re "the state of software complexity in 2021": Ignore complex software, and just don't include it on your system. Start with a subset, and add only what you need. That's how OpenBSD remains manageable. If people want to extend, they can go ahead. But you don't have to fix the world.

Re: Flatpak Is Not the Future

#117

Post by simiones »

enriquto wrote: post #43
alkonaut wrote: post #38

Earlier quoted context omitted.

Is there any difference in trust between package maintainers and flatpack packagers? If anything, isn't the flatpack situation better in that regard because the end user is more likely to have a sandbox?

> Is there any difference in trust between package maintainers and flatpack packagers? You shouldn't need to trust either. Just the sandboxing system of your OS.

That's only true for the simplest of apps. The whole point of desktop OSs is that programs can integrate with each other, but that necessarily discards the notion of a sandbox almost entirely.

Re: Flatpak Is Not the Future

#118

Post by AnIdiotOnTheNet »

necovek wrote: post #22

The most important takeaway from this is, to me, the need to separate sandboxing from dependency management. However, as can be seen with AppImage, which seems to be strictly focused on dependency management, that results in bloat. It would be great if we could have a sandboxing solution that ignores the dependency management altogether. The problem is not with Flatpak or Snaps (or Docker). The problem is that the fr…

> Backwards compatibility is hard in software in general

I disagree. Pretty much every desktop OS in the world manages to get quite a lot of backwards compatibility without a whole lot of trouble, except for Linux Desktop.

That suggests the problem isn't hard, it's just that the culture of Linux Desktop is incompatible with the concept.

Re: Flatpak Is Not the Future

#120

Post by post-it »

mrweasel wrote: post #36

My main complaint about solutions, like Flatpak or Snap, is that they add another package manager. Now I have to manage two sets of packages. The baseline tools, like all the GNU standard Unix tools, and other command line tools are still managed by DNF, APT, whatever, and then another set of apps are managed by Snap. It's pretty confusing, especially if you never use the "app stores" otherwise. You quickly end up wi…

Package managers that integrate apt, flatpak, and (potentially) snap are a nice solution. Unfortunately, the one that happens to be on my system (Pop!_Shop) is awful.
Post reply on HN