Difficile de suivre le fil : vous n'avez pas répondu à votre propre message mais à celui d'après.
Et vous vous êtes planté dans l'anecdote : *mais* la chair est faible... pas *et* la chair est faible :)
Le bikoz : Tentative de traduction cyclique anglais <-> russe par une IA d'une phrase tirée de l'Evangile selon saint Mathieu ( XXVI, 41 ) dont une des traductions françaises est : "L'Esprit est fort, mais la chair est faible."
Essayez de respecter les évangiles quand vous trollez :o)
(je fais du méta-troll de bon matin : la journée s'annonce mal)
Heu... est ce vraiment une bonne idée de se les mettre à dos ?
Il y a un risque non nuls qu'ils considèrent ça comme une attaque en règle et courrent faire des bisous à Microsoft en février 2008. Et dans ce cas il y a fort à parier qu'ils auront plein de bisous en retour :-(
enfin bon... je dis ça je dis rien.
(mais en termes de com et de lobbying je trouve ça moyen quand même)
Si vous aviez mis la phrase dans l'autre sens ( code sql "Oracle" à faire tourner sur MySQL ) ou si vous aviez précisé la version de mysql ça aurait pu passer... mais :
En l'occurence les vieilles versions de MySQL n'ont qu'un nombre limité d'entorses connues (mais autorisées) à la norme SQL-3... j'ai relevé :
* le type INT auquel devrait être préféré le type INTEGER de la norme SQL-3,
* le type DEC auquel devrait être préféré le type DECIMAL,
* le type NUMERIC auquel devrait être préféré le type DECIMAL.
Et ces "entorses" étant comprises par Oracle (qui fait la même chose depuis plus longtemps) le code tournera sur Oracle sans modification.
Les versions récentes de MySQL convertissant à la volée INT en INTEGER et NUMERIC en DECIMAL à la création des champs (DEC n'étant même plus proposé), ce demi-problème n'est d'ailleurs plus d'actualité.
Dans l'autre sens en revanche Oracle "offre" un jeu d'entorses à la norme SQL-3 un peu plus grand (ce qui peut se comprendre : plus grosse bestiole et ausi nécessité de gérer la compatibilité ascendante)... et MySQL ne suit pas... ce qui n'est pas un mal.
Liste non exhaustive parce que je ne vais pas me peler la comparaison complète de la ref Oracle et de SQL-3 :
* BFILE qui corresponds à BLOB,
* INT auquel devrait être préféré le type INTEGER,
* DATE qui corresponds à DATETIME,
* LONG qui corresponds à BIGINT,
* LONG RAW qui corresponds à BIGINT,
* NCHAR qui corresponds à CHAR,
* NCLOB qui corresponds à TEXT,
* NUMBER qui corresponds à DECIMAL,
* NUMERIC auquel devrait être préféré le type DECIMAL,
* DEC auquel devrait être préféré le type DECIMAL,
* NVARCHAR2 qui corresponds à VARCHAR,
* RAW qui corresponds à BLOB,
* VARCHAR2 qui corresponds à VARCHAR.
Il y a aussi des types "Maison" qui n'ont pas d'équivalent dans la norme SQL-3 : NATURAL, POSITIVE, PLS_INTEGER, BINARY_INTEGER, SIMPLE_INTEGER, SIGNTYPE...
Sans compter quelques trucs plus tordus comme LOGGING, NOCACHE, NOPARALLEL, BYTE ... qui n'ont pas d'équivalent à ma connaissance dans la norme SQL-3. Ainsi que quelques détails sur CHAR et sur les implémentation des TRIGGERS (mais bon les TRIGGERS sur les vieilles versions de MySQL y'en a pas et sur les versions récentes c'est bien conforme à la norme SQL-3 si je ne m'abuse)
Bref... en réalité du code SQL qui passe pour MySQL a presque 100% de chances de tourner sur Oracle (la reciproque n'est pas "tout à fait vraie" encore huhuhu mais le SQL Oracle récent utilise assez peu ces types exotiques... sauf VARCHAR2 qu'on retrouve à toutes les sauces).
vala et je rajouterais que dans la norme SQL y'a pas de commande alakon du genre SELECT-LIKE-ORACLE-7.3 ou INSERT-LIKE-MSSQL-2K.
Certes les divers serveurs de bases de données n'implémentent pas 100% de la norme SQL et ajoutent parfois leurs petits bricolages perso pour "enrichir" le truc... mais la norme n'a pas été dégueulassée pour "être compatible" avec les bricolages historiques délirants des divers éditeurs de sgbd.
ODF décharge cela sur l'application, ce qui est normal. Ca n'est pas à la norme de dire: "faites au mieux". C'est au programme de le faire, point barre. Ca n'a rien à faire dans une spec.
Faudra alors penser a lire la spec d'openxml, vous y auriez notamment appris que le _but d'openxml_ c'est de faciliter la transition des anciens documents (Word/WordPerfect principalement) dans un nouveau format, ces elements ont donc une presence tout a fait legitime directement dans la spec, vu que c'est son but.
+1
Et dit plus simplement : MS OpenXML est un pseudo format de transition entre tout un ensemble hétéroclite de formats binaires. Pseudo format permettant de mettre en XML sans vraie transformation ces formats (histoire de garder toutes les infos qu'elles soient nécessaires ou non "au kazou" et puis ça évite de trop modifier les logiciels)... et un hypothétique futur format unifié.
Charge à Microsoft (et à personne d'autre compte tenu du fait que les petites infos non documentées rendent l'écriture d'un vrai convertisseur impossible pour quelqu'un d'autre) de fournir dans un avenir plus ou moins lointain :
1) Le fameux format unifié et propre qui lui pourrait mériter d'être estampillé ISO (et qu'on pourrait aussi bien attendre indéfiniment... le status quo pouvant se révéler parfaitement satisfaisant pour Microsoft : quasimonopole préservé et clients toujours capitfs)
2) Le convertisseur entre le format transitionnel MS OpenXML et le format ISO merveilleux en question. (convertisseur qui disposera de toutes les infos nécessaires puisque tout ce qui est dans les binaires aura été conservé "tel quel"... si tant est qu'un tel convertisseur voie le jour huhuhu ayez confiansssse !)
Et autrement dit encore plus simplement : il ne faut surtout pas considérer un bricolage de transition comme un format de référence.
J'ai bien fait d'ajouter ma précaution lexicale : il s'agit de ma traduction du verbiage commercial de Microsoft... entre dire et faire il y a souvent un monde.
Mais là aussi il y a un hiatus : si on calque "faithfully" on ne peut pas améliorer... et si on améliore alors ça ne peut pas être de l'identique. Deux choses antinomiques dans une seule et même phrase.
"on fait exactement pareil qu'avant... mais mieux" Je n'avais pas relevé cette aberration là digne du "pareil... mais mieux" des Guignols de l'info. Je vous remercie de votre vigilance. Il aurait été dommage de passer à côté de cette perle.
Mais en effet on peut certainement faire autrement et mieux... en particulier en exploitant les conteneurs génériques pour les paramètres spécifiques. Ca éviterait, pour commencer, à ce pauvre OpenXML de se trainer dans la spec autant de casseroles historiques. Et peut être aussi en évitant d'insérer dans le truc des formats redondants par rapport à des formats déjà normalisés (tentative d'en profiter pour faire normaliser en douce des choses qui ne pourraient pas passer autrement ?). Peut être en évitant de laisser trainer des reliquats binaires pour les masques...
La liste est longue et ça n'est pas dans un post qu'on pourra en dresser la liste exhaustive mais tant que Microsoft refusera de remettre son ouvrage sur le métier ça ne risquera pas de bouger.
Je passe sur le début qui ne sert à rien et j'en viens à la partie intéressante qui a trait au sujet dans votre propos.
On va essayer pour commencer de ne pas mélanger les choses :
* le but d'un standard qui est toujours le même : échanger des informations dans un format connu et maitrisé de tous !
* la raison pour laquelle on a besoin de standards qui rejoint (encore heureux) le but premier du standard mais qui au delà touche à des aspects qui concernent la pérennité des données dans le temps (même en cas de faillite du fournisseur de solutions logicielles, même en cas de désaccord majeur avec un éditeur où de décision brutale de celui-ci d'arrêter le suivi d'un format fermé... il n'y a pas que ça mais ça donne déjà une idée d'ensemble)
* la raison pour laquelle un éditeur particulier tente de propulser son format à lui qu'il a pondu au rang officiel de standard.
Comme dans toute démarche alliant le marketing, la stratégie, la communication, la gestion d'un troupeau de clients établi, et le coupage d'herbe sous les pieds des adversaires il n'y a jamais une seule raison qui explique une démarche telle que celle de Microsoft avec OpenXML...
Et dans la mesure ou les objectifs annoncés sur la page que vous avez donné en lien sont directement issus de ce qu'affirme Microsoft nous avons au mieux les objectif officiels de Microsoft... les objectifs réels sont en général un "petit peu" différents (et en ça Microsoft ne diffère en rien des autres grands groupes).... le souci de faire ce qui est le mieux pour les clients n'étant souvent qu'une composante mineure des intentions réelles (bien que 100% des publicités et des communications officielles affirment que c'est le souci premier de 100% des entreprises commeciales... oeuf de course)
Bref... cette petite mise au point lexicale étant faite intéressons nous à cette citation issue des objectifs avoués par Microsoft... (je vais prendre le risque d'en faire une traduction française pour les lecteurs un peu gênés par la langue de Sir Shakespeare... pardon d'avance à tous si c'est moyennement exécuté) :
OpenXML a été conçu dès le départ pour être capable de représenter fidèlement (ndt la connotation de faithfully/fidèlement est intraduisible : faith==foi, full==plein...) l'ensemble pré-existant de documents texte, de présentations et de feuilles de calcul qui sont encodées dans des formats binaires définis par la société Microsoft. Le processus de standardisation a consisté à calquer en XML les structures nécessaires pour représenter les fichiers existants, les améliorer, fournir une documentations détaillée et autoriser l'interopérabilité. A l'heure ou ce document est écrit plus de 400 millions d'utilisateurs créent des documents en utilisant les formats binaires avec des estimations s'élevant à 40 milliards de documents auxquels s'ajoutent quelques milliards de plus chaque année. Les formats binaires originaux furent créés à une époque où l'espace était précieux et où les temps de lecture avaient une influence très importante sur le ressenti des utilisateurs. Ils exploitaient la sérialisation directe de structures stockées en mémoire et utilisées par les applications Microsoft® Office®. Les équipements, les réseaux et les infrastructures standard (en particulier XML) permettent de nouvelles conceptions qui favorisent l'implémentation par de multiples vendeurs sur de multiples plateformes et rendent possible le progrès.
Une petite remarque sur la fin : sur le fond XML n'apporte pas beaucoup de choses par rapport aux formats binaires (XML est un poil plus facile à manipuler et peut être plus clean techniquement mais bon)... même avec des formats binaires il suffit que les specifications soient publiées pour que plusieurs vendeurs exploitent le truc et que ça se développe sur plusieurs plateformes.
La "technique de l'époque" même avec la sérialisation permet très bien de définir des standards d'échange (certes binaires). Si Microsoft ne l'a pas fait avant ça n'est pas qu'ils ne pouvaient pas... c'est juste qu'ils n'avaient pas envie hein!
Maintenant le plus énorme dans ce texte c'est le hiatus entre la première partie et la deuxième : je le refais au ralenti :
1) On a bestialement calqué les structures binaires anciennes dans le XML ... structures qui étaient optimisées pour les équipements de l'époque et qui ne se justifient plus vraiment aujourd'hui (je zappe le couplet sur les millions d'utilisateurs de de documents existants qui sert juste à rappeller que Microsoft aime ses utilisateurs et ne les oublie pas) 2) même si XML et les nouvelles technologies permettent de faire les choses autrement et mieux.
Mon interprétation de la chose : on pouvait certainement faire mieux mais on avait pas le temps (ou l'envie, et puis ça aurait coûté trop cher) de réfléchir à un format qui exploite à fond les mécanismes et les finesses de XML... donc on a transposé vite fait nos formats binaires en XML... comme ça c'est tout bénéfice :
* On dit qu'on fait de l'XML (même si c'est pas très propre) et puis on dit que c'est open tant qu'à faire hein... c'est vendeur en ce moment :o)
* On a déjà le convertisseur binaire <-> XML qui permet de presque rien toucher à notre suite logicielle
* Vu l'épaisseur de l'engin va falloir se lever de bonne heure pour nous suivre sur ce terrain
* Et si ça peut faire du tort à ODF et Sun et OpenOffice et KDE... mafoi dommage collatéral bien regrettable mais c'est la vie huhuhu
finalement je n'aurais peut être pas du vous présenter d'excuses mais malgré vos insultes je ne les retire pas.
Mon but, contrairement à ce que vous semblez croire, n'est pas de "jouer au con" ou de "chercher la petite bête" mais de vous faire réfléchir au dela des trolls que vous vous complaisez à nourrir... objectif peut être trop ambitieux au vu de vos réactions je dois en convenir avec tristesse.
Que le but affiché d'OpenXML soit la rétrocompatibilité est brillant du point de vue marketing mais lamentable du point de vue technique et financier... et ce sont les clients qui en paieront forcément le prix (comme d'habitude).
Quand on crée un format standard on de crée pas, en principe, une caverne d'ali baba virtuelle ou les trucs les plus sordides pourront cotoyer des joyaux. Un format standard doit permettre de modéliser de façon unique chaque élément que l'on peut trouver dans un type de document donné.
Après c'est le travail de convertiseurs de formats de prendre un fichier dans un format ancien WX pour le convertir sans pertes dans le nouveau format (et si le nouveau format a été spécifié proprement il ne doit pas y avoir d'éléments "non convertissables")
Un pseudo format qui présente des redondances de définition, un formalisme dépendant des applications est tout simplement le signe d'un projet bancal techniquement et mal fini... à mon avis fait par des gens à qui l'on n'a pas laissé le temps de pousser assez loin la spécification. Ca crève les yeux dès qu'on a quelques notions de XML et plus on creuse plus les preuves s'accumulent.
ODF de ce point de vue là est clean et cohérent... que OpenOffice tire parti d'un conteneur générique de paramètres pour faire du formattage conditionnel est affreusement sale mais c'est du détournement d'usage... ça ne remet pas en cause la qualité intrinsèque du format ODF.
En revanche OpenXML de ce point de vue est déplorable puisque le détournement se fait dès la spécification du format. C'est indéfendable et je vous l'ai montré gentiment en vous piégeant.
Plutôt que de reconnaitre qu'openXML en l'état nécessite encore du travail pour constituer un format standard sain vous avez préféré sombrer dans l'insulte... c'est assez mauvais joueur mais pas totalement inattendu.
Ayant appris à respecter mes contradicteurs même quand nos points de vues sont irréconciliables, je terminerai cet échange sterile en vous saluant avec le respect qui vous est dû.
même autoSpaceLikeWord2007 sans avoir besoin de faire évoluer la norme ODF... alors que pour déclarer UseFormerLineSpacing dans du FOOXML... ben c'est pas possible en l'état.
Eh si c'est possible, cf.la section "Extended File Properties" dans la description d'OpenXML
haboooooon vous êtes en train de me dire que FOOXML n'est pas orthogonal en gros ? Qu'il y a des sections différentes qui peuvent servir à la même chose... ptet pas étonnant que ça fasse 6000 pages finalement.
Quand je parlais de malpropreté...
Bon en même temps c'était un peu trop facile... et puéril de ma part de vous tendre ce piège. Je vous présente mes excuses.
Le UseFormerLineSpacing en l'occurence est une valeur de paramètre et pas un identifiant de structure XML... autrement dit le format ODF reste "propre" du point de vue historique et indépendante des suites logicielles.
Ben non.
Rien pour étayer ? bon tant pis :-(
Comme il est possible vous n'ayez pas bien compris je vais expliquer de façon plus basique :
Ca n'est pas dans ODF tout simplement parce que ça n'a pas besoin d'y être... de la même façon que lorsqu'on définit un entier numérique il n'y a pas besoin de préciser qu'il doit être obligatoirement constitué de chiffres... hébien là on définit un réceptacle pour un ensemble de paramètres... ils vont forcément avoir un nom et une valeur mais il n'y a pas forcément besoin de préciser lesquels dans la spécification du format.
ODF spécifie tout simplement une structure de configuration assez souple <config:config-item>...</config:config-item> permettant aux applications de stocker des paramètres supplémentaires.
Dit encore plus simplement ODF intègre une structure permettant de spécifier ces informations sans avoir besoin de dégueulasser la spécification du format... ce qui est parfaitement conforme aux exigences ISO.
C'est moins sale... moins verbeux... plus élégant... plus souple et plus évolutif que l'approche FOOXML qui s'apparente beaucoup à du hardcoding (très très malpropre) sur ce point.
Exemple avec autoSpaceLikeWord95 :
Le xsd FOOXML spécifie un tag dédié <autoSpaceLikeWord95 val="onOffType" /> qui implique au dela de l'inélégance que :
1) Le standard ne serait plus indépendant de l'appli... un comble pour un standard !
2) Le jour où il faudra spécifier autoSpaceLikeWord2007 il faudra mettre à jour la norme...
Au passage... le conteneur ODF <config:config-item> pourrait très bien contenir un autoSpaceLikeWord95 et même autoSpaceLikeWord2007 sans avoir besoin de faire évoluer la norme ODF... alors que pour déclarer UseFormerLineSpacing dans du FOOXML... ben c'est pas possible en l'état.
Terrible ça : 6000 pages pour faire un truc limité :-(
Objection votre honneur toussa. Il me semble que vous oubliez des choses en route vous aussi :
Le UseFormerLineSpacing en l'occurence est une valeur de paramètre et pas un identifiant de structure XML... autrement dit le format ODF reste "propre" du point de vue historique et indépendante des suites logicielles.
Au contraire le Format Office OXML contient explicitement plein de références à une suite logicielle particulière... ce qui n'est pas la vocation d'un format standard!
En principe on s'appuie sur la règle pour tirer des traits droits... tordre une règle pour la faire épouser je ne sais quelle courbe existante et prétendre qu'elle est droite puisque conforme à la règle me semble un procédé pour le moins étrange.
Vous fournissez donc là un bel argument contre le Format Office OXML il me semble :o)
Par contre il y a derrire toussa une belle critique à faire aux deux approches : dans les deux cas, que ce soit ODF ou F O OXML il y a un degré d'incertitude concernant la mise en page des documents.
Problématique gênante à la quelle on peut répondre dans les cas des suites KOffice et OpenOffice puisque le code est libre et qu'on peut donc déterminer ce qu'impliquent ces paramètres et leurs valeurs.
Dans le cas de Microsoft Office en revanche il devient assez difficile de s'en tirer puisque le code n'est pas acccessible et que la signification de ces structures XML n'a pas été publiée.
En amendant la proposition de Format Office OXML pour intégrer proprement ces infos dans des structures XML neutres et en publiant la signification de ces infos Ms pourrait atteindre le même niveau de clarté (Au passage serait bien que les autres suites bureautiques nous épargnent de piocher dans le code en publiant quelque part... wiki ou autre la signification des paramètres qu'ils utilisent).
D'un autre cote, faudrait ptetre se demander aussi qui a sorti une suite avec un nom tres proche d'une autre suite dominante sur le marche...
Quizz historique :
Qui a renommé en 1983 son traitement de texte Multi Tools Word (le Multi semblait devoir être la "marque de fabrique"... le tableur s'appelait Multi Plan) en Word tout court alors que le marché était dominé depuis 1981 par WordStar et que la valeur montante était WordPerfect ?
Qui a créé sa suite Office en 1989 quand le marché regorgeait déjà d'une myriade de suites office ? Pour mémoire WordPerfect Library (1986) renommée en WordPerfect Office (1988), WPS Office (1988), SoftMaker Office (1989), Ability Office (1985)... et ben voui : StarOffice (1986)
Sun a racheté StarOffice en 1999 et releasé les sources en 2001 pour former le projet OpenOffice ( s/Star/Open/ )... je ne pense pas que faire muter Star en Open dans une suite plus vieille que Ms Office puisse être considéré comme une manoeuvre trouble.
En revanche nommer un format "Office Open XML" aka OOXML me semble beaucoup plus douteux compte tenu du contexte...
Mais je vois le mal (presque) partout c'est vrai :P
J'ai un peu joué avec des portables keynux... joli mathos visiblement bien conçu et bien assemblé... le prix aussi est bien conçu :@)
Par contre la préconfiguration sous mandriva est un peu rapide... et faite avec la mandriva free. si j'étais mauvaise langue je dirais qu'ils bootent et cliquent sur suivant jusqu'au bout et basta.
résultat : alors que ça peut marcher fantastiquement bien ça marchouille. Le ouifi est pas fonctionnel, les packages sont pas à jour, les medias rpm quasiment pas configurés (y'a tout de même un truc sympa : des copies locales des isos montées en loop... ça évite d'avoir à jouer au grille-pain avec les cdroms), y'a pas java, pas flash...
C'est pas grand chose à rajouter et une fois tunées les configs que j'ai testé marchaient du feu de dieu mais c'est dommage de traiter ce point là un peu (beaucoup) à l'arrache parce que ça peut donner une expérience décevante aux débutants et ça peut agacer les moins débutants de refaire les mêmes manips de config tout le temps.
Vala mon retour :)
ps : Attention tout de même que (sauf erreur de ma part) maintenant c'est pas 100% de leurs configs qui sont full compatibles linux. Une petite vérif prudente peut éviter de mauvaises surprises ;)
rôoo mais c'est qu'il y a insistance en plus.
(ps : désolé pour le ton aigre de mon précédent post mais faut éviter de trop fuder aussi c'est agaçant)
Le fait qu'un logiciel soit libre n'est pas une caractéristique technique du produit, c'est une caractéristique de la licence, donc juridique comme tu le dis.
Et pour la partie technique, on peut effectivement demander que le fournisseur donne accès aux sources pour permettre la maintenance en interne. Mais je ne vois pas ce qui pourrait justifier d'exiger un code source redistribuable (donc sous licence libre) dans le cadre des besoins techniques d'une collectivité.
tsk. pas bien de déformer mes propos j'ai dit que le fait de demander un logiciel libre relevait à la fois de contraintes techniques *et* juridiques.
Au passage pour le besoin il suffit que l'organisme adjudicateur ait un role de soutien vis à vis d'autres entités publiques pour que le besoin de pouvoir rediffuser une version modifiée prenne tout son sens (il y a aussi les cas de rétrocession dans un souci de réduction des couts ou de protection des modifictions contre l'appropriation expliqués dans le guide pdf que j'ai mis en lien plus bas)
Le libre n'est pas une caractéristique technique, c'est une caractéristique de la licence, pas du produit.
C'est typiquement ce qui est indiqué par « faire mention d'un mode ou procédé de fabrication particulier ou d'une provenance ou origine déterminée ».
Ça n'a donc normalement rien à faire dans des spécifications techniques.
Des caractéristiques techniques... des spécifications techniques pfff premièrement c'est pas la même chose et l'acceptation de la notion de spécifications techniques est terriblement large (définie par décrêt http://www.marche-public.fr/Marches-publics/Textes/Arretes/A(...) )
Sont des spécifications techniques, au sens de l’article 6 du code des marchés publics et de l’article 2 des décrets du décret n° 2005-1308 du 20 octobre 2005 et du décret n° 2005-1742 du 30 décembre 2005 susvisés :
1° Lorsqu’il s’agit d’un marché ou d’un accord-cadre de travaux, l’ensemble des prescriptions techniques contenues notamment dans les cahiers des charges et définissant les caractéristiques requises d’un matériau, d’un produit ou d’une fourniture et permettant de les caractériser de manière telle qu’ils répondent à l’usage auquel ils sont destinés par le pouvoir adjudicateur ou l’entité adjudicatrice ;
2° Lorsqu’il s’agit d’un marché ou d’un accord-cadre de services ou de fournitures, les prescriptions définissant les caractéristiques requises d’un produit ou d’un service.
C'est déjà pas bien net à la base... clairement sujet à interprétation et, histoire d'élargir encore un peu le truc, le décrêt s'offre le luxe de rajouter une couche de flou à l'article 2 histoire de pouvoir jouer avec les cas "non prévus". Autrement dit le caractère technique ou non d'une specification technique est laissé à l'appréciation de l'organisme adjudicateur à condtion que ces spécifications ne tombent pas dans le travers du favoritisme plus ou moins déguisé. Le guide des partiques à éviter sert d'illustration... l'idée fondamentale étant d'éviter les bidouillages de clauses techniques pour "favoriser les copains" hors dans le cas des logiciels libres de telles exigences n'entrent pas dans la catégorie des manoeuvres de favoritisme mais permettent de servir l'intérêt supérieur de l'organisme adjudicateur et à travers lui l'intérêt supérieur du service public.
le pouvoir adjudicateur exprime les spécifications techniques en termes de performances à atteindre ou d’exigences fonctionnelles
hors en termes d'exigences fonctionnelles, en particulier pour les organismes de soutien, la possibilité d'accéder aux sources, des les customiser et de les distribuer relève clairement du besoin fonctionnel. La dimension juridique n'est donc clairement pas la seule à entrer en ligne de compte.
Troisièmement une spécification de licence ne présume (je me répète mais visiblement c'est nécessaire) ni de l'origine (n'importe qui peut répondre) ni d'un mode ou d'un procédé de production particulier... et ça ne télescope pas le principe de concurence : si un vendeur refuse de releaser sous GPL un de ses softs pour répondre à un marché public exigeant la GPL ça n'est pas qu'il *peut* pas... c'est qu'il *choisit* de ne pas le faire.
Quatrièmement la notion de licence applicable relève des clauses particulières et à ce titre peut figurer sans souci dans les exigences d'un marché public (confer les guide ci dessous)
Cinquièmment les sites gouvernementaux définissant les bonnes pratiques et les guides à l'usage des organismes adjudicateurs publient des guides de choix concernant les logiciels libres dissipant définitivement tout doute quand aux aspects juridiques des marchés publics :
Pour une approche juridique plus large il y a aussi l'article de l'encyclopédie juridique des bien informatiques (un peu rude à digérer mais très intéressant) http://encyclo.erid.net/document.php?id=491#ftn78
ps : free ils vendent pas aux pro, mais aux particuliers...
Et c'est pour celà qu'un FAI (free ou pas free d'ailleurs) devrait oublier d'être pro ?
Quand une intervention est planifiée sur mon DSLAM j'aimerais recevoir automatiquement une notification qques jours à l'avance... quand un problème survient j'aimerais que l'info arrive naturellement dans ma boite mail même si c'est à posteriori quand le service mail est touché... quand des modifications d'infrastructure ou de paramétrage peuvent influer de façon sensible sur mon ressenti d'utilisateur j'aimerais en être notifié sans avoir besoin de passer ma vie à lurker dans les newsgroups ou sur freenews "au cas où"... ce ne sont pas des news qu'on a "envie de suivre" mais de l'administratif pénible autant que nécessaire... il faut que l'info arrive sans qu'on ait besoin de deviner qu'elle existe... rien a voir avec le plaisir de découvrir du "nouveau" sur un site comme linuxfr... quand je découvre un nouveau soft ou un nouveau site ça me plait, ça m'instruit et je reviens par plaisir... à l'inverse surveiller une liste des ennuis qui arrivent à free à la recherche de ceux qui me pèteront à lag est tout sauf plaisant.
C'est une demande de client parfaitement légitime à mon sens... que je sois pro ou non ça me semble de la plus élémentaire courtoisie de communiquer directement avec un client quand des modifications sont susceptibles d'influer sur le service qu'il paye.
Il y a des fois ou j'ai l'impression qu'un particulier n'est pas un client à part entière... voir même pas un client du tout mais "autre chose" de beaucoup moins noble :-(
Sans compter qu'il est également dit qu'on ne peut pas lancer un marché public concernant l'acquisition d'un logiciel libre, puisque les contrats sont conclus uniquement à titre onéreux. Comment pourrait-on alors exiger un logiciel libre ?
Ben... faut juste savoir lire et faire l'effort de comprendre le texte de la GPL... ou à défaut, pour se faire une bonne idée du truc, de lire la licence CECILL (http://www.cecill.info/licences/Licence_CeCILL_V1-fr.html ) conçue pour être une licence valide en droit français et compatible avec la GPL.
Extrait de la licence CECILL :
5.3. DROITS DE DISTRIBUTION ET DE DIFFUSION
Le droit de distribution et de diffusion comporte notamment le droit de transmettre et de communiquer le Logiciel au public sur tout support et par tout moyen ainsi que le droit de mettre sur le marché à titre onéreux ou gratuit, un ou des exemplaires du Logiciel par tout procédé.
Les logiciels libres n'imposent pas la gratuité... ça ne sera que la cent dix millionième fois que quelqu'un reproduit cet amalgame vaseux consistant à assimiler libre et gratuit alors que ça n'a rien à voir.
Quand à ça :
Les spécifications techniques ne peuvent pas faire mention d'un mode ou procédé de fabrication particulier ou d'une provenance ou origine déterminée, ni faire référence à une marque, à un brevet ou à un type, dès lors qu'une telle mention ou référence aurait pour effet de favoriser ou d'éliminer certains opérateurs économiques ou certains produits.
Le fait qu'un logiciel soit libre ne présume en rien de son mode de fabrication, de sa marque, ou de son origine... en revanche c'est une caractéristique technique (accès libre au code) et juridique (droit modification et de rediffusion) qui peut entrer de plein droit dans une spécification de besoin ou un cahier des charges (ianal ceci dit).
Peut être que l'on peut imaginer le gouvernail dans une position plus "équilibrée" entre :
- un gouvernement élu qui n'a rien à carrer des demandes des gens et qui trace sa route façon "vous m'avez élu... ben je gouverne où est le problème ? Fallait pas m'élire bande de protestataires grincheux"
- un gouvernement qui fait appel au peuple pour tout et n'importe quoi... y compris des questions sans importance.
Aujourd'hui j'ai quand même l'impressions que le gouvernail n'est pas bien à sa place...
Soluce : en fait il faut ajouter /genrePage.do dans l'url... visiblement y'a un souci de config pour la page à afficher par défaut sur leur serveur web.
a propos de drm... mon droit de consulter le site sony a visiblement été désactivé :P
Error 403--Forbidden
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
3) En effet, l'affirmation de l'intérêt du consommateur est à argumenter.
Ce sont aux constructeurs d'argumenter que la vente est dans l'intérêt du consommateur. Rien de valable jusqu'ici...
havivi bien d'accord... mais c'est comme pour DADVSI : à force de répéter cette ânerie il en reste quelque chose qui finit par être accepté comme une vérité. Ca a été le cas avec la prétendue nocivité du p2p... et là c'est exactement pareil.
Donc il faut mettre en lumière cette vacuité d'arguments à propos de la vente liée. Que plus personne ne puisse plus prétendre que cette vente forcée est dans l'intérêt du consommateur sans passer pour un abruti :)
HP a proposé le remboursement intégral... le fait de refuser une solution peut être interprété comme une attitude "cherche-embrouilles"... de là à être débouté il n'y a pas loin.
Quand on veut jouer sur ce terrain il faut bétonner le dossier... prouver qu'il est impossible de se procurer un matériel équivalent sans os à un prix raisonnable... prouver la mauvaise foi du constructeur... pas évident du tout à démontrer (même si nous ne sommes pas dupes on ne peut pas demander à la justice de juger sur des impressions)
Et il y a un point sur lequel il faut encore beaucoup travailler : l'affirmation que l'imposition systématique de cet OS va dans le sens de l'intérêt du consommateur qui sert de paravent pour l'exception de tolérance par rapport au délit de vente liée... Démonter cette contrevérité une bonne fois pour toute permettra d'aplanir le terrain pour les litiges à venir.
Je pense qu'il aurait fallu accepter le remboursement et considérer ça comme une victoire. En accumulant les remboursements d'ordinateurs à cause de l'OS imposé on renforce la démonstration que cette vente forcée n'est pas souhaitée et ne vas pas dans le sens du mieux pour le consommateur.
Bref... sur ce coup là je pense que le groupe a voulu aller plus vite que la musique :-/
# Sinon y'a iFolder
Posté par maat (site web personnel) . En réponse à la dépêche Syncany, une alternative libre à Dropbox avec bien plus de fonctionnalités. Évalué à 1.
http://www.ifolder.com/
Et ça marche depuis un bout de temps...
# Question de noob
Posté par maat (site web personnel) . En réponse à la dépêche Test d'Ubuntu 9.10 (Karmic Koala). Évalué à -2.
------ []
[^] # Re: A l'est, rien de nouveau
Posté par maat (site web personnel) . En réponse à la dépêche Mandriva passe à l'est. Évalué à 3.
Et vous vous êtes planté dans l'anecdote : *mais* la chair est faible... pas *et* la chair est faible :)
Le bikoz : Tentative de traduction cyclique anglais <-> russe par une IA d'une phrase tirée de l'Evangile selon saint Mathieu ( XXVI, 41 ) dont une des traductions françaises est : "L'Esprit est fort, mais la chair est faible."
Essayez de respecter les évangiles quand vous trollez :o)
(je fais du méta-troll de bon matin : la journée s'annonce mal)
[^] # Re: A l'est, rien de nouveau
Posté par maat (site web personnel) . En réponse à la dépêche Mandriva passe à l'est. Évalué à 3.
"guère épais" huhu
[^] # Re: Une analyse et un projet sur noooxml.org
Posté par maat (site web personnel) . En réponse à la dépêche Guerre des formats bureautiques : l'AFNOR veut couper OpenXML en deux !. Évalué à 2.
Il y a un risque non nuls qu'ils considèrent ça comme une attaque en règle et courrent faire des bisous à Microsoft en février 2008. Et dans ce cas il y a fort à parier qu'ils auront plein de bisous en retour :-(
enfin bon... je dis ça je dis rien.
(mais en termes de com et de lobbying je trouve ça moyen quand même)
[^] # Re: ÉH! LES GENS !
Posté par maat (site web personnel) . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 4.
Si vous aviez mis la phrase dans l'autre sens ( code sql "Oracle" à faire tourner sur MySQL ) ou si vous aviez précisé la version de mysql ça aurait pu passer... mais :
En l'occurence les vieilles versions de MySQL n'ont qu'un nombre limité d'entorses connues (mais autorisées) à la norme SQL-3... j'ai relevé :
* le type INT auquel devrait être préféré le type INTEGER de la norme SQL-3,
* le type DEC auquel devrait être préféré le type DECIMAL,
* le type NUMERIC auquel devrait être préféré le type DECIMAL.
Et ces "entorses" étant comprises par Oracle (qui fait la même chose depuis plus longtemps) le code tournera sur Oracle sans modification.
Les versions récentes de MySQL convertissant à la volée INT en INTEGER et NUMERIC en DECIMAL à la création des champs (DEC n'étant même plus proposé), ce demi-problème n'est d'ailleurs plus d'actualité.
Dans l'autre sens en revanche Oracle "offre" un jeu d'entorses à la norme SQL-3 un peu plus grand (ce qui peut se comprendre : plus grosse bestiole et ausi nécessité de gérer la compatibilité ascendante)... et MySQL ne suit pas... ce qui n'est pas un mal.
Liste non exhaustive parce que je ne vais pas me peler la comparaison complète de la ref Oracle et de SQL-3 :
* BFILE qui corresponds à BLOB,
* INT auquel devrait être préféré le type INTEGER,
* DATE qui corresponds à DATETIME,
* LONG qui corresponds à BIGINT,
* LONG RAW qui corresponds à BIGINT,
* NCHAR qui corresponds à CHAR,
* NCLOB qui corresponds à TEXT,
* NUMBER qui corresponds à DECIMAL,
* NUMERIC auquel devrait être préféré le type DECIMAL,
* DEC auquel devrait être préféré le type DECIMAL,
* NVARCHAR2 qui corresponds à VARCHAR,
* RAW qui corresponds à BLOB,
* VARCHAR2 qui corresponds à VARCHAR.
Il y a aussi des types "Maison" qui n'ont pas d'équivalent dans la norme SQL-3 : NATURAL, POSITIVE, PLS_INTEGER, BINARY_INTEGER, SIMPLE_INTEGER, SIGNTYPE...
Sans compter quelques trucs plus tordus comme LOGGING, NOCACHE, NOPARALLEL, BYTE ... qui n'ont pas d'équivalent à ma connaissance dans la norme SQL-3. Ainsi que quelques détails sur CHAR et sur les implémentation des TRIGGERS (mais bon les TRIGGERS sur les vieilles versions de MySQL y'en a pas et sur les versions récentes c'est bien conforme à la norme SQL-3 si je ne m'abuse)
Bref... en réalité du code SQL qui passe pour MySQL a presque 100% de chances de tourner sur Oracle (la reciproque n'est pas "tout à fait vraie" encore huhuhu mais le SQL Oracle récent utilise assez peu ces types exotiques... sauf VARCHAR2 qu'on retrouve à toutes les sauces).
[^] # Re: ÉH! LES GENS !
Posté par maat (site web personnel) . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 3.
Certes les divers serveurs de bases de données n'implémentent pas 100% de la norme SQL et ajoutent parfois leurs petits bricolages perso pour "enrichir" le truc... mais la norme n'a pas été dégueulassée pour "être compatible" avec les bricolages historiques délirants des divers éditeurs de sgbd.
[^] # Re: quelques explications s'il vous plait
Posté par maat (site web personnel) . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 6.
+1
Et dit plus simplement : MS OpenXML est un pseudo format de transition entre tout un ensemble hétéroclite de formats binaires. Pseudo format permettant de mettre en XML sans vraie transformation ces formats (histoire de garder toutes les infos qu'elles soient nécessaires ou non "au kazou" et puis ça évite de trop modifier les logiciels)... et un hypothétique futur format unifié.
Charge à Microsoft (et à personne d'autre compte tenu du fait que les petites infos non documentées rendent l'écriture d'un vrai convertisseur impossible pour quelqu'un d'autre) de fournir dans un avenir plus ou moins lointain :
1) Le fameux format unifié et propre qui lui pourrait mériter d'être estampillé ISO (et qu'on pourrait aussi bien attendre indéfiniment... le status quo pouvant se révéler parfaitement satisfaisant pour Microsoft : quasimonopole préservé et clients toujours capitfs)
2) Le convertisseur entre le format transitionnel MS OpenXML et le format ISO merveilleux en question. (convertisseur qui disposera de toutes les infos nécessaires puisque tout ce qui est dans les binaires aura été conservé "tel quel"... si tant est qu'un tel convertisseur voie le jour huhuhu ayez confiansssse !)
Et autrement dit encore plus simplement : il ne faut surtout pas considérer un bricolage de transition comme un format de référence.
mais ceci n'est que mon point de vue :)
[^] # Re: questions...
Posté par maat (site web personnel) . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 1.
Mais là aussi il y a un hiatus : si on calque "faithfully" on ne peut pas améliorer... et si on améliore alors ça ne peut pas être de l'identique. Deux choses antinomiques dans une seule et même phrase.
"on fait exactement pareil qu'avant... mais mieux" Je n'avais pas relevé cette aberration là digne du "pareil... mais mieux" des Guignols de l'info. Je vous remercie de votre vigilance. Il aurait été dommage de passer à côté de cette perle.
Mais en effet on peut certainement faire autrement et mieux... en particulier en exploitant les conteneurs génériques pour les paramètres spécifiques. Ca éviterait, pour commencer, à ce pauvre OpenXML de se trainer dans la spec autant de casseroles historiques. Et peut être aussi en évitant d'insérer dans le truc des formats redondants par rapport à des formats déjà normalisés (tentative d'en profiter pour faire normaliser en douce des choses qui ne pourraient pas passer autrement ?). Peut être en évitant de laisser trainer des reliquats binaires pour les masques...
La liste est longue et ça n'est pas dans un post qu'on pourra en dresser la liste exhaustive mais tant que Microsoft refusera de remettre son ouvrage sur le métier ça ne risquera pas de bouger.
[^] # Re: questions...
Posté par maat (site web personnel) . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 3.
On va essayer pour commencer de ne pas mélanger les choses :
* le but d'un standard qui est toujours le même : échanger des informations dans un format connu et maitrisé de tous !
* la raison pour laquelle on a besoin de standards qui rejoint (encore heureux) le but premier du standard mais qui au delà touche à des aspects qui concernent la pérennité des données dans le temps (même en cas de faillite du fournisseur de solutions logicielles, même en cas de désaccord majeur avec un éditeur où de décision brutale de celui-ci d'arrêter le suivi d'un format fermé... il n'y a pas que ça mais ça donne déjà une idée d'ensemble)
* la raison pour laquelle un éditeur particulier tente de propulser son format à lui qu'il a pondu au rang officiel de standard.
Comme dans toute démarche alliant le marketing, la stratégie, la communication, la gestion d'un troupeau de clients établi, et le coupage d'herbe sous les pieds des adversaires il n'y a jamais une seule raison qui explique une démarche telle que celle de Microsoft avec OpenXML...
Et dans la mesure ou les objectifs annoncés sur la page que vous avez donné en lien sont directement issus de ce qu'affirme Microsoft nous avons au mieux les objectif officiels de Microsoft... les objectifs réels sont en général un "petit peu" différents (et en ça Microsoft ne diffère en rien des autres grands groupes).... le souci de faire ce qui est le mieux pour les clients n'étant souvent qu'une composante mineure des intentions réelles (bien que 100% des publicités et des communications officielles affirment que c'est le souci premier de 100% des entreprises commeciales... oeuf de course)
Bref... cette petite mise au point lexicale étant faite intéressons nous à cette citation issue des objectifs avoués par Microsoft... (je vais prendre le risque d'en faire une traduction française pour les lecteurs un peu gênés par la langue de Sir Shakespeare... pardon d'avance à tous si c'est moyennement exécuté) :
Une petite remarque sur la fin : sur le fond XML n'apporte pas beaucoup de choses par rapport aux formats binaires (XML est un poil plus facile à manipuler et peut être plus clean techniquement mais bon)... même avec des formats binaires il suffit que les specifications soient publiées pour que plusieurs vendeurs exploitent le truc et que ça se développe sur plusieurs plateformes.
La "technique de l'époque" même avec la sérialisation permet très bien de définir des standards d'échange (certes binaires). Si Microsoft ne l'a pas fait avant ça n'est pas qu'ils ne pouvaient pas... c'est juste qu'ils n'avaient pas envie hein!
Maintenant le plus énorme dans ce texte c'est le hiatus entre la première partie et la deuxième : je le refais au ralenti :
1) On a bestialement calqué les structures binaires anciennes dans le XML ... structures qui étaient optimisées pour les équipements de l'époque et qui ne se justifient plus vraiment aujourd'hui (je zappe le couplet sur les millions d'utilisateurs de de documents existants qui sert juste à rappeller que Microsoft aime ses utilisateurs et ne les oublie pas)
2) même si XML et les nouvelles technologies permettent de faire les choses autrement et mieux.
Mon interprétation de la chose : on pouvait certainement faire mieux mais on avait pas le temps (ou l'envie, et puis ça aurait coûté trop cher) de réfléchir à un format qui exploite à fond les mécanismes et les finesses de XML... donc on a transposé vite fait nos formats binaires en XML... comme ça c'est tout bénéfice :
* On dit qu'on fait de l'XML (même si c'est pas très propre) et puis on dit que c'est open tant qu'à faire hein... c'est vendeur en ce moment :o)
* On a déjà le convertisseur binaire <-> XML qui permet de presque rien toucher à notre suite logicielle
* Vu l'épaisseur de l'engin va falloir se lever de bonne heure pour nous suivre sur ce terrain
* Et si ça peut faire du tort à ODF et Sun et OpenOffice et KDE... mafoi dommage collatéral bien regrettable mais c'est la vie huhuhu
j'ai bon ?
[^] # Re: questions...
Posté par maat (site web personnel) . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 10.
Mon but, contrairement à ce que vous semblez croire, n'est pas de "jouer au con" ou de "chercher la petite bête" mais de vous faire réfléchir au dela des trolls que vous vous complaisez à nourrir... objectif peut être trop ambitieux au vu de vos réactions je dois en convenir avec tristesse.
Que le but affiché d'OpenXML soit la rétrocompatibilité est brillant du point de vue marketing mais lamentable du point de vue technique et financier... et ce sont les clients qui en paieront forcément le prix (comme d'habitude).
Quand on crée un format standard on de crée pas, en principe, une caverne d'ali baba virtuelle ou les trucs les plus sordides pourront cotoyer des joyaux. Un format standard doit permettre de modéliser de façon unique chaque élément que l'on peut trouver dans un type de document donné.
Après c'est le travail de convertiseurs de formats de prendre un fichier dans un format ancien WX pour le convertir sans pertes dans le nouveau format (et si le nouveau format a été spécifié proprement il ne doit pas y avoir d'éléments "non convertissables")
Un pseudo format qui présente des redondances de définition, un formalisme dépendant des applications est tout simplement le signe d'un projet bancal techniquement et mal fini... à mon avis fait par des gens à qui l'on n'a pas laissé le temps de pousser assez loin la spécification. Ca crève les yeux dès qu'on a quelques notions de XML et plus on creuse plus les preuves s'accumulent.
ODF de ce point de vue là est clean et cohérent... que OpenOffice tire parti d'un conteneur générique de paramètres pour faire du formattage conditionnel est affreusement sale mais c'est du détournement d'usage... ça ne remet pas en cause la qualité intrinsèque du format ODF.
En revanche OpenXML de ce point de vue est déplorable puisque le détournement se fait dès la spécification du format. C'est indéfendable et je vous l'ai montré gentiment en vous piégeant.
Plutôt que de reconnaitre qu'openXML en l'état nécessite encore du travail pour constituer un format standard sain vous avez préféré sombrer dans l'insulte... c'est assez mauvais joueur mais pas totalement inattendu.
Ayant appris à respecter mes contradicteurs même quand nos points de vues sont irréconciliables, je terminerai cet échange sterile en vous saluant avec le respect qui vous est dû.
[^] # Re: questions...
Posté par maat (site web personnel) . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 2.
haboooooon vous êtes en train de me dire que FOOXML n'est pas orthogonal en gros ? Qu'il y a des sections différentes qui peuvent servir à la même chose... ptet pas étonnant que ça fasse 6000 pages finalement.
Quand je parlais de malpropreté...
Bon en même temps c'était un peu trop facile... et puéril de ma part de vous tendre ce piège. Je vous présente mes excuses.
[^] # Re: questions...
Posté par maat (site web personnel) . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 2.
Rien pour étayer ? bon tant pis :-(
Comme il est possible vous n'ayez pas bien compris je vais expliquer de façon plus basique :
Ca n'est pas dans ODF tout simplement parce que ça n'a pas besoin d'y être... de la même façon que lorsqu'on définit un entier numérique il n'y a pas besoin de préciser qu'il doit être obligatoirement constitué de chiffres... hébien là on définit un réceptacle pour un ensemble de paramètres... ils vont forcément avoir un nom et une valeur mais il n'y a pas forcément besoin de préciser lesquels dans la spécification du format.
ODF spécifie tout simplement une structure de configuration assez souple <config:config-item>...</config:config-item> permettant aux applications de stocker des paramètres supplémentaires.
Dit encore plus simplement ODF intègre une structure permettant de spécifier ces informations sans avoir besoin de dégueulasser la spécification du format... ce qui est parfaitement conforme aux exigences ISO.
C'est moins sale... moins verbeux... plus élégant... plus souple et plus évolutif que l'approche FOOXML qui s'apparente beaucoup à du hardcoding (très très malpropre) sur ce point.
Exemple avec autoSpaceLikeWord95 :
Le xsd FOOXML spécifie un tag dédié <autoSpaceLikeWord95 val="onOffType" /> qui implique au dela de l'inélégance que :
1) Le standard ne serait plus indépendant de l'appli... un comble pour un standard !
2) Le jour où il faudra spécifier autoSpaceLikeWord2007 il faudra mettre à jour la norme...
Au passage... le conteneur ODF <config:config-item> pourrait très bien contenir un autoSpaceLikeWord95 et même autoSpaceLikeWord2007 sans avoir besoin de faire évoluer la norme ODF... alors que pour déclarer UseFormerLineSpacing dans du FOOXML... ben c'est pas possible en l'état.
Terrible ça : 6000 pages pour faire un truc limité :-(
[^] # Re: questions...
Posté par maat (site web personnel) . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 1.
Objection votre honneur toussa. Il me semble que vous oubliez des choses en route vous aussi :
Le UseFormerLineSpacing en l'occurence est une valeur de paramètre et pas un identifiant de structure XML... autrement dit le format ODF reste "propre" du point de vue historique et indépendante des suites logicielles.
Au contraire le Format Office OXML contient explicitement plein de références à une suite logicielle particulière... ce qui n'est pas la vocation d'un format standard!
En principe on s'appuie sur la règle pour tirer des traits droits... tordre une règle pour la faire épouser je ne sais quelle courbe existante et prétendre qu'elle est droite puisque conforme à la règle me semble un procédé pour le moins étrange.
Vous fournissez donc là un bel argument contre le Format Office OXML il me semble :o)
Par contre il y a derrire toussa une belle critique à faire aux deux approches : dans les deux cas, que ce soit ODF ou F O OXML il y a un degré d'incertitude concernant la mise en page des documents.
Problématique gênante à la quelle on peut répondre dans les cas des suites KOffice et OpenOffice puisque le code est libre et qu'on peut donc déterminer ce qu'impliquent ces paramètres et leurs valeurs.
Dans le cas de Microsoft Office en revanche il devient assez difficile de s'en tirer puisque le code n'est pas acccessible et que la signification de ces structures XML n'a pas été publiée.
En amendant la proposition de Format Office OXML pour intégrer proprement ces infos dans des structures XML neutres et en publiant la signification de ces infos Ms pourrait atteindre le même niveau de clarté (Au passage serait bien que les autres suites bureautiques nous épargnent de piocher dans le code en publiant quelque part... wiki ou autre la signification des paramètres qu'ils utilisent).
my 2 cents
[^] # Re: FOTE
Posté par maat (site web personnel) . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 10.
Quizz historique :
Qui a renommé en 1983 son traitement de texte Multi Tools Word (le Multi semblait devoir être la "marque de fabrique"... le tableur s'appelait Multi Plan) en Word tout court alors que le marché était dominé depuis 1981 par WordStar et que la valeur montante était WordPerfect ?
Qui a créé sa suite Office en 1989 quand le marché regorgeait déjà d'une myriade de suites office ? Pour mémoire WordPerfect Library (1986) renommée en WordPerfect Office (1988), WPS Office (1988), SoftMaker Office (1989), Ability Office (1985)... et ben voui : StarOffice (1986)
Sun a racheté StarOffice en 1999 et releasé les sources en 2001 pour former le projet OpenOffice ( s/Star/Open/ )... je ne pense pas que faire muter Star en Open dans une suite plus vieille que Ms Office puisse être considéré comme une manoeuvre trouble.
En revanche nommer un format "Office Open XML" aka OOXML me semble beaucoup plus douteux compte tenu du contexte...
Mais je vois le mal (presque) partout c'est vrai :P
# très bien (un poil cher tout de même hein)
Posté par maat (site web personnel) . En réponse au message Portable Keynux ou autre ?. Évalué à 2.
Par contre la préconfiguration sous mandriva est un peu rapide... et faite avec la mandriva free. si j'étais mauvaise langue je dirais qu'ils bootent et cliquent sur suivant jusqu'au bout et basta.
résultat : alors que ça peut marcher fantastiquement bien ça marchouille. Le ouifi est pas fonctionnel, les packages sont pas à jour, les medias rpm quasiment pas configurés (y'a tout de même un truc sympa : des copies locales des isos montées en loop... ça évite d'avoir à jouer au grille-pain avec les cdroms), y'a pas java, pas flash...
C'est pas grand chose à rajouter et une fois tunées les configs que j'ai testé marchaient du feu de dieu mais c'est dommage de traiter ce point là un peu (beaucoup) à l'arrache parce que ça peut donner une expérience décevante aux débutants et ça peut agacer les moins débutants de refaire les mêmes manips de config tout le temps.
Vala mon retour :)
ps : Attention tout de même que (sauf erreur de ma part) maintenant c'est pas 100% de leurs configs qui sont full compatibles linux. Une petite vérif prudente peut éviter de mauvaises surprises ;)
[^] # Re: Ça me laisse perplexe...
Posté par maat (site web personnel) . En réponse à la dépêche Insécurité juridique : On a le droit d'exiger du logiciel libre dans les marchés publics. Évalué à 3.
(ps : désolé pour le ton aigre de mon précédent post mais faut éviter de trop fuder aussi c'est agaçant)
tsk. pas bien de déformer mes propos j'ai dit que le fait de demander un logiciel libre relevait à la fois de contraintes techniques *et* juridiques.
Au passage pour le besoin il suffit que l'organisme adjudicateur ait un role de soutien vis à vis d'autres entités publiques pour que le besoin de pouvoir rediffuser une version modifiée prenne tout son sens (il y a aussi les cas de rétrocession dans un souci de réduction des couts ou de protection des modifictions contre l'appropriation expliqués dans le guide pdf que j'ai mis en lien plus bas)
Des caractéristiques techniques... des spécifications techniques pfff premièrement c'est pas la même chose et l'acceptation de la notion de spécifications techniques est terriblement large (définie par décrêt http://www.marche-public.fr/Marches-publics/Textes/Arretes/A(...) )
C'est déjà pas bien net à la base... clairement sujet à interprétation et, histoire d'élargir encore un peu le truc, le décrêt s'offre le luxe de rajouter une couche de flou à l'article 2 histoire de pouvoir jouer avec les cas "non prévus". Autrement dit le caractère technique ou non d'une specification technique est laissé à l'appréciation de l'organisme adjudicateur à condtion que ces spécifications ne tombent pas dans le travers du favoritisme plus ou moins déguisé. Le guide des partiques à éviter sert d'illustration... l'idée fondamentale étant d'éviter les bidouillages de clauses techniques pour "favoriser les copains" hors dans le cas des logiciels libres de telles exigences n'entrent pas dans la catégorie des manoeuvres de favoritisme mais permettent de servir l'intérêt supérieur de l'organisme adjudicateur et à travers lui l'intérêt supérieur du service public.
Deuxièmement les spécifications techniques recouvrent aussi la notion d'exigence fonctionnelle (Article 6 du code des marchés publics de 2006 toussa http://www.marche-public.fr/CMP-2006/Specifications-techniqu(...) )
hors en termes d'exigences fonctionnelles, en particulier pour les organismes de soutien, la possibilité d'accéder aux sources, des les customiser et de les distribuer relève clairement du besoin fonctionnel. La dimension juridique n'est donc clairement pas la seule à entrer en ligne de compte.
Troisièmement une spécification de licence ne présume (je me répète mais visiblement c'est nécessaire) ni de l'origine (n'importe qui peut répondre) ni d'un mode ou d'un procédé de production particulier... et ça ne télescope pas le principe de concurence : si un vendeur refuse de releaser sous GPL un de ses softs pour répondre à un marché public exigeant la GPL ça n'est pas qu'il *peut* pas... c'est qu'il *choisit* de ne pas le faire.
Quatrièmement la notion de licence applicable relève des clauses particulières et à ce titre peut figurer sans souci dans les exigences d'un marché public (confer les guide ci dessous)
Cinquièmment les sites gouvernementaux définissant les bonnes pratiques et les guides à l'usage des organismes adjudicateurs publient des guides de choix concernant les logiciels libres dissipant définitivement tout doute quand aux aspects juridiques des marchés publics :
Guide de choix et d’usage des licences de logiciels libres pour les administrations
http://synergies.modernisation.gouv.fr/article.php3?id_artic(...)
http://synergies.modernisation.gouv.fr/IMG/pdf/Guide_LLL-2.p(...)
Logiciel libre et marchés publics : les obstacles juridiques faciles à dépasser
http://synergies.modernisation.gouv.fr/article.php3?id_artic(...)
Pour une approche juridique plus large il y a aussi l'article de l'encyclopédie juridique des bien informatiques (un peu rude à digérer mais très intéressant)
http://encyclo.erid.net/document.php?id=491#ftn78
[^] # Re: Chez moi ça marche..
Posté par maat (site web personnel) . En réponse au journal SMTP & Free : Free fâché contre les serveurs perso ?. Évalué à 2.
Et c'est pour celà qu'un FAI (free ou pas free d'ailleurs) devrait oublier d'être pro ?
Quand une intervention est planifiée sur mon DSLAM j'aimerais recevoir automatiquement une notification qques jours à l'avance... quand un problème survient j'aimerais que l'info arrive naturellement dans ma boite mail même si c'est à posteriori quand le service mail est touché... quand des modifications d'infrastructure ou de paramétrage peuvent influer de façon sensible sur mon ressenti d'utilisateur j'aimerais en être notifié sans avoir besoin de passer ma vie à lurker dans les newsgroups ou sur freenews "au cas où"... ce ne sont pas des news qu'on a "envie de suivre" mais de l'administratif pénible autant que nécessaire... il faut que l'info arrive sans qu'on ait besoin de deviner qu'elle existe... rien a voir avec le plaisir de découvrir du "nouveau" sur un site comme linuxfr... quand je découvre un nouveau soft ou un nouveau site ça me plait, ça m'instruit et je reviens par plaisir... à l'inverse surveiller une liste des ennuis qui arrivent à free à la recherche de ceux qui me pèteront à lag est tout sauf plaisant.
C'est une demande de client parfaitement légitime à mon sens... que je sois pro ou non ça me semble de la plus élémentaire courtoisie de communiquer directement avec un client quand des modifications sont susceptibles d'influer sur le service qu'il paye.
Il y a des fois ou j'ai l'impression qu'un particulier n'est pas un client à part entière... voir même pas un client du tout mais "autre chose" de beaucoup moins noble :-(
c'est bien dommage.
[^] # Re: Ça me laisse perplexe...
Posté par maat (site web personnel) . En réponse à la dépêche Insécurité juridique : On a le droit d'exiger du logiciel libre dans les marchés publics. Évalué à 5.
Ben... faut juste savoir lire et faire l'effort de comprendre le texte de la GPL... ou à défaut, pour se faire une bonne idée du truc, de lire la licence CECILL (http://www.cecill.info/licences/Licence_CeCILL_V1-fr.html ) conçue pour être une licence valide en droit français et compatible avec la GPL.
Extrait de la licence CECILL :
Les logiciels libres n'imposent pas la gratuité... ça ne sera que la cent dix millionième fois que quelqu'un reproduit cet amalgame vaseux consistant à assimiler libre et gratuit alors que ça n'a rien à voir.
Quand à ça :
Le fait qu'un logiciel soit libre ne présume en rien de son mode de fabrication, de sa marque, ou de son origine... en revanche c'est une caractéristique technique (accès libre au code) et juridique (droit modification et de rediffusion) qui peut entrer de plein droit dans une spécification de besoin ou un cahier des charges (ianal ceci dit).
[^] # Re: Ils voudraient pas nous laisser souffler 5 minutes ?
Posté par maat (site web personnel) . En réponse à la dépêche Régulation du net : un projet de décret inquiétant. Évalué à 5.
- un gouvernement élu qui n'a rien à carrer des demandes des gens et qui trace sa route façon "vous m'avez élu... ben je gouverne où est le problème ? Fallait pas m'élire bande de protestataires grincheux"
- un gouvernement qui fait appel au peuple pour tout et n'importe quoi... y compris des questions sans importance.
Aujourd'hui j'ai quand même l'impressions que le gouvernail n'est pas bien à sa place...
[^] # Re: Par pitié
Posté par maat (site web personnel) . En réponse à la dépêche Richard Cazenave apporte quelques précisions sur la migration de l'Assemblée Nationale vers Linux. Évalué à 1.
(ok ok pas taper j'vais ------->[])
[^] # Re: Site sony de mauvaise humeur
Posté par maat (site web personnel) . En réponse à la dépêche Les DRM au banc des accusés. Évalué à 1.
Bref : la bonne url c'est : http://store.connect-europe.com/genrePage.do
A+
# Site sony de mauvaise humeur
Posté par maat (site web personnel) . En réponse à la dépêche Les DRM au banc des accusés. Évalué à 2.
Leur serveur est peut être déjà sous vista :D
(Je vais finir par voir des DRM partout moi)
[^] # Re: Faut pas chercher les coups non plus :)
Posté par maat (site web personnel) . En réponse à la dépêche Agir contre la vente liée. Évalué à 1.
havivi bien d'accord... mais c'est comme pour DADVSI : à force de répéter cette ânerie il en reste quelque chose qui finit par être accepté comme une vérité. Ca a été le cas avec la prétendue nocivité du p2p... et là c'est exactement pareil.
Donc il faut mettre en lumière cette vacuité d'arguments à propos de la vente liée. Que plus personne ne puisse plus prétendre que cette vente forcée est dans l'intérêt du consommateur sans passer pour un abruti :)
# Faut pas chercher les coups non plus :)
Posté par maat (site web personnel) . En réponse à la dépêche Agir contre la vente liée. Évalué à 7.
Quand on veut jouer sur ce terrain il faut bétonner le dossier... prouver qu'il est impossible de se procurer un matériel équivalent sans os à un prix raisonnable... prouver la mauvaise foi du constructeur... pas évident du tout à démontrer (même si nous ne sommes pas dupes on ne peut pas demander à la justice de juger sur des impressions)
Et il y a un point sur lequel il faut encore beaucoup travailler : l'affirmation que l'imposition systématique de cet OS va dans le sens de l'intérêt du consommateur qui sert de paravent pour l'exception de tolérance par rapport au délit de vente liée... Démonter cette contrevérité une bonne fois pour toute permettra d'aplanir le terrain pour les litiges à venir.
Je pense qu'il aurait fallu accepter le remboursement et considérer ça comme une victoire. En accumulant les remboursements d'ordinateurs à cause de l'OS imposé on renforce la démonstration que cette vente forcée n'est pas souhaitée et ne vas pas dans le sens du mieux pour le consommateur.
Bref... sur ce coup là je pense que le groupe a voulu aller plus vite que la musique :-/
m2c