gasche a écrit 1151 commentaires

C'est moderne dans un contexte d'intégration par le mainstream des idées de la programmation fonctionnelle. On a un langage avec des fonctions d'ordre supérieur, des types statiques, des options et du filtrage de motif. Ce n'est déjà pas mal !

Du reste, il y a un travail de vulgarisation qui est fait (par exemple sur le pattern-matching avec un mot-clé let explicite qui souligne que les variables sont en position de lieurs) qui est intéressant.

(Le but réel est sans doute de re-segmenter le marché pour éviter que des langages qui tournent sur iOS et Android continuent à être les plus populaires. Mais techniquement c'est un bon essai, et un signe de plus que la programmation fonctionnelle a gagné la partie.)

Ne regardant pas régulièrement les journaux (merci pour ces dépêches récapitulatives qui aident à avoir l'essentiel !), j'ai été content de découvrir un journal sur Seccomp, mais surpris de voir qu'il ne faisait aucune mention de ma dépêche de Janvier 2012 qui parlait de seccomp en grand détail (et du lien avec le projet Capsicum qui m'intéresse beaucoup aussi).

Y a-t-il un problème de "connaissance collective" sur LinuxFR ? J'ai tendance à supposer que les dépêches orientées contenu (par exemple la dernière sur 0.A.D ou celle sur BellePoule) sont là pour durer, et peuvent être considérées comme un savoir acquis pour la communauté. Mais ça ne marche que si des gens font parfois le travail de rechercher ce qui a été écrit dans le passé et de le citer dans les discussions où c'est pertinent.

Il me semble que ce serait important si on veut continuer à avoir des dépêches à "fort contenu ajouté", et pas seulement des actualités pertinentes sur le moment mais vites périmées. Ou alors on peut décider que ce n'est pas le rôle des dépêches (que les contenus ayant vocation à rester archivés sont plutôt les journaux, et que les dépêches sont pour les annonces du prochain salon Linux ou version d'ERP machin), mais dans ce cas il faudrait encourager les auteurs de ce genre de dépêches à plutôt rédiger des journaux.

La formulation est maladroite mais je pensais à l'expérience cumulée par les législateurs (à travers les générations qui travaillent sur les lois), qui est (sans bien sûr idéaliser à outrance) digne de respect et de considération.

Pour un logiciel comme cela, je pense qu'il est indispensable d'avoir un screenshot sur la page d'accueil (ici, dans le README présenté par github), et si possible une page à part avec des screenshots variés.

Sinon, la seule façon de se faire une idée "je le veux ou pas" est de télécharger, compiler et lancer le logiciel, et c'est bien trop compliqué, personne ou presque ne fera l'effort.

Tu énonces trois excellents arguments:

1. La classification inné/acquis est en réalité un sujet extrêmement complexe et encore mal compris. On ne peut pas extrapoler une étude scientifique sur un fait précis à des comportements plus généraux. En particulier, on ne peut pas raisonnablement se contenter d'une hypothèse de la forme "c'est peut-être lié à des prédispositions physiologiques" pour expliquer des inégalités en société.

2. L'utilisation de ce genre d'arguments a historiquement eu des effets catastrophiques, précisément à cause d'extrapolations excessives. L'histoire sert à éviter les erreurs du passé, qui nous enseigne ici clairement qu'en absence de preuves incontestables il vaut mieux se tenir le plus loin possible des arguments sur l'acquis/hérédité.

3. Un débat sur une situation déséquilibrée n'a pas pour but de statuer sur une explication "scientifique" de ce déséquilibre, mais de nous interroger sur l'effet qu'il a sur la société, s'il est désirable, quels sont ses effets positifs et négatifs, et comment faire évoluer la situation dans une direction d'intérêt général. Choisir de débattre d'éventuelles causes physiques hors de notre contrôle (mais supposées et non démontrées) est une façon d'écarter une question (souvent une question qui gêne) sans aucune certitude et qui n'apporte pas de progrès.

J'en ajouterai un quatrième, que je conçois comme une forme de "rasoir d'Ockam" des phénomènes de sociétés : plus une tentative d'explication est "bas niveau", moins elle est probable et digne de considération. Quand on s'interroge sur les accidents de la route, il convient de se demander en premier lieu quels sont les comportements des conducteurs et les environnements de conduites qui influent sur le risque d'accident. C'est seulement quand on a bien compris ces questions, et s'il a lieu de soupçonner des causes plus indirectes, qu'il fait sens de se demander, par exemple, s'il existe des causes psychologiques (hypothèse en soit tout à fait recevable, mais juste "de second ordre") ou évolutives (on observe que dans les bancs de poissons…). Se demander s'il existe une prédisposition génétique aux accidents de la route est encore plus éloigné de l'objet d'étude, et donc encore moins probable, pertinent et raisonnablement lié au problème (on pourrait y venir, mais il faudrait le justifier sérieusement par une compréhension en profondeur des causes plus immédiates). Enfin, supposer qu'il existe un boson inconnu de la physique des particules qui est vecteur d'accidents de la route est absurde (bien que ce soit, dans l'absolu, possible, et qu'on ne puisse pas démontrer scientifiquement le contraire).

Je mettrai cependant un petit bémol concernant les sites anglo-saxons, car sur reddit aussi, dès que le sujet aborde le social ou la politique, des commentaires ne volent pas bien haut.

Bien sûr, reddit/worldnews est délirant, mais la spécificité de reddit est qu'on peut choisir les sous-communautés auxquelles on participe. Je suis sur des sous-reddit techniques (pour des langages de programmation principalement), sur lesquels les questions sociales et politiques sont hors-sujet, donc le problème ne se pose pas.

Stopper les sujets qui ne sont pas techniques ? Dommage !

Réduire la présence des sujets non-technique serait une solution, je pense, mais on ne peut pas les "stopper". Par nature il y a forcément de la politique qui concerne LinuxFR (tout ce qui touche au logiciel libre et à la technique dans le politique), et la question de la représentation des femmes (par exemple) en informatique me semble tout à fait appropriée et importante (et je pense qu'elle aurait pu être traitée d'une façon moins polarisée par les commentateurs).

Je ne vois pas forcément en quoi éviter les discussions politiques sur LinuxFR serait une perte. Si les gens veulent casser du sucre sur l'actualité française, il y a plein de sites qui sont là pour discuter de ça, les gens sont tout à fait libres de faire vivre cette discussion ailleurs.

Cloturer les comptes des pertubateurs ?

Ça me semblerait choquant.

Par contre, si les modérateurs (ou la communauté) déclaraient clairement que les discussions purement sociales et politiques sont hors-sujet, et rappelaient à l'ordre les gens qui dérapent pendant les discussions, on pourrait éviter les perturbations.

Arrêter de lire ou participer aux commentaires ? La pire !

Boarf, de fait c'est ce que je fais; pas par volonté, mais parce que je n'ai plus vraiment le temps de tout lire dans le détail. Le sujet qui m'intéresse le plus personnellement (les langages de programmation) sont très mal traités sur LinuxFR (le niveau des discussions est très décevant). Et en général, le contenu des dépêches (et parfois journaux) concentre souvent 80% du travail total fourni, et aussi de l'intérêt du contenu.

Une dépêche très intéressante et qui a certainement demandé un grand travail. Lu et apprécié.

Je regrette que les commentaires soient envahis de gens qui sont passés à côté du cœur de l'article pour s'attaquer, à travers cette dépêche, à la politique française du moment. C'est bien triste; j'ai l'impression d'avoir de plus en plus besoin d'un sac à vomi quand je me promène sur LinuxFR.

Je me demande si la communauté est sauvable ou s'il est juste le temps de faire le deuil et d'aller dans d'autres zones plus sûres car plus neutres (arstechnica pour le généraliste et linux weekly news pour le technique). Ou peut-être faut-il simplement abandonner l'idée des commentaires sur internet et classer linuxfr dans la catégorie des Youtube/Lemonde et compagnie : lire le contenu éventuellement, les commentaires jamais. Pourtant j'apprécie beaucoup les discussions sur reddit; il y a des choses de bien à faire pour cela, mais LinuxFR étant averse au changement…

Étant membre d'une équipe de recherche publique qui pense à produire des biens publics de qualité, je me sens un peu offensé mais un peu amusé aussi par cette remarque qui tire dans les coins. J'ai deux-trois autres exemples en tête, notamment RMoD qui travaille sur Pharo, Parkas qui contribue notamment à GCC et LLVM, et le beau travail de l'IRILL pour formaliser et améliorer les écosystèmes de gestion de paquets dans le projet Mancoosi.

Une idée de dépêche LinuxFR ? Que les autres coupables se dénoncent…

Pourquoi ne pas la poster comme dépêche maintenant ?

Ce serait drôlement pratique de pouvoir éditer un message sans limite de temps (avec un historique qui permet aux gens de voir les anciennes versions pour la transparence), dis donc.

Ton commentaire est très intéressant sur le plan technique mais aussi un peu déprimant :

Peut-être qu'une partie du problème vient aussi du fait que les gens qui font vraiment de la rétroingénierie (et donc savent ce qu'ils veulent) n'ont pas le temps de contribuer à un tel logiciel open source. En tout cas c'est mon cas.

Et donc votre plan à long terme c'est quoi, dans 20 ans vous conseillerez toujours d'utiliser IDA ? Et si des gens veulent expérimenter sur des façons nouvelles/différentes/avancées de faire de la rétro-ingénérie, ils se font embaucher par la boîte ou refont tout depuis rien ?

On parle souvent de "dette technologique" pour le cas de la base de code d'un logiciel donné (qui par accumulation de code peu maintenu devient impossible à faire avancer), mais je pense que certains domaines souffrent d'un "gouffre technologique" car tous les outils utilisés sont propriétaires. Au contraire, dans de nombreux domaines (par exemple les langages de programmation), il y a un mélange sain d'outils libres et d'outils propriétaires qui fait qu'une partie des outils du domaine font partie de notre savoir collectif. Si on veut écrire un compilateur aujourd'hui, pas besoin de tout reprendre de zéro ou de s'entendre dire "tu ne concurrenceras jamais ICC et personne ne veut utiliser un truc moins bien", on peut s'appuyer sur LLVM (par exemple).

Je pense que c'est sans doute un aspect négligé de certains logiciels libres comme Gimp ou LibreOffice. D'accord, entre quatre yeux, ils sont peut-être moins biens (sous plein d'aspects) que leur principal concurrent propriétaire. Mais ils sont là, ils n'ont pas abandonné le terrain, et chaque fonctionnalité qui leur est ajoutée entre dans notre propriété partagée des connaissances et des outils, d'où chacun pourra repartir pour créer son propre projet—en plus de rendre des services quotidiens aux utilisateurs moins exigeants.

Dans d'autres domaines au contraire, comme l'ingénierie inverse si on en croit ton message, nous sommes collectivement démunis, réduis à mendier l'offre d'un, deux ou trois grands outils, qui ont tellement d'avance qu'ils écrasent toute tentative d'enrichir l'offre publique.

Heureusement qu'il y a des gens assez fous, assez courageux ou ayant assez de temps à perdre pour se lancer à la poursuite de ces géants. Ils n'y arriveront peut-être jamais (mais la chance peut tourner; Sage peut concurrencer Mathematica, IPython+SciPy peut concurrencer Matlab, Blender peut concurrencer Maya, etc.), mais les retombées positives en valent la peine. C'est fou tout ce qu'on peut faire quand on est soudain libre de monter sur les épaules des géants.

(Remarque: dans certains écosystèmes, le rôle du savoir commun partagé est assuré par un accès à un SDK propriétaire mais standardisé. Par exemple, iOS n'a pas apporté la reconnaissance vocale à notre univers de connaissance, mais donné un moyen fiable pour les développeurs d'applications iPhone de s'en servir sur leur système. C'est la norme dans certains écosystèmes, comme les moteurs de jeu vidéo. Ça donne des systèmes plus cloisonnés, moins extensibles, moins appréciés sur LinuxFR, et moins durables dans le temps, mais c'est aussi une forme d'aide à la réalisaton qui est intéressante et appréciée.)

Buffer.add_channel ? Ou Unix.read si tu veux un truc plus bas-niveau.

La comparaison est inégale au vu des années-effort mises dans la réduction et spécialisation des montages de code produites par un compilateur C++, en comparaison au peu de sophistication (relativement) de l'inlining/duplication côté compilateur OCaml. Déjà aujourd'hui avec le boxing autour de std::function il ne me semble pas du tout clair que la stratégie de compilation de OCaml soit perdante. Et ce, en partant d'un langage plus simple, plus élégant et plus uniforme.

Beaucoup d'articles ont été écrits sur Ender's Game. J'ai été personnellement très intéressé par la critique de John Kessel, Creating the Innocent Killer. Je conseillerai à quiconque qui a lu le livre de prendre un quart d'heure pour la lire, le rapport intérêt/temps est sans doute supérieur à celui du film (que je n'ai pas vu, ceci dit).

In relating Ender Wiggin’s childhood and training in Ender’s Game, Orson Scott Card presents a harrowing tale of abuse. Ender’s parents and older brother, the officers running the battle school and the other children being trained there, either ignore the abuse of Ender or participate in it.

Through this abusive training Ender becomes expert at wielding violence against his enemies, and this ability ultimately makes him the savior of the human race. The novel repeatedly tells us that Ender is morally spotless; though he ultimately takes on guilt for the extermination of the alien buggers, his assuming this guilt is a gratuitous act. He is presented as a scapegoat for the acts of others. We are given to believe that the destruction Ender causes is not a result of his intentions; only the sacrifice he makes for others is. In this Card argues that the morality of an act is based solely on the intentions of the person acting.

The result is a character who exterminates an entire race and yet remains fundamentally innocent. The purpose of this paper is to examine the methods Card uses to construct this story of a guiltless genocide, to point out some contradictions inherent in this scenario, and to raise questions about the intention-based morality advocated by Ender’s Game and Speaker for the Dead.

Il est intéressant de noter qu'une partie importante du projet Xen est codée en OCaml (un langage fonctionnel statiquement typé), en fait surtout les parties bas niveau / système. Pour l'instant l'annonce concerne plutôt le code de front-end (interface avec l'utilisateur) en C#, mais des couches logicielles en OCaml sont déjà disponibles depuis longtemps, notamment le XAPI project.

lors d'un écrasement, et avec certaines plateformes où il est compilé de façon optimisée, gzip n'agit plus comme si vous aviez tapé « y » lorsque vous tapez « n ». (bogue présent depuis gzip-1.3.6) ;

Cette erreur a l'air très croustillante. Serait-il possible d'avoir plus d'explications, en particulier un lien vers le commit corrigeant le problème ?

Je n'ai pas compris si la sortie actuelle du jeu est le résultat d'un effort de portage récent. Tu peux élaborer ?

Je remarque dans ton historique de dépêches que tu as produit pas mal de contenu intéressant sur Desura, et Runesoft en particulier. Par curiosité, as-tu des liens avec ces boîtes ?

Je ne trouve pas que vendre 9€ par copie un jeu qui date d'il y a plus de 5 ans et qui a déjà été porté sous Linux soit "intéressant". Je suis peut-être gâté par les Humble Indie Bundle où j'ai payé moins par jeux pour des choses qui m'ont beaucoup plu, mais je trouve que ce prix est élevé. À qui reviennent les profits et quelle est la justification de ce prix ?

(Je suis tout prêt à payer pour des biens immatériels quand ça rend service à des gens que je respecte, etc. Mais ici à qui va l'argent ?)

Pour le morceau de musique associé à la nouvelle version, c'est par ici. Il n'y a pas encore de commentaire écrit.

Peu de paroles cette fois-ci, très instrumental :

I've seen things your programs wouldn't believe.

Stack frames unwinding with Turing complete behaviour.

I watched threads racing trampoline bindings in ld.so.

[..]

(Pas mon préféré, mais les goûts et les couleurs… J'aime bien 3.9: Blob! entre autres.)

La plupart des conseils donnés sont flous, pas forcément applicables, potentiellement contradictoires, voire incitent à faire n'importe quoi. Plus précisément :

Comme il est possible par bruteforce (ou des techniques plus raffinées) de retrouver le mot de passe en clair et qu'il existe des tables précalculées (Rainbow table) pour les principaux algorithmes, il est aussi conseillé de saler les mots de passe. Cela consiste à ajouter des bits aléatoirement générés à la création du login et les ajouter au mot de passe avant d'utiliser la fonction de hachage.

Le bon conseil à donner et d'utiliser une fonction de dérivation de clé connue, de lire sa documentation et de comprendre son interface. Le conseil tel qu'il est formulé ici incite le lecteur à implémenter sa propre technique de salage, ce qui va certainement résulter en de mauvais choix peu sécurisés (en particulier si c'est utilisé avec un algorithme de hachage n'ayant pas les bonnes propriétés). Au lieu de jouer à l'apprenti cryptographe, il vaut mieux utiliser des solutions déjà conçues par des spécialistes. Ça n'empêche pas de décrire l'idée sous-jacente (autant en plus comprendre ce qui est fait), mais en insistant pour éviter les mises en œuvres manuelles.

L'intérêt est de ralentir le déchiffrage de votre base de données, et, à moins que vous n'authentifiez des milliers d'utilisateurs par seconde (ce qui peut arriver en cas d'attaque DDoS, il est donc bon de s'en protéger), ça ne devrait pas poser de problème de performances sur votre serveur.

Merci le conseil contradictoire, c'est non-clair au possible. Je dois utiliser des algorithmes couteux en ressource, ou plutôt essayer de me protéger des DDoS ? Tu veux dire qu'il ne faut pas faire ce que tu dis, ou qu'il faut faire autre chose que tu ne dis pas ? Ça pose problème ou pas finalement ?

Les bibliothèques sont idéalement à inclure (mais cela représente certainement trop de travail pour être réellement fait)

Donc il faut le faire ou il ne faut pas le faire ? Si ce n'est pas faisable en pratique, autant ne pas en parler, les gens ne le feront pas. Une bonne politique de sécurité doit prendre la faisabilité en compte.

Et d'ailleurs ce conseil n'est-il pas contradictoire avec celui des distributions qui conseille au contraire d'utiliser les bibliothèques partagées, pour profiter des fixes de sécurité ? Tu parles d'autre chose, à un autre degré de la chaîne, qui s'applique dans d'autres circonstances ?

L'usage de conteneurs dynamiques (listes chaînées, par exemple) permet de réduire drastiquement les risques de ce genre d'attaques, mais impliquent un coût en ressources (temps processeur et occupation mémoire notamment) plus élevé. Ces conteneurs ne sont donc pas la panacée.

Donc je les utilise ou pas ? Si ce n'est pas la bonne solution, qu'est-ce qui est conseillé ici ?

un gars qui s'y connaît plus ou moins bien sur la technique

Comme nos lecteurs qui moinssent à loisir ont l'air d'avoir envie d'un peu plus de troll et un peu moins de politesse, je précise : je parle des branleurs qui ont suivit des cours de management à la con en école de commerce, et qui font les sangsues dans des startups pour piquer les sous de l'État pour faire de la prétendue recherche, en se faisant payer autant voir plus que les techniciens qui savent de quoi ils parlent, tout ça parce que de toute façon ils ne sont bons à rien d'autre.

(Lalala.)

Je me moque de ton discours politique sous-jacent qui n'apporte à mon avis pas grand chose au débat qu'un troll facile et des "agree to disagree". Je n'étale pas mes opinions sur le droit du travail, et même si c'est encore une justification facile de plus pour aller bosser aux US, à Singapour ou en Chine, j'aurais préféré que tu t'en tiennes aux aspects sur lequel un échange d'opinions est réellement possible et constructif.

Je regrette que tu choisisses de te concentrer sur la pique enfouie dans le message plutôt que le reste de ma réponse, que j'espère constructive; et tu as l'assurance de tout mon respect par ailleurs (la politesse n'étant que la forme que prend l'expression de ce respect, et pas une fin en soi).

Yep, des trucs pratiques si t'es doué en paperasse. les startup c'est plus des gars qui ont une idée.

Mauvaise réponse à mon avis. Dans les startups tu as en général un gars qui s'y connaît plus ou moins bien sur la technique et qui est à temps plein sur la communication, les paperasses et les autres trucs du genre. Je ne connais pas très bien la vie des startups américaines aujourd'hui maintenant, mais je suis sûr que la composante paperasse (pas forcément en relation avec l'état, mais avec les investisseurs, les fonds d'aide à l'innovation, les prix du meilleur blabla…) est tout aussi déterminante.

tu n'es pas obligé d'insulter les personne en désaccord avec toi…

J'avais oublié que le sarcasme ne passe pas bien sur internet, mais je pensais qu'au moins toi Zenitram tu savais ça, crapule.

Bon nombre d’entrepreneurs en France se restreignent car si ça merde un peu, ça reient très cher (à licencier pour cause économique).

Ça ressemble plus à des problèmes de PME (qui sont déjà un minimum viables) qu'à ceux d'une boîte d'informatique qui mise sur l'innovation. Je parle du genre de boîtes que créent ici les gens qui ont un profil "Sillicon Valley", et je pense que c'est un peu différent.

Après, la France, toi compris, ne veut pas des entrepreneurs, ben ils ne faut pas alors qu'ils se plaignent qu'il vont aux USA. La France a choisit.

C'est facile comme discours. Je pense qu'il y a de vrais problèmes dans le milieu entrepreneurial français (pas convaincu que ce soit le droit du travail mais bon chacun ses opinions politiques), mais ce n'est pas en partant à l'étranger que tu aides à les résoudre. Il me paraît normal que chacun fasse ses choix en disant "moi je préfère privilégier ma fiscalité, donc j'optimise en partant (légalement) aux Canaries" si ça lui souhaite, mais il me semble que des notions de dette morale ou de justice entrent aussi en jeu dans les choix.

Tous les acteurs ne vont pas simplement optimiser la variable "niveau de vie" et faire immédiatement leurs choix en fonction. Il y a un seuil de différence que chacun est prêt à tolérer¹, qui varie selon les gens (l'égoïsme, quoi). Certains vont tolérer une différence raisonnable et partir s'ils s'y sentent vraiment forcés (cas typique : il n'y a pas de boulot dans ma branche, tous les postes sont pris), d'autres vont faire la princesse au petit pois et se dire qu'on "ne veut pas d'eux" à la première contrariété, enfin certains vont avoir le tort de prendre un boulot qui les emmerde à mourir parce qu'ils ont peur de l'inconnu alors qu'ils seraient bien plus heureux ailleurs.

À mon avis il y a des extrêmes qui ne sont pas bon, et un juste milieu raisonnable, mais bien sûr c'est un critère subjectif qui dépend de chacun. Ce qui ne veut pas dire pour autant que tout est égal et qu'on n'a rien à dire quand les gens font les connards.

¹: c'est exactement la même chose avec le logiciel libre, on ne choisit pas son logiciel purement sur des critères techniques un instant fixé. Partant de la constation que Microsoft Office a des fonctions tableurs plus avancées que Libre Office, certains vont utiliser la solution propriétaire sans prendre en compte l'intérêt de soutenir le logiciel libre (qu'ils aient effectivement besoins de ces fonctions avancées ou non), d'autres vont utiliser le libre à tout prix même si ça les gêne beaucoup dans leur branche d'activité, et la plupart va privilégier la solution libre tant que le différentiel de qualité pour leur usage précis ne dépasse pas un certain seuil, et passer à la solution propriétaire au delà. Dans tous les cas il s'agit d'optimisation multi-facteur (niveau de vie et sentiment d'arnaquer l'état providence, efficacité au taf et moralité des choix logiciels) où les gens utilisent des coefficients de pondération différents.

Tu marques des points sur la taille du marché anglo-saxon (mais en fait tu peux aussi développer des produits en anglais en France, hein, ou même les spécialiser aux US), et sur un certaine mentalité de classe des grandes entreprises françaises (mais bon moi aussi je peux jouer aux exemples : Xavier Niel a fait quelle grande école ?). Je passerai sur le discours de connard de droite qui ne m'intéresse pas (comme si c'était la facilité à licencier qui faisait ou non le succès des startup).

Je pense qu'aujourd'hui les conditions économiques sont plus que favorable pour les auto-entrepreneurs dans les milieux high-tech. Crédit impôt-recherche par ci, pépinière d'innovation par là, etc. Certes, les investisseurs français ont moins le goût du risque que les VCs de la Valley, mais aujourd'hui avec ton beau marketing de connard de droite et un peu de buzz sur le transfert technologique, oh si, tu peux certainement trouver des thunes pour monter ta boîte un peu innovante en informatique. Je dis pas que ce sera aussi sécurisé qu'un job pénard à Redmond (mais Microsoft France embauche aussi), que tu pourras te sniffer autant de rails de coke qu'à Los Angeles, ou que tu auras autant de facilité à te faire racheter par NetFlix que quelqu'un qui est dans le milieu sur place, mais il reste tout à fait possible de faire des choses ici si tu en as la motivation.