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