gabuzo a écrit 236 commentaires

Mouais le modèle de la 'ture est joli mais je ne trouve pas que le rendu mette en valeur les qualité du ray-tracer. Tous les effets de rendu : sol légèrement réfléchissant, vitre légèrement teintées et les ombres coupées au couteau sont réalisables avec un ray-tracer de base. En revanche je trouve que l'image http://www.coala.uniovi.es/~jandro/noname/gallery/others/grzybu_0002.jpg est extrêmement intéressante pour montrer la qualité du rendu.

Sans la fausse naïveté du type qui d'acouvre qu'il ne peut pas partager ses logiciels, l'argument aurait plus de poids.

C'est vrai mais si les arguments économiques passent bien il y a pas mal d'autres choses qui sonnent trop faux. Sans parler des erreurs (Windows acheté en même temps que l'ordinateur malgré tout livré sur CD au prix "retail") et des vrai morceaux de mauvaise foi (les vidéos de vacances sur un PII 266 installé il y a 4 ans) la partie sur Palladium en version neuneu est complètement ratée. On y croit pas mais pire, cette description m'a fait l'effet d'un réveil et si je m'étais (volontairement ?) laissé bercé par la fausse candeur de l'article en arrivant à la description de Palladium je me suis dit p'tain qu'est-ce que tu perds ton temps à lire ce truc.

<blockquote>Java ne pourra jamais etre aussi rapide que C++, il y a plein d'elements dans Java qui font que ca sera logiquement plus lent (classe Object, tout en virtual, garbage collector...)</blockquote> En fait ce n'est pas si vrai que ça. Java peut être plus rapide que C++ et inversement. Le tout dépendant d'une part de la situation et du programmeur. Effectivment Java déclare par défaut les méthodes en virtual mais rien n'interdit de déclarer une méthode final et la JVM pourra alors faire un branchement direct à l'adresse de la méthode plutôt que de passer par une table d'indirection (c'est finalement assez proche des const en C++ qui sont très importants pour permettre au compilo de prendre les meilleurs décision d'optimisation). Le garbage collector est probablement plus lent qu'un système de déallocation explicite comme en C++. Cependant il faut savoir que le GC peut se déclencher lorsque le programme n'a rien à faire alors qu'un delete en C++ consomme de la CPU immédiatement. On peut bien sûr imaginer en C++ un système qui permettrait de faire des delete différés. Ceci-dit le temps CPU utilisé par le GC est fonction du nombre d'objet en mémoire. Un programmeur expérimenté essayera de minimiser le nombre de création d'objets. Sinon le gros avantage de Java sur C++ en terme de perfs est la possibilité pour la JVM d'optimiser le code à l'exécution donc dans un contexte beaucoup plus complet que lors de la compilation. Dans le cas des méthodes et des attributs en final, la JVM pourra décider de les inliner en fonction de leur usage réel et non de supposition à la compilation.

??? t'es en train de nous expliquer que si ms (ou n'importe qui) fait un truc fermé sans spécification, ça communiquera pas facilement avec l'extérieur... tu le sais, je le sais, on le sait tous... mais euh... rapport?

Le rapport ? Si Mono veut être une implémentation libre de .Net, son interopérabilité avec l'implémentation de Microsoft en terme de performance et de compatibilité sera primordiale pour la crédibilité de Mono. Le fait que la spec de .Net appartienne entièrement à Microsoft est déjà un gros problème pour Mono car lorsque de nouvelles version sortiront, la plate-forme de Microsoft implémentera déjà la spec alors que Mono devra l'implémenter. C'est un premier problème. Ensuite comme je le disais dans mon message original si Mono devient un concurrent pour Microsoft (par exemple en permettant à des entreprises d'utiliser des applications .Net sans avoir à remplacer leurs Unix par du Windows) il serait extrêmement facile de désavantager l'implémentation libre par rapport à l'implémentation de Microsoft.

J'ai donc du mal à imaginer que Mono puisse être réellement crédible lorsqu'il faudra une interopérabilité avec .Net.

si c'est mauvais, on l'utilise pas, si c'est bon, ça fait un moyen de plus de développer...

Je n'avais effectivement pas pensé à l'hypothèse dans laquelle Mono ne cherche pas à être nécessairement compatible avec .Net mais à fournir pour les plates-formes Linux/*BSD/Unix un nouveau framework de développement. C'est effectivement intéressant mais dans un article suivant tu précises que certains aspect de .Net sont complètement calqués sur Windows et pose des problèmes d'implémentation sous Linux (les threads par exemple). Lorsque je lis ça je me demande à quel point Mono sera efficace sous Linux et si l'on ne cherche pas la compatibilité avec .Net pourquoi ne pas sortir un framework inspiré de .Net mais qui ne reprenne pas ce qui est clairement trop lié à Windows.

Donc, le seul truc qu'ils peuvent s'amuser à changer, c'est les APIs de .NET. Et ca, à part fatiguer les développeurs, ca risque pas de leur apporter grand chose.

Sans trop faire chier les développeurs il suffit à Microsoft d'ajouter des API qui n'existent pas ailleurs ou de mettre dans les API des trucs très proches de Windows qui seront très difficiles à implementer sur d'autres plates-formes.

Sans jouer sur les APIs il serait très facile à Microsoft de modifier l'implémentation de sa plate-forme .Net pour dégrader les performances lorsqu'elle dialogue avec un système non Microsoft (en utilisant un protocole de communication non-standard par exemple). Ainsi il serait très très facile à un commercial de démontrer la supériorité d'une solution tout Microsoft (vous voyez, il a suffit de remplacer votre serveur Linux par un NT2003 pour que les clients ne rament plus).

D'une certaine manière, c'est une tentative de MS de mettre en place un framework "vraiment" potable. Je doute que leur désir de pouvoir soit fort au point de leur faire saccager leur nouveau bébé.

Bien sûr l'un des but de .Net est de drainer des développeurs (compétents si possible) il ne faut donc pas en faire un poubelle mais l'un des autres but de Microsoft est de vendre les logiciels de la maison (Windows, Visual Studio, etc.). Connaissant le poids du marketting chez Microsoft il est évident que .Net servira de tremplin à la migration de clients de Unix vers Windows. À mon avis perso Mono et toutes les ouvertures de .Net n'ont été autorisées par le marketting que pour éviter de nouveaux procès pour abus de position dominante (c'est probablement la même chose avec media player 9).

Pas nécessairement, le passage de 2.0 à 2.2 c'est fait sans problème et la série des noyaux 2.2 eset rapidement devenue stable. Pour le 2.4 ça a été effectivement la cata. Si on est optimiste on peut penser que les causes des problèmes lors du lancement du noyau 2.4 on été analysées par les développeurs du noyau qui ne les reproduiront pas lors du lancement du 2.6.

Je vais sûrement passer pour naïf mais je ne peux m'empêcher de sourire quand je vois que le coût d'administration d'un système Sun coûte moins chez que sur un système à base de Linux. (je reprends les termes de la comparaison de l'article mais on peut changer par ce qu'on veut).

Attention si j'ai bien compris il s'agit de comparer d'un côté l'administration d'un cluster de machines Linux en cluster de l'autre une seule machine Sun. Dans le cas du cluster il y a plusieurs machines à administrer mais il faut surtout un admin qui connaisse le système de clustering.

Au final donc il faudra probablement un peu plus de temps pour administrer un cluster d'un admin qui sera payé un peu plus (ou qui sera facturé beaucoup plus si c'est un prestataire).

Je n'ai pas lu l'article (biscotte que ras le bol des enregistrements toutes les 5 minutes) mais d'expérience un cluster a toujours été une catastrophe à administer au sein d'une entreprise car cela nécessite des compétences et du personnel que l'on ne trouve généralement pas chez les utilisateurs.

Ça me paraît donc enfoncer les portes ouvertes que de dire que les coûts d'administration d'un cluster (linux, solaris, aix ou autre) ne sont pas négligeables devant le prix d'achat.

C'est vrai ceci-dit j'ai pas mal bossé sur des TX avec CDE (HP/UX et AIX) jusqu'en 2000 et les entreprises étaient alors généralement équipées de réseaux 10Mb/s. Depuis quasiment toutes les boîtes doivent être équipées de réseaux 100Mbs (qui plus est avec des switches au lieu de hub) je doute donc que la surcharge réseau soit réellement significative.

D'un autre côté, pour l'utilisateur (surtout débutant), la mise en place d'un environnement CDE est généralement prise de tête.

Gnome 2.0 est pourtant officiellement distribué par Sun depuis quelques mois.

je voulais plutot parler des fonctionalites fournies par les players. sur une set-top-box, camescope ou autre PDA, le constructeur maitrise le hardware installé, il n'a pas besoin d'un systeme avec pleins de couches plus moins abstraites et generiques concues pour permettre que le player tourne avec n sortes de chipsets graphiques et audio. En ce qui concerne les STB c'est pourtant le cas. Sur les "boîtes" que je connais il y a une première couche d'abstraction matérielle qui permet de faire fabriquer les décodeurs par plusieurs constructeurs. Ensuite on trouve généralement un middleware offrant des API de plus haut niveau pour les applications interactives (guide de programmes, etc.) et le contrôle d'accès. D'ailleurs le consortium DVB a défini MHP (Multimedia Home Platform) pour standardiser les systèmes d'interactivité en télévision numérique. Sans tout lire un ch'tit coup d'oeil sur le dessin en haut de la première page de http://www.dvb.org/documents/white-papers/WP02%20(MHP).pdf permet de voir que ce standard intègre une variante de HTML (DVB-HTML) une machine virtuelle Java et une API Java (DVB-Java).

Nope SACD c'est complètement différent et incompatlble avec le DVD. De mémoire Sony (le leader de SACD) avait annoncé qu'il n'y aurait pas de lecteur de SACD pour ordinateur.

LinDVD existe, et est commercialisé.
Autant pour moi. J'avais fait un rapide tour du site US d'Intervideo et impossible de trouver le moindre LinDVD dans leurs produits. En recherchant sur le site Taïwanais j'ai effectivement réussi à trouver un Tux sur http://www.intervideo.com.tw/products/products_linstb.htm(...) mais mes connaissances en chinois ne me permettent pas de savoir de quoi il s'agit exactement.

Ceci-dit est-ce que c'est une bouse à un tel point qu'Intervideo en ait honte pour n'y consacrer qu'une page en chinois ?

<blockquote>
Quelques gugusses parient actuellement leur chemise sur le fait que les ventes d'appareils de ce type (nomades, embarqués, audiovisuels et communicants) dépasseront en chiffre d'affaire le marché du PC en 2005 (voir linuxdevices.com ). </blockquote>

Est-ce que ce ne serait pas les mêmes gugusses qui voyaient un avenir sans nuages pour les « dot com » il y a quelques années, qui ont prédit un futur radieux pour UMTS ou qui ont misé sur la convergence entre la télévision et internet (voir la pub pour Vizzavi où la ch'tite nana lisait son mail sur sa télévision).

Dire que MPEG-4 est moins pire que WM9 n'est pas évident à tout point de vue. MPEG-4 n'est pas un système libre mais il demeure plus ouvert que WM9. En revanche le consortium MPEG a donné le bâton pour se faire battre en demandant des royalties non seulement pour les encodeurs et les décodeurs mais aussi pour les programmes "à valeur ajoutée" utilisant la norme MPEG-4. Microsoft n'étant pas complètement stupide a donc sorti WM9 en annonçant qu'il accepterait de licencier sa technologie sur des plates-formes non Windows et surtout en proposant des tarifs étant moitié moins cher que ceux de MPEG-4.

Certes le monde de l'audio-visuel est nettement plus proche que MPEG que de Microsoft mais il n'est pas sûr que pour les fournisseurs de contenu audio-visuel (chaînes de télévision, éditeur de DVD) les royalties liées aux programmes encodés soient négligeables. On peut alors imaginer sans trop de difficultés que les directions financières fasse pression pour un standard qui coûté 50% moins cher que l'autre.

Je resterais circonspect vis à vis des annonces d'intervideo. Certains se souviennent peut être qu'au débuts de l'affaire DeCSS, Intervideo avait créé la surprise en annonçant qu'il avait décidé de développer un lecteur de DVD "légal" (c'est à dire payant les royalties au DVD CCA pour la techno CSS) sous Linux quil s'appelerait naturellement LinDVD

Aujourd'hui plus de 3 ans plus tard plus on entend plus parler de LinDVD. Certes il s'agissait probablement d'un produit OEM destiné aux STB (Set Top Box : le fruit des amours contre nature entre un récepteur de télévision numérique et un ordinateur) mais je pense que si un fabricant avait décidé d'employer une solution à base de LinDVD pour un appareil grand public la nouvelle aurait fait grand bruit au sein de la communauté Linux.

Ce n'est pas du tout comparable au problème que pourrait poser la généralisation de domaine en UTF-8.

Si les deux cas que tu cite sont intéressants ils sont cependant facilement résolvables en installant quelque chose sur la machine (d'ailleurs il me paraît normal qu'un OS en version française n'installe pas pas les polices japonaises ni les input methods correspondantes).

En revanche si je me retrouve avec une carte de visite dont l'email est écrite avec des kanji mettre à jour ma machine pour qu'elle supporte la saisie et l'affichage du japonais, du chinois, de l'arabe, de l'elfe et du klingon ne me permettra pas d'envoyer un mail en anglais à mon correspondant.

Dans ce cas il y a bien un risque de rupture d'Internet avec d'un côté ceux qui auraient la chance d'avoir un domaine en ASCII et qui seraient (relativement) facilement accessibles de l'ensemble du réseau et de l'autre ceux qui pour diverses raisons aurait un domaine avec des caractères exotiques et qui seraient très difficilement accessible hors des personnes écrivant leur langue.

<blockquote>
Oui, mais tu peux très bien être français, apprendre le japonais, et avoir un clavier azerty quand même chez toi, non?

Ca n'empeche pas de pouvoir saisir du japonais.
</blockquote>

Comment ? Dans la pratique, tu rencontres quelqu'un au cours de vacances, salon, etc. et il t'écris son adresse email en japonais. À supposer que ton server SMTP, ton DNS et ton client mail supportent UTF-8 comment ferais-tu pour saisir sur ton clavier azerty les idéogrammes de l'adresse ? Même avec les "input-methods" nécessaires je suis persuadé que c'est impossible pour quelqu'un ne parlant ni japonais ni chinois.

<blockquote>C'est vrai, pour l'email c'est un probleme different. Je pense que pour cela les japonais garderont toujours (eventuellement en double-emploi) un nom de domaine en ASCII. </blockquote>

Sachant que pour des raisons de compatibilité avec le reste du monde il semble nécessaire de garder en plus des domaines UTF8 des domaines ASCII quel est l'intérêt au final pour les différents acteurs ? Pour les "propriétaires" de domaines cela demandera d'enregistrer plus de domaines et d'avoir des configurations serveurs plus compliquées pour que plusieurs domaines renvoient sur le même contenu. Les utilisateurs risquent de se retrouver dans des situations où il leur sera impossible de donner par écrit une adresse mail ou l'URL d'un site si quelqu'un a oublié d'enregistré le nom en ASCII. Les seuls gagnants sont finalement les registars.

Certes les langues latines ne sont pas les seules au monde il est nettement plus facile d'entrer une chaîne en caractères latin sur un OS localisé en chinois, japonais, arabe que l'inverse. En outre les "non latin" sont probablement plus habitués à utiliser (lire et écrire) des caractères latin que l'inverse (de même qu'il est plus facile de dire à un français de ne pas utiliser d'accent que de demander à un anglophone d'en utiliser).

Pour information allez jeter un coup d'oeil aux pages suivantes :
http://www.yahoo.co.jp/(...)
http://tw.yahoo.com/(...)
http://cn.yahoo.com/(...)

Enfin techniquement lorsque l'on voit à la vitesse où sont installés les patches de sécurité on imagine qu'il va se passer des années avant que ces nouvelles URL soient utilisable par un nombre significatif d'internautes.

Si je ne me trompe pas, MaraDNS, bien que ne supportant pas des interfaces avec des bases de données mais il est probablement plus sûr que bind et fonctionne en primaire, secondaire et cache.

http://www.maradns.org/(...)

Delegate est un programme très intéressant mais en voulant l'installer sur une machine FreeBSD à partir de ports on trouve un message décourageant son installation et suggérant de se reporter à un rapport de sécurité pour plus de détails. En regardant plus précisément le rapport en question (dispo sur ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-00%3A04.delegate.asc) on apprend que « [delegate] est écrit dans un style très peu sûr et qu'il contient potentiellement des douzaines de buffer overflows (dont certains ont été mis en évidence) permettant à un attaquant d'executer du code sur le serveur de delegate ». En outre au chapitre solution on trouve : « Il n'existe malheureusement aucun correctif simple --- les problèmes de delegate sont trop endémiques pour pouvoir être résolus avec un simple patch. Le rapport date de 2000 il y a peut être eu des évolutions depuis mais cela n'incite par à utiliser ce programme.

Autant Times New Roman ou Arial sont moches, autant Verdana offre une très bonne lisibilité (surtout dans les petites tailles).

C'est un peu normal. Arial et Times sont d'anciennes adaptations de polices dessinées pour le plomb d'un autre côté les polices telles que Verdana, Georgia, Trebuchet ou Andale mono ont été créées spécifiquement pour l'écran. C'est probablement parce qu'elle ont été conçue pour l'écran que le rendu papier de Georgia et Verdana est assez moyen (Trebuchet et Andale s'en sortent un peu mieux).

Outre leur lisibilité sur l'écran les polices en question couvrent l'ensemble des caractères européens ainsi que le cyrilique et le grec. Ce qui est un avantage non négligeable lorsque l'on sait qu'il est quelque fois difficile de trouver une police gratuite de qualité permettant d'écrire le français.

Enfin pour rassurer les utilisateurs de ces polices : elles ont été créées par Monotype (une fonderie centenaire) et non pas Microsoft.

De la même façon qu'un lecteur CD se calle en 1x lorsque l'on lit un cd audio, un lecteur DVD se cale en 1x lors de la lecture d'un fichier vidéo. Inutile donc de chercher à le ralentir, il est déjà au ralenti

Pas si sûr. Il y a enormément de différence entre un CD Audio et un CD Rom : le mode d'enregistrement est différent (taille de secteur, codes de correction d'erreur, etc.) et il n'y a pas à proprement parler de système de fichier sur un CD Audio.

En revanche un DVD Vidéo est un bête DVD Rom avec un système de fichier spécifique (UDF) et une arboresence particulière. J'ai l'impression que la seule grosse différence est la possibilité d'utiliser CSS sur un DVD Vidéo.

Enfin s'il y a un intérêt à se caler sur un débit constant lors de la lecture d'un CD Audio (car le son n'étant pas compressé le débit reste constant tout au long du disque), c'est totalement différent avec un DVD Vidéo le débit de la vidéo pouvant varier de moins de 1Mbit à 10 Mbits au cours d'une lecture.

Tu as effectivement paramétré le cryptage des données (reste à savoir si c'est fiable ou non) mais il est à parier qu'avec le développement des WiFi, il y aura de nombreux réseaux non protégés par incompétence ou manque de temps de l'administrateur. Il y a eu il doit y avoir un an une expérience faire dans la City à Londres qui consistait à faire un tour en voiture et regarder ce que l'on arrivait à capter. Au final de nombreux réseaux n'étaient pas protégés.

On imagine la zone qu'un pirate pourrait y mettre surtout si le réseau est considéré comme de l'intranet d'un point de vue sécurité et permet d'accéder au réseau filaire de l'entreprise sans firewall à passer.

Je ne sais pas mais dans le dernier (ou avant dernier) numéro de Courrier International il y a un dossiers sur l'exploration de Mars et parmi les articles il y en a un qui parle du marasme financier de la Nasa qui l'oblige à faire du sensationnel et de l'absence de réelle découverte qui l'oblige à faire du réchauffé (la nième découverte d'eau sur Mars).

Bref à la leur de cet article (et d'autres parlent de la situation financière de l'institution) je ne peux pas m'empêcher d'être relativement d'accord avec toi et de penser que la Nasa fait monter la sauce médiatique histoire d'avoir des sous (terminer la station spaciale pour pouvoir s'en servir pour lancer les chats et les tartines).