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

71–80 of 410 posts

Re: Flatpak Is Not the Future

#71

Post by homarp »

faho wrote: post #48
andrepd wrote: post #39

Earlier quoted context omitted.

That just not true. "All Linux users dual boot" where's your data to say that? "Nobody compiles for Linux" factually false, many of the most-played games on steam are Linux-native, and most others run flawlessly on Proton. And 1.2% is slightly more than half the mac market share on steam. Should mac users also be ignored?

>"Nobody compiles for Linux" factually false, many of the most-played games on steam are Linux-native, and most others run flawlessly on Proton. The games that run on proton have not been compiled for linux.

linux native + proton means "some compiles for Linux[1], the rest either tests on proton (steamdeck should increase that segment at least) or does not care"

[1] https://news.ycombinator.com/item?id=28978086

Re: Flatpak Is Not the Future

#72

Post by legulere »

viraptor wrote: post #45

> 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…

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.

Re: Flatpak Is Not the Future

#73

Post by bayesian_horse »

Very valid points. But the average open source app developer or even a developer of a commercial application for linux just doesn't have the time, energy or money to keep installation instructions up to date and support those both with development time and by responding to issues.

Re: Flatpak Is Not the Future

#74

Post by zohch »

oleg_antonyan wrote: post #69

As Linux user and app developer (shameless plug https://github.com/olegantonyan/mpz/ ) I deliberately avoid snap/flatpak/appimage/etc. Instead, I suffer with Open Build Service https://build.opensuse.org/ . It's kind of cool, free and can build for multiple distros, but making it actually do so is a pain. But I still prefer this over flatpak&co both as user and as developer. It just doesn't look like "the future of a…

Why would you rather install some random rpm from someone you don't know as opposed to a flatpak?

Re: Flatpak Is Not the Future

#75

Post by johnchristopher »

capableweb wrote: post #68
johnchristopher wrote: post #64

Earlier quoted context omitted.

Where does that put the Deb files ? edit: should have written "where does dpkg put the files of the package ?" or "where does that put the Deb's files ?", sorry.

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?

Re: Flatpak Is Not the Future

#77

Post by kaba0 »

gens wrote: post #47
cunidev wrote: post #7

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.

Nah, AppImage still won’t run on all distros.

The only thing I think actually solves packaging is nix.

Re: Flatpak Is Not the Future

#78

Post by oleg_antonyan »

zohch wrote: post #74
oleg_antonyan wrote: post #69

As Linux user and app developer (shameless plug https://github.com/olegantonyan/mpz/ ) I deliberately avoid snap/flatpak/appimage/etc. Instead, I suffer with Open Build Service https://build.opensuse.org/ . It's kind of cool, free and can build for multiple distros, but making it actually do so is a pain. But I still prefer this over flatpak&co both as user and as developer. It just doesn't look like "the future of a…

Why would you rather install some random rpm from someone you don't know as opposed to a flatpak?

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

Re: Flatpak Is Not the Future

#79

Post by vetinari »

zimbatm wrote: post #40

There is a deep trend happening in software development. As the number of dependencies for building an application grows, it becomes exponentially harder to shake the tree. This used to be the role of Linux distributions, they were acting as a push-back force, asking projects to support multiple versions of C libraries. This was acceptable because there is not C package manager. Now that each language has their own p…

> 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.

Re: Flatpak Is Not the Future

#80

Post by alkonaut »

legulere wrote: post #72
viraptor wrote: post #45

> 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…

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.

Post reply on HN