Effectivement c'est pas si novateur car de nombreux projets industriels visant la production de carburant à partir d'algues sont déjà lancés ou sur le point de l'être.
Ce site rescense les actus de projets ayant pour but de tirer de l'énergie de la mer, à savoir éoliennes off shore, "éoliennes" sous marines mais également la production de carburant à partir d'algues.
Pas besoin d'une source de CO² d'ailleurs (même si ça permet d'augmenter le rendement). De l'eau et du soleil suffisent pour cultiver des algues avec de bien meilleurs rendements pour la production d'huile que la culture de végétaux terrestres.
Une technologie d'avenir assurément. Quand à savoir si ça va résoudre tous nos problèmes énergétiques, ça reste à voir.
Aucune idée pour la Laguna. Ceci dit j'ai déjà vu des specs où la différence entre la boite manuelle et automatique (de quel type?) était de quelques dixièmes de littres pour un cycle urbain (au lieu de la grosse différence de 2L pour la Laguna).
Je me souviens plus quelles étaient les voitures en question mais c'était des modèles récents. J'imagine qu'un petit tour sur les sites internet de quelques constructeurs suffirait pour trouver les chiffres.
Comme le dit le commentaire précédent le tiens, ces données constructeurs correspondent à une mesure effectuée dans des conditions particulières avec une conduite adaptée pour consommer le moins possible. Généralement la consommation réelle constatée par les utilisateurs est supérieure aux chiffres annoncés (la consommation pouvant varier énormément en fonction du type de conduite et du type de trajets effectués).
Finalement le seul vrai intérêt de ces chiffres est de comparer plusieurs voitures, vu que les conditions de mesure sont sensées être les mêmes.
Dans ces conditions "optimale" une boite auto consomme un peu plus. Sauf que un conducteur lambda muni d'une boite manuelle ne va pas forcément connaître suffisamment bien le moteur pour savoir passer les vitesses au moment optimal pour la consommation, alors qu'une boite auto si.
Dans ces conditions je ne serai pas surpris qu'en situations réelles une boite auto consomme statistiquement moins qu'une boite manuelle.
VirtualBox, sous licence GPL, est aussi efficace que Vmware et je trouve plus simple, au moins pour une utilisation basique (il y a une GUI plutôt bien faite). Bon après mes besoins sont assez basiques et je sais pas ce que vaut VirtualBox pour gérer une trentaire de machines.
D'autant plus que d'autres progrès sont à l'horizon dans ce domaine. En particulier sur le rendement énergétique. Il est à la louche autour de 10% pour le panneau de base commercialisé; bref pas terrible. Mais il existe des prototypes qui ont un rendement atteignant 40% et certains espèrent pouvoir dépasser 50%.
Évidemment le passage du prototype au produit commercialisable n'est pas évident et rapide, mais on peut tout de même penser que les panneaux solaires vont devenir de plus en plus intéressants à moyen terme.
La procédure d'obtention du certificat n'est certe pas satisfaisante. Disons que c'est un premier pas. Il est fort possible que cela évolue (via la future carte d'identité électronique?)
D'autre part même en l'état la signature permet au moins d'être certain que ta déclaration va pas être modifiée après coup.
Si tu es connecté en SSL, tu reçois les pages web (des formulaires tout ce qu'il y a de plus classique) sur une connexion sûre. Tu es également certain qu'ils n'ont pas été modifiés.
Non! Il y a juste authentification mutuelle puis chiffrement du canal de communication. Rien ne te garantie que personne n'a réussi à modifier le site en douce. La page en elle même qui t'es envoyée n'est pas signée.
Franchement, si tu envoies des données (là encore via des formulaires web classiques) sur une connexion authentifiée, c'est que bien toi qui est à l'autre bout. Signer la déclaration ou envoyer la déclaration sur un canal authentifié, je vois la différence théorique, mais en pratique le résultat est le même : tu as la garantie que c'est bien toi (au sens de toi = le possesseur de la clef privée) qui a fait la déclaration. Le fait de considérer la "déclaration" comme un document unique, signé une fois, ou comme la procédure qui consiste à "déclarer" (envoyer petit à petit) les différents élément, sur un canal authentifier, ce sont deux points de vue équivalents, AMHA.
L'authentification est une procédure interactive qui ne peut être vérifiée après coup. La signature elle peut être vérifiée plus tard par n'importe qui a connaissance de la clé publique ad hoc. Elle ne peut être répudiée sauf si tu prouve que tu t'es fait volé ta clé privée. Elle a une valeur juridique. Cette signature est une preuve que tu as fait ta déclaration. Une authentification mutuelle + chiffrement ne permet pas cela.
Authentification et signature (de document) numérique sont deux actions très différentes même si elles utilisent des outils similaires.
Pour moi, c'est au serveur de générer ce pdf et de le signer, garantissant ainsi son authenticité. Certes, ça rajoute de la charge serveur.
Le PDF contient essentiellement ta signature et constitue donc une preuve. Je ne voit pas pourquoi ça serait au serveur de la fournir et encore moins pourquoi il devrait le signer. C'est toi qui certifie l'exactitude des infos (et donc signe), pas le serveur.
Simplement s'il y a moyen de faire plus simple, autant faire plus simple. Pourquoi ne pas se passer de l'applet. Tous les navigateurs qui la supporte supportent aussi l'authentification SSL mutuelle, non ?
En quoi la solution java est-elle complexe? Tu as juste besoin du plugin Java sous ton navigateur. Et OpenSSL tout seul c'est bien pour l'authentification mais à mon avis une signature numérique est indispensable, ce qui suppose des développements supplémentaires. On pourrait imaginer une extension Firefox, mais du coup ça fonctionnerait pas sous IE (pas grave), ni sous Konqueror, Opera, etc.
Pour moi la solution de l'applet Java me semble encore la meilleure solution.
MrLapinot propose d'installer Openssl, qui est certes portable mais qu'il faut tout de même installer et intégrer au navigateur. Je crois qu'il serait bon qu'il se renseigne lui-même un peu sur le fonctionnement de cette applet :)
Bien sûr que le protocole ssl permet l'authentification mutuelle. Mais la gestion des certificats clients au niveau des navigateurs n'est pas facile à gérer. D'autre part l'applet Java ne sert pas qu'à ça:
- le formulaire fait partie intégrante de l'applet et l'applet est signée donc tu es certain que l'appli n'a pas été modifiée par des tiers
- elle sert à signer numériquement ta déclaration et non ssl c'est pas fait pour ça! Je sais que certains protocoles d'authentification peuvent faire usage de schémas de signature, mais c'est pas ce "type" de signature qu'on veut.
- elle génère un pdf de ta signature
Bref la signature n'est qu'une des fonctionnalités de cette applet.
De plus avec l'applet, rien à installer côté client. Ca fonctionne quel que soit le navigateur et l'OS (à quelques exceptions près). C'est quoi le plus simple? Il y en a qui ont peut-être des soucis avec cette applet mais ces problèmes seront certainement prochainement corrigés. Pour ma part ça a fonctionné comme un charme (façon de parler quand on parle d'impôts!).
Le seul truc critiquable c'est la manière dont on te fournit le certificat puisqu'il suffit d'avoir accès à la feuille de déclaration de l'année précédente pour avoir toutes les données nécessaires. Mais l'utilisation d'OpenSSL n'y changerait rien!
Oh, et un "couple de certificats (publique/privé)" n'a aucun sens. Un certificat est par définition publique, et contient une clé publique. La clé privée correspondante n'en fait pas partie.
Il faudrait plus qu'un simple formulaire. L'idée ici n'est pas seulement d'assurer la confidentialité (faisable avec du https basique), mais surtout de signer ta déclaration, ce qui implique que tu disposes de ton côté d'un certificat ad hoc (fournit par l'administration) et de sa clé privée associée.
L'applet java (elle-même signée pour éviter l'exécution de code frauduleux) sert à remplir ta déclaration, mais se charge également de la signer numériquement.
Le choix de Java me semble pertinent. En plus c'est multiplateforme même s'il reste quelques soucis comme l'indique ce journal.
Il y a un point qui n'est pas abordé par ce journal, c'est l'accélération 3D.
Toutes les solutions actuelles permettent d'émuler une machine/OS presque parfaitement mais pour avoir une accélération 3D c'est plus compliqué.
Certes pour les aspects serveurs, on s'en fout mais un utilisateur donné pourrait trouver pleins d'avantages à bénéficier d'accélération graphique dans une machine virtuelle (entre autre pour jouer à des jeux réberbatifs à wine sous un Windows émulé).
VMware semble proposer un support expérimental de DirectX. J'ignore si c'est utilisable.
Dans ce journal je vous invite plus particulièrement à regarder le message de Jux introduisant le projet VMGL qui semble apporter une solution intéressante en permettant une accélération OpenGL (pour le moment limité à du Linux).
Chouette, un début de troll sur la vitesse de Java!
Bon, alors déjà gcj c'est peut-être bien mais côté vitesse, la dernière fois que j'ai essayé c'était beaucoup plus lent que la JVM de SUN.
Cette dernière d'ailleurs, une fois "chauffée" se montre étonnament véloce. Sur du bout de code C transcrit en Java, j'avais une perte de moins de 10% sur les perfs avec la version Java.
Bon, par contre j'avais pas trop regardé toutes les optimisations de compilation de gcc et m'étais contenté d'un -O2 (aucune amélioration avec -O3).
Dans son état actuel GCJ permet éventuellement d'améliorer la vitesse de démarrage et l'empreinte mémoire. Et encore c'est même pas sûr qu'il y arrive de manière vraiment significative.
Ouais, même avec les meilleurs programmeurs au monde je doute qu'une carte intégrée Intel (en l'occurence une Q965) soit capable de battre une carte ATI ou nVidia récente, qui sur le papier sont sensées être largement plus performantes. Essaye de voir sous Windows si tu peux jouer aux jeux derniers cri, options à fond, avec une carte Intel. On va rigoler...
Pour la rapidité des drivers libres il faudra voir quand les drivers ATI seront plus avancés. Et puis je doute que les drivers libres incluront des optimisations spécifiques à tel et tel jeux comme cela semble être le cas avec les drivers propriétaires.
Enfin la plupart des gens ne jouent pas à des jeux derniers cri (de toute façon sous Linux c'est pas facile) et même une carte Intel est très largement suffisante pour faire tourner à fond compiz, googleearth ou Celestia.
Ce qui ne veut pas dire que je sois contre des drivers performants pour les cartes ATI et nVidia.
"While we are grateful that your company provides one of the best closed-source graphics drivers for Linux, it is not without its problems and prevents many users from having a truly free software platform. You have shown an open-source passion in the past when dropping the nforce-net binary blob in favor of the community-spawned forcedeth driver for Ethernet support on your motherboard chipsets. There has been a rumor that you may be developing an open-source strategy for your graphics products, so if that is the case please let us know your true intentions. Even if you were only able to open a subset of your Linux driver, this still would show a sign of solidarity to the free software world.
We stand united under the name OpenTheBlob.com, but realize that legally it may be next to impossible to open-source the binary portion of your graphics driver due to patents and preserving some intellectual property in this competitive market. What we are, however, asking you for is to support the open-source community to the fullest extent possible. The open-source "nv" driver that you provide for X is an abhorrent disaster that is limited to 2D acceleration and doesn't come without its share of limitations and shrouded code. We look to NVIDIA for providing concise programming documentation to willing open-source developers that is not encumbered by Non-Disclosure Agreements or other legal restrictions.
"
En gros ils sont d'accord avec toi que c'est une bonne chose que NVidia propose un driver performant sous Linux.
Ce que les développeurs veulent d'ailleurs c'est pas une libération des drivers mais l'ouverture des spécifications nécessaires pour développer un driver libre. C'est pas pareil. Enfin si les gars de NVidia peuvent participer c'est tant mieux.
Après ça NVidia pourra continuer, tout comme ATI/AMD, de développer des drivers fermés. On veut juste les specs! Y a pas d'imposition de licence ici. Au contraire publier les specs serait une forme de respect des clients qui pourront espérer utiliser du matériel NVidia comme ils l'entendent, y compris sur des architectures exotiques non supportées actuellement.
D'après un des articles sont j'ai laissé le lien plus haut, ça serait une mauvaise idée de tenter de mixer les deux technos. Elles sont trop différentes et les gains obtenus en tentant tout de même de les mélanger peu intéressants.
Aucune idée. Mais il semblerait que les GPU actuels soient pas trop adaptés aux type de calcul demandés ici. Mais je me trompe peut-être.
D'ailleurs la question serait plutôt: est-ce que nVidia va laisser faire?
ATI maintenant c'est AMD, donc ils sont bien placés pour aller dans les deux directions. Et Intel (qui fait également beaucoup de chipsets graphiques) a tout intérêt à promouvoir cela pour valoriser ses processeurs multi-CPU.
D'après ce que j'ai compris (je précise que je suis pas spécialiste):
Le raytracing ça permet de faire des choses plus réalistes sans se prendre la tête. Par exemple gérer les ombres est simplissime alors qu'en "rasterisation" (OpenGL/Direct3D) c'est beaucoup moins trivial.
D'autre part le calcul peut être hautement parallélisable puisqu'on dessine pixel par pixel. En gros doubler le nombre de coeur d'un processeur permet d'effectivement (presque) doubler les perfs. La techno peut donc tirer partie de l'évolution actuelle des procs. Intel semble d'ailleurs promouvoir cette techno...
Enfin, pour les résolutions PC standard, la quantité de calcul est plus importante qu'en OpenGL/Direct3D. Mais la durée de calcul augmente beaucoup moins vite qu'en rasterisation avec la complexité de la scène. Ce qui signifie qu'une fois qu'on sera capable de rendre en temps réel un jeux avec une résolution correcte, on sera rapidement à même d'avoir des scènes beaucoup plus complexes que celles actuellement possibles avec les techniques actuels.
Voilà voilà. Le raytracing c'est (peut-être) l'avenir du jeux vidéo.
En plus ça utilise des processeurs généralistes donc pas de problème de drivers! Bon, d'ici que ce soit utilisable...
J'ajouterai qu'en théorie la dynamique du CD est supérieure à celle du microsillon. Malheureusement, comme déjà souligné plus haut, cette supériorité technique est gachée par des ingénieurs du son incompétents... Du coup la version microsillon peut apparaître comme supérieure car du fait de sa dynamique moindre, si on appliquait la même dégradation que pour le CD ça serait quasiment inaudible. Du coup en pratique le microsillon peut sembler avoir une plus grande dynamique...
J'ai pour habitude de discuter calmement et constructivement le reste du temps, mais je ne peux pas rester poli avec quelqu'un qui a un tel manque de respect pour la logique et l'objectivite technique qui caracterise les discussions sur une spec technique.
Je sais pas moi, achète toi un sac de sable et défoule toi dessus...
Pour l'impression des 6000 pages, je crois que tu n'as pas compris mon propos. Tu reproches à Albert de ne pas avoir imprimé toute la doc alors que dans ses message précédents, tout ce qu'il indique chercher c'est la définition de WordJeSaisPlusQuoi95.
Toi quand tu recherches juste une petite info précise dans un gros doc tu l'imprimes forcément en entier?! La nature ne te dit pas merci!
Pour ce qui de la longueur de cette norme, oui elle est longue. C'est un problème pour une précédure de Fastrack, car un tel pavé demanderait plus de temps pour être correctement relu. Qui plus est ça fait franchement tentative de passage en force de la part de MS surtout si on compare à l'ODF, standardisé à l'OASIS, qui a suivi la procédure normale.
L'un des avantages de l'ODF est de réutiliser antant que possible des standards existants. Évidemment si tu cumules les spécifs de l'ODF avec celles des autres standards utilisés, tu ne dois pas être loin de la longueur de l'OOXML. Cependant ces différents standards ont déjà été étudiés et évalués/implémentés à part, alors que pour l'OOXML il faut évaluer ces parties à partir de zéro. Encore une fois pour une procédure fasttrack ce n'est pas sain.
Je ne suis en soi pas opposé à une standardisation de l'OOXML mais certainement pas en l'état: vu les problèmes techniques dénoncés et les réactions sucitées de part et d'autre, le minimum serait de revenir à une standardisation par la voie normale, histoire que l'ISO s'approprie réellement le format et apporte les corrections nécessaires au texte.
# profil couleur
Posté par ndesmoul . En réponse au message photo: rendu de dcraw et gqview. Évalué à 2.
Pour plus d'infos tu peux commencer par consulter cette page.
http://ufraw.sourceforge.net/Colors.html
[^] # Re: Sympa
Posté par ndesmoul . En réponse au journal La solution à la pénurie de pétrole.. Évalué à 2.
cf. le site "Les énergies de la mer": http://feeds.feedburner.com/LesEnergiesDeLaMer
Ce site rescense les actus de projets ayant pour but de tirer de l'énergie de la mer, à savoir éoliennes off shore, "éoliennes" sous marines mais également la production de carburant à partir d'algues.
Pas besoin d'une source de CO² d'ailleurs (même si ça permet d'augmenter le rendement). De l'eau et du soleil suffisent pour cultiver des algues avec de bien meilleurs rendements pour la production d'huile que la culture de végétaux terrestres.
Une technologie d'avenir assurément. Quand à savoir si ça va résoudre tous nos problèmes énergétiques, ça reste à voir.
[^] # Re: Encore une victoire de manchot !
Posté par ndesmoul . En réponse au journal Darty condamné pour vente subordonée. Évalué à 3.
http://www.pcinpact.com/actu/news/44394-vente-liee-UFC-Darty(...)
[^] # Re: Hum...
Posté par ndesmoul . En réponse au journal Darty condamné pour vente subordonée. Évalué à 8.
[^] # Re: Bof
Posté par ndesmoul . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 2.
https://linuxfr.org/~MrLapinot/26625.html#931463
[^] # Re: Mon expérience personnelle diffère
Posté par ndesmoul . En réponse au journal Windows vs Linux : Un schéma très schématique ?. Évalué à 2.
Je me souviens plus quelles étaient les voitures en question mais c'était des modèles récents. J'imagine qu'un petit tour sur les sites internet de quelques constructeurs suffirait pour trouver les chiffres.
[^] # Re: Mon expérience personnelle diffère
Posté par ndesmoul . En réponse au journal Windows vs Linux : Un schéma très schématique ?. Évalué à 2.
Finalement le seul vrai intérêt de ces chiffres est de comparer plusieurs voitures, vu que les conditions de mesure sont sensées être les mêmes.
Dans ces conditions "optimale" une boite auto consomme un peu plus. Sauf que un conducteur lambda muni d'une boite manuelle ne va pas forcément connaître suffisamment bien le moteur pour savoir passer les vitesses au moment optimal pour la consommation, alors qu'une boite auto si.
Dans ces conditions je ne serai pas surpris qu'en situations réelles une boite auto consomme statistiquement moins qu'une boite manuelle.
[^] # Re: Idem pour Open Source vs Propriétaire
Posté par ndesmoul . En réponse au journal Windows vs Linux : Un schéma très schématique ?. Évalué à 4.
[^] # Re: PowerPC
Posté par ndesmoul . En réponse à la dépêche La course au pétaflops se déroule sous Linux. Évalué à 4.
Évidemment le passage du prototype au produit commercialisable n'est pas évident et rapide, mais on peut tout de même penser que les panneaux solaires vont devenir de plus en plus intéressants à moyen terme.
[^] # Re: Justement
Posté par ndesmoul . En réponse au journal SSL : impôts et EEE PC (en vrac). Évalué à 2.
D'autre part même en l'état la signature permet au moins d'être certain que ta déclaration va pas être modifiée après coup.
[^] # Re: Justement
Posté par ndesmoul . En réponse au journal SSL : impôts et EEE PC (en vrac). Évalué à 3.
Non! Il y a juste authentification mutuelle puis chiffrement du canal de communication. Rien ne te garantie que personne n'a réussi à modifier le site en douce. La page en elle même qui t'es envoyée n'est pas signée.
Franchement, si tu envoies des données (là encore via des formulaires web classiques) sur une connexion authentifiée, c'est que bien toi qui est à l'autre bout. Signer la déclaration ou envoyer la déclaration sur un canal authentifié, je vois la différence théorique, mais en pratique le résultat est le même : tu as la garantie que c'est bien toi (au sens de toi = le possesseur de la clef privée) qui a fait la déclaration. Le fait de considérer la "déclaration" comme un document unique, signé une fois, ou comme la procédure qui consiste à "déclarer" (envoyer petit à petit) les différents élément, sur un canal authentifier, ce sont deux points de vue équivalents, AMHA.
L'authentification est une procédure interactive qui ne peut être vérifiée après coup. La signature elle peut être vérifiée plus tard par n'importe qui a connaissance de la clé publique ad hoc. Elle ne peut être répudiée sauf si tu prouve que tu t'es fait volé ta clé privée. Elle a une valeur juridique. Cette signature est une preuve que tu as fait ta déclaration. Une authentification mutuelle + chiffrement ne permet pas cela.
Authentification et signature (de document) numérique sont deux actions très différentes même si elles utilisent des outils similaires.
Pour moi, c'est au serveur de générer ce pdf et de le signer, garantissant ainsi son authenticité. Certes, ça rajoute de la charge serveur.
Le PDF contient essentiellement ta signature et constitue donc une preuve. Je ne voit pas pourquoi ça serait au serveur de la fournir et encore moins pourquoi il devrait le signer. C'est toi qui certifie l'exactitude des infos (et donc signe), pas le serveur.
Simplement s'il y a moyen de faire plus simple, autant faire plus simple. Pourquoi ne pas se passer de l'applet. Tous les navigateurs qui la supporte supportent aussi l'authentification SSL mutuelle, non ?
En quoi la solution java est-elle complexe? Tu as juste besoin du plugin Java sous ton navigateur. Et OpenSSL tout seul c'est bien pour l'authentification mais à mon avis une signature numérique est indispensable, ce qui suppose des développements supplémentaires. On pourrait imaginer une extension Firefox, mais du coup ça fonctionnerait pas sous IE (pas grave), ni sous Konqueror, Opera, etc.
Pour moi la solution de l'applet Java me semble encore la meilleure solution.
[^] # Re: Justement
Posté par ndesmoul . En réponse au journal SSL : impôts et EEE PC (en vrac). Évalué à 6.
MrLapinot propose d'installer Openssl, qui est certes portable mais qu'il faut tout de même installer et intégrer au navigateur. Je crois qu'il serait bon qu'il se renseigne lui-même un peu sur le fonctionnement de cette applet :)
Bien sûr que le protocole ssl permet l'authentification mutuelle. Mais la gestion des certificats clients au niveau des navigateurs n'est pas facile à gérer. D'autre part l'applet Java ne sert pas qu'à ça:
- le formulaire fait partie intégrante de l'applet et l'applet est signée donc tu es certain que l'appli n'a pas été modifiée par des tiers
- elle sert à signer numériquement ta déclaration et non ssl c'est pas fait pour ça! Je sais que certains protocoles d'authentification peuvent faire usage de schémas de signature, mais c'est pas ce "type" de signature qu'on veut.
- elle génère un pdf de ta signature
Bref la signature n'est qu'une des fonctionnalités de cette applet.
De plus avec l'applet, rien à installer côté client. Ca fonctionne quel que soit le navigateur et l'OS (à quelques exceptions près). C'est quoi le plus simple? Il y en a qui ont peut-être des soucis avec cette applet mais ces problèmes seront certainement prochainement corrigés. Pour ma part ça a fonctionné comme un charme (façon de parler quand on parle d'impôts!).
Le seul truc critiquable c'est la manière dont on te fournit le certificat puisqu'il suffit d'avoir accès à la feuille de déclaration de l'année précédente pour avoir toutes les données nécessaires. Mais l'utilisation d'OpenSSL n'y changerait rien!
Oh, et un "couple de certificats (publique/privé)" n'a aucun sens. Un certificat est par définition publique, et contient une clé publique. La clé privée correspondante n'en fait pas partie.
[^] # Re: Web, form et certificats...
Posté par ndesmoul . En réponse au journal Télédéclarer ses impôts et citoyenneté. Évalué à 3.
L'applet java (elle-même signée pour éviter l'exécution de code frauduleux) sert à remplir ta déclaration, mais se charge également de la signer numériquement.
Le choix de Java me semble pertinent. En plus c'est multiplateforme même s'il reste quelques soucis comme l'indique ce journal.
# virtualisation et 3D
Posté par ndesmoul . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à 4.
Toutes les solutions actuelles permettent d'émuler une machine/OS presque parfaitement mais pour avoir une accélération 3D c'est plus compliqué.
Certes pour les aspects serveurs, on s'en fout mais un utilisateur donné pourrait trouver pleins d'avantages à bénéficier d'accélération graphique dans une machine virtuelle (entre autre pour jouer à des jeux réberbatifs à wine sous un Windows émulé).
VMware semble proposer un support expérimental de DirectX. J'ignore si c'est utilisable.
Un journal parlait de ce sujet https://linuxfr.org//~qdm/24807.html
Dans ce journal je vous invite plus particulièrement à regarder le message de Jux introduisant le projet VMGL qui semble apporter une solution intéressante en permettant une accélération OpenGL (pour le moment limité à du Linux).
La page du projet: http://www.cs.toronto.edu/~andreslc/xen-gl/
[^] # Re: Re:
Posté par ndesmoul . En réponse au journal ubuntu ?== linux ?== gnome. Évalué à 0.
Sous Mandriva 2008, uname -o me donne "GNU/Linux"
[^] # Re: La france s'abstient
Posté par ndesmoul . En réponse au journal Prédiction du jour: OOXML sera accepté comme norme ISO. Ou pas.. Évalué à 2.
http://www.pcinpact.com/actu/news/42732-afnor-vote-iso-OOXML(...)
[^] # Re: un os en java ?
Posté par ndesmoul . En réponse à la dépêche JNode version 0.2.6. Évalué à 2.
Bon, alors déjà gcj c'est peut-être bien mais côté vitesse, la dernière fois que j'ai essayé c'était beaucoup plus lent que la JVM de SUN.
Cette dernière d'ailleurs, une fois "chauffée" se montre étonnament véloce. Sur du bout de code C transcrit en Java, j'avais une perte de moins de 10% sur les perfs avec la version Java.
Bon, par contre j'avais pas trop regardé toutes les optimisations de compilation de gcc et m'étais contenté d'un -O2 (aucune amélioration avec -O3).
Dans son état actuel GCJ permet éventuellement d'améliorer la vitesse de démarrage et l'empreinte mémoire. Et encore c'est même pas sûr qu'il y arrive de manière vraiment significative.
[^] # Re: Mauvaise image de Linux ?
Posté par ndesmoul . En réponse au journal Pour un driver NVIDIA libre .... Évalué à 7.
Pour la rapidité des drivers libres il faudra voir quand les drivers ATI seront plus avancés. Et puis je doute que les drivers libres incluront des optimisations spécifiques à tel et tel jeux comme cela semble être le cas avec les drivers propriétaires.
Enfin la plupart des gens ne jouent pas à des jeux derniers cri (de toute façon sous Linux c'est pas facile) et même une carte Intel est très largement suffisante pour faire tourner à fond compiz, googleearth ou Celestia.
Ce qui ne veut pas dire que je sois contre des drivers performants pour les cartes ATI et nVidia.
[^] # Re: Mauvaise image de Linux ?
Posté par ndesmoul . En réponse au journal Pour un driver NVIDIA libre .... Évalué à 7.
"While we are grateful that your company provides one of the best closed-source graphics drivers for Linux, it is not without its problems and prevents many users from having a truly free software platform. You have shown an open-source passion in the past when dropping the nforce-net binary blob in favor of the community-spawned forcedeth driver for Ethernet support on your motherboard chipsets. There has been a rumor that you may be developing an open-source strategy for your graphics products, so if that is the case please let us know your true intentions. Even if you were only able to open a subset of your Linux driver, this still would show a sign of solidarity to the free software world.
We stand united under the name OpenTheBlob.com, but realize that legally it may be next to impossible to open-source the binary portion of your graphics driver due to patents and preserving some intellectual property in this competitive market. What we are, however, asking you for is to support the open-source community to the fullest extent possible. The open-source "nv" driver that you provide for X is an abhorrent disaster that is limited to 2D acceleration and doesn't come without its share of limitations and shrouded code. We look to NVIDIA for providing concise programming documentation to willing open-source developers that is not encumbered by Non-Disclosure Agreements or other legal restrictions.
"
En gros ils sont d'accord avec toi que c'est une bonne chose que NVidia propose un driver performant sous Linux.
Ce que les développeurs veulent d'ailleurs c'est pas une libération des drivers mais l'ouverture des spécifications nécessaires pour développer un driver libre. C'est pas pareil. Enfin si les gars de NVidia peuvent participer c'est tant mieux.
Après ça NVidia pourra continuer, tout comme ATI/AMD, de développer des drivers fermés. On veut juste les specs! Y a pas d'imposition de licence ici. Au contraire publier les specs serait une forme de respect des clients qui pourront espérer utiliser du matériel NVidia comme ils l'entendent, y compris sur des architectures exotiques non supportées actuellement.
[^] # Re: Mouarf
Posté par ndesmoul . En réponse au journal Raytracing temps réel. Évalué à 2.
[^] # Re: compléments
Posté par ndesmoul . En réponse au journal Raytracing temps réel. Évalué à 3.
D'ailleurs la question serait plutôt: est-ce que nVidia va laisser faire?
ATI maintenant c'est AMD, donc ils sont bien placés pour aller dans les deux directions. Et Intel (qui fait également beaucoup de chipsets graphiques) a tout intérêt à promouvoir cela pour valoriser ses processeurs multi-CPU.
# compléments
Posté par ndesmoul . En réponse au journal Raytracing temps réel. Évalué à 10.
http://www.pcper.com/article.php?aid=455
http://www.pcper.com/article.php?aid=506
D'après ce que j'ai compris (je précise que je suis pas spécialiste):
Le raytracing ça permet de faire des choses plus réalistes sans se prendre la tête. Par exemple gérer les ombres est simplissime alors qu'en "rasterisation" (OpenGL/Direct3D) c'est beaucoup moins trivial.
D'autre part le calcul peut être hautement parallélisable puisqu'on dessine pixel par pixel. En gros doubler le nombre de coeur d'un processeur permet d'effectivement (presque) doubler les perfs. La techno peut donc tirer partie de l'évolution actuelle des procs. Intel semble d'ailleurs promouvoir cette techno...
Enfin, pour les résolutions PC standard, la quantité de calcul est plus importante qu'en OpenGL/Direct3D. Mais la durée de calcul augmente beaucoup moins vite qu'en rasterisation avec la complexité de la scène. Ce qui signifie qu'une fois qu'on sera capable de rendre en temps réel un jeux avec une résolution correcte, on sera rapidement à même d'avoir des scènes beaucoup plus complexes que celles actuellement possibles avec les techniques actuels.
Voilà voilà. Le raytracing c'est (peut-être) l'avenir du jeux vidéo.
En plus ça utilise des processeurs généralistes donc pas de problème de drivers! Bon, d'ici que ce soit utilisable...
[^] # Re: Tout ça pour lancer un troll CD/vynnil ...
Posté par ndesmoul . En réponse au journal La qualitaÿ de la musique grand public.. Évalué à 3.
# wineconsole
Posté par ndesmoul . En réponse au message wcmd de wine- tools introuvable. Évalué à 2.
[^] # Re: Pas mal celle-là
Posté par ndesmoul . En réponse au journal Ratification ISO d'OOXML sous la loupe de l'Europe. Évalué à 3.
Je sais pas moi, achète toi un sac de sable et défoule toi dessus...
Pour l'impression des 6000 pages, je crois que tu n'as pas compris mon propos. Tu reproches à Albert de ne pas avoir imprimé toute la doc alors que dans ses message précédents, tout ce qu'il indique chercher c'est la définition de WordJeSaisPlusQuoi95.
Toi quand tu recherches juste une petite info précise dans un gros doc tu l'imprimes forcément en entier?! La nature ne te dit pas merci!
Pour ce qui de la longueur de cette norme, oui elle est longue. C'est un problème pour une précédure de Fastrack, car un tel pavé demanderait plus de temps pour être correctement relu. Qui plus est ça fait franchement tentative de passage en force de la part de MS surtout si on compare à l'ODF, standardisé à l'OASIS, qui a suivi la procédure normale.
L'un des avantages de l'ODF est de réutiliser antant que possible des standards existants. Évidemment si tu cumules les spécifs de l'ODF avec celles des autres standards utilisés, tu ne dois pas être loin de la longueur de l'OOXML. Cependant ces différents standards ont déjà été étudiés et évalués/implémentés à part, alors que pour l'OOXML il faut évaluer ces parties à partir de zéro. Encore une fois pour une procédure fasttrack ce n'est pas sain.
Je ne suis en soi pas opposé à une standardisation de l'OOXML mais certainement pas en l'état: vu les problèmes techniques dénoncés et les réactions sucitées de part et d'autre, le minimum serait de revenir à une standardisation par la voie normale, histoire que l'ISO s'approprie réellement le format et apporte les corrections nécessaires au texte.