TImaniac a écrit 6420 commentaires

Convertir, non.
Jor.

Si c'est pas pour convertir, c'est pour expliquer aux ouailles, admettons. Dans ce cas les ouailles elles vont sur les sites adaptés et viennent pas sur LinuxFR, en tout cas pas pour lire ça.

Ceux qui veulent être abreuvés des paroles du Vatican, ils vont à l'église. Et personne ne m'oblige à y aller (encore heureux, quoique si tu voulais te faire bien voir par ton curé, t'avais intérêt à amener des gosses au cathé, que tes enfants le veuille ou non).

on est exactement dans la même situation que le pape avec ces encycliques.
Je me vois mal débarquer sur un forum catho en pondant une citation de Stallman avec 3 liens vers la GPL, la LGPL et la GFDL en bas de page, en disant : mangez-en, c'est bon.

peuvent être lues avantageusement par tous !
Peuvent l'être, ou pas. Je trouve juste le côté publicitaire grossier sur LinuxFR totalement déplacé. Je peux venir avec mon publi-communiqué RedHat ou même EDF (pourquoi pas, c'est sans rapport avec le libre, les journaux c'est fait pour ça non ?)

C'est pas parcque c'est le pape (ou un ensemble de personnes du Vatican) que ca doit être plus lu que n'importe quel autre ouvrage dans le style, et c'est pas parcque c'est le Vatican que l'on doit avoir plus de considération pour ses propos que n'importe quel autre publi-communiqué.

Je ne vois pas du tout pourquoi, sous prétexte que c'est le Pape, on ne devrait pas lire et écouter ce qui est écrit.
La finalité est connue : convaincre et convertir.
Surtout qu'en l'occurence les propos sont officiellement raccrocher à la doctrine religieuse, c'est pas une interview en aparté.

Partant de là, on peut, je penses, refuser de lire ou écouter ses propos.

A part essayer d'extraire quelques phrases qui pourraient "flatter" le libre (bien que je vois pas le rapport entre la gratuité et le libre, Free as in speech pas Free as in beer) pour au final tenter de rediriger le lecteur vers des documents purement religieux, à quoi peux bien servir un tel journal ?
Surtout que le contenu n'est qu'un copié-coller sans aucune critique ou analyse, qui de toute façon au regard de ton blog, sera tout sauf objectif.

ben t'auras ton fallback flash :)
et tu supporteras le standard html5 :)
Je dis pas que c'est pertinent du point de vue du libre, je me mets juste à la place du webmaster pragmatique qui veut pas encoder en double toutes ses vidéos.

Le problème, c'est que ces comparaisons se basent sur les versions en cours de développement (niveau "alpha") de Theora, des versions pas "stable" pour un youtube et encore moins pour un fabriquant de hardware.
Une comparaison honnête de ce qui est possible à l'heure actuelle se base sur Theora 1.0. Et là Theora ne tient pas la comparaison.

Si non, ton fallback ne marchera pas dans pleins de cas et faire du flash seul (qui ne demande pas non plus 2 videos encodées différemment) sera bien plus économique et sûre de fonctionner.
Flash supporte H264, on pourra proposer le format H264 dans la balise vidéo et proposer le lecteur flash sans changer le contenu.

Apple paie une licence pour utiliser certains brevets.
Ces brevets ne couvrent pas tout le code nécessaire pour implémenter la norme H264.
Le code d'Apple peut donc violer d'autres brevets et se faire enmerder pour cela.

or si ce dernier viole tel ou tel brevet, ce n'est pas à Apple de se prendre le procés,
Celui qui doit se faire attaquer, c'est celui qui viole le brevet. Si c'est Apple qui développe une implémentation de H264, c'est à eux de se prendre le procès.

Pour Apple, c'est pas compliqué, ils ont misés sur H264 depuis longtemps : iPhone, QuickTime, QuickTime Server, etc.
Apple paye une licence officielle depuis dès années, le modèle commercial du H264 est maintenant connu et ce codec est suffisament répendu pour qu'un risque de brevets sous-marin soit faible.
En revanche pour Ogg, c'est l'inconnu, à défaut de gros acteurs qui l'utilisent (et qui soit solvable, Mozilla n'est pas intéressant de ce point de vue là), il y a toujours un risque qu'une boîte sorte un missile au mauvais moment.
Evidemment, ce risque est du FUD pur et simple, mais le choix d'Apple est compréhensible : ils vont pas changer leurs softs pour prendre un risque supplémentaire.

Flash restera un gros consommateurs de ressources, donc d' energie.
En attendant Flash supporte H264 et le décodage hardware à l'aide des puces ATI et nVidia.

a priori non couvert par des brevets, et ce codec n'a pas été spécifié parce qu'une entreprise sur 5 n'était pas d'accord.

Cette entreprise n'a pas les même à priori que toi concernant les brevets :)

Google a donné une autre raison pour indiqué que Ogg était peut être pas la meilleure idée du moment : niveau qualité, c'est pas génial, pour youtube ca le fera pas.

C'est plus 1 société, c'est 2 sociétés, dont l'une possède la plus grosse banque de conneries, pardon vidéo aujourd'hui regardés sur le net.

Sans parler du fait que Microsoft n'a pas pris position mais a le navigateur avec les plus fortes part de marché... et que trouve-t-on dans son prochain OS et la v3 de Silverlight ? Du H264. MS le fait pas de gaîté de coeur (ils poussent un concurrent, VC-1), mais c'est le marché qui le demande. La pression est forte autour du support du H264, concernant Ogg, tout le monde s'en cogne à part Opera, Mozilla et les libristes.

Il y a d'autres raisons :
- Apple pousse à fond H264, à commencer sur les iPhone. Indépendamment de l'excuse des brevets concernant Ogg, Apple aime H264.
- Niveau hardware, H264 est bien mieux supporté par les fabriquants (ce qui est rappelé indirectement dans le mail de l'annonce : http://lwn.net/Articles/340132/ ). On change pas de matos comme on change de pile logicielle.

Avec Mono, j'ai des résultats comparables :
2214400 2009-07-09 20:36 System.Web.dll
4503320 2009-07-09 20:41 System.Web.dll.so
330944 2009-07-09 20:41 System.Web.dll.metadatas

J'ai généré uniquement les meta-datas (qui sont également présentent dans System.Web.dll et System.Web.dll.so) pour avoir une idée de leur taille, ces informations étant indispensable, que ce soit pour le code natif ou le bytecode.
On peut en déduire la taille du bytecode pour cet assembly :
2214400 - 330944 = 1883456

Si on suppose que System.Web.dll.so contient meta + bytecode (pour quoi faire, je sais pas) et code natif, ca donne un code natif 21% plus gros que le bytecode.
Si on suppose que System.Web.dll.so contient meta + code natif mais sans bytecode (ce qui semble logique), ca donne un code natif 121% plus gros que le bytecode.

Euh, VLC n'est pas à l'abris de problème juridique. C'est pas parcque personne n'a enmerder ce projet qu'il est à l'abris :)

Aucune idée. A priori le code natif a besoin des metadonnées mais pas des instructions .NET en soit. Après va savoir ce que fait ngen, je suis sous Windows et je maîtrise mal cet outil :)
Dans tous les cas, l'avantage est au bytecode puisque l'image native fait plus du double.

09/07/2009 18:00 1 732 915 mscorlib.zip
12/08/2008 10:28 4 546 560 mscorlib.dll
09/07/2009 18:00 4 861 833 mscorlib.ni.dll.zip
12/08/2008 11:20 11 485 184 mscorlib.ni.dll

En C# le destructeur est appelé, mais pas le Dispose (ce qu'est censé appelé le using). Le destructeur est appelé quand le GC passe, plus tard donc.

Répertoire de c:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089

12/08/2008 10:28 4 546 560 mscorlib.dll
1 fichier(s) 4 546 560 octets

Répertoire de C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\9adb89fa22fd5b4ce433b5aca7fb1b07

12/08/2008 11:20 11 485 184 mscorlib.ni.dll
1 fichier(s) 11 485 184 octets

Et est-ce que tu peux aussi imaginer l'inverse ?
Je peux l'imaginer, c'est juste toi qui a du mal à imaginer la réalité :)
Tu devrais pratiquer un peu plus, la pratique répond à beaucoup de questions :)

Comment le code natif peut être plus lent que le code bytecode ?
tu lis où tu reposes la question pour le fun ?
J'ai tenté d'expliquer qu'il y a des différences liées aux nombre d'I/O au démarrage.
J'ai jamais dis qu'en cours d'exécution le code natif était plus lent.

(ce qui est faux en passant, difficile de faire plus compact que du x86)
J'adore tes affirmations gratuites théoriques qui ne se vérifient pas en pratique.
Tu peux concevoir qu'une instruction écrite dans un bytecode de plus haut niveau corresponde à un paquet d'instructions en code machine ?

Pour moi, la VM a un dilemme entre travailler le code pour le rendre ensuite plus rapide et l'interpréter au plus vite pour ne pas avoir une trop grosse latence.
Ca c'est le dilemme des VM Java effectivement.
Le bytecode .NET a été conçu dès le départ pour être compilé en code natif. C'est une différence fondamentale qui fait que .NET ou Mono n'interprête jamais le bytecode .NET (mono a un interprêteur pour d'autres raisons) alors que la VM HotSpot pour Java travaille comme tu l'indiques.

Dans tous les cas, ca ne change rien à ce que je disais au départ : même s'il y a un léger écart au niveau perf, il est la plupart du temps minime.
C'est donc pas la présence d'un compilateur JIT qui fait qu'un programme écrit en C# ou Java est plus lent qu'un programme écrit en C.

En gros tu interprètes mal ce que je dis :)

Je dis que la lenteur au démarrage du JIT (démarrage à froid) est partiellement compensé par le fait que l'AOT a également d'autres raisons d'être plus lent au démarrage. Bref au final, c'est du cas par cas.

Dans tous les cas, pour la majorité des applications, les avantages du JIT sont ailleurs : fournir un bytecode indépendant de la machine.

Dans des tests fait par qui ? Sun ?
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)

Euh, une VM Java comme HotSpot compile (JIT) en code natif une ligne de code à la première exécution. Et c'est gardé en cache. Si tu repasses dans le même code tu repasses pas par du JIT.
Bref y'a un temps de chauffe et après c'est principalement du code natif qui tourne.

Franchement la compilation AOT, ca sert pas à grand chose, quelques cas tout de même :
- réduire le temps de démarrage (pour un serveur on s'en tape le coquillard)
- support des plateformes qui interdisent le JIT (iPhone coucou)
- quelques améliorations de perfs qui demandent un algo d'optimisation long et pas faisable par JIT en live.
- une moindre consommation mémoire.

Cependant :
- l'AOT peut être plus lent : le code binaire prend plus de place et doit être chargé entièrement au démarrage de l'application : le démarrage peut être plus lent, ce qui contrebalance nettement l'avantage précédement : des fois c'est plus rapide, des fois c'est plus lent.

Pour 95% des applications, l'AOT n'apporte pas grand chose, au final c'est ce que fait le JIT en maintenant un cache.

Oui tout à fait, le langage impose des règles que le compilateur doit respecter et intrinsèquement cela limite ses possibilités d'optimisation.

Et cela se passe comme une fleur avec la partie commune ?
Ben c'est comme tout, ca dépend des parties dont tu parles évidemment.
Pour ce qui concerne les libs standards, je n'ai jamais eu de problème de compatibilité.

Tu me dira mono doit faire des testes de conformité avec l'implémentation de MS.
Y'a une batterie impressionnante de tests unitaires pour valider la conformité avec les libs MS.

D'ailleurs, une question à part: est-ce que mono tourne sous d'autre cible que le x86 ?
Ben : http://www.mono-project.com/Supported_Platforms

C'est une blague ?
Ben je connais au moins 3 implémentations différentes, mais bon forcement aucune ne démontre ce que tu avances.

Je t'ai trouvé des exemples de langages ayant les 2 technologies.
Super, mais tu changes plusieurs paramètres, donc tu démontres rien du tout. Peut être que c'est le traducteur JIT de OCaml qui est mauvais, va savoir.
Ou peut être que le principal facteur c'est pas les outils mais la sémantique et les services qu'il y a derrière le langage... Le truc que j'appelle VM.

Je parle des framework MS et ceux de Novell.
Oué oué oué, en gros tu veux parler des libs, c'est là qu'il y a des incompatibilité.
Rien d'anormal, ce sont 2 frameworks différents, avec une partie en commun et chacun des spécificités. Où veux-tu en venir ?