"Approval requires at least 2/3 (i.e. 66.66 %) of the votes cast by national bodies participating in ISO/IEC JTC 1 to be positive; and no more than 1/4 (i.e. 25 %) of the total number of national body votes cast negative. Neither of these criteria were achieved, with 53 % of votes cast by national bodies participating in ISO/IEC JTC 1 being positive and 26 % of national votes cast being negative.
Comments that accompanied the votes will be discussed at a ballot resolution meeting (BRM) to be organized by the relevant subcommittee of ISO/IEC JTC 1 (SC 34, Document description and processing languages) in February 2008 in Geneva, Switzerland.
The objective of the meeting will be to review and seek consensus on possible modifications to the document in light of the comments received along with the votes. If the proposed modifications are such that national bodies then wish to withdraw their negative votes, and the above acceptance criteria are then met, the standard may proceed to publication.
Otherwise, the proposal will have failed and this fast-track procedure will be terminated. This would not preclude subsequent re-submission under the normal ISO/IEC standards development rules."
Traduction approximative:
L'homologation nécessite au moins 2/3 (c-à-d 66,66%) de votes positifs des membres nationaux participant à l'ISO/IEC JTC 1 pour être acceptée ; et pas plus d'1/4 (c-à-d 25%) du total des votes des membres nationaux négatifs. Aucun de ces critères n'a été atteint, avec 53% de votes positifs des membres nationaux participant au ISO/IEC 1 et 26% de votes négatifs des membres nationaux.
Les commentaires qui accompagnent les votes seront discutés lors d'une rencontre décisive pour le vote (BRM) qui sera organisée par le sous-commité ad-hoc de l'ISO/IEC JTC 1 (SC 34, Document description and processing languages) à Genève, Suisse, en Février 2008.
L'objectif de cette rencontre sera d'étudier et de rechercher un consensus sur les modifications possibles du document à la lumière des commentaires reçus avec les votes. Si les modifications proposées sont telles que les membres nationaux souhaitent alors retirer leurs votes négatifs, et que les critères d'acception ci-dessus sont remplis, alors le standard pourra être publié.
Dans le cas contraire, la proposition aura échouée et cette procédure rapide sera finie. Cela n'exclura pas d'autre re-soumissions ultérieures dans les règles de progression normale des standards ISO/IEC.
D'après mon expérience qui ne touche que celles de 2007, je confirme que le public étaient très majoritairement français avec des interventions en français.
Le contenu, très varié, s'adressait au grand public (mais en étant un peu averti sur le sujet, on comprenait certaines blagues...). Toutefois, même si les thématiques étaient généralistes : économie publique, sciences, système, développeurs, éducation, ... Les conférences étaient parfois sur des sujets pointus avec un public plus restreint mais globalement plus averti que celui de certaines séances en amphi.
Il y avait au centre de la manifestation, un espace de démonstration avec d'un côté le multimédia (radio, tv,...) et à côté un lieu dédié à l'éducation où l'on pouvait voir des machines faire tourner les logiciels. Là on pouvait aussi se faire des échanges de clés PGP à 20... ;)
Dans le centre d'Amiens -et Amiens n'a qu'un petit centre-, il y avait des panneaux publicitaires (les "sucettes") un peu partout avec des affiches des RMLL.
Clairement, le gros des efforts fut fait pour accueillir le grand publique et les professionnels. D'ailleurs, on a eu droit à une collation dans un établissement scolaire privé, l'ESIEE, qui est membre de la chambre de commerce d'Amiens. Mais il y avait aussi beaucoup de geeks, le wifi dans la plus part des conférences, une salle info avec une trentaine de postes en libre accès... D'ailleurs je tiens à saluer publiquement l'organisation (le LUG picard, et tous les autres :D ) qui fut très bonne et m'a rendu le séjour *confortable* : chambre à proximité, clean et remplis de visiteurs comme moi, repas dans un restaurant universitaire pour pas cher si besoin, plaquette couleur avec l'agenda détaillé des conférences et mallette (en plastique pas cher hein, mais assez pratique quand même pour ces quelques jours), il y avait de la place dans ce campus universitaire près du centre ville. Une ambiance détendu, festive parfois.
D'ailleurs les gars du coin étaient tellement motivés qu'on pouvait continuer nos discussions, la nuit, dans ce lieu perdu dans la ville nommé "les nocturnes". AMHA l'un des lieux les plus conviviaux de ces rencontres 2007.
Ceci dit, pour l'anecdote, j'y ai rencontré un finlandais (skolelinux), un canadien (scribus), Alan Cox, ... De mon point de vue, ces rencontres furent "mondiales".
J'étais aux RMLL mais je n'avais pu assister à cette présentation. Merci de l'avoir mise en avant. C'est en effet un bon sujet : internet ou minitel 2.0 et bien présenté.
Ca donne envie de monter son apache, son asterisk, etc.
Les gens ne changent pas office de Microsoft pour un autre programme parce que 1- leurs anciens documents sont au format Microsoft et 2- il n'y a que les logiciels de Microsoft qui savent bien gérer les formats Microsoft.
OOXML ne résout pas ce problème.
Et après tu viens me dire que les clients ne sont pas captifs ? pfffff.
Ce qui ne change pas le fait que ce soit un défaut (ou non) d'implantation et non pas un défaut du format.
Oui. La seule implémentation d'OOXML est celle de Microsoft. Il y a 6 000 pages de documentation sur OOXML. Dans ces six mille pages, il y a de nombreuses balises au comportement qui n'est décrit nul part publiquement et qui ne trouve leur définition que... dans l'implémentation de Microsoft !!
Concernant OOXML, il n'y a pas de différence entre le format et l'implémentation, car dans ce cas précis, le format est défini par rapport à l'implémentation de Microsoft. Microsoft a écrit OOXML en référence à son propre "word". C'est d'ailleurs l'argument de Microsoft: OOXML est compatible avec les formats anciens de Microsoft. Mais seulement pour ceux qui utiliseront office 2007.
Dans l'étude, Stephane Rodriguez dénonce le fait que la norme officielle d'OOXML, l'ECMA 376, ne reflète pas l'implémentation, n'existe pas. (point 13)
Bref, même si tu implémentes l'ECMA 376 tu n'auras pas la compatibilité avec les documents sous un des formats de Microsoft.
Microsoft promet la compatibilité avec les anciens formats ? Office 2007 sera -plus ou moins- compatible avec leur anciens formats. Politique que Microsoft poursuit plus ou moins bien depuis très longtemps. Bref beaucoup de bruit pour RIEN.
On aura toujours des "OpenOffice" ou "Abiword" pour avoir leur filtre pour les formats de Microsoft, et cela ne marchera toujours pas aussi bien qu'on en aurait besoin.
Enfin, si OOXML devient standard ISO, on ne pourra même plus contester que l'administration publique veuille utiliser ce format. Je crains qu'avec l'argent de nos impôts on justifie l'achat d'Office 2007 car il est le seul à faire de l'OOXML.
Imaginons quelqu'un se disant: "Je paye Office 2007, mais cette fois c'est la dernière fois, car ce logiciel utilise le standard ISO OOXML. Je passe mes vieux documents dans ce format ISO, puis j'aurai d'autres logiciels compatibles pour les éditer."
Celui là se sera bien fait avoir si tu veux mon avis.
Ok, je te rends justice là-dessus. Il reste cependant qu'on continue de discuter sur des points de détail, alors que le fond lui reste:
OOXML ne sert pas l'interopérabilité, et s'il est accepté par l'ISO, alors il n'aura de standard que le nom.
Ou pour le dire autrement, Microsoft fait encore un fois la preuve de sa volonté d'abuser ses clients pour qu'ils restent captifs et continuent de lui donner leur argent.
L'auteur de l'étude a créé un tableau avec 3 cellules, dont une est la somme des deux autres.
À la main, il a modifié cette cellule en remplaçant un "3" par un "4" (on passe de 10+20=30 à 10+20=40)
Or cette modification est inacceptable par office 2007 qui renvoie une erreur lors de la lecture de ce document modifié.
Pour faire en sorte que ce nouveau tableau soit lisible par office 2007, l'auteur a du modifier *au final* 40% des fichier du document (4 fichiers sur les 10 présents dans le document produit par office 2007).
De ton côté, tu affirmes que l'auteur a commis une erreur car tu calcules qu'il a modifié 33% du document et non 40% comme l'auteur le dit dans l'étude. Ce que tu ne vois pas, c'est que ce chiffre de 40% correspond au nombres de fichiers du document que l'auteur a du modifier pour qu'office 2007 lise son nouveau tableau. Ton propre calcul repose sur le fait que le tableau orginal contient 3 cellules et que l'auteur en a modifié 1, d'où la modification d'1 tiers des cellules du tableau original, donc 33% (en arrondissant).
Donc, d'une part ce que dit l'auteur de l'étude (40% des fichiers à modifier pour faire accepter son nouveau tableau à office 2007) et ce que tu dis (33% des cellules modifiée) sont tous les deux vrais. Cependant, si on sort des abstractions en pourcentage, la réalité de ce qui fut fait était de remplacer un 3 par un 4 au départ et de voir comment office 2007 lit un tel fichier modifié.
D'autre part, tu sèmes la confusion dans la démonstration de l'auteur :
L'auteur prétend simplement que faire un tel changement dans un fichier d'office 2007 est très fastidieux car office 2007 implémente toutes sortes de vérifications et donc, in fine, écrire un logiciel capable de modifier un fichier issu d'office 2007 pour qu'office 2007 puisse ensuite le lire à nouveau est très délicat.
Or justement tout l'intérêt d'OOXML est de rendre interopérable office 2007 avec des implémentations tierces. L'auteur de l'étude montre très concrètement les problèmes que cela pose.
De ton côté, au lieu de t'intéresser au propos de l'auteur sur l'interopérabilité, tu essayes de le prendre au pied de la lettre pour montrer qu'il commet des erreurs qu'on peut qualifier de stupides. Car tu veux faire croire qu'il ne sait même pas calculer qu'un tiers c'est 33% et non 40%. Mais comme je viens de le montrer plus haut, vous ne parlez pas de la même chose. Comme c'est toi qui critique ce qui a été écrit par l'auteur, j'en conclu que c'est toi qui fait erreur pour n'avoir pas su lire correctement le document : juste en dessus d'un tableau avec les fichiers modifiés l'auteur dit "Original versus updated file : 40% of parts need a change!" L'auteur parle bien des fichiers modifiés (updated file) et pas des cellules du tableau.
En conclusion, j'affirme:
1- L'auteur ne s'est pas trompé sur ce chiffre de 40%.
2- Tu as mal lu.
3- Tu réponds à côté de ce qui est démontré par l'auteur.
Ce qui tu pointes ne change rien, mais absolument rien à l'argumentaire.
1- Il est *extrêmement* compliqué de faire un document OOXML qui soit lisible par office 2007, on peut même dire impossible sans l'aide de Microsoft, et Microsoft lui-même s'est tellement embourbé dans sa gestion des données bureautique qu'il n'y a même pas de véritable interopérabilité entre ses diverses versions d'office.
Le 40% ou 33% est anecdotique ici.
2- Office 2007 introduit des erreurs dans les données qu'entre l'utilisateur. Peu importe l'importance de l'erreur, c'est toujours une erreur. Le logiciel ne *doit* pas présumer ce dont a besoin l'utilisateur, il doit simplement le servir au mieux. Là c'est clairement défectueux.
Oui, mais c'est dans les objectifs du format d'arriver de faire en sorte qu'un tel convertisseur soit réalisable et d'en faciliter l'écriture.
Bonjour,
Si je te comprends bien, Microsoft a créé un format de fichier -le .doc- et il aurait besoin de toute la communauté mondiale de l'industrie de la bureautique pour faire son convertisseur ???
Ne pouvaient-ils pas le faire avant, seuls ? Car c'est quand même eux qui ont conçus les formats précédants ! Si c'est si important d'être compatible avec l'existant, c'est à eux de faire le convertisseur ! Qui d'autre qu'eux pourrait le faire aussi bien ? OpenOffice.org essaye et ce n'est toujours pas ça.
Et qu'a fait Microsoft ? Il a fait son convertisseur ? Non, il a seulement donné des spécifications parfois floues du convertisseur qui sont intégrées dans la norme et il a sponsorisé un convertisseur ooxml / odf ! Donc, pour avoir cette fameuse compatibilité avec les anciens documents, tu dois nécessairement utiliser le ooxml de Microsoft Office. Car, c'est celui qui fait le boulot le mieux, vu qu'il a les spécification d'ooxml comme tout le monde et en plus il possède les sources des anciennes version d'office. À qui cela profite-t-il ?
L'argument de la compatibilité avec l'existant (les .doc) qu'avance Microsoft est un bon argument, mais le procédé que cette entreprise utilise la maintient en position de domination sur le , hooooo, sacrééé saint marchéééé. Alléluia !
Bref, le prix que Microsoft demande pour avoir cette compatibilité c'est de continuer à acheter son produit ! HoooYé !
Je ne crois pas en cette générosité à deux temps (dont un à venir, sorte de paradis de la bureautique où on serait tous frères...) que tu dépeints. Je vois pour ma part que les actes de Microsoft visent à maintenir les utilisateurs captifs.
Ainsi Microsoft a su dominer le monde de la bureautique avec office, et au lieu de l'en libérer en fournissant une moulinette pour passer son propre format .doc dans un standard (comme ODF), c'est toute l'industrie mondiale de la bureautique qui devrait supporter le format de Microsoft.
Bravo, belle économie d'énergie : tout le monde va doit implémenter la moulinette en plus des spécifications qui décrivent comment on fait de la bureautique.
C'est comme si le charbon ayant dominer l'énergie pendant des années, on devait faire des centrales mixte charbon/nucléaire aujourd'hui.
je trouves sacrement hypocrite que tout le monde du libre qui a encense ODF descende OpenXML en flamme pour des defauts qui sont presents dans ODF.
Avant tu disais:
Posté par pasBill pasGates (envoyer un message privé) le 16/08/2007 à 00:26. (lien). Évalué à 1.
[snip]
b) Je parlais pas de tous les libristes, mais de certains libristes
Encore avant tu disais:
Posté par pasBill pasGates (envoyer un message privé) le 15/08/2007 à 22:21. (lien). Évalué à -1.
[snip]
b) Ca depend de ta definition de meilleur, si c'est "utilise par un logiciel libre et pas cree par MS" comme certains pensent ici alors non
Faut choisir hein, parce que là je suis confus...
Tu dis:
Si ODF est considere assez bon pour etre un standard(et personne ne s'est plaint depuis hein), cela devrait etre idem pour OpenXML, et sutout, ces gens qui se plaignent d'OpenXML devraient penser a jeter un oeil a ODF parce que visiblement personne ne l'a fait.
Non, si la procédure de sélection des standards est mauvaise, il faut la revoir et vite. On s'en fiche d'ODF et d'OOXML si on ne peut en faire des implémentations tierce complètes. Ou alors c'est qu'on choisi de vider le mot standard de son contenu, ce qui ouvre la porte à beaucoup d'abus.
Comprenons nous bien ! Si le format standard contient des parties binaires qui sont dans un format breveté, alors cela veut dire qu'il faut payer quelqu'un pour s'en servir ou bien dépendre de la générosité d'un vendeur.
Or le but d'un standard c'est de permettre les communications/echanges entre les utilisateurs en donnant les mêmes chances de départ à tous les acteurs. Avec ces parties binaires brevetées, certains acteurs sont de fait favorisés si les utilisateurs créent des échanges/communications avec elles.
Or, justement, Microsoft est en position ultra dominante sur les PC, et justement, il donne aux utilisateurs de windows non seulement le droit d'utiliser tous ces binaires, mais en plus il en crée lui-même et encourage fortement leur usage dans les logiciels (comme word, tiens!).
Et là, pour le coup, la compatibilité elle se fait à coup de reverse-engenering, tu crois que c'est mieux que de lire des sources, non c'est encore pire de lire directement le binaire !!
Les travers des uns ne devraient pas servir à cacher les travers des autres.
c) Ben c'est idem pour ODF, tu veux me dire que ODF n'est pas utilisable/implementable par des softs GPL ?
Si tant est qu'il y le même défaut dans les deux formats, alors il me viendrait plus à l'esprit de dire que l'ISO doit être encore plus exigeant qu'il ne l'a été avec ODf, et qu'il devrait même taper sur les doigts d'ODF pour qu'il se spécifie complètement rapidement si besoin est.
Le problème d'une implémentation tierce complète n'est pas qu'un problème pour les logiciels GPL, c'est un problème pour tous les autres acteurs, exeption faite de Microsoft en ce qui concerne OOXML. Par ailleurs, l'implémentation d'openoffice est publique, ce qui change quand même un peu les choses pour une "compatibilité" pleine avec les documents de ce logiciel pour les parties obscures d'ODF.
a- Ce n'est pas la même chose de mettre dans le standard un comportement qui fait référence à un word particulier comme le fait OOXML, que de faire référence à openoffice 1.1. Pourquoi ? C'est parce que l'implémentation d'openoffice est disponible alors que le code de word n'est disponible que pour Microsoft. Tu veux le même comportement qu'openoffice 1.1 ? Tu mets une équipe qui spécifie le comportement à partir des sources et une autre qui sans avoir vu les source l'implémente à partir des spécifications de la première équipe. Tu ne peux pas faire ça avec word.
Microsoft irrevocably covenants that it will not seek to enforce any of its patent claims necessary to conform to the technical specifications for the Microsoft Office 2003 XML Reference Schemas or the Ecma Office Open XML standard (Ecma 376) (the "Specifications") against those conforming parts of software products
c- Si je comprends bien la citation, ce sont les spécifications qui sont librement implémentable, mais si les spécifications autorisent des formats de documents comme ceux couvert de brevets de Microsoft, alors on aura beau avoir les bonnes spécifications dans le logiciel qui voudra lire le document, s'il y a un format breveté dedans, alors le document ne sera jamais lisible par un logiciel GPL.
Franchement, autant appeler les choses par leur nom : tu FUD.
Voyons tes raisons:
a) Il est tout aussi ouvert qu'ODF (pour les grincheux : ces elements non-documentes sont presents dans ODF aussi)
a) Ça veut dire quoi "elements non-documentes" ? S'il y a des parties non-documentées dans ODF, j'aimerai que tu en listes un peu (ou tout si tu veux) pour qu'on en parle vraiment, et pas à coup de sous-entendus. Car il se pourrai que ne pas avoir le même avis que le tien sur cette question soit autre chose qu'être simplement d'une humeur "grincheuse" ; un standard doit être pleinement défini si on veut être interopérable.
b) Ca depend de ta definition de meilleur, si c'est "utilise par un logiciel libre et pas cree par MS" comme certains pensent ici alors non
b) Les libristes, ne pensent pas que les "logiciels libres" sont meilleurs, ce sont les gens de l'OSI ou des gens comme Linus Torvald qui voudraient qu'on voit les logiciels libres de cette façon car ils veulent en faire du profit. Les gens comme Richard. M. Stallman disent que les logiciels libres ne sont pas meilleurs, mais mieux que les autres logiciels, car ils sont plus éthique (respect des autres, libertés accordées, développement de la communauté, etc.).
Après, les libristes ont effectivement un plan pour en finir avec les logiciels "privateurs", qui passe notemment par une excellence technologique des logiciels libres ; mais c'est un but hein, pas (encore ?) la réalité.
c) Rien a payer et utilisable/implementable par des softs GPL
c) Ton point c contredit ton point a : s'il y a des trous obscurs dans le standard, il ne peut pas y avoir d'implémentation tierce complète, donc on aura des problèmes d'interopérabilité et de favoritisme envers la seule implémentation complète : celle de Microsoft.
On a la vidéo avec GNU/Linux depuis des années ! La VoIP ce n'est pas que la trucs grands public de Microsoft, c'est aussi des standards industriels:
on a plusieurs implémentation de SIP, d'H323 ou de IAX.
Avec des bons clients comme Ekiga, Wengophone, Twinkle,...
La version 3.0 d'Ekiga aura de très bons codecs vidéo comme h263+, theora et même h264. Bref, on sera au niveau de ichat sous mac ou de skype sous windows.
ICE http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-ice/ soulève quand même un problème :
pour bien marcher il faut avoir au moins un serveur qui est prêt a relayer les flux de communication sur le net. Qui a les moyens (bande passante, CPU) et l'envie de mettre en place de tels serveurs ? Ces serveurs seront-ils publics ?
Il y a déjà un standard IETF pour la vidéo (et l'audio) : SIP. Et encore un autre H.323. Ces deux standards sont matures et en production.
Ekiga (anciennement Gnomemeeting) fait cela depuis... des années (6 ans maintenant) !
Il existe beaucoup de clients logiciels (et matériels aussi : des téléphones) qui font SIP (ou H.323) et donc la voix et parfois la vidéo sur toutes les plateformes, par exemple en ce qui concerne la compatibilité avec Ekiga: http://wiki.ekiga.org/index.php/Which_programs_work_with_Eki(...)
Pidgin utilise aussi le protocole SIMPLE (en voie d'être standardisé) pour la messagerie instantannée et la présence pour SIP. De fait on peut, par exemple connecter Pidgin sur ekiga.net et donc se parler par messages textes entre Pidgin et Ekiga:
Il faut d'abord avoir un compte sur http://ekiga.net (gratuit, sans pub, fait avec des logiciels libres, mais pas bô...)
Ensuite on configure Pidgin:
Comptes->Modifier->Ajouter
Onglet Essentiel:
Protocol:SIMPLE
Screen name: Nom d'utilisateur chez ekiga.net
Serveur: ekiga.net
Mot de passe: Mot de passe chez ekiga.net
Local alias: Nom d'utilisateur
Onglet Avancé:
État de publication: activé
Port de connection: 5060
Utiliser UDP: activé
On laisse le reste vide
Pour des petits problèmes d'interopérabilité entre Pidgin et Ekiga:
Aller dans Outils->Préférences->Onglet Conversations
Désactiver "Notifier les contacts que vous êtes en train de leur écrire"
Testé avec Pidgin 2.0.2
La question qui se pose : on a plusieurs standards "concurrents"...
Pour la messagerie/présence Jabber est standardisé, pour la voix et la vidéo SIP et H.323 sont standardisés.
Jingle (Jabber/XMPP) prétend à devenir un standard pour la voix et la vidéo, SIMPLE (SIP) prétend devenir un standard pour la messagerie et la présence.
C'est des méthodes mixtes, on commence avec de la globale puis on passe au déchiffrage. Encore une fois, en France, il n'y a presque personne pour défendre une méthode globale d'apprentissage de la lecture exclusive du déchiffrage. Presque tous les enfants ont appris à déchiffrer.
Après, je ne défend pas tous les profs. De plus l'école est devenue récemment un passage obligé pour assurer une carrière professionnelle, ce qui est une première historique qui pose beaucoup de problèmes.
J'abonde dans le sens de _PhiX_ pour ce qui est de la méthode globale ; elle ne peut pas être responsable d'échecs massifs dans l'enseignement de la lecture car elle n'a jamais été enseignée massivement. Ce qui fut fait était généralement soit de la syllabique assez pure, soit un mélange de globale, surtout en début d'année de CP et principalement pour les "mots outils" (la, le, de, un, pour, etc.), et de syllabique pour le reste des mots.
Tout le bruit autour de la globale fut surtout destiné à faire croire que tel ministre allait sauver les enfants avec la complicité des mass medias sur le dos des profs.
[^] # Re: La France dit NON avec commentaires
Posté par Yannick . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
La position officielle de l'ISO:
http://www.iso.org/iso/newsandmedia/pressrelease.htm?refid=R(...)
Traduction approximative:
L'homologation nécessite au moins 2/3 (c-à-d 66,66%) de votes positifs des membres nationaux participant à l'ISO/IEC JTC 1 pour être acceptée ; et pas plus d'1/4 (c-à-d 25%) du total des votes des membres nationaux négatifs. Aucun de ces critères n'a été atteint, avec 53% de votes positifs des membres nationaux participant au ISO/IEC 1 et 26% de votes négatifs des membres nationaux.
Les commentaires qui accompagnent les votes seront discutés lors d'une rencontre décisive pour le vote (BRM) qui sera organisée par le sous-commité ad-hoc de l'ISO/IEC JTC 1 (SC 34, Document description and processing languages) à Genève, Suisse, en Février 2008.
L'objectif de cette rencontre sera d'étudier et de rechercher un consensus sur les modifications possibles du document à la lumière des commentaires reçus avec les votes. Si les modifications proposées sont telles que les membres nationaux souhaitent alors retirer leurs votes négatifs, et que les critères d'acception ci-dessus sont remplis, alors le standard pourra être publié.
Dans le cas contraire, la proposition aura échouée et cette procédure rapide sera finie. Cela n'exclura pas d'autre re-soumissions ultérieures dans les règles de progression normale des standards ISO/IEC.
Cordialement,
Yannick
[^] # Re: La France dit NON avec commentaires
Posté par Yannick . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 5.
http://portailgroupe.afnor.fr/v3/espace-presse/communiques/2(...)
# La France dit NON avec commentaires
Posté par Yannick . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 6.
http://www.lemondeinformatique.fr/actualites/lire-open-xml-l(...)
:)
Cordialement,
Yannick
[^] # Re: effet d'annonce
Posté par Yannick . En réponse à la dépêche Les vidéos des rencontres mondiales 2007 en ligne. Évalué à 8.
D'après mon expérience qui ne touche que celles de 2007, je confirme que le public étaient très majoritairement français avec des interventions en français.
Le contenu, très varié, s'adressait au grand public (mais en étant un peu averti sur le sujet, on comprenait certaines blagues...). Toutefois, même si les thématiques étaient généralistes : économie publique, sciences, système, développeurs, éducation, ... Les conférences étaient parfois sur des sujets pointus avec un public plus restreint mais globalement plus averti que celui de certaines séances en amphi.
Il y avait au centre de la manifestation, un espace de démonstration avec d'un côté le multimédia (radio, tv,...) et à côté un lieu dédié à l'éducation où l'on pouvait voir des machines faire tourner les logiciels. Là on pouvait aussi se faire des échanges de clés PGP à 20... ;)
Dans le centre d'Amiens -et Amiens n'a qu'un petit centre-, il y avait des panneaux publicitaires (les "sucettes") un peu partout avec des affiches des RMLL.
Clairement, le gros des efforts fut fait pour accueillir le grand publique et les professionnels. D'ailleurs, on a eu droit à une collation dans un établissement scolaire privé, l'ESIEE, qui est membre de la chambre de commerce d'Amiens. Mais il y avait aussi beaucoup de geeks, le wifi dans la plus part des conférences, une salle info avec une trentaine de postes en libre accès... D'ailleurs je tiens à saluer publiquement l'organisation (le LUG picard, et tous les autres :D ) qui fut très bonne et m'a rendu le séjour *confortable* : chambre à proximité, clean et remplis de visiteurs comme moi, repas dans un restaurant universitaire pour pas cher si besoin, plaquette couleur avec l'agenda détaillé des conférences et mallette (en plastique pas cher hein, mais assez pratique quand même pour ces quelques jours), il y avait de la place dans ce campus universitaire près du centre ville. Une ambiance détendu, festive parfois.
D'ailleurs les gars du coin étaient tellement motivés qu'on pouvait continuer nos discussions, la nuit, dans ce lieu perdu dans la ville nommé "les nocturnes". AMHA l'un des lieux les plus conviviaux de ces rencontres 2007.
Ceci dit, pour l'anecdote, j'y ai rencontré un finlandais (skolelinux), un canadien (scribus), Alan Cox, ... De mon point de vue, ces rencontres furent "mondiales".
Cordialement,
Yannick
[^] # Re: Internet libre, ou Minitel 2.0 ?
Posté par Yannick . En réponse à la dépêche Les vidéos des rencontres mondiales 2007 en ligne. Évalué à 2.
J'étais aux RMLL mais je n'avais pu assister à cette présentation. Merci de l'avoir mise en avant. C'est en effet un bon sujet : internet ou minitel 2.0 et bien présenté.
Ca donne envie de monter son apache, son asterisk, etc.
Yannick
[^] # Re: OOXML is defective by design
Posté par Yannick . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 6.
Et tu as répondu (plus bas):
Donc iWorks n'écrit pas au format OOXML. Merci d'avoir répondu à ma question.
De plus, la lecture des documents OOXML n'est pas parfaite. Par exemple:
http://www.bioneural.net/2007/08/11/iwork-08-and-support-for(...)
Les gens ne changent pas office de Microsoft pour un autre programme parce que 1- leurs anciens documents sont au format Microsoft et 2- il n'y a que les logiciels de Microsoft qui savent bien gérer les formats Microsoft.
OOXML ne résout pas ce problème.
Et après tu viens me dire que les clients ne sont pas captifs ? pfffff.
Cordialement,
Yannick
[^] # Re: OOXML is defective by design
Posté par Yannick . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 4.
Que d'amabilité.
Je m'a trompé ???
Voyons voir...
http://www.openmalaysiablog.com/2007/08/msooxml-third-p.html
QUESTION: Est-ce qu'iWork'08 écrit au format OOXML ?
QUESTION: Si iWorks n'écrit pas au format OOXML, est-ce à dire que ce format n'est pas assez bien pour Apple ?
QUESTION: Y a-t-il une autre implémentation complète d'OOXML, mise à part MicroSoftOOXML
Je vais te dire pourquoi Apple n'écrit pas au format OOXML : parce qu'office 2007 ne le lirait pas correctement.
Si tu ne peux pas exporter, ce n'est pas un format d'échange.
Cordialement,
Yannick
[^] # Re: OOXML is defective by design
Posté par Yannick . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.
Oui. La seule implémentation d'OOXML est celle de Microsoft. Il y a 6 000 pages de documentation sur OOXML. Dans ces six mille pages, il y a de nombreuses balises au comportement qui n'est décrit nul part publiquement et qui ne trouve leur définition que... dans l'implémentation de Microsoft !!
Concernant OOXML, il n'y a pas de différence entre le format et l'implémentation, car dans ce cas précis, le format est défini par rapport à l'implémentation de Microsoft. Microsoft a écrit OOXML en référence à son propre "word". C'est d'ailleurs l'argument de Microsoft: OOXML est compatible avec les formats anciens de Microsoft. Mais seulement pour ceux qui utiliseront office 2007.
Dans l'étude, Stephane Rodriguez dénonce le fait que la norme officielle d'OOXML, l'ECMA 376, ne reflète pas l'implémentation, n'existe pas. (point 13)
Bref, même si tu implémentes l'ECMA 376 tu n'auras pas la compatibilité avec les documents sous un des formats de Microsoft.
Microsoft promet la compatibilité avec les anciens formats ? Office 2007 sera -plus ou moins- compatible avec leur anciens formats. Politique que Microsoft poursuit plus ou moins bien depuis très longtemps. Bref beaucoup de bruit pour RIEN.
On aura toujours des "OpenOffice" ou "Abiword" pour avoir leur filtre pour les formats de Microsoft, et cela ne marchera toujours pas aussi bien qu'on en aurait besoin.
Enfin, si OOXML devient standard ISO, on ne pourra même plus contester que l'administration publique veuille utiliser ce format. Je crains qu'avec l'argent de nos impôts on justifie l'achat d'Office 2007 car il est le seul à faire de l'OOXML.
Imaginons quelqu'un se disant: "Je paye Office 2007, mais cette fois c'est la dernière fois, car ce logiciel utilise le standard ISO OOXML. Je passe mes vieux documents dans ce format ISO, puis j'aurai d'autres logiciels compatibles pour les éditer."
Celui là se sera bien fait avoir si tu veux mon avis.
Cordialement,
Yannick
[^] # Re: OOXML is defective by design
Posté par Yannick . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 1.
Ok, je te rends justice là-dessus. Il reste cependant qu'on continue de discuter sur des points de détail, alors que le fond lui reste:
OOXML ne sert pas l'interopérabilité, et s'il est accepté par l'ISO, alors il n'aura de standard que le nom.
Ou pour le dire autrement, Microsoft fait encore un fois la preuve de sa volonté d'abuser ses clients pour qu'ils restent captifs et continuent de lui donner leur argent.
C'est cela qui est un véritable scandale !
Cordialement,
Yannick
[^] # Re: OOXML is defective by design
Posté par Yannick . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 8.
Soyons rigoureux, puisque c'est ton credo.
L'auteur de l'étude a créé un tableau avec 3 cellules, dont une est la somme des deux autres.
À la main, il a modifié cette cellule en remplaçant un "3" par un "4" (on passe de 10+20=30 à 10+20=40)
Or cette modification est inacceptable par office 2007 qui renvoie une erreur lors de la lecture de ce document modifié.
Pour faire en sorte que ce nouveau tableau soit lisible par office 2007, l'auteur a du modifier *au final* 40% des fichier du document (4 fichiers sur les 10 présents dans le document produit par office 2007).
De ton côté, tu affirmes que l'auteur a commis une erreur car tu calcules qu'il a modifié 33% du document et non 40% comme l'auteur le dit dans l'étude. Ce que tu ne vois pas, c'est que ce chiffre de 40% correspond au nombres de fichiers du document que l'auteur a du modifier pour qu'office 2007 lise son nouveau tableau. Ton propre calcul repose sur le fait que le tableau orginal contient 3 cellules et que l'auteur en a modifié 1, d'où la modification d'1 tiers des cellules du tableau original, donc 33% (en arrondissant).
Donc, d'une part ce que dit l'auteur de l'étude (40% des fichiers à modifier pour faire accepter son nouveau tableau à office 2007) et ce que tu dis (33% des cellules modifiée) sont tous les deux vrais. Cependant, si on sort des abstractions en pourcentage, la réalité de ce qui fut fait était de remplacer un 3 par un 4 au départ et de voir comment office 2007 lit un tel fichier modifié.
D'autre part, tu sèmes la confusion dans la démonstration de l'auteur :
L'auteur prétend simplement que faire un tel changement dans un fichier d'office 2007 est très fastidieux car office 2007 implémente toutes sortes de vérifications et donc, in fine, écrire un logiciel capable de modifier un fichier issu d'office 2007 pour qu'office 2007 puisse ensuite le lire à nouveau est très délicat.
Or justement tout l'intérêt d'OOXML est de rendre interopérable office 2007 avec des implémentations tierces. L'auteur de l'étude montre très concrètement les problèmes que cela pose.
De ton côté, au lieu de t'intéresser au propos de l'auteur sur l'interopérabilité, tu essayes de le prendre au pied de la lettre pour montrer qu'il commet des erreurs qu'on peut qualifier de stupides. Car tu veux faire croire qu'il ne sait même pas calculer qu'un tiers c'est 33% et non 40%. Mais comme je viens de le montrer plus haut, vous ne parlez pas de la même chose. Comme c'est toi qui critique ce qui a été écrit par l'auteur, j'en conclu que c'est toi qui fait erreur pour n'avoir pas su lire correctement le document : juste en dessus d'un tableau avec les fichiers modifiés l'auteur dit "Original versus updated file : 40% of parts need a change!" L'auteur parle bien des fichiers modifiés (updated file) et pas des cellules du tableau.
En conclusion, j'affirme:
1- L'auteur ne s'est pas trompé sur ce chiffre de 40%.
2- Tu as mal lu.
3- Tu réponds à côté de ce qui est démontré par l'auteur.
Cordialement,
Yannick
[^] # Re: OOXML is defective by design
Posté par Yannick . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 9.
Ce qui tu pointes ne change rien, mais absolument rien à l'argumentaire.
1- Il est *extrêmement* compliqué de faire un document OOXML qui soit lisible par office 2007, on peut même dire impossible sans l'aide de Microsoft, et Microsoft lui-même s'est tellement embourbé dans sa gestion des données bureautique qu'il n'y a même pas de véritable interopérabilité entre ses diverses versions d'office.
Le 40% ou 33% est anecdotique ici.
2- Office 2007 introduit des erreurs dans les données qu'entre l'utilisateur. Peu importe l'importance de l'erreur, c'est toujours une erreur. Le logiciel ne *doit* pas présumer ce dont a besoin l'utilisateur, il doit simplement le servir au mieux. Là c'est clairement défectueux.
ODF stocke ces données ainsi:
cf. http://developers.slashdot.org/comments.pl?sid=279895&ci(...)
Chipoter sur l'étendue de l'imprécision comme tu le fais est encore anecdotique. Il y a imprécision avec OOXML.
Pour conclure: soit tu argumentes sur le fond, soit tu m'expliques où tu veux en venir avec tes anecdotes.
Cordialement,
Yannick
[^] # Re: quelques explications s'il vous plait
Posté par Yannick . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 7.
Bonjour,
Si je te comprends bien, Microsoft a créé un format de fichier -le .doc- et il aurait besoin de toute la communauté mondiale de l'industrie de la bureautique pour faire son convertisseur ???
Ne pouvaient-ils pas le faire avant, seuls ? Car c'est quand même eux qui ont conçus les formats précédants ! Si c'est si important d'être compatible avec l'existant, c'est à eux de faire le convertisseur ! Qui d'autre qu'eux pourrait le faire aussi bien ? OpenOffice.org essaye et ce n'est toujours pas ça.
Et qu'a fait Microsoft ? Il a fait son convertisseur ? Non, il a seulement donné des spécifications parfois floues du convertisseur qui sont intégrées dans la norme et il a sponsorisé un convertisseur ooxml / odf ! Donc, pour avoir cette fameuse compatibilité avec les anciens documents, tu dois nécessairement utiliser le ooxml de Microsoft Office. Car, c'est celui qui fait le boulot le mieux, vu qu'il a les spécification d'ooxml comme tout le monde et en plus il possède les sources des anciennes version d'office. À qui cela profite-t-il ?
L'argument de la compatibilité avec l'existant (les .doc) qu'avance Microsoft est un bon argument, mais le procédé que cette entreprise utilise la maintient en position de domination sur le , hooooo, sacrééé saint marchéééé. Alléluia !
Bref, le prix que Microsoft demande pour avoir cette compatibilité c'est de continuer à acheter son produit ! HoooYé !
Je ne crois pas en cette générosité à deux temps (dont un à venir, sorte de paradis de la bureautique où on serait tous frères...) que tu dépeints. Je vois pour ma part que les actes de Microsoft visent à maintenir les utilisateurs captifs.
Cordialement,
Yannick
[^] # Re: quelques explications s'il vous plait
Posté par Yannick . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 5.
Ainsi Microsoft a su dominer le monde de la bureautique avec office, et au lieu de l'en libérer en fournissant une moulinette pour passer son propre format .doc dans un standard (comme ODF), c'est toute l'industrie mondiale de la bureautique qui devrait supporter le format de Microsoft.
Bravo, belle économie d'énergie : tout le monde va doit implémenter la moulinette en plus des spécifications qui décrivent comment on fait de la bureautique.
C'est comme si le charbon ayant dominer l'énergie pendant des années, on devait faire des centrales mixte charbon/nucléaire aujourd'hui.
C'est une très mauvaise idée.
Cordialement,
Yannick
[^] # Re: quelques explications s'il vous plait
Posté par Yannick . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 0.
On est d'accord, l'important c'est d'avoir une bonne documentation, donc complète. :)
Cordialement,
Yannick
[^] # Re: quelques explications s'il vous plait
Posté par Yannick . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 2.
Tu dis:
Avant tu disais:
Encore avant tu disais:
Faut choisir hein, parce que là je suis confus...
Tu dis:
Non, si la procédure de sélection des standards est mauvaise, il faut la revoir et vite. On s'en fiche d'ODF et d'OOXML si on ne peut en faire des implémentations tierce complètes. Ou alors c'est qu'on choisi de vider le mot standard de son contenu, ce qui ouvre la porte à beaucoup d'abus.
Cordialement,
Yannick
[^] # Re: quelques explications s'il vous plait
Posté par Yannick . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 8.
Comprenons nous bien ! Si le format standard contient des parties binaires qui sont dans un format breveté, alors cela veut dire qu'il faut payer quelqu'un pour s'en servir ou bien dépendre de la générosité d'un vendeur.
Or le but d'un standard c'est de permettre les communications/echanges entre les utilisateurs en donnant les mêmes chances de départ à tous les acteurs. Avec ces parties binaires brevetées, certains acteurs sont de fait favorisés si les utilisateurs créent des échanges/communications avec elles.
Or, justement, Microsoft est en position ultra dominante sur les PC, et justement, il donne aux utilisateurs de windows non seulement le droit d'utiliser tous ces binaires, mais en plus il en crée lui-même et encourage fortement leur usage dans les logiciels (comme word, tiens!).
Et là, pour le coup, la compatibilité elle se fait à coup de reverse-engenering, tu crois que c'est mieux que de lire des sources, non c'est encore pire de lire directement le binaire !!
Les travers des uns ne devraient pas servir à cacher les travers des autres.
Cordialement,
Yannick
[^] # Re: quelques explications s'il vous plait
Posté par Yannick . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 2.
Si tant est qu'il y le même défaut dans les deux formats, alors il me viendrait plus à l'esprit de dire que l'ISO doit être encore plus exigeant qu'il ne l'a été avec ODf, et qu'il devrait même taper sur les doigts d'ODF pour qu'il se spécifie complètement rapidement si besoin est.
Le problème d'une implémentation tierce complète n'est pas qu'un problème pour les logiciels GPL, c'est un problème pour tous les autres acteurs, exeption faite de Microsoft en ce qui concerne OOXML. Par ailleurs, l'implémentation d'openoffice est publique, ce qui change quand même un peu les choses pour une "compatibilité" pleine avec les documents de ce logiciel pour les parties obscures d'ODF.
Cordialement,
Yannick
[1] et non plus interopérabilité, cf. http://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9
[^] # Re: quelques explications s'il vous plait
Posté par Yannick . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 7.
Ton argument ne tient pas:
a- Ce n'est pas la même chose de mettre dans le standard un comportement qui fait référence à un word particulier comme le fait OOXML, que de faire référence à openoffice 1.1. Pourquoi ? C'est parce que l'implémentation d'openoffice est disponible alors que le code de word n'est disponible que pour Microsoft. Tu veux le même comportement qu'openoffice 1.1 ? Tu mets une équipe qui spécifie le comportement à partir des sources et une autre qui sans avoir vu les source l'implémente à partir des spécifications de la première équipe. Tu ne peux pas faire ça avec word.
c- Si je comprends bien la citation, ce sont les spécifications qui sont librement implémentable, mais si les spécifications autorisent des formats de documents comme ceux couvert de brevets de Microsoft, alors on aura beau avoir les bonnes spécifications dans le logiciel qui voudra lire le document, s'il y a un format breveté dedans, alors le document ne sera jamais lisible par un logiciel GPL.
Cordialement,
Yannick
[^] # Re: quelques explications s'il vous plait
Posté par Yannick . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 7.
Franchement, autant appeler les choses par leur nom : tu FUD.
Voyons tes raisons:
a) Ça veut dire quoi "elements non-documentes" ? S'il y a des parties non-documentées dans ODF, j'aimerai que tu en listes un peu (ou tout si tu veux) pour qu'on en parle vraiment, et pas à coup de sous-entendus. Car il se pourrai que ne pas avoir le même avis que le tien sur cette question soit autre chose qu'être simplement d'une humeur "grincheuse" ; un standard doit être pleinement défini si on veut être interopérable.
Ainsi, ce document montre les problèmes du à ces "éléments non-documentés" dans le format de Microsoft.
http://www.noooxml.org/local--files/arguments/TheCaseAgainst(...)
b) Les libristes, ne pensent pas que les "logiciels libres" sont meilleurs, ce sont les gens de l'OSI ou des gens comme Linus Torvald qui voudraient qu'on voit les logiciels libres de cette façon car ils veulent en faire du profit. Les gens comme Richard. M. Stallman disent que les logiciels libres ne sont pas meilleurs, mais mieux que les autres logiciels, car ils sont plus éthique (respect des autres, libertés accordées, développement de la communauté, etc.).
Après, les libristes ont effectivement un plan pour en finir avec les logiciels "privateurs", qui passe notemment par une excellence technologique des logiciels libres ; mais c'est un but hein, pas (encore ?) la réalité.
c) Ton point c contredit ton point a : s'il y a des trous obscurs dans le standard, il ne peut pas y avoir d'implémentation tierce complète, donc on aura des problèmes d'interopérabilité et de favoritisme envers la seule implémentation complète : celle de Microsoft.
Cordialement,
Yannick
[^] # Re: Et la vidéo ???
Posté par Yannick . En réponse à la dépêche Adium 1.1 est pondu. Évalué à 6.
On a la vidéo avec GNU/Linux depuis des années ! La VoIP ce n'est pas que la trucs grands public de Microsoft, c'est aussi des standards industriels:
on a plusieurs implémentation de SIP, d'H323 ou de IAX.
Avec des bons clients comme Ekiga, Wengophone, Twinkle,...
Liste de clients compatibles avec Ekiga:
http://wiki.ekiga.org/index.php/Which_programs_work_with_Eki(...)
La version 3.0 d'Ekiga aura de très bons codecs vidéo comme h263+, theora et même h264. Bref, on sera au niveau de ichat sous mac ou de skype sous windows.
Cordialement,
Yannick
[^] # Re: ICE et BEHAVE
Posté par Yannick . En réponse à la dépêche Pidgin 2.1 sort de son nid. Évalué à 2.
ICE http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-ice/ soulève quand même un problème :
pour bien marcher il faut avoir au moins un serveur qui est prêt a relayer les flux de communication sur le net. Qui a les moyens (bande passante, CPU) et l'envie de mettre en place de tels serveurs ? Ces serveurs seront-ils publics ?
ICE est moyen de contournement à une situation non standardisée : les NATs. http://fr.wikipedia.org/wiki/Network_address_translation
Personnellement, j'ai plus d'espoir en BEHAVE http://www.ietf.org/html.charters/behave-charter.html qui va standardiser le comportement des NAT et donc permettre de passer à travers sans avoir besoin d'un serveur relai pour passer à travers ceux qui sont "symmétriques".
Je ne crois pas qu'IPv6 va mettre fin aux NATs, donc vivement que BEHAVE soit un standard appliqué dans les routeurs !
Cordialement,
Yannick
[^] # Re: Jingle et SIP
Posté par Yannick . En réponse à la dépêche Pidgin 2.1 sort de son nid. Évalué à 5.
Ekiga (anciennement Gnomemeeting) fait cela depuis... des années (6 ans maintenant) !
Il existe beaucoup de clients logiciels (et matériels aussi : des téléphones) qui font SIP (ou H.323) et donc la voix et parfois la vidéo sur toutes les plateformes, par exemple en ce qui concerne la compatibilité avec Ekiga:
http://wiki.ekiga.org/index.php/Which_programs_work_with_Eki(...)
Pidgin utilise aussi le protocole SIMPLE (en voie d'être standardisé) pour la messagerie instantannée et la présence pour SIP. De fait on peut, par exemple connecter Pidgin sur ekiga.net et donc se parler par messages textes entre Pidgin et Ekiga:
Il faut d'abord avoir un compte sur http://ekiga.net (gratuit, sans pub, fait avec des logiciels libres, mais pas bô...)
Ensuite on configure Pidgin:
Comptes->Modifier->Ajouter
Onglet Essentiel:
Protocol:SIMPLE
Screen name: Nom d'utilisateur chez ekiga.net
Serveur: ekiga.net
Mot de passe: Mot de passe chez ekiga.net
Local alias: Nom d'utilisateur
Onglet Avancé:
État de publication: activé
Port de connection: 5060
Utiliser UDP: activé
On laisse le reste vide
Pour des petits problèmes d'interopérabilité entre Pidgin et Ekiga:
Aller dans Outils->Préférences->Onglet Conversations
Désactiver "Notifier les contacts que vous êtes en train de leur écrire"
Testé avec Pidgin 2.0.2
La question qui se pose : on a plusieurs standards "concurrents"...
Pour la messagerie/présence Jabber est standardisé, pour la voix et la vidéo SIP et H.323 sont standardisés.
Jingle (Jabber/XMPP) prétend à devenir un standard pour la voix et la vidéo, SIMPLE (SIP) prétend devenir un standard pour la messagerie et la présence.
Cordialement,
Yannick
[^] # Re: Des chiffres...
Posté par Yannick . En réponse à la dépêche Les collèges du Rhône se libèrent !. Évalué à 3.
C'est des méthodes mixtes, on commence avec de la globale puis on passe au déchiffrage. Encore une fois, en France, il n'y a presque personne pour défendre une méthode globale d'apprentissage de la lecture exclusive du déchiffrage. Presque tous les enfants ont appris à déchiffrer.
Après, je ne défend pas tous les profs. De plus l'école est devenue récemment un passage obligé pour assurer une carrière professionnelle, ce qui est une première historique qui pose beaucoup de problèmes.
Cordialement,
Yannick
[^] # Re: Compatibilité
Posté par Yannick . En réponse au journal ekiga et le futur support h263/h264. Évalué à 2.
Et pourtant :
http://wiki.ekiga.org/index.php/Roadmap_to_3.00
Et je l'ai testé, ça marche avec x264 (SVN) ;)
Parfois on peut contourner...
Cordialement,
Yannick
[^] # Re: Des chiffres...
Posté par Yannick . En réponse à la dépêche Les collèges du Rhône se libèrent !. Évalué à 3.
J'abonde dans le sens de _PhiX_ pour ce qui est de la méthode globale ; elle ne peut pas être responsable d'échecs massifs dans l'enseignement de la lecture car elle n'a jamais été enseignée massivement. Ce qui fut fait était généralement soit de la syllabique assez pure, soit un mélange de globale, surtout en début d'année de CP et principalement pour les "mots outils" (la, le, de, un, pour, etc.), et de syllabique pour le reste des mots.
Tout le bruit autour de la globale fut surtout destiné à faire croire que tel ministre allait sauver les enfants avec la complicité des mass medias sur le dos des profs.
Je suis moi-même prof en primaire.
Cordialement,
Yannick