Live data from Hacker News

Flatpak Is Not the Future

ludocode.com

91–100 of 410 posts

Re: Flatpak Is Not the Future

#91

To be fair most of that is a result of an ecosystem of idiots and not of the fundamental design itself. It has a namespacing feature, so f-ck'n use it. Instead, they intentionally produce collisions. Providing and sharing common runtimes could have worked pretty well if developers actually used a small set of common runtimes instead of picking from one of a gazillion slightly different rebuilds. As a replacement for…

Game consoles are a stable universal base system, hence why game studios prefer them to regular home computers.

Re: Flatpak Is Not the Future

#92

My experience with these is terrible. I install a JetBrains IDE via a package. I spent a very long time trying to debug a CMake problem that I assumed was my inexperience with CMake. After attacking various processes with strace, it dawned on me that the problems were caused by the IDE not being able to see files in /usr/local. A sandboxed dev environment! Lost for words... A relatively inexperienced dev would have a…

This is the biggest problem with these containers at the moment, you don't get any feedback what permissions are missing, first you need to understand this is a permission problem with the container itself and then to understand what permissions are missing and then apply them correctly.

For flatpak there is an api you can use to change permissions but for snap what I can remember that is not something you, the user, can change, that is up to the maintainer to enable them.

Applications like an IDE uses a lot of different resources so I gave up on using that as a flatpak, luckily Jetbrains ships their IDEs as tar.gz binary package you can use instead.

Flatpak works best when the application is very self contained, like Spotify, it streams music from an internet service, it doesn't require any special permissions.

I used Bitwarden as a flatpak, it had limited file access with one granted directory (Downloads), I was going to download an attachment from the Bitwarden application, the file saving dialog started one directory up from Downloads, you had to pick and open the Downloads directory first before saving, however I managed to save my attachment in that starting location outside of Downloads, some void directory that I never found.

Re: Flatpak Is Not the Future

#93
post #77
post #47

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.

[deleted]

Re: Flatpak Is Not the Future

#94
post #50
post #14

Earlier quoted context omitted.

The article's main opposition is to containerization and not portals - the author would like having an API for portals (a stable libportal?), but likes that approach overall. The problem is that we still need a solution to stop hacked apps from calling fopen() on unrelated files. The article ignores how bad the native runtime security solutions are - SELinux is nigh unusable, no distro has many apparmor profiles, etc…

It took android years and billions of dollars to get to the state it is at. Flatpaks and portals are moving towards that direction (according to my non expert opinion). All this friction and complaints, is just normal for such a big transition in how desktop apps should be written. I remember android devs going up in arms when there were significant API changes in past android versions. The situation for linux looks…

The annoying thing with android is that- even in the J2ME days, blackberry had a more sophisticated, fine grained per-app permission system that was easy to find and adjust at any time.

Android and iOS have been playing catchup ever since... Linux I at least will cut some slack, given its age and origins, though it would really have been nice had they addressed security by now. The situation can only get worse, but sooner or later something will happen that will encourage breaking backwards compatibility, I hope.

All that said, I praise the sun every day that I'm not writing BB apps or j2me anymore, so there's that at least.

Re: Flatpak Is Not the Future

#95
post #83

Earlier quoted context omitted.

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.

The choice being stuck with what a specific Windows version has available and using OS APIs directly instead of C ones, e.g. ZeroMemory() instead of memset(), as the C runtime library isn't part of the OS.

Yes, I was only talking about Win32 and .NET, which is always bundled in windows (Obviously newer versions of the OS may have newer versions of them).

How C libraries work has never been a problem I have encountered (I do deploy C++ libraries with apps though, and the tendency to move to "all apps deploy a full copy of whatever runtimes they need" is a much better situation for all 3 parties involved (developers, users and hackers...).

I get the point of memset (although that particular example I believe is now an intrinsic).

Re: Flatpak Is Not the Future

#96
> If you are a Linux distribution maintainer, please understand what all of these solutions are trying to accomplish. All your hard work in building your software repository, maintaining your libraries, testing countless system configurations, designing a consistent user experience… they are trying to throw all of that away. Every single one of these runtime packaging mechanisms is trying to subvert the operating system, replacing as much as they can with their own. Why would you support this?

This sound like a luddite that is against machines. How about embrace the revolution and then you can save a huge amount of work and focus on other things. There are enough things distor people could focus on instead.

I don't buy any of the technical arguments here and it sounds mostly like moralizing argument rather then anything else.

Re: Flatpak Is Not the Future

#97
Feel like we’ve really missed an intermediate solution based around tree-shaken statically compiled code. A lot of the goals achieved by docker et al could be met with some kind of multi-elf file format that is basically a collection of statically linked executables combined with a way to read built-in configuration files. Maybe this already exists / works.

Re: Flatpak Is Not the Future

#98
End users do not care about this. If the download works then they are happy.

A non-flatpak example is Electron. No one cares how big it is. It works.

I download huge games from Steam all the time and have never looked at the size of a game even a single time... in years. Disk space is still cheap on end users machines.

As long as the calculator works I do not care how much disk space it takes up.

Re: Flatpak Is Not the Future

#99
post #30

From my subjective (user) point of view, flatpak is pretty fine. Yes, I do get annoyed whenever I run flatpak update and see 5-10 updates to drivers or runtimes in the range of ~100MB each. But I also want applications to be "just working". What kinda annoys me though is that file dialogs open in the background. Now I am used to check for it, but when the main window is still in front, yet blocked, because focus is i…

The file dialog issue is fixed in xdg-desktop-portal-gtk 1.10: https://github.com/flatpak/xdg-desktop-portal-gtk/pull/347

Re: Flatpak Is Not the Future

#100
post #74

Earlier quoted context omitted.

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

Because installing an rpm allows you to run arbitrary code as root. Installing a flatpak does not. I mean there are many more reasons but that should be en.
Post reply on HN