Marrant, je dirais le contraire: « podcaster » a la racine « cast » qui signifie « jeter » avec donc le sous-entendu que quelque chose est envoyé par le sujet, alors que « streamer » a pour racine « stream » qui signifie juste « flux » sans notion de direction…
Noter au passage que lsp/eglot sont juste une réimplémentation pour Emacs du "Language Server Protocol" introduit par Visual Studio Code. C'est-à-dire que le service qui tourne en tâche de fond est le même pour lsp/eglot et VSCode.
Dans ma boîte, un jour quelqu'un a lancé un chmod -x /usr/bin/* /usr/sbin/* sur tous les PC Linux de tous les utilisateurs via le logiciel de gestion de parc…
Mais via les cycles de référence il est tout à fait possible d'avoir des fuites de mémoires ; et donc un GC optionnel aurait du sens en effet.
Rust ne permet pas de faire des cycles de références (hors code unsafe), sauf à utiliser des pointeurs faibles (Weak), il n'est donc pas possible d'avoir des fuites de mémoire (du moins pas plus qu'avec un ramasse-miettes).
Je connaissais avant, je ne sais plus où j'en avait entendu parler (probablement Diaspora). Mais plus on parle de Mercurial et de ce qui va autour plus je suis content ☺
Oui, je cherche clairement une solution alternative d'ici juin, et je regarde Heptapod de très près. Et si je peux éviter d'administrer moi-même le truc ça m'arrangerait bien…
complémentation → complétion ou achèvement (aucun des deux ne correspond exactement à l'anglais « completion, » mais « complémentation » est encore plus éloigné).
Je conseille de rajouter cela dans votre ~./.bashrc:
Plutôt dans le ~/.profile qui a l'avantage de fonctionner même pour ceux qui n'utilisent pas bash, voire dans le ~/.xprofile qui vaut aussi pour l'environnement graphique (mais qui peut dépendre des distrib)…
La première touche absolument tous les processeurs modernes quel que soit le fabriquant (y compris probablement les OpenMIPS et OpenSPARC bien qu'ils ne soient pas cités) et permet à un processus d'accéder à sa propre mémoire. Alors pourquoi est-ce un problème (et pourquoi le processus ferait-il comme ça plutôt que d'accéder directement à la mémoire) ? Tout simplement parce qu'un script tournant sur une VM (de type VM javascript) peut exploiter la faille pour lire n'importe où dans la mémoire du processus (donc par exemple dans la mémoire concernant les autres onglets du navigateur). Noter à ce sujet que le noyau Linux contient une VM (eBPF) utilisée à l'origine pour les pare-feux et qui permet à n'importe quel programme d'exécuter un script en espace noyau et donc de lire toute la mémoire du noyau (à un rythme de 1500 octets/s environ). Cette attaque devrait pouvoir être patchée au niveau logiciel dans les VM avec un coût relativement faible.
La deuxième attaque n'a été démontrée que sur les processeurs Intel, mais ARM reconnaît que ses processeurs sont aussi vulnérables. AMD prétend que les siens ne sont pas touchés (plus exactement AMD dit que personne n'a montré que cette faille touche leurs processeurs, mais rien ne prouve qu'ils sont immunisés). Cette faille demande une connaissance très poussée de l'unité de prédiction de branchement du CPU (que les auteurs ont obtenue par rétro-ingénierie sur les processeurs Intel) ainsi que du code de l'OS ou de l'hyperviseur cible. L'attaque permet d'injecter du code dans le contexte de l'OS ou de l'hyperviseur. Elle fonctionne en trompant l'unité de prédiction de branchement pour que celle-ci fasse exécuter du code choisi par l'attaquant au moment où l'OS cible fait un branchement conditionnel. Le résultat de ce code sera jeté quand le CPU s’apercevra de l'erreur de prédiction, mais des effets secondaires peuvent rester visibles (en particulier le chargement de données en cache). Je n'ai pas entendu parler de correctif pour cette attaque…
La troisième attaque ne concernerait que les processeurs Intel et vient du fait que la MMU contrôle l'accès a posteriori. Elle permet à un processus de lire une page mémoire qui est présente dans son espace d'adressage, même si la lecture de cette page est normalement interdite. Elle ne permet pas en revanche de lire une page mémoire non présente dans l'espace d'adressage. La raison pour laquelle cette attaque pose problème c'est qu'une grande partie de la mémoire des OS est présente dans l'espace d'adressage des applications en mode lecture interdite (en tout cas pour Linux et Windows) afin d'accélérer les appels systèmes (il est beaucoup plus rapide de changer les permissions d'une page existante que d'ajouter ou de supprimer des pages dans la MMU). Les patchs du noyau Linux dont on parle visent à retirer la mémoire de l'OS de l'espace d'adressage des applications, ce qui bloquera cette attaque mais augmente considérablement le coût des appels système (jusqu'à 60% de perte de performance sur des benchmarks synthétiques, PostgresSQL a été mesuré à -17% quand ces patchs sont activés).
Je n'ai pas moinssé (ni plussé), mais je n'ai pas trop aimé. En revanche, si tu avais mis : « C'est qui la vieille pédale ? » j'aurais beaucoup plus apprécié…
Avec les threads (pthread_create) il n'y a pas de séparation, et Firefox fait ça depuis longtemps (en fait je crois bien que Netscape le faisait déjà).
Il s'agit donc bien ici de de processus (fork/exec) qui assurent une bien meilleure séparation avec un isolement complet de la mémoire en dehors des zones explicitement partagées.
En fait, ça doit dépendre du relecteur. Pour radial context, ils ont successivement refusé, accepté puis refusé la même extension (les seules différences entre les trois étaient le remplacement d'appels à des API obsolètes par la nouvelle API).
[^] # Re: Téléverser ?
Posté par jeberger (site web personnel) . En réponse au journal Google retire Conversations du magasin Play (Play Store). Évalué à 2 (+1/-0).
Marrant, je dirais le contraire: « podcaster » a la racine « cast » qui signifie « jeter » avec donc le sous-entendu que quelque chose est envoyé par le sujet, alors que « streamer » a pour racine « stream » qui signifie juste « flux » sans notion de direction…
[^] # Re: Eglot
Posté par jeberger (site web personnel) . En réponse au journal Emacs, le dinosaure fait de la résistance. Évalué à 1.
Noter au passage que lsp/eglot sont juste une réimplémentation pour Emacs du "Language Server Protocol" introduit par Visual Studio Code. C'est-à-dire que le service qui tourne en tâche de fond est le même pour lsp/eglot et VSCode.
Source: Wikipedia
[^] # Re: Dans le même genre
Posté par jeberger (site web personnel) . En réponse au journal Comment j'ai foutu en l'air une partie de notre prod (et comment on l'a remise sur pieds). Évalué à 1.
Je n'ai jamais su ce qu'il cherchait à faire, non.
# Dans le même genre
Posté par jeberger (site web personnel) . En réponse au journal Comment j'ai foutu en l'air une partie de notre prod (et comment on l'a remise sur pieds). Évalué à 5.
Dans ma boîte, un jour quelqu'un a lancé un
chmod -x /usr/bin/* /usr/sbin/*
sur tous les PC Linux de tous les utilisateurs via le logiciel de gestion de parc…[^] # Re: Formats des boîtes locales
Posté par jeberger (site web personnel) . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 5.
Thunderbird savait, mais la fonctionnalité a été retirée après la version 78: https://bugzilla.mozilla.org/show_bug.cgi?id=1727931
Il y a 3 mois, ils parlaient de le remettre mais pour l'instant ce n'est pas fait…
[^] # Re: Mauvais nom
Posté par jeberger (site web personnel) . En réponse à la dépêche Changeons ces logiciels open source qui nous espionnent. Évalué à 0.
Euh, non c'est toujours là…
# Faux amis
Posté par jeberger (site web personnel) . En réponse à la dépêche HorsCiné : lancement et financement d’une plate‑forme libre de films en libre diffusion. Évalué à 4.
« ce n'est pas l'acceptation courante » → « ce n'est pas l'acception courante » (Larousse)
[^] # Re: Pffff
Posté par jeberger (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 1.
Rust ne permet pas de faire des cycles de références (hors code
unsafe
), sauf à utiliser des pointeurs faibles (Weak
), il n'est donc pas possible d'avoir des fuites de mémoire (du moins pas plus qu'avec un ramasse-miettes).[^] # Re: Retours
Posté par jeberger (site web personnel) . En réponse à la dépêche Le projet Heptapod : GitLab + Mercurial = 🖤. Évalué à 4.
Je connaissais avant, je ne sais plus où j'en avait entendu parler (probablement Diaspora). Mais plus on parle de Mercurial et de ce qui va autour plus je suis content ☺
[^] # Re: Retours
Posté par jeberger (site web personnel) . En réponse à la dépêche Le projet Heptapod : GitLab + Mercurial = 🖤. Évalué à 5.
Oui, je cherche clairement une solution alternative d'ici juin, et je regarde Heptapod de très près. Et si je peux éviter d'administrer moi-même le truc ça m'arrangerait bien…
# Google va distribuer des mauvais points aux sites qu'il juge lents
Posté par jeberger (site web personnel) . En réponse à la dépêche Firefox 71. Évalué à 5.
Ironique quand on connaît la lenteur des sites de Google…
[^] # Re: correction
Posté par jeberger (site web personnel) . En réponse à la dépêche Sortie de GNU Compiler Collection 9.1. Évalué à 1.
complémentation → complétion ou achèvement (aucun des deux ne correspond exactement à l'anglais « completion, » mais « complémentation » est encore plus éloigné).
# SSE3
Posté par jeberger (site web personnel) . En réponse à la dépêche dav1d is An AV1 Decoder. Évalué à 0.
Juste une petite remarque: il n'y a que deux « S » à « SSE3 »
[^] # Re: Compiler
Posté par jeberger (site web personnel) . En réponse à la dépêche GNU Emacs 26.1. Évalué à 4.
Plutôt dans le
~/.profile
qui a l'avantage de fonctionner même pour ceux qui n'utilisent pas bash, voire dans le~/.xprofile
qui vaut aussi pour l'environnement graphique (mais qui peut dépendre des distrib)…[^] # Re: Meltdown, seulement Intel ?
Posté par jeberger (site web personnel) . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.
En fait l'article décrit trois attaques :
La première touche absolument tous les processeurs modernes quel que soit le fabriquant (y compris probablement les OpenMIPS et OpenSPARC bien qu'ils ne soient pas cités) et permet à un processus d'accéder à sa propre mémoire. Alors pourquoi est-ce un problème (et pourquoi le processus ferait-il comme ça plutôt que d'accéder directement à la mémoire) ? Tout simplement parce qu'un script tournant sur une VM (de type VM javascript) peut exploiter la faille pour lire n'importe où dans la mémoire du processus (donc par exemple dans la mémoire concernant les autres onglets du navigateur). Noter à ce sujet que le noyau Linux contient une VM (eBPF) utilisée à l'origine pour les pare-feux et qui permet à n'importe quel programme d'exécuter un script en espace noyau et donc de lire toute la mémoire du noyau (à un rythme de 1500 octets/s environ). Cette attaque devrait pouvoir être patchée au niveau logiciel dans les VM avec un coût relativement faible.
La deuxième attaque n'a été démontrée que sur les processeurs Intel, mais ARM reconnaît que ses processeurs sont aussi vulnérables. AMD prétend que les siens ne sont pas touchés (plus exactement AMD dit que personne n'a montré que cette faille touche leurs processeurs, mais rien ne prouve qu'ils sont immunisés). Cette faille demande une connaissance très poussée de l'unité de prédiction de branchement du CPU (que les auteurs ont obtenue par rétro-ingénierie sur les processeurs Intel) ainsi que du code de l'OS ou de l'hyperviseur cible. L'attaque permet d'injecter du code dans le contexte de l'OS ou de l'hyperviseur. Elle fonctionne en trompant l'unité de prédiction de branchement pour que celle-ci fasse exécuter du code choisi par l'attaquant au moment où l'OS cible fait un branchement conditionnel. Le résultat de ce code sera jeté quand le CPU s’apercevra de l'erreur de prédiction, mais des effets secondaires peuvent rester visibles (en particulier le chargement de données en cache). Je n'ai pas entendu parler de correctif pour cette attaque…
La troisième attaque ne concernerait que les processeurs Intel et vient du fait que la MMU contrôle l'accès a posteriori. Elle permet à un processus de lire une page mémoire qui est présente dans son espace d'adressage, même si la lecture de cette page est normalement interdite. Elle ne permet pas en revanche de lire une page mémoire non présente dans l'espace d'adressage. La raison pour laquelle cette attaque pose problème c'est qu'une grande partie de la mémoire des OS est présente dans l'espace d'adressage des applications en mode lecture interdite (en tout cas pour Linux et Windows) afin d'accélérer les appels systèmes (il est beaucoup plus rapide de changer les permissions d'une page existante que d'ajouter ou de supprimer des pages dans la MMU). Les patchs du noyau Linux dont on parle visent à retirer la mémoire de l'OS de l'espace d'adressage des applications, ce qui bloquera cette attaque mais augmente considérablement le coût des appels système (jusqu'à 60% de perte de performance sur des benchmarks synthétiques, PostgresSQL a été mesuré à -17% quand ces patchs sont activés).
[^] # Re: Merci pour l'info !
Posté par jeberger (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 1.
Pareil, au pire j'utilise hggit pour interagir avec les moutons qui utilisent Git (qui a dit "broken by design"?)
# Modulo
Posté par jeberger (site web personnel) . En réponse au journal Kotlin + Brainfuck : efficacité, compacité, optimisation. Évalué à 1.
Je suis le seul a être gêné par les
% 0xFFFF
? Ça ne devrait pas plutôt être& 0xFFFF
ou% 0x10000
?[^] # Re: Je ne suis pas sur de comprendre
Posté par jeberger (site web personnel) . En réponse à la dépêche PikoPixel, éditeur de « pixel art ». Évalué à 3.
Yaurait pas comme l'ébauche d'un problème là ? Mon Pi 1 tourne à 700 BogoMIPS (697.95 pour être précis). Je doute que le 3 soit à ce point moins bon…
[^] # Re: Typo
Posté par jeberger (site web personnel) . En réponse à la dépêche darktable 2.2.0. Évalué à 1.
Et aussi : « déformation due à une mauvaise pause » → « déformation due à une mauvaise pose »
[^] # Re: Led comme capteur de luminosité
Posté par jeberger (site web personnel) . En réponse à la dépêche Les diodes ne sont pas toutes des lumières. Évalué à 2.
Je n'ai pas moinssé (ni plussé), mais je n'ai pas trop aimé. En revanche, si tu avais mis : « C'est qui la vieille pédale ? » j'aurais beaucoup plus apprécié…
# Anglicisme
Posté par jeberger (site web personnel) . En réponse à la dépêche LibreOffice : de 5.0 à 5.2, un an après. Évalué à 4.
« problèmes de consistance de l’affichage » → « problèmes de cohérence de l'affichage »
Sinon, bravo pour une dépêche très complète et détaillée (même si c'est « juste » une traduction, ça représente un gros boulot alors félicitations).
[^] # Re: Qwant et le multi processus
Posté par jeberger (site web personnel) . En réponse à la dépêche Firefox 48 : API WebExtensions, Electrolysis et sécurité. Évalué à 3.
Avec les threads (
pthread_create
) il n'y a pas de séparation, et Firefox fait ça depuis longtemps (en fait je crois bien que Netscape le faisait déjà).Il s'agit donc bien ici de de processus (
fork
/exec
) qui assurent une bien meilleure séparation avec un isolement complet de la mémoire en dehors des zones explicitement partagées.[^] # Re: Extensions
Posté par jeberger (site web personnel) . En réponse à la dépêche Firefox 48 : API WebExtensions, Electrolysis et sécurité. Évalué à 6.
En fait, ça doit dépendre du relecteur. Pour radial context, ils ont successivement refusé, accepté puis refusé la même extension (les seules différences entre les trois étaient le remplacement d'appels à des API obsolètes par la nouvelle API).
# Et le dernier lien devrait être…
Posté par jeberger (site web personnel) . En réponse à la dépêche Les journaux LinuxFr.org les mieux notés du mois de juin 2016. Évalué à 2.
https://linuxfr.org/users/zezinho/journaux/coup-de-boost-sur-le-pilote-graphique-intel
[^] # Re: Vrai IDE ?
Posté par jeberger (site web personnel) . En réponse à la dépêche CodeBusters, concours d'intelligence artificielle en ligne du 25 juin au 3 juillet 2016. Évalué à 1.
Quand tu dis « push dans l'IDE, » tu veux dire par copier-coller (ce que je fais) ou il y a un moyen plus simple d'uploader un fichier ?