barmic 🦦 a écrit 5976 commentaires

Le contrôle d'une population par la peur et le totalitarisme a des limites, pleins de limites. Alors que contrôler une population par ses besoins,en construisant ses envies, on en a des exemples tous les jours. C'est bien plus insidieux et on peut facilement se laisser aller au confort que ça procure.

C'est une discussion assez classique, tu trouveras pleins de choses sur internet. Perso j'aime bien "Se distraire à en mourir" de Neil Postman.

Ça n'enlève rien à 1984, c'est juste de l'agiter comme un épouvantail qui m'a fait réagir.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Non, parce que la structure du problème fait qu'un réseau fédéré comme l'e-mail se prête beaucoup mieux à la co-existence de plusieurs acteurs. Ils peuvent s'échanger des données, il n'existe pas d'authentification unique des utilisateurs (d'où les problèmes de l'e-mail, d'ailleurs), etc.

Si un acteur fait 80% des adresses mails et refuse les mails sont implémentation des protocoles sera le standard quelque soit l'avis de l'IETF ou sa pertinence. On peut imaginer pleins de problèmes de ce genre et il est bien plus facile de changer de moteur de recherche que de d'hébergeur email.

Genre la violence que ça a été contre Microsoft ? LOL.

Trop d'arguments. Intéresse toi au sujet plutôt que de le survoler. Regarde ce qui est arrivé à AT&T par exemple. Il me semble que Microsoft c'était plus un abus de position dominante qu'un monopole.

Il faut l'interdire.

Va au plus simple définit une liste des choses autorisées. C'est ironique de voir quelqu'un qui interdit tout ce qui ne peut pas contrôler, tout ce qui ne suit pas certains de ses principes, citer Orwel. En vrai Orwel avait tort, c'est un fait. C'est Huxley qui a décrit quelquechose de bien plus réaliste.

C'est pareil pour toutes les choses qui ont une architecture non-fédérée en général. Le modèle fédéré n'est pas seulement bon pour la diversité technique, mais pour les libertés fondamentales également.

Tout comme le copyleft doit être partagé pour être solide, une fédération doit éviter les positions dominantes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ce qui a tendance à ralentir vim, c'est les plugins qui ne sont pas asynchrones (ou qui ne l'ont pas était pendant longtemps).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Une fonction que j'utilise pas mal est de lancer un "make" ou équivalent dans un terminal vim. Ce qui permet à vim de parser la sortie du make et de me surligner les erreurs dans les fichiers ouverts.

Au cas où, la commande make de base pour ça (en tout cas dans mon vim sans plugin) c'est :make (et ça ne lance pas forcément make).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les bouts de servo qui ont étaient mergés dans gecko le seront toujours, mais il n'y a plus d'employé Mozilla qui travaille sur servo. Donc il y a peu de chance que ce genre de cherry-pick arrive de nouveau. Après ça ne veux pas dire non plus que Mozilla ne va plus utiliser rust, maus servo n'est plus l'incubateur tel qu'il a pu l'être ces dernières années.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'adore VIM et je ne suis pas contre l'approche de MS d'utiliser un "serveur" pour mutualiser le code d'assistance au language et le debugging mais je trouve tout ça lourdingue

En plus de mutualiser le code, ça permet aux développeurs de langage de fournir leur gestion sans avoir à s'interfacer avec tous les éditeurs existant et à ne pas dépendre des release de ceux-ci.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

À la linux fundation

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ils ont viré toute l'équipe cet été. Quand tu réduit tes effectifs c'est souvent la R&D qui part en premier.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Non, j'y ai bien réfléchi, et pour moi la seule solution est d'interdire les moteurs généralistes. Je veux bien discuter si quelqu'un a une meilleure idée…

Ton problème ce n'est pas les moteurs généralistes donc oui c'est une mauvaise idée qui est en plus inefficace :)

Dans la situation « il y a un moteur de recherche hégémonique », le problème ce n'est pas la partie « moteur de recherche », mais bien « hégémonique ». J'en veux pour preuve qu'on pourrait avoir la même conversation au sujet de gmail par exemple.

Et ça tombe bien, parce que ça fait longtemps qu'on sait que les situations de monopole c'est pourri et il y a des lois pour ça. Il y a une procédure en cours là dessus. Je te laisse te renseigner sur l'histoire de la lutte contre les monopoles aux USA pour voir la violence que ça peut avoir.

L'intérêt c'est que ça marchera aussi pour les mails, pour la vente en ligne d'Amazon,… Sans avoir besoin d'interdire, les mails, la vente en ligne, etc.

Edit: après on pourrait règlementer le fait de crawler le web. Pour ne pas que ça devienne une activité continue qui consomme énormément de ressources (un peu comme la chasse), mais c'est plus dans une optique écologiste qu'anti-monopole.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Merci pour ton journal

• la commande :term (ou :terminal) pour faire un split du buffer actuel et afficher un buffer avec un terminal. C’est très pratique pour rester avec la session vim ouverte avec tous les fichiers en cours de modification et pouvoir lancer quelques commandes git, meson ou ninja.

J'ai jamais trop compris l'intérêt. Tous les éditeurs mettent à un moment ou à un autre en avant ce genre de fonctionnalité. J'utilise énormément le terminal et je n'ai jamais vu de problème à utiliser mon urxvt. Pour un vim un Ctrl+z/fg ou un changement d'onglet de mon terminal font très bien l'affaire.

"+y (pour copier depuis vim vers le presse-papier graphique)…

Je devrais prendre l'habitude de l'utiliser mon :r!xclip -o est un peu bourrin.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La terminaison TLS positionne les entêtes qui t'intéresse (et vire les éventuelles passé par un client coquin).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne suis pas d'accord :)

• asynchronisme : on lance une tache donc on ne connait pas la durée qui va s'exécuter en même temps qu'une autre : par ex, interroger une api.
• parallélisation : on veut réduire une tache en la fractionnant en n sous ensembles qui s’exécutent en même temps : par ex convertir une vidéo couleur en n&b : on peut découper la vidéo en 4 morceaux de même durée, appliquer l'algo sur chacun des morceaux et quand tous sont fini on ré-assemble le tout.

Alors en soit oui, mais il y a des amalgames. La parallélisation est le fait de faire plusieurs choses en même temps et l'asynchronisme est le fait de gérer le décallage temporel qu'il peut y avoir entre 2 évènements. J'aime bien parler de réactif pour l'engouement actuel. Il s'agit de considérer toutes tes IO selon des paradigmes asynchrones supprimant tout blocage.

Pour ces 2 problématiques, on peut utiliser aussi bien des thread, des green thread ou des process.

Pour la parallélisation oui, pour du réactif les threads et process sont de piètres palliatifs.

La diff entre thread et process : le thread utilise une mémoire partagé, les processus des espaces mémoires diff.
En terme de rapidité, ils sont sensiblement équivalent (si on est pointilleux, non car la création d'un process à un coût au lancement qui est en plus pas identique selon l'OS utilisé) mais le processus est plus consommateur en mémoire. (ce qui n'est pas forcément un soucis si on la ram suffisante)
Le thread a un défaut majeur : il partage ça mémoire et donc 2 taches ne doivent pas écrire sur le même espace en même temps.

Avoir la RAM suffisante est vraiment un palliatif quand on compare au résultats des solutions réactives et tu es face à un problème de taille : la multiplication de tes threads ou processus multiplie les commutations de contexte. Donc plus tu as de clients plus tu passe une proportion de ton temps dans tes commutations de contexte. Entre ça et la RAM qui va avec c'est très dommageable, pour les gros car ce sont des serveurs en plus à avoir et pour les petits parce que ça empêche de fonctionner correctement sur les les plus petites machines.

Les raisons techniques sont réelles mais c'est pas non plus dramatique de s'en passer.

La différence est drastique.

Par ex, ton navigateur Chrome ou Firefox fait de l'asynchrone en utilisant un process par onglet (mais souvent plusieurs threads dans ce même onglet) : dans l'absolu, ce n'est pas parfait.

Ils ont d'autres contraintes. Ils ont par exemple besoin de garantir qu'un onglet n'accède pas aux données d'un autre onglet. Le fonctionnement des greens threads pose aussi des problèmes quand tu exécute du code qui n'est pas à toi.

Si les green thread ne sont pas disponibles, et qu'on veut faire de l'asynchrone ou de la parallélisation, il faut trancher entre thread ou process

Tu te fourvoie sur les greens threads, ils ne sont pas vraiment fais pour la parallélisation et ce ne sont pas les meilleurs pour ça.

Le principe derrière réactif dont je parlais plus haut c'est d'avoir un pattern reactor. Tu as une boucle d'évènements¹ et tu les traite l'un après l'autre sans avoir de thread (et encore moins de processus) entre la boucle d'évènement et le traitement. Tu as une boucle par CPU et une file d'évènements devant. Chaque IO doit passer par cette boucle d'évènements. Ça c'est l'interne, l'implémentation, c'est du traitement coopératif, on ne préempte pas c'est toi qui laisse la main. Évidement il ne faut pas être être CPU bound (sinon tu as besoin de paralléilisation) mais IO bound.

POE et twisted te montrent assez directement ce paterne. Mais tu as d'autres API qui l'encapsule et t'aide à t'en servir. C'est ça les green thread. Chaque appel qui paraît bloquant est en fait implémenté de façon asynchrone et est l'occasion de passer la main à l'évènement suivant. Mais il y en a d'autres comme les acteurs ou rx par exemple.

Pour en revenir à PHP, je ne vois pas pourquoi l'asynchronisme ou la parallélisation n'aurait pas d'utilité, peut importe le moyen employé ?

En php tu ne gère pas un serveur qui reçois des requêtes que tu dois traiter. Ton code est instancié pour chaque requête. C'est la stack qui s'occupe de ça pour toi. Tu as différentes façon de lancer ton code PHP ce n'est pas lié à ta version de php (pour pouvoir être réactif il faut effectivement ajouter des choses dans le langage). Pour le parallélisme, il est par essence massivement parallèle. Tu peut avoir des besoin de parallélisation en plus, mais en soit c'est rare et c'est dangereux de faire du parallélisme par requête.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

asyncio c'est plus du "green threading" mais y'avait déjà la possibilité de faire des thread avec verrou ou du multiprocessing bien avant.

Ah ah. Oui d'accord. Mais ça on s'en fout et ça n'a pas grand intérêt en PHP. Quand on parle d'async, ce qui a de l'engouement c'est pas le multiprocessing. Toute le monde sait en faire et php est probablement bien mieux capable de paralléliser que python et le gil.

Non ce qui intéresse les gens c'est d'avoir des IO asynchrone. L'idée ce n'est pas de faire du parallélisme mais de multiplexer les IO à bas coup (sans utiliser des threads "lourd" et encore moins faire du multiprocessing).

Twisted c'est plus une couche réseau à de l'async.

C'est précisément ce qui est recherché quand on parle d'asynchrone.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je n'aime pas le turquoise, ça n'en fais pas une mauvaise couleur.

mais si tout le monde s'habillait en turquoise, ça ne te chatouillerais pas de le dire ?

Tu le ressent quand un site est en PHP ? Pas moi. Je n'ai pas particulièrement à expliquer aux gens comment s'habiller.

sortez un peu de votre périmètre de confort et arrêtez de jouer avec votre nombril !

Il me semble bien moins confortable et nombriliste d'avoir un regard curieux sur quelque chose qu'on apprécie pas à priori que de cracher dessus.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

TypeScript et Rust ont a mon sens suffisamment d'arguments pour représenter le futur sans se cacher sous un effet de mode.

Ce n'est pas ce que j'ai voulu dire. C'est leur publicité qui est un biais actuel. Comme go l'a eu avant et scala aussi par exemple. Ils ont une place, mais du fait de l'engouement qu'ils produisent ils sont surexposés. Ça contribue à leur créer une place d'ailleur (et c'est le cycle normal).

Ces technos sont faites pour des web apps, pas vraiment des sites web. (par exemple, wikipédia, des sites vitrines en wordpress n'en ont a pas besoin)

Il est question des parts de framework dans le navigateur dans le web publique, c'est bien explicité.

Pleins de boites vont faire des apps webs sans que ça soit forcément visibles (intranet par exemple) donc ça représente une partie de l'iceberg.

C'est forcément une inconnue, mais amha soit il y a encore plus de latence car moins d'investissement soit c'est du même ordre.

Enfin, faudrait plus un indicateur sur les nouveaux sites et ceux refondus car le web a un peu d'histoire et effectivement tu remplaces pas 20 ans de vanilla JS/jquery par d'autres frameworks en un coup de baguette.

C'est pour ça que la démarche de l'almanach est annuelle, ils préparent la nouvelle version.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

un algo compilé en instructions natives sera plus rapide que de l'interprété.
c'est le ratio entre les 2 qui est difficile (voir impossible) à déterminer.

Et les opcodes+jit c'est quoi d'après toi ?

une mesure de perf sur un algo avec un garbage collector peut être fluctuent alors que sans il est plus prédictible.

Le modèle d'exécution de php doit pas mal aider pour ça.

Et sinon, @barmic, c'est quoi ton intérêt de défendre cœur et âme PHP ?

Te reprendre ce n'est pas défendre corps et âme. Je n'aime pas du tout php. Mais je distingue ne pas du tout aimer et considérer que c'est objectivement mauvais. Je n'aime pas le turquoise, ça n'en fais pas une mauvaise couleur.

Te répondre me donne l'occasion de faire des recherches sur php et python, je trouve ça cool. Ça fait bien longtemps que je ne te réponds plus pour tenter de te convaincre tu te remets bien suffisamment en question tout seul, mais revoir l'historique de l'asynchrone en python, s'intéresser au runtime php,… je trouve ça cool.

Je ne vais pas te demander pourquoi tu viens faire une croisade, au mieux c'est juste du troll.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu pense que la cnil réagit en quelques jours ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ils ont juste formalisé les choses un peu mieux avec des api et des mots clés dédiés depuis 5 ans : async/await.

asyncio a était intégré au langage en 2014, ok ça fait 6 ans. Mais asyncio était hors du langage avant ça et depuis bien avant il y avait twisted. Et ça n'a pas l'air d'avoir trop contraint tornado, flask et autres pour faire de l'asynchrone.

Quand tu évoques le fait que l'async nécessite toute la chaine en async, j'en ai bien conscience et c'est pour ça que quand on me dit que c'est même pas supporté nativement, je doute que ça soit possible d'en faire aussi facilement.

De ce que je vois avec python et java, on expérimente hors du langage et c'est quand les pratiques de la communauté se stabilise que l'on intègre dans le langage. Ça me paraît pas idiot comme approche.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je rappel que Java effectue ses contrôles de type à la compilation et produit un bytecode qui est par nature plus rapide à interpréter.

Il est interprété dans certains modes puis le JIT se met en place et ça fini en code natif après un temps de chauffe assez connu.

PHP compile vers des opcode au premier passage qui sont réutilisés aux autres appel et depuis PHP8 peut faire du JIT.

L'interprétation le bytecode à chaque appel jusqu'au JIT ou interprété du code source au premier accès puis réutiliser l'opcode. La mesure de performance est loin d'être aussi simpliste.

Mais effectivement, je suis plutôt convaincu que la POO est un mauvais paradigme

T'es convaincu de beaucoup de choses j'ai l'impression.

C'est un discours difficile à entendre car beaucoup ont perfectionné leurs apprentissages autours de ça (design pattern et autre joyeuseté).

Les design pattern ce n'est pas forcément OO, une monade c'est un design pattern par exemple.

Dans ces sites, c'est plus l'infra autours qui va faire la diff : load balancer, varnish, logstash, worflow autours de Git etc.
Tout ça a évolué très vite (le front aussi) mais pas vraiment PHP.

Il évolue pas assez vite ou trop ? Qu'est-ce nous donne à nous non utilisateur de ce langage une quelconque pertinence pour dire ce qui devrait être ou ne pas être du PHP ? D'autant que c'est des discussions qu'ils ont et qui sont bien plus argumentées que tout ce que nous pourront produire ici.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Java a de l'async depuis quelques années (et encore ça n'est pas si simple), python depuis 5 ans si je ne m'abuse et perl n'en a pas encore. Comme PHP, ils passent par des bibliothèques externes.

À noter que le cas d'usage le plus répandu de PHP, un reverse proxy avec FPM, une base MySQL ou Postgres, pose différemment la problématique de l'asynchrone. Par exemple si ton driver de base de données n'est pas asynchrone ça n'a pas grand intérêt. En java on commence à en avoir, mais je suis suis pas sûr que ce soit très répandu ailleurs. Pour ce qui est de l'IO sur la socket client, je pense que c'est au sein de FPM (quand tu déploie avec FPM) que ça se gère et pas du tout au niveau des API du langage.

Bien sûr il y a d'autres IO possibles et classiques (en vraiment classique je pense à mongo et redis) mais il faut voir pour chacun où ça en est.

Ensuite faut se rappeler que l'asynchrone ça n'est pas forcément la panacée, ça dépend de ton workload.

Tu n'a pas l'impression de faire des jugements à l'emporte pièce pour chaque pseudo-argument que tu donne ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Excellent ! J'espère qu'il trouvera à place !

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne connais pas assez PHP, mais en java on a pas attendu que ça fasse partie du langage pour avoir de l'asynchrone avec rx et netty. Python non plus d'ailleurs (à minima avec des trucs comme twisted). Pas plus que perl en fait (avec POE).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je parle avec plein de devs et bon le sujet du "meilleur langage" (c'est des discussion de comptoirs donc effectivement c'est toujours un peu excessif) retombe souvent sur la table.
Néanmoins, y'a des trucs récurrents qui reviennent : Python, Scala, Haskell, Rust, TypeScript mais jamais PHP (pourtant, beaucoup d'eux l'utilise à titre pro).

Ta véhémence ne doit pas beaucoup aider.

PHP, comme d'autres langages genre java. N'ont pas la hype. Mais il faut faire la part des choses entre la hype et ce qui est utilisé. Typescript et rust font énormément parler mais ça cache un biais. L'informatique, le développement c'est un énorme paquet de développeurs qui ne s'expriment pas ou pas dans ta langue ou pas là où tu va.

L'exemple le plus simple. Vu la com' on pourrait croire que react, angular et vue dominent le développement en navigateur alors qu'à eux 3 ils représentent 7% des sites web.

Certains des sites les plus visités au monde sont écris en PHP, la rivalité entre laravel et symphony crée une bonne dynamique,… Ça mérite un chouia plus de considération que de crier à tut tête qu'il faut l’abandonner surtout sans autre arguments que "je connais personne qui aime".

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est tellement un classique comme phrase qu'il y a très peu de chance. C'est de l'humour qui sert à exprimer qu'il faut se détendre. Le reste de mon commentaire l'explicite sans ambiguïté si c'était nécessaire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais l'encyclopédie de Diderot était-elle elle-même pratique à distribuer ?

Ben il me semble qu'il était à l'état de l'art de son époque.

(tu peux tout à fait mettre des liens vers des images, le client pourra choisir de les afficher à même la page, comme sur l'exemple ci-dessous)

D'acc c'est le billet donné en haut qui m'a induit en erreur.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll