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

401–410 of 410 posts

Re: Flatpak Is Not the Future

#401

Post by Andrex »

LinAGKar wrote: post #247

>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 sh…

> 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 believe this is the approach Endless OS and Gnome OS are using.

Re: Flatpak Is Not the Future

#402

Post by ltbarcly3 »

panick21_ wrote: post #399
ltbarcly3 wrote: post #398

Earlier quoted context omitted.

Good for you, here is some candy?

Your arguments simply don't hold any water when we are talking about Flatpak. So I guess you can have candy but no water.

Just announcing that you think something you disagree with is wrong isn't an argument at all. I know you think my arguments are wrong since you are disagreeing. The only reason you have given for thinking they are wrong is that you don't think they are convincing. This may be because you have a secret reason you don't want to share, but I believe it is more likely you are more interested in being disagreeable than in understanding.

Re: Flatpak Is Not the Future

#404

Post by badsectoracula »

mjg59 wrote: post #392
badsectoracula wrote: post #372

Earlier quoted context omitted.

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.

OpenGL worked on Linux last time i checked (a few minutes ago).

Linux isn't some special case that makes this impossible, the only reason for this to not work is libraries themselves not making it possible. But the blame lies with the libraries not with Linux.

Re: Flatpak Is Not the Future

#405

Post by mjg59 »

badsectoracula wrote: post #404
mjg59 wrote: post #392

Earlier quoted context omitted.

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

OpenGL worked on Linux last time i checked (a few minutes ago). Linux isn't some special case that makes this impossible, the only reason for this to not work is libraries themselves not making it possible. But the blame lies with the libraries not with Linux.

Like I said, it's technically possible and that is (outside a very small number of well-defined outliers like OpenGL) entirely irrelevant in terms of whether it's practically possible. Even if we rewrote every library now to have mechanisms to make this easier, it wouldn't help for any of the older versions that don't do this and which are already deployed everywhere.

Re: Flatpak Is Not the Future

#406

Post by FengLengshun »

smoldesu wrote: post #264
freebuju wrote: post #147

Flatpak is the future of Linux desktop applications for so many reasons, but among them it allows users not to be caught up in the dependancy mess that plagues Linux distributions. Some of the criticism here does not belong to Flatpak. E.g Fedora's weird duplication of repositories is exclusively a Fedora problem. Has absolutely nothing to do with Flatpak. Applications such as VLC and GIMP which 'ship' with access to…

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…

I used to have the same opinion, up until I get how things work with Flatpak apps better.

It was so confusing at first as to why saved files sometimes don't appear in the right directory. Then I learned about Flatseal, which I used in initial setup and whenever some things don't work right. It gives me a nice and simple GUI way of managing permissions, which I like as a layman.

Theming was confusing at first. The best I could do initially was setting env variable on Flatseal with GTK_THEME=Adwaita:dark, until it clicked to me that the config folder inside ./var/app/flatpak.app.name/ folders is the config folder they access instead of ~/.config so I could just copy-paste the gtk-3.0 (or 2.0, 4.0, or all of them) folder in ~/.config to get theming to work.

The only thing that I haven't figured out yet is Native Host Messaging or whatever it's called, that's needed for connecting with things like Global Menu and Plasma/GNOME Integration extensions on browsers.

It was a hassle at first, but like learning Linux, I just learn it bit by bit. And now I like it because at least there's an easy way for me to find and get the apps I want. It's easier to deal with than Snap and AppImage for me now. Hell, my experience dealing with dependency issues with CrossOver on Arch made me wish they have a Flatpak so I don't have to deal with it.

Re: Flatpak Is Not the Future

#407

Post by badsectoracula »

mjg59 wrote: post #405
badsectoracula wrote: post #404

Earlier quoted context omitted.

OpenGL worked on Linux last time i checked (a few minutes ago). Linux isn't some special case that makes this impossible, the only reason for this to not work is libraries themselves not making it possible. But the blame lies with the libraries not with Linux.

Like I said, it's technically possible and that is (outside a very small number of well-defined outliers like OpenGL) entirely irrelevant in terms of whether it's practically possible. Even if we rewrote every library now to have mechanisms to make this easier, it wouldn't help for any of the older versions that don't do this and which are already deployed everywhere.

Of course it is practically possible, as long as the developers care about backwards ABI compatibility - the issue isn't if it is possible or not (it certainly is as actual existing APIs and libraries show), the issue is library developers breaking their libraries' ABIs.

But that doesn't mean it isn't possible to do something like this, it means that you have to stick to libraries that do not break their ABIs. And this has absolutely nothing to do with Linux you brought previously, everything i mentioned works on Linux and any other OS that supports dynamic linking and has ABI backwards compatibility for the applications that run on top of it.

Re: Flatpak Is Not the Future

#408

Post by mjg59 »

badsectoracula wrote: post #407
mjg59 wrote: post #405

Earlier quoted context omitted.

Like I said, it's technically possible and that is (outside a very small number of well-defined outliers like OpenGL) entirely irrelevant in terms of whether it's practically possible. Even if we rewrote every library now to have mechanisms to make this easier, it wouldn't help for any of the older versions that don't do this and which are already deployed everywhere.

Of course it is practically possible, as long as the developers care about backwards ABI compatibility - the issue isn't if it is possible or not (it certainly is as actual existing APIs and libraries show), the issue is library developers breaking their libraries' ABIs. But that doesn't mean it isn't possible to do something like this, it means that you have to stick to libraries that do not break their ABIs. And th…

RHEL 8 doesn't ship with GTK 4. How do I ship an application that uses functionality that only exists in GTK 4 if available, but falls back to GTK 3 if it isn't? If libraries had been written with this in mind (like OpenGL was), then yes, there'd be a path to doing so. Libraries on Linux could work in the way you suggest. But, for the most part, they don't.

Re: Flatpak Is Not the Future

#409

Post by badsectoracula »

mjg59 wrote: post #408
badsectoracula wrote: post #407

Earlier quoted context omitted.

Of course it is practically possible, as long as the developers care about backwards ABI compatibility - the issue isn't if it is possible or not (it certainly is as actual existing APIs and libraries show), the issue is library developers breaking their libraries' ABIs. But that doesn't mean it isn't possible to do something like this, it means that you have to stick to libraries that do not break their ABIs. And th…

RHEL 8 doesn't ship with GTK 4. How do I ship an application that uses functionality that only exists in GTK 4 if available, but falls back to GTK 3 if it isn't? If libraries had been written with this in mind (like OpenGL was), then yes, there'd be a path to doing so. Libraries on Linux could work in the way you suggest. But, for the most part, they don't.

Well yes, you basically come to what i've been writing about so far: the issue is with libraries like GTK 4 that break ABI backwards compatibility. It isn't the issue with Linux, Linux doesn't break ABI backwards compatibility - if GTK 4 didn't break their ABI you could use the GTK 3 API as a baseline for your application and dynamically load the new GTK 4 stuff (and as a bonus you'd get any inherent improvements that might be there in GTK 4 that are exposed through the GTK 3 API, like how -e.g.- applications written for WinXP get the emoji input popup on Win 10 even though that didn't exist during WinXP's time).

The REAL problem is libraries breaking their ABIs, not Linux itself.

Re: Flatpak Is Not the Future

#410

Post by mjg59 »

badsectoracula wrote: post #409
mjg59 wrote: post #408

Earlier quoted context omitted.

RHEL 8 doesn't ship with GTK 4. How do I ship an application that uses functionality that only exists in GTK 4 if available, but falls back to GTK 3 if it isn't? If libraries had been written with this in mind (like OpenGL was), then yes, there'd be a path to doing so. Libraries on Linux could work in the way you suggest. But, for the most part, they don't.

Well yes, you basically come to what i've been writing about so far: the issue is with libraries like GTK 4 that break ABI backwards compatibility. It isn't the issue with Linux, Linux doesn't break ABI backwards compatibility - if GTK 4 didn't break their ABI you could use the GTK 3 API as a baseline for your application and dynamically load the new GTK 4 stuff (and as a bonus you'd get any inherent improvements tha…

If you're defining Linux as a kernel, then yes, the kernel does not impose any constraints on userland that would make this impossible - and I never said it did. If you're defining Linux as a complete OS, then the fact that it's conceptually possible for libraries to behave this way is irrelevant; they could, but they don't, and any solution for distributing apps needs to deal with that reality rather than just asserting that everything else should be rewritten first before anyone can do anything.
Post reply on HN