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

191–200 of 410 posts

Re: Flatpak Is Not the Future

#191

Post by rkeene2 »

mjg59 wrote: post #150

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…

AppFS [0] solves this by just providing every file any package needs, including libc.

AppFS lazy fetch self-certifying system with end-to-end signature checks way to distribute packages over HTTP (including from static servers) so it's federated.

Since all packages are just a collection of files, AppFS focuses on files within a package. This means if you're on Alpine Linux and want to run ALPINE from Ubuntu (assuming Ubuntu used AppFS) then it would use Ubuntu's libc. This is pretty similar to static linking, except with some of the benefits from dynamic linking.

CERN has a similar, but more limited system called CernVM-FS [1]. AppFS isn't based on that and I only learned about it after writing AppFS.

AppFS is based (in spirit, not in code) on 0install's LazyFS. Around the turn of the century I was trying to write a Linux distribution that ONLY used 0install, but due to limitations it wasn't feasible.

This is possible to do with AppFS and how the docker container "rkeene/appfs" works.

[0] https://appfs.net/

[1] https://cernvm.cern.ch/fs/

Re: Flatpak Is Not the Future

#192

Post by gnulinux »

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.

E.g. factorio is compiled for linux.

Re: Flatpak Is Not the Future

#193

Post by Joker_vD »

nousermane wrote: post #183
mwcampbell wrote: post #163

Earlier quoted context omitted.

> but if we want good cross-distribution support we're still going to be limited to what's shipping in the oldest supported version of RHEL. Why should that requirement be considered so extreme when, in the Windows world, applications are often required to work as far back as Windows 7 (or were until a year or two ago)?

On Windows, .dll files are automatically searched in quite a few places, including current directory, directory where .exe was launched from, and PATH environment variable. Meaning it is far easier for apps to ship private libraries. Plus, when linux apps try to ship private libraries, as official chrome packages do, that gets quite some backlash from distro maintainers.

And on Windows the default way to bundle an application is "make a separate directory for that application, put everything you need inside it" which is kinda equivalent to Linux "/opt" packages, IIRC? Anyway, that neatly combines with the lookup rules for .dlls (they're first searched next to the executable file itself) so that shipping mostly self-contained applications is sorta easy: the applications by default use their packaged libraries, and if those are missing, the system libraries or libraries from PATH are used.

Re: Flatpak Is Not the Future

#194

Post by AnIdiotOnTheNet »

southerntofu wrote: post #162
AnIdiotOnTheNet wrote: post #118

Earlier quoted context omitted.

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

> 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's not at all my experience with Windows or MacOS. Sure some older apps work fine, but certainly not all of them.

The vast majority of them do, in my experience. Especially if you take into consideration how badly it doesn't work in Linux Desktop. You cannot usually even run a binary compiled for the previous version of your distro on the latest one!

Re: Flatpak Is Not the Future

#195

Post by yoz-y »

addicted wrote: post #133
hules wrote: post #34

Earlier quoted context omitted.

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.

That still does not change the argument that file size does not matter. 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).

Not sure about MacApp Store, but on iOS they do trim archs and assets as needed.

Re: Flatpak Is Not the Future

#196

Post by tapoxi »

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.

My experience with AppImages is fine, but I prefer Flatpaks because they can be updated with a remote.

My installs of Signal and Firefox are with Flatpaks and GNOME Software transparently handles updating both.

Re: Flatpak Is Not the Future

#197

Post by oleg_antonyan »

southerntofu wrote: post #170
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…

> Open Build Service I heard about that before, but never tried. How in practice do you deal with conflicting library versions? > It just doesn't look like "the future of application distribution", https://nixos.org/ does. Strongly agree. I just find it sad that nix/guix doesn't have proper desktop integration (to my knowledge), and that nix requires nixGL hacks to start any GUI on foreign distros.

Basically you write spec file for rpm (or debian/control for deb) and put your dependencies there as usual. But for each supported distro you can override packages names in OBS project config, so if the same package called differently in another distro you substitute it without modifying spec-file. Here's how it looks: https://build.opensuse.org/projects/home:oleg_antonyan/prjco...

It's a mess, without meaningful documentation and lots of bugs I've spent hours digging the source code to get any idea of how to use it.

I build everything static except Qt. My project is small enough with only 4 external libraries, so it's ok atm.

Re: Flatpak Is Not the Future

#198

Post by antihero »

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

Re: Flatpak Is Not the Future

#199

Post by lobstrosity420 »

Unfortunately, Flatpaks are the new SystemD. As in, a solid technology which solves real world problems but will face immense resistance from a community filled with splinter groups that have their own pet technology on the same niche, and will accept absolutely nothing else as an alternative. There is simply no path to standardization in this community other than big players like Red Hat and Canonical strong arming their pet technologies in, much to the disdain of everybody else.

As for me I'll keep using Flatpaks as they work great and have wide support. Alternatives are either obnoxious to use (Nix and Guix) or lacking in basic functionality (Appimages).

Re: Flatpak Is Not the Future

#200

Post by bogwog »

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 lot like executables on Windows, where you can just download any exe from anywhere and expect it to just work. Sure, the large size can be a problem, but not every appimage will necessarily end up that huge.

The lack of sandboxing isn't a big deal in my eyes because as the author mentioned with Flatpaks, most apps end up with too many permissions anyways. Proper sandboxing needs some kind of gate keeper/moderator to pressure developers into following the rules. This can be done with app stores, but the only working app store for Linux desktops is Steam, and that's only for games. (to be fair, KDE Discover works, but it's a very poor user experience)

Post reply on HN