Je me suis fait aussi avoir … pour insérer des blocs de code il faut une ligne vide avant le délimiteur de début de bloc de code (les 3 quotes inversées).
Il me semble que ton affirmation nécessite une référence.
Je n'ai malheureusement pas de référence publique, ce benchmark avait été fait chez un opérateur réseau/téléphonie en interne( je l'ai vu lors d'une de mes missions chez cet opérateur), et date pas mal (une dizaine d'année je pense), et dans un contexte donné (gestion de trames SNMP dans une solution de supervision réseau style CACTI). Il est fort possible que Python se soit amélioré depuis par rapport à Perl. D'autre part, python "triche" un peu dans certains cas avec utilisation de bindings python vers bibliothèques écrites en C et compilées, donc on ne peut pas forcément parler de code natif.
Celà dit le sens de mon propos n'est pas forcément d'affirmer qu'aujourd'hui, Perl est plus performant que Python. Ca a été le cas à une époque (au moins pour certains types de traitements), c'était un de ses points forts par rapport à Python, mais malgré cet avantage à ce moment, ce point n'a pas empêché celui-ci de perdre en popularité.
Normalement, en une seule fois ça passe (pas besoin d'intermédiaire):
:g/^d/d
Il n'est pas utile de remplacer quoi que ce soit pour que ça marche. Mon explication sur le remplacement était là pour faire comprendre le mode de fonctionnement de VIM, et ce qu'il permet de faire en général. Ca permet de comprendre la logique (et peut servir plus tard).
Ca ne marchera pas dans tous les cas. Si une ligne commence par "dr--" (lecture uniquement pour le propriétaire), tu ne le trouveras pas. D'autre part, si tu as un fichier qui contient "drwx" dans son nom, il sera supprimé également.
Oui c'est exactement ça. Il te suffit de trouver la regexp qui permet d'identifier toutes les lignes qui commencent par 'd' et de les supprimer comme je te l'ai indiqué dans les précédents posts.
En fait pour être plus précis, g signifie "global". Si on ne spécifie pas "g dans l'expression ( :/toto/d ) , la commande s'exécutera sur la ligne courante : la ligne courante sera supprimée si elle contient l'expression 'toto', et vim demande d'appuyer sur "n" pour trouver le suivant.
Oups … j'ai oublié une étape (le commentaire sous le mien me l'a rappelé, merci à kangourou13000 ) : pour la suppression des lignes il fait ajouter 'd' à la fin ce qui donne pour mon exemple :
En mode édition, Vi(m) permet de faire de la modification massive de fichiers sur tout ou partie de celui-ci.
Par exemple pour faire de la substitution de texte, il est possible d'utiliser "s". Pour remplacer la première occurence de "toto" par "titi" dans un fichier, il suffit de taper la séquence suivante en mode commande :
:s/toto/titi/
s pour substitute, ensuite on fait comme avec sed, on positionne entre /// la regexp source puis la chaine cible. Il est d'usage d'utiliser le / comme caractère de séparation, mais on peut aussi en utiliser d'autres (tels que !, :, … et l'expression devient alors :s!toto!titi!), ce qui est pratique lorsque la regexp contient des '/' A noter que cette commande ne se fera que sur la ligne courante.
Pour faire la modification sur plusieurs lignes, il suffit de spécifier les lignes sur lesquelles on veut faire la modif
:2s/toto/titi/
Cette commande va remplacer la première expression 'toto' par 'titi' en ligne 2. Pour le faire sur plusieurs lignes :
:1,3s/toto/titi/
Cette commande va remplacer la première expression 'toto' par 'titi' sur les lignes 1 à 3. Pour le faire sur la totalité du fichier :
:1,$s/toto/titi/
Le remplacement se fera de la ligne 1 à la dernière ligne, symbolisée par le caractère '$'
Autre point : pour remplacer la totalité des occurences de l'expression régulière sur une ligne plutôt que la première, il suffit d'ajouter un 'g' à la fin de la commande :
:1,$s/toto/titi/g
Ici on remplacera, dans tous le fichier (1,$) l'expression 'toto' par 'titi' sur toutes les lignes. Il existe d'autres flags que 'g' (utilisés également avec sed et awk) que je ne détillerai pas ici pour éviter d'embrouiller, mais vous pouvez aller voir cette documentation. Ce sont plus ou moins les mêmes que pour sed.
Nous avons vu comment remplacer du texte dans ceraines lignes via des regexp. Maintenant commant les supprimer ?
Il suffit d'utiliser 'g' comme ceci pour supprimer par exemple toutes les lignes contenant l'expression toto dans le fichier :
:g/toto/
Ici, pas besoin de spécifier les lignes sur lesquelles la commande s'exécutera, elle se fera sur l'ensemble du fichier. Toutes les lignes contenant 'toto' seront supprimées.
Du coup pour répondre à ta question, il te suffit d'identifier dans ton fichier une expression qui te permet de distinguer un répertoire d'un fichier, et d'utiliser la commande que je t'ai donnée au dessus. Je te laisse chercher un peu la regexp à utiliser ….
Merci pour le retour. Il est vrai que pour ma part, toutes les actions avancées que je dois faire avec Git, je les fais soit en CLI en local, soit via l'IHM de mon gestionnaire de repo. J'utilise essentiellement en milleu pro ou perso Gitlab/github qui permettent de voir pas mal de choses au niveau des historiques et des comparaisons de branches. De ce fait je n'ai pas forcément eu besoin d'autre chose. De toute façon quand j'ai eu besoin de faire quelque chose de plus compliqué que ce que faisait l'IDE, c'est parce que j'avais un gros problème à résoudre et dans ce cas rien ne vaut la bonne vieille ligne de commande. Mais j'essaierai à l'occasion pour voir ce qu'une GUI apporte.
Je n'ai jamais vraiment utilisé ce genre d'outil (excepté tortoise Git à une époque sous windows au travail), et je n'ai pas été vraiment convaincu de leur réelle utilité. Les IDE un peu avancés (VSCodium, Eclipse, etc …) contiennent des plugins permettant de gérer des repo GIT. En quoi une GUI apporte-t-elle quelque chose ?
Il n'y a pas que ça : quand je vois ce que me retourne chatGPT quand je lui demande certaines choses … il suffit que le médecin soit un peu pressé et qu'il ne contrôle pas correctement la synthèse que lui a retourné chatgpt et qu'une grosse erreur apparaisse dans le dossier …. ça m'inquiète.
au dela il faut faire 3 primaires, une partition etendue, et dans l'etendue faire des partitions logiques
Perso dans ce cas je préfère faire du LVM (hors des partitions EFI ou spécifiques au raspberry pour pouvoir démarrer). Ca évite la prise de tête sur les partitions étendues/logiques. L'inconvénient avec LVM par contre c'est la récupération de données via des outils tels que photorec.
Annoncer une trois décennies d'un coup, soit quasiment la durée de vie putative initiale, ça paraît présomptueux
Ce n'est pas parce que Microsoft prévoit de l'exploiter 30 ans qu'en pratique ils pourront le faire. Il s'agit je pense surtout d'une estimation (pour ce genre de projet il est nécessaire je pense de se projeter suffisamment dans le temps).
Comme tu le dis, l'effet "cathédrale" permet d'avoir de la documentation cohérente car les BSD ne sont pas un assemblage d'éléments indépendants, mais un tout cohérent. De plus, j'ai l'impression que sur les divers BSD, le but n'est pas d'avoir la dernière fonctionnalité à la mode ou de suivre la dernière windowserie ou Applerie à la mode, mas d'avoir un système stable et bien documenté, et surtout de ne pas passer son temps à faire, défaire et refaire un truc qui marche déjà. Alors certes on a l'impression qu'ils avancent moins vite que Linux, mais de mon point de vue ce n'est qu'une impression : même s'ils mettent mois de temps à sortir certaines fonctionnalités, ils passent aussi moins de temps à revenir dessus parce qque ça a pas été bien pensé.
J'approuve : j'ai trouvé dans la doc Arch bien plus d'informations pertinentes sur la configuration de NetworkManager par exemple, ou sur systemd, que n'importe ou ailleurs.
Déjà parce que les utilisateurs et utilisatrices finaux commencent souvent pas regarder là-dedans.
Hum … ça j'en mettrai pas ma main à couper. Je dirais que la plupart des gens font comme à la maison : il ne lisent pas le mode d'emploi et vont demander aux autres. En tout cas c'est ce que je constate quotidiennement au travail : bien peu de gens lisent les deux principaux éléments qui permettre de résoudre une grosse partie des problèmes : 1: la documentation (quand elle existe bien sûr) et 2: les logs. Ils préfèrent se perdre en conjonctures farfelues pour dire la fin que ça ne marche pas.
Pour moi le principal problème c'est que beaucoup de développeurs eux-même se foutent royalement de la documentation. Alors oui, écrire un manuel d'utilisation c'est un métier à part entière. Mais entre juste fournir le code et une image docker (ou un snap/appimage/flatpack) et un magnifique manuel utilisateur en 72 langues, je pense qu'il y a un juste milieu.
Tu t'es bien fait comprendre, ne t'inquiète pas. C'est aussi de ça dont je parlais quand je disais que du point de vue de la FSF et de Stallman, le copyright est privateur.
Alors oui, ce n'est pas sur le site de la FSF mais sur le site de gnu.org, qui est soutenu par la FSF. J'ai essayé d'aller voir sur les archives de la FSF France pour voir si ce mot était employé, mais je n'ai pas trouvé.
Donc dire que personne - même pas la FSF ne définit pas ce terme, c'est plutôt faux (je me concentrerai surtout sur ce fait ici, le reste viendra plus tard).
Je pense qu'effectivement je n'ai pas été assez attentif à la signification du mot "priver". D'après le dictionnaire Robert : "Empêcher (qqn) de jouir d'un bien, d'un avantage présent ou futur ; lui ôter ce qu'il a ou lui refuser ce qu'il espère." Je pense que le mot intéressant est "ôter". De ton point de vue (et je le comprends), une licence "ouvre " des droits qui sont par défaut non accordés. Donc de ce point de vue, elle ne "prive pas", mais elle libère. Mais c'est juste regarder un seul aspect des droits d'auteur, copyright, et licence.
Du coup la GPL est privatrice suivant ta logique car il y a des droits qu'elle ne m'accorde pas.
Si on se place du point de vue de Stallman et de la FSF, le copyright ( et je pense patr extension le droit d'auteur) est "privateur", et le copyleft a été créé comme un hack au copyright. Ils estiment que par défaut le logiciel doit être librement redistribuable, et les codes sources accessibles. On peut être d'accord ou non avec ce point de vue, mais si on se place de ce point de vue, le copyright et la licence sont effectivement "privateurs".
Note que je n'aime pas ce terme non plus, que je ne milite pour rien du tout, que je suis loin d'être un adepte de la FSF et de la GPL. Perso je m'en fous un peu que les gens utilisent du libre ou non, qu'ils fassent du libre ou non, tant que l'un des deux mondes n'empeche pas l'autre d'exister. Par contre j'essaie de comprendre les points de vue des autres même si je n'y adhère pas.
Rappelons que personne ne définit "privateur", même pas la FSF, c'est du plaisir perso de prosélytiste n'aimant pas parler de libre en truc bien mais ayant besoin d'attaquer ce qui est différent comme si le libre n'était pas assez bien pour en parler)
Je crois que tu as un problème à voir des attaques là ou il n'y en a pas. Je ne fais qu'exprimer un point de vue. Pas besoin d'être aussi dénigrant ni agressif.
[^] # Re: Il suffit d'analyser la liste
Posté par totof2000 . En réponse au message Vim - Affichage des répertoires sur d'une liste. Évalué à 3.
Je me suis fait aussi avoir … pour insérer des blocs de code il faut une ligne vide avant le délimiteur de début de bloc de code (les 3 quotes inversées).
[^] # Re: performances
Posté par totof2000 . En réponse au journal Utilisation de Perl aujourd'hui.. Évalué à 6.
Je n'ai malheureusement pas de référence publique, ce benchmark avait été fait chez un opérateur réseau/téléphonie en interne( je l'ai vu lors d'une de mes missions chez cet opérateur), et date pas mal (une dizaine d'année je pense), et dans un contexte donné (gestion de trames SNMP dans une solution de supervision réseau style CACTI). Il est fort possible que Python se soit amélioré depuis par rapport à Perl. D'autre part, python "triche" un peu dans certains cas avec utilisation de bindings python vers bibliothèques écrites en C et compilées, donc on ne peut pas forcément parler de code natif.
Celà dit le sens de mon propos n'est pas forcément d'affirmer qu'aujourd'hui, Perl est plus performant que Python. Ca a été le cas à une époque (au moins pour certains types de traitements), c'était un de ses points forts par rapport à Python, mais malgré cet avantage à ce moment, ce point n'a pas empêché celui-ci de perdre en popularité.
[^] # Re: Il suffit d'analyser la liste
Posté par totof2000 . En réponse au message Vim - Affichage des répertoires sur d'une liste. Évalué à 4. Dernière modification le 06 octobre 2024 à 13:28.
Normalement, en une seule fois ça passe (pas besoin d'intermédiaire):
Il n'est pas utile de remplacer quoi que ce soit pour que ça marche. Mon explication sur le remplacement était là pour faire comprendre le mode de fonctionnement de VIM, et ce qu'il permet de faire en général. Ca permet de comprendre la logique (et peut servir plus tard).
Vérifie quand même …
[^] # Re: Il suffit d'analyser la liste
Posté par totof2000 . En réponse au message Vim - Affichage des répertoires sur d'une liste. Évalué à 2. Dernière modification le 06 octobre 2024 à 13:02.
La clé c'est c'est "ligne qui commence par"
[^] # Re: Il suffit d'analyser la liste
Posté par totof2000 . En réponse au message Vim - Affichage des répertoires sur d'une liste. Évalué à 4.
Ca ne marchera pas dans tous les cas. Si une ligne commence par "dr--" (lecture uniquement pour le propriétaire), tu ne le trouveras pas. D'autre part, si tu as un fichier qui contient "drwx" dans son nom, il sera supprimé également.
Il y a moyen de le faire en une seule fois :
```
:g//d
[^] # Re: Il suffit d'analyser la liste
Posté par totof2000 . En réponse au message Vim - Affichage des répertoires sur d'une liste. Évalué à 4.
Oui c'est exactement ça. Il te suffit de trouver la regexp qui permet d'identifier toutes les lignes qui commencent par 'd' et de les supprimer comme je te l'ai indiqué dans les précédents posts.
[^] # Re: Il suffit d'analyser la liste
Posté par totof2000 . En réponse au message Vim - Affichage des répertoires sur d'une liste. Évalué à 4.
Petit coup de pouce pour la trouver : qu'est-ce qui différencie un répertoire d'un fichier dans ta liste ?
[^] # Re: Il suffit d'analyser la liste
Posté par totof2000 . En réponse au message Vim - Affichage des répertoires sur d'une liste. Évalué à 3.
En fait pour être plus précis, g signifie "global". Si on ne spécifie pas "g dans l'expression ( :/toto/d ) , la commande s'exécutera sur la ligne courante : la ligne courante sera supprimée si elle contient l'expression 'toto', et vim demande d'appuyer sur "n" pour trouver le suivant.
[^] # Re: cool des regex XD
Posté par totof2000 . En réponse au message Vim - Affichage des répertoires sur d'une liste. Évalué à 3.
Non, ta réponse a été utile : j'avais oublié un détail à la fin, et lire ton commentaire me l'a rappelé ..
[^] # Re: Il suffit d'analyser la liste
Posté par totof2000 . En réponse au message Vim - Affichage des répertoires sur d'une liste. Évalué à 3. Dernière modification le 06 octobre 2024 à 11:49.
Oups … j'ai oublié une étape (le commentaire sous le mien me l'a rappelé, merci à kangourou13000 ) : pour la suppression des lignes il fait ajouter 'd' à la fin ce qui donne pour mon exemple :
# Il suffit d'analyser la liste
Posté par totof2000 . En réponse au message Vim - Affichage des répertoires sur d'une liste. Évalué à 4. Dernière modification le 06 octobre 2024 à 11:42.
En mode édition, Vi(m) permet de faire de la modification massive de fichiers sur tout ou partie de celui-ci.
Par exemple pour faire de la substitution de texte, il est possible d'utiliser "s". Pour remplacer la première occurence de "toto" par "titi" dans un fichier, il suffit de taper la séquence suivante en mode commande :
s pour substitute, ensuite on fait comme avec sed, on positionne entre /// la regexp source puis la chaine cible. Il est d'usage d'utiliser le / comme caractère de séparation, mais on peut aussi en utiliser d'autres (tels que !, :, … et l'expression devient alors :s!toto!titi!), ce qui est pratique lorsque la regexp contient des '/' A noter que cette commande ne se fera que sur la ligne courante.
Pour faire la modification sur plusieurs lignes, il suffit de spécifier les lignes sur lesquelles on veut faire la modif
Cette commande va remplacer la première expression 'toto' par 'titi' en ligne 2. Pour le faire sur plusieurs lignes :
Cette commande va remplacer la première expression 'toto' par 'titi' sur les lignes 1 à 3. Pour le faire sur la totalité du fichier :
Le remplacement se fera de la ligne 1 à la dernière ligne, symbolisée par le caractère '$'
Autre point : pour remplacer la totalité des occurences de l'expression régulière sur une ligne plutôt que la première, il suffit d'ajouter un 'g' à la fin de la commande :
Ici on remplacera, dans tous le fichier (1,$) l'expression 'toto' par 'titi' sur toutes les lignes. Il existe d'autres flags que 'g' (utilisés également avec sed et awk) que je ne détillerai pas ici pour éviter d'embrouiller, mais vous pouvez aller voir cette documentation. Ce sont plus ou moins les mêmes que pour sed.
Nous avons vu comment remplacer du texte dans ceraines lignes via des regexp. Maintenant commant les supprimer ?
Il suffit d'utiliser 'g' comme ceci pour supprimer par exemple toutes les lignes contenant l'expression toto dans le fichier :
Ici, pas besoin de spécifier les lignes sur lesquelles la commande s'exécutera, elle se fera sur l'ensemble du fichier. Toutes les lignes contenant 'toto' seront supprimées.
Du coup pour répondre à ta question, il te suffit d'identifier dans ton fichier une expression qui te permet de distinguer un répertoire d'un fichier, et d'utiliser la commande que je t'ai donnée au dessus. Je te laisse chercher un peu la regexp à utiliser ….
[^] # Re: quel est l'avantage de ce genre d'outil, par rapport à un IDE ?
Posté par totof2000 . En réponse au journal Gitnuro, un interface graphique pour Git, sort en version 1.4. Évalué à 2. Dernière modification le 03 octobre 2024 à 15:57.
Merci pour le retour. Il est vrai que pour ma part, toutes les actions avancées que je dois faire avec Git, je les fais soit en CLI en local, soit via l'IHM de mon gestionnaire de repo. J'utilise essentiellement en milleu pro ou perso Gitlab/github qui permettent de voir pas mal de choses au niveau des historiques et des comparaisons de branches. De ce fait je n'ai pas forcément eu besoin d'autre chose. De toute façon quand j'ai eu besoin de faire quelque chose de plus compliqué que ce que faisait l'IDE, c'est parce que j'avais un gros problème à résoudre et dans ce cas rien ne vaut la bonne vieille ligne de commande. Mais j'essaierai à l'occasion pour voir ce qu'une GUI apporte.
# quel est l'avantage de ce genre d'outil, par rapport à un IDE ?
Posté par totof2000 . En réponse au journal Gitnuro, un interface graphique pour Git, sort en version 1.4. Évalué à 3. Dernière modification le 03 octobre 2024 à 12:37.
Je n'ai jamais vraiment utilisé ce genre d'outil (excepté tortoise Git à une époque sous windows au travail), et je n'ai pas été vraiment convaincu de leur réelle utilité. Les IDE un peu avancés (VSCodium, Eclipse, etc …) contiennent des plugins permettant de gérer des repo GIT. En quoi une GUI apporte-t-elle quelque chose ?
[^] # Re: Toujours pareil
Posté par totof2000 . En réponse au lien Doctolib déploie une IA pour capter et analyser les conversations patients-médecins ! . Évalué à 5.
Il n'y a pas que ça : quand je vois ce que me retourne chatGPT quand je lui demande certaines choses … il suffit que le médecin soit un peu pressé et qu'il ne contrôle pas correctement la synthèse que lui a retourné chatgpt et qu'une grosse erreur apparaisse dans le dossier …. ça m'inquiète.
[^] # Re: Ctrl + N
Posté par totof2000 . En réponse au message Pourquoi GNOME est devenu un logiciel privateur de liberté ?. Évalué à 2.
Le problème des extensions gnome, c'est que d'une version à l'autre elle risque de ne plus marcher (idem pour firefox d'ailleurs).
[^] # Re: MBR vers GPT, pourquoi faire ?
Posté par totof2000 . En réponse au message Debian pour raspberry : Modifier table de partition du .img produit DOS -> GPT. Évalué à 2.
Perso dans ce cas je préfère faire du LVM (hors des partitions EFI ou spécifiques au raspberry pour pouvoir démarrer). Ca évite la prise de tête sur les partitions étendues/logiques. L'inconvénient avec LVM par contre c'est la récupération de données via des outils tels que photorec.
[^] # Re: gdisk
Posté par totof2000 . En réponse au message Debian pour raspberry : Modifier table de partition du .img produit DOS -> GPT. Évalué à 3.
Il semble d'après ce lien que ce soit possible.
[^] # Re: Durée de vie ?
Posté par totof2000 . En réponse au message Microsoft relance la centrale nucléaire de Three Miles Island.. Évalué à 5.
Ce n'est pas parce que Microsoft prévoit de l'exploiter 30 ans qu'en pratique ils pourront le faire. Il s'agit je pense surtout d'une estimation (pour ce genre de projet il est nécessaire je pense de se projeter suffisamment dans le temps).
[^] # Re: les BSDs...
Posté par totof2000 . En réponse au lien La documentation sur Linux et les logiciels libres est un véritable capharnaüm. Évalué à 4.
Comme tu le dis, l'effet "cathédrale" permet d'avoir de la documentation cohérente car les BSD ne sont pas un assemblage d'éléments indépendants, mais un tout cohérent. De plus, j'ai l'impression que sur les divers BSD, le but n'est pas d'avoir la dernière fonctionnalité à la mode ou de suivre la dernière windowserie ou Applerie à la mode, mas d'avoir un système stable et bien documenté, et surtout de ne pas passer son temps à faire, défaire et refaire un truc qui marche déjà. Alors certes on a l'impression qu'ils avancent moins vite que Linux, mais de mon point de vue ce n'est qu'une impression : même s'ils mettent mois de temps à sortir certaines fonctionnalités, ils passent aussi moins de temps à revenir dessus parce qque ça a pas été bien pensé.
[^] # Re: …pas seulement commerciales
Posté par totof2000 . En réponse au lien La documentation sur Linux et les logiciels libres est un véritable capharnaüm. Évalué à 3.
J'approuve : j'ai trouvé dans la doc Arch bien plus d'informations pertinentes sur la configuration de NetworkManager par exemple, ou sur systemd, que n'importe ou ailleurs.
[^] # Re: La documentation est un véritable capharnaüm
Posté par totof2000 . En réponse au lien La documentation sur Linux et les logiciels libres est un véritable capharnaüm. Évalué à 6.
Hum … ça j'en mettrai pas ma main à couper. Je dirais que la plupart des gens font comme à la maison : il ne lisent pas le mode d'emploi et vont demander aux autres. En tout cas c'est ce que je constate quotidiennement au travail : bien peu de gens lisent les deux principaux éléments qui permettre de résoudre une grosse partie des problèmes : 1: la documentation (quand elle existe bien sûr) et 2: les logs. Ils préfèrent se perdre en conjonctures farfelues pour dire la fin que ça ne marche pas.
[^] # Re: La solution ? Payez :>
Posté par totof2000 . En réponse au lien La documentation sur Linux et les logiciels libres est un véritable capharnaüm. Évalué à 3.
Pour moi le principal problème c'est que beaucoup de développeurs eux-même se foutent royalement de la documentation. Alors oui, écrire un manuel d'utilisation c'est un métier à part entière. Mais entre juste fournir le code et une image docker (ou un snap/appimage/flatpack) et un magnifique manuel utilisateur en 72 langues, je pense qu'il y a un juste milieu.
[^] # Re: Ben si
Posté par totof2000 . En réponse au lien Licences « Fair Source » : ni libres, ni open-source, ni privatrices. Évalué à 6.
Tu t'es bien fait comprendre, ne t'inquiète pas. C'est aussi de ça dont je parlais quand je disais que du point de vue de la FSF et de Stallman, le copyright est privateur.
[^] # Re: Ben si
Posté par totof2000 . En réponse au lien Licences « Fair Source » : ni libres, ni open-source, ni privatrices. Évalué à 4.
Bon … tu veux des faits ?
https://www.gnu.org/philosophy/categories.html#ProprietarySoftware
Alors oui, ce n'est pas sur le site de la FSF mais sur le site de gnu.org, qui est soutenu par la FSF. J'ai essayé d'aller voir sur les archives de la FSF France pour voir si ce mot était employé, mais je n'ai pas trouvé.
Donc dire que personne - même pas la FSF ne définit pas ce terme, c'est plutôt faux (je me concentrerai surtout sur ce fait ici, le reste viendra plus tard).
[^] # Re: Ben si
Posté par totof2000 . En réponse au lien Licences « Fair Source » : ni libres, ni open-source, ni privatrices. Évalué à 5.
Je pense qu'effectivement je n'ai pas été assez attentif à la signification du mot "priver". D'après le dictionnaire Robert : "Empêcher (qqn) de jouir d'un bien, d'un avantage présent ou futur ; lui ôter ce qu'il a ou lui refuser ce qu'il espère." Je pense que le mot intéressant est "ôter". De ton point de vue (et je le comprends), une licence "ouvre " des droits qui sont par défaut non accordés. Donc de ce point de vue, elle ne "prive pas", mais elle libère. Mais c'est juste regarder un seul aspect des droits d'auteur, copyright, et licence.
Si on se place du point de vue de Stallman et de la FSF, le copyright ( et je pense patr extension le droit d'auteur) est "privateur", et le copyleft a été créé comme un hack au copyright. Ils estiment que par défaut le logiciel doit être librement redistribuable, et les codes sources accessibles. On peut être d'accord ou non avec ce point de vue, mais si on se place de ce point de vue, le copyright et la licence sont effectivement "privateurs".
Note que je n'aime pas ce terme non plus, que je ne milite pour rien du tout, que je suis loin d'être un adepte de la FSF et de la GPL. Perso je m'en fous un peu que les gens utilisent du libre ou non, qu'ils fassent du libre ou non, tant que l'un des deux mondes n'empeche pas l'autre d'exister. Par contre j'essaie de comprendre les points de vue des autres même si je n'y adhère pas.
Je crois que tu as un problème à voir des attaques là ou il n'y en a pas. Je ne fais qu'exprimer un point de vue. Pas besoin d'être aussi dénigrant ni agressif.