Le 06/06/2023 à 11h 42

Winderly a dit:

Mais comment entre-t-il dans cet état CC6 ???

Quand il est en idle probablement, vu que c’est un état de basse consommation.

Le 06/06/2023 à 11h 41

obor2 a dit:

N’empêche, il faudra attendre trois ans avant de savoir si le patch est bien effectif :smile:

Inutile d’attendre… y’aura PAS de patch, c’est marqué dans l’article.

Le 06/05/2022 à 11h 09

AMD Opteron 144

Le 30/09/2021 à 11h 04

(quote:article)
Il n’en est rien. D’abord parce que les cas devraient être très limités et ne toucher que des appareils qui doivent rencontrer bien d’autres problèmes du fait de leur vétusté logicielle. Ensuite parce qu’une simple erreur sera affichée et pourra être outrepassée. Sans parler des solutions alternatives, par exemple utiliser Firefox, qui dispose de ses propres certificats racines à jour.

Bah c’est encore mieux que ça… Le certificat sera toujours valide jusqu’en 2024 d’après ce que j’ai compris. Donc même pas d’erreur de TLS à outrepasser…

Le 17/09/2021 à 15h 36

“Des fois, faut sacrifier les jeunes.”

Le 11/09/2021 à 08h 15

Pour ceux qui se demanderait, comme moi, pourquoi c’est passé à la version 3 au lieu de la 2 :
https://www.openssl.org/blog/blog/2018/11/28/version/

Le 06/09/2021 à 06h 53

Go Go Gadget à la Yubikey !

Le 01/02/2021 à 12h 30

3 ans de prison et 45K€ d’amende pour un détraqué qui enc* une chèvre !

Mais broyer des poussins vivants, émasculer à vif des cochons, enfermer des lapins et poules dans des endroits à peine plus grand qu’eux, ça c’est autorisé…

Le sens des priorité de LREM

Le 06/05/2020 à 12h 44

C’est ballot pour Zimbra, la version 9 vient de passer en closed-source.

Le 22/10/2019 à 20h 12

Okki a écrit :



En même temps, tu dois bien être le seul à qui ça arrive. Ubuntu est utilisé par des millions de personnes. Alors si un bug aussi gros et important que le mauvais choix de la disposition du clavier était présent par défaut, il y aurait fatalement un rapport de bug rapidement remonté et un correctif tout aussi rapidement déployé.



J’ai donc bien du mal à croire que tu ne te sois pas trompé quelque part durant l’installation.





C’est pas parce que c’est gros que c’est corrigé !

J’utilise Linux au quotidien depuis la Ubuntu 6 ou 7 de mémoire. Je suis ensuite passé sur Fedora 8 et je tourne avec chaque nouvelle version de Fedora depuis lors ! Et je suis Admin Sys Linux de métier. J’ai installé Fedora sur le PC de mes parents et de mon frère depuis plus de 5 ans. L’utilisation de Linux en desktop au quotidien je connais, et donc je peux te dire que les bugs y’en a des tétra-chié ! Et des bugs pour des trucs de base, pas des trucs compliqués forcément.



C’est pas parce que je suis pro-Linux que je me voile la face !! Il n’y a pas de marché du desktop Linux, donc pas d’argent, donc pas de QA. C’est pas plus compliqué que c’est ça.



Vous voulez des exemples à la con ?

 

• À chaque fois que je démarre mon PC, il faut que je ré-sélectionne la sortie HDMI de ma télé au lieu du casque qui est branché. En 2019 mon PC ne sait pas retenir ma sortie audio par défaut !
  
   
  


• Impossible de faire du mode mirror/clone avec mon écran 1440p et ma télé 1080p. Soit j’ai mon écran en 1080p (au lieu du 1440p), soit j’ai ma télé qui va en out-of-range.
  
   
  


• Dans Firefox, quand j’active le mode lecture sur une page Web, ma sortie audio devient complètement brouillée/hachée… Obligé de restarter Pulseaudio pour retrouver un son normal.
  
   
  


• Je ne vois plus ce problème depuis quelques mois j’ai l’impression, mais pendant des années la LED de verrouillage du pavé numérique pouvait être OFF mais en fait le clavier était bien ON. En appuyant sur 2 fois
  
  la touche Maj ça rallumant la LED… WTF. Vous trouvez que c’est un comportement d’OS stable ça ?!
  
   
  


• Vous avez déjà tenté de faire des Atl-tab pour switcher sur le Bureau quand vous êtes d’un jeu vidéo en plein écran ? Ça semble s’améliorer avec le temps, mais ça bug encore beaucoup (exemple avec Civilization 6).
  
  
  


• Vous avez déjà essayer d’utiliser le gestionnaire Bluetooth de GNOME ? Ben ça marche mal. J’utilise la ligne de commande, c’est plus fiable.
  
   
  
  
  
  
  
  Et pour finir 2 bugs immenses que j’avais reportés (corrigé depuis) sur RHEL/CentOS :
  


• CentOS 6, sur le desktop, quand on cliquait sur la croix pour fermer une fenêtre, ça pouvait en fait fermer la fenêtre qui était derrière celle sur laquelle on avait cliquer ! Véridique… Le développeur de Red Hat n’arrivait au début pas à reproduire le problème parce que sa configuration de souris était un peu custom…
  
   
  


• CentOS 7, quand on sélectionnait le layout clavier FR, ça faisait planter Anaconda quand on voulait éditer le partitionnement du disque… C’était releasé tel quel dans RHEL 7.0 et quelques versions ultérieures…
  
  
  
  J’oublie encore des tas de bugs depuis toutes ces années… Et malgré ces trucs qui me gonfle, je persiste à utiliser Linux. Mais je ne cris pas sur les toits que Linux pour le desktop c’est parfait. C’est clairement faux.

Le 22/10/2019 à 19h 40

> On ne va pas pinailler sur le choix des mots, ces versions sont

déconseillées au grand public pour leur absence de support à long terme

et davantage buggées (la preuve…).



Non c’est faux, les non-LTS ne sont pas déconseillées au grand-public… Et elles sont pas plus buggués que les LTS. La livraison d’une LTS n’a absolument rien de différent d’une GA. Comme l’a dit “haelty”, il n’y a que la durée du support qui change, arbitrairement.

Le 28/12/2018 à 16h 10

Dommage qu’il y ai un délai supplémentaire pour les autoradios.

Sur une Polo neuve, l’option DAB+ est facturée 225 €…



Et donc si je comprends bien, à partir de juin 2020, le DAB+ devra être inclus obligatoirement (facturé ou non…).

Le 03/12/2018 à 20h 39

grsbdl a écrit :



En gros les grands éditeurs auront plus de sous, mais les petits non. Snif, c’est moche.





Bah non. Ça change rien pour les petits éditeurs… " />

Le 19/10/2018 à 17h 34

Ça serait bien qu’il fasse un refresh de Left 4 Dead ouais, comme CS:S et CS:GO en leur temps.

Et un L4D Royale aussi ^^

Le 29/08/2018 à 11h 37

Est-ce qu’il est compatible avec Galiléo ?

Le 05/07/2018 à 18h 41

Et j’oubliais : des interviews ! De développeurs, etc. enfin pas des commerciaux, mais des gars dans le concret.

 

Par exemple il y a quelques années, un gars sur LinuxFR.org avait interviewé Jérôme Glisse (un développeur Red Hat qui bossait (sûrement toujours plus ou moins) sur les pilotes Linux Radeon) :https://linuxfr.org/news/entretien-avec-jerome-glisse-developpeur-des-pilotes-gr…



 C’était juste génial comme interview !

Le 05/07/2018 à 18h 22

Bonne et étonnante nouvelle !



Si jamais vous faites des benchmarks, ça serait bien que vous ne fassiez pas que des tests du dernier gros matos qui sort (genre le tout dernier gros CPU ou GPU). Le gros des ventes se fait sur l’entrée et milieu de gamme il me semble. Moi j’aurais souvent aimer savoir si en achetant une carte entrée de gamme certains “vieux” jeux allaient bien tourner dessus. Tout le monde ne joue pas aux derniers jeux AAA. Y’a des gens qui jouent à un seul jeu pendant des années. Par exemple, savoir si on doit prendre une RX 560 ou RX 550 pour jouer à son jeu préféré est intéressant je trouve.



Si vous faites des tests de matos, un petit mot sur le support du-dit matos sur Linux fait toujours plaisir, notamment pour les clés USB WiFi ou les GPU ! Par exemple si vous testez une clé USB WiFi, vous pouvez démarrer un LiveCD du dernier Ubuntu ou Fedora et voir si la clé fonctionne out-of-the-box nativement, l’utiliser quelques minutes et voilà !

Le 05/07/2018 à 18h 39

INpact Hardware, je ne me souviens plus si je fréquentais à cette époque. Je pense que oui parmi tant qu’autres sites.

 

PC INpact en revanche je lisais régulièrement parmi d’autres sites toujours, et je l’appréciais. Quand vos difficultés financières ont commencées, et que vous annonciez les changements difficile à faire et votre honnête journalistique, cela m’a beaucoup séduit. Au moins depuis cette époque (et sûrement déjà bien avant) vos articles étaient très bons. Dès que vous avez proposé les abonnements, je m’étais abonner car cela devenait dur de trouver des bons sites comme ça. J’ai encore le Tshirt PC Inpact !

 

Next INpact, hé bien je continue à m’abonner chaque année, et ça devrait continuer longtemps, sans parler de votre annonce de nouveau site hardware :)

Le 19/01/2018 à 12h 06

En fait je me suis trompé, Spectre variant 1 n’a pas besoin de màj de microcode. C’est seulement le cas pour Spectre variant 2.

Le 18/01/2018 à 19h 18

David.C a écrit :



Moi j’ai cru comprendre :

-bios

-windows update

-paquet linux





CVE-2017-5753 (Spectre, variant 1)

Nécessite une mise à jour du noyau

Nécessite une mise à jour du microcode



CVE-2017-5715 (Spectre, variant 2)

Nécessite une mise à jour du noyau et des outils de virtualisation

Nécessite une mise à jour du microcode



CVE-2017-5754 (Meltdown, variant 3)

Nécessite une mise à jour du noyau

Processeurs AMD pas vulnérables





Mais pour complexifier tout ça, les mises à jour du microcode (que ce soit via l’OS ou via le BIOS) proposées par les fabricants ne prennent pas encore tous les CPU en charge, parfois il s’agit seulement de certaines générations de CPU.



 







David.C a écrit :



Par contre pas compris si il faut le faire 1 fois et c’est bon meme si

om reformate ou si l’os aplique la rustine a chaque demarrage

(temporaire)





Ta question concerne le microcode.

Le processeur, quand il démarre, dispose toujours du même microcode qu’à sa sortie d’usine. Mais il existe un moyen pour charger un nouveau microcode par dessus, mais ça ne sera jamais persistant. Si tu éteins le PC, le microcode d’origine sera rechargé au prochain boot.

Il existe 2 moyens de charger un microcode à jour sur le CPU : soit via le BIOS, soit via l’OS. L’avantage du chargement du nouveau microcode via le BIOS c’est qu’il est chargé très tôt, et qu’il y a une “persistance” en quelque sorte, puisque peu importe l’OS qu’on charge après, le microcode sera déjà à jour, même si tu ne fais pas les màj de ton OS. Enfin le microcode est dans le BIOS, donc la “persistance” est sur la carte mère en réalité, pas sur le CPU.

Le 18/01/2018 à 17h 52

La mise à jour du microcode peut se faire de 2 manières, soit via une mise à jour du BIOS, soit via une mise à jour de l’OS (qui chargera à chaque fois le microcode très tôt dans le boot).

Le 18/01/2018 à 17h 53

> la communication d’AMD a été un peu chaotique



C’est la marque de fabrique d’AMD ça !

Le 08/01/2018 à 12h 31

edit: grillé *2  " />



 En fait le W3C n’est plus du tout l’organisme qui développe le HTML5, il s’agit maintenant du WHATWG. Comme indiqué sur cette page du site du WHATWG (https://html.spec.whatwg.org/multipage/introduction.html#introduction) : “Although we have asked them to stop doing so, the W3C also republishes some parts

of this specification as separate documents."    

 

Bref, le W3C pompe les docs du WHATWG et en publie de temps un temps un snapshot…



Voir aussi les excellent commentaires de Bruno Michel à ce sujet ici : https://linuxfr.org/users/spacefox/journaux/hache-the-aime-aile-cinq-virgule-deux-a-k-a-html-5-2-pour-les-intimes

Le 30/08/2017 à 11h 01

wanou2 a écrit :



Pour infos, nos prochains avions de chasse seront très certainement américains. La prochaine génération n’est toujours pas à l’étude (pour rappel ça fait plus de 10 ans qu’il vole et qu’il faut 20 ans pour en développer un).



Si aucun de nos partenaires européens souhaite s’engager sur la conception d’un nouveau multi-rôle notre prochain avion sera un f35…





Pourquoi forcément Européen ou Américain ? Les Chinois et Russes font aussi des avions de combat.

Le 14/06/2017 à 19h 12

Oui mais c’est même pas complètement corrigé dans la 54 en fait. Certains styles CSS ne fonctionnent toujours pas (par exemple les “font-weight”).

Et pour les organisations qui sont sur le canal ESR, pas de correctif avant 2018…

Le 14/06/2017 à 18h 45

eccstasy a écrit :



Bref, ça n’avance pas et c’est regrettable.





Pour ma part je trouve que Mozilla a voulu aller beaucoup trop vite là en activant e10s par défaut pour tout le monde d’éligible, et ce à partir de la version 52 (ESR inclus). Or il y a toujours un bug HTML/CSS avec le mode e10s activé. Un bug ouvert depuis 4 ans ! Et ils ont quand même poussés e10s dans le canal  ESR. Des génies chez Mozilla…



Pour info, le bug en question fait que les styles CSS appliqués aux éléments <select><option> ne fonctionne plus quand e10s est activé…

Le 16/02/2017 à 13h 08

shadowfox a écrit :



Sha1, ça fait 10 ans que c’est plus assez, un PC actuel peut trouver une collision en moins de 5 secondes.



EDIT : Encore je dis 5 secondes, mais selon la bécane, ça doit plutôt tenir de quelques milisecondes. ^^’





N’exagères pas non plus. Selon ce papier “Practical Free-Start Collision Attacks on 76-step SHA-1”, c’est plutôt :

“We report that a single […] GTX 970 is sufficient to find the collision in less than 5 days.”



 Et apparemment pas sur une version “complète” de SHA-1. Enfin je ne sais pas ce que c’est ces histoires de “XX-step reduced version” qu’on peut lire à droite à gauche. Si quelqu’un peut expliquer.

Le 26/10/2016 à 19h 29

Soriatane a écrit :



Non, non je te rassure on est capable de faire des conneries tout seul comme des grands! (c’est la France qui a bombardé la Lybie).





Oui merci Nicolas Sarkozy, le président qui nous as fait réintégré l’OTAN. Un pur génie ce président.

Le 26/10/2016 à 16h 25

Soriatane a écrit :



Les USA sont nos alliées normalement que l’on puisse travailler avec eux. Après dire que la France est un rouage du système, c’est un peu fort et surtout dépendant de l’organe politique pas de l’organe militaire.

Les USA nos alliés ?     

Les attentats (Nice, Hyper Casher, Charlie, etc.), le flux migratoire en Europe, la jungle de Calais, etc. Tout ceci est de leur faute quand même.

Le 26/10/2016 à 16h 22

Tophe a écrit :





Exactement. 2 cycles de releases différents dont un qui est plus fermé que l’autre. Donc rien ne peux te garantir que le cycle de release de RHEL utilise réellement le code source disponible.



C’est simplement ça que je voulais démontrer. Je ne suis pas en train d’affirmer que Red Hat utilise du code légèrement modifié avec des backdoor dedans… Je dis juste qu’il est impossible d’affirmer que ce ne soit pas le cas.



De toute façon, à mon avis les backdoor ce sont des failles de sécurités connus de certaines entités mais pas du développeur upstream, plutôt que des bouts de code intentionnellement ajoutés pour créer une backdoor. En tout cas je ne pense pas que ce soit le cas dans les binaires issus de projet open-source.

 







Tophe a écrit :



http://vault.centos.org/7.2.1511/os/Source/SPackages/ 

http://ftp.redhat.com/pub/redhat/linux/enterprise/7Workstation/en/RH-COMMON/SRPMS/

Que veux-tu de plus ? 

Dans l’interview que j’ai cité, ils disent qu’ils manquent l’environnement de build pour générer les paquets. Je me suis trompé en disant qu’il manquait la recette, ils disent qu’ils l’ont. Mais c’est l’environnement de build qui n’est pas documenté.

Le 26/10/2016 à 13h 08

fred42 a écrit :



Et comment CentOS qui est une “presque”¹ copie de RedHat fait pour compiler sa distribution si RedHat ne rend pas disponible sa méthode de compilation ?



C’est bien parce que RedHat fournit tout ce qui est nécessaire à la reproduction que CentOS existe.



¹ J’ai mis “presque” parce qu’ils enlèvent ce qui est propriété de RedHat (marques et artwork).









Tophe a écrit :



0 différences entre les 2, à part les artworks en effet et surtout le support.





Non Red Hat ne fournit pas la méthode pour builder CentOS. C’est à la communauté de trouver la recette. Je vous invite à lire cette interview (qui date de 2011) de 2 membres de la communauté francophone :https://linuxfr.org/news/entretien-avec-les-membres-francophones-de-centos



Les 2 extraits qui le disent :

“c’est un peu comme essayer de refaire un cocktail en ne connaissant que

certains ingrédients, mais sans savoir combien de temps il faut

mélanger, dans quel ordre, etc.. Bref, essayer avec plusieurs shakers,

secouer et comparer le résultat à l’original.”



“Red Hat fournit les SRPM (code source + recette pour construire), et

c’est déjà beaucoup ! CentOS, SL et OL reconstruisent les RPM (en

enlevant les images qui sont la propriété de Red Hat). La difficulté est

que l’environnement pour appliquer ces recettes n’est pas connu, ni

l’ordre pour reconstruire les paquets. C’est un processus itératif avec

plein de culs de sac. N’importe qui peut s’y essayer. Le protocole a été

publié. En revanche, ce n’est pas la vocation de CentOS de fournir

cette recette non plus (ni à notre connaissance SL ou OL d’ailleurs).”



 D’ailleurs si la recette était fourni par Red Hat, le délai de release entre RHEL et CentOS serait plus court.

 

En 2014 (de mémoire), CentOS s’est fortement rapprochée de Red Hat mais je ne pense pas que cela change quoi que ce soit sur ce point.

 







Tophe a écrit :



Il semblerait que lecbee ne connaît pas la philosophie de RH: upstream first !





C’est quoi le rapport  avec le processus de rebuild de CentOS ?

Le 26/10/2016 à 07h 15

Tophe a écrit :



Plus confiance dans du CentOS que dans du RedHat ?

Loool. Beau troll, mais on n’est pas vendredi: sais-tu au moins de quoi tu parles, et connais-tu donc la différence entre ces 2 distributions ?





Oui je connais la différence :

CentOS : source disponible et méthode compilation disponible. Donc reproductible et vérifiable.

Red Hat : source disponible et méthode de compilation indisponible. Donc pas reproductible et pas vérifiable.

Le 25/10/2016 à 19h 39

FRANCKYIV a écrit :



" />



Tu crois vraiment que tu lis le code source et que tu compiles à la main chaque composant, ou alors tu fais confiance aux distributions ? " />





Ta remarque confirme bien que la disponibilité du code source Microsoft pour les états est juste de la fumisterie, puisque même les codes sources disponibles “par défaut” ne peuvent pas vraiment être “contrôlés” non plus (par exemple comment être sûr qu’il n’y a pas de backdoor dans les binaires RHEL ou SUSE ?).



 Ceci dit, j’ai bien plus confiance dans un binaire Debian ou CentOS qu’un binaire Microsoft ou Red Hat c’est certain.

Le 25/10/2016 à 18h 07

trekker92 a écrit :



donc ce n’est pas un probleme, fin du débat =)





Y’a pas eu d’appel d’offre, tout est normal en effet.

Le 25/10/2016 à 17h 57

trekker92 a écrit :



si tu avais lu en entier, t’aurais vu que la fonction publique n’embauche surtout pas.

et tu veux forcer les entreprises à embaucher pour des portages sous linux qui ne concernent personne?





Forcer les entreprises ? Bah non bien sûr, mais y’avait un appel d’offre* à plusieurs dizaines de millions d’euros à la clé.



* ah ba non justement y’en a pas eu…

Le 25/10/2016 à 17h 50

Mr.Nox a écrit :



Les États ont accès aux codes sources, rien d’obscur.





LOL. Tu crois qu’ils vont leur filer le code source qui contient les backdoors ? Ou bien ils enlèvent le code malicieux avant ?

Le 25/10/2016 à 17h 48

trekker92 a écrit :



faux, un systeme linux/bsd et c’est la cata pour tous les appareils tierces (connexions serial, protocoles propriétaires) , progiciels, etc





Et ben c’est génial ça ! Ça veut dire qu’il y a plein de chose à développer, créer, tester. Donc création d’emploi pour des développeurs, administrateurs, etc. Des créations des d’emplois et d’entreprises françaises, des impôts payés en France.

Le 25/10/2016 à 16h 55

v6relou a écrit :



Les libristes toujours à râler mais ils n’ont rien à proposer de sérieux en remplacement.

Si, ils ont un écosystème Linux/BSD, des emplois à créer et des impôts à payer en France.   

Mais le gouvernement français préfère visiblement les intérêts des États-Unis que les nôtres.

Le 26/10/2016 à 08h 22

Letron a écrit :



Non.





Si.

Le 26/08/2016 à 16h 14

Bhou a écrit :



Mais ce n’est pas adapté à du serveur clairement.

Ah ah j'ai ri. On peut savoir pourquoi ?! En tout cas je suis sysadmin et je préfère administrer mes CentOS 7 que les 6.     

 





Bhou a écrit :



Le pire dans l’histoire c’est qu’un alternative au vieux system d’init

qui a plus de 20 ans existait déjà avec entre autre openrc qui pour

l’utiliser et vraiment excellent en usage serveur.





Tu n’as pas du saisir le fait que systemd n’était pas là juste pour remplacer initd.

 





Bhou a écrit :



Ce qui va à l’encontre de la philosophie *nix de base: chaque outil doit faire une

seule et unique chose mais doit bien le faire (au niveau systeme, pas au

niveau applicatif desktop).

Et il faut arrêter d’être psycho-rigide parfois et se poser des questions. Cette soi-disant philosophie est-telle pertinente pour tous les systèmes ?



Au fait Linux est bien plus monolithique que systemd, et ça bizarrement ça ne gène pas les anti-systemd…

Le 08/08/2016 à 18h 54

> bien que ce soit la « force qui nous est la plus familière, elle ne fait pas partie du modèle standard » explique le CERN.



Ouais enfin la gravité n’est pas une force. C’est quand même ballot de la part du CERN de dire cela. Même pour vulgariser il aurait pu trouver un autre mot en restant compréhensible.

Le 20/05/2016 à 10h 22

J’ai installé des Windows 7 SP1 (64 bits) tout frais, sur 3 PC différents, et à chaque fois ça me dit que le patch n’est pas supporté.

Bref c’est une grosse bouze ce truc.

Le 24/03/2016 à 11h 45

C’est vrai que le titre de l’article pourrait être revu car il laisse penser que les utilisateurs de Windows ne sont pas touchés.

 

Je suppose que s’ils dévoilent le patch avec tous les détails techniques le même jour c’est que le patch correctif en question doit être suffisamment explicite pour comprendre rapidement le problème, du coup autant tout dévoiler tout de suite ça ne devrait pas changer grand chose.



En tout cas j’ai hâte de savoir le 12 avril si d’autres implémentations SMB sont touchées, comme par exemple celle de NetApp.

Le 25/01/2016 à 18h 25

Drepanocytose a écrit :



Sinon c’est moi ou ils augmentent la fréquence des RC depuis qques temps ?





Non ça fait pas loin de 10 ans que chaque version est testée avec 7 ou 8 rc avant la sortie finale. Le noyau 2.6.23 (octobre 2007) avait eu 9 RC même.

Vers 2004-2005, il semble qu’il y avait moins de rc (genre entre 3 et 5), puis après ça a augmenté et aujourd’hui on en toujours sur un rythme ultra rodé de 8 rc.

Le 13/01/2016 à 20h 25

Le A10-7850K s’achète à 141 €.

Le i7-4790 s’achète à 330 €.

Le i7 est donc 2,34 fois plus cher.



Si on regarde des benchs, globalement le A10 a un meilleur ratio prix/performance que l’i7 :



CineBench 11.5 (higer = better)

i7 : 8,34

A10 : 3,63   (*2.34 = 8,50)



FryBench (lower = better)

i7 : 4,38

A10 : 11,55   (/2.34 = 4,93)



Espresso transcode (lower = better)

i7 : 46

A10 : 88   (/2.34 = 37,60)



Handbrake (higer = better)

i7 : 26,86

A10 : 14,34   (*2.34 = 33.56)



3DMark06 CPU

i7 : 7977

A10 : 4544   (*2.34 = 10635)



3DMark06 CPU

i7 : 29133

A10 : 10951   (*2.34 = 25631)

Le 12/01/2016 à 20h 52

Le i7 est infiniment plus cher aussi…

Le 05/01/2016 à 21h 56

Ricard a écrit :



Ransom32 ? " />



M’en fous, je suis en 64bits. " />





Ransom32(Méga)

Le 22/12/2015 à 13h 07

Pour information/anecdote, voici les “CVSS v2 Base Score” des dernières grosses failles bien connues (un score plus élevé signifie une gravité plus élevée) :

  POODLE : 4.3 MEDIUM   


 Heartbleed : 5.0 MEDIUM   


  Grub2 "28 chars" : 6.9 MEDIUM   

 Shellshock : 10.0 HIGH

Le 02/12/2015 à 19h 54

Commentaire_supprime a écrit :



 

Quelqu’un pour expliquer ? Cela signifie que si je m’en paye un, je ne peux pas le mettre dans mon dock SATA, le formater en EXT4 et coller dessus ⁸⁄₁₀ To de données comme ça à partir de ma Fedora ? Il faut quoi en plus ?





Non ça ne fonctionnera pas.

 

Le support pour Linux est encore est plein chantier/réflexion.

Tu trouveras des infos ici :https://lwn.net/Articles/637035/

Et même quand les premiers supports “out-of-the-box” auront lieu dans les distributions comme Fedora, il ne faudra pas compter y faire du RAID. Ça sera mono-disque et mono-partition.



En fait ce sont des disques vraiment spécialisés, il faut une application user-space qui sait quoi en faire.

Le 24/11/2015 à 20h 27

_nash_ a écrit :



si nividia a changé sa politique.

ils y a eu des commit pour le driver legacy nv



 

J’ai un doute sur ce dont tu parles : le pilote NVIDIA officiel qui supporte les anciennes cartes graphiques (GeForce ⁶⁄₇) ou bien le pilote xorg-nv ?

Dans le premier cas, la politique d’NVIDIA a toujours été comme ça (màj régulière d’ancien pilote pour qu’il tourne au moins sur les kernel/Xorg récent) et donc c’est pas Linus qui a changé quoi que ce soit.

Dans le cas de xorg-nv, à la base c’est un pilote créé par NVIDIA eux-mêmes, il ne supporte pas la 3D, a été officiellement abandonné il y a plusieurs années.

 





_nash_ a écrit :



et enfin, il y a les pilotes pour tegra



 

Comme je le disais, Linus n’y a rien changé, NVIDIA travaillait déjà avant pour intégrer son matériel Tegra sur Linux (car il y a un gros marché Android à avoir).