221–230 of 410 posts
> This is uncompetitive with Windows on its face. If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system. What about the gargantuan WinSXS folder?
People have tried to provide a packaging format that would allow apps to declare their depencies in a distribution neutral manner[1]. It was, uh, not a huge success. Let's take an extreme example. If I build an app on Ubuntu and then try to run it against the system libraries on Alpine, it'll fail, because Alpine is built against a different libc. We can simply declare Alpine out of scope and only support glibc based…
You can optionally support newer functionality with a single binary by dynamically loading libraries resolving functions at runtime using dlsym or API-specific mechanisms (e.g glxGetProcAddress).
Earlier quoted context omitted.
> No. It doesn't. You still need to trust the people who package the thing. How is this any different than sudo apt install foo?
apt is not misleadingly advertised as a sandboxing environment. Flatpack is: "Flatpak: Linux application sandboxing and distribution framework " [0] "It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system." [1] The whole point of a sandboxing environment is that you can run applications that do not want to be sandboxed. The flatpack prop…
Earlier quoted context omitted.
SystemD is not harmful for distributions. Flatpak replaces high-granularity, properly managed dependencies and security updates with huge blobs.
Flatpaks are not meant to replace established package managers, but to act as a supplement to them. Flatapak's design decisions go to huge lengths to ensure they are a side-by-side system with default package managers e.g. the notion that Flatpak packages have a different XDG_CONFIG directory so as not to conflict with applications installed via the main package manager. Therefore the argument that they are harmful t…
Earlier quoted context omitted.
> On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API. Now, with Flatpak, each runtime is an SDK on its own. However, unlike Windows and macOS, specific runtime is not being bound to a specific OS release, but to the app requirement.
That's right, it makes the problem worse. The first time I noticed that trend was on macOS, where applications bundle most of their libraries, and binaries compiled for multiple architectures. Then we had Electron apps that ship with their own full copy of a browser and dependent libraries. When NPM was designed, they observed that resolving colliding versions of the same dependency was sometimes difficult. Their ans…
And parts of the industry are beginning to move back and favor stability, as a result of
- numerous NPM packages being taken over by coin miners and other malware - at the scale of some of them, even a ten minute takeover window were millions of installs, and source chain audits are almost impossible
- framework churn being an actual liability for large enterprises - many were burned when AngularJS fell out of love and now they were stuck with a tech stack widely considered "out of date". Most new projects these days seem to be ReactJS where Facebook's heavy involvement promises at least some long term support
- developer / tooling churn - same as above, the constant amount of training to keep up with breaking changes may be tolerable at startup, money-burn phase, but once your company achieves a certain size it becomes untenable
This gave me an idea: how about shipping an installer with an embedded appimage. The installer will check the system libraries for compatibility, and if compatible, it will install the application so that it uses the system libraries. If not compatible, it will install the appimage (and do the desktop integration stuff). I actually really like appimages for distributing games and small apps. The user experience is a…
In this scenario, what would be the point of deferring to the system libraries if you already shipped and made the user download the built in ones? As far as desktop integration goes, there is already a tool available that will setup the .desktop file for you when you first run an Appimage. >The lack of sandboxing isn't a big deal in my eyes It should be, executing random Appimages you've downloaded online is a huge…
Presumably you'd delete the installer after you finished installing the app, the same way people do on Windows. Also, the appimage could be compressed in the installer to reduce the size. I haven't worked out all the implementation details, but I'm sure it's doable in a user friendly way.
> It should be, executing random Appimages you've downloaded online is a huge security liability.
That's FUD, nobody is downloading and executing "random" software from the internet (if a trusted developer gives you malware, that's another story). Checksums and/or code signing can add peace of mind. Windows and MacOS have done just fine without any sandboxing whatsoever.
I'm all for sandboxing, but if it isn't being implemented properly, it's just an extra layer of headache on the frustration cake that is Linux software distribution.
> you can still tweak the sandbox permissions yourself
You and I maybe, but the average user who just wants to install GIMP isn't going to understand why they'd want to do that. Why should I be suspicious of this app? Is the developer is shady? Who even is the developer? Is the distributor shady? Who even is the distributor? Is my wifi password not strong enough? etc
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…
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…
There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have…
Earlier quoted context omitted.
Flatpaks are not meant to replace established package managers, but to act as a supplement to them. Flatapak's design decisions go to huge lengths to ensure they are a side-by-side system with default package managers e.g. the notion that Flatpak packages have a different XDG_CONFIG directory so as not to conflict with applications installed via the main package manager. Therefore the argument that they are harmful t…
If flatpaks weren't in competition with packages repos they would serve no purpose. They are explicitly in competition with package repos. They exist so that app developers can get their work out to users without cooperating with downstream packagers.
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…
There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have…
As opposed to what? Dynamic linking does not solve this problem, contrary to popular belief.
>- Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself.
Again, as opposed to what?
>- Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk.
Sounds like a good way for a proprietary software to be distributed...
>- Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks.
I don't see how one follows the other.