Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flatpak is not the future (2021)

ludocode.com

Post reply on HN
Print view View original

71–80 of 166 posts

Re: Flatpak is not the future (2021)

#71

Post by TOGoS »

One major headache with trying to run precompiled binaries on Linux is that if they were compiled using a newer version of glibc than the target machine, they won't be able to run. Back while working on Factorio, I was trying to get around this problem with endless Docker containers, but coworker Wheybags came up with a much simpler solution to this, which is simply to, at compile time, link to the oldest compatible version of glibc by including a header: https://github.com/wheybags/glibc_version_header

It's too bad this hasn't been standard practice for the past 30 years!

Re: Flatpak is not the future (2021)

#72

Post by prmoustache »

danShumway wrote: post #59
prmoustache wrote: post #51

Earlier quoted context omitted.

I don't know, the only flatpak packaged application I tried to use today is crashing at startup and it just makes it more annoying to debug and do an actual bug report. https://docs.flatpak.org/en/latest/debugging.html An average user would just say that app is shit, linux is shit, I go back to windows!

I guess millage may vary, the only thing I can say is that there are multiple instances (particularly GoG which the article seems to praise) that literally never work on some of my systems. The few times I've run into Flatpak crashes, they're architecture problems that would have been present in any version of the app, so I'd be doing that work regardless. They're harder to debug in Flatpak, but also heck debugging c…

But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro. Whenever I have an app available as rpm, I choose the rpm over the flatpak version, for space saving purpose mostly.

None of my apps crashes except one. And that is a piece of shit of a proprietary app that is not packaged by the distro maintainers: Microsoft Edge.

Re: Flatpak is not the future (2021)

#73

Post by nine_k »

AdmiralAsshat wrote: post #13

Just built a new Gaming Linux PC which is intended to replace my aging Dell XPS 13 as my daily driver. Decided to go all-in on flatpaks, as I've been trying to stay away from rpm-fusion. The Steam Flatpak has been an adventure, to say the least. I added a second SSD just for games that gets automatically mounted on boot, and I gather that having the games installed somewhere outside of steam's /home/ directory was no…

I would just bind-mount the appropriate part of the second disk as /home/steam, or whatever. I don't see why one should persuade a program to follow a complicated setup when the setup can just be made straightforward with OS tools.

Re: Flatpak is not the future (2021)

#75

Post by jcastro »

ekianjo wrote: post #18
jcastro wrote: post #10

Earlier quoted context omitted.

The disk space thing is a myth, once you start to install apps people actually use it ends up being about the same. If you test it with VMs you can check it out for yourself: https://www.ypsidanger.com/wasting-disk-space/

Tell me again when you dont end up with 20 different versions of Nvidia drivers

Your system should be cleaning up unused runtimes. That's perhaps a distribution integration issue that should be filed and fixed?

Re: Flatpak is not the future (2021)

#76

Post by kirbyfan64sos »

prmoustache wrote: post #51
danShumway wrote: post #41

This debate will never die, but while people have been complaining about it, Flatpak has quietly just become a better way to package software for end users. My criteria is that I'm a user, I don't care about what's elegant to developers -- and I have fewer problems with Flatpak than I have with non-Flatpak software. The vast majority of Flatpak problems I do have as a user come down to sandboxing permissions that I a…

I don't know, the only flatpak packaged application I tried to use today is crashing at startup and it just makes it more annoying to debug and do an actual bug report. https://docs.flatpak.org/en/latest/debugging.html An average user would just say that app is shit, linux is shit, I go back to windows!

These docs are a bit sparse and more for debugging some very specific things. If all you want is a stack trace:

- You can use `flatpak install --include-sdk --include-debug THE-APP` to install the SDK and debug info for an app - Then `flatpak-coredumpctl -m MATCH THE-APP` will use coredumpctl to open the matching coredump inside the corresponding SDK's gdb

Re: Flatpak is not the future (2021)

#77

Post by dale_glass »

pmontra wrote: post #69
dale_glass wrote: post #17

I think it's an unfortunate necessity for some kinds of applications. Eg, we make this: https://overte.org/ We're currently using AppImage because that was the first thing that worked for us, but most of the reasons are the same either way: We want to spend time developing the software, and that means it's hard to justify packaging every release for a dozen distributions. And I'd say nobody particularly wants to do i…

I install only debs because I don't want too much redundant code around and having to update all of it, if it ever updates. I prefer Debian to care about updating shared libraries. I make few exceptions, none for snaps and flatpacks so far. I installed Firefox from the tar.bz2 on their site, as I did with Windows before my switch to Linux in 2009. It auto updates and so far it's OK. I'm on Debian 11, I'll upgrade to…

We also have a build script that will automatically build it from source on most distributions if that's more to your liking.

It's less user friendly but on the good side you can use that to build pull requests or arbitrary commits.

Re: Flatpak is not the future (2021)

#78

Post by OJFord »

Is there anything that offers mobile-style sandboxing & permissions API like described?

I'd love that, but I'm not even sure how it would work, I don't want it via walled-garden app store where you basically have to target it as an extra platform, because of dealing with those APIs... It would need to somehow just sort of slot into Unix, and if you didn't have it 'enabled' on the system it would just plough on uncontrolled as it does today.

What's the story or usual recommended practice on NixOS? Seems like the overlap with security-minder types would be quite high, and if you did use something like Flatpak wouldn't that interfere with Nix's own management? (Or at least not use it.) (I didn't learn much from the Flatpak Nix wiki page.)

Re: Flatpak is not the future (2021)

#79

Post by lairv »

gumballindie wrote: post #33

Neither are snaps. The future, for regular daily use, are appimages. Much like MacOS dmgs, these are a "single" file (from an end user perspective) that you download, double click, and run. That's it. Ideally we'd see more work in this area. I am slowly trying to figure out how to automate builds for GUI apps and I am considering somehow settings up an inexpensive server to pull, package, and submit appimages to appi…

I've encountered appimages a few time and wasn't really convinced. Maybe I'm missing something but here's what I found annoying:

- need to move the x.appimage somewhere in your $PATH

- need to create an alias like nvim.appimage -> nvim

- no way to automatically update

- the application isn't listed in your application list on ubuntu

On the other hand `sudo snap install nvim --classic` brings me all of the above without any work from me

Re: Flatpak is not the future (2021)

#80

Post by jwells89 »

AdmiralAsshat wrote: post #13

Just built a new Gaming Linux PC which is intended to replace my aging Dell XPS 13 as my daily driver. Decided to go all-in on flatpaks, as I've been trying to stay away from rpm-fusion. The Steam Flatpak has been an adventure, to say the least. I added a second SSD just for games that gets automatically mounted on boot, and I gather that having the games installed somewhere outside of steam's /home/ directory was no…

Problems like this seem like a natural consequence of trying to mash together distribution and sandboxing, rather than leaving the sandboxing to the OS. It’s so much easier to build something that “just works” if you’re concerned only with distribution (really, it’s as simple as macOS style app bundles. Yes it takes a bit more space but the UX improvement is worth it).

Following this, it seems like there should be an XDG standard for sandboxing which distros are free to implement whichever way they feel is best. With that, Linux app packaging solutions need only worry about playing nice with that spec.

Post reply on HN