jben a écrit 841 commentaires

Mes conclusions :

• Ce genre de benchmark mesure surtout la connaissance de celui qui l'a écrit dans les différents langages concernés

• […]

• Laissez le calcul haute performance aux spécialistes et pas au économistes :-)

J'ai envie de dire que ce genre de benchmark mesure surtout ma méconnaissance des langages.

Déjà un problème conceptuel. Dans l'article ils décrivent leur problème, mais ils ne décrivent pas leur algo. Qui semble aller de soi quand on lit l'article, mais quand on regarde dans le détail il y a plein de petits trucs qui peuvent tout changer. Il aurait été un minimum de mettre dans l'article ou dans une annexe l'algo de manière dissociée du language.

Un autre problème conceptuel est sur le choix de l'algo utilisé dans la comparaison. C'est un algo qui est vectorisable, où beaucoup d'étape (peut-être toutes) peuvent êtres écrites sous forme de calcul matriciel. Ça implique pas mal de chose, quand à l'utilisation des libs adaptées et quand à la capacité des differents compilateurs de de faire des opérations utiles comme changer l'ordre des boucles.

Le point du calcul matriciel m'amène à voir que dans certains programmes (MATLAB par exemple) certaines étapes vectorisables sont vectorisés, mais pas d'autres (pourquoi ?) et dans d'autres (en C++ par exemple) ces mêmes étapes ne sont pas vectorisées (pourquoi ? ils ne connaissent pas les libs comme armadillo ?). Dans un benchmark, le minimum est de mettre toutes les possiblilités dans des conditions équivalentes. Soit on utilise les subtilitées et les capacités de chaque language pour optimiser au mieux le code, et dans ce cas on compare les langages dans un cas très particulier, les conclusions sont attachées à ce cas particulier. Soit on utilise rigoureusement le même algo (et ne vectorise pas dans un code sans le faire dans l'autre), et dans ce cas on a une comparaison tellement générale qu'elle ne retranscrira pas la particularité d'un langage à résoudre un problème donné. Mais en faisant un mélange entre les deux, au lieu d'obtenir une conclusion partielle, ils obtiennent une conclusion invalide.

Après dans le détail, je viens juste de l'évoquer, pour les quelques langages que je connais, je saute au plafond. En C++ outre les boucles dans un ordre étrange, c'est du code vectorisable, il y a des libs pour ça. Dans un des code, j'ai eu l'horreur de voir une definition d'un template Matrix à la main. Moi aussi quand j'étais jeune j'ai codé intégralement sans rien y connaître mes libs de calcul matriciel (j'ai même écrit une lib d'algèbre linéaire en PHP, oui j'ai honte), oh ben on a des opérations inefficace aussi bien en temps qu'en mémoire, c'est étrange.

Au niveau du choix des langages, on a également de qui être dubitatif, Mathematica, vraiment. Oui un logiciel de calcul symbolique n'est pas un logiciel de calcul numérique. MATLAB, c'est efficace pour du calcul matriciel, oui les trois premières lettres du noms ne sont pas là par hasard. On peut être dubitatif également sur le soin apporté à chaque logiciel, par exemple en MATLAB on fait un MEX, en R on pourrait implémenter une procédure C ou C++ (qui aurait les perfs du C, et avec les libs adaptés genre Rcpp ça a le niveau de simplicité du R), et après la conclusion sur R est négative, on s'y attendait.

Après pour les conclusions, elles ne sont pas vraiment fausse (enfin certaines me laissent séptique pour ne pas dire ahuri), mais elles enfoncent des portes ouvertes. Oui les langages compilés sont plus rapide pour faire des boucles, oui les langages adaptés pour le calcul matriciel (R, MATLAB) ne sont pas adaptés pour faire des boucles, oui les langages de calculs symbolique ne sont pas adaptés pour faire du calcul numérique, oui la compilation JIT c'est le bien.

Bref, ça vaut rien ce benchmark. L'article ne semble pas publié dans une revue, autrement il aurait clairement mérité une réponse en règle.

Oui mais le don que le locataire a effectué avant est necessaire à l'obtention du rabais. Au yeux du fisc, et il a raison, cette partie fait intégralement partie du loyer, même si tu ne la touche pas, elle doit être intégré au calcul de ton revenu.

Et au niveau de la libre fixation du prix du loyer, c'est vrai si ni le locataire ni le propriétaire ne tire pas de bénéfices extérieur de la fixation des prix, ce qui n'est pas le cas en l'espèce. Sinon au yeux du fisc c'est un transfert d'argent (par exemple les parents qui louent à leurs enfant un logement à un prix très inférieur au marché, et bien ça doit être déclaré en tant que don).

Une rapide recherche sur le net montre que c'est connu.

Pour le meurtre en effet, tu n'as pas de graduation en fonction du moyen. Mais en fonction du moyen tu peux viser plus d'infractions et faire des combinaisons gagnantes. Par exemple pour ton meurtre à la petite cuillère, je pense que nous sommes dans la catégorie des actes de barbarie (222-1), qui entraînent un mort volontaire (221-1), et comme tu as fait un crime avant le meurtre (222-2) tu passe de 30 ans de réclusion criminelle à la réclusion criminelle à perpétuité.

Aussi le moyen peut te faire changer de catégorie. Dans le cas de ton suppositoire explosif, il sera difficile pour toi de plaider la non prémiditation. Ainsi tu rentres dans la catégorie des assassinats (221-3), ce qui change aussi la peine pour la réclusion criminelle à perpétuité.

Un conseil, au niveau moyen, reste simple !

Cher ami,

Ca m'étonnerais

Moi aussi vois-tu. Mais il en est ainsi des formules de politesse. De même que quand tu clôtures lettre adressé au service des impôts par « je vous prie, Madame, Monsieur, bla bla bla les plus sincères », tu n'en pense pas un mot, mais tu l'écris. Tu préfereras donc cette version je pense :

Cher contradicteur,

Cette hypothèse est juste fausse, pleine de préjugé et stupide.

Soit. C'est ton avis, qui ne semble pas partager par tous les intervenants de la discussion.

Le chiffrement, ca existe.

Oui. Mais pour que le mot de passe puisse t'être envoyé, il faut que la clef de déchiffrement soit accessible par le système automatisé. Nous nous plaçons, depuis le début, dans l'hypothèse d'une compromission du système de traitement automatisé, sinon le fait de discuter du mode de stockage n'aurait point d'intérêt. Dans ce cas, si la base est compromise, la clef de déchiffrement est également compromise, et donc au niveau sécurité, je le répète, c'est équivalent à un stockage en clair.

Sans rancune, je te laisse à ton thread d'expert de comptoir.

Peux-tu nous donner des références en matière de sécurité ? Que je sache à qui ne jamais faire confiance.

Cher ami,

Tu as du lire la discussion en diagonale, je te pardonne. L'hypothèse de départ était quelque chose comme « si un site est capable de renvoyer son mot de passe à un utilisateur, alors il est stocké en clair ». Là tu distingues le stockage via une bijection dont la réciproque est aisément calculable et le stockage en claire.

Je confirme, distinguer ces deux formes de stockage, c'est de la nuisance au minimum. Les arguments que tu m'invoques, c'est-à-dire possibilité de calculer la réciproque en un temps raisonnable ne sont pas adéquats. Nous sommes dans l’hypothèse d'un site qui renvoie à l'utilisateur son mot de passe.

Crois-tu sérieusement qu'un site qui te renvoie ton mot de passe l'avait hashé et l'a brutforcé rien que pour le le renvoyer ? Moi je n'y crois pas une seconde.

Relis bien le thread auquel tu réponds, et tu comprendras que tu fais preuve de nuisance, à dessein ou non, ça je ne le sais.

Ridicule, j'espère que tu ne code que des applis en php.

Ce que je code est bien plus interessant que des applis.

Si la bijection réciproque est facile à calculer (du genre ce n'est pas un chiffrement avec une clef non disponible), c'est strictement équivalement à un stockage en clair.

Différencier le stockage via une fonction bijective dont la réciproque est connu et le stockage en clair stricto sensu, c'est caractéristique soit d'une incompétence flagrante soit d'une volonté de nuire. Je te laisse choisir.

si il y a un salt, là ça devient très dur.

Tu plaisantes j'espère ?

Je récupère le sel, qui est pas utilisateur en même temps que la base. Pour chaque utilisateur, je bruteforce connaissant le sel, chez moi, avec mon vieux processeur je fais 10⁵ hash/seconde, bref en espérance 5 secondes pour avoir le mot de passe d'un utilisateur.

Alors c'est vrai que qu'on ne peux pas travailler de manière globale, et qu'on doit travailler utilisateur par utilisateur, mais ça me parait un peu faiblard de baser la sécurité là dessus.

Ça me fait penser aux incompétents qui anonymisent une base de donnée de faisant un hash(nom.prenom) en fournissant à coté la liste des (nom,prenom)s.

Pourquoi réinventer la roue à chaque fois ? On a un standard pour faire cela, reconnu et tout et tout, ça se nomme HMAC et ça s'utilise avec un algo de calcul de condensat (MD5, SHA-1, SHA-2, SHA-3…). J'en parle dans un commentaire sur un des nombreux journaux sur le sujet. Moi je le fais en python, vous le faites en javascript, soit, on se fout de l'implémentation. Mais c'est pas une raison pour ne pas utiliser HMAC au lieu d'un algo maison.

Commentaire sur le reste du journal : à chaque fois on utilise les mêmes arguments, à chaque fois on voit les mêmes propositions, à chaque fois avec les mêmes défauts, et à chaque fois les même réponses. Ce genre de débat est aussi inintéressant qu'un débat sur la moto.

J'ai voulu tenter de mettre cela (que j'encode ici en base64) ça ne passe pas

8J2TnvCdk7Eg8J2Tu/Cdk6rwnZOw8J2Triwg8J2TuPCdk7Eg8J2TrfCdk67wnZO88J2TrvCdk7zw
nZO58J2TuPCdk77wnZO7LCDwnZOe8J2TsSDwnZO/8J2TsvCdk67wnZO18J2TtfCdk67wnZO88J2T
vPCdk64g8J2TrvCdk7fwnZO38J2TrvCdk7bwnZOy8J2Triwg8J2TtyfwnZOq8J2Tsi3wnZOz8J2T
riDwnZOt8J2TuPCdk7fwnZOsIPCdk73wnZOq8J2Tt/Cdk70g8J2Tv/Cdk67wnZOs8J2TviDwnZO6
8J2TvvCdk64g8J2TufCdk7jwnZO+8J2TuyDwnZOs8J2TrvCdk73wnZO98J2TriDwnZOy8J2Tt/Cd
k6/wnZOq8J2TtvCdk7LwnZOuID8K

Encore un système qui ne supporte pas les unicodes plus haut que U+10000. Je ne sais pas pourquoi, mais c'est assez fréquent.

Tu remarqueras que la tranche horaire à laquelle je poste des messages avec accents est toujours différente de celle à laquelle je poste des messages avec accents. Tu remarqueras aussi que j'ai souvent tendance à poster en fin de journée, voire en pleine nuit. Tu pourras alors inférer que je me trouve sur un autre continent, et que je n'ai pas accès à du bépo partout où je suis.

Non mais cette excuse pourrie, à un moment ça suffit. Ça fait plusieurs années que j'utilise un qwerty-us en France ou ailleurs (actuellement ailleurs), et je ne vous pas en quoi ça pose un problème.

Tu peux avoir plein de raison de ne pas mettre les accents, allant de la mauvaise foi à la flemme en passant pas l'ignorance orthographique (ce qui est mon cas), mais le choix du clavier ne fait définitivement pas partie de ces raisons. Te viendrais-t'il à l'idée de poster sur un forum russe/chinois/whatever en utilisant que l'ASCII avec comme excuse « nan mais je ne sais pas faire autre chose avec mon clavier ».

En fait à la relecture de ton commentaire (le temps d'édition est trop court) j'ai pensé à autre chose. Ça dépend quelle est ta constante. Si (comme moi) tu as une certaine distance à faire qui est fixé, alors afficher en L/km est judicieux, tu minimise le pognon mis pour une distance. Si tu as une certaine quantité de carburant à mettre et après tu marches à pied, alors afficher en km/L est judicieux, tu maximise la distance pour un pognon fixé.

C'est ce que je disais dans mon premier messages, les deux ont leurs avantages, même si perso je préfère l'un à l'autre. Mais il n'y a pas une grandeur qui est tout bien et l'autre tout mal.

Si tu passe de .065 à .069 L/km, alors tu passes de 500 à 470 km. Je pense que le ressenti est le même dans les deux cas. Ton raisonnement était fallacieux.

Après tu dis que ce que tu vois c'est la distance, oui, mais c'est aussi ce que tu ne maîtrise pas. Souvent tu cherche à diminuer la quantité d'essence pour un même trajet. Et de plus présenté comme ça, c'est directement lié au pognon que tu dépenses pour faire avancer ta boîte de métal (j'ai aussi une voiture, ce n'est pas un raisonnement anti-voiture, mais il faut avouer que ça reste une boîte de métal) ou à la quantité de polluants que tu rejette. Bref ce sachant que tu dois faire une certaine distance qui t'est imposée, cette consommation en L/km est proportionnellement lié à ton pogon ou à ta conscience écologique suivant ton obédience.

Mais donc: je ne l'ai pas touché, pas de témoin à part mes passagers (apparemment ça ne compte pas pour les assureurs) et donc 100% pour ma gueule.

Quand ton assureur te propose une solution que tu ne trouve pas acceptable, il n'y a que trois raisons de le laisser faire, et de ne pas porter l'affaire au civil contre l'autre automobiliste ou ton assureur suivant le cas (souvent tu attaques l'autre automobilistes et les assureurs vont se joindre au dossier) :

• Considérer que les assureurs sont des dieux qui ont raison.
• Ne pas vouloir s'emmerder pour cela.
• Avoir tort.

Après le problème, c'est que pour l'avoir déjà fait, c'est que les assureurs ne sont pas effrayés par un imbécile se mettant à déclamer « je vais aller en justice », il faut vraiment le faire. Ce n'est que quelques jours avant l'audience (une heure avant dans mon cas) que comme par miracle, les assureurs réussissent à se mettre d'accord sur une solution que tu trouve acceptable.

En fait elles sont toutes les deux pertinentes dans certains cas.

Par exemple, je fais 10 km avec une conduite souple .05 L/km (20 km/L), et 10 km avec une conduite agressive, .1 L/km (10 km/L), ma consommation moyenne sera de .075 L/km (13.3 km/L) et non .067 L/km (15 km/L). On peut faire la moyenne des L/km mais pas des km/L.

Par contre si tu dit, « j'utilise la moitié de mon plein pour me faire plaisir en conduisant comme une brute (se faire plaisir dans ou sur un engin motorisé, c'est étrange) et l'autre moitié en conduite éco », alors dans ce cas, il faudra faire la moyenne des km/L et non des L/km.

Après je pense que intuitivement, on fait plus de somme et moyenne de quantité qui correspondent à des L/km et donc que l’unité européenne est plus adaptés. Je pense que l'utilisation d'une distance par volume de carburant nous conduit à faire des moyenne non appropriées, et à sous-estimer notre consommation réelle.

Avec une phrase par ligne c'est assez rare d'avoir 2000 caractères, sauf quand j'écris aux impôts.

Après c'est aussi trompeur le numéro de ligne, des fois il fait référence à la dernière ligne du paragraphe…

Édit: j'ai cru que tu avais répondu à l'commentaires que je viens de poster dans ce thread.

Le fait que le retour à la ligne (simple) ne soit pas significatif permet aussi des trucs sympa. J'essai par exemple lorque je rédige un document MarkDown ou LaTeX qui est versionné, d'utiliser la logique une phrase, une ligne. Les lignes peuvent être longues ce n'est pas le problème, je ne respecte pas de limite de nombre de caractères pas ligne. En tout cas, ça permet au gestionnaire de version d'être plus efficace, et d'avoir moins de conflits.

Mais pour cela, il faut que le retour à la ligne (simple, toujours) ne soit pas significatif.

Sans vouloir le défendre, quand j'écris un commentaire sur linuxfr, je mets des retours à la ligne un peu n'importe où, avec l'habitude que les retours à la ligne (non dupliqués) ne sont pas significatifs en MarkDown. Ce n'est qu'après avoir écrit mon commentaire que je suis obligé de le relire pour les supprimer, et ça me les brise sérieusement. J'ai proposé un rapport de bug pour proposer de rendre ce comportement optionnel resté sans effet à ce jour.

Ceci n'est en aucun cas une critique, j'essaie juste d'avoir une explication rationnelle à certains retours à la ligne intempestifs que l'on constate.

Le module cifs est-il chargé lors du montage des filesystems au boot ? Si il n'est chargé qu'après, ça expliquerai pourquoi le mount -a fonctionne et qu'il ne fait pas au boot. Tu as regardé les logs de démarrage ?

je n'ai que très, très rarement besoin de lancer des recherches sur autre chose que le sujet, l'expéditeur ou les destinataires de mes messages

Le problème c'est que le sujet n'est pas chiffré avec OpenPGP. Alors il y a des gens comme moi, quand ils envoient un mail chiffré, mettent en sujet « Mail chiffré ». Va faire tes recherches après avec des sujets aussi significatifs…

Au final, moi je fais des recherches par expediteur, destinataire et date… C'est limité, d'où l’intérêt de bien trier ses mails et ne pas compter sur google un système de recherche ultérieur.

Il est courant de noter en point la différence de deux proportions effectuées sur une population non constante.

Donc si je reprends les données du journal il s'agit bien d'un bond de 2.38 % à 4.21 %, et si on veut parler de la difference on va parler de 1.83 points de pourcentage et non 1.83 %, car parler de 1.83 % sous-entendrai qu'on est resté à population constante.

Après je répond juste à ce qu'est un point de pourcentage. Le commentaire initial qui demande si c'est un bond en points de pourcentage, j'avoue que je ne comprends pas.

Je te propose deux alternatives :

• Tu mets en place un serveur SMTP. Utiliser postfix dans ton c'est un peu utiliser une pioche pour planter une paquerette. Un serveur plus léger et plus simple à configurer comme opensmtpd (il est dans debian testing, et il se backporte facilement sur stable) peut être un bon choix.

• Tu code ton propre serveur smtp qui recevra le mail et fera la requete. Cela parrait difficile, mais en fait il ne suffit que d'utiliser l'implementation de twisted, et il y a même un tutorial pour réaliser un serveur SMTP.

Et en dernière alternative, que je ne te propose pas, mais qui existe, si tu as envie de te pourrir le cerveau et que tu es un masochiste à un stade avancé, tu peux configurer exim.

Alors vous avez en plus des disques pour les données, ok. Donc ma remarque sur la taille tombe à l'eau.

Si je demandais pour le moyen de transport, c'est que pour moi, tout ce qui est info (portabe et disque) ça va dans la remorque mono-roue. Une remorque mono-roue ça ne vibre pas beaucoup et c'est idéal pour transporter le materiel. (Je viens de passer d'acheter une mono-roue, par rapport à la remorque classique à deux roues que j'utilisais avant, ça n'a rien à voir au niveau vibrations et effort sur le pédaleur). Par contre aucune nécessité de séparer les sauvegardes, à moins que tu envisage le cas attaque par des zombis, si l'un survit il aura les données, par contre avoir deux copies c'est une bonne idée.

Après je le redis car je le pense, 2GiB pour traiter des raws pour moi c'est faible, mais c'est mon avis. darktable c'est bien, et au niveau distrib, ce que vous voulez. (Je n'ai rien dit pour le traitement des fichiers audio, car je n'y connais… rien).

L'essentiel est surtout de vous familiariser avec le système et les logiciels avant de partir, au moment où vous avez accès à tout le nain-ternet.

Et ton sac tu le met où ? Surtout pas sur le bonhomme. Si tu ne veux pas te fatiguer inutilement le cycliste n'a aucun sac, et tu charge le vélo comme un mulet. Sacoches avant et arrières + remorques.

C'est vrai que je viens de faire le calcul, ça fait 22km par jour en moyenne. Et 29km en altérnant un jour de repos pour trois jour de vélo.

Mais peut-être qu'ils ont prévu plein de choses en plus du vélo, et donc ça explique la nécessité d'un ordinateur.