votre avatar Premium

Elioty

est avec nous depuis le 31 mars 2015 ❤️

97 commentaires

Attention ce n'est pas vrai ! le PCIe n'est pas complètement rétrocompatible; la rétrocompatibilité est d'une génération à l'autre, un saut de plusieurs générations n'est pas forcément possible.

j'ai déjà eu le cas avec une carte PCI v3 qui a refusé de fonctionné sur un port PCI v1 de carte mère : le manuel de la carte était très clair : rétrocompatibilité PCIe-v2 uniquement.

Alors j'ai relu l'historique des versions de PCI Express sur wikipedia (version anglaise, comme ça tu pourras aussi aller relire mais c'est déjà le souvenir que j'avais des formations sur le PCIe que j'ai reçues au boulot, d'un point de vue software, tu comprendras ensuite d'où vient mon oubli) et la rétrocompatibilité dans les deux sens reste encore un objectif avec PCIe 7, et c'est effectivement vrai de manière générale. Le nombre de lanes, ainsi que la génération/vitesse à laquelle elles doivent fonctionner sont auto-négociés entre le root complex et chaque device, et ça se calque sur le moi-disant des deux, assurant cette rétrocompatibilité.

Par contre, il y a eu effectivement une seule petite rupture à un moment donné, mais pas du tout au niveau du protocole de communication en lui-même, c'est au niveau de l'alimentation électrique via le connecteur PCI Express. Depuis le PCIe 2.1, les cartes x16 peuvent tirer jusqu'à 75W depuis le connecteur PCIe (si besoin de plus, les cartes utilisent des connecteurs d'alimentation PCIe supplémentaires comme sur les cartes graphiques par exemple). Les contrôleurs PCIe 2.0 et inférieur peuvent effectivement ne pas être capable d'alimenter des cartes en version 2.1 et supérieur (pas retrouvé ce qu'ils devaient être capables de fournir par contre). Ce qui explique donc complétement le cas que tu donnes en exemple. Mais il semble être le seul ! Et ce n'est purement qu'une question de puissance électrique. Côté mécanique, protocole de communication et logiciel, il n'y a eu aucune rupture de compatibilité depuis le PCIe 1.0.
C'est tout de même obtus de parler d'obsolescence alors que le PCIe est rétrocompatible dans les deux sens. Tu peux brancher un appareil PCIe 7 sur un contrôleur PCIe 1 et inversement (pour le connecteur sur cuivre tout du moins, côté fibre, avant la 6.4 et la 7.0, il n'existait que quelques solutions propriétaires). Ça sera certes limité en terme de bande passante mais la communication restera fonctionnelle.

Rien vue aujourd'hui.

A priori ça devait être (du délestage ?) assez localisé et/ou ciblé car pas eu de coupure à domicile, les horloges du four et du micro-onde étaient toujours à l'heure :transpi:
Je n'ai vu l'info nul part dans la presse mais au boulot, sur un site industriel sur la métropole de Bordeaux, on a aussi eu une coupure vers midi 20~30 d'une bonne quinzaine de secondes. Côté réseau informatique et serveurs, c'est bien redondé, eu aucun soucis. Côté bureau ça a coupé aussi mais on est tous sur PC portables donc les batteries ont largement tenu. Par contre au labo, on a dû passer du temps à redémarrer certains équipements :eeek2:

Si c'est pour répondre à ce qu'est un événement, c'est non.

Certainement variable de condition. Un ou plusieurs threads peuvent attendre sur une variable de condition. Lorsqu'un événement donné se produit, on vient (le thread qui réceptionne ou produit l'événement) réveiller un, n ou tous les threads en attente sur la variable de condition associée.
En principe, ça couvre le démarrage à ces températures là, oui. En tout cas c'est comme ça pour tous les composants de micro-électronique que je connaisse, ils sont censés fonctionner et être capable de démarrer à n'importe quelle température dans la fourchette en question (aussi bien la borne inférieure que supérieure). Certains équipements sont évidemment équipés de ventilateurs ou d'autres systèmes de refroidissement qui seront activés immédiatement si l'équipement démarre à haute température. À l'inverse, certains équipements dans l'aéronautique et le spatial sont équipés de radiateur pour les réchauffer lorsque la température baisse trop (et pour donc éviter de sortir de leur fourchette de température acceptable).

Faut bien être capable de démarrer l'hélicoptère ou le jet d'un VIP stationné en plein cagnard sur un tarmac qatari ou au fin fond de la Sibérie ou du Canada.
Avec ou sans prendre en compte les dividendes ? Qui peuvent être perçus directement ou directement réinvestis pour augmenter son capital et sur une telle période, ça doit représenter une certaine somme !

Les failles Spectre/Meltdown sont couvertes médiatiquement car elles sont quasi impossible à corriger, touchent tous les PC depuis 15 ans et la plupart des smartphones -> surface importante.
(intéressant d'ailleurs de voir à quel point Intel semble plus souvent cité qu'AMD, et ARM très très peu cité alors que touché aussi).
Par ailleurs, les marques Intel/AMD, le composant CPU sont les éléments les plus parlants dans un ordi - beaucoup de gens ont une compréhension très limitée des autres éléments. On touche au coeur de l'ordi, ça réagit.

Pour les GPU, c'est légèrement différent: les failles sont plutôt logicielles - tant qu'il y a des failles logicielles suffisamment évidentes, peu de chercheurs iront sur le hardware. Je pense que 80-90% des utilisateurs n'ont pas de notion de leur GPU (je ne parle pas de l'audience de next), surtout si on inclut les téléphones (je ne sais pas du tout quel CPU/GPU j'ai dans mon tel par exemple - juste sa capacité de stockage et qu'il est 5G, ça me suffit). Par contre, en regardant les failles GPU sur les pilotes, je me suis aperçu qu'il y en a un paquet pour des GPU Arm, dont certaines très bien notées - avec Android qui ne se met pas à jour c'est tout bénef.

Mais au-delà des GPU, il y aura aussi les NPU, les processeurs TPM, les cartes Wifi, les SSD - nombre d'éléments dans un ordi sont attaquables, et tous ont de plus en plus de traitements "autonome" (il y a des démos de RAM qui traitent les données). Niveau OS, c'est drôle aussi: lors d'un context-switch, il faut pouvoir prévenir les pilotes et cartes que le processus a changé (la 1ère fuite avec les CG, c'était simplement de pouvoir capturer l'écran du processus précédent).
Quand les éléments NVMe parleront ensemble ça va être drôle aussi (genre la carte réseau qui cause au SSD sans le CPU...).

Les mécanismes de sécu sont en plus maintenant conjointement implémenté entre le CPU, l'OS et ... l'appli! Ca devient impossible à dire qu'on est sécurisé du coup!

Pour se donner une idée de l'ampleur de bazar, on peut reprendre par exemple la sécurité dans Windows. Il y a quelques éléments plus ou moins cocasses qui sont plus sécurisés que les autres: l'imprimante, le fond d'écran, les sons systèmes :) - car pouvoir d'espionnage ou de nuisance maximum - enfin début 2000 :)

Expérience personnelle: j'ai eu un jour un patch à mettre sur des machines. Le cache des cartes RAID était accessible depuis n'importe quelle VM... Oups!

Quand les éléments NVMe parleront ensemble ça va être drôle aussi (genre la carte réseau qui cause au SSD sans le CPU...).
Ca existe déjà depuis longtemps le P2P sur un bus mémoire (échanges directes entre deux périphériques sans que le CPU ne lise sur l'un pour écrire sur l'autre). Ca permet de gagner énormément en performance et en énergie et les processeurs implémentent une "IOMMU" (ou DVMA, SMMU, PAMU, SR-IOV... selon les architectures et protocoles) pour protéger tout ça et ne laisse discuter entre eux (et aux adresses voulues) que les périphériques autorisés par le système d'exploitation et ses pilotes.

D'ailleurs, l'API DirectStorage de Microsoft permet maintenant aux applications (principalement jeux mais pas que) de programmer des transferts de données d'un SSD NVMe directement vers le GPU. Ce genre de techno était plutôt dans une niche auparavant soit pour optimiser des choses en interne des noyaux soit pour éviter de la fuite/manipulation de données entre VMs sur une même machine (dans le cas où l'hyperviseur donne l'accès direct à un périphérique physique à une VM, sans IOMMU, l'invité pourrait utiliser ce périphérique pour manipuler les données directement en mémoire physique), ou pour restreindre l'accès à la mémoire centrale si un périphérique n'est pas digne de confiance.

Il existe également des API équivalentes côté monde UNIX pour programmer des transferts de données directs entre périphériques (entre deux cartes réseaux ou une carte réseau et un disque).
C'est moi ou c'est Poutou sur la dernière planche ? :D
Je trouve ça dommage depuis le début de leur aventure qu'ils soient partis sur du ARM et non du RISC-V. :craint: Après, c'est pas un processeur COTS/pour le commerce (même B2B), c'est un costum chip pour des supercalculateurs européens, ils doivent avoir un cahier des charges long comme le bras et avec une pression de fou (en terme d'objectifs et de délai).

fdorin a dit:


Je ne sais pas ce qui est le plus inquiétant : avoir vu qu’il ne fallait pas cliquer, ou reconnaitre le lien AVANT même d’avoir cliqué ? :D


Je ne connais pas le lien par cœur mais je me doutais très fortement de ce que j’allais y trouver et j’ai vu juste :D



Bonnes fêtes à tous et à toute l’équipe NextINpact :smack:

Cela dit, la version précédente était très certainement déjà vulnérable à ces attaques-là et cette nouvelle version corrige tout de même bien d’autres failles. Donc même s’il reste des vulnérabilités connues, cette nouvelle version reste plus sûre que la précédente donc elle est toujours utile, en attend la prochaine version corrigeant ces dernières failles.

Voilà, contribution faite. J’ai pris le pack magazine + stickers et rajouté 5€ de don pour faire un total de 32€ (livraison incluse) comme la dernière fois avec le magazine #3 (parce que vous avec réduit le tarif de cette contribution !!!) :fou:



Bon courage à vous, nous sommes tous avec vous !



71% à l’heure où j’écris ce message. L’objectif approche :chinois: :love:



EDIT: d’ailleurs elle est où la page remerciements sur le site ? Je n’ai pas réussi à la trouver.


Zeratool a dit:


Merci pour ces nouveaux boutons largement plus lisibles.


J’allais dire la même chose, GROS +1 !

Attention à la formulation :
“une évolution de la base au niveau de sécurité r62 d’Android 10”
laisserait entendre que le système se base sur Android mais c’est faux. Sailfish OS est une distribution Linux et non une distribution Android (lui-même étant un fork de Linux, soit).
C’est la base du support des applications Android qui a été mis à jour.


(reply:2062469:le hollandais volant)


Merci pour toutes ces précisions :D

Si je ne m’abuse il y a un rapport 10^3 à 10^4 entre un électron et un proton (ou anti-proton du coup) ce qui rend le poids de l’électron négligeable par rapport à celui d’un proton.



Du coup cet atome hybride “pèserait” environ 50 % de plus qu’un atome d’hélium classique (3 masses de proton au lieu de 2).

Je ne comprend toujours pas pourquoi l’article parle de l’électron au singulier et non au pluriel, l’atome d’hélium devrait en avoir deux (étant donné qu’il y a deux protons dans le noyau)



Du coup, avec le poids de l’électron étant négligeable vis-à-vis du poids du (anti)proton, on devrait même être au double de la masse pour cette atome hybride, non ?


(reply:2062415:le hollandais volant)


Importante différence de masse entre un électron et un antiproton mais relativement parlant, ça donne quoi comme différence sur l’ensemble de l’atome d’hélium classique versus d’hélium avec antiprotons à la place des électrons ?

L’accélération matérielle est le fait d’utiliser une unité de traitement dédiée à la tâche en question et non d’utiliser le processeur qui lui reste générique et programmable logiciellement.



Dans le cas de la vidéo, tous les GPUs comprennent une unité de décodage matériel de la vidéo dans différents codecs. L’AV1 étant relativement récent, seuls les GPUs les plus récents sont capables de le décodé matériellement et ont donc une part faible dans le parc mondial.



Les avantages principaux de ce genre d’unité de traitement sont leur faible consommation et leur performance vis-à-vis d’une solution logicielle (étant donné que ces unités ont été spécifiquement conçues pour réaliser cette tâche contrairement aux CPUs). La partie performance permet justement en principe de supporter des formats vidéo (genre de la 4K/8K) que le CPU de la machine ne serait pas capable de décoder suffisamment rapidement pour tenir le framerate de la vidéo (sous condition que le média et le bus mémoire possède suffisamment de bande passante pour alimenter le GPU bien sûr).
Même pour les CPUs plus performants, cela permet de dégager de la charge de leur côté pour faire autre chose ; pratique si vous faites autres choses (jeu, bureautique, navigation web, développement…) avec une vidéo YouTube en incrustée ou sur un autre écran par exemple.



Dernier avantage pour le cas du décodage vidéo, ces unités se trouvent dans le GPU, ce qui permet au flux vidéo décodé (qui peut demander énormément de bande passante suivant la résolution) d’être au plus proche de la sortie vidéo à destination de l’écran, économisant beaucoup d’envois de données vers le GPU depuis le CPU si c’était ce dernier qui avait fait le décodage.

De toute manière, la solution à long terme, c’est le RISC-V ! :incline: :fumer:

Ça fait beaucoup de transistors gaspillés, entre l’AVX-512 et les e-core (sur desktop)…

Les E-cores ont tout de même une utilité et permettent d’économiser de l’énergie lorsque le processeur est peu demandé. Désactiver/bloquer l’utilisation de l’AVX-512 alors que les unités de traitement sont là est un gaspillage pur et dur.



Les unités de traitement AVX-512 sont là, même si ce n’est pas forcément très utile pour le public visé par ces processeurs, c’est trop tard, elles sont dans le design et sont gravées. Et le client les paient tout de même !
La consommation de ces unités de traitement est, certes, importante, mais elles sont très efficaces ! Ça peut provoquer un pic de consommation et de chaleur mais les calculs seront terminés bien plus rapidement et en consommant au final moins d’énergie.
Les processeurs sont de nos jours parfaitement capables de s’auto-réguler en cas de problème de chauffe ou d’alimentation, et ce genre d’unités de calculs consomment quasiment 0 (en micro voire nano ampères) lorsqu’elles ne sont pas utilisées.



Ce ne sera pas forcément un mal que Intel retire ces unités de la prochaine gen mais pour la gen 12, elles y sont, on les pait, c’est vraiment un mal qu’Intel bride quelque chose pour lequel le client a payé.


qui n’est alors pas toujours bien gérée par les applications.


C’est surtout le rôle de l’OS de faire son boulot et de migrer un thread exécutant une instruction AVX-512 sur un cœur en étant dépourvu sur un cœur disposant de l’instruction demandée.
Après, si l’application a demandé à l’OS de n’exécuter le thread en question que sur les E-cores, tant pis pour elle, là ça sera de sa faute et l’OS peut lui envoyer un signal “illegal instruction”.



Je pense que cette histoire est surtout une volonté commerciale d’Intel de garder l’AVX-512 sur ses Xeon et c’est maintenant un bon gaspillage de transistors puisque les P-cores en sont pourtant bien pourvus…


Fort de cette expérience, l’ANFR en déduit « qu’une augmentation du trafic de la 5G conforme à l’indicateur d’exposition introduit par l’ANFR devrait à terme engendrer une augmentation de l’ordre de 20 % sur le niveau global de l’exposition ».


Euh mais à terme, les usagers vont transiter de la 3/4G vers la 5G générant donc du trafic sur les bandes de la 5G mais moins de trafic sur les bandes des 3 et 4G. Est-ce que cela a bien été pris en compte dans leur estimation ?

:top: Bravo aux premiers Pirates membres d’un gouvernement au monde :top:
Surtout étonné (mais dans le bon sens du terme) et ravi qu’ils héritent du ministère des affaires étrangères.
Autant le premier sur le numérique, c’est leur cible principale (avec le modèle démocratique), autant niveau relation internationale, je ne connais pas leur orientation sur le sujet.

J’ai créé un compte Ulule rien que pour vous :smack:



Participation réalisée ! Ne changez rien.
:inpactitude:

La scalabilité d’un “processeur” ne dépend pas seulement de lui-même mais aussi du logiciel qui l’exploite (aussi bien applicatif que l’OS, et en particulier son scheduler/ordonnanceur), et de la bande passante de la mémoire et/ou du stockage (voire du réseau) si le logiciel en question en demande dans des proportions importantes.



Les Ryzen ont une architecture plutôt straight-forward avec un seul contrôleur mémoire (contrairement aux Threadrippers basés sur Zen1), sous forme d’arbre (contre l’architecture en anneau chez Intel pendant un temps (et peut-être encore aujourd’hui ?)) et pas de partage d’unité de calcul entre cœur comme sur Bulldozer. Il n’y aucune raison que les cœurs en eux-mêmes ne soient pas scalables, à part pour des raisons qui leur sont extérieures : refroidissement insuffisant donc moins de boost, cache L1, L2 ou L3 trop petits pour l’application (juste le L3 sur Zen* qui est partagé entre cœur, L1 et L2 sont dédiés à un seul cœur sur cette architecture) ou bande passante (mémoire, stockage, réseau) insuffisante pour nourrir plus de cœurs.



Et justement dans le cas de l’outil de bench que tu considères, ça doit certainement consommer pas mal de bande passage du stockage et dans une moindre mesure de la mémoire.
Fait tourner un test purement CPU et tu verras que les Ryzen sont parfaitement scalables.



Et même dans le cas des Threadrippers en Zen1, si l’application est designée de sorte a prendre en considération l’architecture avec deux contrôleurs mémoires, ça sera tout aussi scalable.



Et enfin, comme l’a dit @David_L, les benchs théoriques sont pas vraiment la réalité. Bien sûr qu’il peut t’arriver de devoir compresser ou décompresser des fichiers ou de faire d’autres calculs parallélisable mais de nos jours, un CPU travaille rarement pour une seule application, tout simplement car on, en tant qu’utilisateur, utilise plusieurs applications en même temps, mais aussi car l’OS fait aussi tourner tout un tas d’autres services en taches de fond.



* sur les Ryzen 5900X et 5950X, il y a deux caches L3 (un par CCD) ce qui peut amener le même genre de soucis que deux contrôleurs mémoires mais tes tests n’ont pas relevé de problème dans la linéarité des performances de 8 jusqu’à 11 coeurs donc pas là que se situe le goulot d’étranglement pour ton bench en particulier.


Elles sont tout le temps énormes et je commente rarement mais là, la 3 avec Clippy en Castex (ou Castex en Clippy ? :keskidit: ) m’a fait explosé de rire. Bravo !



:dix: :dix: :dix:


Il sera par contre intéressant de tester ces modèles pour voir si des modifications dans leur consommation ou leur capacité d’overclocking découlent des changements opérés.


Si c’est effectivement le cas, ça pourrait justement permettre à AMD de sortir des refresh en XT avec des fréquences (très) légèrement augmentées avec ces nouveaux CCD (cœurs). Il y a déjà des rumeurs à ce sujet qui courent sur le net.

Je pense que cette “Journée internationale de préparation aux épidémies” est nouvelle/vient juste d’être déclarée par l’ONU, d’où l’article.
De plus, le 27 décembre ne serait-il pas la date du premier cas officiellement déclaré de Covid-19 en Chine l’an dernier ?


sephirostoy a dit:


Je crois que mon 2600 a trouvé son successeur… (i7 2600, pas Ryzen 2600 :D ).


Mon 2600 aussi commence sérieusement à chercher un successeur (i7 2600k). Je vais juste attendre quelques mois de plus pour laisser le temps à AMD de peaufiner les BIOS et surtout pour réfléchir à quel CPU prendre entre 5800X, 5900X et 5950X :mad2: Peut-être le dernier pour garder ma nouvelle bécane 10 ans comme l’actuel qui s’en approche beaucoup.


AncalagonTotof a dit:


Dommage de ne pas voir un 3950XT. Vont-ils faire comme l‘an dernier ? Attendre quelques mois avant de le sortir ? Pour 100 ou 200 € de plus ? Je risque de craquer (le slip ;-) ) avant sur un 3950X.


Je ne pense pas. Les prochains CPU chez AMD seront les Ryzen 4000 (en Zen 3 et à ne pas confondre avec les APU qui arrivent en ce moment) avant la fin de l’année ! Pas vraiment la place dans le calendrier pour sortir et laisser vivre un nouveau produit. AMD/Lisa Su (PDG) a communiqué aujourd‘hui pour célébrer l’anniversaire des Ryzen 3000 (77) et la sortie de ces nouvelles variantes XT en concluant que Zen3 est bien dans les clous côté planning pour sortir d‘ici la fin de l’année.


Albirew a dit:


PPC -> x86_64 -> ARM Ce sera quoi la prochaine architecture? SPARC? MIPS? :D


Comme David, je vote RISC-V ! L‘avantage ? ISA (le jeu d’instructions) et ses extensions sont libres de droit, aucune royalties à payer comme c‘est le cas pour ARM.

On passe de « pouvant » à « qui provoquent ».



Oui mais aussi de « une maladie grave » à « des maladies graves ».

Est-ce que cela à une importance dans le débat ? C’est une bonne question.

Oui, ils sont doués, ils font des lois sans même savoir si c’est applicable. Que d’argent du contribuable perdu à payer des heures au carré…

C’est justement dans le domaine de l’embarqué que je l’emploie tous les jours au travail <img data-src=" /> On compile en C99 et on a également un paquet de règles de codage comme celles dictées par l’ANSSI dans son document.







Witcher a écrit :



LOL le C a été abandonné depuis 30 ans pour le C++ !





Ah bon, il n’y a eu que le C89 ? Première nouvelle !!

Il y a pourtant eu une révision en 1999 (C99) et une en 2011 (C11) et une nouvelle est à venir dans quelques années prénommée pour l’instant C2x (sans parler des versions “bugfix”/mineures C95 et C17…).



Le C est encore utilisé dans de nombreux domaines. J’en fais tous les jours au travail…



Oups, j’ai feed le troll <img data-src=" />








Ricard a écrit :



Mouais pareil. AUtant rester sur la version livrée avec l’appareil.





Et le suivi des mises à jour ?! OnePlus a maintenu pendant plusieurs années son OnePlus 3 mais il est maintenant bloqué en Android 9 (il est sorti avec Android 6 quand même !) avec le patch d’octobre 2019. Je vais donc certainement sauter le pas vers une ROM costum toujours maintenu dans pas longtemps pour mon appareil. Celle-ci va s’ajouter à la liste des candidates.








OlivierJ a écrit :



Les opérateurs sont les premiers à surveiller leur réseau. l’ANFR n’est pas là pour ça.









Norde a écrit :



&nbsp;

Je rajouterai que les campagnes de mesures / contrôle permettent de prévenir les dérives / relâchements.





Tu as la raison juste au dessus de ton dernier message : les opérateurs contrôlent aussi leur réseau pour pas se faire taper sur les doigts et éviter les amendes puisque c’est la loi. Ils ne le font pas gracieusement et par pur bonté.



secouss a dit:


(tu jette un disque sur 3)


:cap: Un plateau sur 3.



Enfin, si les plateaux peuvent être testés/vérifiés avant d’être montés dans un disque dur, j’espère…







Teuf a écrit :



Nous allons très certainement repousser au 21 septembre. Mais je n’ai pas les moyens de mettre à jour mon billet ce soir.









Titia a écrit :



21 septembre !! XD





Vous me sauvez les gars !!! <img data-src=" />


Noooooon, rencontre à Bordeaux le samedi 14 septembre, le seul weekend de septembre où je suis pris <img data-src=" />

Je suis d’accord avec toi, il faut bien trouver un “dénominateur commun” pour brancher deux langages si différents dans leurs grands principes, qui est donc l’ABI du C.



Néanmoins, ce dénominateur commun n’est justement que l’interface binaire des wrappers vers le langage de destination. Sachant que le langage de destination est utilisé pour écrire ce même wrapper, il peut utiliser dans son implémentation les spécificités du langage de destination, mais évidemment pas dans son interface, limitée par l’ABI du C.



Mais une fois le LTO passé, ces wrappers étant généralement courts, ils auront certainement été inlinés donnant un overhead proche de zéro.



Enfin, ça reste du travail pas fait en simplement quelques jours. Pour les types/classes échangés entre les deux langages, il faut faire des wrappers pour tous les services ; pour ce qui est template, il faut faire une “moulinette” qui génère ces wrappers ou les faire à la main comme pour les classes s’il y en a juste quelques-uns, sinon vite chronophage.



Bref, je raconte quasiment la même chose que toi, nous sommes d’accord <img data-src=" />

Je n’ai pas lu tous les commentaires, la discussion est longue mais une nouveauté toute récente concernant l’interopérabilité C++/Rust, les dévs de Firefox ont réussi à faire du LTO (link-time optimization) entre fichiers objet issus de C++ et de Rust !!!

&nbsp;<img data-src=" />

reddit.com Reddit



C’est un peu le niveau ultime de l’interopérabilité quand même… Faut juste que Microsoft se mette à la page <img data-src=" />

Mon Intel i7 2600K et ses failles HW à répétition avec patchouille SW plombant les performances petit à petit va officiellement partir à la retraire cette année ! Certainement pour un 3700X, voire 3800X… ou un 3950X si le banquier le permet ?! :iloveyou:
En tout cas, super article ! Ça en fait presque oublier la perte de HFR l’an dernier !


(quote:41574:ZX81.1)
La gestion du PCIE 4.0 est sur le CPU. Il faudra un Ryzen 23 (Zen 2) pour en profiter, et peut-être pas sur toute les CM. AMD laisse cette option à la discrétion des fabricants. D’après les premières infos, seuls les ports proches du CPU pourront en profiter sur les anciennes CM.


:cap:


David_L a dit:


AS arrive dès Gen11, pas besoin d’attendre un hypothétique GPU pour en profiter. Vu que ça fait des années qu’Intel fait des promesses dans le vide à ce sujet, c’était la moindre des choses :D


C’est bien ce qu’il me semblait :yes:


Charly32 a dit:


Merci pour ta réponse !J’ai l’impression que ce qui a le plus freiné l’adoption des écrans freesync c’était…l’obligation de posséder un GPU AMD. Dans mon entourage, ça commence à sérieusement considérer les écrans Freesync depuis que nVidia les supporte.


Sans oublier qu’Intel va supporter l’AdaptativeSync (la norme sur laquelle se base FreeSync, ce dernier n’étant au final que le programme de certification d’AMD avec des critères en plus du simple taux de rafraichissement variable) sur ses GPU dédiés à venir l’an prochain et devrait même commencer à le supporter sur ses prochains iGPU de mémoire.
Bref, même si AMD ne détient pas la couronne des performances, ils ont encore une fois réussi à imposer les technologies qu’ils développent (x86_64, Mantle qui a donné naissance à DX12 et Vulkan, et maintenant Free/AdaptativeSync, et j’en oublie certainement).

Bon, je verrais ce soir à la maison car son mon Firefox ESR 52.4 (32-bits) du boulot (derrière un proxy d’entreprise), j’ai essayé deux fois de l’ouvrir et à chaque fois il fait freezer mon navigateur quelques secondes jusqu’à que Firefox me propose d’arrêter le script qui bloque tout le monde… Et ensuite, sans javascript, il n’y a plus grand chose qui fonctionne. Bref, vous devriez certainement faire un peu plus d’asynchrone par ci par là dans votre code pour débloquer le navigateur.



Sinon, impatient de voir ça ce soir, encore quelques heures à tenir !!! <img data-src=" />

Effectivement, ça m’a fait tiquer un peu aussi. J’aurais écris “utilise […] pour la troisième fois” tout simplement. Cela dit, je ne suis pas un expert et je me suis fait avoir avec “après que” et la conjugaison du verbe de la subordonnée derrière la dernière fois donc mon avis est à prendre avec des pincettes <img data-src=" />







fred42 a écrit :



Article 212 du Code civil :

Les époux se doivent mutuellement respect, fidélité, secours, assistance.



Ce n’est pas un délit pénal, mais c’est bien contraire à la loi.





Tu peux avoir des relations extra-conjugales tout en étant fidèle. L’un n’exclut pas l’autre. En effet, comment font les couples libertins ? Ce n’est pas parce que tu as des relations avec d’autres que tu n’es plus fidèle envers ton ou ta compagne. S’il y a commun-accord entre les deux mariés sur le sujet, je ne vois pas en quoi la fidélité serait rompue. Ce n’est cependant que mon humble avis, je ne suis pas juriste.



Après, si l’un des deux changent d’avis et lance une procédure de divorce, ça doit être compliqué à prouver que les relations extra conjugales étaient “légitimes” et ne rompaient pas le devoir de fidélité.