Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. C'est ce que je vais faire si vraiment je ne trouve pas de solution autre...
  3. oh , pas la même forme , mais cela est déjà bien je trouve. Cela m'a permi de trouver cela aussi : https://www.amazon.fr/Feicuan-Crystal-Replacement-Universal-Mechanical/dp/B071ZF9GB1 sans mention de compatibilité cherry mx..
  4. https://www.ebay.fr/itm/183945738496
  5. Les touches ne sont pas transparentes sur le haut.
  6. ca ? https://www.amazon.ca/Mechanical-SADES-Keyboards-Mutilmedia-Illuminated/dp/B07XLLNM4J
  7. Bonsoir, Alors pour faire simple.. je suis incapable de trouver un clavier mécanique ayant cette configuration: 108key. Keycaps Gloss sur le haut, blanc sur le dessous. Comme sur les deux images ici : -------- J'ai tout essayé, Dualtone, translucent... Le tout en MXblue. Si une personne sait m'aider ^^'
  8. Bon, au final, je pense avoir trouvé celui-là : https://www.amazon.fr/dp/B004HE2YZE Moins cher chez Amazon, il devrait me permettre de placer l'alim, la CM et possiblement la CG (au cas où ...). Vous en pensez quoi ?
  9. L'étagère fait 30cm de profondeur. Je suis conscient qu'en prenant de l'existant, ça réglera mon problème mais le souci, c'est que : j'ai des pièces (qui offrent plus de puissances) qui dorment dans un placard ; ça me permettra de faire tourner un PC la nuit, plus éloignée de la chambre (entre 400 ko/s et 1Mo/s 😞) ; plus multitâche que le NUC que j'ai (j'ai tenté un p'tit jeu, ça n'a jamais fonctionné). Je dois changer de meuble TV (mais pas tout de suite, la personne doit d'abord trouver un autre meuble), il est possible que j'ai plus de place en hauteur mais l'avantage du boîtier horizontal, c'est que je suis quasi-sûr de tout le temps pouvoir le placer.
  10. Je n'avais pas vu ta contribution. J'ai également demandé à un modo de séparer du sujet de capitalisation car le débat est tout autre. Je dirait au contraire que les éléments de conteneurisation apportent plus de réponses aux problématiques de sécurité. Si tu peux détailler ton propos, je suis intéressé. Comme souvent les problème de sécurité sont lié aux équipes qui l'utilisent et je ne vois pas en quoi docker empirerai le sujet. Bien au contraire le fait que le conteneur embarque le moins d'outil possible réduit les surfaces d'attaque. La conteneurisation avec ses couches d'images & dockerfiles permet d'accélérer les cycles de mise à jours et éviter le retard trop souvent constaté de mise à jours des socles/libs. J'aimerai bien avoir plus de précisions du lien indiqué sur le fait annoncé que LXC est moins sécurisé à cause de "relaxed isolation levels" sachant que les "priviledged containers" sont à proscrire et même interdit en général. J'attend encore de voir le "technology killer" que l'on nous annonce toujours depuis de nombreuses années. Les paris sont difficiles (et quand je vois que l'article parle de l'implémentation d'Intel dans openstack qui est un socle qui est tombé en disgrâce). Pour l'article en lui même, je trouve de nombreux faux arguments et même éronnés. Exemple parmi tant d'autre : l'aspect démarrage de conteneurs présenté ici comme "lent" ... je dois avouer ne pas comprendre et ne pas le constater au quotidien (quel est l'ordre de comparaison?). Les seuls éléments en compétition avec docker sont les approches serverless qui sont plus un complément qu'une concurrence directe car ne répondent pas aux même enjeux. Edit: Ah firecracker est un framework pour le serverless. L'article d'AWS confirme ma vision que c'est un complément (ici via containers kata) et que kubernetes restera probablement un hyperviseur transverse https://aws.amazon.com/fr/blogs/france/kata-containers-1-5-pour-firecracker/
  11. Il était vendu sans OS ni disque dur, avec apparemment 4Go de RAM.
  12. Que tu ne sois pas d'accord avec moi très bien je le respecte, il n’empêche que les bench ingame montre que certains jeux sont pénalisé lorsqu'ils tournent sur un amd, et c'est la question posée par la personne à la base de savoir si son 2600 pouvait être la cause de son soucis, auquel je réponds que oui c'est possible surtout en 1080p. Pour le xmp je confirme que c'est bien mais que l'on peux faire mieux manuellement et en voici la preuve illustrée. RAM 3600C17 à la base passée en 3600C16 puis 3800C17 et le ring à 4.5GHz et le cpu à 5.1GHz, le gain de bande passante et latence est plus que notable. Évidement si l'on touche sans savoir quoi faire les timing ram c'est clair que l'on risque d'avoir de l'instabilité ou réduction de perf, et c'est normal car il y a pas mal de timing qui influence les perf et dépendent de ta ram et ta carte mère et ton cpu. Tout ce que je dis c'est que un ryzen < au 3900x n'est pas le meilleur choix pour jouer en 1080p 144Hz mais je conviens qu'ils sont meilleurs en rapport perf/prix donc je comprends très bien pourquoi ils se vendent super bien, et ils ont d'autres qualités de performance multithread etc... Le manque de performance en écriture et latence ram est pour moi une explication logique du pourquoi mais je peux me tromper, mais vu que le 3900x n'a pas le soucis et qu'il s'en sort bien mieux cela conforte aussi mon idée. Bref comme tu dis restons en là j'ai dis ce que j'avais à dire et djnrq fera bien comme il veut.
  13. KCleaner - 3.7 ( Released 2020-06-01) ===================================== https://www.kcsoftwares.com/?kcleaner
  14. Ce sujet porte sur l'analyse de https://insights.stackoverflow.com/survey/2020 qui est le sondage annuel de stackoverflow pour identifier les tendances et attentes de la communauté (65.000 réponse). Note: Aucune relecture, de nombreuses réécritures partielles de phrases. Certains passages peuvent donc être un carnage. Les pourcentages sont à considérer avec une réponse à choix multiple (la somme ne fait donc pas 100%). Pourquoi une analyse spécifique à docker/kubernetes et pas le reste ? Tout simplement parce que ces 2 domaines apparaissent dans le top 3 et que c'est mon domaine et donc je peut essayer de contextualiser les chiffres. 1. Popularité des plateformes de déploiement 1.1 (plateforme appréciée) https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-platforms-loved5 1 - Linux 76.9% 2 - Docker 73.6% 3 - Kubernetes 71.1% 4 - AWS 66.4% Nous retrouvons Linux en top 1 car son succès global (Android, serveur) n'est plus à prouver. Nous pouvons cependant souligner le lien très étroit entre les images docker et les socles Linux. Jusqu'à il y a encore peut de temps les conteneurs Windows étaient à l'étude. et les déploiements .net passaient par des conteneurs .net core Tout les conteneurs reposaient donc sur des socles Linux avec comme toujours la bataille des différentes distributions (Ubuntu puis Alpine et autres). Ubuntu était devenu (et est toujours) le standard mais désormais ce sont les distribution Alpine qui tendant à passer devant par leur rapidité de démarrage et la taille des images (ainsi que la réduction des surfaces d'attaque en réduisant le nombre d'outils inclus de base). A noter cependant qu'avec Alpine de nombreux soucis ont été rencontrés pour le portage de nombreuses libs (exemple OpenJDK) car la bibliothèque glibc qui sert à de nombreux process a été remplacée par musl libc qui a des comportements différents selon les situations. Lors du passage à la conteneurisation des connaissances/compétences avancées en socle Linux sont devenus parfois nécessaires. Docker et Kubernetes suivent en tant que technologies les plus appréciées. Succès s'explique par plusieurs points: La maturité des fondamentaux système (LXC, namespace) et outils ( compose, helm, registry entre autres) Les nombreux retours d'expériences (articles) Les nombreuses communautés (une technologie quelle que soit sa bonne conception ne percera qu'avec des communautés actives). Même docker(l'entreprise) a perdu sa propre bataille d'hyperviseur de conteneurs : "Swarm VS kubernetes" (alors que Swarm apportaient de trés bonnes réponse à certaines problématiques). L'adoption et contributions par de nombreux acteurs majeurs (Google, Amazon, Microsoft, IBM etc... ) et la portabilité entre ces différents hébergeurs cloud. Exemple d'ouverture publique des problématiques de la solution AKS d'Azure https://github.com/Azure/AKS La liberté système que permet l'approche (permettant à docker de répondre à de nombreux cas d'usage). et surtout le fait que les conteneurs (tels que vu par docker) a été libéré par docker (à l'origine Kubernetes a percé car a su répondre aux problématique d'industrialisation du déploiement et d'exploitation (avec notamment de nombreuses métriques) en production dans un écosystème multi-service et multi-host en capitalisant et introduisant (pour docker) des concepts simples permettant non seulement d'organiser les relations au sein d'une application mais également de s'intéresser aux éléments extérieurs (ingress gérant le provisionnement automatique d'équilibreurs de charge externes et des DNS) et surtout de laisser le choix de l'implémentation à différentes solution évitant de forcer l'utilisation d'une technologie en particulier. Exemple: liberté de choix du reverse-proxy (nginx, traefik), du composant de CNI (la couche réseau: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) et aussi du runtime engine ( docker ou CRI-O ou containerd) https://kubernetes.io/docs/setup/production-environment/container-runtimes/). Kubernetes a su répondre également aux enjeux de l'auto-hébergement en démontrant qu'il pouvait s'installer sur les serveurs locaux d'entreprise ("on-premise") A noter cependant que Kubernetes ne représente qu'une petite partie des sujets docker (https://trends.google.fr/trends/explore?date=all&geo=FR&q=docker,kubernetes ). La problématique kubernetes reste limitée à des projets d'une certaine taille et ayant les moyens pour y consacrer du temps (retour d'expérience: 40 clusters (gérants 150 VM) vs 5000 VM docker). C'est cependant un élément vital pour les applications nécessitant de la haute disponibilité. Nous pourrons également souligner l'organisation très ouverte mais bien structurée des contributeurs en SIG : Special Interest Group https://github.com/kubernetes/community/blob/master/governance.md permetant aux différents contributeur de retrouver des communautés dédiées à chaque problématique (voir la liste: https://github.com/kubernetes/community/blob/master/sig-list.md ). Pourquoi retenir AWS dans l'extrait du top ? Tout simplement qu'à l'heure actuelle l'écosystème AWS pour kubernetes est (avis personnel d'utilisateur multi-cloud) le plus avancé (en terme d'offre de services) et le plus mature (stabilité et autres). 1.2 (plateforme désirée) https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-platforms-wanted5 1 - Docker 24.5% 2 - AWS 20.2% 3 - Kubernetes 18.5% 4 - Linux 16.6% La conteneurisation avec Docker et Kubernetes retient l'attention car c'est en effet la technologie en vogue pour de nombreuses entreprises et projets (retour d'expérience personnel : il nous arrive même de conseiller un projet à ne pas basculer sur la conteneurisation car non adapté au projet principalement "trop couteux pour cause de coût de transition (formations/niveau de maturité des équipes)"). Les offres d'emplois continuent pour l'instant d'évoluer en ce sens https://www.beseen.com/blog/talent/kubernetes-career-trends/ ou https://www.itjobswatch.co.uk/jobs/uk/kubernetes.do que ce soit au niveau projet ou chez les cloudeurs (à noter OVH, Scaleway pour parler des français). Cependant de nos jours les virages technologiques sont parfois assez violent (retour d'expérience personnel: kubernetes enterrant openstack https://trends.google.fr/trends/explore?date=all&geo=FR&q=kubernetes,openstack ). Nous pourrons noter une très forte affinité de kubernetes avec les déploiement en agile/devops; la technologie impliquant un travail étroit entre les équipes de développement et celles en charge du déploiement/exploitation. (A titre personnel je n'ai rencontré que de très rares projet kubernetes qui ne soit pas sur ce modèle). 1.3 (plateforme détestée) https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-platforms-dreaded5 Nous ne commenterons pas la présence de WordPress au top1 😛 14 - AWS 33.6% 15 - Kubernetes 28.9% 16 - Docker 26.4% Pour autant, bien que les précédents points glorifient ces technologies il n'y a pas de lumière sans ombre. Kubernetes sont en bas de ce classement (donc c'est positif) cependant les pourcentages sont quand même notable. Sans plus de détails sur les causes de ces votes je vais extrapoler à partir de mon expérience. Principale cause, à mon sens, les développeurs doivent désormais s'occuper de l'aspect packaging et parfois avec des problématiques système ce qu'un développeur n'apprécie pas toujours (souhaitant se concentrer sur les problématique fonctionnelles/code). L'organisations en service/microservice impose de penser les applications d'une nouvelle manière ce qui n'est pas toujours simple. Il est même parfois plus simple de faire "à l'ancienne", c'est parfois la raison d'un échec projet : avoir voulu utiliser les technologies tendances alors qu'elles n'avaient pas forcément de plus value et on entrainer un "enfer de nouveauté" (transition technologique, problème de maturité etc...). Notons également le changement des habitudes des développeurs sur l'écosystème avec par exemple la disparition des fichiers de logs en tant que tels et l'utilisation de commandes/outils pour consulter les journaux. Cela a été dans mon cas de nombreuses sources de conflit ("Les logs sont sur la sortie standard! Pas dans des fichiers!") . Egalement, lorsqu'il y a des "bugs" lié à la plateforme ceux ci sont parfois très complexe dépassant complètement les développeurs et peuvent parfois prendre un certain temps à être identifiés et corrigés (par Kubernetes ou par le cloudeur qui réalise une implémentation spécifique à son socle). Les cloudeurs tardent parfois à proposer les dernières versions kubernetes entrainant un gap pour avoir un correctif de certains problèmes. En point final, de très fortes différences entre le niveau d'expérience d' équipes sachant déjà faire du docker et les débutantes. Si nous pouvons déjà le voir entre 2 équipes "Java" (simple exemple) on rajoute à nouveau une surcouche de compétence en docker/Kubernetes pouvant encore creuser la différence. Nous pouvons aussi le voir sur la qualité des différentes images présentes sur le hub docker: il faut souvent savoir faire le trie. N'hésitez pas à commenter vos problématiques. 2. Technologies liées https://insights.stackoverflow.com/survey/2020#correlated-technologies Intéressons nous maintenant aux technologies liées avec un focus sur celles autour de la conteneurisation. Comme indiqué précédemment, Docker est très lié à Linux (et donc en complément à la pratique de bash pour étudier les problématiques système). Nous pouvons remarquer que les technologies qui gravitent autour de la conteneurisation sont surtout des bases PostgreSQL et des outils tels que Elasticsearch (c'est l'outil préféré pour le stockage des logs). Le succès de postgreSQL s'explique principalement par l'attrait des développeurs (et pour les mêmes raisons qu'évoqué au point 1 de kubernetes). Par contre son lien avec docker & kubernetes s'explique par sa très bonne conteneurisation (permetant un travail en local), sa flexibilité et sa capacité de mise à l'échelle avec notamment des implémentations cloudeur qui permettent une offre haute disponibilité (exemple: AWS RDS). Si redis est lié à Docker, nous pouvons voir qu'il est aussi lié à Kubernetes. Il s'agit tout simplement de la technologie retenue lors de besoin du passage en services qui permet de synchroniser simplement des états entre les conteneurs d'un même périmètre. Nous retrouvons AWS comme cloudeur principal des offres de conteneurisation mais je trouve étrange qu'Azure ne soit pas plus présent. Go est lié à kubernetes car les modules sont écrit en Go 🙂 Terraform et Ansible sont des outils classiques des approches Devops et s'intègrent très bien (bien que le besoin de terraform pour kubernetes soit, à mon sens, assez réduit étant donné sa capacité à décommissioner dynamiquement les ressources provisionnées) . Plus proche de kubernetes je rajouterai HELM et pour docker Compose. J'inclurai également Prometheus comme outil de consolidation des métriques qui est le couple recommandé (avec Graphana) bien que des outils propriétaires tels que datadog ont une progression notable ces 2 dernières années par leur intégration globale unifiée (un outil pour les gouverner tous). En terme de langages, j'ai surtout vu au niveau projets du nodeJS et du Java, mais cela ne semble pas se refléter sur ce sondage. 3. Le mot de la fin En espérant que la lecture vous a intéressé 🙂 Cet article est amené à évoluer selon vos retours ! Peut être le proposer en article/news Nxi ? (nécessite probablement une réécriture/adaptation)
  15. Je vais éviter de lister la somme des tests en jeux que tu connais par coeur qui montrent tout simplement qu'à part qq exceptions comme déjà dit + haut, IRL, on s'en balek de ta latence et de la BP sur une conf bien pensée. nadawak, je vais pas me fatiguer là 😫 Chez amédé, tout peut être laissé en tout auto, y compris le "ring", il n'y a rien à faire depuis les Ryzen 2000, c'est quasi inutile ===> battle royale dans les cordes... Pour les lecteurs, la fréquence Ring (bus) ou BCLK fait référence à la fréquence des composants autres que le processeur. L'augmentation de sa fréquence rend vite instalable les confs Intel d'ailleurs 🤪 car tout y passe (là non plus, je ne vais pas lister les milliers de posts de demande d'aide d'OC pour les Intel). De +, à partir d'un certain niveau de fréquence, le ratio 1:1 n'est plus respecté 👮‍♂️ et ne permet plus de gain voire même cause des pertes de perfs. Pis, ne regardons même pas la tension (VCore) à appliquer / appliqué au proc ⚡ ⚡ ⚡ (ha les CM qui jouaient de l'offset sans rien dire .... merci bien....). Concernant les Ryzen, le max RAM respectant ce ratio est de 3600 MHz pour les Ryzen 3000 (vitesse maxi du contrôleur mémoire intégré au CPU selon les données Constructeur est à 3200 MHz) et de 3200 pour les Ryzen 2000 (vitesse maxi données Constructeur est à 2933MHz). Itou pour le FLCK de l'Infinity Fabric. Une approche à base de 1700X chez NXI bien sûr (2017-2020) Et un de mes favoris qui dit tout ou presque ici. Suffit de regarder les résultats en jeux des 3700X, 3900X, 9700K et 9900K pour voir l'énorme INpact de ces histoires IRL (c'est juste de l'ironie bien sûr... 😱). Voilà, ce sera ma dernière contribution sur ce point dans ce post. 🔚 Aujourd'hui, c'est Ryzen, épicétou et ce, je le dis même avec un 6700K dans ma conf de 2016.
  16. Il n’empêche que la bande passante en écriture et latence RAM sont trop faible sur ces ryzen hormis le 3900x et les empêche de performer comme il devrait sur les jeux dépendant en mémoire. Je ne pense pas que la différence de bande passante sur le cache L3 compense car quand il y a plusieurs Go de texture à transférer du NVME à la RAM ou VRAM c'est pas quelques Mo de cache qui font la différence. Personnellement en OC ma ram fait comme un 3900x en bande passante mais avec une latence bien plus faible. C'est le défaut du profil XMP c'est bien pour commencer mais clairement pas le mieux que tu puisses faire avec ta ram. Le fait aussi d'OC le ring des intel améliore aussi pas mal la donne.
  17. Oui je vais attendre l'annonce déjà, et ensuite je verrais. je regardais les alims j'ai du la laissé la seasonic dans le panier, car je me demandais si avec un procc qui est plus gourmand je devrais pas changer car je suis en 550w Bon j'ai joué pas mal, c'est plutot niquel.
  18. Certains dans l'Alliance t'expliqueraient facilement le fonctionne de processeurs paramétrables qui s'adaptent à des taches/calculs spécifiques. Qui dit spécifique, dit développement spécifique et tu peux rencontrer des problèmes sur le long terme pour maintenir tes applications et quand tu comptes faire une évolution tu repars presque à zéro. Ainsi ce sont souvent des interconnexion maison pour relier l'ensemble des CPU ou GPU "grand-publics" optimisés pour la stabilité, les RACK, le refroidissement des salles et avec une haute capacité d'interconnexion mémoire... -> voir avec les spécialistes
  19. Attention à l'Inpact @toTOW!!!! Booom QloUé lE BEC la miniteam passe 3ème au classement 😄 A ce rythme là (mais j'espère que la mini-team Next PCinpact va se mobiliser!) on dépassera la mini-team France dans presque 3années 😄 Il faut se mobiliser pour y arriver plus rapidement !
  20. Bonjour @moustiqk, tu peux obtenir des réponses avec la liste des comptes du CERN sous FAH ici puisqu'ils partagent leurs puissances de calculs inutilisées sur FAH / folding@Home pour les besoins de la science et notamment les recherches sur le Covid-19 (tu peux également voir le compte NVIDIA avec le supercalculateur Saturn-V et autres !) L'ordi ou la grappe d'ordinateur que le CERN nomme "CMS-Experiment" possède presque uniquement des CPU et quelques GPU Nvidia sous linux. La différence de puissance entre CPU et GPU mais le CERN n'utilise pas de GPU pour ce supercalculateur là (à disposition de FAH en tout cas). La puissance entre CPU et GPU n'est pas comparable mais certains calculs ne se font pas sur GPU donc il y a besoin de tout. Si toi aussi tu veux rejoindre l'aventure et exploiter les ressources inutilisées de tes machines pour la recherche sur le COVID et d'autres recherches en open-source, PCinpact à une mini-team au sein de l'alliance francophone. Chaque calcul de projet nous rapporte des "points" et il y des classements pour s'évaluer face aux supercalculateurs ou d'autres. L'Alliance francophone à de l'avance sur le CERN pour 2 semaines mais il faut nous aider 🙂 ! https://forum.zebulon.fr/topic/221153-folding-les-tutos/ Voici une partie des CPU utilisés par le compte du CERN "CMS-EXPERIMENT". Beaucoup d'autres informations intéressantes sur les CPU/GPU sont sur les forum des mini-teams, de l'alliance. Il y à beaucoup de documentation sur les capacités de calculs sur FAH (entre le rendements des carte vidéo/CPU ou l'analyse des consommations, également l'Alliance à un monitoring de certains actifs pour surveiller les machines, etc.. A découvrir! Ci-dessous l'image de liste (incomplète car très longue) des CPU/GPU du compte CMS-EXPERIMENT du CERN Au plaisir de te compter parmi nous.
  21. Yes. Le 510 elite est très décrié. Les versions "i" sont avec le contrôleur de ventilateurs qui a l'air pas idiot. Il y a une différence de 40€ ... à voir si nécessaire. Côté proc, je viens de voir des rumeurs sur le prix du 3600 xt à 319€ via materiel. A ce prix, j'opterais plus pour le 3700x du coup...
  22. Une Lamborghini Sian en Lego Technic (sortie ce jour) 😄
  23. Le H510 est une révision du H500. Laisses béton la version Elite, c'est le pire choix des 3 versions en termes de refroidissement. Je regardais la version de base de mon côité, même le 510 i ne me fait pas tourner la tête. Selon les bruits de moquette, le prix Constructeur du 3600XT sera très proche de celui du 3600X. Après, il y a tout ceux qui sont dans la chaîne de distrib.
  24. Yesterday
  25. Bonsoir, Suite au non-succès de mon dernier sujet (merci le COVID !), j'ai finalement opté pour une autre solution : recycler les pièces pour en faire un PC de salon. Je dispose actuellement d'un NUC (dont l'estimation est ici) qui fait bien le travail (lecture de vidéo en 1080p, Youtube via Kodi/LibreElec, plutôt silencieux) mais ça s'arrête là. J'ai eu l'idée de recycler mon vieux PC afin de pouvoir en demander un peu plus : sauvegarde de données, VM, Kodi, émulation, téléchargements nocturnes, ...) et je me suis rappelé que passé un temps, les boîtiers HTPC étaient bien à la mode. Je suis bien conscient que je devrais abandonner certaines choses (la carte graphique par exemple) mais ma priorité reste d'obtenir un PC silencieux, quitte à avoir quelques frais (genre, changer le ventirad). Si vous avez des idées ... 😉 Merci.
  26. Bonjour, Suite à un projet, je souhaite me débarrasser d'un "vieux" NUC Intel (référence BOXNUC5CPYH) afin de pouvoir recycler les pièces de mon ancien PC, plus véloce. Néanmoins, je parviens pas à vraiment estimer le coût de la bête étant donné que le tarif a pas baissé mais augmenté ... Pour un mini-PC de 2 ans, est-ce raisonnable de le laisser partir à 100 € ? Puis-je espérer plus ? Merci à vous 😉
  1. Load more activity
×
×
  • Create New...