Flatpak 1.0 Nears With Today's 0.99.1 Release

[phoronix]

Phoronix: Flatpak 1.0 Nears With Today's 0.99.1 Release

Red Hat's Alexander Larsson who has been leading much of the Flatpak development going back to the days of XDG-App has today announced the release of Flatpak 0.99.1 as the first pre-release prior to the major 1.0 release...

http://www.phoronix.com/scan.php?page=news_item&px=Flatpak-0.99.1-Released

[tildearrow]

Typo:

install/update/ininstall

[Michael]

Typo:

Seems to be an upstream typo in the release announcement I was wondering what "ininstall" did as I hadn't used that command previously with Flatpak, but yep, after checking further I assume it's a typo for uninstall.

[perpetually high]

I absolutely love flatpak. Kudos to those actively developing. I opt for it before anything else now (within reason, sometimes of course apt is better). Snap is a 3rd option. AppImages are fourth, and I still build and compile certain things from source when needed.

If you're looking to try it, it's as easy as:

$ sudo apt install flatpak (or however you wanna install it)

$ flatpak search appname

$ flatpak install flathub com.whatever.here

My current apps if any is looking to install something new to try today.

Flatpak:

com.discordapp.Discord/x86_64/stable                 system,current
com.github.JannikHv.Gydl/x86_64/stable               system,current
com.github.fabiocolacio.marker/x86_64/stable         system,current
com.github.mdh34.hackup/x86_64/stable                system,current
com.google.AndroidStudio/x86_64/stable               system,current
com.googleplaymusicdesktopplayer.GPMDP/x86_64/stable system,current
com.spotify.Client/x86_64/stable                     system,current
com.transmissionbt.Transmission/x86_64/stable        system,current
com.uploadedlobster.peek/x86_64/stable               system,current
com.valvesoftware.Steam/x86_64/stable                system,current
de.haeckerfelix.gradio/x86_64/stable                 system,current
io.github.Pithos/x86_64/stable                       system,current
io.github.mmstick.FontFinder/x86_64/stable           system,current
net.pcsx2.PCSX2/i386/stable                          system,current
org.filezillaproject.Filezilla/x86_64/stable         system,current
org.gimp.GIMP/x86_64/stable                          system,current
org.libreoffice.LibreOffice/x86_64/stable            system,current
org.libretro.RetroArch/x86_64/stable                 system,current
org.openshot.OpenShot/x86_64/stable                  system,current
org.signal.Signal/x86_64/stable                      system,current
org.videolan.VLC/x86_64/stable                       system,current

Snap:

Name             Version      Rev   Tracking  Developer     Notes
acestreamplayer  3.0.2-snap9  7     stable    vs            -
core             16-2.33      4830  stable    canonical     core
corebird         1.7.4        97    stable    snapcrafters  -
cumulonimbus     1.23.3       44    stable    snapcrafters  -
gitkraken        3.6.3        62    stable    mmtrt         -
gnome-3-26-1604  3.26.0       64    stable/…  canonical     -
winds            2.1.0        65    stable    getstream-io  -

[Weasel]

inb4 people start saying how flatpak, snap, AppImage or whatever are "useless" and should just use distro packages "without the bloat". Because building 1 single application for 10 Ubuntu versions, 10 Fedora versions, and so on, is a perfectly sane thing we have going on without flatpak.

The normal userland design is just broken and rotten at the core. I may not like flatpak's sandboxing, but it's really the only solution right now, unfortunately. Don't hate it for trying to fix something rotten, even if it isn't ideal. (ideal would be stable libraries, like on Windows, then you won't need flatpak or bloat)

[starshipeleven]

(ideal would be stable libraries, like on Windows, then you won't need flatpak or bloat)

(on windows it's still an "evolved" system so while it's relatively stable there is no guarantee that applications or drivers still work 4-5 years later as things still do change if slowly. A true versioned OS API is found in Android where applications can target specific Android versions and still work fine as the OS was designed for that from the start)

(flatpacked applications would 100% keep working in the future, as they would rely on stable libraries from the runtimes, which is a much better design than Windows where you bog down development of the libraries with legacy support and QA to make sure new additions don't break old stuff for the sake of providing a stable interface to the other applications. This model is simply not viable if you aren't a large company like Microsoft, and of course on Linux you can't do like with Android as they started from scratch and here isn't possible)

[Weasel]

I think you have a different stable definition than I do. Extending an interface/library API does not make it "unstable" if the old interface respects the same contract within its interface. The Linux Kernel is an obvious example of this. You can obviously change the function's implementation itself, even make it a simple stub or wrapper around a "new" function you just implemented -- as long as the outside interface remains the same, it's no problem.

Really in most cases extending an interface (even a stable C++ interface, like Microsoft's COM) or adding new functions will never touch the old functions (in fact, maybe all?) I don't see how that will lead to "extra maintenance burden" other than people wanting to remove it for their purism bs reasons.

[starshipeleven]

I think you have a different stable definition than I do.

That's because I work in IT support (and some server administration too). I know what is actually done in the trenches to keep applications stable and free of issues. Especially with Windows 10 that breaks shit every major update.

VMWare is a giant in the corporate world for a reason. Everyone is virtualizing full Windows OSes to run their payload application on their server(s). That's completely retarded and wasteful, but paying someone to troubleshoot stupid things at random times costs more than paying for a bigger server.

Extending an interface/library API does not make it "unstable" if the old interface respects the same contract within its interface. The Linux Kernel is an obvious example of this.

I still don't understand why you think userspace libraries break API all the time and that is the main issue. They do what they can to keep their API stable too, the issue is complexity, and bugs.

As said in the other thread, what is exposed by the kernel to userspace are primitives, relatively simple things which are then consumed by libc, which provides more complex things to be consumed by something else which eventually is the end software. Being primitives, it's not something that lends itself to much change over time, and is also relatively easy to provide.
Where the game is harder and performance would suffer (the driver ABI) they never provided anything remotely stable.

But let's remain on your statements. If we take for example Mesa (the userspace 3D acceleration "library"), you can see that they don't change the interfaces, but still manage to break shit regardless.

Why that?

Because they are changing the internal functionality of the library. Mesa isn't returning the result of an addition, it is returning graphic buffers, stuff that has to be compiled and sent to the GPU to render, and any other type of complex objects. If you change the internal functions it does not matter that the API to call the library remains the same, it's the results you are getting that can change and then break your code downstream that expected the results in a certain way but got them different.

To make the example with a math library for the sake of keeping things simple, the lib isn't changing the function call, you can always ask it add(2,2), and the result of that will always be an INT, but maybe yesterday it was returning 4, and now it returns 2.

The API is 100% the same, the result is kinda wrong. If the code downstream made assumptions (for performance reasons perhaps) and can't handle a "2" as an answer here, then you get explosions. Again this is just for the sake of making a simple example.

As the results asked to the library are more and more complex, it becomes harder to actually keep the answers the same when you change the library, because you genuinely might not be able to test all corner cases (very fucking common with filesystems and 3D acceleration, for example). Which is why you can end breaking stuff without touching the library API. Actually most breakage is from this.

And why there is all the continuous testing suites running on all half-serious software source code, so that you can automatically test that a change you made somewhere isn't breaking something else.

Really in most cases extending an interface (even a stable C++ interface, like Microsoft's COM) or adding new functions will never touch the old functions (in fact, maybe all?) I don't see how that will lead to "extra maintenance burden" other than people wanting to remove it for their purism bs reasons.

That's a great way to end with an unmaintainable mess.

I've seen this bs enough with java applications where the function used by the end application is extending another function, that was extending another function, that is also extending a core function, that was created by extending another core function, that extended another core function. (I'm shortening this a bit)

Now, if there is a bug somehwere (there is always a bug somewhere) you got functions where the code is split all over the place and in some (most) cases you might not fully understand what you are extending either (that code was written by someone else in your team, you just forgot what you wrote 10 years ago, it is stuff coming from a library so it was never yours to begin with) so you don't know how to troubleshoot it properly, or even how to pinpoint where the bug is. This adds time and costs of debugging this piece of garbage and increases the chances of introducing more bugs while fixing bugs.

If you never touch the old functions then how do you improve the library over time, again extending them? It's going to become a horrible unreadable mess, where even minor security patches or the odd library-wide change because of some compiler issue or language change require massive QA to check that nothing in the spaghetti got broken in the process. Which is what Windows and Windows .Net are actually are under the hood. And also why for example Mono can boast better performance in running the same code, as it is created from scratch and lacks the legacy crap that is bogging down development.

Another example of this is Xorg. It works, yes. Is it easy to develop.... ummmm... not really.

Which is why in some cases library developers just decide to drop legacy crap or even rewrite the library from scratch changing the API. Which happens but isn't as common as you think.

[oiaohm]

inb4 people start saying how flatpak, snap, AppImage or whatever are "useless" and should just use distro packages "without the bloat". Because building 1 single application for 10 Ubuntu versions, 10 Fedora versions, and so on, is a perfectly sane thing we have going on without flatpak.

The normal userland design is just broken and rotten at the core. I may not like flatpak's sandboxing, but it's really the only solution right now, unfortunately. Don't hate it for trying to fix something rotten, even if it isn't ideal. (ideal would be stable libraries, like on Windows, then you won't need flatpak or bloat)

Stable libraries really don't exist on windows.
http://test.winehq.org/data/9ef8fa2a...ndex_Win8.html
Wine project running tests has see that the idea of stable libraries and windows is kind of false. Wine works out what the average functionality of windows libraries is and implements that.

Weasel there are formal tools to give you ABI changes rates.

https://lvc.github.io/abi-compliance-checker/

This gives you reports like the following
https://abi-laboratory.pro/index.php...eline&l=ffmpeg

If you perform the proper tests on Windows you will find its ABI breakage numbers are higher than Linux Distributions.

I think you have a different stable definition than I do. Extending an interface/library API does not make it "unstable" if the old interface respects the same contract within its interface. The Linux Kernel is an obvious example of this. You can obviously change the function's implementation itself, even make it a simple stub or wrapper around a "new" function you just implemented -- as long as the outside interface remains the same, it's no problem.

Really in most cases extending an interface (even a stable C++ interface, like Microsoft's COM) or adding new functions will never touch the old functions (in fact, maybe all?) I don't see how that will lead to "extra maintenance burden" other than people wanting to remove it for their purism bs reasons.

LOL not true at all. Please stop random presuming crap. If you were running ABI tests you would notice that Microsoft Com object regularly lose features more often than not. Does not cause issues due to program error handling.

The issue with Linux distributions is quite simple.

if you look at the ffmpeg one. If you ship 24 different versions you can have compatibility from 2010 ffmpeg to current and that just for ffmpeg. That is 260 releases.

That is roughly 1 in 10 modifications a breakage. Windows updates ABI breakage about 1 in 5 updates do a ABI break. So Windows ABI is technically half as stable as Linux Distribution ABI.
Please note ffmpeg is up there on breakages.

https://abi-laboratory.pro/?view=timeline&l=glibc

glibc from 2010 to current only 3 versions are required this is about the same place as new visual studio run-times. In fact glibc has a slower required change rate in number of versions required than using visual studio.

Most Linux distributions don't ship multi versions of the same library Windows on the other hand with SXS does provide multi versions of the same library.

So the Linux userspace library ABI break rate at source code and binaries is lower windows so Linux distributions technically have higher ABI stability. The problem is ABI stability deliverablity this is where multi versions of libraries comes important.

Linux problem is no effective system for providing multi binary versions libraries and to provide libraries exactly matching what the applications want. Flatpak is starting to deliver a common system for this. Nix and other have tried before.

Remember in your manifest file that visual studio will auto make and embed in your exe tells windows what version of particular libraries that program wants to see. The sandbox inside windows makes sure that is what the application does see.

Reality here Windows appearance of ABI stability is a good slide of hand trick. Flatpak is a system offering to put a related slide of hand trick on Linux. Yes SXS under windows has caused disc space usage bloat and other things that people complain flatpak will cause.

It really easy to say Linux has unstable userland ABI but the tests tell you that its not the problem particularly when the tests tell you repeatedly that windows is worse. ABI stablity is looking at the wrong problem. What you need is ABI stability deliverable and this is locking versions of libraries to match applications and allowing more than 1 version of a library to be installed. Of course more than 1 version of a library install does not mean you have to allow any application to use 2 different versions of the same library. Of course this also requires working out what versions of libraries must be updated for hardware support and have solid abi stability..

[oiaohm]

Please note providing multi libraries particular old libraries like Windows does has a security price. This is one of the factors that makes windows easier to find exploits.