arnaudus a écrit 5237 commentaires

Et bien je trouve son programme paradoxal.

Je trouve ça amusant d'avoir la fraicheur d'esprit de souhaiter lire le programme d'Asselineau et de partir sur l'idée de l'analyser d'un point de vue rationnel.

Asselineau, je le «connais» depuis près de 15 ans par Wikipédia. À l'époque, le mec (ou un soutien proche) n'arrêtait pas de créer un article sur lui, alors qu'il ne remplissait pas les critères d'admissibilité. Au bout de plusieurs suppressions de pages, de menaces de poursuites, de menaces physiques à l'encontre des admins de Wikipédia, le mec a réussi à faire tellement de buzz qu'il a commencé à intéresser des pigistes de journaux locaux, puis de plus en plus gros, autour de l'idée que Wikipédia censurait les mouvements politiques marginaux, que ça prouvait que Wikipédia était noyauté par la CIA ou les chinois du FBI, etc. Après plusieurs mois de ce petit jeu, il s'est avéré que l'histoire de ce mec avait assez intéressé les journalistes pour qu'il atteigne mécaniquement les critères d'admissibilité de Wikipédia! Le premier Homme à devenir connu pour s'être trop plaint qu'il était inconnu. C'est un tour de force, pathétique quelque part, mais quand même assez impressionnant.

Les gens un peu barrés, il y en a toujours eu, ça ne m'étonne pas. Ce qui m'étonnera toujours et démontre mon manque de compréhension de la psychologie humaine, c'est que certain d'entre eux arrivent à attirer autour d'eux une cour de suiveurs encore plus barrés, et super-motivés. J'imagine que c'est comme ça que les religions démarrent, mais j'avoue ne pas réussir à comprendre comment ça peut marcher.

tu manges ce qui est pré-mâché.

En même temps, à mon avis, le pré-mâché a l'avantage de laisser aux gens qui n'ont pas de dents le bénéfice du doute sur leur capacité à mastiquer. Parce qu'il y a quand même pire que les gens qui répètent les âneries pré-mâchées : c'est ceux qui les inventent eux mêmes :-)

Au final, tu as donc stocké 6 hashs (un par chiffre) de 1 chiffre chacun.

Tu peux stocker 20 hashes de 3 chiffres (un par combinaison), je ne suis pas certain du tout que ça facilite une attaque éventuelle…

J'imagine que ça permet de ne pas se faire intercepter son code en une fois au cas où ça se produit. Choisir 3 chiffres parmi 6 donne (si je ne me trompe pas) 20 combinaisons, ce qui fait que quelqu'un qui te voit taper ton code dans un cybercafé ou qui arrive à l'intercepter n'a qu'une chance sur 20 de pouvoir le reproduire.

les claviers virtuels sont déjà assez pénibles comme ça. si c'est pour en plus ajouter une complexité

On peut toujours discuter des détails, mais je ne pense pas que les banques ou autres organismes n'aient pour unique but dans la vie que de pourrir ton expérience utilisateur avec leurs services, c'est même probablement le contraire. Il faut quand même comprendre que l'équation est extrêmement difficile à résoudre : on veut des moyens de payement les plus fiables, les moins chers, les plus rapides, les plus sécurisés, et les plus faciles à utiliser possible. Par exemple, à titre personnel, je n'ai jamais compris l'intérêt des cartes sans contact, mais à voir le nombre de gens qui trouvent ça génial et qui réclament ce type de services aux commerçants, je me dis que je ne représente pas du tout la majorité. Comme on veut par dessus tout que la banque couvre les fraudes (à raison la plupart du temps, mais aussi en cas de négligence), il parait quand même assez normal que les banques trouvent un compromis entre l'achat en un clic et le chèque de banque. C'est certain que la multiplication des systèmes d'identification un peu baroques (code SMS, email, code partiel, claviers virtuels…) est un peu déroutante et semble parfois inefficace, mais comme on ne veut pas non plus de puces implantées sous la peau, il faut bien quand même une solution intermédiaire en terme de complexité.

Oui mais là, ce que tu décris, c'est simplement de maitriser une panoplie d'outils : un langage compilé pour les perfs, un langage de haut niveau pour parser des fichiers, un shell pour automatiser les tâches, et éventuellement quelques langages spécialisés en fonction des besoins (service web, bases de données, gestion des tâches sur un cluster de calcul…). Je pense que personne ne peut vraiment imaginer que c'est inutile.

Là où ça devient vraiment discutable, c'est (si j'ai bien compris l'approche proposée dans le journal) l'idée d'avoir une culture générale très large en terme de langages de programmation. Mon point de vue, c'est que si on est à l'aide en perl, il n'y a aucune raison d'apprendre python et ruby sans avoir auparavant identifié un besoin précis. Même si chaque langage a ses particularités, et qu'un traitement pourrait être plus efficace ou plus facile à coder avec un langage précis, mieux vaut certainement utiliser un langage dont on maitrise les caractéristiques plutôt que de pondre un code de débutant dans un langage qu'on connait mal. Ça pose trop de problèmes de lisibilité, de maintenance, de performances, ou même de sécurité.

Mouais, les mécanismes de la fiction ne sont pas ceux de la réalité, tout le monde le sait. Le but est de raconter une hsitoire, et quand tu racontes une histoire, tu utilises des "trucs". Sinon, c'est pas que c'est réaliste, c'est que c'est chiant.

Par exemple, quand tu as un personnage qui a envie de pisser, c'est parce qu'il doit sortir de la maison pour se faire bouffer par les zombies ou par les dinausaures. Tu n'as jamais un mec qui sort pisser, et qui revient deux minutes après sans qu'il ne se soit rien passé. C'est comme ça, dans les films, aller pisser, ça doit servir à quelque chose.

L'autre problème que tu évoques, c'est évidemment que tous ces films sont des produits industriels standardisés. Individuellement, les ficelles qu'ils utilisent sont évidemment des "bons" processus narratifs, mais ils sont usés jusqu'à la corde par leur sur-utilisation et parfois par leur utilisation caricaturale.

Il faut de toutes manières imaginer que le public devient de plus en plus difficile, parce que justement il est super habitué à des superproductions théorisées et millimétrées. Évidemment, tu peux toujours trouver un marché de niche pour le ciné alternatif, mais trouver un public pour des films d'actions qui ont des moments chiants où il ne se passe rien, ça ne va pas être évident. Au final, il suffit de relire les grands auteurs classiques par exemple pour se rendre compte à quel point ils ne maitrisent pas les lecteurs ; Victor Hugo écrivait bien et ses romans méritent d'être lus pour leur aspect historique ou pour la description de la société, mais pas pour la maitrise du récit de fiction. Si tu es snob, tu peux trouver les chapitres entiers de descriptions "enrichissants" ou "reposants", mais honnêtement, c'est juste super chiant.

apprendre à apprendre et de combiner le meilleur de chaque langage

D'après mon expérience, c'est quand même dans l'exploitation de leurs subtilités que les langages deviennent intéressants, et l'expertise du programmeur également.

Le problème de l'approche polyvalente, c'est quand même qu'un programmeur ne peut pas connaitre à fond des dizaines de langages. Du coup, il va écrire du code passe partout, c'est à dire du pseudocode traduit dans la grammaire du langage en question. Ça pose un certain nombre de problèmes, notamment le fait de ne pas maitriser correctement un seul langage, et de manière plus générale ne pas exploiter les possibilités d'un langage. On peut aussi écrire du code qui respecte la grammaire du langage mais pas son esprit (par exemple l'(in)fameux C/C++).

L'autre problème, c'est que pour un projet donné, on ne peut pas écrire un bout de code en C, un bout en Rust, un truc en javascript, l'interface en perl et le serveur en C++… Au bout d'un moment, il faut savoir maintenir une cohérence dans un projet, parce que d'autres êtres humains sont susceptibles de lire le code et d'essayer de modifier le truc.

Au final, j'ai du mal à comprendre ce principe de la connaissance superficielle des outils. Pour trouver du boulot, peut-être? Mais après, forcément, on risque d'être impliqué des années dans un projet basé sur un ou deux langages, et donc se spécialiser.

La question, c'est quand même si les causes d'invalidité partielle de la GPL sont problématiques ou non. Il y a trois points "litigieux" dans la GPL d'après la CeCILL :
* Le problème de la cession des droits d'auteurs sans limitation dans le temps
* Le problème de l'absence totale de garanties
* Le problème de l'absence de la localisation du tribunal en cas de litige

Je ne sais plus comment la CeCILL gère le premmier problème, mais pour les deux autres, la résolution n'est franchement pas terrible.

Pour les garanties, la CeCILL se met en conformité avec le droit français ; elle admet qu'il y a une garantie pour les dommages directs et quand l'utilisateur est un particulier. Or, pour moi, c'est problématique : la CeCILL offre cette garantie non seulement aux utilisateurs français (qui y auraient droit de toutes manières même si la licence était la GPL, sauf qu'ils leurs faudrait éventuellement contester la licence au tribunal pour ça), mais aussi à tous les utilisateurs étrangers (et ce, même si la clause de levée de garantie était légale dans leur pays). Du coup, ça met en effet l'auteur du logiciel en situation de "sécurité juridique" : il sait qu'il doit potentiellement payer pour les dommages directs à tous les utilisateurs de la planète. Mieux vaut éviter d'utliliser la CeCILL quand on code un driver de disque dur, hein…

Pour la localisation, la CeCILL impose Paris. À mes yeux, c'est une clause de juriste à la con, qui assure certes la sécurité de l'auteur du logiciel, mais qui retire énormément de sécurité à l'utilisateur. Franchement, tu utiliserais un logiciel chinois qui t'impose d'aller défendre tes droits à Pékin? L'"insécurité" relative de la GPL me semble beaucoup plus satisfaisante : le plaignant bénéficie des lois de son pays. De toutes manières, il me semble très improbable qu'un tribunal étranger se déclare incompétent et décide de se débarrasser du problème.

C'est mon opinion de non-juriste et elle ne vaut pas grand chose, je l'admet. J'ai juste l'impression que la CeCILL grave dans le marbre ce que concluerait logiquement un tribunal français si un auteur français essayait de faire valoir ses droits, et grave aussi dans le marbre les droits qu'aurait un utilisateur français, qui est bien plus protégé que la moyenne. Du coup, tu as la "sécurité" (dans le sens de "certitude"), mais à mon avis mieux vaudrait rester dans le flou, surtout pour les dommages directs qui peuvent te conduire sur la paille alors que tu bosses bénévolement, faut pas déconner quand même.

Pour avoir discuté avec des gens qui étaient dans les discussions ayant finalement mené à la rédaction de la CeCill, j'ai quand même eu l'impression que les motivations étaient principalement politiques. C'est sûr que ça a été vendu sur la base d'argument juridiques, mais sur le fond, l'idée semble avoir tourné autour de l'idée qu'il n'était pas acceptable pour un organisme public Français par exemple de mettre son travail disponible dans une licence élaborée par nos "ennemis" anglo-saxons.

En plus, imagine que la licence est tellement bien écrite et tellement claire que toutes les clauses paraissent sans aucun doute légales et inattaquables. Personne n'irait tenter un procès perdu d'avance. Du coup, ça voudrait dire que cette licence parfaite ne serait pas validée par la justice? Ça me semble paradoxal.

D'une certaine manière, à ma connaissance, personne n'a jamais vraiment remis en question la validité potentielle d'une licence comme la GPL. Il reste quelques zones d'ombre (liées par exemple à la manière de gérer la rétractation des auteurs, qui est théoriquement possible en droit français), mais globalement, quand on regarde les quelques conflits qui ont existé, les débats ont porté par exemple sur la nature du propriétaire des machines sur lesquelles les logiciels tournaient, et pas sur les bases de la GPL.

Du coup, on aime quand même bien jouer à se faire peur. Si la GPL était trouée, il y a peu de doutes qu'on le saurait déja.

Donc du coup, les solutions vaporware qui n'existent pas sont mieux que celles proposées?

Oui, parce que les solutions proposées sont indéboggables et ne relèvent que de bricolages «quick & dirty», le genre de choses que tu utilises quand tu n'as besoin que de faire quelque chose une fois et oublier à jamais. Et encore, il ne faut pas que ça soit quelque chose d'important.

Ce que le PO souhaite faire, importer deux fichiers csv qui contiennent des données partiellement chevauchantes, chercher un certain pattern dans le deuxième fichier, et remplacer ce pattern sous certaines conditions avec des données du premier fichier. Enfin, il souhaite écrire un csv valide. Tu as vu la quantité de trucs nouveaux qui arrivent à chaque question? «Ah oui, c'est possible que des IDs soient dupliqués», «il est possible que certains ne correspondent pas», etc. Clairement, il faut quelques dizaines de lignes de code dans un vrai langage de script, qui importe les deux fichiers, vérifie s'ils sont valides (bon nombre de colonnes, bons types de données, etc), retire, gère, ou fait quelque chose pour les ID dupliqués ou manquants, éventuellement balance des warnings "Ligne 3251 ID invalide", fait les remplacements souhaités, et génère le fichier valide en sortie.

Après, on peut discuter éternellement sur l'adéquation d'un outil à faire quelque chose. Si l'argument c'est simplement que c'est possible, alors oui, mais c'est aussi possible en Brainfuck. Si ça doit tenir sur 4 lignes incompréhensibles et illisibles, alors oui, c'est possible, mais il faut faire confiance et c'est du code jetable (c'est peut-être ce qui était demandé, hein). Ça n'est pas comme ça que je ferais, mais j'admet tout à fait que c'est une culture qui existe en info et il faut vivre avec.

La question, c'est un peu la même que si tu appelles un plombier pour une fuite. Tu as peut-être des mecs qui te collent un chewing-gum sur la fuite, qui foutent un coup de scotch autour et qui scellent au briquet en t'expliquant que ça polymérise le chewing-gum et que tu vois, ça ne fuit plus. En 5 minutes il a fini, et peut-être qu'en effet, ça va tenir 20 ans. Mais il n'y a pas besoin d'être un gourou de la plomberie pour voir que ça n'est pas comme ça qu'on devrait faire. C'est sûr que de couper l'eau, faire des soudures, des tests, en profiter pour changer les joints et consolider au cas où les autres endroits où ça pourrait fuir dans les années qui viennent, ça prend plus de temps et ça coûte plus cher.

Une installation qui ne dispose pas de ces fameux "langages avancés"

Et tu manipulerais des fichiers .csv (pour t'interfacer avec un tableur?) sur des systèmes qui n'ont pas perl ou python?

On pourrait le faire en assembleur, aussi.

Honnêtement, à part pour un exercice, je ne vois pas vraiment l'intérêt de tripatouiller des fichiers csv avec bash/awk/grep. Tous les langages interprétés un peu avancés ont des bibliothèques capables d'importer du csv, de stocker le contenu dans des variables adéquates, de les manipuler, et de réécrire les fichiers.

D'expérience, quand on commence à tripoter à l'arrache le contenu de fichiers, on a très rapidement des problèmes majeurs (notamment, aucune assurance sur la conformité du fichier après modification), et on va avoir des algos de plus en plus complexes pour faire des opérations triviales (additionner deux colonnes, transposer un tableau par exemple).Du coup, perl, ruby, python, R, on s'en fout un peu, mais à mon avis il faut changer d'outil.

Je lis souvent l'argument «on ne sait pas si la licence X ou Y est valable en France car il n'y a jamais eu de procès». Je ne suis pas juriste, mais je ne pense pas que cet argument fonctionne.

Ce n'est pas à la justice de valider une licence. La justice ne peut faire qu'une chose, c'est l'invalider (totalement, ou juste une clause). C'est le cas pour tous les contrats : a priori, quand on signe un contrat, on est engagé par le contrat. Ce qui peut se passer est que certaines clauses soient illégales, et si on ne veut pas les respecter, alors ça peut être à la justice de trancher (et donc d'établir une jurisprudence sur les clauses qui sont illégales ou non).

Si quelqu'un pense que certaines clauses de la CC-NC ne sont pas valides en droit français ET que ce quelqu'un bénéficie d'un document distribué sous cette licence ET qu'il viole la clause en question ET que l'ayant droit n'est pas d'accord et qu'il lui fait un procès, alors la justice devra se prononcer. Ça fait beaucoup de "ET".

Du coup, j'aurais tendance à penser que le contrat de licence doit être considéré comme valide tant que ses clauses n'ont pas été invalidées par la justice.

quand tu descends ton temps de travail, c'est un addendum au contrat

Il me semble qu'il y a quand même un truc précis pour les 80% liés à des obligations familiales. Ça dépend très certainement des conventions collectives et donc du secteur d'activité, mais le fait d'accorder les 80% est parfois une obligation pour l'employeur (et donc, j'imagine que ça n'équivaut pas forcément à la signature d'un nouveau contrat de travail, surtout que c'est réversible).

Par contre, il faudrait demander à des spécialistes du droit de travail, mais le fait de refuser de signer un nouveau contrat de travail peut tout à fait légalement entrainer un licenciement. Du coup, ça ne me semble pas forcément débile de penser que si ton employeur souhaite te faire signer un nouveau contrat (avec par exemple augmentation ou diminution du temps de travail) et que tu refuses, alors tu peux te faire licencier. Ça n'est pas une faute, et tu vas donc bénéficier d'indemnités et tout, mais le licenciement est légal.

D'une manière générale, quand les employeurs parlent de l'impossibilité de licencier les gens, en fait, ils parlent du coût d'un licenciement sans faute. Pour licencier quelqu'un, il faut avoir une raison valable, mais ça peut très bien être lié à une mauvaise entente ou à un désaccord sur le temps de travail. Par contre, en absence de faute, c'est sûr qu'il faut raquer un peu. Ce que voudraient les entreprises, c'est de pouvoir licencier sans faute et sans raquer, mais ça c'est pas prévu par le code du travail.

Le problème n'est pas dans la subordination, le problème est dans le marché du travail et dans l'intensité de la concurrence (marges disponibles dans le secteur). Comme dans toute négociation, chacun a à y perdre et à y gagner.

Il y a des secteurs où les salariés sont en position de force. Mais ça n'est pas fréquent ; en général, même quand le marché du travail est en faveur des salariés, les marges peuvent être tellement basses qu'une augmentation de salaire peut couler la boîte, surtout dans un contexte international très compliqué.

parce qu'il y a plusieurs niveaux de veille

C'est quand même un truc assez curieux, et il faut vraiment creuser pour comprendre comment ça marche (ce que je n'ai jamais fait). Le problème (sous Ubuntu, mais j'imagine sous n'importe quelle distrib) c'est que la mise en veille et le réveil est potentiellement problématique pour tout un tas de pilotes ou autres modules, et que ça rend les choses très difficiles à débogguer. Par exemple, refermer le couvercle d'un laptop ne fait pas la même chose que de cliquer sur "Mettre en veille", qui ne fait pas non plus la même chose que ce qui se passe après x minutes d'inactivité. Et là, on ne parle même pas de l'hibernation, qui peut se déclencher directement à partir du menu, ou automatiquement en fonction du niveau de batterie, etc. C'est d'une complexité… et ça explique bien pourquoi il y a autant de problèmes avec la veille et l'hibernation, rien que de remonter un bug reproductible demande une compréhension très fine des mécanismes de veille.

Par exemple, mon laptop ne se réveille pas d'hibernation quand elle est déclenchée à cause d'une batterie faible après une mise en veille par inactivité (ouf). Bon, bah dans ce cas je redémarre, et je n'ai jamais cherché à reproduire le bug pour le reporter…

De toutes manières, je ne suis pas du tout certain que des fichiers créés il y a 18 ans soient parfaitement lisibles avec des versions récentes de MS Office…

Euh, tes deux lignes du 28/02 ne fonctionnent pas (ou alors je n'ai pas compris). J'ai l'impression que tu donnes une piste, mais ça n'est pas une solution. Ce qui fonctionne c'est la solution en deux lignes qui est en dessous.

Parce que la réponse en 2 lignes n'était pas encore là lors de mon premier post? :-)

Merci, je croyais que c'était clair mais visiblement non :-)

C'est une histoire de partage des tâches. Le script, une fois lancé, doit s'exécuter comme prévu. Le job de cron est de le lancer à certaines heures. Si tu délègues à ton script le choix de s'arrêter si ça n'est pas la bonne heure, alors tu empiètes sur le job de cron, tu crées tout un tas de bugs potentiels. Au final, tu vas rescripter un cron-like sans fonctionnalités et tout buggé. Alors non, je ne trouve pas ça élégant. C'est peut-être pragmatique, ça peut éventuellement marcher, mais c'est crade.

139 lignes dans cron, ça n'est pas simple, ça n'est pas non plus élégant, mais ça a le mérite de ne pas empiéter sur les tâches des différents acteurs.

J'ai tendance à considérer que les définitions des termes appartiennent à ceux qui utilisent les mots dans leur langue, plutôt qu'à ceux qui les définissent. En l'occurrence, en France, le libéralisme est assumé par les libéraux économiques, et ce que tu appelles les "sociaux-libéraux" s'appellent en français les "sociaux-démocrates".

Que les anglophones n'aient pas la même défintion, ou même que les définitions historiques soient obsolètes, ça ne me gène pas. Tant pis pour les gens qui se prétendent libéraux et qui ne se retrouvent pas dans la définition "journalistique" du libéralisme ; ils sont juste destinés à rester éternellement incompris et à se battre contre les mots plutot que contre les idées.

Sur le fond, de toutes manières, tu n'as pas 150 visions. Soit tu "libères" les salaires, en diminuant les cotisations sociales pour les reverser en partie au salarié et en partie à l'employeur (charge à eux de réinvestir cet argent dans la protection ou dans l'assurance sociale), soit tu étatise les prélèvements obligatoires pour en faire des trucs plus ou moins redistributifs ou plus ou moins mutualisés (en privant les salariés de la liberté de consacrer cet argent à autre chose). Prétendre que retirer une telle liberté de choix, ça revient en fait à te donner plus de liberté effective, c'est une définition Nord-Coréenne de la liberté…

Je crois que c'est exactement ça le problème, et que le débat actuel est rendu volontairement confus pour éviter de mettre à jour le fait que les candidats de droite et de gauche sont complètement d'accord sur le constat de base : l'emploi est dramatiquement rare depuis 40 ans, et pourtant c'est une des choses les plus taxées. Après, les propositions diffèrent sur les solutions, puisque la vision libérale, c'est de diminuer la protection sociale de manière à baisser le coût de la main d'œuvre, alors que la solution de gauche est d'aumenter la taxation de la valeur ajoutée pour rendre les gains de productivité liés à l'automatisation moins rentables. J'imagine que les centristes pourraient défendre une vision "un peu des deux" s'ils daignaient publier leur programme.

Mais bon, on peut bidouiller les taxes et les cotisations autant qu'on veut, un salarié est un être humain qui peut tomber malade, qui a besoin de week-ends, de vacances, qui a une vie familiale, qui a besoin de sous même quand on n'a pas besoin de lui au boulot, etc. J'ai du mal à comprendre comment on peut imaginer que la tendance puisse d'inverser : à moins d'imposer par la force ou par des mesures fiscales violentes une perte d'argent sur les gains de productivité, il sera toujours plus rentable d'automatiser les tâches. Tant qu'on ne change pas notre façon de penser, on finira dans le mur.

la solution en bas est plus elegante.

Pragmatique et simple peut-être (et encore, c'est buggogène si on merdoie sur les timezones etc), mais élégante, carrément pas. On pourrait imaginer que cron appelle toutes les 10 secondes la totalité des scripts qu'on y met et que chaque script vériie que ça n'est pas l'heure de se lancer…

Personne n'a parlé de mettre toutes les heures sauf celles où il ne veut pas? Ça fait 139 lignes.

j'harcelais souvent Arte en les traitant de gros racistes

Cool, c'est constructif. Ça fait plaisir de tomber sur des gens raisonnables.