81–90 of 410 posts
Earlier quoted context omitted.
I recommend just shipping everything you need with your app, either manually or using AppImage. Flatpack is, more or less, just a bad package management.. technology.
Nah, AppImage still won’t run on all distros. The only thing I think actually solves packaging is nix.
Earlier quoted context omitted.
Even with .net framework 4.x you need to bring the framework with you, if you want to use the newest frameworks, as your customers might not have the most current version installed.
The point as formulated still stands though. You don't have to because you can always guarantee that your end users will have a Win32 runtima and a .NET runtime. There is a choice, and it's between using a later framework, and relying on the OS one.
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.
The Linux kernel is not at a point of allowing this kind of fine grained sandboxing or mocking of APIs. I'm guessing because it's a significant undertaking. I'm sure as more features become available in the Kernel w.r.t. sandboxing Snap and Flatpak will definitely utilise them.
Earlier quoted context omitted.
I recommend just shipping everything you need with your app, either manually or using AppImage. Flatpack is, more or less, just a bad package management.. technology.
Nah, AppImage still won’t run on all distros. The only thing I think actually solves packaging is nix.
Earlier quoted context omitted.
The .deb file should remain where it was when you downloaded it, dpkg just installs the contents of the .deb file.
Where is the contents of the .deb files put?
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…
Nix/Guix seems like the only one that's trying something different enough to address some of those other use-cases, but the cat's out of the bag for most people.
> If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. That's not the case anymore. If you're aiming higher than .net framework 4.x, you have the option of either self-contained package (your app + .net core - min 70MB - appimage approach), or framework dependent (requires .net version at installation - flatpak approach). I find the "things are not shared" section a bit…
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…
I recommend just shipping everything you need with your app, either manually or using AppImage. Flatpack is, more or less, just a bad package management.. technology.