TImaniac a écrit 6423 commentaires

Comme dirait un grand parolier :
"jesus christ un jour tu vas revenir
Est-c'que tu pourrais légaliser
le mariage pour les curés
histoire qu'ils laissent un peu les enfants tranquilles"
(à prendre au nème degré étant donné le parolier en question ;))

1) Il s'agit d'un copié-coller d'un texte religieux, sans aucune forme d'analyse ou de critique : cela s'apparente à de la publicité.

2) Linuxfr.org publie des "dépêches" qui traitent de cinéma, mais se contente pas de publier une dépêche contenant un extrait youtube de la bande annonce du film. D'ailleur je penses pas me tromper en disant qu'une telle dépêche serait refusée.

Je n'ai pas franchement le sentiment de contrevenir à la ligne éditoriale de ce site en proposant l'extrait d'un texte qui parle de gratuité et de don dans le monde marchant !
Tu essai d'attirer l'attention avec une phrase (admettons que le sujet puisse être intéressant) pour au final indiquer au lecteur d'aller lire des textes qui parlent de pleins d'autres sujets.

C'est de la publicité grossière que tu nous fais là. J'espère que tout le monde ne va pas faire comme toi et que chacun va garder ses publi-communiqué sur ses croyances personnelles dans son coin, sinon c'est la mort assurée de LinuxFR.

La ligne éditoriale de LinuxFR :
"Les journaux sont destinés à des informations[...]"
Ce ne sont pas des informations que tu propages, mais des propos religieux.

"[...]ou simplement pour donner votre avis."
C'est le problème avec les croyants, il faut boire les paroles, pas donner son avis, alors on cite juste un texte, c'est auto-suffisant.
Ca se voit très bien dans les commentaires : plutôt que d'argumenter/critiquer, je te ponds une citation divine.

Certes, mais de là à reprocher à certains de seulement s'exprimer !!
Il s'exprime pas, il propose un publi-communiqué consistant en un copié-coller des propos rapportés d'une autre personne.
Après quand tu t'exprimes, surtout dans un espace de liberté comme LinuxFR, tu te soumets aux critiques et reproches, c'est tout ce qu'il y a de plus normal.

Je ne suis pas d'accord avec ce que vous dites, mais je me battrai jusqu'au bout pour que vous puissiez le dire
Personne ne l'empêche de s'exprimer le pape, mais là ce n'est pas de l'expression, c'est de la publicité, faut pas tout mélanger.

Que les propos du pape soient sur un site web, ca me va, mais j'ai pas plus de respect pour ce journal que pour d'autres publicité.
Et entre nous, les publicitaires du vatican sont mauvais, tu mets une bellaminette qui sorte une citation du pape dans une bulle, y'aurait beaucoup plus de chance que ca attire le geek moyen.

On parle bien cinéma ici.
Oué mais personne ne vient en faisant un copié-coller de l'interview du principal acteur et en pointant un lien vers le site web officiel de la boîte de prod.

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.