Flatpak 1.2 Likely Coming Around Year's End With New Features

[oiaohm]

Why does it even matter how fast official releases are done? It's not like people work or send patches any faster (or slower) just because there's a time-based release.

You have to remember users need official releases that will work. Users really taking from master of git where they might get something half way though a patch series being applied is not really a workable option.

People work or send patches are partly effected by release cycle. Stackleak patches for Linux mainline shows this. Developer modified their patch they now have to wait for a release cycle to get it approved or rejected for include in next release. Why release is when a lot of projects run their final quality control checks. So something that has taken less than 30 mins of work can take 5 years to get included in the Linux kernel all due to the 90 day release effect and minor revisions required to get code to acceptable quality.

So how quick you patch will be reviewed is linked to the release cycle.

You don't want year long release cycles in most cases. 90 days is how long a CVE fault will be kept secret for. So to produce releases to deal with reported CVE faults you have to release roughly every 90 days. This is also to hide defective releases a bit.

90 days is a slow release cycle.
1-90 days is what you release cycle has to be inside. CVE rules set your upper limit. You min is set by how fast you can do quality control and packaging.

Wine development is fairly fast release cycle. Wine cannot go faster than 2 weeks without starting to effect those packaging with burn out. Wine is also at 2 weeks to at least give a tolerable turn around on driver caused breakages in wine.

[ssokolow]

This turned up on HN front page today: http://flatkill.org/. Apparently flatpak marketing is lies.

Looks like either a smear or propaganda to me.

Here are some reasons that I'm not very impressed by that page:

• The overall feel of the site is that someone wrote one of those single-page "I'll sell you the secret to success" sites using something like Jekyll or asciidoc and left it on the default template.
• The page is conspicuously missing any information on when it was published or updated and who wrote it. (To the point that, if I'm reading the WHOIS information correctly, the flatkill.org domain is one report away from being shut down for the ToS violation of failing to provide valid WHOIS information.)
• It conflates flathub and flatpak.
• It uses dramatic language, with a dearth of details.
• It doesn't provide clarifications or citations for claims like "almost all popular applications on flathub".
• It says "flatpak shows a reassuring "sandbox" icon when installing the app" when flatpak itself has only a CLI or library interface and it's up to each desktop to provide an interface graphical enough to have icons. Given that I can find no such icon on Flathub for any of the packages that are mentioned, and this mention, it's pretty clear that the author is actually referring to a design flaw in GNOME Software Center.
• It doesn't provide any screenshots of the aforementioned problems (eg. where does the "sandbox" icon appear?) and it leaves it up to the reader to determine the meaning of the contents of the one screenshot it does provide.
• The "You are NOT getting security updates" section links to CVEs aplenty, but has no actual citations for the claimed delay in getting the fixes into Flatpak'd applications.
• The author assumes that "This is a minor security update" in the release notes means "We don't consider a setuid vulnerability to be a big deal" which it could just as easily mean something like "This security update didn't change many lines of code" or "This security update poses minimal risk of breaking production systems". (ie. The author assumes the interpretation most favourable to their agenda, rather than either giving the benefit of the doubt or finding further evidence, as is expected of good discourse.)
• The author resorts to childishly writing "Running KDE apps in fakepak?" (emphasis mine)
• In claiming that "fcitx has been broken since flatpak 1.0, never fixed since", the author neglects to mention that the problem was reported to the flatpak developers less than two months ago and the breakage happened because fcitx was relying on a security hole.
• A trustworthy source is more likely to put in the effort to prevent grammatical errors like "rethinked" from slipping into the released page, and to correct them promptly.

[brrrrttttt]

This turned up on HN front page today: http://flatkill.org/. Apparently flatpak marketing is lies.

[Weasel]

Lot of people think wine development releases at every 2 weeks is fast. This is half the speed Nvidia is moving at.

Why does it even matter how fast official releases are done? It's not like people work or send patches any faster (or slower) just because there's a time-based release.

[oiaohm]

Sure, but spotify claims that they do snap. So I used snap to have spotify.

And people after they have deployed a lot of snap and had the issue of bad perform get them end up swapping across to flatpak. Flatpak has not been able to use marketing to get packages.

The issue with snap is that bad that it would be useful to have something like alien package converter to convert snap package to flatpak ones.

Just because upstream developers support something does not mean it fact works. Snap is one of those things it broken and I have seen no fix for it problems coming. Its really a matter of time until coverters appear.

Spotify on flatpak is built from the official deb package coveted. Why are ubuntu and debian users not using that package directly that much you find it has dependencies on exact versions of ffmpeg and other things that they did not bundle. Spotify is good example of we make broken then it up to the community to turn provided broken into functional..

[oiaohm]

Exactly. And even in the worst-case scenario where they might want to break stuff at some point, they could always introduce an LTS release that will be supported for like a year or so.

Wine project stable. New stable every 12 months with updates every 3 months. Why is wine updates on it stable so fast. Please remember nvidia opengl is updating every week and it not the only part updating this fast. This Nvidia example is Windows or Linux no difference..

Welcome to the bugger. You are dealing in graphical the update of the parts you depend on are insanely fast. You need to perform updates ever 3 months unless you start telling people they cannot use X versions of Nvidia graphics and the like so you deal with quirks in those drivers in kind of timely pattern.

Game and application developers want to make a binary that does not change.

If the application and game developers want to be stable and your drivers are updating weekly you need a middle ware.

Windows has the application compatibility toolkit that is a solution to apply shims to non changing binaries to deal with the changing quirks.

Really when you know the field a release every 3 months will most likely be too slow. I can see flatpak dealing with some of these graphics hell in the run-times.

The idea of LTS starts falling apart with the desktop. You graphics drivers are not LTS. Other parts of the desktop are not LTS either.

Lot of people think wine development releases at every 2 weeks is fast. This is half the speed Nvidia is moving at.

[Wilfred]

Have you even used flatpak? flatpak has spotify and pretty much everything snap has. flatpaks have been a much better experience for me even on ubuntu.

Sure, but spotify claims that they do snap. So I used snap to have spotify.

[Vistaus]

The implementation of a quarterly release schedule doesn't imply that their will be breaking changes every quarter. Considering that Flatpak is design to provide a stable and environment for flatpak packaged programs, I'd expect that their wont be breaking changes (or only very rarely). They will probably just fix bugs, add new portals and extend existing features in every release.

Exactly. And even in the worst-case scenario where they might want to break stuff at some point, they could always introduce an LTS release that will be supported for like a year or so.

[Vistaus]

Flatpak sucks. Snap has spotify, useful software. FOSS can simply use the standard packaging.

Flatpak sucks because Snap has Spotify? Flatpak has Spotify too.

https://flathub.org/apps/details/com.spotify.Client

In fact, Flatpak had Spotify long before Snap had.

[cybertraveler]

I’m rather shocked that Flatpak developers would want to go to a quarterly releases schedule. In part rapid release are cause many of the issues flatpaks supposedly address. We could easily end up with dozens of incompatible Flatpak releases. Makes no sense really.

The implementation of a quarterly release schedule doesn't imply that their will be breaking changes every quarter. Considering that Flatpak is design to provide a stable and environment for flatpak packaged programs, I'd expect that their wont be breaking changes (or only very rarely). They will probably just fix bugs, add new portals and extend existing features in every release.