Comme dis dans le commentaire précédent, ce que tu décris est le PDF.
En fait faut en revenir au problème initiale :
le format PDF n'est pas une solution en soit car il ne constitue pas l'original, mais plutôt une photocopie sur lequel il est difficile de revenir en arrière.
Pour de nombreuses raisons, beaucoup de monde a besoin de conserver les originaux (tout bêtement pour travailler dessus), notamment les grands organismes. Une partie s'est apercu que ses informations étaient stockées dans ces documents, et ont commencé à se poser des questions sur la pérénité mais aussi l'opacité de ce moyen de stockage : c'est ainsi que certains organismes ont commencé à remettre en cause le format .doc. le format de OOo a le gros avantage d'être ouvert et utilise des technos standarisées, il permet donc d'obtenir une transparence technique et donc un gage de pérénité pour ces organismes.
MS s'est trouvé dans une situation délicate : on risque de perdre des clients. Ils ont donc fait le format MS Office XML dans Office 2003. Problème : ce format bien qu'utilisant des technos ouverte restait fermé. De son côté Sun a décidé de standarisé son format, histoire d'obtenir un label relativement convoité : "Standard" (alors qu'une normalisation suffirait, sans la notion de "standard" qui rappelle trop le W3C qui lui a besoin de vrais standards).
Si sur le papier l'idée peut sembler bonne, visiblement les efforts de coopération avec MS ont tournés court. Quand on voit le résultat (c'est à dire la prise en compte de la suite MSOffice dans l'ODF), on se dit que Sun et l'OASIS n'ont pas fait grand chose pour intégrer le lourd passif de MS en matière de documents dans son format propriétaire (il suffit de constater que les formats gérés par l'ODF correspondent aux formats gérés par OOo et non par MS Office qui contient différentes applications). Bref, Sun s'est retrouvé à faire un standard "tout seul", pas seul physiquement, mais en tout cas sans le principal acteur du marché. Balo pour un standard. Bref, en tant que standard, l'ODF est mort, sans doute à cause de conflits entre MS et Sun. Reste qu'il est normalisé et c'est tant mieux.
Reste que le label "standard" reste toujours vendeur, et c'est Sun qui risque d'y gagner quelques part de marché. MS ne veut pas lâcher le morceau, et en réaction à ce qui s'est passé à l'OASIS, et pour satisfaire les besoins de nouveau clients, ils se lancent dans la normalisation de leur format XML.
Par rapport au problème initiale, qui est "l'emprisonnement des données", les 2 solutions se valent et répondent à leurs objectifs. Reste que Sun et une partie du libre a fait tourner le débat vers un autre point : l'interopérabilité. Bah oui, qui dit standard, dit interopérabilité. Et maintenant on part dans des débats sur quel est le meilleur format, tel format est le standard il doit être implémenté par tout le monde, blablabla. Alors qu'il n'y a pas de standard, juste des formats ouverts.
Je vais reprendre un exemple que j'aime bien , qui concerne toujours MS et Sun : .NET et Java sont 2 plateformes, toutes 2 plus ou moins normalisées à travers différents organismes/comité, mais aucun n'a la prétention de s'occtroyer le titre de "standard". Y'a 2 alternatives (et beaucoup plus), et c'est tant mieux.
Enfin Sun a bien joué son coup, en faisant basculer le débat de la a dépendance des données vis-à-vis d'un format au faux débat de l'interopérabilité avec comme solution SON standard, qui a conduit inévitablement vers le même débat qu'au W3C : IE ca pu, ca implémente pas les standards... MS Office ca pu ca n'implémente pas les standards. Pourtant c'est pas du tout la même situation et le même type d'informations/documents.
Techniquement, les 2 formats ont leurs avantages et inconvénients, il en fait aucun doute que le format ODF est très bien conçu comme le dis Normal Walsh. Il faut noter qu'il dit "techniquement". (DocBook est pour moi nettement plus élégant sur le typage de l'information que l'ODF, mais c'est pas le sujet, et les 2 formats n'ont pas les mêmes objectifs).
l'ODF est très orienté fonctionnalités de OOo : c'est un format de travail.
l'OpenXML est très orienté MS Office : c'est un autre format de travail.
La bataille actuelle montre clairement que ces formats sont "stratégiques", justement parcque ce sont des formats de travail, et que de leurs structures sont fortement liées aux informations manipulées par l'outil. Hors ces informations sont intrinséquement définies par les fonctionnalités de l'application.
Pour ces raisons :
- Une suite bureautique utilise le format de travail d'une autre suite mettra la première en retrait de la 2ème, les 2 risquant d'être à terme fonctionnement identique. C'est empêcher l'innovation de la première. KOffice se condamne ainsi pour moi sur le long terme à être un clone de OOo, avec comme seul atout l'intégration à KDE.
- Chaque suite doit garder une liberté dans l'évolution de son format de travail et donc maîtriser son propre format.
- Cela ne sert donc à rien de vouloir imposer l'ODF ou l'OpenXML comme unique standard. Que les 2 soient normalisés peut avoir de nombreux avantages, mais chercher à décrêter qu'il n'y a qu'un seul standard (au sens W3C par exemple, mais c'est pas du tout la même situation) me paraît absurde.
- Il faut un vrai format d'échange pour les documents Office. Un format non pas de travail mais un format d'interopérabilité. Ce format ne doit pas être aussi puissant que OpenXML ou ODF, il doit reprendre les points communs de ces principaux formats. Ce format ne doit pas être le format de travail d'une suite, mais doit s'intégrer en import/export.
Sinon une petite remarque sur l'article de Wikipedia : c'est à ce genre d'articles qu'on peut remettre en doute la qualité d'une encyclopédie telle que Wikiepedia. Heuresement qu'on tombe pas trop souvent sur ce genre d'article. C'est bourré de subjectivité, de mauvaise foi, d'inexactitude, bref, c'est vraiment à virer de l'encyclopédie. Détrompez vous j'aime wikipedia, mais pas toutes les contributions ;)
C'est pas parcqu'ils ont pris cette décision qu'ils sont sûr d'implémenter à 100% l'ODF... Sans parler des lacunes sémantiques de ce format qui risque de voir des différences entre OOo et d'autres suites, alors que les 2 respectent le format.
Un exemple qui montre clairement que l'OASIS n'a pas fait son boulot (ou alors l'OASIS ne sert à rien) : http://software.newsforge.com/article.pl?sid=05/09/09/192250(...)
Si ca à voir. Les auteurs de mod_perl ont cassé la compatibilité parcqu'ils étaient essentiellement constitués d'API "perlisé" de Apache. Apache a cassé la compatibilité, mod_perl a donc pété au passage. Et donc toutes les applis qui les utilise comme talweg.
.NET propose pour talweg tous les API dont ils avaient besoins qui se trouvait dans mod_perl, mais cette fois si avec l'indépendance vis-à-vis du serveur Apache 1, puisqu'on peut facilement imaginer faire tourner l'appli sur un autre serveur web comme Apache 2 ou IIS.
C'est tout l'intérêt de plateforme complètes et intégrées comme .NET ou Java : les APIs sont unifiés et on y trouve de tout en "standard", évitant d'avoir à se trimbaler des dépendances vers 15000 bibliothèques externes dont on n'est pas sûr de la pérénité dans le temps.
Sans cela, il est probable que M$ n'aurait meme pas pense a commencer a essayer de tenter de la faire.
Je penses que MS comme SUN cherche à standardisé leurs formats respectifs pour "appater" des clients potentiels. Le logo "standard" étant vendeur.
Sinon pour le plugin on ne se comprend pas.
Sun a fait sa part de boulot en faisant le "plugin office" dans OOo.
Reste a M$ a faire la sienne avec le "plugin OOo" dans Office.
A la différence prêt que SUN avait un intérêt à supporter le format MS : utiliser les millions de documents existant dans ce format. MS n'a aucun intérêt à utiliser le format OOo. Si SUN croît que son format peut servir de standard d'interopérabilité et qu'il gagnerait à être supporter par MS Office, c'est à lui de le démontrer.
u as dit que gcc n'offrait pas ça (
elle est où l'option --gc dans le compilo ? :)
Oui, tu remarqueras que c'est exactement ce que je dis dans le post auquel tu réponds
Bah oué je confirmes mes doutes également c'est tout :) Mais comme quoi y'a bien des services qui sont propres aux environnement d'exécutions "managés" ;)
pas la compilation. C++ est beaucoup plus difficile à compiler que Java, par exemple.
Compiler Java n'est pas difficile, mais compiler Java en natif comme le fait GCC c'était visiblement pas évident puisqu'ils avaient l'air d'être tout fier de le faire et qu'ils sont le seul à le proposer...
Quant au bench que tu cites, c'est de la merde. Il faut vraiment être un âne (je ne parle pas de toi) pour utiliser des benchs qui tournent aussi vite et prétendre que c'est représentatif de quelque chose...
Autant pour comparer 2 langages je trouves effectivement que c'est de la merde généralement, autant pour comparer 2 implantations je vois pas en quoi c'est de la merde, sachant que le temps de 'lancement' n'est généralement pas pris en compte...
En tout cas les bench semblent refléter la réalité, il suffit de comparer gcc et le compilo d'intel par exemple pour voir qu'on retrouve bien graphiquement ce qu'on constate de manière empirique :)
L'intérêt, c'est l'occupation mémoire plus faible, la facilité de distribution, etc.
En fait GCJ est parti dans "Extra" me demande pas pourquoi... http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...)
Ben même si ce sont des benchs de merde, visiblement l'occupation mémoire semble pas spécialement améliorée avec GCJ... Après faut voir sur une appli réelle et comparer... Mais bon des premiers tests de Eclipse sur Fedora que j'avais fais, question rammmage ca avait pas l'air d'apporter quoique ce soit :)
Quand à la facilité de distribution, je trouve que c'est plutôt un désavantage : le bytecode a l'avantage d'être portable, la phase de JIT est pour moi le meilleur compromis : tu distribues un seul binaire, et tu profites de l'exécution native.
Effectivement, mais autant je trouve le copyright de Adobe sur PostScript douteux, je comprends mieux le cas Java, qui peut être une marque déposée. (je suppose que c'est d'ailleur le cas). J'avais jamais penser à ca, cela dis ca peut aussi s'inscrire dans des exceptions comme le reverse engineering, parfoislégitimisé par l'interopérabilité qui en découle.
Tu as des sources SVP ?
Des sources de ? Du fait que le format a était fait par Sun tout seul ? Ben pas vraiment de sources mais un constat :
Specif avant de rentrer à l'OASIS fait par Sun - Specif à la sortie de l'OASIS = aucune modification.
En gros les membres ont votés, et ils ont approuvé le format de Sun, sans rien toucher. Yahoo. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=o(...)
Sinon le plugin en question il ressemble tout betement a OOo. Ben oui OOo sait lire et ecrire les formats Office et Open Document. 100 % des fonctionnalites pour Open Document (logique) pour les formats Office je ne sais pas (donc je ne balance pas de chiffres) mais en ce qui concerne la lecture je constate qu'OOo me relit bien (pas parfaitement certes mais tres bien quand meme) les documents Office.
Ben vas-y fait le plugin, comme ca tous les utilisateurs d'office pourront enfin lire nos documents ODF qu'on fait sous notre OS libre.
Personne ne demande a Microsoft d'utiliser le format ODT comme format par defaut !
Euh... le journal pointe une FAQ (Frequently != personne) : Why is Microsoft offering a new standard, rather than simply supporting the file format for the Open Office product (sometimes called ODF)?
Donc si, des gens se demande pourquoi MS a besoin d'un autre format que ODF.
Ce qu'on lui demande est de pouvoir exporter/importer, out-of-the-box, le format ouvert ODT
Justement ce que j'ai voulu montrer : c'est pas possible. Aussi vrai qu'il n'est pas possible que OOo gère intégralement MS Office à moins d'être fonctionnelement identique. Je vois pas l'intérêt qu'à MS à supporter "partiellement ODF" sachant qu'il sera perpétuellement critiqué justement pour ce côté "partiel" (lié à l'ODF lui même, pas à MS pourtant). En refusant d'utiliser l'ODF, ils se démarquent du courant que veut faire passer Sun : "l'ODF est un standard". En n'incluant aucun support pour l'ODF, MS montre clairement son opposition à ce format. MS implémentera donc le support de l'ODF peut être un jour, non pas parcque c'est un standard, mais parqu'il y aura beaucoup de demande de la part de ses clients (comme ils le font pour le PDF qu'ils se décident à supporter face aux demandes)
Comme ca il est a peu pres sur que c'est ce format qui sera utilise et que Word conservera sa position "en avance"
Evidemment. Et Sun tu crois qu'il tente de faire quoi en "standardisant" l'ODF ? Exactement pareil. La décision de MS est donc tout à fait logique.
La rapidite ? c'est important pour le format par defaut qu'on utilise en interne mais ce n'est pas critique pour un format d'echange, qu'on utilise qu'a l'exportation.
Si l'ODT devenait un standard de fait (comprendre répendu), t'aurais d'un côté la suite MS Office qui se coltinerait à chaque fois la lecture puis l'écriture avec en permanence une conversion : résultat lenteurs permanente (je prends l'exemple con d'un document qui circule dans une boîte où ce n'est pas comme tu dis le format d'échange mais directement le document de travail). De l'autre côté t'aura la suite OOo qui gère nativement le format et qui sera clairement avantagé.
Le problème de l'ODF, c'est de vouloir faire d'un format de travail un format d'échange. C'est avantager exclusivement une suite Office, il est tout à fait normal que MS refuse celà.
Et pour un traitement de texte 99% des fonctionnalites courantes sont gerees a la fois par OOo et Office, et sont disponibles dans le format OOo.
99% ! Genre ! Et c'est moi qui suis de mauvaise foi. Alors pourquoi OOo ne gère pas intégralement le format XML Office 2003 qui est documenté ?
Pourquoi KOffice a de nombreux problèmes à gérer le format ODF ?
S'il y a des facilités entre OOo et MS Office, c'est uniquement parcque OOo essai de "copier" MS Office (fonctionnelement) contrairement à KOffice : si comme tu dis 99% des fonctionnalités étaient identiques, on aurait 2 produits identiques : quel es l'intérêt ? Chaque concurrent (Sun, KOffice, MS) ont besoin d'avoir une liberté pour innover, et pour cela il faut un format neutre qui soit un vrai format d'échange, bref qui ne soit pas le format de travail de OOo.
Sun a voulu imposer son format tout seul, bien, bah qu'il démontre qu'il est interopérable en écrivant un plugin à Word qui fait l'import/export.
Ah oui tiens la réaction de RSF : http://www.pcinpact.com/actu/news/26270-Censure-de-Google-en(...)
Citation : La liberté d’expression n’est pas un principe accessoire, que l’on peut mettre de côté lorsqu’on opère dans une dictature. C’est une valeur reconnue par la Déclaration universelle des Droits de l’Homme et inscrite dans la Constitution chinoise
Des explications ? Ben j'en ai donné : les logiciels n'ont pas les mêmes fonctionnalités. Si tel soft propose une fonctionnalité et permet sa sauvegarde les informations associées dans un format de document, et que tel autre soft ne propose pas la même fonctionnalité, il sera bien impossible pour lui de traiter correctement ces informations.
Tu prends n'importe quel différence entre les 2 suites OOo et MS Office, ca te fait autant de problème potentiels dans les 2 formats (MS et ODF).
Un format interopérable doit être indépendant et reprendre les points communs, quitte à ne pas être aussi puissant que format dédié à chaque soft. Mais ca demande la création d'un vrai standard par les principaux acteurs.
De toute façon le format ODF ne pose pas de problème uniquement à MS, il pose aussi problème aux autres suite office, comme KOffice, qui ne peut supporter tout le format, ce qui en montre clairement les limites.
Comment peuvent ils parler de compatibilité ascendante quand on sait pertinament qu'on ne pourra pas ouvrir un doc office 2003 avec office 95 (
Forcement tu prends le cas extrême. Mais leur intention est bien d'intégrer dans Office 2000/XP/2003 des filtres d'import/export vers leur nouveau format.
Leur truc génial dont ils parlent, des feuilles de styles non définis par microsoft mais personnalisé, avec du xml, ça me rappelle quelque chose... ah oui, le XML et les feuilles de style...
Tu dis n'importe quoi. Ils ne parlent pas de feuille de style à aucun moment. Essaye d'utiliser InfoPath dans Office 2003, tu comprendras mieux après de quoi ils parlent.
* Donc pour rendre les choses plus rapides il faut parser du xml qui n'est pas du xml ? Ou bien faire un décompresseur/parseur plus performant, ou un format de compression adapté au logiciel ?
La manière dont est structurée un document XML influence énormément les performances des outils qui l'utilise. Si un grand nombre de transformations est nécessaire pour passer de la représentation XML à la représentation métier de l'appli, tu peux mettre un temps fou à charger les gros documents. Suffit de voir le temps nécessaire pour charger un document MS Office dans OpenOffice.org : non pas que OOo est mal codé et super lent, c'est juste que OOo doit "transformer" un format dans un autre.
Ce n'est pas une justification pour ne pas utiliser ODF, n'importe quel format peut être robust-testé.
Non mais c'est une justification pour utiliser
Techniquement parlant. Après il y a toujours l'aspect "je veux imposer mon format à moi le mien"
Il est à peu prêt normal qu'ils préfèrent choisir un format dont ils ont testé la robustesse dans leurs applications à eux (donc entre autre testé en interne) que de se baser sur un truc nouveau inconnu pour eux. OOo fait exactement pareil en utilisant leur propre format : ils le maîtrise et c'est stratégique.
Ce ne sont que des déclarations d'intention. Je suppose qu'en tant que tel ils n'y aura pas de refus de vente, mais des conditions dans la licence qui font qu'un éditeur de LL n'aura aucun intérêt à achter la dite licence.
Justement, pourquoi pas ODF ?
Euh... t'as lu mon post en entier ? L'ODF est étroitement lié aux fonctionnalités de OOo. Il n'est donc pas adapté à servir de standard d'interopérabilité. Sun a tout à fait le droit d'avoir ce format, c'est même ce que je préconise, OOo doit avoir un format supportant toutes les fonctionnalités d'OOo. Mais qu'on arrête de l'appeler "pompeusement" standard tout en y trouvant un gage d'interopérabilité avec d'autres suites Office qui n'ont pas les mêmes fonctionnalités.
Ah oui et pour troller un peu, je trouve leur commentaire sur Sun et l'OASIS tout à fait pertinent, je ne trouves pas que ce soit de la propagande : le processus de "standardisation" de l'ODF a été du foutage de gueule, en gros Sun a simplement obtenu le label "Standard" sans rien toucher à son format, hors celui-ci est tout sauf parfait, notamment en ce qui concerne l'interopérabilité, ce qui est plutôt balo pour standard. Comme je l'ai dis plus haut, l'ODF est un format liés aux fonctionnalités de OOo, point barre (bref, c'est pas pour MS Office ou KOffice par exemple).
Boh, remarquez: du moment qu'on a les specs, rien n'interdit de se faire un filtre XSLT pour transformer de l'ODF en OpenXML et vice versa.
Faut bien voir que les formats des suites offices ne sont pas des formats d'échanges de données "génériques". Les formats sont étroitement liés aux fonctionnalités des softs pour lesquels ils sont créés. Créer un filtre de transformation d'un format dans l'autre sera forcement imparfait et des informations seront forcement perdues.
Vu à quoi ressemble d'ODF, il aurait été idiot pour MS de le supporter natif. (un filtre import/export je dis pas). Comme il aurait été idiot que OOo utilise le format de MS en natif (au risque d'avoir un clone fonctionnel sans possibilité d'innovation).
L'idée serait peut être de réfléchir à un format d'interopérabilité (un vrai, pas ODF), qui soit assez relativement générique, et où les éditeurs de suite Office seraient réellement impliquées. Bref un format qui ne permettent pas d'avoir une compatibilité à 100% des fonctionnalités, mais qui permette au moins d'échanger un contenu, en laissant chaque acteur faire évoluer son propre format (et donc évoluer les fonctionnalités de leurs softs).
mais si tu veux t'implanter en chine c'est normal de les respecter.
Je dis pas que ce que fais Google est anormal, il respecte les lois chinoises et c'est très bien. Mais bon je penses pouvoir affirmer sans me tromper que la pratique de la censure telle qu'elle est pratiqué là bas relève plus du non respect des droits de l'homme que d'autre chose. D'où le fait que j'en conclu que Google préfère se plier au règles du "marché" potentiel chinois que d'avoir un peu d'éthique, quitte à laisser passer un marché juteux.
Parmis tes choix :
1 - le premier est éthique et respecte leurs lois.
2 - pas possible, ils deviennent hors la loi.
3 - respecte les lois mais pas éthique.
Contrairement à ce que tu penses, je trouve le dernier choix comme moins respectable que les 2 autres.
En même temps personne ne les obliges à s'implanter en Chine... Mais bon les intérêts commerciaux ont été plus fort que l'éthique. Mais bon ca devient de plus en plus utopique de demander à une entité commerciale de penser de manière "humaine".
En même temps rien ne t'obliges à mettre ".exe" à la fin de ton fichier, t'es sous Linux, pas sous Windows, l'OS ne charge pas un exécutable en fonction de l'extension ;)
Non. Une VM peut faire dynamiquement des optimisations de très haut niveau qui ne sont pas possible à implémenter statiquement.
Il y a aussi des optimisations liées à la machine cible : en C "standard", il faut choisir les optimisations (386, 686, etc.) et filer autant de versions, avec un compilateur JIT, celui-ci peut déterminer "à la volée" les optimisations éventuelles.
Contrairement à ce que raconte Timaniac, il est bien entendu parfaitement possible de faire du garbage collecting sans utiliser de VM, de même que de la reflection, etc
Eh oh j'ai jamais dis ca :) Il y a bien des GC pour C++ par exemple. Comme il y a des possibilité de reflection également en C++ avec certains outils. Mais c'est pas en standard dans le langage. Et pour la sécurité (les AppDomain par exemple), j'ai beaucoup plus de doute sur la faisabilité (mais bon ca doit pouvoir se faire). Un environnement d'exécution comme Java ou .NET/Mono propose ces services en standard, et potentiellement pour tous ceux qui ciblent le code intermédiaire de ces VM. La VM constitue plutôt l'ensemble d'instructions "imposées" qui permet de contrôler et d'obtenir un certain nombre de garanties à l'exécution du code natif résultant.
En fait, beaucoup de gens (comme Timaniac) confondent runtime et VM.
J'ai pourtant tenté d'expliqué que la VM n'était qu'une "vision" du programmeur, et qu'à l'exécution c'était kif kif bourriqot. D'ailleur je parles dès que possible d'"environnement d'exécution", plutôt que de VM.
Ceci dit, comme le montre l'exemple de GCJ, compiler nativement un langage comme Java ne pose pas de problèmes particuliers.
Euh ca fait quand même un moment qu'ils courraient après ;)
Et puis au final un bout de code compilé avec GCJ tourne généralement moins vite qu'un bout de code tournant sur la JVM de Sun donc bon l'intérêt... Cela dis ca reste utile pour faire du JIT sans aucune interprétation.
(désolé pour les sources, mais http://shootout.alioth.debian.org/debian/ ne tient plus compte de GCJ, me demande pas pourquoi)
Je pensais que la CLR était un peu comme la JVM, une sorte "d'émulateur" pour un proc virtuel, avec donc des instructions de très bas niveau...
Un émulateur serait plutôt ce qu'on appelle un "interpréteur" : il lit bêtement à la suite les instructions de la machine virtuelle, les interprêtes, et les exécute. C'est ce qui se passe par exemple avec l'interprêteur Perl. C'est comme ca que fonctionnait les JVM initialement. Maintenant l'environnement d'exécution "compile" le bytecode en code natif avant de l'exécuter.
Donc il existe une manière de compiler du .NET en natif ? (comme avec gcj ?)
.NET a été conçu pour être compilé dès le départ, c'est donc assez naturelle. sous Mono ca donne :
mono --aot monprog.exe
Pour java c'était plus compliqué, vu que ce n'était pas conçu pour dès le départ. La plupart des JVM mixait donc du JIT et de l'interprétation. GCJ a démontré que c'était cependant possible de tout compiler avant.
l'indépendance de la plate-forme (principal avantage de la VM, mais à mon avis ce n'était pas le but recherché par Microsoft)
MS doit supporter plusieurs architectures matérielles : x86, x64 plus les proc de PDA/smartphone (ARM, etc.) L'indépendance vis-à-vis d'une plateforme matérielle est donc bien un but recherché par MS.
- langages de haut niveau comme c#/delphi.NET/<votre_langage_favori> avec garbage collector, programmation fonctionnelle & co... (il existe déjà des langages compilés qui font tout ça, cf OCaml. Au pire il suffirait de coder un frontend c# pour gcc => pas besoin de VM non plus !)
Faut bien voir que la VM n'est qu'une "vision", une sorte d'abstraction pour les programmeurs et compilateurs. Mais à l'exécution tout ca est compilé en code natif (JIT), voir même avant (AOT), bref après ca marche comme OCaml ou du code compilé avec gcc. Faut bien voir que gcc propose intrinsèquement la même architecture avec un code intermédiaire entre le frontend et le backend (commun à tout le monde). La différence c'est que gcc n'offre pas (ou très peu) de services supplémentaires (à l'exécution). S'il y a des différences de perf, c'est pas lié à la présence du code intermédiaire pour la VM, mais justement aux services associés : GC, sécurité, reflection, etc. Après tout est une question d'objectifs. Si les VM ont du succès aujourd'hui par rapport à hier, c'est que les services qu'elles offrent sont plus intéressant que les pertes de performances qu'elles engendrent (avant c'était trop pénalisant, aujourd'hui ca peut le rester dans des parties critiques).
Donc en gros, pourquoi l'avenir de l'informatique passerait t-il forcément par un dispositif avec une machine virtuelle ?
Pour l'ensemble des services qu'elles offrent, qui permettent de gagner en productivité.
[^] # Re: Mon avis à moi (en essayant d'être concis)
Posté par TImaniac (site web personnel) . En réponse au journal MSoffice XML Vs OpenDocument. Évalué à 9.
En fait faut en revenir au problème initiale :
le format PDF n'est pas une solution en soit car il ne constitue pas l'original, mais plutôt une photocopie sur lequel il est difficile de revenir en arrière.
Pour de nombreuses raisons, beaucoup de monde a besoin de conserver les originaux (tout bêtement pour travailler dessus), notamment les grands organismes. Une partie s'est apercu que ses informations étaient stockées dans ces documents, et ont commencé à se poser des questions sur la pérénité mais aussi l'opacité de ce moyen de stockage : c'est ainsi que certains organismes ont commencé à remettre en cause le format .doc. le format de OOo a le gros avantage d'être ouvert et utilise des technos standarisées, il permet donc d'obtenir une transparence technique et donc un gage de pérénité pour ces organismes.
MS s'est trouvé dans une situation délicate : on risque de perdre des clients. Ils ont donc fait le format MS Office XML dans Office 2003. Problème : ce format bien qu'utilisant des technos ouverte restait fermé. De son côté Sun a décidé de standarisé son format, histoire d'obtenir un label relativement convoité : "Standard" (alors qu'une normalisation suffirait, sans la notion de "standard" qui rappelle trop le W3C qui lui a besoin de vrais standards).
Si sur le papier l'idée peut sembler bonne, visiblement les efforts de coopération avec MS ont tournés court. Quand on voit le résultat (c'est à dire la prise en compte de la suite MSOffice dans l'ODF), on se dit que Sun et l'OASIS n'ont pas fait grand chose pour intégrer le lourd passif de MS en matière de documents dans son format propriétaire (il suffit de constater que les formats gérés par l'ODF correspondent aux formats gérés par OOo et non par MS Office qui contient différentes applications). Bref, Sun s'est retrouvé à faire un standard "tout seul", pas seul physiquement, mais en tout cas sans le principal acteur du marché. Balo pour un standard. Bref, en tant que standard, l'ODF est mort, sans doute à cause de conflits entre MS et Sun. Reste qu'il est normalisé et c'est tant mieux.
Reste que le label "standard" reste toujours vendeur, et c'est Sun qui risque d'y gagner quelques part de marché. MS ne veut pas lâcher le morceau, et en réaction à ce qui s'est passé à l'OASIS, et pour satisfaire les besoins de nouveau clients, ils se lancent dans la normalisation de leur format XML.
Par rapport au problème initiale, qui est "l'emprisonnement des données", les 2 solutions se valent et répondent à leurs objectifs. Reste que Sun et une partie du libre a fait tourner le débat vers un autre point : l'interopérabilité. Bah oui, qui dit standard, dit interopérabilité. Et maintenant on part dans des débats sur quel est le meilleur format, tel format est le standard il doit être implémenté par tout le monde, blablabla. Alors qu'il n'y a pas de standard, juste des formats ouverts.
Je vais reprendre un exemple que j'aime bien , qui concerne toujours MS et Sun : .NET et Java sont 2 plateformes, toutes 2 plus ou moins normalisées à travers différents organismes/comité, mais aucun n'a la prétention de s'occtroyer le titre de "standard". Y'a 2 alternatives (et beaucoup plus), et c'est tant mieux.
Enfin Sun a bien joué son coup, en faisant basculer le débat de la a dépendance des données vis-à-vis d'un format au faux débat de l'interopérabilité avec comme solution SON standard, qui a conduit inévitablement vers le même débat qu'au W3C : IE ca pu, ca implémente pas les standards... MS Office ca pu ca n'implémente pas les standards. Pourtant c'est pas du tout la même situation et le même type d'informations/documents.
# Mon avis à moi (en essayant d'être concis)
Posté par TImaniac (site web personnel) . En réponse au journal MSoffice XML Vs OpenDocument. Évalué à 8.
l'ODF est très orienté fonctionnalités de OOo : c'est un format de travail.
l'OpenXML est très orienté MS Office : c'est un autre format de travail.
La bataille actuelle montre clairement que ces formats sont "stratégiques", justement parcque ce sont des formats de travail, et que de leurs structures sont fortement liées aux informations manipulées par l'outil. Hors ces informations sont intrinséquement définies par les fonctionnalités de l'application.
Pour ces raisons :
- Une suite bureautique utilise le format de travail d'une autre suite mettra la première en retrait de la 2ème, les 2 risquant d'être à terme fonctionnement identique. C'est empêcher l'innovation de la première. KOffice se condamne ainsi pour moi sur le long terme à être un clone de OOo, avec comme seul atout l'intégration à KDE.
- Chaque suite doit garder une liberté dans l'évolution de son format de travail et donc maîtriser son propre format.
- Cela ne sert donc à rien de vouloir imposer l'ODF ou l'OpenXML comme unique standard. Que les 2 soient normalisés peut avoir de nombreux avantages, mais chercher à décrêter qu'il n'y a qu'un seul standard (au sens W3C par exemple, mais c'est pas du tout la même situation) me paraît absurde.
- Il faut un vrai format d'échange pour les documents Office. Un format non pas de travail mais un format d'interopérabilité. Ce format ne doit pas être aussi puissant que OpenXML ou ODF, il doit reprendre les points communs de ces principaux formats. Ce format ne doit pas être le format de travail d'une suite, mais doit s'intégrer en import/export.
Sinon une petite remarque sur l'article de Wikipedia : c'est à ce genre d'articles qu'on peut remettre en doute la qualité d'une encyclopédie telle que Wikiepedia. Heuresement qu'on tombe pas trop souvent sur ce genre d'article. C'est bourré de subjectivité, de mauvaise foi, d'inexactitude, bref, c'est vraiment à virer de l'encyclopédie. Détrompez vous j'aime wikipedia, mais pas toutes les contributions ;)
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Pourquoi Office 12 ne supporte pas OpenDocument. Évalué à 2.
Un exemple qui montre clairement que l'OASIS n'a pas fait son boulot (ou alors l'OASIS ne sert à rien) :
http://software.newsforge.com/article.pl?sid=05/09/09/192250(...)
[^] # Re: lapin compris
Posté par TImaniac (site web personnel) . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 2.
.NET propose pour talweg tous les API dont ils avaient besoins qui se trouvait dans mod_perl, mais cette fois si avec l'indépendance vis-à-vis du serveur Apache 1, puisqu'on peut facilement imaginer faire tourner l'appli sur un autre serveur web comme Apache 2 ou IIS.
C'est tout l'intérêt de plateforme complètes et intégrées comme .NET ou Java : les APIs sont unifiés et on y trouve de tout en "standard", évitant d'avoir à se trimbaler des dépendances vers 15000 bibliothèques externes dont on n'est pas sûr de la pérénité dans le temps.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Pourquoi Office 12 ne supporte pas OpenDocument. Évalué à 2.
Je penses que MS comme SUN cherche à standardisé leurs formats respectifs pour "appater" des clients potentiels. Le logo "standard" étant vendeur.
Sinon pour le plugin on ne se comprend pas.
Sun a fait sa part de boulot en faisant le "plugin office" dans OOo.
Reste a M$ a faire la sienne avec le "plugin OOo" dans Office.
A la différence prêt que SUN avait un intérêt à supporter le format MS : utiliser les millions de documents existant dans ce format. MS n'a aucun intérêt à utiliser le format OOo. Si SUN croît que son format peut servir de standard d'interopérabilité et qu'il gagnerait à être supporter par MS Office, c'est à lui de le démontrer.
[^] # Re: C# et le libre...
Posté par TImaniac (site web personnel) . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 2.
elle est où l'option --gc dans le compilo ? :)
Oui, tu remarqueras que c'est exactement ce que je dis dans le post auquel tu réponds
Bah oué je confirmes mes doutes également c'est tout :) Mais comme quoi y'a bien des services qui sont propres aux environnement d'exécutions "managés" ;)
pas la compilation. C++ est beaucoup plus difficile à compiler que Java, par exemple.
Compiler Java n'est pas difficile, mais compiler Java en natif comme le fait GCC c'était visiblement pas évident puisqu'ils avaient l'air d'être tout fier de le faire et qu'ils sont le seul à le proposer...
Quant au bench que tu cites, c'est de la merde. Il faut vraiment être un âne (je ne parle pas de toi) pour utiliser des benchs qui tournent aussi vite et prétendre que c'est représentatif de quelque chose...
Autant pour comparer 2 langages je trouves effectivement que c'est de la merde généralement, autant pour comparer 2 implantations je vois pas en quoi c'est de la merde, sachant que le temps de 'lancement' n'est généralement pas pris en compte...
En tout cas les bench semblent refléter la réalité, il suffit de comparer gcc et le compilo d'intel par exemple pour voir qu'on retrouve bien graphiquement ce qu'on constate de manière empirique :)
L'intérêt, c'est l'occupation mémoire plus faible, la facilité de distribution, etc.
En fait GCJ est parti dans "Extra" me demande pas pourquoi...
http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...)
Ben même si ce sont des benchs de merde, visiblement l'occupation mémoire semble pas spécialement améliorée avec GCJ... Après faut voir sur une appli réelle et comparer... Mais bon des premiers tests de Eclipse sur Fedora que j'avais fais, question rammmage ca avait pas l'air d'apporter quoique ce soit :)
Quand à la facilité de distribution, je trouve que c'est plutôt un désavantage : le bytecode a l'avantage d'être portable, la phase de JIT est pour moi le meilleur compromis : tu distribues un seul binaire, et tu profites de l'exécution native.
[^] # Re: C# et le libre...
Posté par TImaniac (site web personnel) . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 2.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Pourquoi Office 12 ne supporte pas OpenDocument. Évalué à 0.
Des sources de ? Du fait que le format a était fait par Sun tout seul ? Ben pas vraiment de sources mais un constat :
Specif avant de rentrer à l'OASIS fait par Sun - Specif à la sortie de l'OASIS = aucune modification.
En gros les membres ont votés, et ils ont approuvé le format de Sun, sans rien toucher. Yahoo.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=o(...)
Sinon le plugin en question il ressemble tout betement a OOo. Ben oui OOo sait lire et ecrire les formats Office et Open Document. 100 % des fonctionnalites pour Open Document (logique) pour les formats Office je ne sais pas (donc je ne balance pas de chiffres) mais en ce qui concerne la lecture je constate qu'OOo me relit bien (pas parfaitement certes mais tres bien quand meme) les documents Office.
Ben vas-y fait le plugin, comme ca tous les utilisateurs d'office pourront enfin lire nos documents ODF qu'on fait sous notre OS libre.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Pourquoi Office 12 ne supporte pas OpenDocument. Évalué à 2.
Euh... le journal pointe une FAQ (Frequently != personne) :
Why is Microsoft offering a new standard, rather than simply supporting the file format for the Open Office product (sometimes called ODF)?
Donc si, des gens se demande pourquoi MS a besoin d'un autre format que ODF.
Ce qu'on lui demande est de pouvoir exporter/importer, out-of-the-box, le format ouvert ODT
Justement ce que j'ai voulu montrer : c'est pas possible. Aussi vrai qu'il n'est pas possible que OOo gère intégralement MS Office à moins d'être fonctionnelement identique. Je vois pas l'intérêt qu'à MS à supporter "partiellement ODF" sachant qu'il sera perpétuellement critiqué justement pour ce côté "partiel" (lié à l'ODF lui même, pas à MS pourtant). En refusant d'utiliser l'ODF, ils se démarquent du courant que veut faire passer Sun : "l'ODF est un standard". En n'incluant aucun support pour l'ODF, MS montre clairement son opposition à ce format. MS implémentera donc le support de l'ODF peut être un jour, non pas parcque c'est un standard, mais parqu'il y aura beaucoup de demande de la part de ses clients (comme ils le font pour le PDF qu'ils se décident à supporter face aux demandes)
Comme ca il est a peu pres sur que c'est ce format qui sera utilise et que Word conservera sa position "en avance"
Evidemment. Et Sun tu crois qu'il tente de faire quoi en "standardisant" l'ODF ? Exactement pareil. La décision de MS est donc tout à fait logique.
La rapidite ? c'est important pour le format par defaut qu'on utilise en interne mais ce n'est pas critique pour un format d'echange, qu'on utilise qu'a l'exportation.
Si l'ODT devenait un standard de fait (comprendre répendu), t'aurais d'un côté la suite MS Office qui se coltinerait à chaque fois la lecture puis l'écriture avec en permanence une conversion : résultat lenteurs permanente (je prends l'exemple con d'un document qui circule dans une boîte où ce n'est pas comme tu dis le format d'échange mais directement le document de travail). De l'autre côté t'aura la suite OOo qui gère nativement le format et qui sera clairement avantagé.
Le problème de l'ODF, c'est de vouloir faire d'un format de travail un format d'échange. C'est avantager exclusivement une suite Office, il est tout à fait normal que MS refuse celà.
Et pour un traitement de texte 99% des fonctionnalites courantes sont gerees a la fois par OOo et Office, et sont disponibles dans le format OOo.
99% ! Genre ! Et c'est moi qui suis de mauvaise foi. Alors pourquoi OOo ne gère pas intégralement le format XML Office 2003 qui est documenté ?
Pourquoi KOffice a de nombreux problèmes à gérer le format ODF ?
S'il y a des facilités entre OOo et MS Office, c'est uniquement parcque OOo essai de "copier" MS Office (fonctionnelement) contrairement à KOffice : si comme tu dis 99% des fonctionnalités étaient identiques, on aurait 2 produits identiques : quel es l'intérêt ? Chaque concurrent (Sun, KOffice, MS) ont besoin d'avoir une liberté pour innover, et pour cela il faut un format neutre qui soit un vrai format d'échange, bref qui ne soit pas le format de travail de OOo.
Sun a voulu imposer son format tout seul, bien, bah qu'il démontre qu'il est interopérable en écrivant un plugin à Word qui fait l'import/export.
[^] # Re: Obligé ?
Posté par TImaniac (site web personnel) . En réponse au journal Google Resiste aux US mais cede a la chine. Évalué à 5.
http://www.pcinpact.com/actu/news/26270-Censure-de-Google-en(...)
Citation :
La liberté d’expression n’est pas un principe accessoire, que l’on peut mettre de côté lorsqu’on opère dans une dictature. C’est une valeur reconnue par la Déclaration universelle des Droits de l’Homme et inscrite dans la Constitution chinoise
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Pourquoi Office 12 ne supporte pas OpenDocument. Évalué à 1.
Tu prends n'importe quel différence entre les 2 suites OOo et MS Office, ca te fait autant de problème potentiels dans les 2 formats (MS et ODF).
Un format interopérable doit être indépendant et reprendre les points communs, quitte à ne pas être aussi puissant que format dédié à chaque soft. Mais ca demande la création d'un vrai standard par les principaux acteurs.
De toute façon le format ODF ne pose pas de problème uniquement à MS, il pose aussi problème aux autres suite office, comme KOffice, qui ne peut supporter tout le format, ce qui en montre clairement les limites.
[^] # Re: compatibilité, performance, test
Posté par TImaniac (site web personnel) . En réponse au journal Pourquoi Office 12 ne supporte pas OpenDocument. Évalué à 4.
Forcement tu prends le cas extrême. Mais leur intention est bien d'intégrer dans Office 2000/XP/2003 des filtres d'import/export vers leur nouveau format.
Leur truc génial dont ils parlent, des feuilles de styles non définis par microsoft mais personnalisé, avec du xml, ça me rappelle quelque chose... ah oui, le XML et les feuilles de style...
Tu dis n'importe quoi. Ils ne parlent pas de feuille de style à aucun moment. Essaye d'utiliser InfoPath dans Office 2003, tu comprendras mieux après de quoi ils parlent.
* Donc pour rendre les choses plus rapides il faut parser du xml qui n'est pas du xml ? Ou bien faire un décompresseur/parseur plus performant, ou un format de compression adapté au logiciel ?
La manière dont est structurée un document XML influence énormément les performances des outils qui l'utilise. Si un grand nombre de transformations est nécessaire pour passer de la représentation XML à la représentation métier de l'appli, tu peux mettre un temps fou à charger les gros documents. Suffit de voir le temps nécessaire pour charger un document MS Office dans OpenOffice.org : non pas que OOo est mal codé et super lent, c'est juste que OOo doit "transformer" un format dans un autre.
Ce n'est pas une justification pour ne pas utiliser ODF, n'importe quel format peut être robust-testé.
Non mais c'est une justification pour utiliser
Techniquement parlant. Après il y a toujours l'aspect "je veux imposer mon format à moi le mien"
Il est à peu prêt normal qu'ils préfèrent choisir un format dont ils ont testé la robustesse dans leurs applications à eux (donc entre autre testé en interne) que de se baser sur un truc nouveau inconnu pour eux. OOo fait exactement pareil en utilisant leur propre format : ils le maîtrise et c'est stratégique.
[^] # Re: Refus de vente?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Microsoft "vend" son code source. Évalué à 7.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Pourquoi Office 12 ne supporte pas OpenDocument. Évalué à 2.
Euh... t'as lu mon post en entier ? L'ODF est étroitement lié aux fonctionnalités de OOo. Il n'est donc pas adapté à servir de standard d'interopérabilité. Sun a tout à fait le droit d'avoir ce format, c'est même ce que je préconise, OOo doit avoir un format supportant toutes les fonctionnalités d'OOo. Mais qu'on arrête de l'appeler "pompeusement" standard tout en y trouvant un gage d'interopérabilité avec d'autres suites Office qui n'ont pas les mêmes fonctionnalités.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Pourquoi Office 12 ne supporte pas OpenDocument. Évalué à 1.
# mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Pourquoi Office 12 ne supporte pas OpenDocument. Évalué à 1.
Faut bien voir que les formats des suites offices ne sont pas des formats d'échanges de données "génériques". Les formats sont étroitement liés aux fonctionnalités des softs pour lesquels ils sont créés. Créer un filtre de transformation d'un format dans l'autre sera forcement imparfait et des informations seront forcement perdues.
Vu à quoi ressemble d'ODF, il aurait été idiot pour MS de le supporter natif. (un filtre import/export je dis pas). Comme il aurait été idiot que OOo utilise le format de MS en natif (au risque d'avoir un clone fonctionnel sans possibilité d'innovation).
L'idée serait peut être de réfléchir à un format d'interopérabilité (un vrai, pas ODF), qui soit assez relativement générique, et où les éditeurs de suite Office seraient réellement impliquées. Bref un format qui ne permettent pas d'avoir une compatibilité à 100% des fonctionnalités, mais qui permette au moins d'échanger un contenu, en laissant chaque acteur faire évoluer son propre format (et donc évoluer les fonctionnalités de leurs softs).
[^] # Re: Obligé ?
Posté par TImaniac (site web personnel) . En réponse au journal Google Resiste aux US mais cede a la chine. Évalué à 7.
Je dis pas que ce que fais Google est anormal, il respecte les lois chinoises et c'est très bien. Mais bon je penses pouvoir affirmer sans me tromper que la pratique de la censure telle qu'elle est pratiqué là bas relève plus du non respect des droits de l'homme que d'autre chose. D'où le fait que j'en conclu que Google préfère se plier au règles du "marché" potentiel chinois que d'avoir un peu d'éthique, quitte à laisser passer un marché juteux.
Parmis tes choix :
1 - le premier est éthique et respecte leurs lois.
2 - pas possible, ils deviennent hors la loi.
3 - respecte les lois mais pas éthique.
Contrairement à ce que tu penses, je trouve le dernier choix comme moins respectable que les 2 autres.
[^] # Re: Obligé ?
Posté par TImaniac (site web personnel) . En réponse au journal Google Resiste aux US mais cede a la chine. Évalué à 10.
# si y'a que ca qui te gène
Posté par TImaniac (site web personnel) . En réponse au journal Pourra-t-on encore vivre sans .exe ?. Évalué à 4.
[^] # Re: C# et le libre...
Posté par TImaniac (site web personnel) . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 0.
[^] # Re: C# et le libre...
Posté par TImaniac (site web personnel) . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 4.
http://msdn.microsoft.com/library/default.asp?url=/library/e(...)
C'est pas bien compliqué de faire en sorte que l'installeur effectue cette opération.
[^] # Re: On peut donc en conclure...
Posté par TImaniac (site web personnel) . En réponse au journal Zéro et des poussières.... Évalué à 7.
[^] # Re: C# et le libre...
Posté par TImaniac (site web personnel) . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 2.
Il y a aussi des optimisations liées à la machine cible : en C "standard", il faut choisir les optimisations (386, 686, etc.) et filer autant de versions, avec un compilateur JIT, celui-ci peut déterminer "à la volée" les optimisations éventuelles.
Contrairement à ce que raconte Timaniac, il est bien entendu parfaitement possible de faire du garbage collecting sans utiliser de VM, de même que de la reflection, etc
Eh oh j'ai jamais dis ca :) Il y a bien des GC pour C++ par exemple. Comme il y a des possibilité de reflection également en C++ avec certains outils. Mais c'est pas en standard dans le langage. Et pour la sécurité (les AppDomain par exemple), j'ai beaucoup plus de doute sur la faisabilité (mais bon ca doit pouvoir se faire). Un environnement d'exécution comme Java ou .NET/Mono propose ces services en standard, et potentiellement pour tous ceux qui ciblent le code intermédiaire de ces VM. La VM constitue plutôt l'ensemble d'instructions "imposées" qui permet de contrôler et d'obtenir un certain nombre de garanties à l'exécution du code natif résultant.
En fait, beaucoup de gens (comme Timaniac) confondent runtime et VM.
J'ai pourtant tenté d'expliqué que la VM n'était qu'une "vision" du programmeur, et qu'à l'exécution c'était kif kif bourriqot. D'ailleur je parles dès que possible d'"environnement d'exécution", plutôt que de VM.
Ceci dit, comme le montre l'exemple de GCJ, compiler nativement un langage comme Java ne pose pas de problèmes particuliers.
Euh ca fait quand même un moment qu'ils courraient après ;)
Et puis au final un bout de code compilé avec GCJ tourne généralement moins vite qu'un bout de code tournant sur la JVM de Sun donc bon l'intérêt... Cela dis ca reste utile pour faire du JIT sans aucune interprétation.
(désolé pour les sources, mais http://shootout.alioth.debian.org/debian/ ne tient plus compte de GCJ, me demande pas pourquoi)
[^] # Re: C# et le libre...
Posté par TImaniac (site web personnel) . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 2.
Un émulateur serait plutôt ce qu'on appelle un "interpréteur" : il lit bêtement à la suite les instructions de la machine virtuelle, les interprêtes, et les exécute. C'est ce qui se passe par exemple avec l'interprêteur Perl. C'est comme ca que fonctionnait les JVM initialement. Maintenant l'environnement d'exécution "compile" le bytecode en code natif avant de l'exécuter.
Donc il existe une manière de compiler du .NET en natif ? (comme avec gcj ?)
.NET a été conçu pour être compilé dès le départ, c'est donc assez naturelle. sous Mono ca donne :
mono --aot monprog.exe
Pour java c'était plus compliqué, vu que ce n'était pas conçu pour dès le départ. La plupart des JVM mixait donc du JIT et de l'interprétation. GCJ a démontré que c'était cependant possible de tout compiler avant.
[^] # Re: C# et le libre...
Posté par TImaniac (site web personnel) . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 3.
MS doit supporter plusieurs architectures matérielles : x86, x64 plus les proc de PDA/smartphone (ARM, etc.) L'indépendance vis-à-vis d'une plateforme matérielle est donc bien un but recherché par MS.
- langages de haut niveau comme c#/delphi.NET/<votre_langage_favori> avec garbage collector, programmation fonctionnelle & co... (il existe déjà des langages compilés qui font tout ça, cf OCaml. Au pire il suffirait de coder un frontend c# pour gcc => pas besoin de VM non plus !)
Faut bien voir que la VM n'est qu'une "vision", une sorte d'abstraction pour les programmeurs et compilateurs. Mais à l'exécution tout ca est compilé en code natif (JIT), voir même avant (AOT), bref après ca marche comme OCaml ou du code compilé avec gcc. Faut bien voir que gcc propose intrinsèquement la même architecture avec un code intermédiaire entre le frontend et le backend (commun à tout le monde). La différence c'est que gcc n'offre pas (ou très peu) de services supplémentaires (à l'exécution). S'il y a des différences de perf, c'est pas lié à la présence du code intermédiaire pour la VM, mais justement aux services associés : GC, sécurité, reflection, etc. Après tout est une question d'objectifs. Si les VM ont du succès aujourd'hui par rapport à hier, c'est que les services qu'elles offrent sont plus intéressant que les pertes de performances qu'elles engendrent (avant c'était trop pénalisant, aujourd'hui ca peut le rester dans des parties critiques).
Donc en gros, pourquoi l'avenir de l'informatique passerait t-il forcément par un dispositif avec une machine virtuelle ?
Pour l'ensemble des services qu'elles offrent, qui permettent de gagner en productivité.