131–140 of 410 posts
Earlier quoted context omitted.
Nah, AppImage still won’t run on all distros. The only thing I think actually solves packaging is nix.
And AppImage integrates poorly with desktops.
Earlier quoted context omitted.
> it works No. It doesn't. You still need to trust the people who package the thing. A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it…
> No. It doesn't. You still need to trust the people who package the thing. Flatpak and Snap have never claimed to solve the trust issue though. Flatpak allows you to add your own repositories and thus developers can package their own applications. So if you trust the developer enough to run their software, you should be able to trust them to package their own app with.
To make things worse, Flathub changed the way they display "Publisher" field for a flatpak. Which says whether a package was published by Flathub maintainers, Upstream developer or somebody else in Flathub. Now instead of saying who, they just say a "See details" link under Publisher field in flathub.org for a flatpak. That link which in turn directs me to a github page and I am still unsure who the hell uploaded that flatpak.
Before, they used to say Upstream developer's name or say "Flathub maintainers" which means Flathub team uploaded the flatpak making it easier verify who uploaded the flatpak. But now it is making it more difficult. This has been the most pissing thing about Flatpak other than the security issues and problems which keeps coming up about Flathub every now and then. Why would you change something that is so crucial when it is working?
Cos now, I could package a software which is not in Flathub and it would just say "See details" instead of my name. This provides the illusion of trust. Cos if it were to show my name there, more people would've been like.. who the hell is this guy and do a check on me (I used to do that). But now, If I could slip through Flathub checks and provide malicious flatpak, majority of the folks will still install cos most of them are using Flatpak for convenience. Not security and performance.
Want proof? Just scroll up and you will see someone saying he don't care even though agrees to the things in the blog post. He just don't care. :shrug:
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…
Firefox is larger on macOS because it contains 2 archs (x86_64 and arm64), not because it bundles of full runtime -- also the compression algo of dmg files is typically quite bad (zlib or bzip2), which is not helping.
In fact, this reinforces it. OSX believes file size matters so little they’re willing to double file size simply so users don’t have to pick x64 or x86 when downloading the app (and if they’re using the App Store the App Store could do it for them, but even that Apple thinks is too much complexity).
Right! Time to pushback against these developers who uses Flatpaks, Appimages, Snaps, Electron, etc. We are no longer in the world of doubling performance and memory size. Even more, nowadays people are conscious of the power usage. Time to fight the bloat!
Right! Time to pushback against these developers who uses Flatpaks, Appimages, Snaps, Electron, etc. We are no longer in the world of doubling performance and memory size. Even more, nowadays people are conscious of the power usage. Time to fight the bloat!
Higher memory consumption as a trade off for developer convenience might be questionable in many cases but here it is to increase USER convenience. What are developers supposed to ship their apps with? Make packages for every Linux distribution under the sun? Flaktpaks and Appimages solve a real problem. The current alternative is NOT being able to use the specific software at all because you don't have the right ver…
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 regula…
Seems to me they love treating application management like one manages dependencies in a software project. There are a lot of parallels with the paradigm. Its clear where the notion came from. And I think in the context of unix/linux history it makes sense. If I were an MIT grad student in 1978 there probably isn't much difference between a library and an application practically.
But that was over 40 years ago. There is a clear distinction now and the overwhelming majority of PC users are not MIT grad students. Applications should be easy to install. People don't care that there is more than one version of some dependency. They don't care that your repro doesn't have what they want. They have work to do.
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…
I agree that the implementation is lacking. Snap has the abysmally named "--classic" parameter to allow installs to "run without confinement". Flatpak can request permission changes at install time (albeit declaring them), where users are likely to just click OK/OK/OK. The sandboxing needs to be tightened up. Flathub is a strange beast. There's no mention of security on their wiki. They stopped publishing minutes (or…
the flatpak sandbox UX is bleak. right now, you have to check the JSON file you linked to check how much access a flatpak program gets. i disagree with the --own-name and --talk-name flags (i think this is for screensharing; zoom should use the screensharing portal instead. letting zoom talk to gnome shell directly could be bad.). --socket=x11 is a massive hole in the sandbox, since x11 does not have a security model…
In general, GUI package managers w/ Flatpak support show you the permissions, as does the CLI upon an attempted install.
Earlier quoted context omitted.
> it works No. It doesn't. You still need to trust the people who package the thing. A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it…
> No. It doesn't. You still need to trust the people who package the thing. Flatpak and Snap have never claimed to solve the trust issue though. Flatpak allows you to add your own repositories and thus developers can package their own applications. So if you trust the developer enough to run their software, you should be able to trust them to package their own app with.
Flatpak/snap is somewhere in between where on the main repos (eg. flathub.org) anyone can publish a package for anything without being affiliated with upstream. It incentivizes users to just search for the app name and download whatever comes up as a result. That's a pattern we've known to be broken for years: from Windows users downloading the first link Google suggests (usually a sponsored link bundled with spyware/adware) to Android users downloading anything the Play Store suggests (usually spyware, see how many flashlight apps there are and what permissions they require). F-Droid in the Android ecosystem strikes a balance because there is strong community vetting for all packages published, so it's like a distro-agnostic repository following the distro packaging threat model.
I believe there are ways to mitigate those issues (eg. namespace enforcement on flatpak) but i don't think downplaying them is doing any good.
To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux. While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro. For example, the Elementary OS…