Flatpak Is Not the Future • Hacker News Board

Re: Flatpak Is Not the Future

#241

Post by necovek » Tue, Nov 23, 2021, 3:52 PM UTC

AnIdiotOnTheNet wrote: post #118

necovek wrote: post #22

The most important takeaway from this is, to me, the need to separate sandboxing from dependency management. However, as can be seen with AppImage, which seems to be strictly focused on dependency management, that results in bloat. It would be great if we could have a sandboxing solution that ignores the dependency management altogether. The problem is not with Flatpak or Snaps (or Docker). The problem is that the fr…

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

You must have missed all the articles on the huge effort Microsoft went to to maintain backwards compatibility (like that famous SimCity story).

I can't find the original article anymore, but you can find references to it on Joel Spolsky's blog:

- https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

- https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

Referenced posts probably live somewhere on https://devblogs.microsoft.com/oldnewthing/ today, but the quoted snippets should tell you that it's not that easy at all, and that Microsoft is investing heavily in maintaining it.

Re: Flatpak Is Not the Future

#242

Post by gopher_space » Tue, Nov 23, 2021, 3:53 PM UTC

WastingMyTime89 wrote: post #187

gens wrote: 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.

You are replying to a comment explaining to you why Flatpak actually works with a dismissive sentence implying it's just a bad technology. Do you have anything substantive justifying your opinion? From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change. Despite being centered around technology, a very vocal part of the Linux community seems to be extr…

> Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative.

A working system calls for a conservative viewpoint. I'm only looking to introduce change if my needs aren't being met.

Re: Flatpak Is Not the Future

#243

Post by goohle » Tue, Nov 23, 2021, 3:54 PM UTC

kirbyfan64sos wrote: post #102

capableweb wrote: post #24

Earlier quoted context omitted.

> You can't do that with a .deb! Pretty sure you can by doing "dpkg --root=$HOME -i mypackage.deb" or something like that, long time ago I used dpkg, but it should be possible with some flag. Otherwise I agree, Flatpak is a breath of fresh air!

This often doesn't really work in practice on its own at least, since packages tend to hardcode their in installation directories. (You could try using an overlayfs, but at that point it's becoming pretty cumbersome.)

You can recompile package from source to support installation into `~/.local` (see `man 7 file-hierarchy`), but burden to support this will be on you, including updates, protection from malware and viruses, firewalling, and so on.

For example, rust's cargo can compile and install applications into `~/.local`, but it's pain to keep them up to date, so I prefer to use same tools from my OS (Fedora) distribution repo instead.

Re: Flatpak Is Not the Future

#244

Post by whoknowswhat11 » Tue, Nov 23, 2021, 3:56 PM UTC

WastingMyTime89 wrote: post #187

gens wrote: 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.

You are replying to a comment explaining to you why Flatpak actually works with a dismissive sentence implying it's just a bad technology. Do you have anything substantive justifying your opinion? From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change. Despite being centered around technology, a very vocal part of the Linux community seems to be extr…

And a lot of the complaints about both are very generalized. "Flatpack is bad package management technology" tells you very little about what is wrong with it.

Systemd was such an improvement over the existing speghetti for folks selling / supporting linux that it was a pretty clear takeoff.

Flatpack seems a bit more focused than snaps. The usability issues with snaps kind of surprising given ubuntu has usually had a good user focus. One thing, Fedora has their silverblue / ostree type distribution initiative, which may reduce their use case for using things like flatpack for printer subsystems etc (snaps seem more flexible). I moved off linux desktop a year ago though so not at all current unfortunatly.

Re: Flatpak Is Not the Future

#245

Post by sdfghderwg » Tue, Nov 23, 2021, 3:58 PM UTC

> I implore you, do not use these packaging tools. Don’t add their services to your Linux distributions, don’t use apps packaged this way, and don’t ship apps that use them. Mass containerization and alternate runtimes cannot possibly be the future of desktop apps on Linux. If this is really the direction it’s going, the future will be so shitty that we’ll all end up back on macOS or Windows.

As a long time desktop user, I've dropped Ubuntu for Debian because of this. At some point in the past Ubuntu seemed like it was going all in on snaps. I don't know what they're doing now, but I don't care any more.

Re: Flatpak Is Not the Future

#246

Post by nonameiguess » Tue, Nov 23, 2021, 3:58 PM UTC

simiones wrote: post #173

zimbatm wrote: post #40

There is a deep trend happening in software development. As the number of dependencies for building an application grows, it becomes exponentially harder to shake the tree. This used to be the role of Linux distributions, they were acting as a push-back force, asking projects to support multiple versions of C libraries. This was acceptable because there is not C package manager. Now that each language has their own p…

> On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API. This is a very good observation I think. Basically, what Linux distributions have failed to do is to create a higher level SDK for their platforms - instead, they rely on a soup of libraries and on the package maintainer model to know which of these is which. Basically, they are failing to…

I don't think this is really true. There is a fairly stable core set of C libraries present on virtually any Linux distro with a desktop environment that does most of what any application needs in terms of system services. The basic problem is more what the parent was discussing: these are C libraries, and rather than using the FFI for their app language of choice and using these pre-installed libraries, developers would rather rewrite all functionality in the same language as their applications, and the Rust crate, Go mod, or Node package you find when Googling whether something exists in your language of choice is likely to be much less stable than something like libcurl.

Mac and Windows solve this by creating their own languages for app development and then porting the system services to be provided in Swift and C# or whatever in addition to the original C implementation. There is no corporation behind most Linux distros willing to do that other than Canonical and Redhat, but they're perfectly happy to just stick with C, as is Gnome (KDE being perfectly happy to stick with C++). Most app developers are not, however.

For what it's worth, Redhat did kind of solve this problem for the Linux container ecosystem with libcontainer, rewriting all of the core functionality in Go, in recognition of the fact that this is the direction the ecosystem was moving in thanks to Docker and Kubernetes using Go, and now app developers for the CNCF ecosystem can just use that single set of core dependencies that stays pretty stable.

Re: Flatpak Is Not the Future

#247

Post by LinAGKar » Tue, Nov 23, 2021, 3:58 PM UTC

>Note that the app package itself is only 4.4 MB. The rest is all redundant libraries that are already on my system.

The author promotes avoiding this redundancy by using the libraries on the host. But maybe we should go the other way, by having only the bare necessities to run the OS installed on the host, and install all applications as Flatpak.

I agree with some things though. Different versions of the runtimes should share as much as possible, so as to consume as little space as possible, and libraries retaining backwards compatibility would help with this. And applications should target the regular Freedesktop/GNOME/KDE runtimes if possible, Fedora shouldn't be doing their own thing completely separate from Flathub. And we need to get applications to use portals and not allow them to declare file system access on install time.

Re: Flatpak Is Not the Future

#248

Post by mceachen » Tue, Nov 23, 2021, 4:00 PM UTC

tapoxi wrote: post #196

gens wrote: 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.

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.

FWIW, PhotoStructure has an AppImage edition and it can upgrade automatically in-place.

(There's also a docker image, a macOS DMG, a Windows installer, and other editions as well--and yes, you can configure any edition to _not_ upgrade automatically if you prefer).

Re: Flatpak Is Not the Future

#249

Post by goohle » Tue, Nov 23, 2021, 4:02 PM UTC

AnIdiotOnTheNet wrote: post #113

drran wrote: post #101

Earlier quoted context omitted.

Maintainers are not developers, they are users, so the developer cannot push unwelcome changes, such as ads, trackers, trojans, backdoors, keyloggers, etc. directly to users because the maintainer will refuse to accept that.

On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software, and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained"), which reflects poorly on the developer in the mind of the user. I personally see no upside to shoving an unpaid third party between user and developer.

> On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software,

Such maintainer will be kicked off from distribution.

> and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained")

Developer wishes are developer wishes. User wishes are more important. If package has a maintainer, then it IS maintained.

You can use any distribution developed by developers (do you know any?) if you dislike maintained distributions and share experience with us.

Re: Flatpak Is Not the Future

#250

Post by silon42 » Tue, Nov 23, 2021, 4:07 PM UTC

fullstop wrote: post #223

enriquto wrote: post #216

Earlier quoted context omitted.

apt is not misleadingly advertised as a sandboxing environment. Flatpack is: "Flatpak: Linux application sandboxing and distribution framework " [0] "It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system." [1] The whole point of a sandboxing environment is that you can run applications that do not want to be sandboxed. The flatpack prop…

Trust of the packager is still involved, no?

Yes, but only for things you give access to (data files, internet)... sandboxing by default, it should not be able to do anything except consume CPU (memory needs to be limited also, which might be an issue in practice).