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…
Flatpak Is Not the Future
91–100 of 410 posts
Re: Flatpak Is Not the Future
#92My 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…
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
#93Earlier 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.
Re: Flatpak Is Not the Future
#94Earlier 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…
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
#95Earlier 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.
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
#96This 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
#97Re: Flatpak Is Not the Future
#98A 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
#99From 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…
Re: Flatpak Is Not the Future
#100Earlier 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