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

351–360 of 410 posts

Re: Flatpak Is Not the Future

#351

Post by nickelpro »

lobstrosity420 wrote: post #229
nickelpro wrote: post #224

Earlier quoted context omitted.

If flatpaks weren't in competition with packages repos they would serve no purpose. They are explicitly in competition with package repos. They exist so that app developers can get their work out to users without cooperating with downstream packagers.

Overlap in functionality does not equal competition. They exist so that app developers can get their work out to users without cooperating with downstream packagers yes, but that does not keep anyone from packaging applications using the traditional methods.

Exactly, app developers who opt for flatpaks no longer have to give a damn about downstream. App uses an ancient version of OpenSSL that downstream won't package? No problem, use a flatpak. App needs symbols from a dropped API in ImageMagick and downstream won't package the out-of-date library? No problem, use a flatpak.

When app developers needed to work with downstream, end users won because it forced app developers to keep up with the environment to meet the requirements of repo packagers. Flatpak is directly in contest with this, trading packaging efficiency and keeping apps up-to-date for app ossification and upstream convenience.

Re: Flatpak Is Not the Future

#352

Post by sandGorgon »

galcerte wrote: post #37
sandGorgon wrote: post #20

The short (but polite) rebuttal to this is - OSX. DMG files are similar sized and proven to be very successful. For e.g. - firefox ( https://www.mozilla.org/en-US/firefox/all/#product-desktop-r... ). Win64 installer is 50mb. MacOS installer is 130mb. Linux 64-bit is 70mb. Same is the case with Chrome - https://chromeenterprise.google/intl/en_US/browser/download/... . Windows MSI is 79mb. OSX PKG for the same is 195mb…

> This OTOH does not exist. Linux gamers are 1% of either the gaming market or the desktop computing market. All gamers either dual boot windows...or android. Even for those who game on Linux, they do it on an abstraction layer like Wine. Which is what Valve maintains First off, 1.13% of Steam users are on Linux [1], and given how many users Steam has, just 1% of that population should be able to make quite a fuss. S…

I'm on your side. I'm a Linux gamer..or rather used to be.

Until I saw this - https://news.ycombinator.com/item?id=28978086

Yeah sure, Linux gamers are more engaged, etc etc. But for a indie developer making games...it's like 5% of the market. Probably does not even recoup development cost.

I realised that I am probably doing a disservice to the indie gaming developers, by insisting on a militant stance.

Wine is fine. I'll just play it on Linux. Let them make more money.

Re: Flatpak Is Not the Future

#353

Post by sandGorgon »

andrepd wrote: post #39
sandGorgon wrote: post #20

The short (but polite) rebuttal to this is - OSX. DMG files are similar sized and proven to be very successful. For e.g. - firefox ( https://www.mozilla.org/en-US/firefox/all/#product-desktop-r... ). Win64 installer is 50mb. MacOS installer is 130mb. Linux 64-bit is 70mb. Same is the case with Chrome - https://chromeenterprise.google/intl/en_US/browser/download/... . Windows MSI is 79mb. OSX PKG for the same is 195mb…

That just not true. "All Linux users dual boot" where's your data to say that? "Nobody compiles for Linux" factually false, many of the most-played games on steam are Linux-native, and most others run flawlessly on Proton. And 1.2% is slightly more than half the mac market share on steam. Should mac users also be ignored?

Your data is wrong. I wish it were correct. But it's not.

OSX users are 2.56% of Steam. Linux is 1.13%

https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...

Re: Flatpak Is Not the Future

#354

Post by ltbarcly3 »

panick21_ wrote: post #167
ltbarcly3 wrote: post #145

Earlier quoted context omitted.

The whole point is that this is technically worse and only being used to try to bootstrap a walled garden where they (RedHat, Canonical for flatpack or snap) get paid a fee due to a monopoly on app distribution to their users. This is not 'the revolution' we should support. I encourage you to study the technical arguments until you understand them well enough that they become convincing.

> monopoly on app distribution to their users And the argument that it is a walled garden is simply nonsense. Its not monopoly any more then any default repository is. > I encourage you to study the technical arguments until you understand them well enough that they become convincing. I have been using flatpak since it came out and many other people in this thread have already pointed out the failure of the technical…

I guess Canonical, who makes 100% of their revenue on support contracts for open source software, doesn't release the snap server code in open source because... what's the reason you are going to come up with? What possible reason is there apart from making it difficult for anyone else to set up any repository at all?

It's the same reason they bet big on Ubuntu on Phones. App stores are worth a ton of money, you contribute effectively nothing and collect 25% of other company's revenue purely because you can lock out any competing app store.

Re: Flatpak Is Not the Future

#355

Post by necovek »

AnIdiotOnTheNet wrote: post #304
necovek wrote: post #277

Earlier quoted context omitted.

You started off by disagreeing that backwards compatibility is hard, because other platforms (like Windows or MacOS) can do it. When given evidence that it's at huge cost and investment that they manage to do that (basically an admission from them that it is hard — you may have a different definition of "hard" than I do), you seem to suggest that either they are not doing a lot of work towards compatibility or that t…

You misunderstand. I am saying that all that effort was spent chasing the long tail of compatibility, which is valuable if compatibility is one of your big selling points. However, one need not go to such extremes to get a good amount of compatibility, just don't have a policy of breaking ABIs constantly the way Linux Desktop does.

Ok, I see your premise now. I am not sure I agree: do you know of a system that has seen less investment on backwards compatibility yet successfully maintains it?

Of course, not "frozen" like TeX, but seeing active feature development too.

Re: Flatpak Is Not the Future

#356

Post by necovek »

pabs3 wrote: post #345
necovek wrote: post #278

Earlier quoted context omitted.

Thanks: bubblewrap seems to have been extracted from flatpak. The documentation seems to focus on filesystem access sandboxing. Is there something with practical suggestions on how to sandbox things like webcam access, clipboard, screen (for screen sharing/recording apps), networking... with bubblewrap? (I know some of that is visible in the filesystem, but not all of it is)

Look into Flatpak portals. I'm not sure how they work wrt bubblewrap, but they pass limited interfaces to various things into the container. Things on the host side then prompt the user for which webcam/etc the app should get access to. I think they are similar to Android intents in that the app can't ask for access to a specific thing, just for access to certain kind of things and then it is up to the user to choose…

Yes, I am familiar with portals and what they do: I was exactly wondering if bubblewrap contains something similar — it's been ages since I was involved with Linux system architecture (let's say I am stuck in the SysV init world, and I still go for "service apache2 restart" :)), so it'd be great if there was a quick introduction for someone wanting to use flatpak/snap style sandboxing without the dependency management and distribution channels.

Re: Flatpak Is Not the Future

#357

Post by raffraffraff »

fsflover wrote: post #214
goodpoint wrote: post #210

Earlier quoted context omitted.

There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have…

So basically all the same drawbacks as in Windows, when you install third-party software?

When I had to install my first AppImage I got a horrible déjà vu from my Windows XP days. The Linux repo experience is just better. Trust the repo via gpg and https instead of trusting every download url and scanning every blob for malware. Upgrade the whole system at once, instead of hunting down every new blob (and remembering where you got it).

Re: Flatpak Is Not the Future

#358

Post by necovek »

AnIdiotOnTheNet wrote: post #304
necovek wrote: post #277

Earlier quoted context omitted.

You started off by disagreeing that backwards compatibility is hard, because other platforms (like Windows or MacOS) can do it. When given evidence that it's at huge cost and investment that they manage to do that (basically an admission from them that it is hard — you may have a different definition of "hard" than I do), you seem to suggest that either they are not doing a lot of work towards compatibility or that t…

You misunderstand. I am saying that all that effort was spent chasing the long tail of compatibility, which is valuable if compatibility is one of your big selling points. However, one need not go to such extremes to get a good amount of compatibility, just don't have a policy of breaking ABIs constantly the way Linux Desktop does.

And let me address the "policy of breaking ABIs constantly the way Linux Desktop does."

As you probably know, there is no policy, and no "Linux Desktop" either. You've got Linux distribution releases that are supported for up to 10 years (like RHEL and Ubuntu LTS) by teams a couple of orders of magnitude smaller than either of MacOS or Windows. They usually get HWE kernel updates too (hardware enablement) from newer Linux series. By definition, they maintain ABI backwards compatibility for the duration of their support. If you care about it, that's what you should use.

But it's in the nature of free software world to want to mix and match, so the idea of a singular Linux Desktop does not exist. You should treat each one of them as a separate OS, which is unfortunate, but realistic. Flatpak/snapcraft recognise that to a point (packaging up everything but the kernel, regardless of the system packages already installed).

Re: Flatpak Is Not the Future

#359

Post by raffraffraff »

cunidev wrote: post #7

To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux. While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro. For example, the Elementary OS…

This validates an assumption that I had made: easier developers, harder for everyone else.

It's a pain in the ass packaging apps for each distro, but the value of a single command to update libraries and applications on millions of Linux systems is worth it, no?

Re: Flatpak Is Not the Future

#360

Post by panick21_ »

ltbarcly3 wrote: post #354
panick21_ wrote: post #167

Earlier quoted context omitted.

> monopoly on app distribution to their users And the argument that it is a walled garden is simply nonsense. Its not monopoly any more then any default repository is. > I encourage you to study the technical arguments until you understand them well enough that they become convincing. I have been using flatpak since it came out and many other people in this thread have already pointed out the failure of the technical…

I guess Canonical, who makes 100% of their revenue on support contracts for open source software, doesn't release the snap server code in open source because... what's the reason you are going to come up with? What possible reason is there apart from making it difficult for anyone else to set up any repository at all? It's the same reason they bet big on Ubuntu on Phones. App stores are worth a ton of money, you cont…

I don't care about Snap, only Flatpak.
Post reply on HN