Flatpaks for Fedora 27

By Jake Edge
July 26, 2017

A proposal to add Flatpak as an option for distributing desktop applications in Fedora 27 has recently made an appearance. It is meant as an experiment of sorts to see how well Flatpak and RPM will play together—and to fix any problems found. There is a view that containers are the future, on the desktop as well as the server; Flatpaks would provide Fedora one possible path toward that future. The proposal sparked a huge thread on the Fedora devel mailing list; while the proposal itself doesn't really change much for those uninterested in Flatpaks, some are concerned with where Fedora packaging might be headed once the experiment ends.

Flatpak, which was originally known as xdg-app, is both a packaging format and a mechanism to sandbox applications that is inspired, to some extent, by container technologies (e.g. Docker). It is meant to make it easier for users to install applications by bundling any needed dependencies (beyond the standard Flatpak runtime bundle) into the package. Flatpak would make it easier to get the "latest and greatest" version of an application or to run multiple versions side by side. The sandboxing features are targeted at providing secure compartmentalization so the applications cannot interfere with each other—or escape their sandbox if they get compromised. The vision is that projects can create a single Flatpak that could be installed on multiple distributions.

The GNOME community has been instrumental in developing Flatpak and many Fedora team members have been involved as well—not surprising given the overlap between the GNOME and Fedora teams. Owen Taylor is the owner of the proposal "to enable package maintainers to build Flatpaks of their applications and make those Flatpaks available for installation". The plan is fleshed out further on a Fedora wiki page. The idea is to make it possible for package maintainers to process the standard Fedora RPMs for their packages into Flatpaks.

In order to do that, there are two pieces that need to be built: a runtime and an application. The runtime is a collection of common libraries that Flatpaks can depend on; there would be versions for each Fedora release, which could coexist on a given system. The application piece consists of the program of interest, and any additional libraries it needs, bundled up in the Flatpak-specific format (which may require rebuilding the application and libraries with different build options). The target of the Fedora proposal is Flatpaks for graphical applications, so the runtime would be filled with GNOME-specific libraries.

Proposal

In early July, Fedora program manager Jaroslav Reznik posted the feature proposal as part of the normal review process for Fedora 27 features. The first response, perhaps predictably, came from Kevin Kofler, who asked a number of important questions before concluding: "I strongly oppose this change." The proposal says that Flatpaks will be built from RPMs, but those will not be the standard Fedora RPMs for the packages, as they will need to be relocated into the filesystem hierarchy used by Flatpak. Kofler asked if only Flatpaks would be shipped for these packages or, if not, which RPMs would be available.

Taylor responded that the rebuilt RPMs are not really useful outside of the Flatpaks, though they could still be downloaded from Koji. The regular RPMs would be available along with the Flatpaks, he said. He described his vision of where this might all be leading, which is part of what caused a bit of an uproar in the Fedora world. That vision was not part of the proposal, but suggested that over the following two releases (i.e. Fedora 28 and 29), graphical applications would fully move into Flatpaks and that standard RPMs might be dropped for them. He concluded:

But this is really highly dependent on how modularity work happens more widely in Fedora. "standard RPM packaging" assumes we still have a F<N> tag in Koji where everything is built together with common coordinated dependencies.

The Change proposal, in any case is really only about enabling this as an something that packagers may opt into if they want to.

Kofler's second set of questions had to do with the advantages of shipping Flatpaks for Fedora. The existing RPM-based distribution is working and Flatpaks have only downsides, he said:

I see only drawbacks compared to RPM, because everything not included in the base runtime must be bundled, so we have all the usual issues of bundled libraries: larger downloads, more disk consumption, more RAM consumption (shared system libraries are also shared in RAM), slower and less efficient delivery of security fixes, FHS [Filesystem hierarchy standard] noncompliance, etc. And the portability argument is moot when we are talking about delivering Fedora software to Fedora users.

Taylor said that he believed the proposal itself answered that question in its "Benefit to Fedora" section, which lists several benefits. The main ones seem to be that it allows application maintainers to choose their dependencies separately from the versions in the Fedora release, it provides a way of testing different versions of applications, and that it can sandbox some applications. Bastien Nocera disagreed with Kofler's assessment; he dismissed the FHS compliance question and questioned the assertion of slower security fixes, while also listing his set of "positive changes".

Sandboxes

Kofler pointed out the problems he sees with rebuilding the libraries for the Flatpak layout; he also described ways that the process of updating Flatpaks will lead to slower security fixes. But a good chunk of his response concerned sandboxing; he is not convinced that the "Flatpak way" is the right way forward. Michael Catanzaro acknowledged many of Kofler's points, but was enthusiastic about the Flatpak sandboxing. But, as Andy Lutomirski noted, there are two elements to Flatpak that aren't necessarily tied:

Flatpak provides two things that are very nearly orthogonal: packaging and sandboxing. Packaging is the system of bundles, apps, runtimes, etc that allows you to build a Flatpak, send it to a different machine, and run it there, even if the other machine runs a different distro.

Sandboxing is Flatpak's system of portals, confinement, etc.

Aside from the fact that both are based on namespaces, I see no reason at all that they need to be conflated. It should be entirely possible for Flatpak [to] run an "app" that is actually a conventional RPM installed on the host system using host libraries.

So, if sandboxing can be provided by other means, "what on earth is the point of forcing packagers to make Flatpaks?", Richard W. M. Jones asked. Others agreed with that assessment and wondered what Flatpaks provide that can't be solved with RPM packages. But it is a rare Fedora system that only has RPMs from Fedora repositories installed, as Bill Nottingham pointed out. Typically systems are built up from other sources as well: Coprs, RPMs from elsewhere, packages from language-specific repositories (e.g. PyPI), containers from various sources, packages retrieved using curl, and software built from tarballs. He continued:

If the only answer Fedora has for this is "convince everyone to only build RPMs using system [repo] components"... that's fighting a rear-guard battle that has already been lost. I don't think supporting Flatpak apps is necessarily any worse than what already has to happen with all of the above.

And Flatpaks do have some other advantages, as Taylor outlined:

Well, the nice thing is that:

There are no scriplets with [Flatpaks] - no arbitrary code execution at install time.
There is no ability for Flatpaks to drop arbitrary files at arbitrary locations on your system.

The idea is that you don't *have* to inspect a flatpak before installation to make sure that it's not dangerous.

Fedora == RPM?

But in another sub-thread, Kofler wonders why users would get Flatpaks from Fedora; why wouldn't they just get them from upstream? RPMs are an important feature of Fedora, he said:

The whole point of delivering software under the Fedora umbrella is to deliver it as RPMs. If there is no RPM, delivering through Fedora is completely useless.

Fedora project leader Matthew Miller took exception to that characterization: "I strongly dispute the idea that Fedora must be tied to a particular packaging technology." But Stephen J. Smoogen agreed with Kofler, at least from a branding standpoint: "RPM is part and parcel of what makes Fedora for most people." Others, including Miller, disagreed; various examples, counter-examples, and car analogies were offered up, but it seems there are some fundamentally different views of what Fedora is.

The "plan" that Taylor outlined is part of what has gotten some in the Fedora community riled. It posits a future without RPMs, at least for some packages, but it is only Taylor's vision, not something that is currently being considered. As he put it:

But I want to be clear that there is no *proposal* on the table to ship things Flatpak only, and *no proposed timescale*. And there won't be until we know how the tools work out for packagers, how Flatpak usage works out for users, and we have a significant body of Fedora packages built as Flatpaks to look at things like installed size and network usage.

These are things we can only get to by building out the infrastructure so that packagers can start trying building Flatpaks and users can start trying installing them.

The intent seems to be to test out Flatpaks in a "real world" environment to see what advantages, problems, and downsides they have. Many, including Miller, believe it is in keeping with the nature of the distribution to do that kind of experiment. There are a number of ideas swirling around the industry these days, and containerization is one of them, so it makes sense for Fedora to explore that, Christian Schaller said:

Containers have caught on due to solving some important problems and thus people are looking at models for what the future operating system would look like where containers are the primary content delivery mechanism. In Fedora we have efforts [around] Docker/OCI containers and Flatpak containers and we are looking at image based OS installs with the Atomic and Atomic Workstation effort. The fact that we are developing stuff like this in Fedora is a good thing as it means that if it does turn out to be a better model we are well positioned to take advantage of the shift in the market. And if the scepticism some people have about containers turns out to be well founded we still have our RPM based OS to fall back on.

The Fedora Engineering Steering Committee (FESCo) took up the proposal at its July 21 meeting. As can be seen in the log (starting at 16:04), FESCo members noted the opposition, but found that it was mostly ideological differences over packaging formats. Adding Flatpaks in parallel to RPMs is not really harming anyone or anything. If the experiment is successful, perhaps there will be other proposals down the road that do change the picture with regard to RPM availability, but those can be dealt with then. In the end, FESCo unanimously approved the proposal, so Fedora 27 should be a good testbed for those who are interested in trying out Flatpaks.

Flatpaks for Fedora 27

Posted Jul 26, 2017 20:30 UTC (Wed) by jdulaney (subscriber, #83672) [Link] (32 responses)

My single worry is that flatpaks and their ilk will lead to a reduction in quality. Fedora has very high standards when it comes to package quality, and, in my experience, many upstreams would rather not meet these standards. Flatpak seems to offer a convenient workaround that makes it easier to ship shit.

Flatpaks for Fedora 27

Posted Jul 26, 2017 20:55 UTC (Wed) by drag (guest, #31333) [Link] (19 responses)

I wouldn't worry about it.

Fedora isn't the only distribution out there that cares about high quality packaging. If flatpaks gain acceptance then for desktop applications the efforts of different distributions can be combined. So instead of just Fedora improving the quality of packaging in Fedora you have Debian, Ubuntu, Arch, Suse, and other packagers all working on improving the quality of packaging for Fedora users.

Flatpaks for Fedora 27

Posted Jul 26, 2017 23:38 UTC (Wed) by pizza (subscriber, #46) [Link] (18 responses)

You seem to be missing the point -- it doesn't matter how high the distribution quality standards are when the packaging ends up being done by a random third party that has nothing to do with any of those distributions.

I share jdulaney's expectations of an outcome of utter rubbish; you'll end up with what you have today, only instead of a tarball of unmaintained everything that you plop somewhere in /opt, you'll instead have the same unmaintained everything wrapped inside a fancier container.

Flatpaks for Fedora 27

Posted Jul 27, 2017 1:57 UTC (Thu) by drag (guest, #31333) [Link] (12 responses)

I didn't miss the point one bit.

Why is it such a forgone conclusion that the people packaging the software now will have nothing to do with packaging the software in the future? You think that people working in Fedora or other distributions that package software will have no interest or ability whatsoever with working with upstream authors to increase the quality and creating acceptable guidelines?

I think it's silly notion that the only possible way that Linux distributions can have quality packages for users is that they must insert themselves as blockers and control access to software binaries in such a way as to prevent end users to ever come into contact with anything directly produced by software authors.

Flatpaks for Fedora 27

Posted Jul 27, 2017 3:39 UTC (Thu) by pizza (subscriber, #46) [Link] (11 responses)

> You think that people working in Fedora or other distributions that package software will have no interest or ability whatsoever with working with upstream authors to increase the quality and creating acceptable guidelines?

The packagers for Fedora, Debian, or whatever have *always* wanted to work more closely with upstream authors.
But cooperation has always been a two-way street. The upstream authors that want to work with distributions generally already do so. But the rest don't want to -- and what's the point of writing yet another set of guidelines that will just be ignored anyway? (Owncloud was a particularly aggregious example that comes to mind; they actually rejected the distro packagers' suggestions and patches to make things, oh, not require manual intervention on *every* package update. Grumble..)

Remember, the goal here isn't for Flatpak to be used by only a single distro -- there's no advantage to that versus the distro's native packaging. Instead, this is intended to be sorta universal. But then you'll run right back into the problem where the runtimes will either be completely over- or under-specified, both leading to the inevitable conclusion where you'll have to bundle the world with your "universal" flatpak in order for it to work everywhere.

Flatpaks for Fedora 27

Posted Jul 27, 2017 8:59 UTC (Thu) by mjthayer (guest, #39183) [Link]

Speaking as an "upstream author" who does quite a bit of own packaging, I see this in a positive way, assuming of course (and that is a big assumption) that Flatpack really does work well (generally and for us in particular). First, for Fedora it is an opportunity, not a requirement. If they do not see eye to eye with us about packaging quality they remain just as free as they are today to do their own packaging as RPMs. In fact, it should free up packaging resources by letting them concentrate their packaging efforts on software where it is needed, letting upstreams that they trust do it themselves.

For us though it should also make it easier to do higher quality upstream packaging by reducing the number of different environments we have to target, and by providing an environment which should be both more friendly to out-of-distribution packagers and to distribution people wanting to work with us.

Flatpaks for Fedora 27

Posted Jul 28, 2017 13:38 UTC (Fri) by otaylor (subscriber, #4190) [Link] (9 responses)

> But then you'll run right back into the problem where the runtimes will either be completely over- or under-specified, both leading to the inevitable conclusion where you'll have to bundle the world with your "universal" flatpak in order for it to work everywhere.

Runtimes aren't specifications, they are actual binary bits. If you build and test your application against version 1.6 of the org.freedesktop.Platform or version 27 of the org.fedoraproject.Platform runtime, then other than bug fixes and security updates, you have tested with the exact same libraries that your users will be running with - whether they are on Fedora 27, or Fedora 28, or Debian. So there's never a need to bundle a library because you are worried it won't work the same everywhere. (You might need to bundle a library because it isn't in the runtime you are building against, or because you need a newer version.)

The expectation is that users will have a small handful of runtimes on their systems - the increase in disk space is a tradeoff to get the benefit of reliable cross-distribution and cross-distribution-version binaries. Ending up with dozens of runtimes in use, or not having clear recommendations to application developers about how to select a well-maintained runtime - those would be failures of the Flatpak ecosystem, and are things we are working to avoid.

Flatpaks for Fedora 27

Posted Jul 28, 2017 14:16 UTC (Fri) by pizza (subscriber, #46) [Link] (7 responses)

> The expectation is that users will have a small handful of runtimes on their systems

The reality is that users will have a *large* number of runtimes on their systems, including multiple versions of individual runtimes.

> Ending up with dozens of runtimes in use, or not having clear recommendations to application developers about how to select a well-maintained runtime - those would be failures of the Flatpak ecosystem, and are things we are working to avoid.

It won't be a failure of the Flatpak ecosystem per se, but an acknowledgment of the reality that the overwhelming majority application developers are going to do the bare minimum of effort to get their software packaged and delivered. Which means they'll stick to the original runtime set they started with. This will only get worse as proprietary vendors start doing this too -- and you can bet they'll compound ancient (and long-since-unmaintained) runtimes by bundling plenty of other libraries too.

I don't intend to come off as cynical here, and I really want to be shown to be wrong, but after twenty years of dealing with this crap, I can't see how technical wizardry is going to solve fundamental problem of people putting minimal (if any) thought/effort into longer-term maintainability.

Flatpaks for Fedora 27

Posted Jul 28, 2017 15:44 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

> It won't be a failure of the Flatpak ecosystem per se, but an acknowledgment of the reality that the overwhelming majority application developers are going to do the bare minimum of effort to get their software packaged and delivered.

Flatpak can address it to a good extend by making the right thing to do is easy and obvious. This includes the tools but also the documentation. The worst case scenario of multiple runtimes is still going to be better than a typical third party RPM repo (Chrome relying on redhat-lsb instead of redhat-lsb-core thereby installing multiple needless dependencies.. Skype RPM which is missing a lot of dependencies etc)

Flatpaks for Fedora 27

Posted Jul 28, 2017 17:28 UTC (Fri) by zlynx (guest, #2285) [Link] (4 responses)

For comparison my Windows desktop has over 20 "runtimes" installed. Different versions of the Visual C++ Redistributable packages from 2005 to 2015 in 32 and 64 bits. And like you said there are several versions of the 2005, 2008 and 2012 libraries.

Even this year I've installed packages that still use the 2005 runtime because of XP support. Also they probably don't wish to pay their developers to update ancient C++ code to 2017 standards.

Yes, open source software projects hate having to fix old bugs revealed by LTO optimizing compilers, or new versions of malloc/new and memcpy in the libraries. But this does push their software forward in a way that proprietary software doesn't get. Does anyone want code that only builds with an ancient compiler and library set from 15 years ago?

Flatpaks for Fedora 27

Posted Jul 28, 2017 19:15 UTC (Fri) by excors (subscriber, #95769) [Link]

> Even this year I've installed packages that still use the 2005 runtime because of XP support.

I think even the latest version of Visual Studio (and its associated CRT) has XP runtime support - you just have to choose to compile with an _xp version of the 'Platform Toolset', and then it should work fine for users on XP.

(You can't run VS itself on XP, but any developers who are still using XP are insane.)

One possible reason for sticking with an ancient version of VS is that you can't safely mix libraries built with different versions (unless they're DLLs that are very careful about their interfaces). If you've got a third-party binary-only library that was built with VS2005 and is impossible to update, or if you've got hundreds of open source libraries that you're just too lazy to recompile (because you've got to load each one into VS individually, upgrade the project file, fix all the build failures, manually copy the build output into the right place, etc), you might want to stick with VS2005 forever. Open source projects seem pretty good at avoiding that situation, by only depending on open source libraries and by having build scripts that make it trivial to rebuild everything with the latest toolchain.

(I suspect some people are also tied to an ancient version of VS by IDE plugins that don't support anything newer (at least without an expensive licence renewal). And some people stuck with VC6 for like a decade just because they thought the new IDE was ugly and slow.)

Flatpaks for Fedora 27

Posted Jul 28, 2017 22:17 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

> Windows desktop has over 20 "runtimes" installed

> they probably don't wish to pay their developers to update ancient C++ code to 2017 standards.

> Does anyone want code that only builds with an ancient compiler and library set from 15 years ago?

Just highlighting that not all useful code bases have dedicated on-going maintenance budgets or volunteers willing to maintain distro packages of unmaintained software, so having a somewhat reasonable way to reliably run old code is as problem that MS had to solve for Windows (which has orders of magnitude more software that is expected to run), so its not surprising that other solutions end up in the same general shape with how runtimes are defined.

Flatpaks for Fedora 27

Posted Jul 28, 2017 23:14 UTC (Fri) by pizza (subscriber, #46) [Link]

> Just highlighting that not all useful code bases have dedicated on-going maintenance budgets or volunteers willing to maintain distro packages of unmaintained software

Yeah, instead we'll have a growing number of flatpaks of unmaintained software that only runs (and/or if source is available, compiles only) on ancient, unmaintained runtimes. Because why put forth any effort into something that still "works"?

Also, let's not forget that while being able to reliably run old code was surely a boon for Microsoft, it also became a considerable millstone around their necks.

Flatpaks for Fedora 27

Posted Aug 3, 2017 9:18 UTC (Thu) by Wol (subscriber, #4433) [Link]

> Does anyone want code that only builds with an ancient compiler and library set from 15 years ago?

YES!

A program I would love to get running again is WordPerfect - which relies on libc5 ...

(I know I go on about it, but the reality is I almost never use office software nowadays, so it's not worth the effort getting it working. But if I could get it running it would take over "just like that" - replacing Word and loWriter for me in a heartbeat!)

Cheers,
Wol

Flatpaks for Fedora 27

Posted Aug 3, 2017 2:37 UTC (Thu) by Garak (guest, #99377) [Link]

I don't intend to come off as cynical here, and I really want to be shown to be wrong, but after twenty years of dealing with this crap, I can't see how technical wizardry is going to solve fundamental problem of people putting minimal (if any) thought/effort into longer-term maintainability.

I think the fundamental problem here is that people talk about the issue as a fundamental problem. I think people's worldview should expand to include the nuance that one cannot overstate the variance of importance between software packages. All this top-down academic talk tries to treat 'the software development efficiency' problem as something to try and solve in one way for all software. That's wrong. As each important piece of software increases its stature of importance, different methodologies (more thought/effort) will be applied to their development. There is no 'fundamental problem' with this. What there is is an abundance of software developers and academics trying to make a name for themselves and this issue as with a few others, seem to get a lot of milage. I'd rather those folks stopped trying to fix all software at the same time, and instead focused their thought and effort on specific packages. But the realist/cynic in me knows that we will see this recurring narrative for decades. I think it's somewhat related to open source pundits that view forking, casual and otherwise as a bad thing. I think the ecosystem would benefit from a thousand fold increase in forking. Sure, like most blades of grass or baby animals, most forks will have relatively short uneventful lives. But the power of evolution comes about because most individuals don't matter that much to the big picture. What matters is enough diversity so that the better solution eventually/inevitably comes about. Nature is full of crap. The solution isn't to redesign the digestive system, it's to watch where you are stepping. If you are afraid to get your shoes dirty, you can pay the toll to stroll in some super-rich people's walled garden. In fact there are many walled gardens to choose from, and over time, the ones with the most crap will fade, while others will thrive. Of course there may also be competing products that allow you to enjoy strolls through unwalled jungles- clever safety equipment that prevents you from slipping on dog turds and being bitten by poisonous creatures. I can't say what things will look like in a hundred years, but I don't think there is really a fundamental problem here.

Flatpaks for Fedora 27

Posted Aug 4, 2017 3:39 UTC (Fri) by HelloWorld (guest, #56129) [Link]

The fact that every library that isn't in the runtime (and virtually every non-trivial application will need a bunch of those) needs to be bundled is exactly what makes Flatpak retarded. This “runtime” thing is just a poor man's version of package dependencies, except you can have only one. That's not progress but a huge step backwards.

Flatpaks for Fedora 27

Posted Jul 28, 2017 13:30 UTC (Fri) by anton (subscriber, #25547) [Link] (4 responses)

It gives the user the choice between the quality of the distribution-"improved" package, and the quality of the upstream-provided package, or the quality of some third-party-improved package. In theory, this will lead to better quality (at least in my world which contains distribution packages that are worse than what's coming from upstream, e.g. Debian's version of xpdf), but I am sure the distributions will at least arrange things to make using non-distribution-provided packages look like a second-rate option, and make it inconvenient to use them.

Flatpaks for Fedora 27

Posted Jul 28, 2017 14:22 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

You should say distribution-improved as well as distribution-"improved", because while the latter unfortunately happens, the former is far more common.

And 3rd-party packages are a second-rate option in the same way that out-of-tree kernel modules are a second-rate option. It's a fundamental property of how they're developed and delivered, and will always lag behind the mothership unless said 3rd party is sufficiently proactive.

Flatpaks for Fedora 27

Posted Jul 30, 2017 15:28 UTC (Sun) by anton (subscriber, #25547) [Link] (2 responses)

In cases like xpdf where the distribution introduced a bug that is not present in the upstream, and fails to fix it in the course of several years, it's very easy for a third party to provide a package that is better than the distribution package. Also, given that the distribution has made extensive changes to xpdf, it's also much easier for a third party to lag less behind upstream than the distribution does. Concerning proactivity, there is no magic that makes people more proactive just because they are distribution maintainers.

In any case, if you want the package derived from the most recent upstream release (as your "lag" criterion indicates), if you have alternative packages, you can select that (and ideally, you could tell the package management that this is your preference, and it will do it automatically for you).

Flatpaks for Fedora 27

Posted Jul 31, 2017 3:11 UTC (Mon) by foom (subscriber, #14868) [Link] (1 responses)

In the other direction, I greatly appreciate that Debian's version of xpdf has patched out the upstream bug where it sometimes refuses to let you copy text from a pdf document. (Which bug, I'll note, upstream has actively refused to fix for the last 15 years!)

Flatpaks for Fedora 27

Posted Aug 1, 2017 10:54 UTC (Tue) by anton (subscriber, #25547) [Link]

I think this is a result of the xpdf developers' stance on digital restriction management of PDFs, i.e., they consider it a feature. So "misfeature" might be more accurate than "bug".

Anyway, this shows the potential value of third-party packages: The packager could disable this (mis)feature without introducing the Debian-originated papersize bug.

Flatpaks for Fedora 27

Posted Jul 27, 2017 11:16 UTC (Thu) by NAR (subscriber, #1313) [Link] (11 responses)

If you don't trust the software author to create good quality software, why are you installing his software at all? If you think package maintainers will somehow magically improve quality, let me remind you how Debian "fixed" openssl a couple of years ago... I accept that software packagers are good in modifying a software to build and install on a particular distribution with a particular set of libraries - but this work shouldn't even be necessary in an ideal world, this has to be done only because distributions exist.

I work on Erlang software which should be able to run on Erlang versions 15-20 (that's six different versions). What do you think, how many versions can be parallel installed on the same Linux distribution? Five less than necessary. Of course, I can install from source, but even that doesn't work for ancient (i.e. 5 years old) software, because it requires libraries that no longer are installed in a current distribution. I'd be screwed without containers.

Flatpaks for Fedora 27

Posted Jul 27, 2017 11:59 UTC (Thu) by pizza (subscriber, #46) [Link]

> If you don't trust the software author to create good quality software, why are you installing his software at all?

There are other selection criteria than "quality"

> but this work shouldn't even be necessary in an ideal world, this has to be done only because distributions exist.

In an ideal world, distributions would have no reason to exist.

Flatpaks for Fedora 27

Posted Jul 27, 2017 12:59 UTC (Thu) by flussence (guest, #85566) [Link] (8 responses)

>If you don't trust the software author to create good quality software, why are you installing his software at all?
That freedom only exists if saying no is a realistic option. OpenSSL is a textbook example - it took two major disasters before OpenBSD came along and gave everyone an escape route, and even that is an uphill struggle with constant API breakage on both sides, abandonware and third-party binaries to contend with.

Fedora itself is a good example too; there's absolutely no way to opt out of things like CVE-2017-1000082, unless one is willing to jump ship to another distro entirely. A lot of people will clutch at any excuse to keep being slowly frogboiled. (Me included. Not enough hours in a day to fight every battle...)

Flatpaks for Fedora 27

Posted Jul 27, 2017 13:53 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

"there's absolutely no way to opt out of things like CVE-2017-1000082, unless one is willing to jump ship to another distro entirely"

Not sure why you believe that? It is resolved in the latest systemd release and Fedora will inherit these changes as part of the regular release updates.

Flatpaks for Fedora 27

Posted Jul 28, 2017 17:23 UTC (Fri) by flussence (guest, #85566) [Link] (5 responses)

Sorry, but there's no option to compile out the cowboy attitude that led to a third party having to get that CVE number assigned in the first place. There'll be another one next month, and another, and another. Systemd has more than earned its trophy.

My comment about clutching for excuses to defend that kind of culture clearly hit the mark, though.

Flatpaks for Fedora 27

Posted Jul 28, 2017 18:39 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

> Sorry, but there's no option to compile out the cowboy attitude that led to a third party having to get that CVE number assigned in the first place.

Your original claim was "there's absolutely no way to opt out of things like CVE-2017-100008". That is incorrect. You appear to have shifted your arguments towards something non technical now.

Flatpaks for Fedora 27

Posted Jul 30, 2017 20:54 UTC (Sun) by flussence (guest, #85566) [Link] (1 responses)

I've been entirely consistent: systemd has a colossal arrogance problem, every one of these disasters it causes can be traced back to that cultural defect, and nobody involved can see the wood for the trees or put their fragile ego aside for long enough to just fix a damn bug without it taking a prolonged public shaming campaign *every single time*. The cycle of abuse will continue indefinitely and end users who can't escape will suffer for it.

I already see the pattern of strawmanning and obtuseness that precedes a systemd white-knighting 100-reply war of attrition starting here, so I'm out. You're not interested in an answer, you just want to win.

Flatpaks for Fedora 27

Posted Jul 31, 2017 0:19 UTC (Mon) by anselm (subscriber, #2796) [Link]

Loads of bugs get fixed in systemd without much ado. This particular one was obnoxious and could have been handled a lot better, especially because it came about due to some assumptions on the part of the implementers that were out of touch with actual reality. But it's probably a lot easier to convince people to correct an inadvertent oversight of theirs than it is to convince them that something they presumably put a lot of thought into was actually not that great an idea and needs to be redesigned, especially if they have both a long history of making fairly reasonable design choices and the well-bolstered ego that often comes with such a history. That phenomenon, though, is by no means specific to systemd.

In any case, even this particular bug was fixed in the end, and that is a sign that the process seems to work after all. Also, systemd is fundamentally a good and useful piece of software. Its popularity is well-deserved, there are no credible alternatives, and it is unreasonable to throw it out simply because its developers occasionally need convincing that a bug is really a bug, especially if they do come around in the end. If we were to abolish every piece of software whose head developer is a bit of a stubborn know-it-all curmudgeon we should probably begin with OpenBSD and the Linux kernel.

Flatpaks for Fedora 27

Posted Aug 3, 2017 9:26 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

> Your original claim was "there's absolutely no way to opt out of things like CVE-2017-100008". That is incorrect. You appear to have shifted your arguments towards something non technical now.

You seem to have missed "things like". To be honest, so did I ... :-)

You can't opt out of attitudes you disagree with, when other people you have to deal with hold those attitudes. I can't opt out of supporting Word :-( Not without extreme marital grief ... (and yes, she does sometimes use loWriter. But "change == grief" :-(

Cheers,
Wol

Flatpaks for Fedora 27

Posted Aug 4, 2017 3:22 UTC (Fri) by HelloWorld (guest, #56129) [Link]

BS. If you can't opt out from it, it is not a “thing like” CVE-2017-100008 (duh)

Flatpaks for Fedora 27

Posted Jul 27, 2017 16:52 UTC (Thu) by zlynx (guest, #2285) [Link]

No way to "opt out?"

I suppose that you might need to study the RPM documents for a little while, but opting out is simple. Download the srpm package. Create a patch for the behavior you want. Bump the package epoch. Build your version and install it.

Because the epoch is newer, no regular distro update will ever replace your custom package. You have opted out.

Flatpaks for Fedora 27

Posted Jul 31, 2017 15:11 UTC (Mon) by abo (subscriber, #77288) [Link]

> If you don't trust the software author to create good quality software, why are you installing his software at all?

Perhaps I trust the Fedora maintainers to ensure that the software is of decent quality. They can handle bundled libraries to make sure security updates are applied and ensure that the software is properly licensed, for example.

They also provide a complete distribution compiled on a single cluster of trusted build servers. I may trust that the source code in the upstream GIT repository is of decent quality, but that doesn't mean that I'd be happy to run binaries compiled on the laptop of the main developer of that upstream. At least not until reproducible builds are a reality, anyway.

Flatpaks for Fedora 27

Posted Jul 26, 2017 20:54 UTC (Wed) by tau (subscriber, #79651) [Link] (1 responses)

http://kmkeen.com/maintainers-matter/

This reasoned anti-Flatpak (and Snappy et al) article was posted on LWN a while back. It makes interesting food for thought, and much as I like the ideas behind Flatpak I'm rather inclined to agree with this analysis.

Flatpaks for Fedora 27

Posted Jul 27, 2017 17:05 UTC (Thu) by mattdm (subscriber, #18) [Link]

I agree with a lot of what that article has to say -- but it's actually *in alignment* with what we're doing here. The idea of this proposal is actually to create a large pool of Flatpaks which contain software *with* maintainers in the traditional distro sense. That's entirely separate from arguing against third-party Flatpaks.

Flatpaks for Fedora 27

Posted Jul 26, 2017 21:53 UTC (Wed) by DOT (subscriber, #58786) [Link] (8 responses)

I love Flatpaks, since they can be updated reliably without restarting the system, which is a major usability benefit. But it must be possible to improve RPM in such a way that updated packages never require a system restart. I'm thinking that containerization plays a major part in this, since it separates all the different versions of apps and their dependencies.

Flatpaks for Fedora 27

Posted Jul 26, 2017 23:34 UTC (Wed) by tao (subscriber, #17563) [Link] (7 responses)

What software do you typically have trouble updating without restarting your system? I'm fairly sure flatpaks won't solve the need to reboot (or mess around with kpatch) to upgrade your kernel.

Flatpaks for Fedora 27

Posted Jul 27, 2017 9:20 UTC (Thu) by DOT (subscriber, #58786) [Link] (6 responses)

GNOME Software requires a reboot for every update (except Flatpaks), because it can't be guaranteed to work otherwise. Flatpaks do provide that guarantee, because their scope is limited. A consequence of that is that Flatpaks can't update your kernel, for example. So Flatpaks are not a complete solution, but RPM could definitely learn from it.

Flatpaks for Fedora 27

Posted Jul 27, 2017 14:14 UTC (Thu) by lsl (subscriber, #86508) [Link] (5 responses)

Gnome Software might not be able to guarantee it for arbitrary byzantine situations , but I'm 100% confident that I can reliably update a program that's not even running using RPM without rebooting the whole system.

For running programs there's a set of pathological conditions where this might indeed lead to issues. In an ideal world even with these pathological programs the worst case would be some kind of error message about a version mismatch or an unability to parse data files. But lots of software is crap so you might also get to enjoy arbitrary misbehaviour.

Most software doesn't care at all, though. It's mostly the GUI behemoths dlopen'ing random unversioned garbage from disk in response to unpredictable network or user events.

Flatpaks for Fedora 27

Posted Jul 28, 2017 20:27 UTC (Fri) by epa (subscriber, #39769) [Link] (4 responses)

An interesting point for security fixes is that even if the system keeps running fine across the update, you probably need to reboot to be certain the vulnerable code is not still running somewhere. Let's say bash has a security hole, for example. A new package updates /bin/bash and everything stays up. Existing bash processes stay running. But that's the very problem the package update was intended to fix -- a vulnerable older version is still executing.

The unhappy conclusion (unless you want to contemplate some global software-tracking tentacular thingummy that can tell you exactly which current processes were started from which versions of which files) is that in many cases software updates require a reboot on Linux just as much as on other systems.

Flatpaks for Fedora 27

Posted Jul 29, 2017 1:32 UTC (Sat) by lsl (subscriber, #86508) [Link] (2 responses)

That global software-tracking tentacular thingummy isn't far-fetched at all. You can get a reasonable approximation by looking at running processes that have files mapped that no longer exist in the file system (because RPM/dpkg renamed the new version over it). Basically look for DEL in the output of lsof(1) and filter on the paths your programs and libraries tend to live.

Things like DNFs tracer plugin integrate a slightly more advanced play on this into the package management, telling you what (and for many things, how exactly) you need to restart following the transaction.

Flatpaks for Fedora 27

Posted Jul 29, 2017 11:31 UTC (Sat) by pabs (subscriber, #43278) [Link] (1 responses)

There are better running process options than just open file tracking; for eg needrestart goes further than just open file tracking by also inspecting programs written in Python/Perl and determining if they have any libraries that were upgraded loaded.

The DNF tracer plugin sounds interesting, do you have a link?

Flatpaks for Fedora 27

Posted Jul 29, 2017 23:45 UTC (Sat) by lsl (subscriber, #86508) [Link]

Sure: https://dnf-plugins-extras.readthedocs.io/en/latest/trace.... There's also a link to the underlying tracer program which is not specific to DNF/Fedora.

Install the python3-dnf-plugin-tracer package to enable it on recent Fedora.

Flatpaks for Fedora 27

Posted Jul 29, 2017 11:28 UTC (Sat) by nix (subscriber, #2304) [Link]

What you say is true for a lot of things that are directly or indirectly network-exposed, but in the bash case you're probably fine, since nearly all bash-related vulnerabilities involve the attacker doing something that spawns a new shell with unexpected capabilities (e.g., in the most famous case, shell functions that should not be there). So in bash's case, unless the hole relates to readline doing something unexpected when faced with hostile input *and* it's paired with a terminal emulator bug that lets the attacker force keyboard input via hostile output, you're probably fairly safe, as these things go. (And even in that case I'd say the terminal emulator bug is the really bad one. If someone can type arbitrary stuff into your shell, they can do bad things even if readline etc are bug-free.)

Flatpaks for Fedora 27

Posted Jul 27, 2017 4:51 UTC (Thu) by hifi (guest, #109741) [Link] (6 responses)

One of the most used third party packaging on Linux is probably Steam and it's a good example how badly things break when you control only half of the runtime libraries.

Most of the time games work just fine but many game developers need to bundle their own builds of third party libraries and that's usually the point when things start to break big time as they are built against other libraries of whatever version the developer had on their system.

I've seen libgcc_s bundled with one game which broke when I upgraded from Fedora 25 to 26 - manually removing the bundled library fixed that. Removing libstdc++.so from the Steam runtime to even get the damn thing started is also very often needed even on Ubuntu which supposedly is supported by Steam.

Then there's Mesa and its dependencies on system libraries and Steam games using Mesa with their own bundled libraries that might be used by Mesa as well and have conflicting ABI which will again silently break games. One recent issue regarding this has been worked around in most distributions.

What I'm trying to say here is that cross distribution packaging is hard and offloading the issue to upstream to do their own packaging leads to this kind of mess real fast and the end user is the one suffering from it.

Flatpaks for Fedora 27

Posted Jul 27, 2017 8:46 UTC (Thu) by mjthayer (guest, #39183) [Link]

> One of the most used third party packaging on Linux is probably Steam and it's a good example how badly things break when you control only half of the runtime libraries.

[...]

> What I'm trying to say here is that cross distribution packaging is hard and offloading the issue to upstream to do their own packaging leads to this kind of mess real fast and the end user is the one suffering from it.

I quite agree with you, but draw a different conclusion, namely that it is an excellent opportunity for the FLOSS community to gain more badly-needed experience in cross-distribution packaging.

Flatpaks for Fedora 27

Posted Jul 27, 2017 14:25 UTC (Thu) by sorpigal (guest, #36106) [Link]

If all flatpak does is provide a standard, documented way to produce steam-style runtime environments it will at least prevent proliferation of multiple bad implementations of a bad idea. App bundles are hard to get right but the only way you will convince supporters that it's not worth the effort is to let them try it and experience the pain. A single standard way to do it should at least collect painful experience in one place where it will perhaps do some good. I hardly dare hope that the result is an advance in the state of the art, but crazier things have happened.

Flatpaks for Fedora 27

Posted Aug 4, 2017 20:37 UTC (Fri) by RedDwarf (guest, #89472) [Link] (3 responses)

It seems to me that the number of ways in which libgcc and libstdc++ can break things is limited.
* The version of glibc in the system is too old
- libgcc from my gcc 7.1.1 x86_64 system requires glibc 2.14, from 2011-06-01. So if the game includes a modern libgcc, it will not work in pre-2012
systems.
- libstdc++, from the same system, requires glibc 2.18, from 2013-08-12.

* The game depends on a system library (directly or indirectly), and this library requires a newer libgcc/libstdc++ than the one bundled with the game.

The first case can obviously be solved by also including glibc in the game. The second case by updating the bundled libgcc/libstdc++ or including a copy of the libraries that depend on libgcc/libstdc++.

But most importantly, both libgcc and libstdc++ are backwards compatible and symbol versioned. The game startup script should just freaking check which version is newer, the bundled one or the one in the system, and use it.
Not saying this is obvious, but is also not out of control. If you are a big company creating a big game, specially Valve, you really should have somebody that understands this stuff.

Flatpaks for Fedora 27

Posted Aug 4, 2017 21:30 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> But most importantly, both libgcc and libstdc++ are backwards compatible and symbol versioned. The game startup script should just freaking check which version is newer, the bundled one or the one in the system, and use it.
They are backwards compatible - until they aren't. You can't rely on a third-party library without doing any testing.

Flatpaks for Fedora 27

Posted Aug 5, 2017 0:50 UTC (Sat) by nix (subscriber, #2304) [Link]

The first case can obviously be solved by also including glibc in the game.

That's so hard that no-one does it: too many things can go wrong. The problem is that the dynamic linker in use must be the one that comes with the glibc you're using, and that is, of course, wired into PT_INTERP in every binary. The game vendor could run game binaries by running their ld-linux.so.2 explicitly with the --library-path option, i.e. /their/ld-linux.so.2 --library-path /their /their/game/binary, but that is very clunky, and if the game binary invokes another game binary without using the same technique it all falls apart because the library path is now unset and you are suddenly using the system glibc. They could *not* get away with setting LD_LIBRARY_PATH to point to their glibc and then running /their/ld-linux.so.2 /their/game/binary: if the game binary invoked any other binary at all that *wasn't* part of the game, you'd end up with the system ld.so and the game glibc, and disaster would result.

Flatpaks for Fedora 27

Posted Aug 10, 2017 18:55 UTC (Thu) by dirtyepic (guest, #30178) [Link]

> The first case can obviously be solved by also including glibc in the game. The second case by updating the bundled libgcc/libstdc++ or including a copy of the libraries that depend on libgcc/libstdc++.

Jesus christ on a crutch.

Flatpaks for Fedora 27

Posted Jul 27, 2017 9:08 UTC (Thu) by dunlapg (guest, #57764) [Link]

The intent seems to be to test out Flatpaks in a "real world" environment to see what advantages, problems, and downsides they have.

This seems to me to be the main argument for taking Fedora-packaged software and putting them in Flatpacks. Only Fedora developers can create, modify, or improve Fedora Flatpack functionality and integration; only people who create Flatpack packages know what's easy or hard about creating a Flatpack package; and communication across different organizations and social groups has natural barriers. The obvious solution is to have Fedora developers who create Flatpack packages, so they can give feedback directly to (or directly modify) the Fedora Flatpack integration.

Flatpaks for Fedora 27

Posted Jul 27, 2017 9:46 UTC (Thu) by mjthayer (guest, #39183) [Link] (6 responses)

A couple of thoughts.

I wonder whether this could be made to work for something like VirtualBox. We have a couple of system integration needs (like installing and using a kernel module) which would be quite challenging to fit within the Flatpack portal concept; but if Flatpack is going to be limited to applications which do not present any special integration challenges that might limit its reach quite a bit.

It would be really nice to see Flatpack environment add-ons for distributions which do not officially support it, like long-term support distributions which are not seeing new features. Rolling Flatpack packages once for these distributions would save a lot of people rolling their own packages of their particular software, which can only be good for the packaging quality.

And I'm not quite sure that separating the sandboxing and the packaging sides of Flatpack are quite realistic, orthogonal though they may be. That would mean that every Flatpack application would have to target a range of different sandboxes, each with their own equivalent to Flatpack's portals; or slightly better, that people providing Flatpack would also have to provide a range of sandbox plug-ins to match whatever the packages applications might use; or a mix of the two.

Flatpaks for Fedora 27

Posted Jul 27, 2017 10:32 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (5 responses)

Given that most stock distributions don't support out of tree kernel modules anyway, any Flatpak that relies on kernel modules isn't going to be universally compatible. The only long term strategy here is to get your support code upstream.

Flatpaks for Fedora 27

Posted Jul 27, 2017 10:50 UTC (Thu) by mjthayer (guest, #39183) [Link] (4 responses)

Our interface changes from version to version of VirtualBox, which is something of a blocker for getting it upstream. And even if we were to stablise it, would the kernel developers really want a second virtualisation interface? And at this point in time we are not ready to support KVM as an alternative: we currently have a single interface which works on four operating system families (or kernel families, whatever you like to say), and supporting a second interface would require resources we would rather invest elsewhere. The usual disclaimer about what we might or might not do in future applies of course.

And at least disregarding Flatpack, it is surprising how well out-of-tree modules work in practice. Let's see if Flatpack changes that equation.

Flatpaks for Fedora 27

Posted Jul 27, 2017 11:31 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

Secure Boot systems will reject any unsigned kernel modules, so you're left either asking users to disable a security feature or manage signing themselves (the easiest way being to keep the private key material on the local system, which isn't a huge improvement over disabling it). In addition, there's a risk that kernel security updates will break your modules, so users still end up being trained to do things that reduce their security. The support load for all of this ends up on distributions, so it's not really surprising that they wouldn't place handling out of tree kernel modules as a high priority - if a Virtualbox Flatpak fails to work on Fedora but works on Ubuntu, it's still the Fedora developers who are going to be blamed even if all they did was move to a new kernel version more quickly.

In the absence of a way to ensure that out of tree kernel modules can be built on all distributions, it'd be misleading to support them in a project that's intended to make it possible to produce packages that can be used on all distributions.

Flatpaks for Fedora 27

Posted Jul 28, 2017 10:08 UTC (Fri) by mjthayer (guest, #39183) [Link] (2 responses)

If the Flatpak is provided by Fedora, then yes, users might blame Fedora if a security update temporarily stopped it from working. If it comes from us, I would more expect them to blame us, but perhaps I am being naive here. I can't really see myself pointing the finger at Fedora in this case if users come to us (I have pointed the finger at others in the past, but only when I was sufficiently convinced that it was justified).

My current thought is that some sort of user self-signing would be the best route, trying to make it as easy as possible for the user to choose a trade-off between security and ease of use - say store the key on the local disk, store it on a USB key, or make it as clear as possible how the user can do it themself in the way that suits them best. By the way, thank you for drawing my attention to this. It wasn't really on my radar, though a couple of colleagues had started looking at it.

Regarding Flatpak, not only do we install kernel modules, we also install system services. That is also something which Flatpak would probably not cope with, so if we were to go the Flatpak route we would probably want a second component installed outside of Flatpak which it could talk to. Any thoughts from the Flatpak developers welcome here.

Flatpaks for Fedora 27

Posted Jul 28, 2017 13:34 UTC (Fri) by farnz (subscriber, #17727) [Link] (1 responses)

You're definitely being naïve here. Microsoft's experience with Windows was that 85% of Windows XP blue screen crashes could be definitively traced to buggy third party code; 30% of Windows Vista crashes traced to a single vendor's device drivers. And yet, who got the blame for Windows being crashy? The device makers? No, Microsoft.

The same sort of thing will happen if a Fedora upgrade breaks your installed software - the last thing you did was update Fedora, and now VirtualBox fails. Here, not only is it obvious that things have stopped working, but the proximate cause is obvious - "I updated Fedora and now my apps don't work!" - and thus Fedora gets the blame and has to shunt things onto you.

Flatpaks for Fedora 27

Posted Jul 28, 2017 14:53 UTC (Fri) by mjthayer (guest, #39183) [Link]

Your conclusion may still be right, but I don't think that the example is quite comparable. A comparable situation to a blue screen on Windows would be a kernel panic in Fedora, which is a far cry from VirtualBox refusing to start with a message about driver not loaded. Particularly as VirtualBox is third-party software in an environment where third-party is a second-class citizen, so to speak, and automatically treated as less reliable, particularly in regard to system integration. (Not that integration is any harder than on Windows or OS X, where we do not have the second-class status - if anything it is the other way round.)

My version of your blue screen example would be when VirtualBox multi-monitor full-screen handling was not working on Ubuntu. It was a simple mistake in the Unity code, a function being called with (x1, y1, x2, y2) instead of (x, y, w, h) or vice versa, and no one else used that particular EWMH functionality, so it was our risk so to speak. So users reasonably assumed it was our bug, and as a result I spent quite a lot of time getting a one-line fix into Unity. Whatever, on a closed operating system we would have had to live with it.

Flatpaks for Fedora 27

Posted Jul 27, 2017 16:41 UTC (Thu) by marduk (subscriber, #3831) [Link]

I'm for Flatpaks, but I agree with some of the comments here regarding quality. It's the same problem we have with most "third-party" apps. For example the apps that come with stock Android are usually pretty good in quality, and Play Store has a lot of good quality apps, but There is a very small signal-noise-ratio when it comes to apps in these marketplaces. Most of them are just crap.

Having said that, people *love* crap. So why not just give them what they want?

Flatpaks for Fedora 27

Posted Aug 7, 2017 7:34 UTC (Mon) by omgold (guest, #109541) [Link] (8 responses)

The thing I most worry about, is that containers will be very advantageous to the proliferation of non-free software. One has to be aware that one function of distro maintainers is to prevent the inclusion of proprietary software in the distro. As a result vendors of such have to package their stuff themselves for various distros, have to provide their own repo (which has to awkwardly included manually by the user into the list of package sources). Due to the simplicity (in comparison) of installing distro-included software, this gives free software a big advantage.

With containers this advantage will be lost. And as history shows most users care more about the difficulty to get started with a software than about freedom. Smartphone OSes show where this will lead. The result will be: Google Play Store. All that madness seen there we will have with desktop/server Linux, too.

Flatpaks for Fedora 27

Posted Aug 7, 2017 9:17 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

You mean, installing applications in one click without having to worry about dependency hell with many years of backwards compatibility? Yeah, that's crazy talk.

Flatpaks for Fedora 27

Posted Aug 8, 2017 7:13 UTC (Tue) by omgold (guest, #109541) [Link] (6 responses)

Well, of course it is a nice idea in principle to get rid of dependency hell (except for the problems already mentioned here). But the issue I mean is that - as this is a much larger problem for proprietary software - that this will boost their popularity under Linux.

Soon someone will create an appstore where they can easily fetched from. Then we will be flooded with apps to be known to be adware, spyware, and other nasty stuff, but you can't reasonably get around using them, too, as everyone else is using them. Think e.g. about certain instant messengers under Android.

Wonder why there is so little free software (as in speech, not in beer) under Android? This is the reason.

Flatpaks for Fedora 27

Posted Aug 8, 2017 8:07 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> But the issue I mean is that - as this is a much larger problem for proprietary software - that this will boost their popularity under Linux.
And this is bad exactly how?

> Soon someone will create an appstore where they can easily fetched from. Then we will be flooded with apps to be known to be adware, spyware, and other nasty stuff, but you can't reasonably get around using them, too, as everyone else is using them. Think e.g. about certain instant messengers under Android.
The instant messenger I'm using has permission to use the Internet and that's pretty much it. It can't get my phone's GPS position or access its camera. And I'm perfectly fine with that.

And to put it this way, most open source Linux messengers suck. If I had to chose between Pidgin and WeChat with root access to my computer and a direct link to Chine then I'd choose it any time.

Flatpaks for Fedora 27

Posted Aug 9, 2017 9:23 UTC (Wed) by omgold (guest, #109541) [Link] (4 responses)

> And this is bad exactly how?

This is bad because it prevents (to a certain degree) high-quality open source software with the same purpose to be developed. Most people don't care much whether the software they use is proprietary 'freeware' or actual free software. As a result there will be less interest in development of such.

Don't believe that? Look at the situation under Windows or phone OSes. Isn't that exactly the case there? For all I know under Windows most free software there was developed under free OSes and then ported using cygwin, mingw and/or the win versions of GTK/Qt. On Android, look at the F-Droid repo and grieve.

>The instant messenger I'm using has permission to use the Internet and that's pretty much it.

And how many people you know you can communicate with it? For me it is the way that pretty much everyone I know uses Whatsapp only. I hate it and would like to get rid of it, but no way I could convince these people to switch to something free. It is either using it too, or be left out completely.

> And to put it this way, most open source Linux messengers suck.

On that I agree. It is certainly true, that this is a field where proprietary solutions have been driving progress forward. But are you really satisfied with using proprietary?

I see that in a few areas open source is behind (e.g. office suite, image manipulation, games, symbolic math, engineering software), but what should we do? Give up on developing free alternatives?

Flatpaks for Fedora 27

Posted Aug 9, 2017 9:48 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> This is bad because it prevents (to a certain degree) high-quality open source software with the same purpose to be developed. Most people don't care much whether the software they use is proprietary 'freeware' or actual free software. As a result there will be less interest in development of such.
And this is bad exactly how?

I don't care about ideological purity. I care that users are able to get their needs met, and if this means freeware or proprietary software then what is the problem?

If free software movement can't produce high-quality software for users then I don't see why proprietary software should be hampered.

> Don't believe that? Look at the situation under Windows or phone OSes.
Let's look at Windows - it totally dominates the desktop space, with more than 90% of usage (and the other ~5% are Mac OS). I call that "success".

> And how many people you know you can communicate with it?
Around 30 in my contact list. It's Slack, btw. Why?

> On that I agree. It is certainly true, that this is a field where proprietary solutions have been driving progress forward. But are you really satisfied with using proprietary?
Mostly.

> I see that in a few areas open source is behind (e.g. office suite, image manipulation, games, symbolic math, engineering software), but what should we do? Give up on developing free alternatives?
LibreOffice is ok-ish these days and symbolic math might eventually get there.

Flatpaks for Fedora 27

Posted Aug 10, 2017 6:33 UTC (Thu) by omgold (guest, #109541) [Link] (2 responses)

> And this is bad exactly how?

I think I already answered that. It has nothing to do with ideology:

> Then we will be flooded with apps to be known to be adware, spyware, and other nasty stuff, but you can't reasonably get around using them, too, as everyone else is using them.

For me alone the fact that most proprietary apps annoy me with advertisements is enough of a reason for not using them when there is a free software alternative. If you add to that that it has been proven again and again that you cannot trust them to respect your privacy it turns it almost into a no-go. And don't get me started on the problem of developers abandoning their software completely or removing features you value.

To me all of these are serious real-world problems.

Flatpaks for Fedora 27

Posted Aug 10, 2017 6:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> For me alone the fact that most proprietary apps annoy me with advertisements is enough of a reason for not using them when there is a free software alternative. If you add to that that it has been proven again and again that you cannot trust them to respect your privacy it turns it almost into a no-go.
I don't use apps with ads. And I have quite a bit of paid apps that respect my privacy.

Besides, these days both Android and iOS can limit apps into fairly tight sandboxes anyway. And this is the CORRECT way to deal with bad applications rather than sabotaging non-ideologically-compliant vendors.

If you compulsively install every ad-sponsored app you see in stores, then you have a big problem.

Flatpaks for Fedora 27

Posted Aug 11, 2017 8:37 UTC (Fri) by omgold (guest, #109541) [Link]

> I don't use apps with ads.

I don't either. But for a lot of purposes I can't find any without. And there the issue I'm talking about becomes very visible. Under desktop Linux this isn't much of a problem - currently.

> Besides, these days both Android and iOS can limit apps into fairly tight sandboxes anyway.

Good luck trying to limit Whatapp to read only the contacts you want it to read. And if you don't you might run into problems like this:

http://splinternews.com/facebook-recommended-that-this-ps...