Re: [opensuse-factory] A users wishlist to make zypper up/dup & suse noob-friendly
On 14 July 2015 at 14:58, Thomas Langkamp
Sadly, as described here, this would make openSUSE liable for any patent infringement by encouraging our users to install patent encumbered software, or possibly even guilty of "facilitation of crime"
Thanks Richard for your reply :) Are you saying that there is a difference between providing
"yast / repos / add community repo"
and the same functionality as a desktop icon? Interesting. But Why? Only because the one is more hidden than the other? I cannot imagine how this would make a difference in court, but I am no lawyer also.
Precisely (and I recently double checked this with our lawyers) One is clearly identified as 'not provided by the openSUSE Project' and it's a clear opt-in..the user has to go to it, know what it's for, and do it The other, is a big flashing button that says 'hey, the openSUSE Project says you can get your codecs here'..
So what about my other points?
- when adding packman: automagically add packman with a 98 priority & allow vendor change once & automatically apply zypper up or dup afterwards (those more knowledgable should still be enabled to change priority / vendor change of course; this is about sane defaults for noobs)
I dislike this idea - I do not automatically favour Packman packages above openSUSE's, because openSUSE's are tested and Packmans are not
- install recommends: only once during installation as default
Neutral to the idea - this is similar to how I set up my servers (so I guess +1 in that scenario), but not my desktops (so -1 in that use case)
- automatically update/grade the OS daily: by executing zypper up or dup in the background (via cron-job or graphical utility?) AFAIK apper still cannot propose solutions for conflicts and thus might not be feasible for this job.
I dislike this idea because of the lack of user-interaction, but it's not that dissimilar from how PackageKit already works in GNOME (Downloads in the background, but requires user interaction to actually install stuff)
- Require minimal user intervention for the update/grade: require sudo password if new software is installed, but not when existing software is updated; but let the user know if he needs to restart or log-off.
No way in heck - Root access should be required to change the software on an openSUSE machine - SysAdmin 101
- partialy unrelated: let flash stay for the noobs, those more knowledgable can uninstall / block it
I disagree, I'd rather we remove something so terribly insecure as Flash by default, and let the people who need it put it on there. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 14.07.2015 um 16:13 schrieb Richard Brown:
On 14 July 2015 at 14:58, Thomas Langkamp
wrote: Sadly, as described here, this would make openSUSE liable for any patent infringement by encouraging our users to install patent encumbered software, or possibly even guilty of "facilitation of crime"
Thanks Richard for your reply :) Are you saying that there is a difference between providing
"yast / repos / add community repo"
and the same functionality as a desktop icon? Interesting. But Why? Only because the one is more hidden than the other? I cannot imagine how this would make a difference in court, but I am no lawyer also.
Precisely (and I recently double checked this with our lawyers)
One is clearly identified as 'not provided by the openSUSE Project' and it's a clear opt-in..the user has to go to it, know what it's for, and do it
The other, is a big flashing button that says 'hey, the openSUSE Project says you can get your codecs here'..
Thanks for clearing this one up. I am curious how ubuntu manages to get around legaly with its opt-in button during installation - does anyone know? Do they pay?
So what about my other points?
- when adding packman: automagically add packman with a 98 priority & allow vendor change once & automatically apply zypper up or dup afterwards (those more knowledgable should still be enabled to change priority / vendor change of course; this is about sane defaults for noobs)
I dislike this idea - I do not automatically favour Packman packages above openSUSE's, because openSUSE's are tested and Packmans are not
I disagree. Most users add packman-repo to get full multimedia (codec) capabilities, because the official packages do not fully work. So you kind of have to switch to packman. But if one adds packman-repo without vendor change or 98 priority almost nothing changes. He could even end up with a mixture of packages, for example vlc from packman but vlc-librarys from official repo and ends up with a completely broken vlc installation. This weighs heavier than if the packman packages are tested or not, if they are the only alternative for patented multimedia-stuff. If you can live with the official patent-free-ones, you most probably will just not add the packman-repo or you will use software from packman, that is not available in the official repo at all and thus is not conflicting in any way. To make the situation even better, maybe it would be possible to implement openQA also for the packman repo. Or would this also be illegal for openSUSE? I think my proposal is more noob-friendly, while the more knowledgeable should carry the burdon of changing the noob-friendly-defaults afterwards to their liking. A new linux or suse user just does not know anything about priorities or vendor change. True - in time - he should learn about those as I did. Thats what the wiki etc. are for. But if the learning curve is too steep already within the first few hours using suse, we will not get new users, nor good reviews at all. This feature whishlist is mostly a plea to you devs to think about the beginner user, to include him while you make plans for defaults and help them to have an easy start with openSUSE. No one can be forced to learn. The user has to like the OS first to even get the motivation to learn more about it in the long run. I stronly believe we need a broader user base even those noobs which cannot intall software in the beginning - because from those we can recruit more active community members in the long run. To keep suse exclusive to experienced users, by saying the new user first has to read tons of documentation before he starts with suse, will pay back badly in the long run I believe. Our guiding principles Carlos already cited - they say that we want include everybody! «... create a distribution which is stable, easy to use and a complete multi-purpose distribution for users and developers, for desktop and server use, for beginners and experienced users, for e v e r y b o d y. »
- install recommends: only once during installation as default
Neutral to the idea - this is similar to how I set up my servers (so I guess +1 in that scenario), but not my desktops (so -1 in that use case)
If I uninstall Kmail because I want thunderbird, but Kmail keeps coming back at me - how is this a scenario I want at the desktop?
- automatically update/grade the OS daily: by executing zypper up or dup in the background (via cron-job or graphical utility?) AFAIK apper still cannot propose solutions for conflicts and thus might not be feasible for this job.
I dislike this idea because of the lack of user-interaction, but it's not that dissimilar from how PackageKit already works in GNOME (Downloads in the background, but requires user interaction to actually install stuff)
this would be fine with me. however apper (for KDE) then needs an update for tumbleweed. In the moment it does not install anything but says that an error occured "installation abortet by the user" all the time. And if this works again, apper has to learn to solve conflicts and propose solutions for them instead of just leaving the user with an cryptic error message.
- Require minimal user intervention for the update/grade: require sudo password if new software is installed, but not when existing software is updated; but let the user know if he needs to restart or log-off.
No way in heck - Root access should be required to change the software on an openSUSE machine - SysAdmin 101
I thought other distros allowed this already with PolicyKit - if this is not the case - my bad. Then I am fine with typing my sudo password once. However then it would be nice to automatically add the first generated user-account on the system to the sudoers by default, while further users obviously should not get those privileges. Thanks for listening tomtomme -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-07-14 at 16:13 +0200, Richard Brown wrote:
- Require minimal user intervention for the update/grade: require sudo password if new software is installed, but not when existing software is updated; but let the user know if he needs to restart or log-off.
No way in heck - Root access should be required to change the software on an openSUSE machine - SysAdmin 101
erm.. PackageKit's default policies have been setup like this forever:
pkcon install supertuxkart => asks for root permission
pkcon update zsh -> zsh is being updated without root
password.
Even the full setup using offline update never asks for the root
password: PK downloads all patches in the background, on shutdown /
reboot, the user declares he wants to install updates on next boot.. no
root auth needed.
--
Dimstar / Dominique Leuenberger
On Tue, 14 Jul 2015 16:13:01 +0200, Richard Brown wrote:
Precisely (and I recently double checked this with our lawyers)
One is clearly identified as 'not provided by the openSUSE Project' and it's a clear opt-in..the user has to go to it, know what it's for, and do it
The other, is a big flashing button that says 'hey, the openSUSE Project says you can get your codecs here'..
Out of curiosity, what would the lawyers think about the option being presented at installation time, have it deselected by default, and have the installer present a dialogue box telling the user that the option is provided as a convenience for users where the code in question is not patent-encumbered, and that the user is responsible for abiding by their own local laws? Would that possibly be sufficient to move the liability from the project (and from SUSE itself)? Just kinda thinking out loud - I'm sure a similar idea has been proposed in the past. If not to the current legal folks, though, maybe worth a shot? Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 15 July 2015 at 21:52, Jim Henderson
On Tue, 14 Jul 2015 16:13:01 +0200, Richard Brown wrote:
Precisely (and I recently double checked this with our lawyers)
One is clearly identified as 'not provided by the openSUSE Project' and it's a clear opt-in..the user has to go to it, know what it's for, and do it
The other, is a big flashing button that says 'hey, the openSUSE Project says you can get your codecs here'..
Out of curiosity, what would the lawyers think about the option being presented at installation time, have it deselected by default, and have the installer present a dialogue box telling the user that the option is provided as a convenience for users where the code in question is not patent-encumbered, and that the user is responsible for abiding by their own local laws?
Would that possibly be sufficient to move the liability from the project (and from SUSE itself)?
Just kinda thinking out loud - I'm sure a similar idea has been proposed in the past. If not to the current legal folks, though, maybe worth a shot?
I threw an idea very similar to that past them..the answer was "in most countries that would be fine, but the US, no" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/14/2015 04:13 PM, Richard Brown wrote:
On 14 July 2015 at 14:58, Thomas Langkamp
wrote: Sadly, as described here, this would make openSUSE liable for any patent infringement by encouraging our users to install patent encumbered software, or possibly even guilty of "facilitation of crime"
Thanks Richard for your reply :) Are you saying that there is a difference between providing
"yast / repos / add community repo"
and the same functionality as a desktop icon? Interesting. But Why? Only because the one is more hidden than the other? I cannot imagine how this would make a difference in court, but I am no lawyer also. Precisely (and I recently double checked this with our lawyers)
One is clearly identified as 'not provided by the openSUSE Project' and it's a clear opt-in..the user has to go to it, know what it's for, and do it
The other, is a big flashing button that says 'hey, the openSUSE Project says you can get your codecs here'..
There could be a supplementary screen : * If you live in US click here (open-sources repositories, DMCA ok...). * If you live in UK/Germany/Europe... click here (Packman repository added) * If you live in space click here, at your own risk (All repos) Dsant -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Dimstar / Dominique Leuenberger
-
Dsant
-
Jim Henderson
-
Richard Brown
-
Thomas Langkamp