Reprise du message précédent :

Je suis qqun animé de mauvaises intentions, la première chose que je fais, avec ton système, c'est d'usurper l'identité d'une appli whitelistée/légitime

Comment ça fonctionne votre bout de code au faire, j'aimerais tester sur mon vieu coucou

tu crées un fichier pti.c contenant ce code :

tu le compiles en tapant cette commande :

puis tu l'exécutes en tapant "./pti"

chez moi j'ai ça comme score avec un intel core 2 quad Q9650 et le noyau linux 4.14.9 :

ça donne ça avec mon i7-3770k@4Ghz sur le noyau 4.14.11-1-ARCH :

Hop, ici avec un Phenom II X6 @3.7GHz, noyau 4.14.11 :  

Un peu divers et variés ces résultats.

Divers et variés parce que nous n'avons pas les même CPU.

on remarque quand même une sacré baisse des performances à cause du patch, ça fait peur,
 
faudrait tester l'impact sur une machine virtuelle, un windows tournant dans virtualbox, ça doit faire mal aussi,
 
puis une compilation du noyau linux, d'un gros projet pour voir si les temps de compilation augmentent fortement

Avec pti=off :

 
Sacrée différence !

Apres faut voir aussi ce que fait le code... Il est clairement écrit pour ce problème en particulier, les tests de Phoronix sur des jeux ne montrent aucune difference.

Je l'ai précisé, ce n'est pas représentatif d'un cas d'utilisation courante. Simplement afin de se faire une idée du temps bouffé par les patchs.
 
Ce bout de code demande 100M (ouais +1 ) de fois, via un appel système, quel est son propre PID. Et au passage donne le temps d'éxecution.
 
Bien evidemment, aucun programme n'a besoin de connaitre son PID trouzemille fois.

Un programme schizophrène peut être, pour se rassurer.

Un vrai programme schizophrène obtient toujours 2 réponses différentes au getpid (au delà de 2, c'est une coloc )

4.14.11-1-zen #1 ZEN SMP PREEMPT Wed Jan 3 07:02:02 UTC 2018 x86_64 GNU/Linux  
Rizen 1800x
1693
4.292849
 
Z'ont peut-être pas mis le patch avec le noyau zen?

Pour le patch, sur un core i5-2520M Thinkpad x220, 22s vs 5s
Sur Arch par contre, ça fait 2 mois que je suis dessus, j'avais des doutes, je me disais au niveau stabilité etc. mettre les mains dans le cambouis... bah, mon petit Thinkpad ronronne du tonnerre (régulièrement des uptime de plus de 10j)
Impressionné, je dis oui!  

Visiblement c'est désactivé : https://git.archlinux.org/svntogit/ [...] ages/linux
 
C'est vérifiable via :

Par contre, question con, mais peut-on se passer du correctif si on tourne sur la dernière version de Firefox ? Vu qu'ils ont corrigé le problème directement sur le navigateur (voir ça : http://www.androidpolice.com/2018/ [...] abilities/ ) ... ou les failles impactent d'autres logiciels ?

Idem, j'suis passé sur Arch avec le pc du boulot, donc sensible mais j'aime les défis. Seulement un petit soucis en 4 mois et encore c'était rien du tout : un soucis de dépendance dans une maj d'insomnia. Ca se règle en 2 seconde et voilà.

C’est pas des failles spécifiques aux navigateurs (ce serait pas autant la panique, sinon) : elles permettent, entre autres, de récupérer directement en clair le contenu de la RAM, et de faciliter la création de keyloggers.

L’ennui, c’est que si Meltdown et une des deux failles de Spectre sont « facilement » corrigibles de manière logicielle, la deuxième – évidemment, celle qui concerne toutes les plateformes depuis 23 ans – ne peut l’être sans changer carrément le CPU par un modèle matériellement corrrigé. Sauf que ça revient à dire qu’il faudra carrément changer de machine (pour les PC portables et les tablettes/smartphones), voire de carte-mère (pour les PC de bureau, de préférence montés par soi-même ou par un assembleur), car je doute qu’Intel sorte une version corrigée de mon Core 2 Duo P7450…

Les débianistes crachent sur Arch en disant que c’est une distro instable. Sauf que non : à moins d’utiliser les dépôts « Testing », les versions des paquets disponibles sont en principe les versions finalisées (les mêmes que celles proposées pour Windows au même moment), considérées comme stables par les créateurs des logiciels concernés. Et un paquet ne rentre dans les dépôts officiels qu’une fois testé, ce qui fait qu’il arrive que certains arrivent quand même avec un peu de retard, même sur Arch. Par exemple, une nouvelle version du noyau : Linux 4.15 finalisé ne devrait être proposé dans les dépôts normaux qu’à partir de la version 4.15.3, pas avant. D’ici-là, les utilisateurs d’Arch Linux resteront en 4.14.x. Alors que Debian va rester en 4.9 jusqu’à la sortie de Buster (dans un an ? D’ici-là, on aura peut-être vu passer deux versions LTS de Linux).

Comme le dit le développeur de XScreenSaver : il ne faut pas confondre « stable » et « antique ».

Ok, je comprend mieux, merci pour la réponse

 
tu as un CPU amd, le patch ne concerne que les CPU intel

Debian reste en 4.9 par défaut, le 4.14 est dispo si on le veut mais pourquoi? On ne modifie pas tous le hardware tous les mois. L'avantage avec Debian c'est qu'on peut avoir des mises à jour miniatures avec la garantie que le pc ne va pas bouger pendant toute la durée de vie de la version de la distro. C'est un avantage pour qui ne veut pas / ne peut pas réapprendre trop souvent à utiliser son pc.
 
Il ne faut pas confondre administrer son pc sans cesse et l'utiliser.

debian avec des vieux paquets c'est surtout bien en entreprise quand on utilise un serveur qui fait tourner tout le temps la même chose sur du matos qui bouge jamais, ça évite les problèmes d'api qui change, de bug de régression, on a un système qui est gelé avec juste les correctifs de sécurité,

par contre debian "stable" ça va pas trop le faire sur un PC desktop à la maison, l'utilisateur lambda veut souvent utiliser les dernières versions des logiciels pour avoir la dernière fonctionnalité à la mode, la dernière version de plasma qui va bien, il veut aussi que sa clé tuner TNT usb ( qu'il vient tout juste d'acheter ) fonctionne, comme debian ça utilise des paquets pas très récents alors le noyau linux risque d'être à une ancienne version, qui ne contiendra pas les pilotes les plus récents pour le matos, ainsi que les correctifs

On est bien d'accord, chaque distro a son public et son usage. Elles ne sont pas interchangeables, c'est pour cela qu'il y en a autant, même si on ne prend en compte que les plus connues.

 
Ca dépend des personnes. J'avais une tour PC avec un GPU AMD donc là oui la question ne se posait pas, je passais sur Gentoo ou Arch pour être sur d'avoir la dernière version de Mesa. Par contre, depuis que je suis passé sur GPU Nvidia sur mon laptop, je suis resté sur Debian Stable. Via les backports, j'ai le Kernel et les drivers qui ne sont pas si ancien même si la vitesse de MAJ est pas aussi rapide que sur une RR comme Arch. Après pour les autres applications et DE, les versions de Stretch me conviennent parfaitement.  Il y a juste Firefox que j'ai téléchargé sur Mozilla sans passé par les dépôts Debian. Sinon, je ne cherche pas à avoir la dernière version de Mate ou VLC car tant que ça fonctionne et que ça ne m'apporte rien de plus de mon utilisation au quotidien, pourquoi passer en RR ?

 
Trop même. Tellement d'énergie investie dans des nouvelles distribs pour au final mourir un an après

 
C'est la sélection naturelle. Ca permet d'expérimenter des nouvelles choses sans tout péter.
Le développement est pas forcément perdu si c'est intégré dans une autre distro ou packagé proprement (typiquement toutes les variantes d'ubuntu).

Cela commençait à devenir un peu confus avec l'histoire des 2 failles donc je pensais qu'au final AMD était aussi impacté. Après, en zieutant le test phoronix, il semblerait que l'impact soit relativement nul hors 1 ou 2 cas.

1. Correctifs de sécurité mis à part, si les nouvelles versions du noyau ne font que changer le nombre de pilotes pris en charge, c’est sûr que tu vas pas vraiment en avoir besoin, sauf à être dans le cas présenté par Elbarto.
 
2. Perso, administrer mes Arch se limite généralement à vérifier et installer les dernières MAJ le matin, après avoir déjeuné. Après, j’ai rarement de raisons de faire plus que de l’utilisation classique pendant le reste de la journée, jusqu’au lendemain.
 

On est bien d’accord.  
 
 
Ah, mais il n’a jamais été question de vouloir te forcer à quitter ta Debian pour passer sur Arch (si tu le fais, ce sera toi qui l’auras décidé). Je disais juste, au départ, que les gué-guerres entre « distros fixes, voire très fixes FTW » contre « elle est fraîche, ma rolling » sont en grande partie dues à une incompréhension mutuelle de la part des deux « camps », à cause d’idées préconçues.

i7 4790k

Avant :
1211
3.571401

Après :
1208
13.998673

:-/ Bon ben ma machine est dédiée calcul pour usage pro donc je vais rester pti=off le temps que je prennes le temps de faire des benchmarks sur les softs que j'utilise ...

Debranche la du net alors.

Après quelques benchmark, 0 influence sur mon usage sauf postgres je laisse donc en défaut c'est à dire pti=on

il faudrait que quelqu'un teste les conséquences sur une machine virtuelle,
 
par exemple un windows 7 qui tourne dans virtualbox, le host étant archlinux,  
 
l'idée est de voir chez un particulier ( PC desktop ) si ce patch a un impact négatif sur les logiciels qui utilisent la virtualisation, les CPU modernes ont des fonctions de virtualisation, et je me demande si ce patch va faire chuter les performances

Perso j'ai un Archlinux LXDE qui tourne sous Virtualbox, avec W10 comme système hôte et je ne vois aucune différence.
Pourtant Windows a reçu le patch de sécurité.

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

Rien de tel sur mes deux machines tournant sous Arch (aussi bien portable que tour). Je dois pas avoir une carte du modèle qui cause ces messages.

Rien non plus pour moi

je suis en train de tester le noyau 4.15.0-rc7-mainline pour voir si le problème a été corrigé,

à noter que malgré les messages d'erreur les cartes PCI fonctionnent quand même

le problème semble avoir été résolu avec le noyau 4.15.0-rc7

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 en mode plein écran :
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

Hello !  
 
Je souhaite m'essayer à Arch. J'ai déjà Ubuntu au taff, Mint KDE sur un de mes PC et Ubuntu sur le HTPC.
 
J'aime bien l'idée de l'OS libre, mais j'ai horreur de l'interface et de la double bar qui empêche de cliquer aveuglément sur le bouton fermer par exemple.
 
Bref, vous me conseillerez quoi comme bureau ? Apparemment KDE est recommandé sur Arch, je cherche quelque chose d'assez Windowsien...
 
Autrement, le bureau Deepin, vous avez testé ? https://www.youtube.com/watch?v=pDHjL8T4VdQ&t=632s