Benoît Sibaud a écrit 9301 commentaires

Tu viens d'illustrer la définition du conservatisme en fait : une fois un truc établi (la définition des 4 libertés), rien ne doit changer, et ceux qui voudraient pousser un changement (copyleft, tivoïsation, passage à 3 libertés ou moins, peu importe) sont des gens qui sont supposés fragmenter la communauté.
Avec du pur conservatisme, on aurait eu les 4 libertés dans le logiciel et rien dans d'autres domaines car le dogme dit "4 libertés dans le logiciel".

Bref comme dans n'importe quel débat d'idée, y a des conservateurs, des progressistes (ans jugement de valeur sur faut-il être conservateur ou progressiste…), des gens qui tirent dans un sens, des gens qui tirent mais dans un autre sens, des accords sur les idées, des accords tactiques pour gagner même si on n'est pas d'accord sur tout, des négociations, des compromis, etc. Ce n'est pas gênant que des gens disent qu'il n'existe pas qu'une seule couleur verte, c'est même plutôt sain, ça l'est quand quelqu'un dit que le rouge c'est le vert.

Il y a une section entière nommée Philosophie dans les pages FSF/GNU.

https://www.gnu.org/philosophy/philosophy.html
https://www.fsf.org/philosophy

Le logiciel libre n'a pas de couleur politique, au sein "des partis politiques", mais le terme a été conçu initialement pour porter des valeurs politiques (toujours pas au sens des partis) et une philosophie. Et plus tard le terme "Open Source" a été publicisé pour ne s'intéresser qu'aux aspects techniques/pratiques/pragmatiques permis par des logiciels offrants un certain nombre de libertés aux utilisateurs et développeurs.

D'autant que le terme va être utilisé pour parler principalement de la licence d'un logiciel (approche strictement juridique), du logiciel lui-même, des possibilités offertes aux développeurs ou bien aux utilisateurs, des intentions des auteurs dudit logiciel, etc. Sans parler des sujets annexes comme sa gouvernance, son modèle de développement ouvert ou fermé, etc.

Après tu as le droit de t'amuser en t'amusant, mais bon c'est juste la vie d'avoir des gens qui ont ou non des opinions et qui les expriment, notamment via des partis politiques. Cela ne signifie pas qu'ils sont représentatifs de tous les autres, juste qu'ils se sont engagés en exprimant leurs positions, un peu comme toi qui alignent régulièrement les tiennes par une avalanche de commentaires ici par exemple.

Dans l'absolu et en théorie "licence libre ou Open Source" d'une part, et tivoïsation d'autre part, sont orthogonaux. On peut avoir l'un, les deux ou aucun des deux. Pareil pour "licence libre ou Open Source" et "brevet logiciel", ou "licence libre ou Open Source" par exemple. En pratique, tout n'est pas noir/blanc, mais on trouve probablement plus d'opposants à la tivoïsation et aux brevets logiciels du côté des personnes voulant que les utilisateurs soient libres, et plutôt moins chez ceux qui s'intéressent principalement ou uniquement aux aspects techniques (si je mettais sur un axe un côté "philosophie / logiciels libres" et un côté "pragmatisme / Open Source"). On peut probablement trouver toutes les combinaisons, mais pas dans les mêmes proportions.

Et une des raisons de ces variations vient précisément des objectifs/attendus de ceux qui utilisent "logiciel libre" et de ceux qui utilisent "Open Source", qui ne sont pas les mêmes (en tout cas de ceux qui ont conscience des nuances qui ont conduit à créer ces deux termes), quand bien même ils parlent des mêmes licences et des mêmes logiciels. C'est comme dire "charges sociales" ou "cotisations", ça désigne la même chose en pratique, pourtant l'intention est différente (pour ceux qui y placent une intention conscience).

ça fait beaucoup de jugement de valeur tout ça… (ou trop manichéen).

Il me semble plus simple d'accepter que certains veulent

• du libre
• du libre et pas de tivoïsation
• du libre et un modèle de développement ouvert
• du libre, pas de tivoïsation et un modèle de développement ouvert
• etc.

comme il y a des personnes qui veulent plutôt du copyleft ou du non-copyleft, du Python ou du Java, des brevets sur le logiciel ou non, etc.

Le socle commun reste "le logiciel est libre car sa licence respecte les quatre libertés", ensuite l'utilisateur (ou même le développeur) est plus ou moins libre suivant si tivoïsation ou non, brevet ou non, modèle de développement ouvert ou fermé, code écrit en malgache ou en anglais, documentation présente ou non, modèle opencore/fauxpensource ou non, etc.

Erreur de Content-Type:

< content-disposition: inline; filename="HAIKU logo - black.svg"
< content-type: text/plain; charset=UTF-8

Ouais enfin un paquet Debian, ça fait revenir l'être aimé, tu as le poil luisant et avec de la poudre verte, il devient reproductible (le paquet, pas l'être aimé ou le poil).

Passer sous le radar, pendant quelques temps, avant de pouvoir placer ses liens. La vieille stratégie qui se transmet de bouche de spammeur à oreille de spammeur : "tu sais il faut attendre le 3è commentaire avant de spammer, mon pote qui hérite des millions d'un riche oncle africain l'avait expliqué à un ami qui fait revenir l'être aimé et qui agrandit ton gros SEO".

Pour le coup ce n'est pas moi qui l'ait détecté. Une personne de la modération a dit "nouveau compte, à surveiller ?", sur une intuition ou sur le pseudo ou sur l'adresse de courriel ou… je ne sais pas.

Du coup j'ai regardé, je n'ai pas vu de lien publicitaire, j'avais un doute aussi vu le pseudo et l'adresse de courriel et l'IP et la poudre verte que l'on répand sur tout nouveau compte pour détecter les faux, alors j'ai pris une phrase plus ou moins au pif et j'ai lancé une recherche sur internet. Deux résultats: LinuxFr et HardwareFr.

A priori, au bout d'un moment, on reconnaît des motifs dans les adresses IP/de courriel et les pseudos d'une part. Ensuite on va trouver louche ou pas un pavé sur un sujet par un nouveau ("louche" dans le sens, "hmm je vais regarder à 2 fois" si y a pas entourloupe). Mais bon c'est plus facile quand le texte est en turc, en vietnamien ou en anglais, avec des liens explicites.

A posteriori, on recherche les URL/noms que l'on a déjà virés, dans le cas où l'on en aurait oublié, ou que le pénible serait revenu.

Bonjour,

pour info il s'agit d'un compte de spammeur. Le contenu provient (au moins) d'un forum Hardware.fr de janvier 2018.

ça fait désordre sur la page d'accueil : « * Offre valable jusqu'au 28 Février 2017 »

La dépêche a été modifiée avec les dernières informations disponibles sur la campagne.

Je suis d'accord que ça doit être corrigé, que l'entrée devait être réouverte et avec ta première solution

How I connect with non-English speakers about open source avec
victorhck in the free world (mars 2020)

bricodeur et bricodeuse : Personne qui utilise et programme des machines en amateur.

Attention, this flim
is not a flim about cycling.

(tiré des sous-titres en anglais)

Cf https://linuxfr.org/news/entretien-de-linuxfr-org-avec-opensource-com

Dîtes non à la lumbricinophobie ! #jesuisver

Vélo couché

Corrigé, merci.

Corrigé, merci.

Tout à fait, j'aime beaucoup cet extrait, le côté « dès que je regarde quelque part, je trouve un truc qui ne marche pas » (comme je voudrais). Je dirais que c'est un mélange de « plus tu fais de choses, plus tu rencontres de problèmes », d'un regard plus intéressé par ce qui ne marche pas que par ce qui marche (j'ai travaillé dans les tests et de manière générale mon boulot a souvent été d'assurer que ça marche comme prévu), d'acceptation (j'aurais aussi pu me dire « je m'en fous » ou « je créé une entrée dans le suivi et on verra plus tard »), voire une forme de perfectionnisme (« je ne veux aucune erreur, tout doit marcher comme prévu »). Mais ça rentre aussi dans une des définitions de la procrastination qui est de se lancer dans une véritable frénésie d’activités pour éviter de faire une tâche que l'on veut éviter de faire (source https://fr.wikipedia.org/wiki/Procrastination ).

En français c'est facile : le g se prononce comme dans coing. Le e comme dans laitue. Le d comme dans friand. Le t comme dans dessert. Y manque plus grand chose.

Ma première idée aurait plutôt était de corriger le code.

On est normalement dans une situation qui n'est pas censée arriver. Plutôt qui n'est plus censée arriver. Les soucis proviennent des données avant le passage en Ruby on Rails, ça relève de la dette technique. Je vais néanmoins regarder ce que je sais faire niveau code sur ce point.

Je suis surpris de l'utilité de ce script pour une base de données SQL. L'un des grands intérêts d'SQL c'est qu'il donne tous les outils pour avoir des données cohérentes et sa force c'est que les données restent cohérentes, elles ne le sont pas qu'au moment où ton cron vient de passer.

Vaste question. J'y vois de très nombreuses réponses :

• cela suppose que les développeurs sont parfaits : ils ne font pas d'erreurs de conception, pas d'erreurs de développement, pas d'oublis, ils ont une maîtrise parfaite du SQL, ils gèrent tous les cas du passé, et ils pensent à faire toutes les adaptations nécessaires sur les contraintes à gérer ;
• cela suppose que les outils sont parfaits : les bibliothèques de développement n'ont pas de bugs ou de lacunes, la base de données non plus (pour mémoire MySQL n'avait pas de clés étrangères à un moment, et MySQL gérait mal l'UTF-8 sur 4 octets à un moment, pour ne citer que deux exemples) ;
• la confiance n'exclut pas le contrôle : ceinture et bretelles, ça ne coûte pas grand-chose d'avoir un script en plus, qui vérifie de façon différente certains points, en l'occurrence précisément les points que l'on ne garantit pas par la base de données elle-même. Et la duplication de vérification peut aussi être faite par des personnes différentes (par exemple le dév mettra des contraintes dans le code, le DBA dans la base SQL et l'adminsys dans un script shell externe) ;
• certaines vérifications doivent être faites a posteriori : le script vérifie aussi l'absence de spammeurs non filtrés, basé sur les comportements de spammeurs déjà détectés, et en remontant dans le temps, au cas où l'on en aurait laissé passer, pour les virer avec retard ;
• certaines vérifications sont pénibles à écrire en SQL : par exemple nodes.content_type contient News, Diary, etc., nodes.content_id contient l'identifiant qui correspond à ce que l'on trouvera respectivement dans news.id, diaries.id, etc. Même chose pour les slugs avec du sluggable_type et du sluggable_id. Écrire des contraintes dessus repose à ma connaissance sur des triggers et il faut vraiment être sûr de comment ça s'intégrer avec Ruby On Rails par exemple (qui fait toujours des tas de choses implicitement). Pareil on a un materialized_path composé d'une concaténation de chaînes de 12 octets chacune contenant un id de commentaire : vérifier que la taille est un multiple de 12 et que chaque sous-chaîne de 12 caractères correspond à un entier utilisé comme id dans la table comments mais aussi un id qui est sur le bon contenu, ça peut être compliqué à écrire (et on peut aussi se dire qu'il n'y a aucune raison que ça soit corrompu un jour, même si l'expérience montre que si) ;
• les scripts garantissent aussi une cohérence la base SQL et Redis, ce que ne permettent pas les contraintes SQL (par exemple on va trouver dans Redis la tribune associée à une dépêche refusée, donc si on supprime cette dépêche, il faut nettoyer côté Redis aussi) ;
• il y a des plantages qui peuvent interrompre des opérations en cours. On peut espérer que tout soit transactionnel, mais, un, ce n'est pas le cas, deux, les transactions ne seront pas multi-base de données ;
• il y a des opérations manuelles en base parfois (notamment pour virer des comptes ou gérer des spammeurs), et tant que cela n'est pas codé proprement, on peut avoir une bête typo en base de données (le souci sur les arborescences de commentaires est juste un zéro manquant dans une chaîne de caractère, soit cinq zéros d'affilée au lieu de six, une erreur facile à faire pour un humain sur un copier-coller par exemple) ;
• on a des données dénormalisées, ce qui augmente les risques de désynchronisation (comme les nodes.comment_count vs le nombre de commentaires ou le cached_slug qui est une copie locale) ;
• il y a le poids de l'historique ou dette technique : on a des données très anciennes, on a pu avoir des soucis de conversion dans le passé, les contraintes ont changé au fil du temps, le code est surtout utilisé sur les nouvelles données donc on peut avoir des surprises sur les anciennes (par exemple le code d'édition des anciennes dépêches qui n'existent qu'en HTML est actuellement cassé car il cherche désespérément la dernière version en Markdown), etc. ;
• de fait, le script trouve des choses, régulièrement. Il détecte le bug sur les tags avec espace (le code RoR lui est "persuadé" d'avoir géré correctement), il détecte les oublis lors d'opérations manuelles comme une purge complète de compte suite à une demande d'un utilisateur, etc. ;
• il assure une non-régression : on a déjà eu des soucis dans le passé sur certains cas, on met en place un test pour savoir si cela se reproduit (en espérant que cela n'arrive plus car on a fait des corrections ailleurs pour l'éviter) ;
• je suis largement plus à l'aise pour faire des vérifications externes que pour modifier du code Ruby On Rails ;
• dans mon expérience pro et dans mon expérience associative, on m'a très souvent dit que c'était inutile de vérifier les données ainsi, et pourtant j'ai détecté ainsi de nombreux problèmes distincts, à pas cher, sur des projets différents, avec des bases SQL ou NoSQL variées. Pour faire un parallèle hasardeux, dans certains domaines sensibles (aéronautique, nucléaire), on s'assure d'avoir deux ou plus implémentations différentes d'un même comportement pour être sûr qu'au moins une va marcher et détecter les incohérences, ici c'est un peu ça de façon limitée, ciblée et pas coûteuse.

Corrigé, merci.