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":)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
