Alors il suffit de faire un link static, et l'application sera nettement plus petite puisque toutes les parties non utilisées des libs qt seront enlevées
J'aimerais bien voir des exemples où ça fait une difference notable (et sur quel archi) parce qu'à chaque fois que j'ai essayé de l'utiliser ça a été non mesurable
Alors, ce Daala, est-il tant meilleur que ça que H.265? Non? Ce sera un échec
Qu'est ce que tu en sais ? Rien. Eux non plus d'ailleurs puisque c'est en developpement et que "Daala tries for a larger leap forward— by first leaping sideways— to a new codec design ".
Autrement dit la tactique est de s'éloigner deliberément de h265 avant de commencer le travail d'optimisation, avec l'espoir que le processus d'optimisation de les ramenera pas sur le minimum local qu'est h265. Moi je trouve ça interessant. Ca peut echouer, ca peut réussir.
C'est assez fatiguant de lire ces commentaires blasés sur linuxfr. Moi je m'en fous mais si j'étais le dev de ce codec y'aurait rien de tel pour me démotiver.
Un bon fanboy t'expliquera que c'est une super feature puisque ça évite de remplir la mémoire du serveur X avec les données à copier quand on fait le contrôle-C (au lieu de ça ton appli se contente de lui indiquer que si quelqu'un veut coller un truc, elle pourra fournir les données, et meme négocier le format avec l'appli qui veut coller). Mais comme tu le fais remarquer, si l'appli source disparait entre le ctrl-C et et le ctrl-V, c'est raté !
Mais bon, vu comme c'est merdique et incomprehensible faudrait vraiment avoir des oeilleres pour trouver ça génial.
Bon sinon c'est bien pour les photographes et autres, mais je crois que ton post concerne le grand publique ?
Ben oui, genre les gens qui lisent du texte qui s'affiche sur un écran, genre toi ou moi en ce moment :) Ca apporte quand meme un vrai confort de lire du texte qui est parfaitement défini, des caractères avec une jolie typographie , sans bords flous et non déformés par un vilain algorithme de hinting pour coller à la grille de pixels.
Pourquoi faire des écrans à des résolutions aussi hautes si c'est pour faire une affichage ou chaque "pixel" logique serait un agglomérat de 4 pixels physiques ?
C'est juste une astuce pour presenter à l'application une unité (le pixel) qui aura la même taille (on pourrait même dire "le même angle" , c'est le rapport taille / distance qui compte ici), que l'écran soit normal ou haute résolution. Avec l'avantage que ça marche bien pour l'existant dont les gui ont été dimensionnées en pixels par rapport à un écran canonique. Au lieu de dire "pouah les gros nuls de developpeurs, il fallait specifier l'interface en une unité independante de la résolution" , Apple a décreté que le pixel était une unité independante de la résolution physique.
A priori il n'y a un petit surcout que quand le rapport entre la résolution virtuelle et la résolution physique n'est pas un entier (genre quand macos fait du 1920x1080 sur un ecran 2560x1440)
Pour jack, c'est temps réel et latence faible à tout prix même si ça bouffe 100% du processeur.
Pour PA, c'est plus orienté desktop avec dans l'idée quelque chose de pas trop mauvais le plus > souvent mais sans aucune garantie de latence mais avec une charge machine plus faible.
Ben ouais mais regarde macos (ou ios). Une seule API, coreaudio, qui permet de tout faire, faible latence ou gros buffers, zéro prise de tête et tout le monde est content. Ca aurait surement été possible sous linux si poettering s'était interessé aux problématiques de temps réel pour l'audio dès le départ, et si les gens qui gravitent autour de jack avaient été un peu moins violents dans leurs réactions.
vs2012 a beaucoup de "No", et pas sur des features c++11 anecdotiques. Ca me semble un peu abusé de dire qu'il est au même niveau que les gcc et clang d'il y a un an.
Moi j'aime bien remplacer le pain par des pâtes, genre des trucs bien plats. Avec un peu de sauce tomate , bechamel et fromage, cuit au four, c'est très bon !
Vas-y montre nous des applications desktop open source C ou C++ qui font quelque chose de plus sophistiqué que exit() précedé optionnellement d'une tentative d'affichage d'un petit message à l'utilisateur avant la mort du soft, je suis bien curieux de voir comment ils gèrent ça.
Et je te donne 50 points de bonus si en plus tu en es l'auteur !
Ouais mais non google au début c'était pas du marketting bien au contraire. C'etait juste le premier moteur de recherche qui ne soit pas farci de pubs lourdingues, avec une page d'acceuil hyper legere et dépouillée, et des résultat incomparablement plus pertinents que les autres. Quand il est apparu google était tout simplement le meilleur, et pas de peu. Et c'est clairement le bouche à oreille qui l'a fait connaitre progressivement, en tout cas moi je faisais partie des gens qui ne pouvaient pas s'empecher de dire aux autre de laisser tomber leur altavista tout moisi et d'essayer ce nouveau moteur de recherche
Ces instructions nécessitent, comme l'indique le "atomique", qu'un seul coup d'horloge pour être exécutée
Ca prend plus d'un cycle d'horloge. Dans mon souvenir c'est de l'ordre de 100 cycles pour une instruction atomique quand un lock de mutex (sans contention) en prend 300
Bof a l'usage moi je la trouve très fiable, et beaucoup moins couteuse que tous les appels a clock_gettime ou QueryPerformanceCounter et cie qui ont vite fait de plomber les perfs. Dans mon expérience le seul cas où ça a semblé faire de la merde à uné époque c'était sur certains athlons x2, et sur ces machines le QueryPerformanceCounter souffrait du meme bug (perte de synchro des compteurs entre les coeurs, je crois que maintenant tous les os font le necessaire pour que ça n'arrive plus).
parce que le printf debugging c'est mal, ça peut faire apparaitre des bugs étranges ou les faire disparaitre (dans tous les cas c'est la merde)
On peut en dire autant du debuggeur, il y a aussi des bugs qui ne se produisent qu'en dehors du debuggeur.
parce que savoir quand une variable est modifié et par ou (avoir la stack), est parfois essentiel à la correction d'un bug.
C'est vrai mais honnetement ça ne m'arrive pour ainsi dire jamais , à par dans les cas où ça sent la corruption de mémoire , et là en général je commence par sortir valgrind
parce que des traces trop verbeuses peuvent avoir un gros impact sur les perfs; l'appli sur laquelle je bosse fait des traces de plusieurs centaines de Mo à l'heure, et on essaye de retreindre…
Il suffit de ne pas faire des traces monstrueuses, debugger au printf pour moi ça ne veut pas dire farcir chaque ligne de code avec un printf("prout oulala %d:%d\n", FILE,__LINE__) , tout comme je ne commence pas par lacher un milliard de breakpoints avant de demarrer gdb
Parce que changer une valeur sans avoir à tout recompiler permet de tester des cas plus larges.
Certes
Parce que dès qu'on joue un petit peu avec des theads, les traces ont un impacte dans l’ordonnancement.
Le debuggeur aussi , d'autant plus si tu as été obligé de recompiler ton code avec les optimisations un peu moins fortes pour avec des stack trace qui ressemblent à quelque chose
# nostalgie
Posté par Troy McClure (site web personnel) . En réponse au journal A quand la prochaine secousse sismique dans le monde High-Tech ?. Évalué à 10.
Ah ça me rappelle la douce époque où on arborait fierement nos montres-calculatrices au poignet. Ca c'était la classe
[^] # Re: Migrations ?
Posté par Troy McClure (site web personnel) . En réponse à la dépêche Qt 5.1 est juillet. Évalué à 5.
Alors il suffit de faire un link static, et l'application sera nettement plus petite puisque toutes les parties non utilisées des libs qt seront enlevées
[^] # Re: Prédiction de branchement
Posté par Troy McClure (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 4.
J'aimerais bien voir des exemples où ça fait une difference notable (et sur quel archi) parce qu'à chaque fois que j'ai essayé de l'utiliser ça a été non mesurable
[^] # Re: Pour le succès
Posté par Troy McClure (site web personnel) . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 5. Dernière modification le 03 juillet 2013 à 21:14.
Qu'est ce que tu en sais ? Rien. Eux non plus d'ailleurs puisque c'est en developpement et que "Daala tries for a larger leap forward— by first leaping sideways— to a new codec design ".
Autrement dit la tactique est de s'éloigner deliberément de h265 avant de commencer le travail d'optimisation, avec l'espoir que le processus d'optimisation de les ramenera pas sur le minimum local qu'est h265. Moi je trouve ça interessant. Ca peut echouer, ca peut réussir.
C'est assez fatiguant de lire ces commentaires blasés sur linuxfr. Moi je m'en fous mais si j'étais le dev de ce codec y'aurait rien de tel pour me démotiver.
[^] # Re: le clipboard ...
Posté par Troy McClure (site web personnel) . En réponse au journal Mais qui a mangé mon presse-papier?. Évalué à 10.
Un bon fanboy t'expliquera que c'est une super feature puisque ça évite de remplir la mémoire du serveur X avec les données à copier quand on fait le contrôle-C (au lieu de ça ton appli se contente de lui indiquer que si quelqu'un veut coller un truc, elle pourra fournir les données, et meme négocier le format avec l'appli qui veut coller). Mais comme tu le fais remarquer, si l'appli source disparait entre le ctrl-C et et le ctrl-V, c'est raté !
Mais bon, vu comme c'est merdique et incomprehensible faudrait vraiment avoir des oeilleres pour trouver ça génial.
[^] # Re: Idée pour Steam
Posté par Troy McClure (site web personnel) . En réponse au journal Linux totalise 1,07% des utilisateurs Steam en juin 2013. C'est déjà ça.... Évalué à 6.
y'a surgeon simulator 2013 quand même
[^] # Re: muè
Posté par Troy McClure (site web personnel) . En réponse au journal L'avenement des écrans haute-résolution. Évalué à 9.
Ben oui, genre les gens qui lisent du texte qui s'affiche sur un écran, genre toi ou moi en ce moment :) Ca apporte quand meme un vrai confort de lire du texte qui est parfaitement défini, des caractères avec une jolie typographie , sans bords flous et non déformés par un vilain algorithme de hinting pour coller à la grille de pixels.
[^] # Re: question un peu idiote
Posté par Troy McClure (site web personnel) . En réponse au journal L'avenement des écrans haute-résolution. Évalué à 9.
sinon sur mac ils en sont rendus à recommander des faire des
icones en 1024x1024 !
[^] # Re: question un peu idiote
Posté par Troy McClure (site web personnel) . En réponse au journal L'avenement des écrans haute-résolution. Évalué à 2.
C'est juste une astuce pour presenter à l'application une unité (le pixel) qui aura la même taille (on pourrait même dire "le même angle" , c'est le rapport taille / distance qui compte ici), que l'écran soit normal ou haute résolution. Avec l'avantage que ça marche bien pour l'existant dont les gui ont été dimensionnées en pixels par rapport à un écran canonique. Au lieu de dire "pouah les gros nuls de developpeurs, il fallait specifier l'interface en une unité independante de la résolution" , Apple a décreté que le pixel était une unité independante de la résolution physique.
A priori il n'y a un petit surcout que quand le rapport entre la résolution virtuelle et la résolution physique n'est pas un entier (genre quand macos fait du 1920x1080 sur un ecran 2560x1440)
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par Troy McClure (site web personnel) . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 4.
Ben ouais mais regarde macos (ou ios). Une seule API, coreaudio, qui permet de tout faire, faible latence ou gros buffers, zéro prise de tête et tout le monde est content. Ca aurait surement été possible sous linux si poettering s'était interessé aux problématiques de temps réel pour l'audio dès le départ, et si les gens qui gravitent autour de jack avaient été un peu moins violents dans leurs réactions.
[^] # Re: et le seul et unique alors ?
Posté par Troy McClure (site web personnel) . En réponse au sondage Votre univers SF / Space opéra préféré. Évalué à 5.
Best movie ever
[^] # Re: Et pendent ce temps chez Microsoft...
Posté par Troy McClure (site web personnel) . En réponse à la dépêche C++11 : sur le fil. Évalué à 5. Dernière modification le 08 juin 2013 à 12:30.
Pourtant quand on regarde ce document (qui date d'il y a a peu près un an):
http://cpprocks.com/a-comparison-of-c11-language-support-in-vs2012-g-4-7-and-clang-3-1/
vs2012 a beaucoup de "No", et pas sur des features c++11 anecdotiques. Ca me semble un peu abusé de dire qu'il est au même niveau que les gcc et clang d'il y a un an.
[^] # Re: Ironie ?
Posté par Troy McClure (site web personnel) . En réponse au journal Tropes vs Women : Damsel in Distress (part 2). Évalué à 10.
[^] # Re: Mir et Wayland ne sont pas comparables
Posté par Troy McClure (site web personnel) . En réponse au journal Mir est peut-être une hérésie mais.... Évalué à 6.
Ah oui comme au Bangladesh, effectivement ça a l'air efficace
# Autre variante
Posté par Troy McClure (site web personnel) . En réponse au journal Recette pour burgers. Évalué à 10.
Moi j'aime bien remplacer le pain par des pâtes, genre des trucs bien plats. Avec un peu de sauce tomate , bechamel et fromage, cuit au four, c'est très bon !
[^] # Re: Frites maison ?
Posté par Troy McClure (site web personnel) . En réponse au journal Recette pour burgers. Évalué à 7.
jore tu l'as fait exprès…
[^] # Re: Malloc Linux
Posté par Troy McClure (site web personnel) . En réponse au journal Où il est question de D3, des communes de France et des performances SVG des moteurs de rendu. Évalué à 2.
nope, *printf peut appeller malloc , (meme sprintf).
[^] # Re: Malloc Linux
Posté par Troy McClure (site web personnel) . En réponse au journal Où il est question de D3, des communes de France et des performances SVG des moteurs de rendu. Évalué à 3. Dernière modification le 22 mai 2013 à 11:48.
Vas-y montre nous des applications desktop open source C ou C++ qui font quelque chose de plus sophistiqué que exit() précedé optionnellement d'une tentative d'affichage d'un petit message à l'utilisateur avant la mort du soft, je suis bien curieux de voir comment ils gèrent ça.
Et je te donne 50 points de bonus si en plus tu en es l'auteur !
[^] # Re: Titre racoleur, vidéo intéressante.
Posté par Troy McClure (site web personnel) . En réponse au journal Le succès de Google est-il mathématique?. Évalué à 10.
Ouais mais non google au début c'était pas du marketting bien au contraire. C'etait juste le premier moteur de recherche qui ne soit pas farci de pubs lourdingues, avec une page d'acceuil hyper legere et dépouillée, et des résultat incomparablement plus pertinents que les autres. Quand il est apparu google était tout simplement le meilleur, et pas de peu. Et c'est clairement le bouche à oreille qui l'a fait connaitre progressivement, en tout cas moi je faisais partie des gens qui ne pouvaient pas s'empecher de dire aux autre de laisser tomber leur altavista tout moisi et d'essayer ce nouveau moteur de recherche
[^] # Re: Pas thread safe
Posté par Troy McClure (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 4.
Ca prend plus d'un cycle d'horloge. Dans mon souvenir c'est de l'ordre de 100 cycles pour une instruction atomique quand un lock de mutex (sans contention) en prend 300
[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par Troy McClure (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Bof a l'usage moi je la trouve très fiable, et beaucoup moins couteuse que tous les appels a clock_gettime ou QueryPerformanceCounter et cie qui ont vite fait de plomber les perfs. Dans mon expérience le seul cas où ça a semblé faire de la merde à uné époque c'était sur certains athlons x2, et sur ces machines le QueryPerformanceCounter souffrait du meme bug (perte de synchro des compteurs entre les coeurs, je crois que maintenant tous les os font le necessaire pour que ça n'arrive plus).
[^] # Re: Oui
Posté par Troy McClure (site web personnel) . En réponse au journal Un debugger est-il indispensable ?. Évalué à 3.
On peut en dire autant du debuggeur, il y a aussi des bugs qui ne se produisent qu'en dehors du debuggeur.
C'est vrai mais honnetement ça ne m'arrive pour ainsi dire jamais , à par dans les cas où ça sent la corruption de mémoire , et là en général je commence par sortir valgrind
Il suffit de ne pas faire des traces monstrueuses, debugger au printf pour moi ça ne veut pas dire farcir chaque ligne de code avec un printf("prout oulala %d:%d\n", FILE,__LINE__) , tout comme je ne commence pas par lacher un milliard de breakpoints avant de demarrer gdb
Certes
Le debuggeur aussi , d'autant plus si tu as été obligé de recompiler ton code avec les optimisations un peu moins fortes pour avec des stack trace qui ressemblent à quelque chose
# wow
Posté par Troy McClure (site web personnel) . En réponse au journal Un ordinateur sous Linux à 500 000 $. Évalué à 9.
C'est fort impressionnant, quelle distribution Linux a les reins assez solides pour faire tourner une telle machine de course ?
[^] # Re: Quelques idées
Posté par Troy McClure (site web personnel) . En réponse au journal Les friture essentielles du canard du futur. Évalué à 3.
support de http://theonion.github.io/fartscroll.js/
[^] # Re: .
Posté par Troy McClure (site web personnel) . En réponse au journal Les friture essentielles du canard du futur. Évalué à 4.