Anonyme a écrit 62265 commentaires

Je pense que vous avez une typo, ce n'est pas Yancy mais YaCy.

Il y a tout plein d'infos dans les journaux précédents: https://linuxfr.org/users/vejmarie

Oui le problème de faire bande à part est très critiquable, que ce soit avec les standards comme l'Adaptive Sync ou le noyau Linux.
D'un autre côté leur suivi et leur pilote sont assez exemplaires pour du propriétaire, perso je n'ai jamais eu de régression ni de bug et même du matériel de génération Fermi tourne avec la dernière béta 390.12 (qui vient corriger des vulnérabilités de Spectre) On verra plus tard ce que ça donne avec Wayland.
En attendant je suis bien ennuyé pour changer de carte graphique parce que pas envie de continuer avec le blob Nvidia mais les tensions des cartes AMD récentes ont été poussées inutilement et mes multiples recherches me font conclure qu'il n'y a pas d'outil d'undervolting fonctionnant avec le pilote libre, même en changeant le VBIOS de la carte graphique.

Ton problème c'était que nouveau a un bug avec ta carte graphique. C'est tout de même très étrange que Linux, faute de pilote fonctionnel, ne bascule pas sur le pilote vesa par défaut.

Bref, te voilà parti dans les joies de la recompilation du module nvidia à chaque mise à jour du noyau. Sur Debian/Ubuntu, sgfxi pourra alléger cette tâche.

Faut compter je pense sur 2019 / 2020 pour avoir une généralisation des différentes corrections au sein de tous les produits de tous les fondeurs impactés.

C'est très optimiste, les fabricants de processeurs ont plutôt des projets qui prennent quatre à cinq ans de recherche et développement.

Si on parle de Meltdown, Intel proposera certainement une correction hardware d'ici deux ans pour mitiger la baisse de performance et se mettre au même niveau que les autres. C'est ça la correction "facile" mais ça n'est que la surface.

Pour Spectre, c'est toute la mécanique d'exécution spéculative et de prédiction de branchement qui est à revoir donc on touche vraiment aux fondements des processeurs et là ce sera plutôt quatre ans (donc plutôt Zen 2 ou 3 que le prochain Zen+ chez AMD). De plus, c'est un nouveau vecteur d'attaque entier à explorer donc on va certainement trouver d'autres choses.

Comme un lecteur a tenté de te le rappeler d'ailleurs.

"tenter" le mot est fort. C'est qu'une citation.
D'ailleurs ta réponse était à peine meilleure. Mais merci d'avoir ensuite explicité.

Le fait que ça vole en éclat avec ces failles, et pour tout le monde en même temps, remet sérieusement les pendules à l'heure.

Pas tout à fait. Il reste les failles de l'Intel ME (on en a eu une belle l'année dernière) et celles à prévoir du côté du PSP d'AMD qui repose sur Trustzone (qui a déjà été exploité). Power garde l'avantage d'avoir moins de surface d'attaque potentielle et ce indépendamment de l'hyperviseur.

Si je t'ai fait connaitre ou découvrir powervm, j'en suis ravi.

J'ai aussi découvert IBM i, je ne connaissais que AIX. :)

Pour un JV tout ce qui relève de l'art est tout ce dont on peu admirer la beauté en utilisant juste ses sens le reste étant de la technique qui elle n'est pas accessible aux novices.

Déjà, il y a plein de choses culturelles ou symboliques plus ou moins cachées dans les œuvres d'art donc ça n'utilise pas que les sens mais aussi l'intellect et la mémoire et tout le message n'est pas accessible par le novice. L'art n'est pas universel.

Ensuite, la technique elle-même a une forme de beauté, de sensibilité et tout ce qui différencie l'artisanat de l'art au niveau législatif (et surtout fiscal) c'est le fait de produire quelque chose qui a de l'utilité autre qu'esthétique.
Toute production artistique demande avant tout du savoir technique.

J'ai du mal à voir en quoi un JV participe au bien commun, cela n'est pas vital dans notre monde moderne.

La plupart des activités humaines ne sont plus vitales de nos jours.
Le bien commun c'est aussi la culture et le savoir, le JV est utilisé à des fins pédagogiques, éducatives, thérapeutiques et expérimentales dans divers domaines, en quoi ces outils sont différents des outils classiques pour mériter d'être exclus du bien commun ?

je suis pour le salaire de subsistance qui permétrait au gens de de vivre et de s’épanouir dans des domaines qu'ils aiment.

Donc, encore une fois, pourquoi exclure la création de jeu vidéo et par extension le domaine artistique et le divertissement ? C'est pas cohérent. L'humain a de plus en plus de temps libre pour faire autre chose que produire de l'utile.

La version proposée dans le paquet debian n'est pas très récente. Mais si c'est pour reproduire un tutorial qui date de la même époque, ça peut être pratique.

Si vous compilez le code, une version stable est disponible sur leur site, c'est probablement le meilleur choix.

Sinon, le binaire de Salome-méca (1.4 Go) sera très bien.

Pour ses premiers Atom, Intel a eu la fausse bonne idée d'utiliser des processeurs graphiques PowerVR dont le support est mauvais, même pour Windows. Ça a tellement bousillé l'image de la marque "Atom" que depuis seuls les modèles serveur et embarqués ont gardé ce nom et les modèles grand public sont appelés Celeron/Pentium N ou J malgré de nouveaux modèles contenant leur GPU maison HD Graphics ayant des pilotes libres.

Actuellement la seule façon d'avoir du 12V en entrée c'est de prendre un modèle ITX normal avec le port d'alimentation ATX 20/24 broches et de lui ajouter une convertisseur de tension de type Pico-PSU.

Pour la mémoire, même si c'est de la DDR3 1066 tu vas avoir des problèmes de compatibilité avec les processeurs récents donc vérifie bien les spécifications des cartes-mères que tu veux acheter.

Non. Tu prends une faille qui touche tous les fabricants et là dessus tu ironises sur le marketing d'IBM. Je vois pas en quoi ton propos est constructif.

donc c'est difficile d'utiliser du code non LIBRE.

Non c'est simple : je fourni un programme et je fous des restrictions dessus (accord de non-divulgation, restriction de l'utilisation, interdiction de modification) et si tu les respectent pas je t'attaque en justice.
Tu confonds licence libre et sources partagées.

et eux doivent pouvoir protéger leurs œuvres.

En quoi c'est différent par rapport à faire un logo, une image, une charte graphique, des éléments sonores ou une composition intuitive des éléments affichés à l'écran pour un autre type de logiciel ?
Et où places-tu la limite entre programme et JV ? Est-ce qu'un mod manager ou un launcher font partie du jeu ? Est-ce que l'éditeur de niveau inclus dans le binaire n'est pas en soi un logiciel distinct du jeu en lui-même ? Est-ce que le serveur pour du multijoueur fait partie du jeu ? est-ce que le moteur de jeu est inclus dans ta définition ?
Si le manuel d'utilisation ou le tutoriel d'un logiciel "sérieux" est écrit en alexandrins, est-ce que ça compte pour pouvoir "protéger son œuvre" ?

L'art libre ainsi que l'art non-commercial existent déjà, regarde les journaux et dépêches ici-même pour en avoir un aperçu.

recevoir un salaire des états qui seraient payé par une partie de l'impot car les dev libre contribuent au bien commun selon moi.

Certes mais en quoi ça diffère du JV ? Pourquoi ne pas vouloir appliquer ton principe marxiste à tous les artistes ? Et comme tu le sous-entends, en quoi l'art et le divertissement ne participeraient pas au bien commun ?

et le correctif pour l'ESR c'est fin du mois

Sous android j'ai pas l'impression que ce soit plus lent mais des personnes se plaignent de la lenteur sur le play store…

Les raisons peuvent être diverses entre les appareils avec des SOC ARM in-order déjà limites en charge, les serveurs à l'autre bout qui doivent parfois être impacté en terme de latence et les biais de l'effet psychologique.

mmh, je vois que c'est toujours un peu la misère avec systemd que init, :)

promesse non tenu

Les autres failles bientôt

Faut pas compter la dessus, la seule correction à Spectre est le changement de matériel.

Si on utilise un processeur JAVA il est possible de faire autre chose que d'utiliser du logiciel libre avec.

Sur une machine lisp aussi, suffit de ne pas partager librement son code. Puis comme on peut le voir dans l'informatique actuelle, on peut avoir un OS open-source avec des modules propriétaires, même la GPL le permet. Enfin, il y a des boites qui s'en tapent et qui repompent du code GPL dans leur blob comme si c'était du BSD.

Comment faire je ne sais pas

Pourtant avec la phrase précédente, tu sous-entends que ce n'est pas possible de le faire sur une machine lisp pour balayer l'idée de la machine java. Tu manques de cohérence.

C'est pour ça que je veux que les logiciels privateur meurent sauf dans le cas particulier des jeux vidéo.

Ah bon pourquoi une exception ? Que tu considères le JV comme un art ou comme un divertissement il n'y a aucune raison que ce type de logiciel en particulier soit épargné, c'est aussi du savoir.
Ça faciliterait énormément la portabilité et la maintenabilité au fur et à mesure de l'évolution de l'informatique plutôt que se taper les DLC, les émulateurs, machines virtuelles et interpréteurs, les libs i386 en doublon, les jeux codés à l'arrache qui respectent pas les API graphiques et nécessitent des profils particuliers dans les pilotes de CG, les bugs foireux pas MÀJ, etc.

Le mec qui a fait uBlock Origin, un certain Raymond Hill, a également fait uMatrix, une super extension pour gérer cookie / css / images / javascript et autres joyeusetés.

La faille Spectre touche la totalité des processeurs out-of-order donc rien ne vole en éclat plus qu'ailleurs.

Ça se fait déjà : Tu cherches du boulot en parallèle et tu ne reviens pas de vacances dans ta précédente entreprise. Par contre tu risques de passer aux prudhommes donc mieux vaut ne pas être solvable.

Ce qui fait la différence est peut-être le manque d'instructions AES.

Si, c'est le trait horizontal en haut à gauche de l'EEPROM

Ah oui c'est discret. Trop vu la place à cet endroit.

perso je préfère les pastilles carrés sur la patte 1 au moins on est sûr de ne pas se tromper.

Oui ça reste lisible même si la sérigraphie est abimée. Surtout que ça a été utilisé pour les connecteurs

Les détrompeurs des mosfets sont sous les composants.

Oui j'avais bien vu le point sur la vidéo mais sur le rendu j'ai pas tilté. Un peu de fatigue :)

Le schéma électrique est présent dans le projet Kicad.

Merci, je ne savais pas qu'on pouvais l'y inclure, je fais que de la réparation et de la conception sur plaquette d'essai, donc je connais pas ce genre de logiciel. Je m'attendais à le trouver en pdf dans /schemes/ ou avec le manuel dans son dossier de documentation.
Je pense deviner que c'est le anavi-light.sch vu la composition du fichier.

Petite carte assez simple mais bien pensée. Le mec sait router proprement des circuits imprimés.

Par contre la sérigraphie de la carte ne montre pas de détrompeurs pour l'eeprom. Et sur les pdf/svg il manque aussi ceux des mosfets (alors que curieusement c'est présent dans le fichier KiCAD présenté en vidéo : différence de version ?). Au moins les connecteurs sont bien indiqués sur la carte, c'est le principal.
Aussi, je n'ai pas trouvé le schéma électrique pourtant c'est par là qu'on commence la conception.
Ensuite le site Web n'est pas à jour, il faut chercher le manuel dans son github (d'ailleurs je ne comprends pas pourquoi la doc n'est pas dans les dossiers de chaque projet, mais bon). Par contre le device tree overlay dans l'eeprom n'est jamais fourni dans ses projets donc si a pas précautionneusement sauvé le contenu et qu'elle flanche faut se retaper toute la création.

Enfin une chose m'échappe sur la page du financement participatif : Pourquoi ralentir toute la production et la livraison en ne proposant pas de kits avec les composants traversants à souder soi-même ? Ça aurait aussi pu permettre un prix d'appel un peu plus intéressant.

J'ai un smartphone Nexus 5X et je vais donc recevoir dans les prochains jours le correctif de janvier de Google : je serai protégé.

Oui, mais en attendant le Nexus 5X a un gros problème matériel qui le fait redémarrer en boucle : https://duckduckgo.com/?q=nexus+5x+bootloop.

Pour les conseils sur les choix de vie numérique, on repassera.

DDR2 667 en SO-DIMM. Et j'imagine que sur cette gamme c'est pas de la ECC ou de la registered.

D'après NextInpact, la communication sur ce bug a commencé le 29 novembre:
"les partenaires sont prévenus, de manière plus ou moins rapide selon leur importance [..] Selon nos informations, le programme a débuté le 29 novembre dernier".

Et pour les stocks options, ce serait un peu pareil : "mi-décembre, The Motley Fool a évoqué le fait que le PDG Brian Krzanich avait vendu toutes les stocks options qu'il pouvait selon une déclaration d'Intel le… 29 novembre dernier, son rôle lui imposant d'en garder 250 000 au minimum."

OK merci :)

Déjà que les x86 ne brillaient pas en basse conso face à ARM, si on ajoute ce patch ça creuse encore l'écart.