loufoque a écrit 71 commentaires

sharpfonts.com et ça va de suite beaucoup mieux...

Le serveur (sans le contenu "artistique") du MMORPG planeshift est par exemple libre et distribué.

L'AFNOR de toutes façons, c'est plus une blague qu'autre chose.

Le fait que VLC ne gère pas correctement les sous-titres (en particulier le format SSA/ASS, avec placements, effets, couleurs, polices embarquées...) est la raison pour laquelle je ne l'utilise pas.
MPlayer, lui, fonctionne parfaitement depuis un an ou quelque chose comme ça.

Je vois pas trop en quoi ça consiste personnellement.
- Les informaticiens théoriques ils font pas de logiciel,
- Les informaticiens appliqués ils font déjà du logiciel libre, puisque c'est la vitrine de leur travail,
- Les physiciens leur code est moche de toutes façons, on en veut pas.

Pour avoir la 3D sous un Windows virtualisé, c'est facile, il suffit de donner un accès direct à la carte graphique à l'OS invité.
Ce qui peut se faire avec le VT-d d'Intel, par exemple.

La critique de l'IPhone dit qu'il faut l'éviter et prendre un Freerunner un moment.
Mais bon il faut être honnête, le Freerunner, c'est "bof", au mieux.

Un IPhone jailbreaké, c'est cent fois mieux en termes de fonctionnalités...

Les hebergeurs sont responsables légalement des infractions commises sur leur serveur.
Donc ça revient au même, elles sont dans l'obligation de vérifier et de censurer de manière préventive pour s'éviter les ennuis.

La riposte graduée, finalement, c'est la même chose que la LEN, sauf que la LEN s'applique aux hebergeurs de serveurs et la ripostée graduée aux fournisseurs d'accès à Internet.

Tant que se battre contre la riposte graduée, pourquoi ne pas aussi en profiter pour remettre en question cette loi qui oblige les herbergeurs à censurer massivement le net par prévention ?

Il y a-t-il du matériel, avec pilote propriétaire ou non, qui fonctionne réellement en 802.11n sous linux actuellement ?

Savoir que les logiciels des avions sont faits avec des horreurs comme des diagrammes UML et de l'objet à outrance ça me rassure pas vraiment, personnellement...

Ça n'a rien à voir.
Avec des mutexes read/write ou avec rcu, tu peux exécuter du code par plusieurs threads en même temps et pourtant le verrou doit bien être libéré par celui qui l'a acquis.

Y'a plus de gens qui veulent un appareil photo qu'un support 3G/3G+ ?
Les gens sont bêtes dis donc.

Les technologies 10 Gigabit existent et sont éprouvées, et le HDMI lui-même ne permet que 3 Gb/s.
De plus encoder à la volée en mpeg2 voire en h264 ne pose pas un si gros problème que ça.

Une télévision n'est rien de plus qu'un grand écran d'ordinateur de mauvaise qualité avec un switch pour avoir plusieurs entrées, des convertisseurs analogique -> numérique, un redimensionneur et décodeur vidéo logiciel ou matériel (de moins bonne qualité que ceux des cartes graphiques lambdas), et une télécommande infrarouge pour contrôler le switch.
Ce genre d'équipement est avantageusement remplacé par un PC basse consommation associé à un écran.

Le gros problème, c'est que les chaînes ne sont pas diffusés dans un format pratique pour être utilisées par un ordinateur. L'idéal serait de tout diffuser sur IP, via le protocole rtsp par exemple, mais en pratique ce n'est pas fait.

Free le fait un peu, mais uniquement des versions dégradées et c'est limité à certaines chaînes. De plus, en fait, à ce que j'en sais, il ne s'agit que d'un serveur que met en fait en place la freebox hd pour relayer les données qu'elle reçoit de la freebox adsl.
TF1 et M6 ont aussi montré leur réticence à être diffusés via rtsp, ce qui est une totale aberration, mais bon la loi n'empêche pas ce genre de pratique, pourtant nécessaire à l'interopérabilité.

Pour regarder la télé sur un ordi, on est actuellement obligé de passer par un boîtier propriétaire, et de ré-acquérir les sorties de ce boîtier (ce qui nécessite d'avoir un équipement graphique et sonore particulier) pour pouvoir les retransmettre sur un ordinateur ou sur le réseau, et réaliser les changements de chaînes sur le boîtier.
Ce qui est plutôt une aberration avec des choses comme les box, quand on sait que ça passe par Internet de toutes façons et que l'ordinateur en question peut bien plus facilement utiliser des technologies et des standards universels pour se connecter au réseau local.

Autre problème : il n'existe aucune technologie de qualité permettant de connecter un ordinateur à un écran à distance, ce qui serait pourtant fort pratique pour pouvoir brancher son ordinateur portable (qui n'a généralement pas de sortie DVI et encore moins S/PDIF) sur sa télé via ethernet ou wifi.
En fait, plutôt que de faire des nouveaux standards stupides comme HDMI, l'audiovisuel ferait mieux de travailler à la transmission via IP pour réutiliser les réseaux et les standards. Quand on voit qu'on vend maintenant des switchs HDMI, on se demande vraiment quel est l'intérêt par rapport à des switchs ethernet...

Avec un compte FON et un aircrack qui cracke tous les WEPs à proximité, le wifi doit être disponible presque partout.
Si on rajoute à ça la connectivité à certains hotspots (neuf, orange...) on doit bien s'en tirer quand même.

Je suppose que déjà le système de parallélisation automatique du x86 doit prendre une certaine place sur la puce...
Si on l'enlevait et qu'on passait à du VLIW on devrait gagner une place non négligeable. Mais bon, Intel a essayé (Itanium), et le marché n'a pas suivi.

Le problème finalement, c'est surtout le support logiciel. Les cartes graphiques sont essentiellement utilisées par les pilotes pour les jeux fournis par leurs constructeurs, donc ce n'est pas vraiment problématique si leur assembleur est tellement complexe que seul le constructeur sait l'exploiter. Ce qui compte, c'est la performance.
Surtout qu'il n'y a pas de problème de compatibilité, puisque ça passe par une couche d'abstraction (OpenGL, DirectX...)

Les CPUs font face à un tout autre problème. Il y a à la fois le problème de compatibilité et celui de la simplicité. Les divers OS, compilateurs, etc. doivent être à même d'exploiter le matériel sans dépenser des milliers en recherche dessus, et les utilisateurs veulent que le travail qu'ils ont effectués jusqu'à présent fonctionne.
Pour toutes ces raisons, malheureusement, on ne peut pas se débarasser de x86 si facilement pour le remplacer par un jeu d'instruction mieux fait et qui permettrait de gagner des performances non négligeables. C'est triste quand on voit que les GPU peuvent tout se permettre puisqu'ils n'ont pas à conserver la moindre usabilité ou compatibilité avec quiconque, ce qui leur permet d'évoluer et de s'améliorer beaucoup plus.

Idéalement, on pourrait se dire qu'un GPU devrait fusionner avec le CPU pour devenir son unité de calcul vectoriel. Sauf que pour les raisons citées ci-dessus, le GPU a bien plus de potentiel, donc ce n'est pas réellement envisageable.
Le seul moyen pour que ce le soit, ce serait que le constructeur maintienne une implémentation libre d'une abstraction. Un peu comme ce que fait nvidia avec CUDA, qui permet justement d'utiliser un GPU comme un CPU limité.

(Désolé si je me répète un peu, il est tard)

C'est aussi le nom d'un fruit ! Quel plagiat !

C'est un peu comme Coda etc. en fait finalement.

J'ai du mal à comprendre ce qu'est cette chose.
C'est pas tout simplement un client X (ou NX) en Java ? Pourquoi y'a une image ISO de distribution etc. ?

La malfaisance, c'est relatif.

Lua et OCaml n'ont rien à voir.
Si tu dois penser que tous les langages qui ont les fonctions en tant que first-class citicizens sont similaire à OCaml, alors 95% des langages de programmation le sont.

Une différence fondamentale entre Lua et OCaml c'est que déjà Lua est typé avec du duck-typing, alors que OCaml c'est du typage statique avec inférence et polymorphisme paramétrique.

http://en.wikipedia.org/wiki/Structural_type_system

Ah oui et bien sûr, si tu ne peux pas comparer tes éléments, tu auras une erreur à la compilation et non à l'exécution, bien évidemment.

Je ne sais réellement pas d'où tu sors tout ce tas de choses fausses sur C++.

En C++, on généralise les fonctions aux foncteurs, c'est à dire tout type qui peut s'appeler tel une fonction (donc éventuellement une classe avec un operator() surchargé).
C'est comme ça qu'on fait des closures etc.

boost::lambda (et autres du même genre) génère automatiquement un foncteur à partir d'une expression lambda.

Et en C++0x y'a une syntaxe spéciale pour exprimer les fonctions lambda.

Donc franchement, je ne vois pas pourquoi tu parles de pointeurCradeSurFonctionDeComparaisonMaisAvecUnLangagePourriCommeC++TasPasLeChoix. D'autant plus que la fonction utilisera par défaut operator==, donc il s'agira d'un argument optionnel.

Et je vois pas non plus pourquoi tu mets des & et * ? C'est n'importe quoi. Et cette définition de result vide alors que tu le redéfinis après, c'est tout simplement sous-optimal et stupide.

Je pense qu'intersection devrait être une fonction libre : il ne s'agit nullement d'une propriété propre à ta liste.
Accessoirement elle devrait écrire sa sortie sur un itérateur pour pouvoir mieux être exploitée.
Bref, un design à la std::set_intersection, mais sans tri. (ça va faire un bel algo en O(n*m) tout pourri)

Quand on voit que les gens qui critiquent le C++ ne savent même pas des trucs basiques comme ça, ça fait peur.