Troy McClure a écrit 2213 commentaires

ptet qu'il écoute de la musique pour chauve-souris

J'en ignorais tout merci de m'ouvrir les yeux !

ben chais pas, quand le brave kim ecrivait a ses collaborateurs "Les suppressions (de fichiers) en masse contribuent à une baisse des revenus" ( http://www.numerama.com/magazine/21337-le-dossier-accablant-du-procureur-contre-megaupload.html ) j'imagine que tu vas me dire qu'il parlait bien evidemment des suppressions d'iso debian

Wow t'es vraiment d'une mauvaise foi confondante

Et ils répondaient aux requêtes dmca, donc étaient totalement en accord avec la loi.

Non car ils n'étaient pas suffisament proactifs sur les contenus dont ils savaient qu'ils étaient piratés et sur lesquels le fbi a les mails echangés entre les employés comme preuves, cf l'article de ars technica https://linuxfr.org/nodes/89091/comments/1311960

http://arstechnica.com/tech-policy/news/2012/01/why-the-feds-smashed-megaupload.ars

Megaupload employees apparently knew how the site was being used. When making payments through its “uploader rewards” program, employees sometimes looked through the material in those accounts first. "10+ Full popular DVD rips (split files), a few small porn movies, some software with keygenerators (warez)," said one of these notes. (The DMCA does not provide a "safe harbor" to sites who have actual knowledge of infringing material and do nothing about it.)

sinon, les USA, ca a des cotés sympa. le rock 'n roll, le chewing gum, le coca...

Et les bonnes séries qu'on télécharge sur megaupload !

A priori audioflinger c'est un demon écrit en c++: http://gitorious.org/android-eeepc/base/blobs/90329a69f8e26626c3dc51c50a287e47931afe18/libs/audioflinger/AudioFlinger.cpp

Sinon j'aime bien le bug report sur les pb de latence d'android qui montre bien que google n'en a strictement rien à foutre: http://code.google.com/p/android/issues/detail?id=3434

Je propose qu'on remplace Lara Croft par un Tux avec un gros gun.

et la qualité sonore ne se degrade pas quand il y a du reechantillonage ? parce que "trivial" ça sonne comme "interpolation lineaire" voire pire (j'imagine qu'il faut se taper les sources pour savoir ce que c'est exactement) , le genre de truc idéal pour avoir un son de casserole. Le fait qu'ils aient choisi par defaut un resampling de qualité correcte ne me semble pas etre une erreur de configuration.

ça reste quand même un peu cher la lecture de partitions cryptées, par exemple j'ai pu constater qu'un Atom, qui n'est pas tellement plus puissant qu'un cpu de smartphone, sature a 100% cpu pour une vitesse de lecture de 16Mo/s. Sans doute que ça ne sera dispo sur ces machines que le jour où leurs cpus auront une acceleration materielle pour ces operations crypto

Peut etre que finalement XCB n'était pas si "nécessaire" que ça et que tout marche plutot bien avec la libX11

je suis totalement d'accord, un menu, que ce soit un popup ou dans une barre de menu, ça n'est "pratique" que quand il n'a qu'un seul niveau: tu cliques pour ouvrir le menu, et tu bouges la souris jusqu'à la ligne qui t'interesse. Dès qu'il faut entrer dans un sous-menu ça devient tout de suite très fastidieux.

Voir la tronche de Jimmy Whales dans une énorme bannière sur toutes les pages wikipedia pendant deux mois par an, je me demande si ce n'est pas plus énervant et intrusif qu'une bonne petite pub pour du viagra dans un coin de l'écran

les cartes son ont perdu en fonctionnalité (mixage en hard) car ça n'avait plus aucun interet de faire cette operation sur la carte son, le coût de cette opération étant epsilonesque pour un cpu moderne. Il se demande si le même phénomene ne va pas un jour rendre les GPUs obsoletes.

altivec a les mêmes contraintes d'alignement sur les load et les store que SSE, et il n'a même pas d'instructions non-alignées comme les movups de SSE. Par contre le shuffle de altivec est autrement plus puissant que celui de sse.

Arf je fais pareil, quand ça swappe un peu trop il ne faut pas hesiter à sortir le killall firefox. J'avais commencé à faire ça a une epoque ou il fallait parfois dix minutes à un vieux (genre une ou deux semaines d'âge) firefox pour quitter proprement, je ne sais pas trop ce qui posait probleme. Puis j'ai continué quand je voulais juste repartir sur un firefox frais sans perdre les onglets ouverts. Il existe aussi un certain nombres d'extensions pour rebooter firefox mais je n'ai pas eu trop l'occasion de m'en servir

ne marche pas.

ça se produit en particulier sur la tribune

J'ai pas comparé avec le jpg, mais par contre le webp en qualité 90 est a peu pres comparable au png pour le temps de decompression, genre 15% ou 20% plus lent seulement. C'est plus rapide en qualité moindre et plus lent en qualité supérieure, mais je n'ai pas la moindre idée de comment se situe jpg par rapport à png. Je n'ai pas non plus vu d'acceleration notable avec sse2 dans webp, par rapport à la version c basique.

Pour webpll je pense que le code n'a pas encore été pleinement optimisé, d'ailleurs c'est du c++ alors que webp est en C, et on dirait que les images webpll n'ont pas le moindre magic number dans le header, j'imagine que google voudra corriger ça quand il auront une version moins experimentale

par contre en terme de vitesse de decompression c'est pas encore ça, pour l'instant la decompression du webpll est 5x plus lente que celle du png , (mais c'est une version alpha il y a peut etre une marge de progression conséquente).

En fait les noms des outils laissent entendre que le format lossless s'appellerait webpll , alors que le format lossy s'appelle webp . Actuellement les sources des deux formats sont completements independantes, meme si elles vivent dans le même dépot.

Les sources du format lossless sont d'ailleurs très concises , 1500 lignes pour le decodeur seul, 5600 pour le decodeur, l'encodeur et l'outil de conversion png <-> webpll , et il n'a pas de dependance sur la zlib (contrairement à libpng, qui compte plus de 40000 lignes de sources)

Si relis mon commentaire avec attention tu verras que je parlais de GIF ANIME pas de webp, quand je mentionnais la simplicité à pleurer.

Cela dit, par une extraordinaire coïncidence, j'étais justement en train de regarder le poids de la lib webp:

cwebp , l'outil de compression, compilé avec la libwebp statique et strippé, pèse 87ko
dwebp , l'outil de décompression, pèse 83ko

On reste donc dans quelque chose d'assez léger, même si beaucoup plus sophistiqué qu'un truc qui lit les gifs, y'a des optimisations sse2/neon, y'a du multi thread dans le décodeur etc..

Y'a la même chose dans les gifs animes, ouvre un gif de kitten animé dans gimp, si il a été 'optimisé' la frame n ne contient que les informations de modification de la frame n-1

pour moi ce qui distingue un gif animé d'une video h264 ou webm, c'est que le "decodeur" est d'une simplicité à pleurer par rapport aux videos, et que ça tient dans 10ko de C.