ODF n'est pas un format d'échange, c'est un format bureautique.
L'un empêche pas l'autre. C'est pas moi qui le dit, c'est l'OASIS : "A standard for office document processing and interchange will be of great utility to many users and software companies developing applications, and should be made available as soon as possible."
Et pourtant OOo, MS-Office, etc savent exporter et importer du html
Toute la nuance est justement dans ces opérations d"'import/export" qui montre clairement qu'il y a perte d'information (et en l'occurence non négligeable).
Es-ce que SVG doit être compatible avec AutoCAD, VISIO ou metafile de Windows ?
bah non, c'est pas le but d'un format d'échange :)
Et tu entends quoi par format d'échange ?
Qu'on soit en phase : je ne considère pas du tout qu'OOXML est un format d'échange.
Pour moi un format d'échange est un format qui sert à "échanger" des informations structurées entres applicatifs. Cela suppose que le format est clairement défini et ne contient pas de portes ouvertes à tout et n'importe quoi comme données externes comme les proposent ODF ou OOXML.
Es-ce que le w3c a pourri sa norme html car il y a des millions de page web conçu pour EI6 ?
La différence c'est qu'HTML est conçu par un organisme indépendant et le format existe indépendamment des applicatifs. ODF a été conçu pour supporter les informations d'OOo et OOXML celles d'MSOffice. Le premier se défini pourtant comme un format d'échange, le 2ème non.
ODF ne remplace pas ou ne concurrence pas de standard.
ODF reprend ce qui est déjà standardisé.
Si : ODF suppose l'implémentation d'une JVM, hors une norme ISO concurrente existe, je te laisse deviner laquelle ;)
ODF n'est pas conçu pas et pour un boite.
Non effectivement, elle est conçu pour 2 boîtes ;)
ben c'est les oignons de MS. Ce n'est pas de la faute à ODF. Et en passant, MS participait aux débuts de ODF. Mais MS s'est barré.
Faut vraiment être de mauvaise foi de ne pas y voir des conflits d'intérêt entre IBM, Sun et MS.
OOXMlL n'est pas un format d'échange meilleur que ODF et ici la faute en revient exclusivement à MS.
Mais MS ne prétend pas que c'est un format d'échange, il est clairement présenté comme un format permettant de migrer des documents écrits pour MS Office.
Il y a plein de truc que supporte ODF et que ne supporte pas OOXML.
Oué bah oué.
Enfin des commentaires censés, merci ;) C'est dans les critères de l'ISO : pour un même domaine, il ne faut qu'une spèc.
Ben étant donné que les 2 formats ne répondent pas au même besoin, j'ai envie de dire que ce ne sont pas les mêmes domaines ;)
La raison est simplement pour pourrir la standardisation de format bureautique vers un format vraiment ouvert (et non à la botte de MS).
Le problème c'est que Sun et IBM ont déjà pourri la standardisation en proposant l'ODF sachant pertinement qu'il ne remplissait pas son objectif affiché : être un format d'échange.
Par exemple Adobe "doit" faire un conversion PDF => ODF.
C'est débile :) Ces 2 formats ne représentent absolument pas le même type d'informations...
Vu les objectifs ISO, c'est un non sens de ratifier OOXML.
Je suis d'accord, comme c'est un non sens d'avoir ratifié l'ODF...
tu as pas du tout comprendre ce que dit la FSF Europe je pense...
Venant d'un type qui sait même pas ce que veut dire "représenter une information" au sens informatique, ca me fait doucement rire...
La FSF parle de la conversion Microsoft oxml vers ODF qui ete rendu volontairement difficile par microsoft (d'apres ton lien).
Elle est pas rendu difficile, elle est par nature IMPOSSIBLE. (on peut évidemment obtenir un certain niveau de transformation mais forcement incomplet).
Toi tu parles de la conversion des formats MS Office 97 -> MS Office 2007
Cites pas n'importe quoi. Je disais clairement qu'ODF ne permettait pas de représenter toutes les informations que permet de représenter l'OOXML. C'est exactement la même chose que dit la FSF.
Alors s'il te plait tente de rester coherent soit tu dis que microsoft oxml a ete cree pour avoir un "rendu" parfait des documents de MS Office 97 a 2007
Oui il a été créé dans ce but. C'est évidemment pas exempt de défaut, mais l'OOXML a ce but et permet de convertir la plupart des documents sans problème. L'ODF est beaucoup moins bon pour faire cette tâche.
Ce qui est hallucinant c'est que même les détracteurs de l'OOXML ont pour la plupart fini par admettre que l'OOXML n'avait pas le même but et les mêmes possibilité que l'ODF. C'est justement cet argument de l'objectif qu'ils utilisent maintenant pour justifier un non passage à l'ISO.
"OpenXML was designed from the start to be capable of faithfully representing the pre-existing corpus of word-processing documents, presentations, and spreadsheets that are encoded in binary formats defined by Microsoft Corporation. The standardization process consisted of mirroring in XML the capabilities required to represent the existing corpus, extending them, providing detailed documentation, and enabling interoperability."
Est-ce que tu peux comprendre que y'a des utilisateurs qui ont envie d'avoir autre chose qu'un format binaire tout en conservant au maximum l'intégrité de leur base documentaire existante ? (cas de la British Library) OOXML répond à ce besoin, l'ODF non, car il n'a pas été conçu pour.
Comme disait albert, pour l'odf ca te gene, mais pas pour le ooxml.
Je dis pas que c'est mieux ou moins bien, je dis que c'est PAREIL.
Si tu veux une réponse : pour un format qui se veut un format d'échange ca me gène. Pour un format qui se veut un format compatible avec la majorité des documents offices existant, ca me gène moins parcqu'il y a une bonne raison : la compatibilité. Pour le format d'échange, il n'y a aucune raison, c'est même parfaitement contradictoire avec l'objectif.
euh il répondait juste à une affirmation SANS FONDEMENT de ta part.
\o/ Vous êtes trop fort pour moi.
Avant de retourner la question, et de demander des preuves. Commence par prouver TOI tes premières affirmation.
Ben en tout cas la FSF Europe est d'accord avec moi : http://www.fsfeurope.org/documents/msooxml-converter-hoax.fr(...)
Visiblement il n'ont pas senti le besoin de prouver quoique ce soit vu que tout le monde est d'accord sur ce point (sauf vous bien entendu).
Ben oui koffice, meme si il ne supporte pas encore toute la norme, utilise ce format pour stocker ses documents (donc en lecture et en écriture).
On me souffle dans l'oreillete qu'abiword le supporte aussi.
Mais pas entièrement comme tu le précises très bien. Parcque justement l'ODF est fortement lié aux fonctionnalités d'OOo. CQFD.
Donc ton affirmation sur H264 obligatoire pour avoir ODF est fausse.
Ce que je voulais dire c'est qu'il est impossible de lire tout type de document ODF car le format est trop "ouvert". T'as très bien compris ce que j'ai voulu dire.
Pour le moment aucune preuve n'a ete faite sur le sujet.
Allez gros malin, je vais arrêter de tomber dans ton piège à la con, et je te retourne la question : prouve moi que l'ensemble des informations que propose de représenter le format OOXML à travers ses 6000 pages de specs sont transcriptlbles dans le format ODF (auquel cas effectivement l'OOXML n'a pas de raison d'exister).
bon courage ;)
Rq: J'ai un peu change ta phrase car ODF ne represente rien, c'est le logiciel ouvrant le fichier qui represente.
\o/ Alors là t'es vraiment foet, tu comprends pas ce que je dis, donc tu changes mes propos... Joli.
En informatique, on utiliser souvent l'expression "représenter quelquechose" comme désigner la façon de "coder" une information de façon à pouvoir l'interpréter.
Exemple : comment "représenter" un titre dans le langage HTML ? (réponse : utiliser la balise "title").
Bref, il n'y a pas que la représentation "graphique" : un format comme OOXML ou ODF décrit la façon de "représenter" des informations (utiles pour les applications qui les utilisent) dans un fichier.
c'est une norme pour "representer des documents office" ce qui est legerement plus general.
Ca c'est la théorie des bisounours. En pratique c'est utilisé pour représenter les documents Office d'OOo.
ODF a toujours ete prevu en plusieurs etapes.
Pourquoi pas, mais dans ce cas on laisse pas la possibilité de mettre des formules dans un document si on n'indique pas comment l'interpréter !
Là l'objectif était clairement de sortir un truc le plus rapidement possible, un truc qui permette à OOo d'utiliser le format en natif, quitte à mettre de côté certains aspects. Affirmer que c'est pour proposer un format d'échange et d'interopérabilité, c'est malhonnête. L'objectif est de supporter OOo, et d'améliorer au fur-et-à-mesure. Dans un vrai format d'échange et d'interopérabilité, c'est les applications qui s'adaptent au format, pas l'inverse.
tiens c'est rigolo ce genre de "remarque" c'est recent dans les trolls sur ODF/microsoft OXML ca date meme que de la semaine derniere...
C'est ironique ? Non parcque j'en ai parlé y'a bien plus longtemps.
Premierement tu vas nous pointer une page precise dans la description de ODF pour le fait d'inclure H264.
Bah grosso merdo dans un document ODF tu peux inclures n'importe quel type de media, donc pourquoi pas une vidéo H264. Si je fais un document avec une telle vidéo dedans, comment tu fais pour le relire si sur ton PC ton application ne supporte pas ca ?
Regarde page 303 dans la spec, il est fait référence à un système de plugin pour pouvoir ajouter tout et n'importe quoi comme player... Tu trouves ca normal ce genre de porte ouverte à tout et n'importe quoi dans un format qui se veut un format d'échange et d'interopérabilité ?
Question contenus binaire, l'ODF ne se cache même pas, tiré de la doc :
"As XML has no native support for binary objects such as images, [OLE] objects, or other media
types, and because uncompressed XML files can get very large, OpenDocument uses a
package file to store the XML content of a document together with its associated binary data, and
to optionally compress the XML content."
Deuxiemement tu vas aussi nous expliquer comment tu vas lire les objets binaires inclus dans microsoft oxml
Puisqu'il faut que je le répète une fois de plus : je cherche pas à montrer qu'ooxml est mieux ou n'a pas ces défauts, je montre juste qu'ODF a les mêmes types de problème, par nature : c'est un format de travail d'une suite bureautique existante : OOo. Par nature ce format n'a pas pour but l'interopérabilité ou l'échange, mais le support des fonctionnalités qu'à décider Sun et IBM (OOo donc).
tu vas m'expliquer l'interet d'avoir une norme redondante si elle n'apporte strictement rien que ce soit niveau proprete ou autre.
Forcement, quand on se documente pas, on risque pas de trouver des différences. l'OOXML supporte la représentation de la plupart des informations nécessaire à décrire un document pour les suites MS Office 97 -> MS Office 2007, ce que ne permet pas l'ODF. En soit ca justifie largement son existance, comme le rappel l'article référencé sur le site d'IBM.
oui je prefere qu'ils aient pris leur temps plutot qu'avoir des erreurs grossieres mathematiques
Et pourquoi n'auraient-ils pas pu prendre leur temps tout court pour pondre la norme ODF ? Pourquoi ne pas avoir attendu qu'OpenFormula se face tranquillement pour pondre ODF ? Non le but était d'avoir le label "ISO" le plus vite possible pour l'utiliser comme argument marketing.
Les bons observateurs auraient dû s'insurger dès le départ sur l'absence de critique sur la standardisation de l'ISO.
=>
Les bons observateurs auraient dû s'insurger dès le départ sur l'absence de critique sur la standardisation de l'ODF à l'ISO.
OOXML n'est pas un format ouvert (suffit d'en lire les specs: il manque des parties, il reste des morceaux en binaire - dans du XML! - et il y a des tas de références de compatibilité avec les comportement d'anciens produits M$, par exemple pour l'affichage du "é" à-la word 2.0 !).
Mais personne ne dit qu'OOXML est parfait ! Juste qu'ODF est pas mieux. A lire les specs d'ODF, il faudrait implémenter une JVM, un décodeur H264 et j'en passe. Sans parler des manques flagrant de specs (il n'y a pas de liste exhaustive des formats d'image qu'on peut inclure, JPG, SVG, autre ?) Niveau binaire et conneries, c'est pas beaucoup mieux.
Every line of code that is written to our standards is a small victory; every line of code that is written to any other standard, is a small defeat. Total victory, for DRG, is the universal adoption of our standards by developers, as this is an important step towards total victory for Microsoft itself: “A computer on every desk and in every home, running Microsoft software.”
Mais c'est exactement le même combat de tous les acteurs du secteur, à commencer par IBM et Sun : il faut mieux maîtriser les formats et les faire standardiser, on peut ainsi maîtriser nos produits et leurs évolutions, que de se mettre en retrait avec un temps de retard en implémentant le format "standard" des concurrents.
Pourtant l'auteur prend bien la peine d'écrire, dès le début, qu'il n'est pas affilié ni ne travaille pour IBM.
"Mis en avant par IBM" si tu préfères :) Ca change rien au contenu.
Ce n'est pas la compilation des milliers de strates de bugs d'Office qu'est la spec OpenXML...
Faut pas exagérer non plus, OpenXML ce n'est pas "que" ca. D'ailleur une des propositions qui a été faite et uqi n'est pas exclu, c'est de séparer ce qui est "clean" des trucs "legacy".
Que l'ODF soit mieux conçu parcque faisant plus ou moins table rase des problèmes de compatibilité qu'a MS avec ses vieux formats, on est d'accord, qu'il se focalise sur la description du contenu, on est d'accord, mais ca change rien au contenu : le contenu est fortement lié aux fonctionnalités de l'appli qui l'utilise, et l'ODF n'a pas été conçu pour représenter un contenu "générique" indépendant de toute fonctionnalité, il est fortement couplé aux fonctionnalités d'OOo tout comme l'est OpenXML avec MS Office.
OpenXML ne devrait pas être ISO, certes, mais ODF n'auraient jamais dû l'être si on s'en tient aux mêmes objectifs que l'article que tu as cité : un format d'interopérabilité et d'échange. Etant donné l'importance de l'impact "commercial" d'un tel label, il serait malhonnête de certifié l'un et pas l'autre, quitte à modifié l'OpenXML pour sortir les trucs "crades" et "legacy".
Le problèmes de ceux qui critique une éventuellement standardisation par l'ISO de l'OpenXML, c'est qu'en ommettant systématiquement de remettre en cause la standardisation de l'ODF, ils affichent clairement leur cheval de bataille : donner un avantage à tel ou tel acteur plutôt qu'à tel autre. Les bons observateurs auraient dû s'insurger dès le départ sur l'absence de critique sur la standardisation de l'ISO. Mais ca arrangeait tout le monde (sauf MS).
Cet article d'IBM est très juste, il décrit bien le pourquoi de l'existance de l'OpenXML et en quoi il ne résoud pas le problème d'interopérabilité. La conclusion d'IBM, c'est qu'OpenXML ne peut être un standard (sous-entendu ISO).
Le soucis, c'est qu'il n'explique pas pourquoi la question ne s'est pas posé pour l'ODF, qui était loin d'être exempt de défaut, et même s'il est plus "clean" que l'OpenXML (beaucoup moins de conneries liées à la compatibilité avec les formats du passé), il n'est pas non plus une réponse à l'interopérabilité pour les mêmes raisons : il est fortement lié aux fonctionnalités d'OOo qui reste l'implémentation de référence (et c'est pas les autres implémentations qui vont montrer le contraire...).
Si l'ODF est passé ISO, c'est pas pour la beauté d'avoir un format interopérable, c'est avant tout pour avoir un label à présenter aux gros clients (administrations) et mettre en avant les solutions de Sun/IBM face à MS Office.
Si l'ODF a eu le droit à cette certification, il n'y a pas beaucoup de raison d'empêcher l'OpenXML de ne pas l'avoir (sans pour autant dire qu'il faut qu'il le soit tel quel).
Le seul format d'interopérabilité qui pourra exister ne pourra être qu'un sous-ensemble des formats utilisés par les principaux produits du marché. Ce format ne pourra pas être le format de "travail" permettant d'exploiter toutes les fonctionnalités d'une appli, mais sera plutôt un format d'échange sur un mode "Import/Export", utile lors des migrations par exemple. Ce format ne pourra pas exister sans l'engagement des différents acteurs du marché, et dans un objectif commun de créer un format d'échange (et non de travail).
Parcqu'une application de bureautique dépend fortement du format utilisé : il faut s'assurer que toutes les informations manipulées par l'application sont sauvegardées pour être rechargées.
ODF aussi complet soit-il ne couvre pas l'ensemble des fonctionnalités de MS Office, MS ne peut donc pas se contenter de ce format : ils leur faut un format "natif" à l'application.
Le couple Application<>Format étant tellement important ils doivent également utiliser leur propre format pour :
- Assurer la compatibilité avec les documents existant (les documents enregistré dans le vieux format .doc doivent pouvoir l'être dans un nouveau format sans perte d'information)
- Maîtriser les évolutions de leurs produits
Si OpenXML existe, c'est du fait de la demande croissante des utilisateurs (notamment administrations) d'avoir un format "ouvert" et documenté, sous la pression de SUN et IBM qui ont montré les avantages d'un tel format avec OOo et l'ODF.
Dans ce cas, tu redémarres le programme incriminé (qui a dit firefox ? :p), pas le système entier...
Evidemment si t'es un geek !
Mais madame michu, tu vas pas lui demander d'ouvrir la fenêtre qui liste les process, de lui demander de matter de temps en temps quel appli bouffe de la ram pour lui conseiller de redémarrer là dite appli...
Ca c'est n'importe quoi !
Le seul conseil "générique" et applicable par n'importe quel utilisateur reste de "redémarrer" une fois de temps en temps.
Faut arrêter un peu la mauvaise fois là...
T'es con ou quoi ? J'ai justement écris juste avant :
"Certaines mises à jour nécessite un reboot."
Faut arrêter de faire semblant de pas comprendre en jouant sur la forme alors que tout le monde a compris ce que j'ai dis.
et la différence est donc dans la nécessité de _devoir_
Y'a aucune nécessité. Tu fais ce que tu veux.
Bon, faut encore une andouille pour contre-balancer la mauvaise foi, donc je m'y colles : Delete programs you never use
Un programme que je n'utilise pas, ne doit pas ralentir ma bécane. Il y a des tonnes de programme que je n'utilise pas sur ma bécane.
Il y a une différence entre "je ne l'utilise pas" et "il bouffe des ressources quand même".
Même si on n'utilise pas un programme, il utilise des ressources :
- espace disque
- processeur (certains programmes tournent en tâche de fond)
- mémoire (certains programmes tournent en tâche de fond)
Clean up your hard disk
Plus les disques sont utilisés et plus c'est lent...
C'est la notion de "scalability" de Windows ?
Plus un disque est plein, plus les fichiers deviennent fragmentés sur le disque et limite les perfs du système en conséquence. Y 'a pas de miracle.
Run fewer programs at the same time
Retour à MS-DOS.
Le problème est identique sous tous les OS.
Restart regularly
Poilant de rire.
Encore une fois, ce problème est similaire sous Linux : tu peux très bien avoir des programmes avec une légère fuite mémoire par exemple qui vont poser dégrader les perfs globales au bout d'un certain temps.
Restart your PC at least once a week
Mort de rire.
Certaines mises à jour nécessite un reboot. Sous linux aussi. Ne pas rebooter une fois de temps en temps sur un poste client c'est potentiellement s'exposer à des problèmes de sécurité.
Check for viruses and spyware
J'ai jamais fait ça sous Linux en 10 ans d'utilisation.
Quelqu'un a essayé ça sous Linux ? On y gagne en performance ?
C'est la rançon du succès.
Disable services you don’t need
Ce conseil sur slashdot ne m'étonnerait pas...
Ce serait un conseil de sécurité, il serait bienvenu.
Mais pour accélérer une bécane...
Un service qui s'exécute bouffe de la RAM et parfois du CPU.
Mais je suis bien d'accord, IE est une merde et n'aurait jamais du "tolérer" ce genre de page web, mais le fait est que beaucoup de sites sont comme ca à l'heure actuelle. Et MS ne peut pas se permettre de casser la compatibilité comme ca pif paf poum de manière arbitraire.
D'ailleur Firefox est aussi laxiste sur ce point là, et pour les mêmes raisons de compatibilité avec l'existant.
Ben vi, c'est vrai au lieu de forcer les dev à faire correctement on rajoute encore une couche... pitoyable !
Et tu proposes quoi à part forcer les développeurs ?
Sérieux c'est débile, t'as vu le nombre de site web sur internet ? je met ma main à couper que 90% d'entre eux ne respectent pas les standards, tu voudrais que MS casse la compatibilité avec tout les sites tout ca par "respect" pour les standards ??
Ben oui, il y a la solution du doctype mais les dev win sont trop con pour l'utiliser donc on choisi autre chose.
C'est quoi cette argumentation de merde, on insulte les développeurs qui essaient de faire des sites qui marchent avec le navigateur qui a les 3/4 du marché ?
Mais avec un tel raisonnement, pourquoi ça changerait puisque ce qu'ils font marchera d'office sous ie 6-7-8 ?
Bah tous les nouveaux sites pourront être fait en suivant les standards, le développeur y aura intérêt puisqu'il pourra partir du principe qu'il n'aura qu'un seul site à développer pour Opera/Firefox/IE/Safari.
Donc comme d'hab, ils vont mettre en place des standards, personne ne saura qu'il faut mettre la balise meta
Pourquoi les développeurs l'ignoreraient ?
sinon ils metterait déjà correctement la balise doctype et il n'y aurait pas ce problème
Comme indiqué par la team IE, le problème vient du fait que beaucoup d'entête de document HTML sont générés automatiquement par des softs (Dreamwaver & co). Effectivement c'est du laxisme.
Quand tu comprendras que forcer les développeurs à migrer tous leurs sites existant (ce qui est tout bonnement innimagineable) n'est pas répondre à leurs attentes... Respecter les standards n'est pas une finalité en soit, c'est un outil pour faciliter la vie des développeurs. MS offrent le choix au développeur d'utiliser l'outil qu'il veut selon ses besoins.
et de deux que tout le monde s'en branle et donc ça ne sert à rien
Bah non on pourra enfin faire un site sans se soucier du navigateur (pour le HTML en tout cas, avec le javascript c'est pas gagné), ce dont de nombreux développeurs ne se branlent pas tellement ils passent du temps.
PS : je te rappelle que Firefox ou Safari ne sont pas full w3c-compliant, et qu'ils s'adaptent également aux sites existant, c'est ce qui fait aussi leur succès... Pourquoi tu ne les critiques pas de la même manière ? Ils pourraient systématiquement afficher un message d'erreur si une page est pas w3c-compliant !
pourquoi ne pas utiliser le doctype plutôt que meta ? ça résoudrait la plupart des problèmes non ?
Ben justement non. C'était la solution choisie dans IE7, manque de bol les développeurs mettent leurs DOCTYPE n'importe comment, et des pages qui se déclarent comme respectant tel ou tel standard était en fait toujours codé pour IE6 : résultat IE7 affiche incorrectement de sites qui marchait sous IE6.
Du coup là ils choisissent une autre technique, celle de la balise meta, qui a très peut de chance d'être déjà utilisée sur le web.
Mais bon, comme d'hab, ms a systématiquement peur d'aller en avant, d'oser casser un peu la compatibilité.
C'est pas une question d"oser", c'est juste une solution de transition qui permet de supporter les anciens sites tout en laissant la possibilité aux nouveaux sites d'être w3c-compliant. Bref tout le monde est content.
je viens de lire le lien que tu pointes, c'est de la mauvaise foi total mais surtout des problèmes incommensurables aux développeurs web !
Ca va être quoi le problème pour les développeurs web ? Supporter les standards va les faire chier ? Rien ne les obligera à utiliser ce mode ! Ce mode est prévu pour ceux qui veulent coder leur site en respectant les standards et ne souhaitant pas faire plusieurs versions de leur sites pour différents navigateurs, où est la mauvaise idée ?
De plus ceux que ca fait chier, rien ne les obligeras à utiliser ce mode, IE8 restera compatible avec les rendus de IE7 et IE6, donc pourquoi critiquer cette initiative ?
Tu proposes quoi sérieusement ? Que IE8 ne propose que le support strict des standards et soit incappable d'afficher correctement tous les sites qui ont été fait pour les versions précédentes de IE ? Ou plutôt que IE8 soit toujours aussi pourri au niveau des standards pour continuer à gueuler sur MS ?
Naïf de quoi ?
De croire que IE8 va améliorer le support des standards du W3C dans ce navigateur ? Je penses pas être naïf, ca serait juste complètement stupide et mauvais pour l'image de MS que de ne pas améliorer ce point, surtout qu'il est annoncé comme étant un objectif.
Je prétend pas que ca va être parfait, je dis que ca sera sûrement mieux, tout comme ie7 est mieux que ie6.
La solution choisie, à savoir proposer un mode n'ayant pas à se soucier de gérer la compatibilité avec l'existant laisse penser qu'ils peuvent quelque chose de pas trop mal. Si on prend tous les autres formats du W3C implémentés par MS, la compatibilité avec ces standards est plus que bonne (SOAP, XPath, W3C Schema, XSLT, etc.), ils peuvent tout à fait faire pareil avec IE8.
On dirait que ca vous fait chier à l'idée que MS respecte un peu mieux les standards.
Disons que Monad (powershell) était initialement planifié pour débarquer dans Vista par défaut, finalement ils ont préféré le distribuer séparement. Il est par contre dans Windows Server 2008 par défaut, ce qui correspond probablement plus au public visé : les administrateurs.
En fait en Python c'est pareil qu'en Java ou C# :)
Les types immutables en Python sont grosso modo là pour cacher ce que les types primitifs cachent en Java ou les types valeurs en C#. (c'est un racourci mais ca suffit pour ce qui nous intéresse).
Dans la sémantique exprimée par le langage Python, cela donne effectivement l'impression qu'il y a création d'un nouvel objet à chaque manipulation. En réalité l'interpréteur fait la même chose qu'en C# ou Java, à savoir des opérations sur des valeurs. L'objet est justement immutable pour cacher cette optimisation.
Si un entier était modifiable, il devrait être référencé en permanence par un "pointeur" (comme les autres types qui sont manipuler à travers un pointeur/adresse en interne), ce qui nécessite un intermédiaire : il faut faire un accès à une adresse mémoire pour obtenir le pointeur puis un autre accès mémoire pour accéder à la valeur référencé par le pointeur, ce dernier accès étant plus lent car effectué dans une autre partie de la mémoire. Si t'es dans une opération de type a = b + c, faut faire 3 fois ce boulot !
Je sais pas si je suis clair :)
Par contre ce que je dis là n'est pas vrai pour les types immutables qui ne sont pas "optimisés", cad qui ne cache pas des manipulations de valeur. Par exemple le type String.est en Java, C# ou Python un truc "immutable", il n'est pas pour autant utlisé en tant que valeur mais en tant que référence, pour la simple et bonne raison que la valeur contient beaucoup de données (plusieurs caractères) et de taille variable : les passer par valeur d'une méthode à une autre par exemple nécessiterait systématiquement une copie de l'intégralité des données, c'est moins coûteux de passer uniquement la référence (qui elle est stockée sous la forme d'une adresse).
Si ces types sont immutables, ce n'est pas cette fois pour cacher une optimisation du type manipulation de valeur à la place de manipulation de référence. C'est plus pour éviter au programmeur de faire n'importe quoi en manipulant le contenue d'une chaîne.
Du coup là par contre ca peut devenir très couteux de faire des opérations sur des chaînes de caractères, style :
string a = "rezzef"
a += "suite"
a += "suite2"
a += "ligne3"
Là effectivement il y a création systématique d'un nouvel objet pour stocker le résultat de la concaténation, ce qui est coûteux.
Des langages comme C# ou Java propose des classes qui cachent des chaînes de caractères "modifiables" quand c'est nécessaire (typiquement pour l'exemple ci dessus) :
StringBuilder sb = new StringBuilder("rezzef")
sb.Append("suite")
sb.Append("suite2")
sb.Append("ligne3")
string res = sb.ToString()
Dans cet exemple l'objet sb n'est pas immutable, et les appels successifs à la méthode Append modifie le contenue de la chaîne de caractère qui est stockée en interne (probablement dans un tableau de caractère), le dernier appelle permet de recopier le contenu dans une "string" classique.
Tiens d'ailleur à ce propos, la team IE vient d'annoncer un chamboulement pour IE8 : va enfin y avoir un mode respectueux des standards. Le mode proposé par IE7 (à savoir améliorer le support des standards mais en cassant la compatibilité avec certains sites) n'ayant pas convaincu, il change de stratégie : l'ajout d'une balise meta particulière permettra au navigateur de passer dans un mode visant à respecter au mieux les standards du W3C. Bref, une bonne nouvelle.
En fait en C# il y a les types objets "valeurs" et les types objets "références".
En l'occurence un int est un type valeur. Donc concrêtement dans l'exemple que tu cites, un espace (de 32 bits en C#) sur la pile va être réservé pour stocker la variable 'i', et seul son contenu sera modifié à chaque nouvelle affectation dans la boucle. Pas de nouvelle allocation donc.
Ca correspond un peu aux types primitifs en Java, à la différence qu'il n'y avait pas d'unification entre les types primitifs et les autres mais une séparation nette, contrairement à C#, qui a montré qu'on pouvait très bien tout considérer comme des objets avec des propriétés communes sans pour autant oublier la notion de types "valeur" qui améliorent grandement les perfs.
Il y a quand même des différences entre une fonction "globale" et une méthode.
Une méthode est raccrochée à une classe, cela lui offre des fonctionnalités particulières qui fait justement tout l'intérêt de la programmation objet :
- l'encapsulation : la méthode a accès des champs privés de la classe, contrairement à une fonction externe. Bref on peut exposer des actions (méthodes), sans exposer les détails d'implémentation internes de la classe.
- l'héritage : une méthode peut être redéfinie par une sous-classe et modifier le comportement de l'action attendue.
Une méthode suppose l'existance d'une instance à manipuler, ce qui explique la syntaxe toto.Foo().
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 1.
L'un empêche pas l'autre. C'est pas moi qui le dit, c'est l'OASIS :
"A standard for office document processing and interchange will be of great utility to many users and software companies developing applications, and should be made available as soon as possible."
Et pourtant OOo, MS-Office, etc savent exporter et importer du html
Toute la nuance est justement dans ces opérations d"'import/export" qui montre clairement qu'il y a perte d'information (et en l'occurence non négligeable).
Es-ce que SVG doit être compatible avec AutoCAD, VISIO ou metafile de Windows ?
bah non, c'est pas le but d'un format d'échange :)
Et tu entends quoi par format d'échange ?
Qu'on soit en phase : je ne considère pas du tout qu'OOXML est un format d'échange.
Pour moi un format d'échange est un format qui sert à "échanger" des informations structurées entres applicatifs. Cela suppose que le format est clairement défini et ne contient pas de portes ouvertes à tout et n'importe quoi comme données externes comme les proposent ODF ou OOXML.
Es-ce que le w3c a pourri sa norme html car il y a des millions de page web conçu pour EI6 ?
La différence c'est qu'HTML est conçu par un organisme indépendant et le format existe indépendamment des applicatifs. ODF a été conçu pour supporter les informations d'OOo et OOXML celles d'MSOffice. Le premier se défini pourtant comme un format d'échange, le 2ème non.
ODF ne remplace pas ou ne concurrence pas de standard.
ODF reprend ce qui est déjà standardisé.
Si : ODF suppose l'implémentation d'une JVM, hors une norme ISO concurrente existe, je te laisse deviner laquelle ;)
ODF n'est pas conçu pas et pour un boite.
Non effectivement, elle est conçu pour 2 boîtes ;)
ben c'est les oignons de MS. Ce n'est pas de la faute à ODF. Et en passant, MS participait aux débuts de ODF. Mais MS s'est barré.
Faut vraiment être de mauvaise foi de ne pas y voir des conflits d'intérêt entre IBM, Sun et MS.
OOXMlL n'est pas un format d'échange meilleur que ODF et ici la faute en revient exclusivement à MS.
Mais MS ne prétend pas que c'est un format d'échange, il est clairement présenté comme un format permettant de migrer des documents écrits pour MS Office.
Il y a plein de truc que supporte ODF et que ne supporte pas OOXML.
Oué bah oué.
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 1.
C'est dans les critères de l'ISO : pour un même domaine, il ne faut qu'une spèc.
Ben étant donné que les 2 formats ne répondent pas au même besoin, j'ai envie de dire que ce ne sont pas les mêmes domaines ;)
La raison est simplement pour pourrir la standardisation de format bureautique vers un format vraiment ouvert (et non à la botte de MS).
Le problème c'est que Sun et IBM ont déjà pourri la standardisation en proposant l'ODF sachant pertinement qu'il ne remplissait pas son objectif affiché : être un format d'échange.
Par exemple Adobe "doit" faire un conversion PDF => ODF.
C'est débile :) Ces 2 formats ne représentent absolument pas le même type d'informations...
Vu les objectifs ISO, c'est un non sens de ratifier OOXML.
Je suis d'accord, comme c'est un non sens d'avoir ratifié l'ODF...
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 0.
Venant d'un type qui sait même pas ce que veut dire "représenter une information" au sens informatique, ca me fait doucement rire...
La FSF parle de la conversion Microsoft oxml vers ODF qui ete rendu volontairement difficile par microsoft (d'apres ton lien).
Elle est pas rendu difficile, elle est par nature IMPOSSIBLE. (on peut évidemment obtenir un certain niveau de transformation mais forcement incomplet).
Toi tu parles de la conversion des formats MS Office 97 -> MS Office 2007
Cites pas n'importe quoi. Je disais clairement qu'ODF ne permettait pas de représenter toutes les informations que permet de représenter l'OOXML. C'est exactement la même chose que dit la FSF.
Alors s'il te plait tente de rester coherent soit tu dis que microsoft oxml a ete cree pour avoir un "rendu" parfait des documents de MS Office 97 a 2007
Oui il a été créé dans ce but. C'est évidemment pas exempt de défaut, mais l'OOXML a ce but et permet de convertir la plupart des documents sans problème. L'ODF est beaucoup moins bon pour faire cette tâche.
Ce qui est hallucinant c'est que même les détracteurs de l'OOXML ont pour la plupart fini par admettre que l'OOXML n'avait pas le même but et les mêmes possibilité que l'ODF. C'est justement cet argument de l'objectif qu'ils utilisent maintenant pour justifier un non passage à l'ISO.
Les objectifs d'OOXML sont clairs et présenté dans ce document de l'ECMA :
http://www.ecma-international.org/news/TC45_current_work/Ope(...)
"OpenXML was designed from the start to be capable of faithfully representing the pre-existing corpus of word-processing documents, presentations, and spreadsheets that are encoded in binary formats defined by Microsoft Corporation. The standardization process consisted of mirroring in XML the capabilities required to represent the existing corpus, extending them, providing detailed documentation, and enabling interoperability."
Est-ce que tu peux comprendre que y'a des utilisateurs qui ont envie d'avoir autre chose qu'un format binaire tout en conservant au maximum l'intégrité de leur base documentaire existante ? (cas de la British Library) OOXML répond à ce besoin, l'ODF non, car il n'a pas été conçu pour.
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 1.
Je dis pas que c'est mieux ou moins bien, je dis que c'est PAREIL.
Si tu veux une réponse : pour un format qui se veut un format d'échange ca me gène. Pour un format qui se veut un format compatible avec la majorité des documents offices existant, ca me gène moins parcqu'il y a une bonne raison : la compatibilité. Pour le format d'échange, il n'y a aucune raison, c'est même parfaitement contradictoire avec l'objectif.
euh il répondait juste à une affirmation SANS FONDEMENT de ta part.
\o/ Vous êtes trop fort pour moi.
Avant de retourner la question, et de demander des preuves. Commence par prouver TOI tes premières affirmation.
Ben en tout cas la FSF Europe est d'accord avec moi :
http://www.fsfeurope.org/documents/msooxml-converter-hoax.fr(...)
Visiblement il n'ont pas senti le besoin de prouver quoique ce soit vu que tout le monde est d'accord sur ce point (sauf vous bien entendu).
Ben oui koffice, meme si il ne supporte pas encore toute la norme, utilise ce format pour stocker ses documents (donc en lecture et en écriture).
On me souffle dans l'oreillete qu'abiword le supporte aussi.
Mais pas entièrement comme tu le précises très bien. Parcque justement l'ODF est fortement lié aux fonctionnalités d'OOo. CQFD.
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 2.
Ce que je voulais dire c'est qu'il est impossible de lire tout type de document ODF car le format est trop "ouvert". T'as très bien compris ce que j'ai voulu dire.
Pour le moment aucune preuve n'a ete faite sur le sujet.
Allez gros malin, je vais arrêter de tomber dans ton piège à la con, et je te retourne la question : prouve moi que l'ensemble des informations que propose de représenter le format OOXML à travers ses 6000 pages de specs sont transcriptlbles dans le format ODF (auquel cas effectivement l'OOXML n'a pas de raison d'exister).
bon courage ;)
Rq: J'ai un peu change ta phrase car ODF ne represente rien, c'est le logiciel ouvrant le fichier qui represente.
\o/ Alors là t'es vraiment foet, tu comprends pas ce que je dis, donc tu changes mes propos... Joli.
En informatique, on utiliser souvent l'expression "représenter quelquechose" comme désigner la façon de "coder" une information de façon à pouvoir l'interpréter.
Exemple : comment "représenter" un titre dans le langage HTML ? (réponse : utiliser la balise "title").
Bref, il n'y a pas que la représentation "graphique" : un format comme OOXML ou ODF décrit la façon de "représenter" des informations (utiles pour les applications qui les utilisent) dans un fichier.
c'est une norme pour "representer des documents office" ce qui est legerement plus general.
Ca c'est la théorie des bisounours. En pratique c'est utilisé pour représenter les documents Office d'OOo.
ODF a toujours ete prevu en plusieurs etapes.
Pourquoi pas, mais dans ce cas on laisse pas la possibilité de mettre des formules dans un document si on n'indique pas comment l'interpréter !
Là l'objectif était clairement de sortir un truc le plus rapidement possible, un truc qui permette à OOo d'utiliser le format en natif, quitte à mettre de côté certains aspects. Affirmer que c'est pour proposer un format d'échange et d'interopérabilité, c'est malhonnête. L'objectif est de supporter OOo, et d'améliorer au fur-et-à-mesure. Dans un vrai format d'échange et d'interopérabilité, c'est les applications qui s'adaptent au format, pas l'inverse.
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 0.
C'est ironique ? Non parcque j'en ai parlé y'a bien plus longtemps.
Premierement tu vas nous pointer une page precise dans la description de ODF pour le fait d'inclure H264.
Bah grosso merdo dans un document ODF tu peux inclures n'importe quel type de media, donc pourquoi pas une vidéo H264. Si je fais un document avec une telle vidéo dedans, comment tu fais pour le relire si sur ton PC ton application ne supporte pas ca ?
Regarde page 303 dans la spec, il est fait référence à un système de plugin pour pouvoir ajouter tout et n'importe quoi comme player... Tu trouves ca normal ce genre de porte ouverte à tout et n'importe quoi dans un format qui se veut un format d'échange et d'interopérabilité ?
Question contenus binaire, l'ODF ne se cache même pas, tiré de la doc :
"As XML has no native support for binary objects such as images, [OLE] objects, or other media
types, and because uncompressed XML files can get very large, OpenDocument uses a
package file to store the XML content of a document together with its associated binary data, and
to optionally compress the XML content."
Deuxiemement tu vas aussi nous expliquer comment tu vas lire les objets binaires inclus dans microsoft oxml
Puisqu'il faut que je le répète une fois de plus : je cherche pas à montrer qu'ooxml est mieux ou n'a pas ces défauts, je montre juste qu'ODF a les mêmes types de problème, par nature : c'est un format de travail d'une suite bureautique existante : OOo. Par nature ce format n'a pas pour but l'interopérabilité ou l'échange, mais le support des fonctionnalités qu'à décider Sun et IBM (OOo donc).
tu vas m'expliquer l'interet d'avoir une norme redondante si elle n'apporte strictement rien que ce soit niveau proprete ou autre.
Forcement, quand on se documente pas, on risque pas de trouver des différences. l'OOXML supporte la représentation de la plupart des informations nécessaire à décrire un document pour les suites MS Office 97 -> MS Office 2007, ce que ne permet pas l'ODF. En soit ca justifie largement son existance, comme le rappel l'article référencé sur le site d'IBM.
oui je prefere qu'ils aient pris leur temps plutot qu'avoir des erreurs grossieres mathematiques
Et pourquoi n'auraient-ils pas pu prendre leur temps tout court pour pondre la norme ODF ? Pourquoi ne pas avoir attendu qu'OpenFormula se face tranquillement pour pondre ODF ? Non le but était d'avoir le label "ISO" le plus vite possible pour l'utiliser comme argument marketing.
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 1.
=>
Les bons observateurs auraient dû s'insurger dès le départ sur l'absence de critique sur la standardisation de l'ODF à l'ISO.
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 1.
Mais personne ne dit qu'OOXML est parfait ! Juste qu'ODF est pas mieux. A lire les specs d'ODF, il faudrait implémenter une JVM, un décodeur H264 et j'en passe. Sans parler des manques flagrant de specs (il n'y a pas de liste exhaustive des formats d'image qu'on peut inclure, JPG, SVG, autre ?) Niveau binaire et conneries, c'est pas beaucoup mieux.
Every line of code that is written to our standards is a small victory; every line of code that is written to any other standard, is a small defeat. Total victory, for DRG, is the universal adoption of our standards by developers, as this is an important step towards total victory for Microsoft itself: “A computer on every desk and in every home, running Microsoft software.”
Mais c'est exactement le même combat de tous les acteurs du secteur, à commencer par IBM et Sun : il faut mieux maîtriser les formats et les faire standardiser, on peut ainsi maîtriser nos produits et leurs évolutions, que de se mettre en retrait avec un temps de retard en implémentant le format "standard" des concurrents.
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 1.
"Mis en avant par IBM" si tu préfères :) Ca change rien au contenu.
Ce n'est pas la compilation des milliers de strates de bugs d'Office qu'est la spec OpenXML...
Faut pas exagérer non plus, OpenXML ce n'est pas "que" ca. D'ailleur une des propositions qui a été faite et uqi n'est pas exclu, c'est de séparer ce qui est "clean" des trucs "legacy".
Que l'ODF soit mieux conçu parcque faisant plus ou moins table rase des problèmes de compatibilité qu'a MS avec ses vieux formats, on est d'accord, qu'il se focalise sur la description du contenu, on est d'accord, mais ca change rien au contenu : le contenu est fortement lié aux fonctionnalités de l'appli qui l'utilise, et l'ODF n'a pas été conçu pour représenter un contenu "générique" indépendant de toute fonctionnalité, il est fortement couplé aux fonctionnalités d'OOo tout comme l'est OpenXML avec MS Office.
OpenXML ne devrait pas être ISO, certes, mais ODF n'auraient jamais dû l'être si on s'en tient aux mêmes objectifs que l'article que tu as cité : un format d'interopérabilité et d'échange. Etant donné l'importance de l'impact "commercial" d'un tel label, il serait malhonnête de certifié l'un et pas l'autre, quitte à modifié l'OpenXML pour sortir les trucs "crades" et "legacy".
Le problèmes de ceux qui critique une éventuellement standardisation par l'ISO de l'OpenXML, c'est qu'en ommettant systématiquement de remettre en cause la standardisation de l'ODF, ils affichent clairement leur cheval de bataille : donner un avantage à tel ou tel acteur plutôt qu'à tel autre. Les bons observateurs auraient dû s'insurger dès le départ sur l'absence de critique sur la standardisation de l'ISO. Mais ca arrangeait tout le monde (sauf MS).
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 2.
Le soucis, c'est qu'il n'explique pas pourquoi la question ne s'est pas posé pour l'ODF, qui était loin d'être exempt de défaut, et même s'il est plus "clean" que l'OpenXML (beaucoup moins de conneries liées à la compatibilité avec les formats du passé), il n'est pas non plus une réponse à l'interopérabilité pour les mêmes raisons : il est fortement lié aux fonctionnalités d'OOo qui reste l'implémentation de référence (et c'est pas les autres implémentations qui vont montrer le contraire...).
Si l'ODF est passé ISO, c'est pas pour la beauté d'avoir un format interopérable, c'est avant tout pour avoir un label à présenter aux gros clients (administrations) et mettre en avant les solutions de Sun/IBM face à MS Office.
Si l'ODF a eu le droit à cette certification, il n'y a pas beaucoup de raison d'empêcher l'OpenXML de ne pas l'avoir (sans pour autant dire qu'il faut qu'il le soit tel quel).
Le seul format d'interopérabilité qui pourra exister ne pourra être qu'un sous-ensemble des formats utilisés par les principaux produits du marché. Ce format ne pourra pas être le format de "travail" permettant d'exploiter toutes les fonctionnalités d'une appli, mais sera plutôt un format d'échange sur un mode "Import/Export", utile lors des migrations par exemple. Ce format ne pourra pas exister sans l'engagement des différents acteurs du marché, et dans un objectif commun de créer un format d'échange (et non de travail).
[^] # Re: Question bête
Posté par TImaniac (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 2.
ODF aussi complet soit-il ne couvre pas l'ensemble des fonctionnalités de MS Office, MS ne peut donc pas se contenter de ce format : ils leur faut un format "natif" à l'application.
Le couple Application<>Format étant tellement important ils doivent également utiliser leur propre format pour :
- Assurer la compatibilité avec les documents existant (les documents enregistré dans le vieux format .doc doivent pouvoir l'être dans un nouveau format sans perte d'information)
- Maîtriser les évolutions de leurs produits
Si OpenXML existe, c'est du fait de la demande croissante des utilisateurs (notamment administrations) d'avoir un format "ouvert" et documenté, sous la pression de SUN et IBM qui ont montré les avantages d'un tel format avec OOo et l'ODF.
[^] # Re: mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Rigolons : accélérer Vista. Évalué à 0.
Evidemment si t'es un geek !
Mais madame michu, tu vas pas lui demander d'ouvrir la fenêtre qui liste les process, de lui demander de matter de temps en temps quel appli bouffe de la ram pour lui conseiller de redémarrer là dite appli...
Ca c'est n'importe quoi !
Le seul conseil "générique" et applicable par n'importe quel utilisateur reste de "redémarrer" une fois de temps en temps.
[^] # Re: mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Rigolons : accélérer Vista. Évalué à -2.
T'es con ou quoi ? J'ai justement écris juste avant :
"Certaines mises à jour nécessite un reboot."
Faut arrêter de faire semblant de pas comprendre en jouant sur la forme alors que tout le monde a compris ce que j'ai dis.
et la différence est donc dans la nécessité de _devoir_
Y'a aucune nécessité. Tu fais ce que tu veux.
# mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Rigolons : accélérer Vista. Évalué à 3.
Delete programs you never use
Un programme que je n'utilise pas, ne doit pas ralentir ma bécane. Il y a des tonnes de programme que je n'utilise pas sur ma bécane.
Il y a une différence entre "je ne l'utilise pas" et "il bouffe des ressources quand même".
Même si on n'utilise pas un programme, il utilise des ressources :
- espace disque
- processeur (certains programmes tournent en tâche de fond)
- mémoire (certains programmes tournent en tâche de fond)
Clean up your hard disk
Plus les disques sont utilisés et plus c'est lent...
C'est la notion de "scalability" de Windows ?
Plus un disque est plein, plus les fichiers deviennent fragmentés sur le disque et limite les perfs du système en conséquence. Y 'a pas de miracle.
Run fewer programs at the same time
Retour à MS-DOS.
Le problème est identique sous tous les OS.
Restart regularly
Poilant de rire.
Encore une fois, ce problème est similaire sous Linux : tu peux très bien avoir des programmes avec une légère fuite mémoire par exemple qui vont poser dégrader les perfs globales au bout d'un certain temps.
Restart your PC at least once a week
Mort de rire.
Certaines mises à jour nécessite un reboot. Sous linux aussi. Ne pas rebooter une fois de temps en temps sur un poste client c'est potentiellement s'exposer à des problèmes de sécurité.
Check for viruses and spyware
J'ai jamais fait ça sous Linux en 10 ans d'utilisation.
Quelqu'un a essayé ça sous Linux ? On y gagne en performance ?
C'est la rançon du succès.
Disable services you don’t need
Ce conseil sur slashdot ne m'étonnerait pas...
Ce serait un conseil de sécurité, il serait bienvenu.
Mais pour accélérer une bécane...
Un service qui s'exécute bouffe de la RAM et parfois du CPU.
[^] # Re: l'acrobat qui fesait trop le malin...
Posté par TImaniac (site web personnel) . En réponse au journal PDF, PNG, transparence et ... Acroread. Évalué à 9.
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 1.
D'ailleur Firefox est aussi laxiste sur ce point là, et pour les mêmes raisons de compatibilité avec l'existant.
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 1.
Et tu proposes quoi à part forcer les développeurs ?
Sérieux c'est débile, t'as vu le nombre de site web sur internet ? je met ma main à couper que 90% d'entre eux ne respectent pas les standards, tu voudrais que MS casse la compatibilité avec tout les sites tout ca par "respect" pour les standards ??
Ben oui, il y a la solution du doctype mais les dev win sont trop con pour l'utiliser donc on choisi autre chose.
C'est quoi cette argumentation de merde, on insulte les développeurs qui essaient de faire des sites qui marchent avec le navigateur qui a les 3/4 du marché ?
Mais avec un tel raisonnement, pourquoi ça changerait puisque ce qu'ils font marchera d'office sous ie 6-7-8 ?
Bah tous les nouveaux sites pourront être fait en suivant les standards, le développeur y aura intérêt puisqu'il pourra partir du principe qu'il n'aura qu'un seul site à développer pour Opera/Firefox/IE/Safari.
Donc comme d'hab, ils vont mettre en place des standards, personne ne saura qu'il faut mettre la balise meta
Pourquoi les développeurs l'ignoreraient ?
sinon ils metterait déjà correctement la balise doctype et il n'y aurait pas ce problème
Comme indiqué par la team IE, le problème vient du fait que beaucoup d'entête de document HTML sont générés automatiquement par des softs (Dreamwaver & co). Effectivement c'est du laxisme.
Quand tu comprendras que forcer les développeurs à migrer tous leurs sites existant (ce qui est tout bonnement innimagineable) n'est pas répondre à leurs attentes... Respecter les standards n'est pas une finalité en soit, c'est un outil pour faciliter la vie des développeurs. MS offrent le choix au développeur d'utiliser l'outil qu'il veut selon ses besoins.
et de deux que tout le monde s'en branle et donc ça ne sert à rien
Bah non on pourra enfin faire un site sans se soucier du navigateur (pour le HTML en tout cas, avec le javascript c'est pas gagné), ce dont de nombreux développeurs ne se branlent pas tellement ils passent du temps.
PS : je te rappelle que Firefox ou Safari ne sont pas full w3c-compliant, et qu'ils s'adaptent également aux sites existant, c'est ce qui fait aussi leur succès... Pourquoi tu ne les critiques pas de la même manière ? Ils pourraient systématiquement afficher un message d'erreur si une page est pas w3c-compliant !
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 2.
Ben justement non. C'était la solution choisie dans IE7, manque de bol les développeurs mettent leurs DOCTYPE n'importe comment, et des pages qui se déclarent comme respectant tel ou tel standard était en fait toujours codé pour IE6 : résultat IE7 affiche incorrectement de sites qui marchait sous IE6.
Du coup là ils choisissent une autre technique, celle de la balise meta, qui a très peut de chance d'être déjà utilisée sur le web.
Mais bon, comme d'hab, ms a systématiquement peur d'aller en avant, d'oser casser un peu la compatibilité.
C'est pas une question d"oser", c'est juste une solution de transition qui permet de supporter les anciens sites tout en laissant la possibilité aux nouveaux sites d'être w3c-compliant. Bref tout le monde est content.
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 3.
mais surtout des problèmes incommensurables aux développeurs web !
Ca va être quoi le problème pour les développeurs web ? Supporter les standards va les faire chier ? Rien ne les obligera à utiliser ce mode ! Ce mode est prévu pour ceux qui veulent coder leur site en respectant les standards et ne souhaitant pas faire plusieurs versions de leur sites pour différents navigateurs, où est la mauvaise idée ?
De plus ceux que ca fait chier, rien ne les obligeras à utiliser ce mode, IE8 restera compatible avec les rendus de IE7 et IE6, donc pourquoi critiquer cette initiative ?
Tu proposes quoi sérieusement ? Que IE8 ne propose que le support strict des standards et soit incappable d'afficher correctement tous les sites qui ont été fait pour les versions précédentes de IE ? Ou plutôt que IE8 soit toujours aussi pourri au niveau des standards pour continuer à gueuler sur MS ?
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 1.
De croire que IE8 va améliorer le support des standards du W3C dans ce navigateur ? Je penses pas être naïf, ca serait juste complètement stupide et mauvais pour l'image de MS que de ne pas améliorer ce point, surtout qu'il est annoncé comme étant un objectif.
Je prétend pas que ca va être parfait, je dis que ca sera sûrement mieux, tout comme ie7 est mieux que ie6.
La solution choisie, à savoir proposer un mode n'ayant pas à se soucier de gérer la compatibilité avec l'existant laisse penser qu'ils peuvent quelque chose de pas trop mal. Si on prend tous les autres formats du W3C implémentés par MS, la compatibilité avec ces standards est plus que bonne (SOAP, XPath, W3C Schema, XSLT, etc.), ils peuvent tout à fait faire pareil avec IE8.
On dirait que ca vous fait chier à l'idée que MS respecte un peu mieux les standards.
[^] # Re: Windows et ligne de commande
Posté par TImaniac (site web personnel) . En réponse au journal De l'arrivée de nouveaux utilisateurs d'origine Windows dans le monde du libre.... Évalué à 2.
[^] # Re: C & Cie
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 2.
Les types immutables en Python sont grosso modo là pour cacher ce que les types primitifs cachent en Java ou les types valeurs en C#. (c'est un racourci mais ca suffit pour ce qui nous intéresse).
Dans la sémantique exprimée par le langage Python, cela donne effectivement l'impression qu'il y a création d'un nouvel objet à chaque manipulation. En réalité l'interpréteur fait la même chose qu'en C# ou Java, à savoir des opérations sur des valeurs. L'objet est justement immutable pour cacher cette optimisation.
Si un entier était modifiable, il devrait être référencé en permanence par un "pointeur" (comme les autres types qui sont manipuler à travers un pointeur/adresse en interne), ce qui nécessite un intermédiaire : il faut faire un accès à une adresse mémoire pour obtenir le pointeur puis un autre accès mémoire pour accéder à la valeur référencé par le pointeur, ce dernier accès étant plus lent car effectué dans une autre partie de la mémoire. Si t'es dans une opération de type a = b + c, faut faire 3 fois ce boulot !
Je sais pas si je suis clair :)
Par contre ce que je dis là n'est pas vrai pour les types immutables qui ne sont pas "optimisés", cad qui ne cache pas des manipulations de valeur. Par exemple le type String.est en Java, C# ou Python un truc "immutable", il n'est pas pour autant utlisé en tant que valeur mais en tant que référence, pour la simple et bonne raison que la valeur contient beaucoup de données (plusieurs caractères) et de taille variable : les passer par valeur d'une méthode à une autre par exemple nécessiterait systématiquement une copie de l'intégralité des données, c'est moins coûteux de passer uniquement la référence (qui elle est stockée sous la forme d'une adresse).
Si ces types sont immutables, ce n'est pas cette fois pour cacher une optimisation du type manipulation de valeur à la place de manipulation de référence. C'est plus pour éviter au programmeur de faire n'importe quoi en manipulant le contenue d'une chaîne.
Du coup là par contre ca peut devenir très couteux de faire des opérations sur des chaînes de caractères, style :
string a = "rezzef"
a += "suite"
a += "suite2"
a += "ligne3"
Là effectivement il y a création systématique d'un nouvel objet pour stocker le résultat de la concaténation, ce qui est coûteux.
Des langages comme C# ou Java propose des classes qui cachent des chaînes de caractères "modifiables" quand c'est nécessaire (typiquement pour l'exemple ci dessus) :
StringBuilder sb = new StringBuilder("rezzef")
sb.Append("suite")
sb.Append("suite2")
sb.Append("ligne3")
string res = sb.ToString()
Dans cet exemple l'objet sb n'est pas immutable, et les appels successifs à la méthode Append modifie le contenue de la chaîne de caractère qui est stockée en interne (probablement dans un tableau de caractère), le dernier appelle permet de recopier le contenu dans une "string" classique.
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 1.
[^] # Re: C & Cie
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 1.
En l'occurence un int est un type valeur. Donc concrêtement dans l'exemple que tu cites, un espace (de 32 bits en C#) sur la pile va être réservé pour stocker la variable 'i', et seul son contenu sera modifié à chaque nouvelle affectation dans la boucle. Pas de nouvelle allocation donc.
Ca correspond un peu aux types primitifs en Java, à la différence qu'il n'y avait pas d'unification entre les types primitifs et les autres mais une séparation nette, contrairement à C#, qui a montré qu'on pouvait très bien tout considérer comme des objets avec des propriétés communes sans pour autant oublier la notion de types "valeur" qui améliorent grandement les perfs.
[^] # Re: C & Cie
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 1.
Une méthode est raccrochée à une classe, cela lui offre des fonctionnalités particulières qui fait justement tout l'intérêt de la programmation objet :
- l'encapsulation : la méthode a accès des champs privés de la classe, contrairement à une fonction externe. Bref on peut exposer des actions (méthodes), sans exposer les détails d'implémentation internes de la classe.
- l'héritage : une méthode peut être redéfinie par une sous-classe et modifier le comportement de l'action attendue.
Une méthode suppose l'existance d'une instance à manipuler, ce qui explique la syntaxe toto.Foo().