ckyl a écrit 3877 commentaires

Dans le gros paragraphe de la présentation des tables de hash, il n'y aurait pas eu une confusion entre les mots "clef" et "valeur" ?

Pourquoi ?

Une table de hashage ne se s'occupe que de la clé, la valeur étant juste une référence qu'on stock pour pouvoir la retourner à l'utilisateur[1].

Après j'ai aussi utilisé le mot valeur pour designer l'entier retourné par la fonction de hachage appliquée à une clé, ce qui est un peu malheureux mais devrait rester compréhensible.

[1] Ok dans le cas d'une multi map on s'en sert aussi un peu mais bon :)

Ne serait-il pas plus pertinent dans ce cas de raisonner non pas en valeur absolue mais en proportion du chiffre d'affaire ?

Non.

Chercher la correlation entre contribution au logiciel libre et comportement responsable ou bonnes pratiques concernant les données utilisateur est idiot à la base. Ce sont deux choses assez orthogonales en pratique comme en théorie.

Pour le cas de hash32 en particulier, en théorie ils auraient besoin de la réflection. En pratique, et exactement pour les raisons que tu cites, ils ont une petite cachoterie qui se nomme SharedSecret. Grosso modo c'est une classe publique qui autorise un mécanisme de classe amies du, très, pauvre. C'est aussi pourri mais au moins c'est type safe. Bref le bordel habituel :(

Y'a Andrew Huges qui en avait parlé il y a longtemps.

cela ne prend pas les accents ?

La font humor-sans ne définie pas les symboles avec les accents. On doit cependant pouvoir en trouver une autre qui fait l'affaire ou l'améliorer. J'ai pas trop cherché non plus c'est rare que j'annote des graphiques en francais.

Merci pour le patch. D'ailleurs c'est dommage de ne pas pouvoir ressortir facilement les corrections faites par les modos pour les réappliquer sur le document source.

J'ai pas écrit de Perl depuis des années mais je pense que pour la situation actuelle tu peux regarder là et pour l'historique là

WTF !! Mais c'est ça qui méritait un journal dénonciateur !!

Je fais rarement des choses dénonciatrices ;) C'est beaucoup plus intéressant de comprendre le processus et l'idée qu'il y a derrière un changement. En l’occurrence, l'auteur de ce changement à pas mal expliqué les choses sur reddit.

Après on peut émettre un avis: le sien. Pour ce changement je comprends parfaitement le rationnel, et je pense que par défaut le comportement actuel est le bon. Il y a plus de monde qui se faisait piéger par la référence gardée sur le buffer original que de gens écrivant des parser sachant ce qu'ils font (et plus de gens intéressés à gagner 8 octets par instance). À l'époque j'avais même du écrire un agent pour essayer d'identifier les substring qui survivaient à plusieurs GC pour auditer une grosse base de code. Ce qui est beaucoup plus discutable c'est que maintenant il soit impossible d'avoir accès à l'ancien comportement et de l'avoir fait dans une mineure.

Mais la leçon la plus intéressante, c'est de voir que ce deuxième changement a été précipité par l'ajout de hash32 qui était une mauvaise réponse au problème.

Quant à leur solution à la problématique d'attaque par collisions elle me laisse un goût amer. Ils ont fortement compliqué l'implémentation de la classe de référence.

Je ne suis pas d'accord avec ça. La réponse de la JEP 180 est pour moi la bonne: corriger la structure de donnée pour offrir une meilleure complexité au pire cas et une performance équivalente au cas moyen.

• Ça pallie aux attaques par collision sur les Strings.
• Ça gère mieux les fonctions de hash biaisées. Il n'y a pas que String dans la vie, et les fonctions des utilisateurs sont en général une catastrophe (j'inclus les miennes)
• Ça permet d'être plus agressif sur le load factor, ce qui dans certains cas particulier peut être intéressant
• C'est une solution auto-contenu. On corrige les structures de données qui pose problème. Ca veut dire que n'importe qui peut faire de même avec ses structures de données. Souvent la solution est de la tambouille interne au JDK. C'est dégueulasse par ce que le message c'est: "On a fait un truc pour nous mais toi développeur t'es dans la merde alors que tu as le même problème" et c'est bien trop courant.

Complexifier la classe pour moi est un faux problème. Ce n'est pas très complexe, le design s'explique facilement et c'était déjà complexe. Ça se test très facilement (et de manière exhaustive). Ça pourrait prendre un an à développer, ça reste une classe utilisée par le monde entier donc seul le résultat final compte c'est d'ailleurs pour ça qu'on te fourni ces classes.

J'aurai préféré qu'ils enrichissent l'API de HashMap avec un constructeur qui permette de passer une fonction de hashage, comme TreeMap avec le Comparator. De cette manière, le développeur choisi si il veut se protéger de l'attaque ou pas.

Ça pourrait être quelque chose d'orthogonal au fait d'améliorer le pire cas. En pratique je ne suis pas certain de l'utilité de la chose pour les raisons suivantes:

• Si la complexité au pire cas est raisonnable, c'est beaucoup moins critique
• Il faut faire super attention à ce que le contrat entre equals et hashCode soit respecté.
• Pour les hashCode "lent" tu veux en général les cacher une fois qu'ils ont été calculés. C'est notamment le cas avec String. Avec un hachage externe à l'objet ça devient compliqué, crado ou dangereux.

Mais ça demande d'y réfléchir plus longuement.

Répondu dans un autre commentaire: mode xkcd de matplotlib.

(Et à la fin du journal tu trouves un lien avec tout ce qui a servi à faire le journal (code Java, logs des runs JMH et le notebook IPython pour traiter les résultats)

Mais pourquoi Java documente ainsi la triperie interne ?

En général ce n'est pas le cas. Les contrats sont du type "Chaque opération à cette complexité", "l'ordre d'itération est garantie ou non" etc.

Pour l'histoire spécifique de hashCode je ne sais pas pourquoi ça a été documenté. On trouve dans le bug tacker que l'implémentation actuelle est apparue entre 1997 et 1999 avec Java 1.2. Ils ont donc déjà fait le changement une fois mais le contexte était différent, d'ailleurs l'analyse est rigolote:

Risk Assessment:      Surprisingly small.  Serialization of Hashtables does
                      not depend on consistent hash values.  It is possible
                      that some customer has implemented some persistent data
                      structure that relies on the String hash function not
                      changing, but it is highly unlikely that more than a
                      handful of customers have done so.

Maintenant même si la javadoc n'avait pas documenté l'algo noir sur blanc je ne sais pas si ils auraient fait le changement. D'une manière générale Java est très conservateur sur les changements de comportement même pour des choses qui ne sont pas écrite noir sur blanc. Le but est de ne pas casser le code existant même si il est en tord. (pour le meilleur ou pour le pire donc). En théorie changer hashCode ne change pas grand chose, en pratique du code pourri qui fait des supposition sur l'ordre des iterateurs, qui le persiste ou fait d'autres merdes avec ça se trouve malheureusement.

D'un autre côté dans la même 7u6 ils ont discrètement balancé un autre changement nucléaire sur les String: changer l'implémentation de substring. Là le changement était permis par le contrat mais l'impact sur les applis est réel. En gros, avant un substring créait un objet qui pointait sur le byte buffer original (on partage donc la mémoire et c'est O(1)) maintenant il fait une copie du byte buffer original (on ne partage donc plus la mémoire et c'est O(n)). Le rationnel était qu'il est facile de faire des fuites mémoire par error avec l'ancienne implémentation. Maintenant tout le code qui reposait intensivement sur substring (parser etc.) à vu son profile à l'exécution bien changer… Comme quoi le choix de le faire où non peut être variable et est en général bien analysé.

Tu fais comment pour générer les graphiques qui semblent dessinés à la main ?

C'est le mode xkcd de matplotlib. Si ca t'intéresse le code qui a servi à générer les graphiques est dans le notebook IPython sur github (dernier lien).

Il ne faut pas en abuser, mais je trouve qu'il indique clairement que l'intention du graphe est de donner une idée générale ou un ordre de grandeur et non de focaliser sur des chiffres précis: "Si deux courbes sont proches, ne vas pas chercher plus loin que tu as le même comportement". À l'inverse le style ggplot2 indique clairement que si tu as envie d'analyser précisément le graphique tu peux: "Si deux courbes sont proches tu peux analyser chaque couple de point individuellement et creuser pourquoi".

Merci. Apparement il y a aussi:

• le lien de la pep 452 (http manquant)
• le pointeur vers le code de HashMap (un espace en trop)
• le lien vers les slides du 28C3 (http manquant)

Les autres semblent être bons, ils apparaissent comme visités chez moi.

toutes les entreprises n'ont pas les moyens de payer 1 informaticien par serveur, sauf si tu bosses pour Google, donc tous les moyens sont bons pour gagner du temps.

Je pense que tu prends le mauvais exemple. Si on fais un calcul au dos de l'enveloppe pessimiste: ~2 millions de serveur pour au max 2000 SRE (ça ferait un ratio SWE:SRE de 4:1) ça nous fait minimum 1000 serveurs par personne (qui n'est pas dédié à plein temps à ça).

C'est totalement inintéressant comme calcul, sauf qu'on est en 2014 et si tu fais du sysadmin manuel, à la papa, non automatisée "You're doing it wrong". D'ailleurs ils sont pas encore mort les sysadm ? :)

Moi cette polemique me fait doucement rigoler. Mozilla Corp depense de l'argent dans la location de locaux a Paris, oh mon dieu!

Tu me réponds à moi, mais t'es conscient qu'on pense la même chose ? ;)

Ça va je crois que Sophia-Antipolis, Aix-en-Provence et Lyon ont aussi des bassins d'emplois informatiques assez conséquents. Ce n'est pas Paris, mais je doute qu’ils ne trouvent pas assez de gens compétents à bas.

Sérieusement faut arrêter de déconner. Lr grosse majorité des gens compétents avec qui j'ai bossé se sont petit à petit fait recruter à l'étranger/Paris avec un gros chèque et des projets intéressants car le bassin local n'a rien à offrir. La plupart des autres, sont resté pour la région, et ne sont plus sur le marché de l'emploi local car ils sont en poste depuis de quelques années et sont totalement hors grille tarifaire de nos jours. Il reste 2 pelés à recruter et tous les moyens/mauvais.

Donc pour trouver des gens compétents c'est juste la misère (la question du salaire vient après), la où à Paris, SF, Londres, Berlin, NY, Zurich ça se fait facilement. Sachant que faire venir les gens n'est pas non plus évident car tu es en compétition avec les autres bassins qui importent et n'avoir que 1, 2 ou 3 boites qui sont des employeurs potentiels dans ton secteur pose forcément un handicap quand les gens décident de leur destination.

Je ne connais personne, même des gens bien payés, qui aime vivre à Paris. Souvent ils sont là pour le boulot mais s'ils pouvaient avoir le même ailleurs ils partiraient.

Tu peux ne pas aimer Paris ou autre grande ville et c'est mon cas.

Ce qu'il dit est par contre extrêmement juste. Si tu demandes à des gens de venir à Paris, tu leur offres des bureaux en plein cœur de Paris, ils ont largement le niveau de vie pour y vivre et donc profiter pleinement de la ville. C'est très différent de locaux en proche banlieue, qui en gros font que tu as tout les inconvénients de la région, sans pouvoir en avoir le style de vie des gens aisés. Par exemple si tu cherches à me recruter à NY tu auras certainement plus de chance si tu es dans le centre de Manhattan que dans le trou du cul du Queens ou du New Jersey. Et pour la même raison le bassin d'emploi remonte de la vallée vers San Francisco.

Le problème est que souvent les offres d'emplois sont plus intéressants à Paris que ce soit en diversité comme en qualité. Mais cela peut se faire ailleurs, Paris n'étant pas une condition indispensable à cette réalité.

Personne ne dit le contraire, c'est juste effectivement la réalité actuelle.

Questions:

• C'est quoi le but de ces bureaux ?
• Qui les fréquente tous les jours ?
  • Que font-ils ?
  • Où ont-ils besoin d'aller ?
  • Qui ont-ils besoin de rencontrer ?
• Qui les fréquente ponctuellement ?
  • Que font-ils ?
  • D'où viennent-ils ?

Après on pourra discuter du bien fondé de l’implantation. Choisir son point d’implantation c'est un compris entre être dans un bassin d'emploi qui répond à ton besoin, être accessible, pouvoir accéder aux autres, et le coût (on peut même rajouter attirer par son emplacement).

Dire qu'on peut tout faire n'importe où c'est de la connerie. Certaines choses se décentralisent, d'autres non. Certaines compétences peuvent se trouver partout, d'autres non. Certaines choses se ont besoin d'interaction physiques, d'autres non.

Enfin il y a un choix entre une vision à long terme, et les besoins du moment. Par exemple tu as besoin de monter une nouvelle équipe dans un domaine précis pour un projet critique. Tu utilises ton bureau d'une ville dont le bassin d'emploi correspond à ton projet, disons Londres pour du HFT par exemple, où le mets à Brest par ce qu'a long terme c'est mieux (et qui va être largement 3x moins cher) ?

Il ne faut pas oublier que les cds sont une grosse part de leurs revenus. Et d'ailleurs, ils sont de très bonnes qualités, avec des thèmes très sympas et des stickers qui vont avec ;)

C'est clair que j'utilise OpenBSD pour avoir des themes très sympas et des stickers plutôt qu'un OpenSSL non troué. Il faut savoir définir les priorités d'un projet et tenir la barre !

Google laisse 20% de leur temps a ses devis sur des projets perso ou open source

Dans un autre siècle oui, maintenant ca semblerait plutôt être 20% après tes 100%.

C'est bien tu as compris tous les mots. Tu es maintenant prêt pour créer ton exchange Bitcoin, cours chercher ton MongoDB et révolutionne l'histoire des catastrophes financières ;)

L'exemple classique du transfert d'argent entre 2 comptes :

transfertPognon a b somme = atomically $ do
  courantA <- readTVar a
  when (courantA < somme) retry
  courantB <- readTVar b
  writeTVar a (courantA - somme)
  writeTVar b (courantB + somme)

C'est niveau CS 101 mais tu devrais l'envoyer aux Jean Kevin de la nouvelle finance mondiale: Les exchanges Bitcoins. Ca fait au moins deux qui ferment et se font piller sur exactement cet exemple, et pleins d'autres ont eu le soucis.

Quand tu te dis que Bitcoin remet en cause tous les processus de consistance, de sécurité et d'exposition aux risque des banques/exchange classiques par ce l'eventual consistancy ça ne marche pas des masses sur des transaction anonymes. Et quand tu vois le niveau des gars qui arrivent à se vautrer sur une bête balance de compte… :P

Je n'arrive jamais a retrouver ce que je veux facilement, que ce soit un programme à lancer ou une fenêtre déjà ouverte. Au final je finis juste par lancer une console puis taper le nom du programme à lancer

Tu sais il suffit de faire "Windows" puis taper le nom ;)

Si tu n'as pas trouvé ca je te conseil vivement de lire la doc.

Porter des chaussettes et des sandales ne protège pas des balles.

Autrement si tu aides une agence gouvernementale à introduire une backdoor dans OpenSSL, je ne suis pas certain que ta nationalité change grand chose si tu décides de le révéler. Je penses que ta vie va bien se compliquer que tu sois citoyen US ou du Kirghizistan. Ca sera peut être un peu plus indirect c'est vrai.

Ben oui donc, il "suffit" d'être "position 3", non?

L’intérêt pour une SSII de mettre quelqu'un en forfait jour n'était pas clair du tout vu que j'avais zappé la partie forfait vu que part définition ces esclaves là tu ne les vois pas souvent.

Pour la régie aucun intérêt, la facturation client / SSII est fixe il vaut mieux avoir un autre gars placé qu'un qui bosse 16h par jour. Juridiquement ça expose à plus de risque aussi donc autant faire simple. Pour le forfait, oui exploiter sa main d’œuvre jusqu'à la moelle fait sens :p

Et cette idée de 48 K€ mini ne me semble pas trop délirante (il faut être payé en conséquence, et la on va vers 2x le salaire médian, pas idiot). Je m'étais plutôt braqué sur une généralisation de la question à toutes les SSII pour tout le monde (qui peuvent payer plus de 48 K€) que j'ai sans doute mal compris.

Oui pas de forfait jour en dessous de ce tarif (je crois que juridiquement tu peux faire des exception mais faut être débile pour signer). Clairement le deal est de la souplesse et une tolérance à la surcharge de la part de l'employé contre un bon fixe et un bonus plus ou moins négocié. Jusque là pas de soucis tant que les deux parties sont d'accord sur la charge de travail prévue. Le problème c'est que ce ne sera jamais écrit nulle part.

La modification vise à essayer de trouver un moyen pour faire rester cette souplesse dans le domaine du raisonnable. On bascule vite de la souplesse à l'exploitation sans pouvoir facilement tracer la ligne, ni trouver des mesures simples pour l'empêcher. La preuve la solution est assez pourrie. Dans le monde réel, elle a le seul mérite de rappeler que tu as le droit d'avoir une vie.

Perso je me demande si des forfaits heures à volume variables ne seraient pas une réponse plus adéquate même si encore une fois le décompte est inapplicable en pratique. Ça éviterait les 40-45h/semaine en moyenne qui se transforment en 80h. Si tu veux que je bosse plus annuellement, on renégocie le contrat ou tu paies en heure sup.

Mais encore une fois l'informatique n'est pas trop touchée puisque l'offre existe. Le meilleur moyen de punir un con reste de ne plus travailler pour lui pas de le forcer à appliquer à la loi.

et vois pas ce que le salaire vient faire la

Pour avoir un forfait jour il faut remplir l'une de ces deux conditions:
- Position 3 et donc mini 48K de fixe
- mini ~70k de fixe

Ce n'est pas pinailler, c'est juste la loi + convention collective. Aucun employeur ne sera assez con pour faire un contrat qui ne respect pas ca. Ca l'engagerait à payer toutes les heures sup si l'employé veut s'amuser.

Donc pour ceux qui se poserait la question, très simplement si tu ne remplis pas la première condition tu n'as pas un forfait jour. Par contre les forfaits heures sont extrêmement courant.

Et puis bon, quelqu'un qui me parle d'heures et de barème dont on se fou complet pour le boulot à faire, perso je me braque, je sens que le boulot va mal se passer et on va plus discuter de merdes légales que de faire le taf…

C'est un contrat que tu signes qui t'engage. Le choix est aussi simple que ça:
- Forfait d'heure à l'année: donc masse de travail relativement connue
- Forfait de jour: donc masse de travail inconnue que tu ne "peux pas" refuser.

Le tout c'est de comprendre sa situation, pour qui on travail, quel travail on fait, qu'est ce qu'on a en retour et faire un choix. Ce n'est pas emmerder les gens.

Tu remarqueras qu'à aucun moment j'ai dit que l'un était mieux que l'autre, ni qu'il fallait pinailler pour respecter l'un ou l'autre à la lettre.

Je rappelle simplement la problématique ouverte du forfait jour dont il est question dans le journal qui est qu'un salarié pour une rémunération fixe à une masse de travail potentiellement non bornée par autre chose que les 24h d'une journée. Trouver une solution intelligente et générale au problème n'est pas simple car comme toujours tu as des gens qui abusent des deux côtés. Et empêcher les abus sans limiter les autres n'est jamais simple.

Je ne suis pas plus que toi pour les lois stupides et perso je m'en balance grave, si t'abuses j'irais bosser ailleurs le marché le permet…

Tant que les gens confondront implication, productivité et qualité avec temps de présence…

Tu n'as jamais indiqué quelque chose comme 8h chaque jour reporté dans ton rapport mensuel d'activité de manière implicite ou explicite ? Non par ce que facturer au jour sans limite d'heure pour une SSII je vois pas bien l’intérêt. Au contraire le message est généralement de pas trop accepter de bosser plus. Si le client veut plus il paie plus.

Bon évidement si tu vends du forfait la logique s'inverse…

j'ai toujours eu des contrats en forfaits jours

Tu veux dire que même en tant que junior on t'a donné un barème > 3 et mini 48K de salaire ? …

L'autre SSII de merde dans ta ZAC sera ravie de te payer à prix d'or

Il y a des SSII qui font des forfaits jour ?

Des vrais, pas le forfait heure classique qu'on essaie de te faire croire que c'est un forfait jour au cas ou tu serais assez bête pour ne pas voir la différence. Perso j'ai pas souvenir d'avoir croisé des gens de SSII avec ce statut et ça ouvre clairement la porte aux conflits. La SSII a intérêt à facturer un max au client et donc facturer ce qui est réellement travaillé (ou placer un deuxième gars), mais si tu commences à décompter les heures de tes mecs en forfait jour pour les facturer il va se rendre compte qu'il se fait pigeonner avec une rémunération fixe contrairement à toi… De même pour la condition d'autonomie ca me parait un peu limite.

En général la carotte des forfaits jours c'est une bonne rémunération fixe et les bonus. La deuxième partie en SSII…

donc en gros, du vent, car en pratique si tu ne réponds pas mais que le boss veut ben… Tu seras au placard, poussé à démissionner et voila.

Ça permet aussi de remettre un peu les choses à plat et de rappeler aux gens qu'ils peuvent décrocher. Définir la limite dans un forfait-jour est très difficile.

Et au final, on donne du bashing à ceux qui lisent trop vite, une réputation pas terrible, pour un "gain" nul pour le salarié.

L'article est mal écrit. Cela ne concerne que les forfait-jour qui n'avaient aucune limite et qui ont été jugé illégaux en l'état.

Le forfait-jour c'est une rémunération fixe pour une charge et un volume de travail non bornée hormis un nombre de jours. Ça peut se passer très bien comme ouvrir la porte à absolument tout les abus. A voir si tu as une solution plus intelligente au problème. On peut les supprimer et passer aux heures sup mais ça risque de coûter très cher…