copie/colle des commandes & actualisation du wiki

smolski · 16-05-2015 08:24:32

Nous avons des problèmes de copie/colle des commandes issues du wiki df au lieu de les réécrire avec circonspiction, notamment en utilisant l'autocompletion.

Cette façon de faire des débutants qui débutent, mais aussi de la plupart des utilisateurs des wikis nous oblige à rédacter des lignes de commande qui tôt ou tard vont se trouver obsolètes et induire des erreurs surtout en root qui peuvent se montrer irréparables.

La thématique est :

Quelle formulation devons-nous mettre en place pour prévenir le copie/colle de commande via internet lorsqu'on ne la déchiffre pas auparavant et préférer la réécriture de ces commandes chez soi ?

1/ Où et comment la mettre en place automatiquement dans les tutos df ?
2/ Où et comment la mettre en place automatiquement sur le forum ?

Tchibâââ...

Dernière modification par smolski (16-05-2015 16:13:47)

sogal · 16-05-2015 08:50:09

Salut,
Peux-tu préciser, je ne suis pas spécifiquement au courant de ces problèmes et du coup j'ai rien compris

?
C'est quoi le soucis, la mise en forme entre le moment où quelqu'un copie une commande depuis son PC ou son émulateur de terminal dans le wiki ? C'est spécifique aux commandes ou cela concerne tout texte copié/collé ?

smolski · 16-05-2015 09:20:48

Reformulation dans le post#1

Ça va-t'y mieux ainsi ?

bendia · 16-05-2015 09:37:17

@sogal : le début du débat est là https://debian-facile.org/viewtopic.php … 39#p120339

Pour le fond du débat, ça mérite un tuto à chocolat qui liste les risques :

La malveillance de la part de l'auteur
L'erreur de la part de l'auteur
L'obsolescence du conseil

Ensuite, quelle est notre vision de Debian ici ? Une distrib qui demande de bien comprendre ce que tu fais sinon pas touche, ou une distrib «juste qui fonctionne» ? Ça sous-tend notre façon de rédiger les tutos.

Pour ma part, c'est le 2 Donc, on met des commandes copiables et on explique le pourquoi du comment.

Peut-être aussi doit-on définir une série de tutos importants pour les débutants auxquels il faut porter une attention soutenue, particulièrement à la publication d'une nouvelle stable.

smolski · 16-05-2015 09:45:44

Que la commande soit copiable n'empêche pas qu'elle soit vérifiée par une réécriture.
La prévention contre le copie/colle des commandes n'est pas seulement pour df mais pour tous les tutos d'entraide.

Une éducation à l'information via internet, pour aller plus loin.

milou · 16-05-2015 09:51:35

A mes débuts sous Linux, beaucoup d'intervenants qui aident recommandent de copier-coller les commandes pour éviter les erreurs.....

bendia · 16-05-2015 09:51:55

Bah, on ne peut empêcher personne de le faire

On peut juste le dire dans un tuto chocolat, et faire en sorte que si cela est fait depuis notre wiki, ça le soit sans dommage

Par ailleurs, pour ma part, en ce qui concerne les sources, sans copier/collé, c'est pénible.

milou · 16-05-2015 09:59:12

bendia a écrit :

Bah, on ne peut empêcher personne de le faire On peut juste le dire dans un tuto chocolat, et faire en sorte que si cela est fait depuis notre wiki, ça le soit sans dommage

Tout à fait d'accord pour l'avertissement. Et il faut reconnaître que si on se contente d'un copier coller, ce n'est pas la meilleure méthode pour retenir et comprendre ce que l'on fait.

bendia a écrit :

Par ailleurs, pour ma part, en ce qui concerne les sources, sans copier/collé, c'est pénible.

+1

sogal · 16-05-2015 11:21:18

@ smolski: vi vi merci!
@ bendia: et avec l'historique c'est encore plus clair

Pour ma part, je ne suis pas nécessairement favorable, comme ça a été évoqué, de mettre en place un système pour actualiser automatiquement les tutos en fonction de la release ou autre. Debian, comme tous les autres systèmes, évoluent en permanence et une partie des tutos se retrouvera, forcément, obsolète pour une durée plus ou moins longue.
Pour répondre en partie à la question de Bendia, je vois DF comme un site qui ne veut pas mâcher le travail du débutant mais le guider et lui donner les moyens d'apprendre, petit à petit et avec l'aide de tous, à et comprendre et maîtriser son système, bref le rendre autonome. Nulle autonomie ne peut s'atteindre sans un minimum d'effort et lire les tutos intégralement quand on ne connaît encore rien et, a fortiori, les bandeaux d'avertissement, me semble un effort minimum.

Pour les sources, un bandeau bien voyant en début de tutos qui résume l'ensemble des précautions à prendre (vérifier la release en cours, être attentif, voire demander conseil, avant de copier/coller, etc...) me paraît un moyen adéquat et suffisant.

Pour les mises en garde d'ordre général, on pourrait mettre en place la même chose dans les tutos génériques (https://debian-facile.org/doc:systeme:c … papillonne par exemple) pour bien marteler ces mises en garde.

Dernière modification par sogal (16-05-2015 11:21:45)

Papadakis · 16-05-2015 11:36:23

Un jour, l'année dernière, entre étudiants professionnels en formation (donc tous dans l'informatique), on se dit nos distros (genre 28 cm).
Ubuntu, Manjaro, Windows, ..., Mac ..., quand arrive mon tour, Debian.
"Mais t'es un cinglé toi".
"Tu fais tout en ligne de commande ?"
"T'as un environnement de bureau ?".

Voilà où on en est, même dans le milieu informatique.
Mais bon, c'est sûr qu'un débutant de chez débutant arrivant ici va se gaver de copier-coller, parce qu'il comprend pas ou par flemme.
Un gros placard en haut du tuto qui fournit l'info déjà présente débutants, confirmés, blabla (je regarde jamais ahah) mais qui fournit aussi l'info : avec copier-coller possibles ou copier-coller déconseillés ou copier-coller interdits.

Enfin voilà, c'est une idée comme ça et une anecdote.

Dernière modification par Papadakis (16-05-2015 11:37:52)

Anonyme-8 · 16-05-2015 11:41:18

Est ce que les gens sont obligés de comprendre ce qu'ils font?
Si quelqu'un veut juste utilisé un pc sous Debian pour de la bureautique, il veut un pc fonctionnel et pas nécessairement un cours d'admin linux. C'est son droit.

Il faudrait effectivement une série de tuto pour les débutants (éventuellement compléter https://debian-facile.org/doc:systeme:c … papillonne). Le guide de survie du débutant, et insister sur le fait que suivre une série de commande est loin d'être une bonne idée. C'est surtout sur les bonnes pratiques et l'attitude à avoir en cas de pb.

On en arrive là à cause du sources.list mais sur le wiki on a beaucoup trop de pages dessus et on manque de clarté. L'information est trop déstructuré à mon goût.
Quand je vois

wiki a écrit :

Configurations types recommandées en version monolithique

faut pas s'étonner que certains finissent par un simple copié / collé.

Si on veut un discussion constructive, il serait intéressant de prendre un exemple concret du wiki et de l'analyser pour en tirer les conclusions.
ça pourrait aussi aider à la rédaction du wiki en définissant les bonnes pratiques avec les choses à faire / pas faire et tous les conseils possibles.

captnfab · 16-05-2015 11:54:33

@Anonyme-8: je pense que là on dévie un peu du sujet initial, mais les problèmes que tu soulèves méritent à mon avis un sujet à eux seuls: « Comment avoir des tutos qui soient à la fois complets, non-redondants et accessibles aux utilisateurs qui attaquent le tuto par le 12e paragraphe ? » Pour éviter d'avoir à spliter le sujet plus tard, je préférerais qu'on ne mélange pas les deux discussions dans ce fil, même si elles sont bien sûr liées

smolski · 16-05-2015 11:55:32

Oui, il y a la discussion sur les tutos des sources.
Si on met tout ce qui concerne les sources sur une seule page, c'est confus. Il y faudrait un étalement de plusieurs pages mais avec un renvoi systématique dans chacune d'elles à toutes les autres concernant les sources.
Peut-être par numéro, genre :

apt
sources stables
sources.list.d/
sources testing
etc...

Sauf à y retirer la page en cours.

Dernière modification par smolski (16-05-2015 11:56:18)

Anonyme-8 · 16-05-2015 12:23:06

@captnfab: je pense que c'est une des raisons du pb. Déstructurer l'information sans avoir de cheminement logique fait qu'on a des passagers clandestins. A force de ne pas avoir d'explication complète et satisfaisant, on peut se limiter à recopier la première commande qui semble pertinente.
Je m’arrêterai là.

smolski: on ne pourra pas avoir une seule page sur ce sujet et c'est évident, et ton idée est bonne.

pour moi "APT : syntaxe d'un fichier sources.list" doit être mis en avant et pas dans une page séparée.
Pour moi, cette page devrait être le point d'entrée pour le sources.list. C'est le meilleur moyen d'éviter les copier / coller bête et méchant.

et sources.list.d ne doit pas être mis au même niveau que les autres pages car loin d'intéresser l'utilisateur débutant. L'ajouter dans la section "Aller plus loin" me semble plus juste. C'est simplement pour hiérarchisé l'information et faciliter la compréhension.

bendia · 16-05-2015 12:31:14

Pour ma part, les seules grosses bêtises que j'ai faites, je me suis débrouillé tout seul sans copié/collé, et avec l'auto-completion

Les risques me paraissent donc théoriques de copier une commande, en particulier si on a essayé de la comprendre. Comme dit milou, on conseille même parfois de le faire pour éviter les typo. Il me semble même que nous l'avons déjà fait ici.

Donc, franchement, à part ce que j'ai dit plus haut (tuto chocolat et lignes de commandes sans dangers), je ne vois pas ce qu'on peut faire d'autre.

vv222 · 16-05-2015 13:25:29

On parle depuis le début de bandeaux d'avertissements, ce qui paraît une bonne idée jusqu'à ce qu'on se rappelle ce qui a lancé la discussion à l'origine : les utilisateurs qui ne lisent *pas* les explications et se contentent de copier/coller les fichiers donnés en exemple dans les articles du wiki. Ceux-ci ne liront pas plus les éventuels avertissements, même s'ils sont en gras/couleur/surligné/clignotant… Et ceux qui lisent déjà l'article n'ont pas forcément besoin d'un avertissement supplémentaire, ils ont déjà envie de comprendre ce qu'ils font et sont donc probablement déjà prudents au moment de recopier un exemple.

Je pose donc à nouveau cette question, et si elle dérive trop de la question initiale faites-moi signe et j'ouvrirai une autre discussion : veut-on s'adresser à ces deux publics, ou uniquement aux lecteurs ?
Pour l'instant smolski nous propose de réfléchir à des méthodes pour que les copieurs deviennent des lecteurs, mais il ne faut pas oublier que certains ne veulent tout simplement pas fournir un effort de compréhension. Pas par mauvaise volonté, simplement parce qu'ils ne partagent pas forcément notre côté "passionné" et que pour eux l'outil informatique doit juste fonctionner sans prise de tête.

Mon avis, vous le connaissez déjà, est que les fichiers/commandes donnés en exemple dans nos articles doivent être suffisants pour que les copieurs puissent régler leur problème d'un simple copier/coller, et que le reste de l'article s'adresse aux lecteurs qui cherchent à comprendre "comment ça marche ?", ces derniers pouvant être lassés par un nombre trop important d'avertissements.

Dernière modification par vv222 (16-05-2015 13:25:57)

bendia · 16-05-2015 13:59:16

Je plussoie avec vv222. Si on donne des commandes mais qu'on dit Ne les copiez pas, ça implique que soit on est pas sûr de ce qu'on écrit, soit, qu'on est des truands, et ça donne confiance au lecteur (oui vv222, je suis dans la confiance en ce moment

).

smolski · 16-05-2015 14:06:52

Il faut et l'un, la commande juste à copier et l'autre étudier la commande/fichier si vous ne la comprenez pas.

Comment y parvenir ?

sogal · 16-05-2015 14:15:12

De toute façon, on ne pourra jamais contenter tous les types de publics. Et comme le dit vv222, les avertissements ne seront pas lus/vus par ceux qui veulent juste "consommer" le tuto.
Une bonne manière, et c'est déjà en partie fait, consiste à donner la commande (telle qu'elle peut être copiée/collée) puis à l'expliquer en détail.

Ou alors une connexion ssh sur l'ordi du débutant en question, on fait tout à sa place et tada "juste ça fonctionne":P

vv222 · 16-05-2015 14:27:24

smolski a écrit :

Il faut et l'un, la commande juste à copier et l'autre étudier la commande/fichier si vous ne la comprenez pas.

Comment y parvenir ?

Les explications sont déjà présentes dans la plupart de nos articles, et leur amélioration représente le gros du travail effectué sur le wiki au quotidien. Donc à mon avis pas grand chose à changer de ce côté, on avance déjà dans la bonne direction.
Ce qu'il faudrait c'est faire une passe sur l'intégralité du wiki (et oui, heureusement qu'on est nombreux à s'y intéresser) pour s'assurer que tous les exemples de fichiers/commandes qui y sont proposés puisse être "bêtement" copiés sans risque que ça casse quelque chose.

Pour revenir à l'exemple du fichier sources.list qui a lancé cette discussion, désigner les branches par leur nom de code ("jessie", "stretch", etc.) est à l'épreuve du temps, là où le même fichier utilisant les noms génériques des branches ("stable", "testing", etc.) pose le risque d'un système qui pourra avoir un comportement inattendu tous les deux ans (mise-à-jour "surprise" vers la nouvelle stable).
C'est à mon avis ce genre de détails qui mérite d'être débusqué et corrigé par une version moins ambiguë partout où c'est possible. Toujours garder en tête que s'il y a moyen de casser un système avec une commande proposée sur le wiki, on trouvera *toujours* quelqu'un pour le faire.

Il va sans dire que si je propose une telle relecture massive c'est que je me porte volontaire pour y participer

smolski · 16-05-2015 14:29:09

sogal a écrit :

De toute façon, on ne pourra jamais

Ah ah ah

Faisons au mieux et cette discussion ouverte déjà bien animée le prouve, on peut chercher mieux qu'actuellement.
Ne baissons pas les bras et continuons à faire des propositions concrètes.

Nous pourrions trouver en commun une formulation incitative à la lecture et à l'ouverture des liens en rapport avec le tuto en cours et à la placer de manière active, par survol de la souris par exemple...

bendia · 16-05-2015 14:30:36

On est sage que de sa propre expérience

smolski · 16-05-2015 14:39:10

vv222 a écrit :

faire une passe sur l'intégralité du wiki

Ça, ça me paraît bien lourdingue en réalité, nous sommes tous des bénévoles et des passionnés, c'est peut-être pas une charge qu'il est nécessaire d'assumer d'un coup d'un seul, mais on peut se la redistribuer dans ce sens au fur et à mesure que le forum renvoie vers tel ou tel tuto ?

Peut-être ajouter :

mise à jour le : date

vv222 · 16-05-2015 14:45:36

smolski a écrit :

vv222 a écrit :
faire une passe sur l'intégralité du wiki

Ça, ça me paraît bien lourdingue en réalité, nous sommes tous des bénévoles et des passionnés, c'est peut-être pas une charge qu'il est nécessaire d'assumer d'un coup d'un seul, mais on peut se la redistribuer dans ce sens au fur et à mesure que le forum renvoie vers tel ou tel tuto ?

Peut-être ajouter :
mise à jour le : date

Hey, je ne parlais pas de la faire avant demain hein
Bien sûr, il faut prendre son temps avec ce genre de choses, disons plutôt que la "copiabilité" des commandes est un nouveau point à avoir en tête lorsqu'on bosse sur un article.

L’ajout de la date de dernière mise-à-jour, c'est quelque chose qui est déjà en place sur le wiki, non ?
En tout cas c'est aussi quelque chose d'important : un article mis-à-jour le mois dernier inspire bien plus de confiance qu'un article qui n'a pas bougé depuis 2008.

smolski · 16-05-2015 14:50:06

vv222 a écrit :

L’ajout de la date de dernière mise-à-jour, c'est quelque chose qui est déjà en place sur le wiki, non ?

On a : testé par.. le ... mais pas : mis à jour par... le...

Refaire un test d'un tuto est une chose, en actualiser les commandes une autre.

Debian-facile

#1 16-05-2015 08:24:32

copie/colle des commandes & actualisation du wiki

#2 16-05-2015 08:50:09

Re : copie/colle des commandes & actualisation du wiki

#3 16-05-2015 09:20:48

Re : copie/colle des commandes & actualisation du wiki

#4 16-05-2015 09:37:17

Re : copie/colle des commandes & actualisation du wiki

#5 16-05-2015 09:45:44

Re : copie/colle des commandes & actualisation du wiki

#6 16-05-2015 09:51:35

Re : copie/colle des commandes & actualisation du wiki

#7 16-05-2015 09:51:55

Re : copie/colle des commandes & actualisation du wiki

#8 16-05-2015 09:59:12

Re : copie/colle des commandes & actualisation du wiki

#9 16-05-2015 11:21:18

Re : copie/colle des commandes & actualisation du wiki

#10 16-05-2015 11:36:23

Re : copie/colle des commandes & actualisation du wiki

#11 16-05-2015 11:41:18

Re : copie/colle des commandes & actualisation du wiki

#12 16-05-2015 11:54:33

Re : copie/colle des commandes & actualisation du wiki

#13 16-05-2015 11:55:32

Re : copie/colle des commandes & actualisation du wiki

#14 16-05-2015 12:23:06

Re : copie/colle des commandes & actualisation du wiki

#15 16-05-2015 12:31:14

Re : copie/colle des commandes & actualisation du wiki

#16 16-05-2015 13:25:29

Re : copie/colle des commandes & actualisation du wiki

#17 16-05-2015 13:59:16

Re : copie/colle des commandes & actualisation du wiki

#18 16-05-2015 14:06:52

Re : copie/colle des commandes & actualisation du wiki

#19 16-05-2015 14:15:12

Re : copie/colle des commandes & actualisation du wiki

#20 16-05-2015 14:27:24

Re : copie/colle des commandes & actualisation du wiki

#21 16-05-2015 14:29:09

Re : copie/colle des commandes & actualisation du wiki

#22 16-05-2015 14:30:36

Re : copie/colle des commandes & actualisation du wiki

#23 16-05-2015 14:39:10

Re : copie/colle des commandes & actualisation du wiki

#24 16-05-2015 14:45:36

Re : copie/colle des commandes & actualisation du wiki

#25 16-05-2015 14:50:06

Re : copie/colle des commandes & actualisation du wiki

Pied de page des forums