Flatpaks for Fedora 27

Posted Jul 27, 2017 11:16 UTC (Thu) by NAR (subscriber, #1313)
In reply to: Flatpaks for Fedora 27 by jdulaney
Parent article: Flatpaks for Fedora 27

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.