jben a écrit 839 commentaires

Pour avoir:

• agit sur le fait que le site ne pouvait se permettre de diffuser cette idéologie,
• affirmé que la liberté d'expression n'oblige pas le site à accepter de publier n'importe quoi,
• confirmé que les règles du site s'appliquaient,
• initié un travail sur un code de conduite,

Merci.

Non. Du moins il existe au moins une personne qui pense que ça a un sens de restreindre la longueur des lignes, et qui nomme la chocolatine par son nom. Moi.

Le PDF est un format extrêmement complexe, j'avais même une difficulté monstre à couper une double page en deux.

C'est un problème que j'ai eu récemment, comment splitter une page en deux.

J'ai écrit un truc à l'arrache pour ça.

Le ThinkPad d'occasion est une valeur sure… Pour l'instant, excepté ma machine pro (c'est pas moi qui paie, et il y a des règles budgétaires qui me dépassent), tous mes ThinkPads sont des machines d'occasions, j'en suis très content (mais je me suis limité à la série X, je ne me prononce pas sur les autres séries en occasion).

La série est essentielle si j'ai bien compris.

Utilisateurs depuis quelques années de Thinkpad série X, j'en suis très content. J'utilise encore mon X200 (date de sortie 2008) de temps en temps. Ma machine perso principale est un X220 (date de sortie 2011) (ah… ce clavier…), je l'utilise tous les jours, et j'écris avec actuellement. Ma machine pro est un X13.

Pour ma part, satisfaction à 100% sur toute la ligne. Robustesse, comptabilité, ergonomie (le trackpoint est un plaisir et vraiment utilisable, contrairement à la concurrence)…

Par contre, j'ai vu certaines machines d'autres séries que des gens autour de moi ont achetés en se disant ThinkPad c'est bien… c'est assez décevant. Bref, les séries historiques ont toujours une très bonne qualité, les autres, bof.

En gros:

• Série X: ultraportable
• Série W (maintenant P): série spécifique
• Série T: pas vraiment portable, mais puissants

Les autres séries: à éviter sauf exception.

Je parle spécifiquement de RMS, pas de la FSF.

Je ne sais pas où tu as vu qu'ils ont quelque chose contre le logiciel libre qui n'est pas sous copyleft.

Dans de multiples interventions de RMS sur différents canaux. Je fais même une citation. As-tu lu la citation ?

A noter que la FSF et RMS n'ont jamais été pour le libre, mais uniquement le logiciel libre,

C'est même pire que ça. Uniquement pour le logiciel libre sous copyleft.

Et même récement:

Please keep recommending GCC as the compiler to choose. source

LLVM is a big step backwards from GCC because it is not copylefted.
That has been a major setback for our freedom. source

Et c'est dans une discussion où il y a des arguments techniques.

C'est peut-être parce que je n'aime pas le copyleft, mais je trouve que refuser de recommander un logiciel car il est libre sans copyleft est symptomatique du personnage: nuisible.

Je pense qu'il a repris mon postulat. Il n'y a pas eu de vrai sélection pour Artic Code Vault si j'ai bien compris, c'est tous les projets publics actifs qui ont été sauvegardés.

Ma vision, c'est que pour les comptes assez anciens, ne pas avoir le flag est très mauvais signe. Par contre avoir le flag n'est pas suffisant de mon point de vue.

J'indiquais donc une implication :

• Formulation initiale: contributeur ⇒ flag
• Contraposée: non flag ⇒ non contributeur

Je ne dis rien sur la réciproque (qui est fausse de mon point de vue, et aussi du tien Arcaik).

Attention, ceci est vrai uniquement pour les activités de commit sur github. On peut contribuer par d'autre moyen sur github (reviews par exemple), ou en dehors de github (dépot autres), ou contribuer autrement (orga conf…).

pour pinailler sur la list des 11-20, je remarque que aCLr a aussi contribué à sqlalchemy qui me semble être un gros projet.
Il y au aussi abtinmo qui semble avoir travaillé sur de gros projets (en regardant ce que dit Github quand je passe la sourit par dessus "Arctic Code Vault Contributor").

J'avoue avoir été un peu rapide. Je devrais reprendre la liste des vingt que j'ai fait au début, j'ai sûrement laissé passer des choses. Toutefois, quand on essaie de faire la même chose avec les signataires de celle demandant le retrait de RMS, alors la différence est assez violente, on a pas besoin de chercher.

pose aussi la question légitimité qu'ont les fondations à signée la lettre anti-RMS (OSI, CC, Xorg) sans avoir demandées à leur membres un avis sur la question.

Ces organisations ont leurs processus décisionnels qui leur sont propres. Si ceux-ci sont respecté, l'avis des membres n'est pas requis. Par exemple pour Debian, il y a une GR en cours.

Après, certain pourront faire la remarque que le board de la FSF a respecté le processus décisionnel (ce qui semble être le cas), mais pour autant ce n'est pas le processus décisionnel qui est remis en cause, c'est la décision, donc nous ne parlons pas de la même chose.

Il me semble pas avoir dit ça ?

Non, mais c'est un argument que l'on voit. Et j'explique ce qui a motivé ma réponse. Quand je reproche quelque chose à quelqu'un, je le dis explicitement.

Aussi, pour pinailler, dans ta liste, je considère que https://github.com/Abdykarov n'est pas dépot assez fourni. on dirait un profil d'étudiant en train de se sur-vendre. Pas de contribution en dehors de petits projets, pas de contribution externe…

C'est peut être une vision biaisée, mais un profil sans le "Arctic Code Vault Contributor", à moins que ça soit un profil récent, je considère que c'est un profil qui ne contribue pas.

Il y a un effet de biais sur les premiers, c'est assez étonnant. Si je prends les dix suivants, j'ai :

• Achmad Fathoni (Robot Operating System for Arch): je ne sais pas si c'est un robot ou si il a développé un robot. Dans tous les cas, la création du robot est une contribution.
• aCLr: aucune contribution à des projets, sauf de manière récente, il y a une première contribution en cours sur helm.

Les autres sont des inconnus complets pour moi. J'ai peut-être des critères un peu stricts, mais j'invite à faire la même chose sur l'autre lettre ouverte. J'avoue que ce qui me fait réagir c'est de considérer que le nombre à une importance, ou que ceux qui veulent voir RMS dehors sont des anti-libres.

Je suis pas certain que le nombre soit le plus important. En effet, il y a quelques noms importants, mais la masse de ceux qui ont signé cette contre pétition est principalement constitué d'inconnus complet.

J'ai pris quelques noms au hasard (ils sont gentils d'avoir laissé les profils github c'est sympa pour les recherches). J'ai pris une vingtaine au hasard, et aucun, je dis bien aucun dans mon échantillon ne semble être un vrai contributeur au libre, du moins au gros projets libres. Je trouve quelques projets publics persos (la majorité du temps sans intérêt), beaucoup de contributions sur des projets privés (donc je ne sais même pas ce que c'est), et rien sur des vrai projets (comprendre un truc avec au moins 2-3 personnes impliquées, je ne demande même pas un gros projets). J'ai doublé à chaque fois d'une recherche du nom et du pseudo dans un moteur de recherche, car tout n'est pas sur github, et heuresement, et je n'ai rien trouvé d'intéressant (mais il y a un problème de langue, je ne comprends que l'anglais et le français, mais à mon avis c'est un mauvais signe pour la contribution, qu'elle qu'en soit la forme, à un gros projet d'envergure).

Alors oui, il y a quelques noms qui claquent, mais l'essentiel est à mon avis constitué de personnes lambda qui ne font que aimer le libre sur le papier sans jamais y contribuer.

Le gars qui a des profils insta, facebook, whatever avec des contenus pas très pro (beuverie, contenus NFSW etc.) va se décrédibilisé beaucoup plus vite.

Sur ce point, je suis assez optimiste. La majorité des étudiants que je côtoie ont compris ces enjeux et ne font pas n'importe quoi avec leur profil public sur les réseaux sociaux.

Je ne vise pas les projets perso, au contraire, c'est très bien d'avoir des projets de dev perso, (et généralement plus ils sont funs, mieux c'est). Également, je ne vise pas les contributions mineures sur des gros projets, c'est très bien les contributions mineures.

Je vise les projets étudiants qui n'ont pas vocation à être autre chose que des projets étudiants qui devraient rester privés (attention, si c'est un vrai truc initié dans le cadre d'un projet étudiant, c'est très bien que cela soit public).

Là où j'enseigne, les étudiants ont certains semestres, pas mal de projets (mais moins que dans certaines autres) dans le cadre des enseignements, qui sont à vocation à uniquement former les étudiants, pas à être visibles. Sur quelques semestres, cela commence à faire pas mal en volume et à noyer ce qui est pertinent.

Je suppose que tu as lu mon post scriptum.

Sérieusement, personnellement c'est le mot diffamation sorti à tort est à travers qui m'indispose. J'ai l'impression que c'est ce que l'on sort dès qu'on est à court d'arguments.

Alors oui, je suis contre la diffamation illégale (en même temps, je ne vais pas m'exprimer pour un truc illégal), et c'est important de faire la distinction et de préciser que nous avons le droit de remettre en cause l'honneur de rms ?

L'objectif en soi des auteurs de la lettre ouverte n'est pas de remettre en cause l'honneur de rms, mais de ne pas vouloir que cette personne ait une position de représentation au sein de la FSF dans un soucis d'ouverture aux débats sociétaux. C'est de la diffamation, mais de la diffamation légale.

Une fois, ceci dit, je vais probablement retourner dans mon silence. Et attendre que rms disparaisse de la représentation (j'espère ne pas attendre quelques années), sans approuver complètement les méthodes publiques utilisées contre lui, mais approuvant l'objectif.

Oula… C'est extrêmement gênant comme position.

La diffamation est définie en France par:

Toute allégation ou imputation d'un fait qui porte atteinte à l'honneur ou à la considération de la personne ou du corps auquel le fait est imputé est une diffamation.

La diffamation est illégale sauf dans deux cas (les excuses de vérité et de bonne foi), mais ça reste, dans tous les cas de la diffamation.

Donc, quand tu dis

Moi en tant que modérateur je demande à ce qu'on ne diffame pas RMS

Tu demande qu'on ne porte pas atteinte à l'honneur ou à la considération de rms. Donc, tu demandes en tant que modérateur que rien ne soit dit contre lui, que cela soit vrai (excuse de vérité) ou que cela soit de bonne foi (précautions nécessaires, et poursuite d'un intérêt supérieur). Il est donc inutile de débattre dans ce cas, ta position en tant que modérateur est que ce quel que soit l'état de vérité, les précautions prises ou le but poursuivi, les contributeurs du site n'ont pas le droit de remettre en cause rms.

Nous ne sommes pas loin d'une dérive sectaire. C'est grave.

P.S.: Il y a un homme de paille dans ce commentaire, en interprétant les propos au sens littéral. Mais comme la mode de certains soutiens de rms consiste à interpréter au sens littéral, sans vouloir comprendre le message qu'il veut faire passer, cela me semblait pertinent d'interpréter au sens littéral.

Il y a -w qui permet de mettre un délai entre chaque mail. Cet outil est imaginé pour une utilisation légitime, donc avec un smtp sympathique. J'utilise pour ma part le smtp de l'université (puisque j'utilise mon adresse pro pour envoyer les mails et qu'en plus les mails sont à destination des étudiants qui sont sur le même serveur), et c'est un usage légitime. Toutefois, je dois mettre un -w 8 quand j'envoie plus de ~80 mails.

Il a été abordé deux points, dans le sujet du journal et dans les commentaires :

• contribuer aux projets libres est formateur et participe à votre réputation, (du moins, complète de manière très intéressante un CV synthéthique),
• faire ses propres projets de réimplémentation permet de comprendre les choses.

Ces deux points ne sont pas exclusifs et ça a été souligné. Mais il y a un point que j'aimerai mettre en avant il faut que les postulants fassent attention à leur réputation publique. Je pense en particulier à tous les codes de projet étudiants (qui sont des réimplémentations de la roue carré, faits dans un but pédagogique, pas dans un but de réécriture/refactoring/whatever), qui ne doivent pas être public. Cela donne une mauvaise image et cela brouille les vrais contributions.

Je suis enseignant-chercheur dans une école d'ingénieur, et même si mon domaine n'est pas de l'info au sens dev, et que ce n'est pas à moi de faire passer ce genre de message en interne, je suis toujours étonné des profils publics des étudiants. Un exemple flagrant, c'est un étudiant ayant un super bon profil technique (en plus d'un bon profil scientifique) qui était présent sur github. Quand on regarde sa page github, on trouve nombre de projets perso ou contributions sur des projets qui ne sont que des projets étudiants dans le cadre des enseignements, et souvent de pietre intérêt générale et de pauvres qualités techniques. Alors que dans le même temps, cet étudiant avait contribué de manière significative à scikit-learn et à sympy (pour ceux qui ne connaissent pas, deux grosses bibliothèques en python scientifique), et ces contributions étaient invisibles et noyées dans la masse des contributions inutiles et bidons sur des projets étudiants.

J'approuve donc le contenu du journal, contribuez sur des gros projets, mais faîtes attention aussi à votre réputation et que ces contributions ne soient pas noyés dans la masse de contributions qui n'en sont pas quand on fait une recherche sur votre nom.

J'avais essayé à l'époque, je me rend compte que miller est beaucoup plus avancé qu'il l'était. Il pourrait correspondre à une grande partie de mes usages. Les deux points principaux qui manquent, c'est pour moi le fait de pouvoir faire des applications de fonction extrèmement complexes (la puissance de python), et les agrégations complexes.

Il est vrai que maintenant, je ne recommencerai pas csvspoon, et que j'utiliserai miller plus quelques scripts.

Mixer les deux outils me parait improbable, ne serait-ce que csvspoon est en python (et utilise intensivement les générateurs pour faire du traitement par flux), qui est fait dans miller directement en C. La base de code me semble complètement imcompatible. Par contre des bonnes idées peuvent passer d'un coté vers l'autre.

En fait, c'est comme cela que je travaillais avant, j'avais une base de donnée pour chaque enseignement qui me suivait pendant tout le semestre. Et c'est rapidement beaucoup contraignant et pas assez flexible. Je devais absolument tout typer avant d'importer, effacer les tables suivant les versions, écrire des scripts python pour faire des calculs complexes… Bref, les jointures se passaient bien, et c'est tout (même pas les agregations, car en fait les opérateur d'agrégation sont très limités en SQL).

Concernant le volume de donnée, la majorité des usages n'est pas du requetage, mais du traitement de l'ensemble des fichiers. Avec csvspoon, les traitements sont faits de manière pas trop stupide (par exemple pour une jointure de deux fichiers de taille n on a un complexité en O(n·log(n)), ce qui est acceptable. Si on veut récupérer une seule donnée, c'est vrai que écrire un query plan serait plus adapté avec des index dans une base de données, mais ce n'est pas mon cas d'usage.

Après, mon cas d'usage, c'est rarement des fichiers à plus de 1000 lignes, mais j'ai déjà traité des données historique d'inscription aux enseignements sur la totalité de l'université, et j'étais à plus de 50 million de lignes, et c'est passé sans problèmes.

À noter, j'ai oublié de le préciser. Autant que possible les données sont traités en flux, c'est à dire qu'elles sont lue au fur et à mesure sur l'input et écrite au fur et à mesure sur l'output. Permettant de traiter des gros volumes de données dans un pipeline de commandes de manière efficace. (Merci au générateurs en python pour cela).

De la chance, de la chance… c'est à définir. Si j'avais trouvé un outil qui me faisait de manière simple les jointures et les agrégations, il est probable que je n'ai jamais écrit une ligne de code. Après, une fois que j'ai commencé, il est vrai que j'ai continué assez fortement.

Concernant la RFC 4180, le parsing du csv est assuré par le module standard csv de python, et donc oui, cette RFC est respectée. Toutefois, actuellement, le seul truc modifiable c'est le délimiter (-d pour l'input, -u pour l'output). Il pourrait être envisageable de mettre d'autres options pour pouvoir changer le comportement du dialect plus précisément, mais j'en ai pas eu besoin.

Un des trucs que je compte faire, c'est de mettre un argument pour l'encoding d'input et d'output. Actuellement c'est celui de la locale utilisé (et c'est très bien par défaut), mais ça serait bien de pouvoir le spécifier (surtout en input). Les SI de l'université nous retournent des fichiers avec un encodage du passé (et j'en ai marre de passer iconv dessus, mais si il n'y avait que ça comme problème au niveau du SI, je serais heureux).

Tout à fait, mais tu ne réponds pas à la question initiale.

Le problème, c'est que pour George_abitbol la compression est très efficace pour tar, et ne l'est pas pour rsync, c'est incohérent. C'est le même source, la même machine de départ, la même machine de destination entre les différents essais, et à moins que la charge CPU change violement, les rapports de performance devraient être les mêmes. Et si la charge externe CPU change violement entre les tests, alors le test est mal conduit. C'est cette incohérence là qui me dérange.

Je suis étonné de ton résultat. J'ai donc voulu tester.

jben@germaine /tmp $ time tar c linux-5.12-rc4 | ssh remote 'tar x' 
0.30user 1.18system 1:31.22elapsed 1%CPU (0avgtext+0avgdata 3696maxresident)k
880inputs+0outputs (7major+264minor)pagefaults 0swaps

jben@germaine /tmp $ time tar cz linux-5.12-rc4 | ssh remote 'tar xz'
22.69user 1.07system 0:22.73elapsed 104%CPU (0avgtext+0avgdata 3532maxresident)k
0inputs+0outputs (0major+550minor)pagefaults 0swaps

jben@germaine /tmp $ time rsync -a linux-5.12-rc4 remote:
1.96user 1.50system 1:26.94elapsed 3%CPU (0avgtext+0avgdata 34996maxresident)k
1043928inputs+0outputs (1major+10494minor)pagefaults 0swaps

jben@germaine /tmp $ time rsync -az linux-5.12-rc4 remote:
18.92user 0.55system 0:20.28elapsed 96%CPU (0avgtext+0avgdata 38012maxresident)k
5128inputs+0outputs (1major+9494minor)pagefaults 0swaps

Bref, moi je trouve (en triant par vitesse) rsync -z > ssh+tar+gz >> rsync > ssh+tar.

Le fait que rsync et ssh+tar soient dans un mouchoir de poche est normal (de même avec les versions compressées), et le fait que je trouve l'un avant l'autre ne me gène pas. Ce qui me gène c'est que tu trouve que la compression ne change rien pour rsync (ce qui peut être le cas si c'est le CPU qui est limitant), mais change beaucoup pour tar (donc le cpu n'est pas limitant).

A-t'on besoin de l'indexation immédiate de nouveaux contenus ? Est-ce que perdre d'indexation immédiate de nouveaux contenu est acceptable ?

Si la réponse à la première question est non ou si la réponse à la seconde question est oui, alors il serait légitime que le no follow et no index soit positionné si la note est inférieure ou égale à k (avec k=5 ou k=10).

Pour les journaux normaux, ce k serait très vite atteint (il suffit d'aller un peu se balader dans l'historique pour voir), pour les journaux problématiques comme celui-là, ils ne seraient jamais indexés.

Une version plus avancée serait de positionner le no follow et no index si (au moins) une des conditions est remplie:
- le journal a moins de 24h et il a une note inférieure ou égale à 5
- le journal a une note négative.

Avec cette version avancée, même si la note grimpe peu (mais ne passe pas dans le négatif), il sera indexé dans les 24h.