Flatpak Officially Announced For "Next Generation Linux Applications"

[johnc]

You don't seem to even realize that the examples you gave are prime examples of projects who had to choose between libav and ffmpeg. As matter of fact, kodi explicitly only supported ffmpeg for a good while during the viability of the split.

https://www.reddit.com/r/kodi/commen...ation_most_of/

Mpv/Mplayer2/<insert derivative here> had to explicitly support both because they weren't compatible with each other for a time. FFmpeg eventually started supporting a compatibility layer. This wasn't always the case. Here: https://github.com/haasn/mpvhq-old/w...g-versus-Libav

obs-studio, a project I've had the luxury of contributing to in part, also had to make this decision for a time. Now, they use FFmpeg entirely since libav has been phased out. You clearly don't know what you're talking about.

Or perhaps if you gave an inkling of logic as to what you were talking about, you wouldn't sound like a complete idiot.

Umm... deciding which LIBRARY you use in your application is completely different than having two sets of code for each library so you can target multiple distributions, which is what you said. Kodi never used libav. It was always an ffmpeg project. Nor did they ever have a libav version of Kodi and an ffmpeg version. Kodi didn't even use system-installed libraries (nor did mplayer2), though XBMC did once make that option available. mplayer2, once they went to libav, was never again tied to ffmpeg, and libav was built into the package. The guy who maintained mplayer2 never had anything to do with ffmpeg once it was converted over to libav. Kodi and mplayer2 are cross-platform projects that bundle what they need right into their own packages. Exactly as Mez' said before you threatened to "punch him in the throat".

You seem to be conflating "having to choose between forks of a similar library" to being the same thing as needing these "flatpak" packages to target multiple Linux distributions.

[SpyroRyder]

I dislike the closed server and etc from Canonical (I hope that they will clarify all of that soon), but when it comes to the approach to fix the problem, I prefer the Snap packages. Both will keep existing, so it will be fun to see how both will evolve. But right now is AppImage the one than has the crown, its a great tool

May I ask why you prefer snap?

[stiiixy]

Okay, my general impression of FlatPak is the ability to package an app with the libraries it was develoed against, all in one convenient bundle, ready to ship and JUST WORK. Unlike Windows, which has its own issues with regards to libraries spread out. You can still work out bugs etc, and maintain seperate major/minor versions. As many as your heart desires. The space usage is irrelevant, as you're making up for it with version control/stability. The space storage argument is irrelevant as far as I am concerned due to the entire point of this system and you should be well aware of the storage 'issue'. It's not replacing package managers (can't this be called by a package manager? Say sudo apt-get install krita-flatpak (which would be a meta-package of sorts that then gets installed inside a flatpak-style instance?).

It seems liek a very useful tech. I'm liking some of the bitnami stuff, and the docker stuff, and all sorts of cool and groovey goings on. The options are impressive to say the least. Certianly potentially keeps the machines number's minimal whilst occupied.

[staalmannen]

What I don't get with snappy / flatpack and the "bundle dlls with application" approach that has already been the case for windows programs for a long time is : why not just statically link the applications instead? The size argument can not be an issue here since you are bundling the full dynamic libraries.

[johnc]

Even in a commercial sense do you know how annoying it is when upstream changes their software and it breaks your commercial product? Take WordPress for example and NextGen Gallery -- when they moved to NGG 2.X their JSON API completly changed, WordPress automatically updated the plugins and clients were left confused as to why all of a sudden the updates broke their websites.

I've had to deal with that NextGen trainwreck of a transition and that (as well as all of PHP, really) are good examples of how you don't do software development. PHP is probably the perfect example of how not to do it. One day you put x in a function and you get y, the next version you put in x and you get w. Or even better yet they just get rid of functions and change all kinds of behavior.

People who develop software that is used by other developers could really help the world out by focusing on a stable API.

When Sun was running Java you would never see this problem. They would deprecate functions and entire frameworks but those functions would still run and behave exactly according to the published specification. If you upgraded the JRE you wouldn't expect your old software to break, and if it did, that was considered a bug in the JRE.

[johnc]

What I don't get with snappy / flatpack and the "bundle dlls with application" approach that has already been the case for windows programs for a long time is : why not just statically link the applications instead? The size argument can not be an issue here since you are bundling the full dynamic libraries.

Exactly. Which is what developers have been doing for years.

Whether an application should dynamically or statically link its libraries really depends on the circumstances of course. One approach can be better than the other so it's really on a case-by-case basis.

[zanny]

Exactly. Which is what developers have been doing for years.

Whether an application should dynamically or statically link its libraries really depends on the circumstances of course. One approach can be better than the other so it's really on a case-by-case basis.

The irony is that Snap / Flatpak only exists because the broader Linux ecosystem refuses to agree on simply having a shared naming and versioning convention for packages. You do not even need to replace deb / rpm / xz infrastructure, you just need some queryable daemon to ask if a compatible version Y of X library or program is available, and if not, install it.

Could you imagine how the Internet would be today if ICANN didn't exist, and there were multiple competing DNS implementations? Would the Internet have ever been a thing with that kind of insane fragmentation?

[unixfan2001]

Beside your troll or oriented/biased overview (Canonical is evil, blah blah blah), I would say none.
I'm still gonna go with ppas/AUR/.deb/.rpm or alike.

Apart from lazy half-involved parties such as Valve, I don't see the point in these snaps/xdg-apps. Amongst other reasons, linux is interesting in the first place because of the way it handles dependencies and packages.
If it just starts to basically copy the Windows model, then one of the strongest added value of using it is just gone. Meaning we are going towards losing the architecture battle, when we should keep the idea it is better designed without multiple libraries, and fight for this sound architecture principle.
I'm not refusing change for the sake of it (such as Cinnamon/Mate users after Gnome3/Unity), but I don't see the added value here. At all.

1. It's not the "Windows model". Whoever told you that was lying. Application bundles/packages originated in RiscOS and NeXTStep, not Windows. In fact, the first implementations in GNU/Linux (Rox comes to mind) predate Windows' app model (which was basically Microsoft's attempt at copying Apple) by quite a bit.

2.That "architecture" you're talking about is horrible and NEEDS to lose. Even Windows managed to get largely rid of dependency hell, why can't we?

[CapsAdmin]

What I don't get with snappy / flatpack and the "bundle dlls with application" approach that has already been the case for windows programs for a long time is : why not just statically link the applications instead? The size argument can not be an issue here since you are bundling the full dynamic libraries.

While that's an existing solution for shared libraries I'm guessing the idea is to "statically link" folders, config files, image files, etc as well. Being able to bundle an application into just one thing flatpak can do.

https://github.com/flatpak/flatpak/wiki

Has some useful info.

[unixfan2001]

Developing countries use wired networks where is fatal security problems (100 attackers per day to a adsl modem). Solution is to put 4G prices down, then flatpak, sandboxing etc features are useless when you install software only from Debian, Steam and gpu manufacturer servers.

I know I asked you this before. I know I probably won't get an answer this time either. I know you have the technological literacy of a goat. But for god's sake! In what parallel universe is 4G/LTE known for its security? DDOS isn't the only way to compromise a system.

In fact, 4G is far more likely to spur security threats than to protect against them. The widespread availability of high speed data connections would be easily leveraged by hackers to target not only vulnerable infrastructure but also other mobile devices.