En connaissant les adresse IP des serveurs robots de Google, il suffit de leur donner plus de contenu en se basant sur cette IP plutôt que sur le user agent. Et là je doute qu'il te faudra juste 30 minutes (sauf de nouveau si c'est codé avec de pieds de cul-de-jatte).
Et autrement si tu sais lire le code qui a été posté, la règle c'est de laisser l'accès à l'article selon deux critères: user-agent ou referer. Un dev qui sait pas lire et comprendre les specs, il code avec des pieds de cul-de-jatte hein…
Après comme déjà dit, je ne discute pas de l'approche puisque j'essaie de ne pas trop donner de leçon quand je ne connais rien au problème hormis mes certitudes du mec qui ne connait rien au problème.
Il y a un discours que je trouve totalement schizophrène sur deux points.
Le premier est la sécurité. Oui c'est mal fait, débile et je virerais l'équipe qui à fait ça. Maintenant pour les règles qu'ils ont, back ou front c'est exactement pareil. ça se contourne trivialement pour les deux cas. On adore rabâcher "la sécurité par l'obscurité c'est pas bien", maintenant passer ces règles côté serveur c'est juste cacher le code. Mais ca ne prendra que 30 minutes de plus à n'importe qui de motivé et pas trop con à trouver le truc. Y'a pas de mystère quand Google arrive à indexer le contenu d'une page et que toi tu n'y as pas accès…
Le deuxième est sur la protection des contenus. "Bouh les DRM c'est pas bien", par contre dès qu'on peut gratter car les mesures techniques pour protéger les contenus (et faire chier les utilisateurs) sont contournable on gratte.
Puis en soit, honnêtement, c’est vraiment mal fait
Ca me fait penser que dans certains pays il n'y a aucune barrière dans le métro et les gens paient pour le service qu'ils utilisent ! Quelle bande de blaireaux…
soit avec un message (messageBox, printf/cout) soit avec un code de retour donné.
Qui va demander une allocation mémoire… Oups. Qui va partir en deadlock… Oups.
Oui et non. Ça dépend de ton programme et de l’usage que tu souhaites faire de cette mémoire. Tu pourrais parfaitement attendre une quelques secondes avant de retenter… choisir un algo plus lent mais moins gourmand…
Tu es conscient que ca veut dire de faire un try catch (ou une ERRNOerie) avec un fallback utile autour de chaque appel de méthode qui peut faire une allocation mémoire ? Quand tu es au niveau lib C sur un filtre UNIX c'est trivial. Maintenant explique moi:
comment tu gères ca correctement sur un navigateur web.
en quoi le résultat est systématiquement mieux que le suicide pour l'utilisateur
en quoi ton soft est meilleur (il vient de prendre 200% de ligne de code avec des chemins d'exécution à la con à tester).
Comme d'hab il faut faire attention à ne pas généraliser. Mais plus tu vas dan les GUI, les applis haut niveau, et les trucs compliqués plus la gestion de ce type d'erreur perd de son intêret par rapport aux couts engendrés et à ce que ca apporte. Ca peut être beaucoup plus payant de prévoir des blocs fonctionnels autonomes qui se suicident et repartent tout seul quand quelque chose va mal. La cohérence est facile à tester et prise en compte dans le design et tu mets pas du code qui sert à rien partout.
Oui, enfin quand une application est en train de construire une représentation mémoire d’un svg dans l’espoir de l’afficher, on peut supposer qu’elle utilise une bonne part du CPU et qu’elle réalise la majorité des mallocs à ce moment là
Donc il n'y à aucune raison que l'OOM killer ne soit pas capable de définir une heuristique qui retrouve ce processus. Pour avoir un peu suivi les discutions sur l'OOM killer il y a quelques années, c'est visiblement pas si simple (le coup de shooter le processus qui à fait le plus d'alloc dans les dernières secondes a été testé, tout comme le plus gros et des dizaines de variantes).
Enfin, c’est la base… si un développeur ne sait pas gérer un malloc qui échoue, il devrait apprendre.
Il y a une différence entre la théorie et la pratique dans des vraies applis complexes. Et souvent la complexité ajoutée par gérer spécifiquement ce cas, fait que ca ne vaut pas le coup par rapport à un suicide simple. Ce type d'erreur peut facilement cascader et empêcher de faire toute chose utile ou même de notifier l'utilisateur que tu ne peux pas faire ce qu'il demande. À quoi bon tout saloper pour le même résultat au final ? Au pire tu vas même introduire des inconsistances à cause de ton code de rattrapage.
Et la on ne parle que du C. Dans la plupart des langages modernes tout le monde se balance de ce cas. J'ai jamais vu catcher des ErrorMemory, OutOfMemoryException ou je ne sais même pas quoi en js sauf dans des cas bien particuliers. Et vu que les libs ne le font pas non plus, tu pourrais wrapper chaque appel de méthode aussi.
Après ce n'est pas vrai pour tout. Il y a des cas où c'est faisable et à faire. Mais si tu tests avec les applis de ton desktop j'ai une petite idée du résultat.
Par défaut l'allocation mémoire de Linux est optimiste et permet d'allouer plus que la mémoire (RAM + swap) disponible. On suppose que les applis n'utiliseront peut être pas réellement la mémoire ou pas en même temps. Le noyau crash un process selon une heuristique quand la mémoire est vraiment utilisée.
En désactivant l'overcommit tu enlèves l'allocation optimiste. Tu fais retourner null à malloc (sbrk en fait) quand tu arrives à la limite. Le processus passe par la au mauvais momoent doit gérer ce cas (et dans 90% plus ou moins se suicider car il ne peut rien faire d'autre).
Dans les deux cas:
Tu vas remplir le swap avant que quoi ce soit se passe
L'application qui se fait butter (ou à qui on demande de se suicider) n'est pas forcément la bonne.
On en revient à une problématique récurrente des nouvelles technologies. Ce qui est favorisé, c'est toujours la facilité d'apprentissage et non la pertinence.
Tu parles de toi même là non ? Par ce que si tu veux une recherche décontextualisée, il suffit de lire l'aide et de décocher l'option… Le meilleur des deux mondes est disponible.
Être maître de la technologie c'est savoir utiliser rationnellement les outils que l'on met à ta disposition en fonction d'un besoin. Par rejeter en bloc un outil par peur. Après c'est des problèmes d'UI/UX pour savoir où et comment exposer telle ou telle fonction.
Les DB c'est clairement pas mon domaine. Mais si tu as des contraintes de dispo tu as déjà résolu le problème de "mon master par en vrille". Par ce que de toute facon il va exploser, devoir être mis à jour ou être injoignable un jour ou l'autre.
C'est exactement ce que j'opposais à zenitram. Ce n'est pas un marché de niche, les marchés de niche ont déjà trouvé leur solution. C'est utile pour tout les autres par contre… Pour qui ça peut être un mieux à pas cher, surtout dans les environnements exposés.
Après il faut aussi voir l'exposition de tes services. Une local privilege escalation sur une machine DB on s'en balance un peu à priori ca peut attendre la prochaine maintenance. Même pour un remote tu peux contrer le truc en attendant le slot.
Non, malgré le poids du navigateur, la consommation de RAM n'est toujours pas suffisamment élevée…
Faudrait te mettre à jour tu passes pour un charlot. Le problème actuel de Java (enfin de la plupart des JVM) est de ne pas être capable d'utiliser la RAM des machines.
Le hardware à un peu changé depuis 10 ans, la taille de heap max pas tellement…
Vu le domaine, c'est un marché de niche. Et c'est mieux d'avoir 70 clients à 1 Million que 1 million de client à 10€.
Ksplice, l'utilité évidente c'est pour les hosting mutualisés, hébergements pourri et assimilés. Bref des environnements exposés ou les solutions techniques des clients est cheap. Ce n'est clairement pas un marché de niche, c'est la majorité du marché.
Les marchés de niche qui ont vraiment besoin de dispo, ils s'ent balance. C'est déjà géré ailleurs dans l'archi. D'ailleurs tu passes déjà ton temps à couper des composants pour faire de la maintenance, des upgrades ou simplement pour vérifier que ca marche bien comme prévu. On coupe déjà des data-center entiers volontairement ou non…
Et pour les niches encore plus spécifiques (lire hors grosse infra web), c'est souvent tellement spécialisé et cloisonné que t'as moins de pression qu'un hosteur ultra-exposé ou que tu as des fenêtres d'upgrade/maintenance régulièrement.
Posté par ckyl .
En réponse à la dépêche Firefox habite au 21.
Évalué à 7.
Dernière modification le 16 mai 2013 à 23:14.
Il ne reste plus qu'à citer des exemples de ces sites qui soient pertinents/utiles à l'utilisateur, sans que l'entreprise dérive ensuite vers des méthodes de merde.
Tu sais ce n'est pas sale de chercher à comprendre ses utilisateurs et ses données pour essayer de leur servir des choses qui correspondent mieux à leurs attentes…
Ben oui, c'est les cookies, et c'est pas comme si on y avait pas déjà pensé
C'est sympathique de prendre les gens pour des cons comme ça…
mais si c'est pour fourguer ces données à qui sait quoi pour en faire quoi sait qui, si c'est ça le "tracking" alors oui je coche "non", et à tous les coups, et sur tous les sites, partout, tout le temps.
Il y a justement un gros travail de nettoyage du domaine pour clarifier les usages. Et ce genre d'initiative, même si elle est triviale et naïve fait bouger petit à petit les choses. Note que pour le moment les bons usages et les bons comportement sont plus limités que les "mauvais".
Par exemple actuellement en France, j'aurai besoin d'un opt-in pour utiliser tes données persos que j'ai en base pour te fournir un meilleur service, par contre je peux faire ce que je veux des données collectées…
Voilà une option qu'elle est bonne. Installer des virus à la main peut vite devenir fastidieux :)
Ca peut paraître con mais…
Tu as des sites qui veulent faire la recommandation sur leur contenu, et ont donc besoin de suivre ce que font leurs utilisateurs pour pouvoir prendre des décisions. Selon législation ca peut être soumis à un opt-in qui fait que finalement personne ne profite de la fonctionnalité. En général on abandonne direct le projet. Avoir un moyen générique d'indiquer qu'on accepte cela peut être intéressant.
Après bien sur le problème est que tu dires oui à un milliards de services sans aucune différence. Même pour un site donné, cocher l'opt-in peut servir à plusieurs choses derrières…
Un de mes collègue a aussi pu montrer un exemple de code multithreadé qui peut être « optimisé » en respectant les règles du modèle mémoire de Java, et qui malgré tout provoquera une exécution non conforme aux souhaits du programmeur.
Parce que le premier modèle est cassé, et que le second (qui date de 2005) permet des trucs qui en pratique autorisent de briser la causalité.
Tu as des resources sur le deuxième voir si il y a des choses que je ne connais pas ?
Il y a bien deux besoins qui existent. Le premier c'est pouvoir aller chercher la perf sur des problèmes très spécifiques ou y'a une poignée de mec qui vont pas faire de conneries et qui ecrivent des softs pour une plateforme donnée figée dans le marbre. Le deuxième c'est le reste du monde.
En pratique, ca permet à la majorité des programmeurs pas trop cons, de raisonner sur du code concurrent et d'écrire des programmes qui marchent et qui marchera encore quand tu changeras de proco.
Ça ne l’est pas s’il s’agit de faire dix lignes de codes pour corriger deux incohérences qui sont de toute façon des erreurs dans les données de départ et que tu pourrais corriger directement dedans.
C'est pour ca que je rebondissais simplement sur le "gros volumes". Corriger directement dans des flux qui font plusieurs centaines de millions de lignes par jour tu ne peux pas. D'ailleurs tu ne peux mêmes pas voir les incohérences si tu n'écris pas tout ce code qui anticipe les erreurs. Par ce que la regexp elle va pas matcher, mais tu nen as aucune idée, ni de pourquoi. Il se peut qu'il y ait plusieurs problèmes différents qui apparaissent et tu veux le savoir et le mesurer. Tu veux avoir une indication de quoi chercher. Faire ca a postériori c'est l'enfer et couteux.
Voilà, c'était simplement un petit conseil. Il y a de plus en plus de gens qui débutent dans le traitement des gros volumes et qui arrivent avec une bonne connaissance des shelleries. Je leur dis simplement de se méfier de awk & co. Ca marche super bien pour fouiller à l'arrache, mais leur tendence à la concision t'empêche de faire le vrai job après.
Après, pour la question du nombre de lignes de code, ça dépend aussi du choix de langage et d’implémentation qu’on fait.
Pas tant que ca, la taille du code vient du fait que tu as besoin de detecter, distinguer et remonter toutes les erreurs possibles.
Pour traiter un gros volume, c’est clair, mieux vaut passer un peu de temps pour bétonner son truc.
Et pour traiter un vrai gros volumes, tu passes 80% de ton temps à nettoyer les données et gérer les cas foireux.
Typiquement dans mon code ce que tu ferais à l'arrache en 1-10 lignes de awk/perl/sed se transforme en 100-2000 lignes de code.
Non. J'ai juste rapporté quelques nombres bruts, sans emphase éditoriale. L'April a fait de même.
Non. Tu as salopé tous les chiffres que tu donnes pour qu'ils perdent tout leur sens tu dis même des contre-vérité.
Entre autres choses, on note que le coût des logiciels privateurs est estimé (et probablement largement supérieur) à 1.5G pour l'État dont ~250M pour l'État lui même. Ce qui ferait dans les 50M par an. Mais 53.9M pour MS pour 2011.
Le 1.5G est une mesure sur 5 ans alors que le 250M est annuelle
L'état VS l'état, alors qu'entre les deux chiffres que tu donnes, il ne s'agit que d'une division par 5 (cf. ligne du dessus)
La séparation des coûts état VS collectivités à disparu
Le 50M on a aucun idée de ce que ca peut être. Il sort de nul part
Il y a un "mais" devant le chiffre de MS mais on a aucune idée d'a quoi il se rapporte.
Je préfère un journal bookmark ou un copier coller ;)
Si tu n'arrives pas à communiquer avec les autres c'est que tu n'es pas capable toi même de découper ton gros-machin en problèmes bien identifiés aux frontières claires. Si tu es un habitué à son ancienne prose, qui ne diffère pas de celle-ci, je pense sincèrement que faire ce genre de reflexion lui apportera plus qu'une quelconque réponse techniques.
Quand je lui dis "arrête le blabla et montre le code" c'est dans le même état d'esprit. Tu dois faire la même démarche pour trouver tes problèmes que pour l'expliquer aux autres. Identifie ce que tu veux mesurer/optimiser/comprendre. Isole le code, défini clairement les paramètres. Mets en place des métriques cohérentes et réfléchi aux façons de les valider. Si tu ne peux pas me sortir le code que je demande, alors c'est que le boulot n'est pas fait et que tu pédales beaucoup mais n'avance pas d'un poil.
À chaque fois qu'il parle d'un bench ou d'une implem tu sens la connerie arriver à 100km et ça fait souvent mouche. En le forçant à s'exprimer clairement il ne peut qu'avancer.
Ouai et le genre de réponse que je fais m'a fait réfléchir. Je m'en était pris des plus violentes et les "plus vieux", je dirais plus compétents qu'importe l'âge, avaient raison ;)
Le plus important dans l'informatique c'est de comprendre son problème et d'être capable de l'expliquer non ? Ca sert à rien de patauger dans la technique, les benchmarks, les optimisations si on n'est pas capable d'exprimer clairement les entrées, l'objectif et les contraintes de ce qu'on manipule. Ca lève un drapeau qu'on est en train de faire n'importe quoi.
[^] # Re: C'est légal
Posté par ckyl . En réponse au journal lemonde.fr ou l'abonnement au javascript. Évalué à 3.
Et autrement si tu sais lire le code qui a été posté, la règle c'est de laisser l'accès à l'article selon deux critères: user-agent ou referer. Un dev qui sait pas lire et comprendre les specs, il code avec des pieds de cul-de-jatte hein…
Après comme déjà dit, je ne discute pas de l'approche puisque j'essaie de ne pas trop donner de leçon quand je ne connais rien au problème hormis mes certitudes du mec qui ne connait rien au problème.
[^] # Re: C'est légal
Posté par ckyl . En réponse au journal lemonde.fr ou l'abonnement au javascript. Évalué à 3.
Par compétant tu veux dire un qui comprend que le problème viens de la règle business pas de l'implémentation en JS ?
[^] # Re: C'est légal
Posté par ckyl . En réponse au journal lemonde.fr ou l'abonnement au javascript. Évalué à 7.
Il y a un discours que je trouve totalement schizophrène sur deux points.
Le premier est la sécurité. Oui c'est mal fait, débile et je virerais l'équipe qui à fait ça. Maintenant pour les règles qu'ils ont, back ou front c'est exactement pareil. ça se contourne trivialement pour les deux cas. On adore rabâcher "la sécurité par l'obscurité c'est pas bien", maintenant passer ces règles côté serveur c'est juste cacher le code. Mais ca ne prendra que 30 minutes de plus à n'importe qui de motivé et pas trop con à trouver le truc. Y'a pas de mystère quand Google arrive à indexer le contenu d'une page et que toi tu n'y as pas accès…
Le deuxième est sur la protection des contenus. "Bouh les DRM c'est pas bien", par contre dès qu'on peut gratter car les mesures techniques pour protéger les contenus (et faire chier les utilisateurs) sont contournable on gratte.
[^] # Re: C'est légal
Posté par ckyl . En réponse au journal lemonde.fr ou l'abonnement au javascript. Évalué à 10.
Ca me fait penser que dans certains pays il n'y a aucune barrière dans le métro et les gens paient pour le service qu'ils utilisent ! Quelle bande de blaireaux…
[^] # Re: Malloc Linux
Posté par ckyl . En réponse au journal Où il est question de D3, des communes de France et des performances SVG des moteurs de rendu. Évalué à 4.
Qui va demander une allocation mémoire… Oups. Qui va partir en deadlock… Oups.
Tu es conscient que ca veut dire de faire un try catch (ou une ERRNOerie) avec un fallback utile autour de chaque appel de méthode qui peut faire une allocation mémoire ? Quand tu es au niveau lib C sur un filtre UNIX c'est trivial. Maintenant explique moi:
Comme d'hab il faut faire attention à ne pas généraliser. Mais plus tu vas dan les GUI, les applis haut niveau, et les trucs compliqués plus la gestion de ce type d'erreur perd de son intêret par rapport aux couts engendrés et à ce que ca apporte. Ca peut être beaucoup plus payant de prévoir des blocs fonctionnels autonomes qui se suicident et repartent tout seul quand quelque chose va mal. La cohérence est facile à tester et prise en compte dans le design et tu mets pas du code qui sert à rien partout.
[^] # Re: Malloc Linux
Posté par ckyl . En réponse au journal Où il est question de D3, des communes de France et des performances SVG des moteurs de rendu. Évalué à 4. Dernière modification le 21 mai 2013 à 18:32.
Donc il n'y à aucune raison que l'OOM killer ne soit pas capable de définir une heuristique qui retrouve ce processus. Pour avoir un peu suivi les discutions sur l'OOM killer il y a quelques années, c'est visiblement pas si simple (le coup de shooter le processus qui à fait le plus d'alloc dans les dernières secondes a été testé, tout comme le plus gros et des dizaines de variantes).
Il y a une différence entre la théorie et la pratique dans des vraies applis complexes. Et souvent la complexité ajoutée par gérer spécifiquement ce cas, fait que ca ne vaut pas le coup par rapport à un suicide simple. Ce type d'erreur peut facilement cascader et empêcher de faire toute chose utile ou même de notifier l'utilisateur que tu ne peux pas faire ce qu'il demande. À quoi bon tout saloper pour le même résultat au final ? Au pire tu vas même introduire des inconsistances à cause de ton code de rattrapage.
Et la on ne parle que du C. Dans la plupart des langages modernes tout le monde se balance de ce cas. J'ai jamais vu catcher des ErrorMemory, OutOfMemoryException ou je ne sais même pas quoi en js sauf dans des cas bien particuliers. Et vu que les libs ne le font pas non plus, tu pourrais wrapper chaque appel de méthode aussi.
Après ce n'est pas vrai pour tout. Il y a des cas où c'est faisable et à faire. Mais si tu tests avec les applis de ton desktop j'ai une petite idée du résultat.
[^] # Re: Malloc Linux
Posté par ckyl . En réponse au journal Où il est question de D3, des communes de France et des performances SVG des moteurs de rendu. Évalué à 5.
Tu supposes deux choses pas forcément vraies:
[^] # Re: Malloc Linux
Posté par ckyl . En réponse au journal Où il est question de D3, des communes de France et des performances SVG des moteurs de rendu. Évalué à 8.
Pas du tout.
Par défaut l'allocation mémoire de Linux est optimiste et permet d'allouer plus que la mémoire (RAM + swap) disponible. On suppose que les applis n'utiliseront peut être pas réellement la mémoire ou pas en même temps. Le noyau crash un process selon une heuristique quand la mémoire est vraiment utilisée.
En désactivant l'overcommit tu enlèves l'allocation optimiste. Tu fais retourner null à malloc (sbrk en fait) quand tu arrives à la limite. Le processus passe par la au mauvais momoent doit gérer ce cas (et dans 90% plus ou moins se suicider car il ne peut rien faire d'autre).
Dans les deux cas:
[^] # Re: Titre racoleur, vidéo intéressante.
Posté par ckyl . En réponse au journal Le succès de Google est-il mathématique?. Évalué à 2.
Tu parles de toi même là non ? Par ce que si tu veux une recherche décontextualisée, il suffit de lire l'aide et de décocher l'option… Le meilleur des deux mondes est disponible.
Être maître de la technologie c'est savoir utiliser rationnellement les outils que l'on met à ta disposition en fonction d'un besoin. Par rejeter en bloc un outil par peur. Après c'est des problèmes d'UI/UX pour savoir où et comment exposer telle ou telle fonction.
[^] # Re: et quid de Ksplice ?
Posté par ckyl . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 2.
Les DB c'est clairement pas mon domaine. Mais si tu as des contraintes de dispo tu as déjà résolu le problème de "mon master par en vrille". Par ce que de toute facon il va exploser, devoir être mis à jour ou être injoignable un jour ou l'autre.
C'est exactement ce que j'opposais à zenitram. Ce n'est pas un marché de niche, les marchés de niche ont déjà trouvé leur solution. C'est utile pour tout les autres par contre… Pour qui ça peut être un mieux à pas cher, surtout dans les environnements exposés.
Après il faut aussi voir l'exposition de tes services. Une local privilege escalation sur une machine DB on s'en balance un peu à priori ca peut attendre la prochaine maintenance. Même pour un remote tu peux contrer le truc en attendant le slot.
[^] # Re: L'effet du web
Posté par ckyl . En réponse au journal Intégrer scoreserver en ajax. Évalué à 3.
Faudrait te mettre à jour tu passes pour un charlot. Le problème actuel de Java (enfin de la plupart des JVM) est de ne pas être capable d'utiliser la RAM des machines.
Le hardware à un peu changé depuis 10 ans, la taille de heap max pas tellement…
[^] # Re: et quid de Ksplice ?
Posté par ckyl . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 4.
Ksplice, l'utilité évidente c'est pour les hosting mutualisés, hébergements pourri et assimilés. Bref des environnements exposés ou les solutions techniques des clients est cheap. Ce n'est clairement pas un marché de niche, c'est la majorité du marché.
Les marchés de niche qui ont vraiment besoin de dispo, ils s'ent balance. C'est déjà géré ailleurs dans l'archi. D'ailleurs tu passes déjà ton temps à couper des composants pour faire de la maintenance, des upgrades ou simplement pour vérifier que ca marche bien comme prévu. On coupe déjà des data-center entiers volontairement ou non…
Et pour les niches encore plus spécifiques (lire hors grosse infra web), c'est souvent tellement spécialisé et cloisonné que t'as moins de pression qu'un hosteur ultra-exposé ou que tu as des fenêtres d'upgrade/maintenance régulièrement.
[^] # Re: L'effet du web
Posté par ckyl . En réponse au journal Intégrer scoreserver en ajax. Évalué à 2.
Bin non tu comprends pas le challenge de réussir à faire tourner un jeu type 1985 et 1990 quand plus de 15 lois de moore sont passées !
[^] # Re: Indiquer aux sites que je souhaite être pisté
Posté par ckyl . En réponse à la dépêche Firefox habite au 21. Évalué à 7. Dernière modification le 16 mai 2013 à 23:14.
Tu sais ce n'est pas sale de chercher à comprendre ses utilisateurs et ses données pour essayer de leur servir des choses qui correspondent mieux à leurs attentes…
[^] # Re: Indiquer aux sites que je souhaite être pisté
Posté par ckyl . En réponse à la dépêche Firefox habite au 21. Évalué à 1.
C'est sympathique de prendre les gens pour des cons comme ça…
Il y a justement un gros travail de nettoyage du domaine pour clarifier les usages. Et ce genre d'initiative, même si elle est triviale et naïve fait bouger petit à petit les choses. Note que pour le moment les bons usages et les bons comportement sont plus limités que les "mauvais".
Par exemple actuellement en France, j'aurai besoin d'un opt-in pour utiliser tes données persos que j'ai en base pour te fournir un meilleur service, par contre je peux faire ce que je veux des données collectées…
[^] # Re: Indiquer aux sites que je souhaite être pisté
Posté par ckyl . En réponse à la dépêche Firefox habite au 21. Évalué à 0.
Ca peut paraître con mais…
Tu as des sites qui veulent faire la recommandation sur leur contenu, et ont donc besoin de suivre ce que font leurs utilisateurs pour pouvoir prendre des décisions. Selon législation ca peut être soumis à un opt-in qui fait que finalement personne ne profite de la fonctionnalité. En général on abandonne direct le projet. Avoir un moyen générique d'indiquer qu'on accepte cela peut être intéressant.
Après bien sur le problème est que tu dires oui à un milliards de services sans aucune différence. Même pour un site donné, cocher l'opt-in peut servir à plusieurs choses derrières…
[^] # Re: Ai-je bien compris ?
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Ca m'intéresse si tu l'as sous le coude.
[^] # Re: Ai-je bien compris ?
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 3.
Oui
Tu as des resources sur le deuxième voir si il y a des choses que je ne connais pas ?
Il y a bien deux besoins qui existent. Le premier c'est pouvoir aller chercher la perf sur des problèmes très spécifiques ou y'a une poignée de mec qui vont pas faire de conneries et qui ecrivent des softs pour une plateforme donnée figée dans le marbre. Le deuxième c'est le reste du monde.
En pratique, ca permet à la majorité des programmeurs pas trop cons, de raisonner sur du code concurrent et d'écrire des programmes qui marchent et qui marchera encore quand tu changeras de proco.
[^] # Re: Ai-je bien compris ?
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Et c'est là que tu te dis que pour 99% du code que tu écris tu es content d'utiliser un langage qui défini un memory model.
[^] # Re: Et?
Posté par ckyl . En réponse au journal 1.5 Milliards dépensés par l'État dans du non libre. Évalué à 4.
(250 + 50) * 5
Merci de confirmer qu'il a tellement salopé les chiffres que tu n'es même pas capable de retrouver ca. Tu rajoutes une ligne à mon commentaire.
[^] # Re: Perl
Posté par ckyl . En réponse à la dépêche Sortie de GNU Awk 4.1.0. Évalué à 3.
Absolument rien.
C'est pour ca que je rebondissais simplement sur le "gros volumes". Corriger directement dans des flux qui font plusieurs centaines de millions de lignes par jour tu ne peux pas. D'ailleurs tu ne peux mêmes pas voir les incohérences si tu n'écris pas tout ce code qui anticipe les erreurs. Par ce que la regexp elle va pas matcher, mais tu nen as aucune idée, ni de pourquoi. Il se peut qu'il y ait plusieurs problèmes différents qui apparaissent et tu veux le savoir et le mesurer. Tu veux avoir une indication de quoi chercher. Faire ca a postériori c'est l'enfer et couteux.
Voilà, c'était simplement un petit conseil. Il y a de plus en plus de gens qui débutent dans le traitement des gros volumes et qui arrivent avec une bonne connaissance des shelleries. Je leur dis simplement de se méfier de awk & co. Ca marche super bien pour fouiller à l'arrache, mais leur tendence à la concision t'empêche de faire le vrai job après.
Pas tant que ca, la taille du code vient du fait que tu as besoin de detecter, distinguer et remonter toutes les erreurs possibles.
[^] # Re: Perl
Posté par ckyl . En réponse à la dépêche Sortie de GNU Awk 4.1.0. Évalué à 3.
Et pour traiter un vrai gros volumes, tu passes 80% de ton temps à nettoyer les données et gérer les cas foireux.
Typiquement dans mon code ce que tu ferais à l'arrache en 1-10 lignes de awk/perl/sed se transforme en 100-2000 lignes de code.
[^] # Re: Et?
Posté par ckyl . En réponse au journal 1.5 Milliards dépensés par l'État dans du non libre. Évalué à 10.
Non. Tu as salopé tous les chiffres que tu donnes pour qu'ils perdent tout leur sens tu dis même des contre-vérité.
Je préfère un journal bookmark ou un copier coller ;)
[^] # Re: Ai-je bien compris ?
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 5.
C'est exactement ce que je dis.
Si tu n'arrives pas à communiquer avec les autres c'est que tu n'es pas capable toi même de découper ton gros-machin en problèmes bien identifiés aux frontières claires. Si tu es un habitué à son ancienne prose, qui ne diffère pas de celle-ci, je pense sincèrement que faire ce genre de reflexion lui apportera plus qu'une quelconque réponse techniques.
Quand je lui dis "arrête le blabla et montre le code" c'est dans le même état d'esprit. Tu dois faire la même démarche pour trouver tes problèmes que pour l'expliquer aux autres. Identifie ce que tu veux mesurer/optimiser/comprendre. Isole le code, défini clairement les paramètres. Mets en place des métriques cohérentes et réfléchi aux façons de les valider. Si tu ne peux pas me sortir le code que je demande, alors c'est que le boulot n'est pas fait et que tu pédales beaucoup mais n'avance pas d'un poil.
À chaque fois qu'il parle d'un bench ou d'une implem tu sens la connerie arriver à 100km et ça fait souvent mouche. En le forçant à s'exprimer clairement il ne peut qu'avancer.
[^] # Re: Ai-je bien compris ?
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 6. Dernière modification le 15 mai 2013 à 13:14.
Ouai et le genre de réponse que je fais m'a fait réfléchir. Je m'en était pris des plus violentes et les "plus vieux", je dirais plus compétents qu'importe l'âge, avaient raison ;)
Le plus important dans l'informatique c'est de comprendre son problème et d'être capable de l'expliquer non ? Ca sert à rien de patauger dans la technique, les benchmarks, les optimisations si on n'est pas capable d'exprimer clairement les entrées, l'objectif et les contraintes de ce qu'on manipule. Ca lève un drapeau qu'on est en train de faire n'importe quoi.