The Forgotten "F": A Tale of Fedora's Foundations
przemek.klosowski at nist.gov
Tue Apr 22 15:24:03 UTC 2014
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
> 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.
(*) 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...
More information about the devel