The Forgotten "F": A Tale of Fedora's Foundations

[Przemek Klosowski]

On 04/22/2014 08:55 AM, Máirín Duffy wrote:
> Some of the choices Przemek suggested don't make sense depending on 
> the context. E.g., full functionality vs. small size / speed I think 
> has a different meaning depending on whether you have a workstation 
> target (which, either way, will include X) or a server target (which 
> might not necessarily include X.) Same with command line vs polished 
> apps.
>
> Everything in our repos is free, so putting the choice in the 
> installer seems off to me. Our policy (which is complex and obviously 
> driven by things stronger than the UX) generally leaves it to users 
> post-install to add encumbered software. I don't actually see the 
> advantage to the user in changing that. PackageKit's UI used to have 
> filters I think some were based on license. Maybe the GNOME software 
> devs would be interested in having some kind of selection for the type 
> of software offered to you. Similarly to how some Android app stores 
> work - e.g. show me only free apps, or you can show me paid apps too.
Thanks for bringing some data into this. I do realize that this is a 
difficult and multifaceted topic, and I don't have a solution to it. I 
just want to point out that our current practice is very fragmented and 
low level, and therefore difficult for end users.

Taking the Free/non-Free issue, the real question is whether the user 
can tolerate somehow diminished functionality in exchange for a more 
open and standard-based system. We're not asking that question, 
however---we're talking about .repo files and RPMfusion URLs. 
/etc/yum.repos.d just is not the vocabulary that should be used to speak 
to new users.

I am concerned that the ideas being offered attempt to elevate these 
choices to a higher level of abstraction but  still are fragmented: a 
separate mechanism for GNOME, another one for OS install, different one 
for apps and non-apps(*). I am trying to see a commonality centered 
around the fact that all these are just special cases of a software 
installation / deinstallation workflow, i.e. selecting search 
parameters, obtaining and evaluating the results, and loading or 
removing the software.
> So to back this up, a lot - what install target are we talking about, 
> exactly? And what type of users are we talking about? My guidance as 
> an IXD would be completely different depending on these things.
I hear you about the IXD but do you think that the cases are so 
different as to have no common workflow?

For instance, I liked your insight that the experienced sysadmins aren't 
interested in licensing questions and rely on RedHat to make a 
reasonable choice. My suggestion, however, is to present a reasonable 
default but also provide a well-explained option to override it. This 
would be my preference in all cases you brought up: both OS installation 
and subsequent software maintenance; all types of install targets; and 
both beginner and advanced users.
The specific UI might be different of course---I do get that too many 
spokes on install are confusing and hard to test, so maybe OS install 
should defer the choice to an already running system.

Ceterum censeo, it's all about a well-oiled, flexible software 
installation/removal mechanism at the center of the OS administration.


     Greetings

             przemek klosowski





(*) It reminds me of the sinking feeling I have when I have to use the 
alternatives (CPAN, npm, PIP, octave pkg) on package-based systems (RPM, 
deb): I feel I am doing the expedient thing that is agains my long term 
interests ("It's the life little pleasures that make life miserable":)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140422/f0a7f5db/attachment.html>