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

391–400 of 410 posts

Re: Flatpak Is Not the Future

#391

Post by danShumway »

nickelpro wrote: post #351
lobstrosity420 wrote: post #229

Earlier quoted context omitted.

Overlap in functionality does not equal competition. They exist so that app developers can get their work out to users without cooperating with downstream packagers yes, but that does not keep anyone from packaging applications using the traditional methods.

Exactly, app developers who opt for flatpaks no longer have to give a damn about downstream. App uses an ancient version of OpenSSL that downstream won't package? No problem, use a flatpak. App needs symbols from a dropped API in ImageMagick and downstream won't package the out-of-date library? No problem, use a flatpak. When app developers needed to work with downstream, end users won because it forced app developer…

> app developers who opt for flatpaks no longer have to give a damn about downstream

As opposed to today, where app developers definitely don't just tell users to run:

  sudo apt-key  --keyserver hkp://:80 --recv 
  sudo add-apt-repository 'deb [arch=amd64] https:// multiverse'
Or even more simply:

  sudo apt install ./mydownloadedpackage.deb
People can correct me if I'm wrong, but I think Ubuntu even allows double-click installs of downloaded Debian packages. Is there a complexity here that I'm missing?

----

As far as I can tell, the parts of distribution that Flatpak makes easier aren't the literal distribution parts. Yes, they make it so you need to create fewer bundles (just Flatpak instead of deb, rpm, etc...). But they're more about the containerization than the distribution, if all you care about is distributing Debian packages outside of the official repos, that isn't necessarily that hard of a problem. I think you can even host a custom package source on a static site through Github pages, you don't even have to pay for the server.

The big change here is that you don't need to share dependencies, but importantly, you already didn't have to share dependencies, Linux apps could already embed unsupported system dependencies that they wanted to use, and many of them (particularly games) already did.

This makes that process easier, which you may view as a negative, but another benefit of that is that easy linking with Flatpak runtimes means applications are more likely to link to those libraries in a more inspectable way, and it's easier to at least audit the applications that were already bundling these dependencies before.

Re: Flatpak Is Not the Future

#392

Post by mjg59 »

badsectoracula wrote: post #372
mjg59 wrote: post #232

Earlier quoted context omitted.

Sure, you could dlopen() different SONAMEs until you find one that works, and now you just have to somehow deal with the structs having changed between versions, and the prototypes of functions not being compatible, so yes it's technically possible but nobody is going to bother

The idea isn't to open dynamic libraries randomly but to open dynamic libraries you explicitly know they provide the newer than 3 years functionality you want. It isn't some fantastic never-seen-before concept, it is how applications on Windows can use new APIs from Windows 11 while still running on Windows XP or how OpenGL programs can use APIs from OpenGL 4.6 while being able to run on drivers that only expose Open…

Yes, and for the reasons I expressed it doesn't work that way for most libraries under Linux.

Re: Flatpak Is Not the Future

#394

Post by f1refly »

oynqr wrote: post #312
smoldesu wrote: post #264

Earlier quoted context omitted.

Counterpoint: Flatpak doesn't really solve anything, and I have no reason to use a Flatpak'd version of a software when there's a native version in my system repos. A lot of people feel this way: they see it when Flatpak doesn't adopt their native system theme, they see it when they try opening a filepicker and it starts in some esoteric location, they see it when they want to edit files of a Flatpak'd app and need t…

Apps not adopting to your theme is a feature, at least when you ask some Gnome devs.

The typical user also doesn't want file picker thumbnails when you ask the Gnome devs ;)

Re: Flatpak Is Not the Future

#395

Post by simiones »

badsectoracula wrote: post #390
simiones wrote: post #385

Earlier quoted context omitted.

Forwards compatibility is basically non-existent in the software world. It's not like you can compile a Win 10 program and expect to any time run it on Win 7.

Actually you can, as long as it doesn't use Win10 APIs (or use them via dynamic loading) it will work on Win7. The issue with glibc is that when you use it it adds requests for the latest versions of the exported symbols that the glibc you use in your system has. You can work around this in a variety of ways (e.g. use __asm__ to specify the version you want and use the header files of an older glibc to ensure that yo…

Actually you're right, I forgot that we used to ship software to various versions of Windows with just a single build based on more or less the latest VC++ runtime (that had re-distributable versions for all intended targets).

Re: Flatpak Is Not the Future

#396

Post by ho_schi »

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…

My experience with Flatpak is okay, the payload by runtimes is okay and it works. What worries me is the actual amount of files within /var/lib/flatpak, for 23 packages (apps and all depdencies) it is about a half million files. This a problem, moving /usr now takes a lot time. I think Flatpak applies well for checking out new applications and closed-source binary applications. You don't want many closed-source applications within the official package-mangement and the core system, it also prevent their publisher to create distribution specific packages.

Good things require always hard work, there is no magic solution. I appreciate API and ABI stability and slick package management of Linux distributions. The work of developers and package maintainers make this possible. This is the reason why Linux is efficient and comfortable. This is not a magic solution but work. And it makes efficient distributions possible.

The grass is green on the other side?

On Windows you have to install all automatic updates or new applications will not run. If you don't do this you will face errors about missing C#-Runtimes or a C++ Redistributable. And application developers need to ship dependencies within the application. This is the reason why Windows is so fat, why applications are fat and the usage of a permission system is not possible. The article doesn't states this.

MacOS on the other hand? The break compatibility every few years. MacOS Classic to MacOS X, Quartz, PPC, Intel and finally M1.

Android and iOS had the luck to be new. Permissions work, if they aren't requested all. But still, iOS fails to provide file-system access, file handling is burden for users and backups are impossible. Apps haven grown quickly into being fat. Garmin Connect, an app which cannot do anything without cloud, 340 MB. Do yourself a favor an check what your banking app requires, you won't get away with less than 200 MB and only the good ones can show you our balance locally - which requires how many kilobytes to store? Messengers like Signal are also growing an growing, Signal is right about 170 MB.

Back to Linux:

I can only appreciate the path to system wide ABI/API stability on Linux, with Systemd, GLIBC, LIBSTDC++ valuing stability and the recent changes around Gtk3 and Gtk4 the situation may become even better. I think Flatpak can be improved, it should be improved. But we don't need another competing standard, before we didn't tried hard to improve the existing solution.

I hope that at one day Canonical will start collaborating with the community and especially Red Hat, they always implement a less favorable solution (Mir, Unity, Snap, Upstart...) lose and harm Linux. Collaborate with Flatpak, add a payment solution and share the revenue with Red Hat and others?

Re: Flatpak Is Not the Future

#397

Post by brnt »

jhaygood86 wrote: post #348
brnt wrote: post #317

Earlier quoted context omitted.

So many flatpaks do this incorrectly though. For Browser by default saves in the flatpaks home/Downloads directory (which is 15 layers deep from ~). You just gotta know to navigate up. Signal let's you save attachments anywhere on disk, but only if you manually navigate to ~/Downloads, does it actually save (in a way visible and accessible outside of the app). You just gotta know. I forgot what exactly the problem wa…

The apps that are "broken" are apps that are not "Flatpak native", so assume they have full write access to ~ Flatpak aware apps (like the ones I develop, or any on elementary OS since flatpak is the native packaging format there) tend to just work.

It's not true they assume full write access to ~, they just don't propagate they limitation of a constricted choise of paths in their GUIs. Because they isn't a way to do that, GUI toolkits don't really provide a way to clearly communicate you can only save/open in a specific dir.

Re: Flatpak Is Not the Future

#398

Post by ltbarcly3 »

panick21_ wrote: post #360
ltbarcly3 wrote: post #354

Earlier quoted context omitted.

I guess Canonical, who makes 100% of their revenue on support contracts for open source software, doesn't release the snap server code in open source because... what's the reason you are going to come up with? What possible reason is there apart from making it difficult for anyone else to set up any repository at all? It's the same reason they bet big on Ubuntu on Phones. App stores are worth a ton of money, you cont…

I don't care about Snap, only Flatpak.

Good for you, here is some candy?

Re: Flatpak Is Not the Future

#400

Post by Andrex »

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…

The new Gnome Software in Gnome 41 does include a serious warning label on Gimp now, for the record.
Post reply on HN