|
|
Log in / Subscribe / Register

Re: Proposal: Rethink Fedora multilib support (Take Two!)

From:  langdon <langdon-AT-redhat.com>
To:  Development discussions related to Fedora <devel-AT-lists.fedoraproject.org>
Subject:  Re: Proposal: Rethink Fedora multilib support (Take Two!)
Date:  Mon, 9 Jan 2017 18:06:24 -0500
Message-ID:  <d08916f9-bf5e-8399-578e-85711594df4e@redhat.com>

On 01/09/2017 10:56 AM, Matthew Miller wrote:
> On Sat, Jan 07, 2017 at 03:47:56AM +0100, Kevin Kofler wrote:
>> I don't buy this sort of alarmist bulldung that keeps being claimed with no
>> evidence whatsoever to justify radical changes to what Fedora is all about,
>> such as:
>> * promoting proprietary drivers (making them easier to use, adding them to
>>    GNOME Software, etc.), which contradicts our Freedom principle,

>> * moving away from integrated packages (which are what a distribution is all
>>    about) towards modules and containers (which, incidentally, also make it
>>    easier to deliver non-free blobs),
>> etc.
re: non-free & packaging
What about modularity would make this any better or worse than RPM? 
There are plenty of proprietary software examples, packaged properly 
(arguably, because it is hard to tell with no sources), delivered as 
RPM. The reason we don't have them in Fedora is purely *policy* and the 
good people enforcing that policy. A technical shift to containers or 
modularity would/should have no impact on that policy.

I also am not sure I am comfortable with the move toward exposing 
proprietary software that we have been considering/implementing. 
However, I do think there is some benefit to being able to show firefox 
next to chrome when someone looks to install it. With information about 
the differences. We have no opportunity to educate users when they just 
go to google and download it directly. Again, modularity or containers 
have no bearing on that discussion, they are an implementation detail.

re: distributions
I agree that this is what a distribution *does* traditionally. However, 
I don't agree that the goal was a completely integrated set of things. 
The goal was to ensure that 1) all the things worked 2) space was 
minimized 3) security could be enforced easily. The goal of modularity 
is to lower the 1st & 2nd requirement a bit and keep the 3rd at the same 
level it is now. I do not believe that anyone thinks that having 
httpd/mod_ssl and ssh sharing the same ssl library instance is somehow 
"good" just in and of itself. They want to have only one ssl library for 
the 1,2, and 3. There may be other reasons but "that's the way we have 
always done it" shouldn't be one of them.

Now, there are some use cases where the interop of the components is 
very important and a distribution enables this because all the things 
are tightly integrated. However, there is no particularly good reason 
for httpd and kde to be tightly integrated. Why can't they be using 
different versions of libraries assuming they are equally secure but 
different in feature set? As a result, modules let us look at having 
"complete integration" at a more granular level than "fedora." This does 
not mean that kde and all its desktop apps might not be one module 
providing for the same very tight integration they have today. With 
modularity, httpd can be doing something different from KDE but also be 
tightly integrated with its own ecosystem like the various pluggable 
modules.

Separating the libraries from binaries, having multiple arch support in 
a generic manner, etc all allow the *operating system* we are delivering 
to be more flexible in terms of the *applications* that it runs. The 
distribution concept might, in some ways, be lost but the goals of the 
distribution would be retained just leveraging different mechanisms to 
implement it.

Langdon
> I don't think it's "alarmist" to note that things change, and that we
> need to be aware of and follow changes to remain relevant. And, there
> is plenty of evidence that things have, in fact, changed, and will be
> changing even more and more rapidly over the next few years. I
> encourage you to look at pretty much *any* analyst report over the last
> few years, or attend a big IT conference yourself and _talk to people_.
>
> But — and I don't know how I can stress this any louder — this is all
> *technical change*. None of it is about changing Fedora's fundamental
> values. Fedora is and will always be a pure free software project.
> That's what we are all here for.
>
> Now, I do see that many people in this larger thread care about
> avoiding changes that break existing proprietary software. To me,
> that's _caring about users_, not promoting the proprietary software; if
> all those users are forced elsewhere, we have no way of reaching them
> at all. So, yeah, let's not break Steam and Wine and whatever else,
> unless we have a really strong reason. But none of this has to do what
> you are responding to specifically, which is the Modularity effort. I
> can state unequivocally that "making it easier to deliver non-free
> blobs" isn't any part of the motivation. It is entirely about how we
> can better deliver the universe of free and open source software.
>
>
>> I think that by destroying what Fedora is all about, we will become a
>> footnote in history. On the other hand, sticking to our principles (Freedom)
>> and to our technical strengths (an integrated distribution of integrated
>> packages) will keep us relevant for a long time to come.
> All of this stuff you are saying about "destroying what Fedora is all
> about" is the "alarmist nonsense" with no evidence or justification. I
> don't see how it's helpful whatsoever to rant about it.
>
> And we need to also remember some of the other Fedora foundations —
> when there is change in the open source world, we should be exploring
> and leading that change: Features and First. All of that together is
> what Fedora is all about.
>
>
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org


to post comments


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds