Autant pour le FPGA c'est compliqué d'imaginer une chaîne complètement libre car les fabriquant protègent leur bébé. On voit mal altera ou xilinx balancer toutes les specs de leur dernier bébé fondu en 10nm et qui leur a coûté plusieurs millions de dollars de R&D.
? Même si tu as une chaîne logicielle totalement libre, il faut bien que tu l'achète le FPGA, donc je ne vois pas trop en quoi ça coûterai de l'argent au fabriquant.
Ou alors ils se font de la marge sur le composant ET sur les outils de programmation?
Il me semblait que ça n'était pas le cas et qu'ils ne vendaient pas les outils de programmation de manière indépendante (l'achat du FPGA te donne le droits d'utiliser les outils de programmation (au moins ceux de base)), quelqu'un peut confirmer/infirmer?
Je ne suis pas fan non plus du design de Wayland (j'aurais préféré un "X12") mais bon n'oublie quand même pas qu'on parle d'un remplacement d'X11 qui coté sécurité est totalement nul donc ça reste une grosse amélioration pour la sécurité.
Après, toute cette duplication de code c'est vrai que ça pique..
J'avais compris mais je pense quand même qu'il est important de faire remarquer qu'avec Wayland, pour avoir vraiment l'équivalent de RedShift (qui n'avais besoin je pense que de travailler avec le serveur X quelque soit le DE) il faut que
1) chaque compositeur implémente la fonctionnalité (je n'ai pas l'impression que libweston soit beaucoup utilisé, je me trompe?)
2) l'accès a la fonctionnalité soit standardisée (dans le protocole XDG-Shell je pense)
Chaque DE reproduisant en interne ce genre de fonctionnalité, bonjour la fragmentation..
Certains considèrent que comme Intel a réussi à implémenter les mêmes techniques que les RISC et a obtenir de très haute performance la différence d'ISA n'a plus grande importance.
D'autres pensent que la raison pour laquelle Intel n'a pas réussi à concurrencer ARM sur l'embarqué est que le "décodeur x86" qui est très complexe est un inconvénient au niveau consommation d'énergie,
bon l'ARM n'est pas vraiment un RISC(*) et son décodeur d'instruction doit quand même être assez compliqué aussi alors..
*:il y avait une vidéo de présentation sur le RISC-V qui montrait bien toutes la complexité de l'ISA ARM mais je n'ai pas le lien désolé.
Ça dépend.. Le pare-feu dans la machine de NAT, ça implique que tu est "à poil" si quelqu'un se connecte derrière le pare-feu: acceptable chez soi probablement, mais pas dans une entreprise..
==> en province
à Paris ce que tu décris c'est seulement le Dimanche ou au mois d’août en dehors des quartiers touristiques.
NB: Ceci n'est en aucun cas une pub pour les cafés/restaurants de Paris, les garçons de cafés malpoli à Paris ça n'est pas qu'une légende, il y en a beaucoup malheureusement..
Pas plus qu'avec OpenGL puisque
1) il y a déjà des extensions spécifiques à chaque carte avec OpenGL
2) les pilotes OpenGL étant très compliqués, il n'est pas rare d'avoir du code qui fonctionne sur X mais pas sur Y (même sans utilisée ces fameuses extensions).
Donc avec Vulkan, normalement le problème (2) devrait diminuer, mais (1) reste bien sûr.
Et la version Anglaise dit "Intel stated in 2015 that the pace of advancement has slowed, starting at the 22 nm feature width around 2012, and continuing at 14 nm. Brian Krzanich, CEO of Intel, announced that "our cadence today is closer to two and a half years than two.”
C'est ce que je disais: la loi de Moore a du plomb dans l'aile..
Bien que Canon soit considéré comme bon en 'cout à la page' il faut se méfier: ma Canon faisait très souvent des nettoyages des tètes d'impression, nettoyage qui consomme de l'encre..
Nettoyage qui n'ont pas empêché la tète d'impression de tomber en panne au bout de 3 ans..
Je suis passer chez HP, je verrai bien si l'imprimante dure plus longtemps, mais elle fait déjà beaucoup moins de nettoyage des tètes d'impression, c'est toujours ça de gagné..
Dommage que les lasers ça coûte cher, je me souviens en avoir trouvé une à un prix presque raisonnable avant de découvrir qu'elle ne faisait pas le recto/verso: j'ai failli me faire avoir, je ne pensais pas que ça existait encore au 21ème siècle une imprimante non recto/verso.
xcomcmdr: RISC = Reduced Instruction Set Computer, donc le RISC est une propriété des ISA, des jeux d'instructions. Le jeux d'instruction x86 n'a PRESQUE PAS évolué vers un jeu d'instruction type RISC (load/store, décodage simple, etc).
Le seul point sur lequel on peut dire qu'ils ont évolué c'est le nombre de registre accessible dans l'ISA qui a augmenté lors du x86-64 (bien que restant très inférieur aux 32 registres entiers classique des ISA RISC).
Les implémentations des x86 et des RISCs se sont rapprochés oui, les ISA non.
Les processeurs RISC-V sont théoriquement peu puissants et peu efficaces énergétiquement
Peu puissants oui, mais "peu efficaces énergétiquement"?
Je pense qu'il s'agit d'une erreur: ils ont même pas de CCR pour améliorer leur efficacité énergétique.
Après ça dépend si tu parles de l'ISA ou des implémentations: l'ISA a été conçue pour être efficace énergétiquement mais les implémentations c'est autre chose..
Mais Linux avait déjà une dynamique fortement positive et un avenir prometteur.
Haiku a choisi la licence MIT car elle permettrait, plus facilement que la GPL, de partager du code avec une éventuelle continuation propriétaire de BeOS. Utiliser un noyau Linux n'était donc pas possible.
Oui enfin préférer miser sur "une éventuelle continuation propriétaire de BeOS" plutôt que sur Linux (même en 2001), comment dirais-je?
"il n'est pire aveugle que celui qui ne veut pas voir.."
Et ça n'explique pas pourquoi Haiku n'a pas pris un noyau BSD plutôt qu'un noyau développé par une seule personne.
Tu es de très mauvaise foi avec ton exemple, la résolution d'un Amiga était pourrie et il n'y avais aucune sécurité, maintenant on a des moniteurs UHD et tout le monde est connecté à Internet, la sécurité n'est donc plus optionnelle, tout ça nécessite beaucoup de RAM.
En plus la "compétition" au niveau de l'OS et l’environnement de bureau qui utilise peu de RAM me parait plutôt ridicule quand on vois les besoins mémoires des browser web capable d'afficher les sites web actuels..
Je pense que tu fais erreur: ces personnes ne cherchent pas "le succès rapidement": autrement ils auraient pris un noyau Linux ou *BSD et ils se seraient focalisés sur les couches hautes, mais ça n'est pas "sexy": réutiliser l'existant ça apporte des contraintes donc ça ne les attire pas, par contre développer quasiment tout depuis le début, ça oui ça leur plait donc le fait que ça dure longtemps n'est pas vraiment un problème pour eux.
Bien sûr (à mon avis), c'est juste reculer pour mieux sauter: à la fin il y a quand même le travail de 'peaufinage' chiant mais nécessaire (les pilotes de périphériques, les bugs bizarres, etc) et finalement les contraintes de l'existant.. ça explique pourquoi beaucoup de projets sont dans l'état 'presque fini' et y restent: les bureaux Linux sont champions pour ça..
Je suis plutôt d'accord avec ta conclusion: sur un ordinateur avec un CPU puissant, de la mémoire et un SSD, les OS classiques marchent (enfin) bien (merci les SSD).
Pour un SoC complètement libre, il faudrait un GPU libre aussi.
Dans un premier temps, le RISC-V semble plutôt cibler les IoT qui n'ont pas besoin de GPU.
Si tu lis plus haut, ils n'ont même pas encore stabilisé la partie FPU et SIMD..
De mémoire une comparaison entre Thumb2 et x86 avait trouvé Thumb2 légèrement + dense que le x86, c'était peut-être légèrement moins dense mais
1) ça se tenait dans un mouchoir de poche.
2) le x86-64 est moins dense que le x86 (sauf pour faire des calculs 64 bits évidemment).
Je ne suis pas tout à fait d'accord: ajouter un décodeur x86 dans le CPU et sous utiliser le CPU car le compilateur ne peut voir qu'un petit nombre de registre, ça a aussi des conséquences au niveau de la consommation.
Et pour ce qui est de la densité de code moins importante des RISC, tu retardes: ARM et MIPS ont tout les deux des extensions avec instruction 16 bits, qui ont une densité de code équivalente à celle des x86, ce qui permet d'avoir le "meilleur des mondes" pour ces RISCs: du code compact pour le "tout venant" mais quand même accès a beaucoup de registre/des instructions supplémentaire quand il y a besoin.
Après il est vrai qu'ARMv8 n'a pas cette extension ce que je trouve très surprenant.
Mais pourquoi donc on n'a pas de concurrent qui propose une puce compétitive face à un Xeon 10 cœurs par exemple?
Sérieux tu pose réellement la question? Pour la même raison que les RISCs haute performance (Alpha et autre) sont morts: Intel peut vendre ses x86 dans le monde Windows ET dans le monde Linux alors qu'un NEW-Alpha sera confiné au monde Linux, donc le retour sur investissement est beaucoup plus difficile --> Intel a les meilleurs fab.
Certes Intel a un désavantage: le jeu d'instruction x86 qui nécessite un décodeur complexe et ça a été probablement un gros désavantage quand les transistors étaient "rare et cher" mais maintenant que le problème principal est "quoi faire avec tout ces transistors?" le désavantage est réduit..
N'ayant jamais eu de smartphone, je ne vois pas ce qui pourrait manquer dans cette approche.
C'est parce que tu manques d'expérience pratique:
*F-droid est nul par rapport aux stores classiques: pas de capture d'écran, pas de retour des utilisateurs ou de votes des utilisateurs.
*Cyanogenmod, c'est de l'aléatoire: j'ai lu des retour avec des problèmes de stabilités, une durée de batterie diminuée, un GPS qui ne marche pas ou le bluetooth: ça dépend du smartphone, ça peut peut-être bien marcher mais il faut bien se renseigner avant.
*est ce que ça marche bien la navigation a partir des cartes OSM?
Quand je vois que Waze une fois m'a bien planté (~45 minutes de retard, sympa quand on a 3 enfants dans la voiture), j'ai tendance à me méfier maintenant..
il semble surtout dire que la marché s'écroule car tous les constructeurs sortent les mêmes machines sans innovation + il y a le mobile qui vient parfois remplacer le PC.
Personnellement je trouve qu'il a raison: quand je vois les tarifs des PC portables avec SSD.. Pas de quoi s'étonné que les ventes de PC baissent..
Un HDD sur un PC portable, c'est une hérésie ça devrait être au minimum un combo SSD+HDD(SSHD) ou un SSD uniquement.
[^] # Re: Code VHDL : peu de lignes ?
Posté par reno . En réponse au journal OPEN-V : premier microcontrôleur libre ?. Évalué à 2.
? Même si tu as une chaîne logicielle totalement libre, il faut bien que tu l'achète le FPGA, donc je ne vois pas trop en quoi ça coûterai de l'argent au fabriquant.
Ou alors ils se font de la marge sur le composant ET sur les outils de programmation?
Il me semblait que ça n'était pas le cas et qu'ils ne vendaient pas les outils de programmation de manière indépendante (l'achat du FPGA te donne le droits d'utiliser les outils de programmation (au moins ceux de base)), quelqu'un peut confirmer/infirmer?
[^] # Re: Wayland d'abord sur Arch
Posté par reno . En réponse à la dépêche Fedora 25 est disponible !. Évalué à 3.
Je ne suis pas fan non plus du design de Wayland (j'aurais préféré un "X12") mais bon n'oublie quand même pas qu'on parle d'un remplacement d'X11 qui coté sécurité est totalement nul donc ça reste une grosse amélioration pour la sécurité.
Après, toute cette duplication de code c'est vrai que ça pique..
[^] # Re: Redshift !
Posté par reno . En réponse à la dépêche Fedora 25 est disponible !. Évalué à 5.
J'avais compris mais je pense quand même qu'il est important de faire remarquer qu'avec Wayland, pour avoir vraiment l'équivalent de RedShift (qui n'avais besoin je pense que de travailler avec le serveur X quelque soit le DE) il faut que
1) chaque compositeur implémente la fonctionnalité (je n'ai pas l'impression que libweston soit beaucoup utilisé, je me trompe?)
2) l'accès a la fonctionnalité soit standardisée (dans le protocole XDG-Shell je pense)
Chaque DE reproduisant en interne ce genre de fonctionnalité, bonjour la fragmentation..
[^] # Re: Redshift !
Posté par reno . En réponse à la dépêche Fedora 25 est disponible !. Évalué à 4.
du compositeur --> DES compositeurS
Contrairement à X chaque compositeur fait tout le travail donc chacun doit (ré)implémenter les fonctionnalités..
[^] # Re: Code VHDL : peu de lignes ?
Posté par reno . En réponse au journal OPEN-V : premier microcontrôleur libre ?. Évalué à 4.
Les avis divergent sur le sujet.
Certains considèrent que comme Intel a réussi à implémenter les mêmes techniques que les RISC et a obtenir de très haute performance la différence d'ISA n'a plus grande importance.
D'autres pensent que la raison pour laquelle Intel n'a pas réussi à concurrencer ARM sur l'embarqué est que le "décodeur x86" qui est très complexe est un inconvénient au niveau consommation d'énergie,
bon l'ARM n'est pas vraiment un RISC(*) et son décodeur d'instruction doit quand même être assez compliqué aussi alors..
*:il y avait une vidéo de présentation sur le RISC-V qui montrait bien toutes la complexité de l'ISA ARM mais je n'ai pas le lien désolé.
[^] # Re: Troll
Posté par reno . En réponse au journal Jouons un peu avec les adresses IPv6…. Évalué à -1.
Ça dépend.. Le pare-feu dans la machine de NAT, ça implique que tu est "à poil" si quelqu'un se connecte derrière le pare-feu: acceptable chez soi probablement, mais pas dans une entreprise..
[^] # Re: Petit test KDE Neon.
Posté par reno . En réponse à la dépêche KDE Plasma 5.8 LTS. Évalué à 9.
Click long??
C'est juste une aberration quand on a une souris avec click droit..
[^] # Re: Quelle super idée !
Posté par reno . En réponse au journal Statue Android à Montélimar . Évalué à 4.
==> en province
à Paris ce que tu décris c'est seulement le Dimanche ou au mois d’août en dehors des quartiers touristiques.
NB: Ceci n'est en aucun cas une pub pour les cafés/restaurants de Paris, les garçons de cafés malpoli à Paris ça n'est pas qu'une légende, il y en a beaucoup malheureusement..
[^] # Re: Vulkan?
Posté par reno . En réponse au journal Mesa: OpenGL 4.5 et OpenGL ES 3.2 pris en charge. Évalué à 9.
Pas plus qu'avec OpenGL puisque
1) il y a déjà des extensions spécifiques à chaque carte avec OpenGL
2) les pilotes OpenGL étant très compliqués, il n'est pas rare d'avoir du code qui fonctionne sur X mais pas sur Y (même sans utilisée ces fameuses extensions).
Donc avec Vulkan, normalement le problème (2) devrait diminuer, mais (1) reste bien sûr.
[^] # Re: Comment bookmark de gens optimistes
Posté par reno . En réponse à la dépêche Le logiciel libre au-delà de x86. Évalué à 3.
Et la version Anglaise dit "Intel stated in 2015 that the pace of advancement has slowed, starting at the 22 nm feature width around 2012, and continuing at 14 nm. Brian Krzanich, CEO of Intel, announced that "our cadence today is closer to two and a half years than two.”
C'est ce que je disais: la loi de Moore a du plomb dans l'aile..
# J'ai eu une mauvaise expérience avec Canon aussi
Posté par reno . En réponse au journal A Savoir: Chez Canon, les cartouches d'encre peuvent désactiver des fonctions de votre scanner!. Évalué à 7.
Bien que Canon soit considéré comme bon en 'cout à la page' il faut se méfier: ma Canon faisait très souvent des nettoyages des tètes d'impression, nettoyage qui consomme de l'encre..
Nettoyage qui n'ont pas empêché la tète d'impression de tomber en panne au bout de 3 ans..
Je suis passer chez HP, je verrai bien si l'imprimante dure plus longtemps, mais elle fait déjà beaucoup moins de nettoyage des tètes d'impression, c'est toujours ça de gagné..
Dommage que les lasers ça coûte cher, je me souviens en avoir trouvé une à un prix presque raisonnable avant de découvrir qu'elle ne faisait pas le recto/verso: j'ai failli me faire avoir, je ne pensais pas que ça existait encore au 21ème siècle une imprimante non recto/verso.
[^] # Re: 2-3 remarques
Posté par reno . En réponse à la dépêche Le logiciel libre au-delà de x86. Évalué à 6.
xcomcmdr: RISC = Reduced Instruction Set Computer, donc le RISC est une propriété des ISA, des jeux d'instructions. Le jeux d'instruction x86 n'a PRESQUE PAS évolué vers un jeu d'instruction type RISC (load/store, décodage simple, etc).
Le seul point sur lequel on peut dire qu'ils ont évolué c'est le nombre de registre accessible dans l'ISA qui a augmenté lors du x86-64 (bien que restant très inférieur aux 32 registres entiers classique des ISA RISC).
Les implémentations des x86 et des RISCs se sont rapprochés oui, les ISA non.
[^] # Re: Comment bookmark de gens optimistes
Posté par reno . En réponse à la dépêche Le logiciel libre au-delà de x86. Évalué à 8.
Tu retardes: je considère que la loi de Moore s'est déjà arrêtée..
# Je pense qu'il y a une erreur sur la description du RISC-V
Posté par reno . En réponse au journal Le logiciel libre au-delà de x86. Évalué à 2.
Peu puissants oui, mais "peu efficaces énergétiquement"?
Je pense qu'il s'agit d'une erreur: ils ont même pas de CCR pour améliorer leur efficacité énergétique.
Après ça dépend si tu parles de l'ISA ou des implémentations: l'ISA a été conçue pour être efficace énergétiquement mais les implémentations c'est autre chose..
[^] # Re: Comment ils font ?
Posté par reno . En réponse à la dépêche Haiku a 15 ans. Évalué à 3.
Mais Linux avait déjà une dynamique fortement positive et un avenir prometteur.
Oui enfin préférer miser sur "une éventuelle continuation propriétaire de BeOS" plutôt que sur Linux (même en 2001), comment dirais-je?
"il n'est pire aveugle que celui qui ne veut pas voir.."
Et ça n'explique pas pourquoi Haiku n'a pas pris un noyau BSD plutôt qu'un noyau développé par une seule personne.
[^] # Re: Toutes ces années de dev
Posté par reno . En réponse à la dépêche Haiku a 15 ans. Évalué à 7.
Tu as raison, la sécurité en nécessite très peu de RAM (juste la gestion des droits d'accès des pages).
Après se faire la compétition sur qui a l'OS et la GUI qui prends 100, 200 ou 300 MO de RAM quand le navigateur web a besoin de plus de 4GO, bof..
[^] # Re: Toutes ces années de dev
Posté par reno . En réponse à la dépêche Haiku a 15 ans. Évalué à 7.
Tu es de très mauvaise foi avec ton exemple, la résolution d'un Amiga était pourrie et il n'y avais aucune sécurité, maintenant on a des moniteurs UHD et tout le monde est connecté à Internet, la sécurité n'est donc plus optionnelle, tout ça nécessite beaucoup de RAM.
En plus la "compétition" au niveau de l'OS et l’environnement de bureau qui utilise peu de RAM me parait plutôt ridicule quand on vois les besoins mémoires des browser web capable d'afficher les sites web actuels..
[^] # Re: Comment ils font ?
Posté par reno . En réponse à la dépêche Haiku a 15 ans. Évalué à 3.
Je pense que tu fais erreur: ces personnes ne cherchent pas "le succès rapidement": autrement ils auraient pris un noyau Linux ou *BSD et ils se seraient focalisés sur les couches hautes, mais ça n'est pas "sexy": réutiliser l'existant ça apporte des contraintes donc ça ne les attire pas, par contre développer quasiment tout depuis le début, ça oui ça leur plait donc le fait que ça dure longtemps n'est pas vraiment un problème pour eux.
Bien sûr (à mon avis), c'est juste reculer pour mieux sauter: à la fin il y a quand même le travail de 'peaufinage' chiant mais nécessaire (les pilotes de périphériques, les bugs bizarres, etc) et finalement les contraintes de l'existant.. ça explique pourquoi beaucoup de projets sont dans l'état 'presque fini' et y restent: les bureaux Linux sont champions pour ça..
Je suis plutôt d'accord avec ta conclusion: sur un ordinateur avec un CPU puissant, de la mémoire et un SSD, les OS classiques marchent (enfin) bien (merci les SSD).
[^] # Re: ARM Bientôt racheté par SoftBank (Japon)
Posté par reno . En réponse au journal De retour du 4e workshop RISC-V. Évalué à 2.
Dans un premier temps, le RISC-V semble plutôt cibler les IoT qui n'ont pas besoin de GPU.
Si tu lis plus haut, ils n'ont même pas encore stabilisé la partie FPU et SIMD..
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par reno . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 4.
Simple? Vraiment ?
https://en.m.wikipedia.org/wiki/Dam_failure
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par reno . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 3.
De mémoire une comparaison entre Thumb2 et x86 avait trouvé Thumb2 légèrement + dense que le x86, c'était peut-être légèrement moins dense mais
1) ça se tenait dans un mouchoir de poche.
2) le x86-64 est moins dense que le x86 (sauf pour faire des calculs 64 bits évidemment).
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par reno . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 1.
Je ne suis pas tout à fait d'accord: ajouter un décodeur x86 dans le CPU et sous utiliser le CPU car le compilateur ne peut voir qu'un petit nombre de registre, ça a aussi des conséquences au niveau de la consommation.
Et pour ce qui est de la densité de code moins importante des RISC, tu retardes: ARM et MIPS ont tout les deux des extensions avec instruction 16 bits, qui ont une densité de code équivalente à celle des x86, ce qui permet d'avoir le "meilleur des mondes" pour ces RISCs: du code compact pour le "tout venant" mais quand même accès a beaucoup de registre/des instructions supplémentaire quand il y a besoin.
Après il est vrai qu'ARMv8 n'a pas cette extension ce que je trouve très surprenant.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par reno . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 3.
Sérieux tu pose réellement la question? Pour la même raison que les RISCs haute performance (Alpha et autre) sont morts: Intel peut vendre ses x86 dans le monde Windows ET dans le monde Linux alors qu'un NEW-Alpha sera confiné au monde Linux, donc le retour sur investissement est beaucoup plus difficile --> Intel a les meilleurs fab.
Certes Intel a un désavantage: le jeu d'instruction x86 qui nécessite un décodeur complexe et ça a été probablement un gros désavantage quand les transistors étaient "rare et cher" mais maintenant que le problème principal est "quoi faire avec tout ces transistors?" le désavantage est réduit..
[^] # Re: je regarde aussi
Posté par reno . En réponse au journal UnaOS - UnaPhone - Un smartphone axé autour de la vie privée ?. Évalué à 1.
C'est parce que tu manques d'expérience pratique:
*F-droid est nul par rapport aux stores classiques: pas de capture d'écran, pas de retour des utilisateurs ou de votes des utilisateurs.
*Cyanogenmod, c'est de l'aléatoire: j'ai lu des retour avec des problèmes de stabilités, une durée de batterie diminuée, un GPS qui ne marche pas ou le bluetooth: ça dépend du smartphone, ça peut peut-être bien marcher mais il faut bien se renseigner avant.
*est ce que ça marche bien la navigation a partir des cartes OSM?
Quand je vois que Waze une fois m'a bien planté (~45 minutes de retard, sympa quand on a 3 enfants dans la voiture), j'ai tendance à me méfier maintenant..
[^] # Re: Moui..
Posté par reno . En réponse au journal Article intéressant sur le marché du PC. Évalué à 7.
Personnellement je trouve qu'il a raison: quand je vois les tarifs des PC portables avec SSD.. Pas de quoi s'étonné que les ventes de PC baissent..
Un HDD sur un PC portable, c'est une hérésie ça devrait être au minimum un combo SSD+HDD(SSHD) ou un SSD uniquement.