Troy McClure a écrit 2213 commentaires

et t'en as pas marre de devoir whitelister 80% des sites webs que tu visites pour qu'il t'affiche autre chose qu'une page blanche ou qu'un message d'erreur te demandant d'autoriser javascript ?

L’unité flottante utilisée par les instructions SSE est sur 80 bits en interne

franchement je pense que tu te trompes. SSE2 c'est 64 bits en double precision, et c'est tout. Des problemes de non-conformité ieee peuvent survenir avec les instructions fused mult-add , mais elles n'existaient pas en sse2. Je te laisse chercher une url qui va dans ton sens, a mon avis tu vas avoir du mal.

moi je veux bien que ce soit de la propagande ou du marketting mais dans quel but ? pourquoi artificiellement gonfler les prérequis de la version 64-bit ?

Comme précisé par ouasse , c'est bien le fpu x87 qui a des registres sur 80-bits. Heureusement intel n'a pas réédité cette colossale connerie avec le SSE2 dont les registres 128 bits contiennent deux reels en double précision, et qui effectue des calculs conformes a IEEE754.

C'est le dernier maillon de la chaîne linuxfr : dépêche, journal, forum, tribune.

Certains parlent même d' incubateur d'excellence .

Tu voulais dire FPU à la place de SSE2 et SSE2 à la place de FPU, non ?

le x87 n'est pas inaccessible, il est juste deprecié à la faveur de sse2, mais a priori on peut continuer à l'utiliser, je pense d'ailleurs que le type long double continue à l'utiliser.

cf par exemple http://www.virtualdub.org/blog/pivot/entry.php?id=107

D'ailleurs dans les minimum systeme requirements de windows 8, c'est

1 Go de ram en 32-bit
2 Go de ram en 64-bit

Je souscris à cette excellente proposition

C'est malin, très malin, et pas forcément inutile. Mais si ça implique de devoir passer par une très longue phase d'apprentissage/lavage de cerveau, on est très très loin du compte.

Si je me souviens bien de ce que j'ai lu à ce sujet il y a quelques jours, ils se sont constitué une base de données de reponses en diffusant des videos youtube à des sujets tests (quelques 10 millions d'images en tout je crois). Ils ont ensuite pris d'autres cobayes, leur ont diffusé des extraits de video qui n'étaient pas parmis ceux diffusés aux premiers sujets, et ont fait la reconstruction sur ceux là. On peut supposer que la base de données constituée à partir de youtube devrait permettre d'avoir déjà des reconstructions très precises pour tout ce qui concerne les chats.

qu'est-ce qui t'embete avec les FS cryptés ?

Pour moi l'interet c'est de l'avoir installé en même temps x86_64 (voire aussi i686 pour la compatibilité avec les vieilles applis 32-bits). L'abi est de toute façon differente de i686, on ne peut pas faire utiliser une lib i686 à une appli x32 , mais les differents systemes peuvent coexister ensembles et ça c'est interessant puisque chaque abi a ses avantages et ses inconvenients

http://zipiz.com

Mon experience avec les autotools, qui remonte a quelques années certes mais j'en ai bouffé pas mal, c'est quand même que ça ne marche bien que dans des environnements 100% gnu. Sous hpux , irix ou dec osf il y avait toujours un truc qui foirait, en particulier quand libtool entrait en jeu , et globalement c'était bien plus simple d'écrire du platform-specifique en dur dans les makefiles pour chaque plateforme plutot que d'essayer de rescotcher les bouts d'autotools qui se detachaient.

perso j'ai adopté scons mais je pense que n'importe quel outil sera meilleur que autoconf/make, que ce soit cmake, waf , rake ... Il faudrait juste arreter d'utiliser par default, pour chaque nouveau projet libre , les autotools.

le truc tu dis ce qui te manque, ce qui est nettement plus parlant que 'truc.h not found'

Sauf quand tu dois farfouiller dans le config.log pour comprendre qu'est ce qui lui pose vraiment probleme avec la libtruc après qu'il t'ait dit "checking for truc.. no". Et sauf quand tu as installé la libtruc qui manque et que le configure persiste a ne pas la voir et que tu passes des heures à chercher la bonne manière de lui faire ajouter le bon flag qui va bien sur le bon fichier.

Accessoirement, je n'ai pas de probleme avec les usines a gaz quand elles savent faire des trucs puissants et compliqués. Le probleme des autotools c'est que c'est une usine à gaz , mais sans etre puissant ou portable, c'est juste mauvais, lent, et fragile. Ainsi que mal documenté.

ils le sont bien entendu. Il n'y a rien de robuste dans les autotools c'est un assemblage hétéroclite de bout de scripts shell , de makefile et de macros m4 emballé dans du perl, qui genere plus ou moins automatiquement un milliard de micro-fichiers plus ou moins indispensables. Pour moi il est vraiment temps que le libre se trouve un autre outil de build que l'infernale combinaison autoconf/automake/libtool/make . Quelque chose qui soit vraiment portable (parce que les autotools n'ont rien de portable , ça ne fonctionne relativement fiablement que sous les derives de gnu/linux avec un toolchain gnu), qui soit simple a ecrire quand on sort du GNU/Hello trivial , qui ne genere pas un ./configure de 350Ko pour gnu/hello

c'est par opposition à un truc tout branlant , fait de bric et et broc et assemblé avec du scotch, les autotools par exemple.

utilisation de vulnérabilité dans le "thumbnailer"

c'est d'ailleurs un truc dans ce style qu'utilise le virus stuxnet qui est allé mettre le bordel en iran:

instead of exploiting a vulnerability to forcibly execute an autorun.inf file, Stuxnet takes advantage of a vulnerability in parsing shortcut (.LNK) files in order to execute a malicious Control Panel module.

An attacker can subvert this operation with a specially crafted .LNK file, which is pointed to a specially crafted Control Panel module (in reality, the malware). When the system attempts to resolve the shortcut file's icon, the vulnerability is triggered and the Control Panel module is automatically executed. The user does not need to click on the icon in order for the malware to be executed. ( http://www.f-secure.com/v-descs/trojan-dropper_w32_stuxnet.shtml )

D'autant que seuls les sodas au vrai sucre sont concernés: "les eaux, les jus de fruit (sans sucres ajoutés) et les produits contenant des édulcorants ne sont pas concernés par cette mesure".

elle n'est atomique que si tes threads ne s'executent que sur un seul coeur , pour les situations où plusieurs coeurs accedent de manière concurrente à la mémoire il faut ajouter le préfix "lock" devant ton instruction, et c'est là que ça commence à couter cher. cf par exemple: http://www.codemaestro.com/reviews/8

Ah c'est marrant moi je dirais vive le c++ avec son rtti et ses templates (utilisés a doses raisonnables) , mais non aux exceptions qui puent et aux iostreams qui sont la honte des flux d'entrée sortie

ouais mais le truc c'est qu'une operation atomique c'est pas loin de couter aussi cher que de locker un mutex. J'avais lu ça sur une page web qui donnait des mesures assez precises, mais je ne la retrouve pas. Il y a celle ci:

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html

qui indique que le mutex prend 0.2 microsec contre 0.05 microsec pour l'operation atomique, et ce dans le meilleur des cas, sur un core duo à 2GHz

ah oui pardon effectivement je parlais des shared_ptr et non des scoped_ptr dont j'ignorais d'ailleurs l'existence

Et quel est le surcout des smart pointeurs au final, faut-il faire attention a ne pas trop en abuser ? Parce qu'a priori a chaque creation ou copie, il y a incrementation atomique d'un compteur de references, il me semble que ce genre d'operation prend typiquement 100 cycles sur un cpu moderne.