Faire des logiciels privateurs est un/une choix/démarche idéologique et politique.
Tu mélange 2 choses différentes :
démarche politique la démarche implique une visée. Ce n'est pas parce que tu fais un acte politique que tu as une visée politique. Ton action interagit avec la société, mais ce n'est pas ton but
choix politique je te sais pas trop ce que tu entend par là, mais je présume que tu parle d'acte politique et oui tout action qui interagit avec la société (ou qui en modifie l'interaction) est politique, mais ça n'est pas une notion très intéressante, c'est tellement universaliste qu'il n'y a pas grand chose à en dire
Ici je pense qu'il est reproché à la démarche politique et pas l'acte politique. L'altruiste peut avoir ou non une démarche politique: glanner est généralement accompagné d'une démarche politique alors qu'aider une personne âgée à traverser l'est rarement.
Quand ton logiciel est cassé, pourquoi ne pourrais-tu pas le réparer toi-même ? Alors certes, nous ne sommes pas tous développeurs, pas plus que nous sommes tous mécanos, électriciens, etc… Mais tu as la possibilité de le faire, ou de le faire faire.
Pas vraiment non. La complexité des logiciels augmente beaucoup plus vite que l'électroménager. Tu as maintenant beaucoup de mal à réparer de l'électroménager trop sophistiqué ? He ben dans le logiciel c'est largement pire.
Tu n'as peut-être pas la capacité de l'exercer pleinement mais tu l'as. Tu n'es pas dépendant de qui que ce soit.
Un pouvoir que tu as sans pouvoir l'exercer ? Intéressant…
Cependant, à quels "vieux bugs restant dans les logiciels libres" tu penses ? Dans un projet libre maintenu, sauf cas très particulier, il y a assez peu de bugs historiques (du moins, rien qui puisse réellement impacter l'utilisation du logiciel). Tu aurais des exemples ?
Je ne sais pas ce que tu entend par "ne puisse réellement impacter l'utilisation du logiciel", mais pythran vient de corriger un bug vieux de 5 ans, gimp a un ticket sur l'enregistrement de macro qui a plus de 10 ans. Mais je ne parle que des cas que je connais ça voir les bugs trackers tu sera surpris.
Et c'est pareil pour tout les domaines. Les logiciels privateurs donnent un pouvoir aux développeurs (et à l'entreprise) sur le consommateur là où le logiciel libre distribue équitablement les pouvoirs entre les différents acteurs.
Purement théorique. Il donne le pouvoir à tous les développeurs éventuellement. Je sais que dans ta théorie l'utilisateur peut soit devenir développeur, soit payer les services d'un développeur, mais c'est justement en ça que c'est le développeur qui a du pouvoir l'utilisateur, il a le droit d'espérer. Il a peut être plus d'espoir que les limites soient comblées si "n'importe quel" développeur a l'accès aux sources, mais ça reste un espoir et les vieux bugs qui restent dans des logiciels libres le montrent bien.
C'est exactement la question que je me posais au sujet de ta réponse. Je pense que l'on ne s'est pas compris. Je vais essayer d'être un peu plus clair.
Je suis d'accord avec toi que git n'aide pas du tout dans ces cas là. On doit même pouvoir trouver des cas pathologiques où il amplifie le problème.
Mais je personnellement les cas où j'ai vu ce genre de modifications parallèles de même fichiers, soit était triviales et pijul, git ou svn ne poserait pas de gros problème, soit était signe de gros problèmes de design et demandais à redévelopper une partie d'une fonctionnalité. Et cela sans que ce soit la faute du gestionnaire de version. Même sans conflit, si tu as une refacto de l'existant et un ajout de fonctionnalités, pijul le pourra pas automatiquement appliquer la refacto sur le nouveau code (pour un exemple simple à décrire).
S'organiser ce n'est pas qu'une question de vcs, c'est une question de qualité. Tu as déjà plusieurs fois sorti la parabole du projet sous pression, de mon humble avis le vcs n'est pas leur seul soucis (et j'aurais tendance à dire que le vcs est plus un symptôme).
Quel va être l'apport de pijul rollback face à un git revert ?
Petite dans le sens qui ne fait qu'une seule chose. Ça ne dépend pas de ta deadline ou autre au contraire. Tu fais de une chose et tu l'intègre s'il y a un problème tu crée une nouvelle branche, je ne vois pas la complexité que ça apporte.
Pour ce qui est des problèmes de résolution de conflits (lors des rebase par exemple), effectivement git va moins t'aider que pijul, mais tu va avoir des problèmes tout de même. Pijul n'est pas magique, 10 dev qui touchent le même fichier en parallèle, c'est pas un problème de gestion de version.
Le solution de pijul retire les commits de l'historique ?
Si oui ça n'est pas une bonne bonne option pour tous les projets. Chaque projet définit ce qu'il veux avoir comme information dans son historique. La notion de "cette liste de changement a posé tel problème" peut en faire parti et donc être intéressante.
De plus ca modifierai l'historique d'une branche partagée, ce qui pose d'autres problèmes.
Enfin dans pijul, (ABC -> x1 -> X) - A peu poser des problèmes vu que x1 peu dépendre de A.
Avoir de petites branches et les supprimer une fois mergé ne me paraît pas être une contrainte chercher à nettoyer son historique de tout les problèmes rencontrés n'est pas forcément une bonne idée non plus.
[…] les patchs sont plus intuitifs que les commits […]
Il faut comprendre : Un formalisme patch based est plus intuitif que commit based. Et donc oui c'est comparable et non ce n'est pas une question de vocabulaire. Git stock des commits et pijul des patchs.
Affirmer "moi je fais les choses bien et je n'ai pas de problème avec git, donc si on fait les choses bien il n'y a pas de problème avec git" souffre d'un biais qui me paraît évident. Si la dépêche peut être abscons les commentaires ont beaucoup aidé à faire ressortir des cas et à expliquer de diverses façons par plusieurs personnes les impacts du changement de paradigme.
Mais, comme le dis l'auteur, si git te convient c'est parfait.
Oui oui c'est pas une spécifité de zsh, laid zsh est plus sympa. Pour enchaîner des substitutions tu n'es pas contraint de créer des variables intermédiaires.
C'est une règle, il faut savoir ce qu'elle signifie pour comprendre quand s'en servir ou quand elle est moins pertinente. Parser la sortie de ls ou file peut être une gageure par exemple (et assez fragile).
Je n'ai rien contre bash perso, j'ai juste une préférence pour zsh comme shell interactif et du coup j'ai tendance à l'utiliser pour mes scripts perso.
L’impression de respect peut être une part importante de l’« expérience utilisateur » quand ceux-ci ont l’impression qu’on veut leur faire prendre des vessies pour des lanternes.
L'énorme travail de transparence pour informer dans la langue de l'utilisateur et présenter les informations aussi simplement que possible, me paraît être l'antithèse d'un manque de respect pour l'utilisateur.
À mon avis quand on envisage la question du « compromis entre l’anonymat et l'observation du comportement des utilisateurs » on glisse très vite vers un compromis au détriment de l’utilisateur. Mozilla est à mon avis une bonne illustration de cet équilibrage difficile.
Le cas particulier de Mozilla est très très clair. Ils ne peuvent se baser sur des études qualitatives (ils ont essayé par le passé). Les gens préfèrent aller voir ailleurs plutôt que de répondre à des enquêtes.
De plus certaines choses, comme le cas du téléchargement analysé vient essentiellement du fait, il me semble, d'un besoin de sécurité minimal dont a besoin l'utilisateur.
Firefox envoie des informations de base concernant les téléchargements non reconnus au service Safe Browsing de Google, notamment le nom du fichier et l’URL à partir de laquelle il a été téléchargé.
Ils ont minimisé les données envoyées (ils téléchargent des listes de contrôle plutôt que de requêter le service), mais dans le cas du téléchargement de fichier exécutables ils font une requête. Je pense que ça pourrait être automatiquement désactivé si un antivirus est configuré.
Quel bel exemple d'honneteté intellectuelle… Allez, je vais t'aider à voir le problème : tu as tronqué la partie interessante : "les rapports de plantage comprennent un fichier […] pouvant contenir des données qui vous identifient ou que vous pouvez considérer comme sensibles ". Et je vois pas pourquoi on a besoin de recueillir des données m'identifiant pour faire de la qualité. J'ai peut-être tort, mais ça aurait été bien vu de leur part de l'expliquer, car manifestement je ne suis pas le seul, on est au moins 2.
C'est en opt-in
Quand c'est activé, Firefox te demande si tu veux l'envoyer
À l'endroit où tu l'a activé (complètement caché dans un endroit qui s'appelle « Vie privée et sécurité », tu as un lien qui s'appelle « En savoir plus »
Si tu va voir tu aura un complément d'information notamment : « Données sensibles : les rapports de plantage comprennent un fichier de « vidage » du contenu de la mémoire de Firefox au moment du plantage, pouvant contenir des données qui vous identifient ou que vous pouvez considérer comme sensibles. »
Donc les rapports de crash inclus un dump de la mémoire, c'est potentiellement sensible, mais c'est assez classique pour aider à reproduire un problème d'utiliser des dumps de mémoire. Ils ne l'activent pas par défaut et ne cachent pas le danger potentiel.
Le buziness modèle de Mozilla c'est de tracker leurs utilisateurs ? Ça doit vraiment être de foutu menteurs (voir le titre de cette page par exemple https://www.mozilla.org/fr/firefox/features/).
Quelle expérience ? Quel ratio tu vois entre le nombre d'utilisation de stats et le nombre de cas où ça a été problématique ?
Si la sécurité dis que c'est que ça doit être vrai, hein ? Tu sais que linuxfr ne faisant presque rien côté client son access log est un très bon moyen pour savoir tout ce qu'on y fait ? Si la sécurité dis qu'il ne faut pas faire l'impasse… En tant qu'utilisateur tu n'a rien qui permet de vérifier quoi que ce soit. Si tu veux invoquer la sécurité pour passer en mode parano très bien, mais ça concerne tout est ça ne t'avance à rien.
[^] # Re: RMS
Posté par barmic . En réponse au journal Kernel-5.1-gnu. Évalué à 3.
Tu mélange 2 choses différentes :
Ici je pense qu'il est reproché à la démarche politique et pas l'acte politique. L'altruiste peut avoir ou non une démarche politique: glanner est généralement accompagné d'une démarche politique alors qu'aider une personne âgée à traverser l'est rarement.
[^] # Re: RMS
Posté par barmic . En réponse au journal Kernel-5.1-gnu. Évalué à 3.
Pas vraiment non. La complexité des logiciels augmente beaucoup plus vite que l'électroménager. Tu as maintenant beaucoup de mal à réparer de l'électroménager trop sophistiqué ? He ben dans le logiciel c'est largement pire.
Un pouvoir que tu as sans pouvoir l'exercer ? Intéressant…
Je ne sais pas ce que tu entend par "ne puisse réellement impacter l'utilisation du logiciel", mais pythran vient de corriger un bug vieux de 5 ans, gimp a un ticket sur l'enregistrement de macro qui a plus de 10 ans. Mais je ne parle que des cas que je connais ça voir les bugs trackers tu sera surpris.
[^] # Re: RMS
Posté par barmic . En réponse au journal Kernel-5.1-gnu. Évalué à 2.
Au hasard, il y a aussi shellshock.
[^] # Re: RMS
Posté par barmic . En réponse au journal Kernel-5.1-gnu. Évalué à 2.
Purement théorique. Il donne le pouvoir à tous les développeurs éventuellement. Je sais que dans ta théorie l'utilisateur peut soit devenir développeur, soit payer les services d'un développeur, mais c'est justement en ça que c'est le développeur qui a du pouvoir l'utilisateur, il a le droit d'espérer. Il a peut être plus d'espoir que les limites soient comblées si "n'importe quel" développeur a l'accès aux sources, mais ça reste un espoir et les vieux bugs qui restent dans des logiciels libres le montrent bien.
[^] # Re: RMS
Posté par barmic . En réponse au journal Kernel-5.1-gnu. Évalué à 6.
Une action opportuniste par exemple ou une faite sans vision particulière (non-opniated par exemple). Oui ça existe, la plupart des projets n'ont pas ce genre de démarche. Et même rms dit que ça existe https://www.developpez.com/actu/231162/Richard-Stallman-l-open-source-est-un-substitut-amoral-et-depolitise-du-mouvement-du-logiciel-libre-qui-n-ose-pas-defendre-la-liberte/
[^] # Re: Soit j'ai rien compris soit...
Posté par barmic . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 3.
C'est exactement la question que je me posais au sujet de ta réponse. Je pense que l'on ne s'est pas compris. Je vais essayer d'être un peu plus clair.
Je suis d'accord avec toi que git n'aide pas du tout dans ces cas là. On doit même pouvoir trouver des cas pathologiques où il amplifie le problème.
Mais je personnellement les cas où j'ai vu ce genre de modifications parallèles de même fichiers, soit était triviales et pijul, git ou svn ne poserait pas de gros problème, soit était signe de gros problèmes de design et demandais à redévelopper une partie d'une fonctionnalité. Et cela sans que ce soit la faute du gestionnaire de version. Même sans conflit, si tu as une refacto de l'existant et un ajout de fonctionnalités, pijul le pourra pas automatiquement appliquer la refacto sur le nouveau code (pour un exemple simple à décrire).
S'organiser ce n'est pas qu'une question de vcs, c'est une question de qualité. Tu as déjà plusieurs fois sorti la parabole du projet sous pression, de mon humble avis le vcs n'est pas leur seul soucis (et j'aurais tendance à dire que le vcs est plus un symptôme).
[^] # Re: Soit j'ai rien compris soit...
Posté par barmic . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
Quel va être l'apport de pijul rollback face à un git revert ?
Petite dans le sens qui ne fait qu'une seule chose. Ça ne dépend pas de ta deadline ou autre au contraire. Tu fais de une chose et tu l'intègre s'il y a un problème tu crée une nouvelle branche, je ne vois pas la complexité que ça apporte.
Pour ce qui est des problèmes de résolution de conflits (lors des rebase par exemple), effectivement git va moins t'aider que pijul, mais tu va avoir des problèmes tout de même. Pijul n'est pas magique, 10 dev qui touchent le même fichier en parallèle, c'est pas un problème de gestion de version.
[^] # Re: Soit j'ai rien compris soit...
Posté par barmic . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 4.
Le solution de pijul retire les commits de l'historique ?
Si oui ça n'est pas une bonne bonne option pour tous les projets. Chaque projet définit ce qu'il veux avoir comme information dans son historique. La notion de "cette liste de changement a posé tel problème" peut en faire parti et donc être intéressante.
De plus ca modifierai l'historique d'une branche partagée, ce qui pose d'autres problèmes.
Enfin dans pijul, (ABC -> x1 -> X) - A peu poser des problèmes vu que x1 peu dépendre de A.
Avoir de petites branches et les supprimer une fois mergé ne me paraît pas être une contrainte chercher à nettoyer son historique de tout les problèmes rencontrés n'est pas forcément une bonne idée non plus.
[^] # Re: posix
Posté par barmic . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 1.
OSEF? Si le problème de portabilité se résume au shebang, on en parlerait pas :)
[^] # Re: Soit j'ai rien compris soit...
Posté par barmic . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 7.
Je crois que j'ai compris.
Il faut comprendre : Un formalisme patch based est plus intuitif que commit based. Et donc oui c'est comparable et non ce n'est pas une question de vocabulaire. Git stock des commits et pijul des patchs.
Affirmer "moi je fais les choses bien et je n'ai pas de problème avec git, donc si on fait les choses bien il n'y a pas de problème avec git" souffre d'un biais qui me paraît évident. Si la dépêche peut être abscons les commentaires ont beaucoup aidé à faire ressortir des cas et à expliquer de diverses façons par plusieurs personnes les impacts du changement de paradigme.
Mais, comme le dis l'auteur, si git te convient c'est parfait.
[^] # Re: POSIX
Posté par barmic . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 2.
Oui oui c'est pas une spécifité de zsh, laid zsh est plus sympa. Pour enchaîner des substitutions tu n'es pas contraint de créer des variables intermédiaires.
[^] # Re: POSIX
Posté par barmic . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 3.
C'est une règle, il faut savoir ce qu'elle signifie pour comprendre quand s'en servir ou quand elle est moins pertinente. Parser la sortie de ls ou file peut être une gageure par exemple (et assez fragile).
[^] # Re: Ksh
Posté par barmic . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 2.
Te-ai pas le même usage que debian donc j'utilise pas les même outils que debian.
[^] # Re: posix
Posté par barmic . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 2.
Depuis une dizaine d'années au moins ça fonctionne. Ça permet d'utiliser env ou awk -F
[^] # Re: posix
Posté par barmic . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 7.
Donc tu as une dépendance explicite à bash, autant utiliser ses fonctionnalités.
[^] # Re: POSIX
Posté par barmic . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 2.
Une partie peu aussi de faire avec d'autres, mais pêle-mêle :
Bien sûr ce ne sont pas des remplaçant parfait et identiques, mais dans bien des cas ils me conviennent voir sont plus confortables
[^] # Re: Ksh
Posté par barmic . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 5.
Je n'ai rien contre bash perso, j'ai juste une préférence pour zsh comme shell interactif et du coup j'ai tendance à l'utiliser pour mes scripts perso.
# POSIX
Posté par barmic . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 4.
Tu pense aussi à positionner la variable POXILY_CORRECT par exemple ?
Perso, je me fou de POSIX, faut juste que mes scripts soient cohérents. Si j'utilise une fonctionnalité de bash, je déclare bien bash, par exemple.
J'aime bien zsh et il me permet d'avoir assez peu de dépendances dans mes scripts, je trouve ça cool.
[^] # Re: Waouh
Posté par barmic . En réponse au journal Librem One : un bundle de services libres ?. Évalué à 2.
C'est quoi un avenir axé sur les données ?
[^] # Re: Ne pas être extrémiste, viser son but
Posté par barmic . En réponse au journal Sur le compromis entre l'anonymat et l'observation du comportement des utilisateurs. Évalué à 5.
L'énorme travail de transparence pour informer dans la langue de l'utilisateur et présenter les informations aussi simplement que possible, me paraît être l'antithèse d'un manque de respect pour l'utilisateur.
Le cas particulier de Mozilla est très très clair. Ils ne peuvent se baser sur des études qualitatives (ils ont essayé par le passé). Les gens préfèrent aller voir ailleurs plutôt que de répondre à des enquêtes.
De plus certaines choses, comme le cas du téléchargement analysé vient essentiellement du fait, il me semble, d'un besoin de sécurité minimal dont a besoin l'utilisateur.
[^] # Re: Ne pas être extrémiste, viser son but
Posté par barmic . En réponse au journal Sur le compromis entre l'anonymat et l'observation du comportement des utilisateurs. Évalué à 4.
Au final, tu liste pleins de choses (tellement bien choisis que ça inclu de l'opt-in…), mais en quoi ça en est leur business ?
Le seul point à peu prêt pertinent là dedans c'est :
et ça a déjà était discuté en long en large et en travers…
[^] # Re: Ne pas être extrémiste, viser son but
Posté par barmic . En réponse au journal Sur le compromis entre l'anonymat et l'observation du comportement des utilisateurs. Évalué à 4.
Si tu regarde les détails tu tombera là dessus Quelles informations sont envoyées à Mozilla ou ses partenaires quand les protections contre l'hameçonnage et les logiciels malveillants sont activées ?.
Ils ont minimisé les données envoyées (ils téléchargent des listes de contrôle plutôt que de requêter le service), mais dans le cas du téléchargement de fichier exécutables ils font une requête. Je pense que ça pourrait être automatiquement désactivé si un antivirus est configuré.
[^] # Re: Ne pas être extrémiste, viser son but
Posté par barmic . En réponse au journal Sur le compromis entre l'anonymat et l'observation du comportement des utilisateurs. Évalué à 7.
Donc les rapports de crash inclus un dump de la mémoire, c'est potentiellement sensible, mais c'est assez classique pour aider à reproduire un problème d'utiliser des dumps de mémoire. Ils ne l'activent pas par défaut et ne cachent pas le danger potentiel.
[^] # Re: Ne pas être extrémiste, viser son but
Posté par barmic . En réponse au journal Sur le compromis entre l'anonymat et l'observation du comportement des utilisateurs. Évalué à 1.
Le buziness modèle de Mozilla c'est de tracker leurs utilisateurs ? Ça doit vraiment être de foutu menteurs (voir le titre de cette page par exemple https://www.mozilla.org/fr/firefox/features/).
[^] # Re: Ne pas être extrémiste, viser son but
Posté par barmic . En réponse au journal Sur le compromis entre l'anonymat et l'observation du comportement des utilisateurs. Évalué à 0.