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":)