Shuba a écrit 439 commentaires

Ma mince expérience me laisse penser qu'il doit y avoir au moins un standard de fait, pour certains signaux.

En effet, j'avais des écouteurs pour mon téléphone qui permettaient d'envoyer les signaux start/stop, next et previous. Lorsqu'ils ont laché, j'en ai racheté d'une autre marque, mais qui n'avaient pas les mêmes fonctionnalités : sart/stop, volume +/-. Le résultat: le start/stop marche, mais pas le volume +/-.

Ce que je peux en déduire : au moins le start/stop respecte un standard de fait. Pour le reste, c'est peut-être mon téléphone qui n'implémente pas le volume +/- par jack.

L'article semble suggérer que ce comportement existe surtout pour des mots clés peu courants, et même sous Bing, je ne pense pas que "Linux" soit un terme de recherche rare :)

Quand on parle de système distribué, les problèmes dits byzantins sont ceux où une partie des acteurs essaie volontairement de tromper les autres, en ne respectant pas le protocole. Ces problèmes sont très difficiles, les cas qu'on sait résoudre sont assez rares je crois, et imposent des hypothèses sur le nombre d'ennemis (pas plus de la moitié du nombre d'acteurs généralement).

Je crois que l'idée est qu'il y aurait des patents trolls de type "prédateur", qui déposent des brevets pouvant couvrir les technologies durant leur développement, et qui ensuite, espèrent bien se faire un max de thune. D'où un coût pas forcément indolore.

Et il y a des exemples de cas ou des brevets on effectivement freiné de 20 ans l'arrivée d'une technologie (bon, pas par crainte de prédation cependant). Par exemple, le JPEG utilise un codage de Huffman plutôt qu'un codage arithmétique (10% plus efficace en gros), parce qu'à l'époque où ça a été développé, IBM avait un brevet sur le codage arithmétique. Par contre, pour JPEG2000, le problème ne s'est pas posé, les 20 ans étaient passés.

Une explication que j'avais entendu au détour d'une conversation serait que pas mal d'acteurs aimeraient bien attendre 20 ans avant de se mettre à vraiment faire de l'IPv6, par craintes de gens qui auraient pu poser des brevets couvrant les diverses parties de IPv6 durant son développement.

Je sais pas vraiment si cette explication est valable, mais ça m'avait semblé plausible.

La raison pour laquelle il est important d'avoir des langages avec des paradigmes différent, c'est qu'avec les paradigmes impératifs, on est tout sauf sûrs d'arriver à continuer à profiter de la loi de Moore. En effet, la fréquence des processeurs n'augmente plus, seul le nombre de coeurs augmente désormais. D'où la nécessité décrire des programmes concurrents ou distribués. Sauf que les langages tels que Java ne proposent que les verrous comme seuls moyens de faire de la programmation concurrente, et ceux-ci ne passent pas vraiment à l'échelle.

À l'opposé, des langages aux paradigmes différents proposent des modèles de parallélisme bien plus évolués : Scala et ses agents, Haskell a une STM, Erlang est conçu pour le message passing, etc.

Avec une différence fondamentale entre la programmation "classique" et la programmation parallèle : si avant on bénéficiait du modèle de Turing pour nous dire que de toute façon, on savait que tout était faisable, là c'est tout sauf le cas, on ne sait toujours pas (à ma connaissance) s'il est possible d'avoir la même classe de calculabilité en distribué qu'avec un seul process. D'où le fait qu'aller chercher des paradigmes différent pourrait aider à mieux appréhender ce problème.

Pour résumer mon post long et plutôt mal structuré en une phrase : on peut continuer à coder en impératif, mais alors il faudra peut-être dire adieu au doublement de la puissance de calcul tous les 18 mois.

J'aurais jamais pensé qu'on pouvait donner les chemins de fer anglais en exemple...

En java, oui, mais là on parle de language avec une VM (pas nécessairement d'un hybride comme java ou C# donc), ce qui veut dire que les langages interprétés ayant une vm ne profitent pas de ce genre d'optim (et mon propos n'a un sens que pour ces languages en fait).

Je comprends l'intérêt d'activer ou d'enlever des trace de debug mais un simple 'if' fait le même boulot, si la VM n'est pas trop stupide, cela aura le même effet qu'un #ifdef en java.

Alors là, il faut que tu m'expliques comment la vm peut faire pour optimiser un if de ce genre... Dans le cas du #ifdef, le code est naturellement optimisé, dans le cas d'un if, même si tu t'amuses à retenir dans ta VM que tel type de conditionnelle est toujours évaluée à true, tu te retrouves quand même à devoir faire un jump derrière, et je pense pas que ça soit strictement équivalent en termes de perfs.

C'est plus un avis sur l'informatique hein. Je trouve ça triste que chaque jour, on réinvente la roue, mais carrée cette fois-ci.

Tu vois beaucoup d'ingénieurs dans le batiment aller poser des briques ou couler du béton toi ? Chacun son travail.


Il me semblait qu'en informatique, le travail des ouvriers est fait par quelquechose appelé un compilateur.

Si, dans cette opposition codeur/ingénieur, tu considères que le rôle du codeur c'est cracher du code sans réfléchir (et c'est ce que je comprends de ce que tu dis), alors il y a un problème, les tâches où on ne réfléchit pas, ce n'est pas pour l'homme.

C'est du journalisme total.

Si je comprends bien, l'intérêt du patch, c'est que les process qui demandent rarement du CPU, mais en ont besoin immédiatement pour leur réactivité (typiquement les applis graphiques donc), sont favorisées par ce group scheduling, sans que ça gêne trop les autres.

Ici, c'est le tty d'origine qui est utilisé pour déterminer les groupes. Est-ce qu'un système d'apprentissage ne serait pas envisageable? Par exemple, chaque nouveau process apparaît dans son propre groupe, donc bénéficie souvent d'opportunités pour prendre du temps CPU. En comptabilisant le pourcentage d'opportunités où il prend finalement ce temps CPU, on pourrait alors créer des groupes regroupant les process selon ces pourcentages.

Est-ce que ça semblerait bien, ou est-ce que ça serait plutôt une gène pour le système?

Il me semble que Gallium3d étant le state tracker, l'implémentation GPGPU se fera au dessus.

En effet, si je dis pas de bêtises, le state tracker est surtout là pour permettre la gestion de la mémoire, et n'enferme donc pas le driver au-dessus dans un point de vue graphique.

J'ajouterais que comparer Direct3D10/11 à OpenGL en parlant de l'implémentation mesa de OpenGL, c'est un peu comparer Direct3D10/11 à OpenGL 2.1, vu qu'il ne me semble pas que Mesa aille au dessus (pas sans Gallium3d en tout cas).

Du coup, c'est facile de dire que le design est bien plus clean dans Direct3D... Mais si on regarde bien, OpenGL3.0 apporte un design très différent de 2.0, et c'est encore accentué dans OpenGL 4.0.

Pour ce qui est des perfs, je crois bien que NVIDIA développe ses cartes en ayant OpenGL en tête, et influence le design d'OpenGL pour ses cartes, donc ça devrait pas faire pencher la balance en faveur de D3D.

Ça en est que ça attend un peu plus de maturité du coté de gallium 3d, qui, si très prometteur, n'est pas encore vraiment utilisable au quotidien dans pas mal de cas (de ce que j'en ai testé en tout cas).

Mais à ton ton un peu arrogant et provocateur, j'ai comme l'impression que tu ne mesures pas vraiment la difficulté du travail. Un driver de carte graphique, c'est vraiment tout sauf trivial.

Un facteur 30 si on suit tes chiffres, ca c'est de la compression...

Tu sais, les séquences les plus difficiles à compresser, ce sont les séquences aléatoires. À l'inverse, les séquences les plus triviales (0000000...) sont très fortement compressibles. Tu ne peux pas donc affirmer que le facteur de compression élevé implique un algorithme performant. Ce pourrait tout aussi bien être une très forte redondance du contenu décompressé... Ce qui est pas loin de l'affirmation qu'on trouve dans le post original.

Je me permet en tant que développeur de VLC de répondre à ce post très bien noté alors qu'il dis à peu près n'importe quoi (désolé pour l'auteur ce n'est pas personnel).

C'est sûrement pas la première ni la dernière fois que je dis n'importe quoi :)
Ça m'apprendra à parler sans être bien au courant.

Merci, je ne connaissais pas CImg.

Reste qu'on m'impose le prototypage en Matlab-like, si ça ne tenait qu'à moi, je ferais tout en C++ (marre de se faire chier à vectoriser des boucles pour atteindre des perfs décentes, c'est perdre du temps par rapport à coder en C++...).

Octave est vraiment sympa, le problème est qu'il n'est pas facile de produire du code qui fonctionne bien sous Octave comme sous Matlab. D'un coté, la syntaxe un peu plus permissive d'Octave peut faire du code qui ne tournera pas sous Matlab. De l'autre coté, Matlab étant plus rapide qu'Octave grâce à son JIT, le code produit pour Matlab sera plus souvent parsemé de boucles, le rendant peu pratiquable sous Octave.

À cela s'ajoute le manque de certaines fonctions Matlab sous Octave, mais ce pourrait être surmonté en s'en donnant les moyens (par exemple en donnant à des étudiants la possibilité de coder ces paquets en tant que projet). Mais pour ça, il faudrait convaincre les ensignants de travailler sous Octave.

http://www.fsf.org/news/blogs/licensing/more-about-the-app-s(...)

C'est la license de l'App Store qui impose des restrictions d'utilisation aux logiciels proposés, ce qui n'est pas permis par la GPL.

Il n'est pas interdit de faire un port sur iOS, juste de le ditribuer via l'App Store. Et vu qu'Apple interdit/empêche l'installation de soft via autre chose que l'App Store, autant ne pas perdre de temps à porter des logiciels sous GPL sur iOS.

Tu as un lien vers ce talk?

L'écrasante majorité de la population ne sait pas vraiment de quoi il retourne non plus.

Mais par contre, si on lui parle de brevet sur le vivant, je suis sur qu'elle voit plus facilement le danger des brevets quand c'est appliqué n'importe comment.

J'ai connu un mec de droite une fois, et bien il avait 10 fois plus de classe.

#INCLUDE <STDIO.H>

INT MAIN()
{
PRINTF("HELLO, CAPSIZED WORLD!!\N");
RETURN 0;
}


GCC REFUSE DE COMPILER, IL FAUDRAIT PEUT-ÊTRE QUE JE FASSE UN RAPPORT DE BUG.