Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3890 connectés 

 


Sujet auquel vous répondez
Sujet : [blabla@olympe] Le topic du modo, dieu de la fibre et du monde
Jubijub

nraynaud a écrit :

au cours de mes googlings de go, j'ai trouvé un blogs qui disait qu'en fait les structures de concurrence de go sont trop lentes pour avoir une tonne de concurrence.
 
(sinon, j'ai pas bien compris la remarque, quelqu'un a mis une info derrière un paywall, google a été la chercher, et l'a affiché en même temps qu'un mur de pub qui va dans sa poche, et c'est moi qui cherche l'info qui suis hypocrite??? je cherche que des infos gratuites dans google, merci beaucoup, je trouve mes infos payantes autrement)


le snippet n'est pas une pub.
 
En gros : c'est pas parce que c'est pas un lien bleu standard que c'est forcément une pub :  
- toutes les zones de pubs ont une mention "Annonces / Ads" : si y'a pas la mention c'est du contenu organique, donc gratuit et sur lequel Google ne gagne pas d'argent
- les feature snippets ne sont pas des pubs
- c'est pas parce que ça permet d'acheter le produit que c'est forcément une pub (des fois on affiche juste des infos sur le produit, ou meme des offres si on pense qu'elles sont pertinentes)
 
 


Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse


[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 

Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
flo850 Et puis la praticité d'avoir le truc tout packagé dans un exécutable sans dépendances
Shinuza

el muchacho a écrit :


Je ne vois pas bien ce que ça apporte par rapport à du Python, dans ce cas.

Wait, t'as déjà essayé de faire des services réseaux (pas du http) avec Python? Non-blocking Avec de l'asynchronisme qui plus est?

masklinn

el muchacho a écrit :


Je ne vois pas bien ce que ça apporte par rapport à du Python, dans ce cas.


Objectivement, python est beaucoup plus gros et complexe, et créer des services réseaux qui gèrent la charge avec est pas trivial, asyncio est chiant et bordélique avec autant de footguns que go a lui tout seul, et n’existait pas quand go a été créé.

el muchacho


Non mais si le NoSQL n'apportait pas in fine les performances nécessaires dans les cas d'utilisation précis où c'est utilisé, ça n'aurait pas été inventé et ça ne serait pas l'outil de base des GAFA. C'est tout ce que je veux dire, rien de plus.

el muchacho

masklinn a écrit :


Non.  

Citation :

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.


Ils voulaient faire un langage sur lequel il est trivial d’onboarder et d’être productif et facile à reviewer.  
 
Il y a des pièges dedans mais fondamentalement go t’en as fait le tour en une matinée et tu peux commencer à coder des services réseaux dans l’après midi. De ce point de vue, c’est loin d’être un échec.  
 
Le but n’a jamais été « un C plus pratique », en tout cas pas dans le sens ou le reste du monde l’entend (coder des quenelles ou des libs réutilisables arbitrairement), tous les choix faits vont à l’opposée de cette idée. À dessein.


Je ne vois pas bien ce que ça apporte par rapport à du Python, dans ce cas.

koskoz

el muchacho a écrit :


Tu sais que le NoSQL ne se limite pas à MongoDB, hein ?


 
no shit

masklinn

el muchacho a écrit :


Tu sais que le NoSQL ne se limite pas à MongoDB, hein ?


 [:esrevni]

el muchacho

koskoz a écrit :


Ça fait longtemps que j'avais vu passer des benchs entre MongoDB et PostgreSQL mais c'était peut-être un peu biaisé vu que ça venait de compte Twitter de consultants Postgre [:greg2]


Tu sais que le NoSQL ne se limite pas à MongoDB, hein ?

nucl3arfl0

flo850 a écrit :

 

alors oui, mais combien de projet ont réellement besoin de scaler hors de l'echelle d'un SGBDR ? Ou plutôt pour combien de projet cet avantage est supérieur à celui d'assurer une cohérence des données

 

perso, le plus gros intérêt que je vois est pour de l'embarqué : synchroniser du NoSQL est beaucoup plus simple que du relationnel. A
u moins quand tu as un objet il est complet, alors qu'il y a souvent un ordre précis à avoir pour des données relationnelles no pété. Par contre, le volume de données est plus grand est la cohérence des données plus complexe à assurer


De mon expérience pro/perso, qui est plutôt limitée, j'ai pas vu beaucoup de cas où le NoSQL était utile sur la scalabilité (dans le sens où avant de mettre le RDBMS à genoux, il fallait y aller, c'était souvent l'application qui était mal branlée).
Quant à utiliser du NoSQL pour toute l'application, j'en ai jamais vu.

flo850

nucl3arfl0 a écrit :

L'intérêt du NoSQL est d'être très facilement scalable, ce qui est plus difficile avec un RDBMS


 
alors oui, mais combien de projet ont réellement besoin de scaler hors de l'echelle d'un SGBDR ? Ou plutôt pour combien de projet cet avantage est supérieur à celui d'assurer une cohérence des données  
 
perso, le plus gros intérêt que je vois est pour de l'embarqué : synchroniser du NoSQL est beaucoup plus simple que du relationnel. A
u moins quand tu as un objet il est complet, alors qu'il y a souvent un ordre précis à avoir pour des données relationnelles no pété. Par contre, le volume de données est plus grand est la cohérence des données plus complexe à assurer

Shinuza

koskoz a écrit :


 
Il y a encore des bonnes raisons d'utiliser du NoSQL maintenant que la hype est passé et qu'on s'est rendu compte que ce n'était pas plus perf que du RDMS [:petrus dei]


En dehors des perfs, c'est comme go, y'a des cas où ça a du sens d'utiliser ça plutôt qu'autre chose (à part mongo db)

nucl3arfl0 L'intérêt du NoSQL est d'être très facilement scalable, ce qui est plus difficile avec un RDBMS
hephaestos

DDT a écrit :


Mais c'est pas un peu du biais de sélection, vu votre politique quant aux langages autorisés?
 
Parce que plébiscité par rapport à devoir faire la même chose en C++, vs plébiscité dans l'absolu, c'est un peu différent. :D


 
C'est vrai. En même temps si je suis les discussions qui ont lieu ici, c'est comparé à C++, java et python, qui sont des langages autorisés. Mais effectivement, l'adoption en interne c'est une compétition un peu biaisée. On me demande, je réponds [:dks:1]

koskoz

el muchacho a écrit :


Où as-tu vu ça ?


 
Ça fait longtemps que j'avais vu passer des benchs entre MongoDB et PostgreSQL mais c'était peut-être un peu biaisé vu que ça venait de compte Twitter de consultants Postgre [:greg2]

el muchacho

koskoz a écrit :


Il y a encore des bonnes raisons d'utiliser du NoSQL maintenant que la hype est passé et qu'on s'est rendu compte que ce n'était pas plus perf que du RDMS [:petrus dei]


Où as-tu vu ça ?

Xavier_OM

DDT a écrit :


Mais c'est pas un peu du biais de sélection, vu votre politique quant aux langages autorisés?
 
Parce que plébiscité par rapport à devoir faire la même chose en C++, vs plébiscité dans l'absolu, c'est un peu différent. :D


 
Mais c'est génial votre astuce  [:merlin l'enchanteur]

DDT

hephaestos a écrit :


Pour répondre à la question de l'usage en interne, c'est un langage qui rencontre un franc succès et qui est largement plébiscité.


Mais c'est pas un peu du biais de sélection, vu votre politique quant aux langages autorisés?
 
Parce que plébiscité par rapport à devoir faire la même chose en C++, vs plébiscité dans l'absolu, c'est un peu différent. :D

koskoz

el muchacho a écrit :


Alors je ne prendrais pas le risque de partir sur du NoSQL, surtout sans expérience.


 
Il y a encore des bonnes raisons d'utiliser du NoSQL maintenant que la hype est passé et qu'on s'est rendu compte que ce n'était pas plus perf que du RDMS [:petrus dei]

Flaie manque juste quelques trucs pour rendre le langage agréable, mais sinon c'est pas non plus une purge
hephaestos Oui niveau philosophie, go remplit ses objectifs. On y fait des trucs simples, explicites. Le langage est tout entier tourné vers son style.  
 
Pour répondre à la question de l'usage en interne, c'est un langage qui rencontre un franc succès et qui est largement plébiscité.
nucl3arfl0

el muchacho a écrit :


Alors je ne prendrais pas le risque de partir sur du NoSQL, surtout sans expérience.


Après c'est un projet perso, qui n'a aucun objectif propre sauf me former/remettre à niveau.
Mais c'est sûr que j'ai pas envie d'y passer 90% de mon temps dessus.

masklinn

el muchacho a écrit :


En fait, Google ne peut pas le dire, mais c'est un échec massif, ce langage. Au départ, ils voulaient faire un "C plus pratique", puis rapidement, au vu des perfs qui n'étaient pas là et des restrictions, ça a changé d'objectif, c'est devenu une espèce de "Java plus sympa".


Non.  

Citation :

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.


Ils voulaient faire un langage sur lequel il est trivial d’onboarder et d’être productif et facile à reviewer.  
 
Il y a des pièges dedans mais fondamentalement go t’en as fait le tour en une matinée et tu peux commencer à coder des services réseaux dans l’après midi. De ce point de vue, c’est loin d’être un échec.  
 
Le but n’a jamais été « un C plus pratique », en tout cas pas dans le sens ou le reste du monde l’entend (coder des quenelles ou des libs réutilisables arbitrairement), tous les choix faits vont à l’opposée de cette idée. À dessein.

el muchacho

masklinn a écrit :


Nebula [:dawa]


Jamais entendu parler. :o

el muchacho

nucl3arfl0 a écrit :


Je travaille sur un proto et j'ai aucune idée du périmètre final du produit.
Ce qui veut dire qu'il y aura forcément des évolutions à prévoir dans le futur.
Peut-être que mon approche n'est pas adaptée, ou bien qu'au final, je me noie dans un verre d'eau.


Alors je ne prendrais pas le risque de partir sur du NoSQL, surtout sans expérience.

masklinn

el muchacho a écrit :


Youtube ? Tu rigoles, il y a des milliers de chaînes passionnantes et dont les productions n'ont pas d'équivalent ailleurs. Perso je suis abo à environ 300 chaînes et j'ai pas le temps de regarder tout ce qui sort.


Nebula [:dawa]

el muchacho

masklinn a écrit :


Concurrence facile oui mais safe non: tu peux balourder des pointeurs (donc partager de l’état mutable) à travers les channels, et comme ils sont lents il est fréquent d’utiliser des primitives plus bad niveau, et genre tu peux segfault si tu protèges pas bien tes accès aux hashmaps.  
 
D’ailleurs c’est marrant, comme ils ont vendu de la concurrence massive mais que les primitives suivent pas t’as un mode spécial pour essayer de toper les erreurs de concurrence au runtime, style UBSan mais pour les race conditions (techniquement c’est basé sur tsan).  
 
A la base ca a été fait pour écrire des petits services réseaux et les rendre faciles a déployer: tu peux gérer une chiée de connection en mode « thread per connection » avec les goroutines, le cross-compile est facile et la stdlib est très fournie en services réseau reimplementés en go, donc tu peux facilement compiler ton artefact et le balancer sur ton serveur et zou.


En fait, Google ne peut pas le dire, mais c'est un échec massif, ce langage. Au départ, ils voulaient faire un "C plus pratique", puis rapidement, au vu des perfs qui n'étaient pas là et des restrictions, ça a changé d'objectif, c'est devenu une espèce de "Java plus sympa".
Les benchmarks que j'en ai vus montrent que c'est un chouilla plus lent que le Java, et il y a moins de possibilités d'optimisation.
 
Je ne juge pas du coté sympa de la prog en Go, je n'en ai jamais fait (et ne compte pas en faire). Mais même si c'est moins lourdingue que le Java, ses caractéristiques et ce que tu en écris ici me font penser que ça n'est pas adapté pour des gros projets. Je me demande si c'est réellement utilisé chez Google en dehors de quelques outils internes.
Après pour faire du prototypage rapide et se rendre compte des problèmes qu'on va devoir surmonter, pourquoi pas, mais franchement, qui fait ça ?
 
 

Jubijub

nraynaud a écrit :

au cours de mes googlings de go, j'ai trouvé un blogs qui disait qu'en fait les structures de concurrence de go sont trop lentes pour avoir une tonne de concurrence.
 
(sinon, j'ai pas bien compris la remarque, quelqu'un a mis une info derrière un paywall, google a été la chercher, et l'a affiché en même temps qu'un mur de pub qui va dans sa poche, et c'est moi qui cherche l'info qui suis hypocrite??? je cherche que des infos gratuites dans google, merci beaucoup, je trouve mes infos payantes autrement)


le snippet n'est pas une pub.
 
En gros : c'est pas parce que c'est pas un lien bleu standard que c'est forcément une pub :  
- toutes les zones de pubs ont une mention "Annonces / Ads" : si y'a pas la mention c'est du contenu organique, donc gratuit et sur lequel Google ne gagne pas d'argent
- les feature snippets ne sont pas des pubs
- c'est pas parce que ça permet d'acheter le produit que c'est forcément une pub (des fois on affiche juste des infos sur le produit, ou meme des offres si on pense qu'elles sont pertinentes)
 
 

nucl3arfl0

el muchacho a écrit :


Tu oublies le modèle relationnel et tu réfléchis aux requêtes dont tu vas avoir le plus besoin, et tu modélises dans l'optique d'optimiser ces requêtes-là.


Je travaille sur un proto et j'ai aucune idée du périmètre final du produit.
Ce qui veut dire qu'il y aura forcément des évolutions à prévoir dans le futur.
Peut-être que mon approche n'est pas adaptée, ou bien qu'au final, je me noie dans un verre d'eau.

R3g

el muchacho a écrit :


Youtube ? Tu rigoles, il y a des milliers de chaînes passionnantes et dont les productions n'ont pas d'équivalent ailleurs. Perso je suis abo à environ 300 chaînes et j'ai pas le temps de regarder tout ce qui sort.


Youtube je regarde de temps en temps des concerts ou alors des trucs postés ici ou sur twitter, mais généralement j'ai pas la patience de regarder en entier.

el muchacho

R3g a écrit :


Disons qu'ils ont une valeur inférieure à ce que ça me couterait de regarder leurs pubs.


Youtube ? Tu rigoles, il y a des milliers de chaînes passionnantes et dont les productions n'ont pas d'équivalent ailleurs. Perso je suis abo à environ 300 chaînes et j'ai pas le temps de regarder tout ce qui sort.

el muchacho

nraynaud a écrit :

mais, on dirait que go c'est super lent [:pingouino]


C'est pas plus rapide que le Java et il y a moins d'opportunité de tuning qu'avec la JVM, en tout cas.

el muchacho

nucl3arfl0 a écrit :


En fait j'essaie de modéliser un truc relativement cons et je sais pas vraiment m'y prendre car je suis trop habitué au modèle relationnel.
J'ai regardé la doc aws, j'ai cherché un peu, mais ça répond pas exactement à mon problème  [:nucl3arfl0:4]  
Donc je cherchais un peu d'assistance pour m'aiguiller vers le bon chemin :D


Tu oublies le modèle relationnel et tu réfléchis aux requêtes dont tu vas avoir le plus besoin, et tu modélises dans l'optique d'optimiser ces requêtes-là.

Shinuza

Jubijub a écrit :


bon je suis un con de manager, mais j'ai jamais compris l'attrait pour Go :  
- y'a pas de syntactic sugar sympa comme dans Python ou TS, du coup ça fait jeune vieux langage
- c'est rapide, mais je pense que Java doit rester compétitif, et donc t'as plus rapide (C/C++/Rust), ou plus lent et plus expressif (Python, etc...)
- j'ai cru comprendre que c'était nativement plus simple de faire des app multithreadées safe, mais du  coup ça justifie tout un autre écosystème ?


- C'est pas délirant de livrer le langage avec peu de features syntaxiques et un format standard, je pense que ça a contribué à la popularité du langage.
- C'est le juste milieu qu'ils voulaient.
- Non. Il a su faire sa niche dans l'univers du networking, notamment pour la raison que tu cites et je suis pas sûr que ça soit pertinent de vouloir faire autre chose avec.
 
Je pense que si la gestion/l'intégration d'asyncio existait dans python quand Go est sorti, ça aurait très probablement changé la donne.

Jubijub

masklinn a écrit :


Concurrence facile oui mais safe non: tu peux balourder des pointeurs (donc partager de l’état mutable) à travers les channels, et comme ils sont lents il est fréquent d’utiliser des primitives plus bad niveau, et genre tu peux segfault si tu protèges pas bien tes accès aux hashmaps.

 

D’ailleurs c’est marrant, comme ils ont vendu de la concurrence massive mais que les primitives suivent pas t’as un mode spécial pour essayer de toper les erreurs de concurrence au runtime, style UBSan mais pour les race conditions (techniquement c’est basé sur tsan).

 

A la base ca a été fait pour écrire des petits services réseaux et les rendre faciles a déployer: tu peux gérer une chiée de connection en mode « thread per connection » avec les goroutines, le cross-compile est facile et la stdlib est très fournie en services réseau reimplementés en go, donc tu peux facilement compiler ton artefact et le balancer sur ton serveur et zou.


Ok...du coup ça apparait pas supérieur

 


Sinon cadeau pour toi : https://vm.tiktok.com/ZMeCHFUBa/ (un indice : only in Australia)

masklinn

Jubijub a écrit :


- j'ai cru comprendre que c'était nativement plus simple de faire des app multithreadées safe, mais du  coup ça justifie tout un autre écosystème ?


Concurrence facile oui mais safe non: tu peux balourder des pointeurs (donc partager de l’état mutable) à travers les channels, et comme ils sont lents il est fréquent d’utiliser des primitives plus bad niveau, et genre tu peux segfault si tu protèges pas bien tes accès aux hashmaps.  
 
D’ailleurs c’est marrant, comme ils ont vendu de la concurrence massive mais que les primitives suivent pas t’as un mode spécial pour essayer de toper les erreurs de concurrence au runtime, style UBSan mais pour les race conditions (techniquement c’est basé sur tsan).  
 
A la base ca a été fait pour écrire des petits services réseaux et les rendre faciles a déployer: tu peux gérer une chiée de connection en mode « thread per connection » avec les goroutines, le cross-compile est facile et la stdlib est très fournie en services réseau reimplementés en go, donc tu peux facilement compiler ton artefact et le balancer sur ton serveur et zou.

rufo

hephaestos a écrit :


Si tu y passes un peu de temps, c'est que tu y attribues un peu de valeur. Si tu n'y attribuais aucune valeur (ce qui est sous entendu dans le raisonnement initial), tu n'y perdrais pas ton temps.
 
Dit autrement : soit ces services ont une valeur, et on assume les voler en refusant de payer et de regarder la pub ; soit ils n'en ont pas, et on n'y va pas.


Moi, je dis qu'il faut faire un graph de Kano pour évaluer la valeur client :o Désolé, je viens de finir mon initiation au lean management  :whistle:

nraynaud et allez pas me dire que je veux tout gratos, j'ai récemment payé 40€ pour 2 putains de PDF, et une tonne de fric en bouquins.
nraynaud au cours de mes googlings de go, j'ai trouvé un blogs qui disait qu'en fait les structures de concurrence de go sont trop lentes pour avoir une tonne de concurrence.
 
(sinon, j'ai pas bien compris la remarque, quelqu'un a mis une info derrière un paywall, google a été la chercher, et l'a affiché en même temps qu'un mur de pub qui va dans sa poche, et c'est moi qui cherche l'info qui suis hypocrite??? je cherche que des infos gratuites dans google, merci beaucoup, je trouve mes infos payantes autrement)
Jubijub

nraynaud a écrit :

je déconne même pas, quand j'ai cherché le chiffre pour le post précédent, google m'a donné une réponse résumée, et les 2 premiers liens étaient illisibles:
https://imgur.com/a/r0osmUN
 
quand je dis que c'est une poubelle, je rigole pas.


- le premier c'est une feature snippet, beaucoup de gens adorent ça parce que ça t'extrait l'info sans avoir à cliquer. Je reconnais que la pertinence est aléatoire, et c'est pas ma feature préférée
- le second c'est un site de merde avec un paywall : pour le coup je suis pas certain de où c'est la faute de google (en l'occurence on a justement sorti l'info pertinente pour que tu n'aies pas à te taper le paywall
- 3ème idem, c'est un bon site statista, mais effectivement ils ont aussi un paywall (je note ici l'aspect rigolo : faut pas que le site ait de publicité, mais les paywall c'est le mal aussi. Donc en gros faut juste que le site fille ses données sans rien demander, parce que c'est pas du tout une vision idéaliste où moins de 1% des gens vont payer pour le service)
 

hephaestos a écrit :


Je sais pas si ça va te remonter le moral, mais je peux te dire ce que nous racontent les gens qui sont au dessus de la médiane ici : le sentiment [:anathema] de baisse de qualité des résultats de recherche viendrait essentiellement du fait que les gens qui ralent sont des utilisateurs assidus et à l'aise avec la technologie, et ne sont pas représentatifs. La plupart de nos utilisateurs, les cons, sont contents d'avoir des résultats premachés qui corrigent leurs erreurs.


+1000 : on est des vieux cons de l'internet ici, tout ce topic a connu Altavista et Yahoo, on sait tous coder (à des degrés divers j'en conviens :o ), je suis sur qu'on a tous tapé des chaines d'initialisation V92 de modem dans des champs abscons, et qu'on a fait du memmaker (voir compilé un kernel, monté une machine virtuelle, etc...)
C'est PAS DU TOUT le skillset de l'utilisateur lambda.
 

nraynaud a écrit :


en tout cas c'est pas une hypocrisie qui rapporte $269000 brouzoufs par personne.


c'est juste le profit, pas le CA (on devait deja être à 150milliard de CA à cette époque)
 

Flaie a écrit :

Les US c'est quand même in espèce de monde chelou a part, j'hallucine quand même comment tout le monde chie sur basecamp depuis ce matin j'ai quasi que ça dans ma timeline twitter, alors qu'il y'a rien de phénoménal quoi.
 
Le championnat de celui qui se plaindra/victimisera le plus quand même :o


oui j'étais surpris de voir aussi la shit storm. Toute la population LGBTQ+ + "allies" leur tombe dessus (y'a des points valables soulevés, genre une lesbienne qui parle de sa femme ouvertement, à quel moment ça devient de la politique ou pas, c'est une bonne question)
 

masklinn a écrit :


Ah mais je me moque pas du tout de toi, juste que ça confirme (encore) mes préjugés sur Go, genre mon peu d'appréciation pour "on compile ultra vite mais t'as que du -O0", donc yay t'attends pas la compilation et c'est toi qui joue l'optimising compiler (y compris inliner manuellement ou aller écrire leur assembleur custom à la con).


bon je suis un con de manager, mais j'ai jamais compris l'attrait pour Go :  
- y'a pas de syntactic sugar sympa comme dans Python ou TS, du coup ça fait jeune vieux langage
- c'est rapide, mais je pense que Java doit rester compétitif, et donc t'as plus rapide (C/C++/Rust), ou plus lent et plus expressif (Python, etc...)
- j'ai cru comprendre que c'était nativement plus simple de faire des app multithreadées safe, mais du  coup ça justifie tout un autre écosystème ?

ratibus

Dion a écrit :

https://twitter.com/rahsfan/status/ [...] 33792?s=21  [:rofl]  
 
Le management d’entreprise par Twitter  [:rofl]


https://mobile.twitter.com/rahsfan/ [...] 7321633792  :D

ratibus

hephaestos a écrit :


Je sais pas si ça va te remonter le moral, mais je peux te dire ce que nous racontent les gens qui sont au dessus de la médiane ici : le sentiment [:anathema] de baisse de qualité des résultats de recherche viendrait essentiellement du fait que les gens qui ralent sont des utilisateurs assidus et à l'aise avec la technologie, et ne sont pas représentatifs. La plupart de nos utilisateurs, les cons, sont contents d'avoir des résultats premachés qui corrigent leurs erreurs.


Et s'ils cliquent sur des liens payants c'est pas plus mal :d


PQ

flo850 a écrit :


Ça a probablement un lien avec l'image que la boîte a construit pendant des années  
 
Ça me semble quand même faire un changement notable


A voir.


Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)