De ce que j'ai compris DSP2 n'est pas compatible avec ce genre de token rsa. Le principe est d'avoir un lien plus fort. Ta banque ne te file pas seulement un code mais aussi Ă quoi il va servir.
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.
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
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.
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.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2.
Tu mélange "trouver des inconvénients à un typage" ou "ne pas aimer un typage" et "typage faible". C'est un mélange sémantique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2.
Ça tout le monde le fait. Compiler d'un langage à un autre c'est simple. C'est l'interfaçage qui est compliqué. Comment utilise-tu une bibliothèque js ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  3.
Je voulais signifier que les threads/processus et les greens threads (tel qu'ils sont implémenté maintenant) résolvent 2 problèmes différentes :
Un vielle exemple de l'impact que peux avoir le scheduling et qui fait un peu ressentir la différence c'est le vieux patch du noyau. On ne touche pas à l'usage CPU, ni au temps d'exécution, mais on a plus de latence.
Je suis pas persuadé que ça face une différence perceptible et quelques soit l'OS ça demande de passer en espace noyau et nettoyer le core sur lequel il s'exécute.
C'est la définition des greens threads donc je sais pas trop quoi dire. T'a l'air de ne pas trop te fier à wikipedia, donc je te laisse choisir la source qui te plaira. Je serais curieux de connaitre une source qui n'explique pas que c'est des threads en espace utilisateur. Après le fait de l'implémenter par de l'asynchrone "caché" n'est pas obligatoire, mais sans ça ça n'a pas vraiment d'intérêt. C'est pour ça que java a jeter sa vielle implémentation il y a un paquet de temps, mais qu'ils y réfléchissent de nouveau.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2.
Pour s'interfacer avec un langage à prototype comme l'est javascript, ça me semble être la meilleure solution.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  4.
Tout Ă fait. De plus :
Non python ne fais pas du duck typing quand ça l'arrange, il fait toujours du duck typing, c'est à dire qu'il ne fait pas un typage nominal, mais structurel1 et qu'il calcul ce typage au runtime. En python une variable est du bon type si et seulement si elle possède la propriété ou la méthode utilisée et pas si la type de l'objet est du même nom qu'attendu.
La force ou la faiblesse d'un typage c'est ça capacité à caster. Quasiment tous les langages ont un cast à un endroit (par exemple pour pouvoir affecter 1 à un entier, un long, un double), mais certains en font plus et en font de l'implicite.
En langage récent qui en fait il y a go et typescript (c'est d'ailleurs extrêmement pertinent pour lui). ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: à chacun sa vision de la simplicité
Posté par barmic 🦦 . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à  2.
Tu as tout à fais raison, pour le fonctionnement, je me suis trompé par contre.
Suivre une série de pointeurs dans un arbre balancé et faire une série d'appels systèmes pour lister le contenu des répertoires puis supprimer chaque fichier n'a sans doute pas le même coût.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Coincidence
Posté par barmic 🦦 . En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à  6.
Ça ne doit pas être trop compliqué de simplement répliqué l'identifiant que tu as du coté clavier.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Coincidence
Posté par barmic 🦦 . En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à  5.
Et lui de te répondre que tu tu as une attaque matériel, wayland ne fera rien pour toi.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi ?
Posté par barmic 🦦 . En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à  3.
De ce que j'ai compris DSP2 n'est pas compatible avec ce genre de token rsa. Le principe est d'avoir un lien plus fort. Ta banque ne te file pas seulement un code mais aussi Ă quoi il va servir.
cf: https://www.certeurope.fr/blog/dsp2-et-authentification-forte-que-prevoit-la-directive-europeenne/ article 97 paragraphe 2
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Autre solution : pas de JS et pas de meta refresh
Posté par barmic 🦦 . En réponse au journal Extension Google Direct pour Firefox. Évalué à  2.
Ce sont d'énorme obstacle. Si tu ne change pas régulièrement d'adresses c'est très difficile de retrouver partout où tu l'a utilisé, le faire changer partout où c'est possible, maintenir une redirection pendant un certains temps.
Vécu ?
C'est un autre problème et je ne dis pas que les lois sur les monopoles ne devraient pas changer.
Mais ça ne marchera jamais. C'est une démarche qui est parfaitement vaine. Déjà elle est nécessairement en retard. Tu tente d'exprimer après coup ce qui a posé problème pour l'interdire, alors que le monopole est la cause racine, c'est une question qui est étudié depuis des décénies et on peut arriver à les empêcher. Ça marche particulièrement pour les entreprises physiques. On va pas s'étonner d'avoir plus de recul là dessus que sur le fonctionnement d'internet (et je ne parle pas du fonctionnement technique, mais de l'économie et la sociologie d'internet).
Genre les monopoles ?
Bien sûr. Mais pour chaque cas que tu as en tête et qui généralement fait réagir, combien est-ce qu'il y en a qui utilisent plus la méthode Huxley (d'autant que certaines perdures depuis des dizaines d'années) ? Je ne dis pas que l'autoritarisme est impossible, mais qu'il est très faibles, limité dans le temps et l'espace là où les méthode décrites par Huxley fonctionne sur la quasi totalité do globe depuis des dizaines d'années.
Je vais prendre bien soin d'ignorer ostenssiblement ce passage.
C'est ce que tu affirme, mais ça n'est pas établi. Il existe plusieurs tentatives de créer des moteurs de recherches généralistes fédérés. Pourquoi les interdire ?
Après je suis toujours septiques de la recherche de toujours tout le temps vouloir du fédéré/acentré/décentralisé. Ça cache systématiquement d'énormes biais.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Servo ? Lent ?
Posté par barmic 🦦 . En réponse à la dépêche Résumé des nouveautés de Firefox 81 à  83. Évalué à  6.
Il me semble qu'il fut y un temps jadis où il était imaginé qu'il remplace gecko. Dans tous les cas au moins par moi :-)
Il va devenir le hurd des moteurs html ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Autre solution : pas de JS et pas de meta refresh
Posté par barmic 🦦 . En réponse au journal Extension Google Direct pour Firefox. Évalué à  6.
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
[^] # Re: Autre solution : pas de JS et pas de meta refresh
Posté par barmic 🦦 . En réponse au journal Extension Google Direct pour Firefox. Évalué à  2.
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.
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.
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.
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
[^] # Re: Et ça donne quoi coté réactivité?
Posté par barmic 🦦 . En réponse au journal Transformer vim en IDE avec LSP et DAP. Évalué à  3.
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
[^] # Re: Terminal
Posté par barmic 🦦 . En réponse au journal Transformer vim en IDE avec LSP et DAP. Évalué à  4.
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
[^] # Re: Servo ? Lent ?
Posté par barmic 🦦 . En réponse à la dépêche Résumé des nouveautés de Firefox 81 à  83. Évalué à  5.
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
[^] # Re: LanguageClient
Posté par barmic 🦦 . En réponse au journal Transformer vim en IDE avec LSP et DAP. Évalué à  8.
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
[^] # Re: Servo ? Lent ?
Posté par barmic 🦦 . En réponse à la dépêche Résumé des nouveautés de Firefox 81 à  83. Évalué à  4.
Ă€ la linux fundation
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Servo ? Lent ?
Posté par barmic 🦦 . En réponse à la dépêche Résumé des nouveautés de Firefox 81 à  83. Évalué à  5.
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
[^] # Re: Autre solution : pas de JS et pas de meta refresh
Posté par barmic 🦦 . En réponse au journal Extension Google Direct pour Firefox. Évalué à  2. Dernière modification le 03 décembre 2020 à 08:12.
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
# Terminal
Posté par barmic 🦦 . En réponse au journal Transformer vim en IDE avec LSP et DAP. Évalué à  4.
Merci pour ton journal
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.
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
[^] # Re: le but ?
Posté par barmic 🦦 . En réponse au lien Le protocole Gemini, revenir à du simple et sûr pour distribuer l'information en ligne ? - Botzmeyer. Évalué à  3.
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
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  3. Dernière modification le 02 décembre 2020 à 01:00.
Je ne suis pas d'accord :)
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 la parallélisation oui, pour du réactif les threads et process sont de piètres palliatifs.
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.
La différence est drastique.
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.
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ènements1 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.
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.
c'est basé à fond sur
epoll(4)
pour attendre des évènements sur une série de file descriptor ↩https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  3.
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).
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
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  3.
Tu le ressent quand un site est en PHP ? Pas moi. Je n'ai pas particulièrement à expliquer aux gens comment s'habiller.
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