Reprise du message précédent :
Il me semble que nvidia n'a pas releasé les firmwares signés pour l'instant donc y'a probablement aucune feature "avancée".
Pour power management et compagnie c'est pas la peine d'y compter, c'est pas du tout fini / automatique sur les générations précédentes.

J'ai beau supporter à 100% le libre, je trouve ça tellement gâché d'acheter une carte graphique haut de gamme à 500 - 600 € et la brider avec le pilote libre nouveau qui lui offrira les perfs d'une carte graphique à même pas 50 €...

Su tu veux absolument du libre et une CG haut de gamme, va chez AMD.
J'ai la Rx480 et avec Mad Max, Warhammer et dernièrement Deus Ex, ça tourne très bien...

je test un truc, étrangement je peux pas éditer le premier post pour l'update ...

C'est un peu le cœur de ma question
Faut pas exagérer non plus, mais oui je comprends bien, c'est une histoire de compromis.
Une stack non libre c'est chiant aussi sur une distrib comme Arch si on veut profiter des nouveautés assez vite.
 
 
Vu que le support des GTX10X0 est pas mature je pense que je vais repartir sur cette idée, qui était l'idée initiale
J'attends de voir le prix de la future rx 49X

Si tu veux tourner sur du libre, autant supporter une compagnie qui supporte le libre...

salut, je me demande une chose, un patch qui m'intéresse ( http://www.spinics.net/lists/netdev/msg448040.html ) a été soumis récemment, comment je peux savoir si / quand / dans quelle version du noyau il sera intégré ? c'est quoi le processus ?

Tu peux suivre les mailing lists, ou bien regarder de temps en temps sur git.

Tu pourrais aussi te l'inclure dans ton noyau jusqu'au jour ou ca na patch plus et tu sauras qu'il est dedans

Sinon le 4.9.1 il est vieux

ou sinon envoyé un mail à Miller

comment bien commencer septembre

n'apparaît que depuis 4.13 (et supérieur)
en attendant un correctif, il faut appliquer ce patch https://patchwork.kernel.org/patch/9885051/

edit : patch appliqué, tests effectués, ça roule.

j'en profite pour dire que tous ceux qui ont une clé Wi-Fi avec cette puce (Wi-Fi AC)

peuvent enfin en profiter depuis 4.12

bien bien. 4.14 RC-1 pilote recompilé et installé, non reconnu
dommage

 
bon je me réponds si jamais ça intéresse quelqu'un maintenant ou plus tard : en allant sur https://www.kernel.org/ et en cliquant sur "browse" sur la dernière version, on a une liste des patches et on peut faire un recherche (en haut à droite). En l'occurence j'ai retrouvé mon patch en 4.14.

Meltdown et Spectre sont en tendance France https://twitter.com/hashtag/Meltdow [...] 9405096960
 
ça fait parler

le "spectre" ça fait penser à James Bond, c'était un des méchants charismatique de la série et des romans
 
https://fr.wikipedia.org/wiki/SPECTRE
 
 

 
ils en ont même parlé sur les médias généralistes type france info/rmc, en mode anxiogène "attention un pirate pourra maintenant récuperer votre mot de passe rien qu'en visitant un simple site web"  

L’article du Fig' est plutôt pas mal pour du généraliste.

avez-vous remarqué ce genre de messages dans dmesg depuis le noyau linux 4.14.11 ?  
 

 
j'ai 3 cartes PCI : une carte son et 2 cartes tuner leadtek,
 
ces messages apparaissent tous les 5 à 6 boots, j'ai ouvert un rapport de bug

 
 
J'espere etre au bon endroit....
 
Dans le cas d'un dd crypté sous ubuntu par exemple,avec des phrases et mdp cossus,quelles sont les chances qu'un utilisateur "lambda" qui "trouve" mon portable puisse exploiter les fichiers?

la plupart des pirates sont loin d'être des génies informatiques, ce sont surtout des "script kiddies", qui ont trouvé un tutoriel sur internet qui explique comment exploiter une faille de sécurité, ils lancent un script, un programme qui fera le boulot à leur place, quelqu'un de débrouillard qui veut par exemple se faire de l'argent facile via les ransomwares,

pour trouver les mots de passe le pirate va utiliser un dictionnaire contenant les mots de passe les plus utilisés ( noms propres, héros de cinéma/télé, les mots comme azerty, admin etc... ), si ton mot de passe est suffisamment long et fort ( généré aléatoirement à partir de chiffres, de lettres, de caractères spéciaux ) alors tu risques pas grand chose,

autre technique de piratage : l'ingénierie sociale en exploitant les faiblesses humaines, la naïveté ( quelqu'un qui t'enverra un mail en se faisant passer pour ton banquier ou ton patron, et qui demandera tes identifiants ), la déduction en étudiant le mode de vie de la personne, son compte facebook, twitter,

peut-être qu'un gouvernement, une organisation type NSA peut finir par arriver à décrypter ton matos si utilisation d'un ordinateur quantique qui coûte 3 milliards ou présence de backdoor mis par l'auteur du système d'exploitation, de l'algorithme de chiffrement

Tu peux lancer John The Ripper dessus et voir combien de temps ca prend, si ca finit un jour.

Le dictionnaire n'est qu'une technique possible

Merci.
Vous confirmez aussi que s'il ouvre le dd en le branchant sur son pc il ne verra aucun fichier en "clair" ?!

oui

Je suis encore sur un 3.10 ici, surtout par flemme.
 
Il a été LTS mais il n'est plus sur la page d'accueil de kernel.org et le dernier patch de la dernière version l'a renommé en "END-OF-LIFE", donc par rapport à meltdown&spectre, c'est mort de chez mort je suppose ?

Sauf si ta distribution le supporte encore.

4.9.1  

 
Non, justement.
 

 
Le kernel ne fait plus rêver...
mais autant virer la version du titre du coup.

vous mettez combien de temps pour compiler le noyau linux ?
 
avec un core 2 quad Q9650 ça a mis 1h30 ( avec l'option make -j 4 ), je ne sais pas si c'est un temps normal,
 
avez-vous constaté un temps plus long de compilation depuis l'application des patchs spectre et meltdown ?

Ça doit pas rallonger le temps de compilation non. Sinon regarde sur Phoronix (enfin Open Benchmarking), ya une grosse DB avec des tests de compil' du kernel sur plein de CPU différents.

je précise que j'utilise un disque dur 7200 tours ( pas de ssd ), ça peut expliquer le temps plus long

J'ai envie de dire que ça dépend très grandement des options activées

C'est sur que si tu compiles le noyau avec les .config de Debian/Arch et compagnie tu risques de perdre du temps ... Avec un I7 et mon .config aux petits oignons, c'est même pas 2 minutes.

en effet, en utilisant  "make localmodconfig" ça va nettement plus vite, 6 minutes pour compiler le noyau avec uniquement les modules nécessaires à ma configuration

j'ai remarqué une baisse de performance avec le noyau 4.15.rc8 mainline pour le streaming youtube, par exemple sur cette vidéo 1080p@60fps c'est pas très fluide en plein écran, il y a des micro-saccades :

https://www.youtube.com/watch?v=CcUXxM_rbAM

par contre si je teste avec le noyau stable 4.14.13-1 c'est fluide à 100%,

j'ai une carte graphique amd radeon HD4650 pcie, j'utilise le pilote libre radeon

[AMD/ATI] Kabini [Radeon HD 8210] ici, et les vidéos 60 fps ont toujours ramées

tu as quoi comme CPU ?

j'ai un intel core 2 quad Q9650 3 Ghz,

essaie de comparer entre le noyau 4.14.13 ( noyau stable ) et le noyau mainline 4.15.rc8, logiquement tes lags vont s'aggraver avec le noyau 4.15rc8, perso j'utilise firefox ( youtube avec le mode html5, pas de plugin flash )

j'ai ouvert un rapport de bug, un développeur m'a demandé de faire un bisect pour identifier le commit qui a introduit le bug, je vais voir si j'ai le temps de le faire

Si tu penses que ca vient de changements du DRM, il sera peut-être plus rapide de le faire sur drm-next et pas sur linux-mainline. Apres si ce n'est pas le cas, ca sera du temps perdu...

vu que le bug n'existe pas dans le noyau 4.14 et qu'il est apparu dans le noyau mainline 4.15.x donc logiquement avec un bisect il sera facile de trouver le commit responsable du bug,
 
il me semble que tout changement dans le noyau mainline finira par apparaître dans le noyau stable, donc il y a interêt à vite trouver le commit coupable, sinon le prochain noyau stable 4.15 va avoir le même problème

Ah bien sur, je disais juste sur quelle branche faire cette dichotomie.

 
AMD A4-1250 APU with Radeon(TM) HD Graphics    
 
avec firefox ta vidéo la vidéo est toujours saccadée, mais le son est fluide. avec chrome tout fout le camp
peu importe le noyau

je pense que ton problème vient en fait de ton CPU qui n'est pas assez puissant ( seulement 1 Ghz, 2 coeurs ) pour les vidéos youtube 1080p@60 fps,

la comparaison avec mon vieux CPU d'il y a 10 ans :

la solution serait que le décodage du streaming youtube puisse se faire à 100% par la carte graphique, accélération graphique h264, là c'est jouable avec ta carte graphique, ce qui soulagerait le CPU,

mais visiblement par défaut les navigateurs internet n'ont pas la possibilité en html5 d'activer l'accélération graphique, ou alors il faut bidouiller mais j'ai pas trouvé de tutoriel, du coup ça repose beaucoup sur la puissance de calcul du CPU

dans tous les cas ce qui est sûr de mon coté c'est que le noyau 4.15rc8 entraine une regression dans la lecture youtube de vidéos 1080p@60 fps ( à 30 fps ça va encore ), il y a des micro-saccades perceptibles quand on a une carte graphique radeon HD4650

720p@60fps sur cette vidéo, aucun soucis O_o : https://www.youtube.com/watch?v=cTNd3h9HC8A
 
étrange ...