et je constate qu'effectivement la vitesse d'execution des script bash est plus rapide par rapport a cygwin , vue qu'on a vraiment un bon kernel tux et un systeme de fichier qui va avec correct , il a accès au fichier windows soit via samba soit via cofs (j'ignore ce que c'est ) .
Perso je te suggeres de te renseigner 30 secondes sur comment coLinux (sur lequel andLinux est base) fonctionne avant de raconter n'importe quoi...
Indice: le systeme de fichier est un wrapper par dessus NTFS
Il est impossible de prouver une propriété en faisant de l'analyse statique pour la bonne et simple raison qu'il est impossible pour un programme de vérifier tous les cas. C'est un truc que tu vois dans les 20 premières minutes d'un cours sur l'analyse statique. La seule solution pour prouver le bon fonctionnement d'un programme en un temps raisonnable, c'est de générer des tonnes de faux négatifs. Ça revient à demander à un compilateur de générer des patterns de code. Pourquoi pas, mais c'est documenté? Quid de la vitesse d'exécution?
Qui t'a dit que ca s'arrete a l'analyse statique ?
Et tu rates la moitie du truc quand tu t'arretes a une page d'introduction
Si tu veux vraiment éviter les buffers overflows, il faut contrôler la création de buffers puis tous les accès subséquents. La seule façon crédible de faire ça et vérifier à l'exécution et la seule façon de vérifier et de faire des processeurs qui soient au courant de la taille de ton "buffer".
Ça a déjà été "fait": http://www.cc.gatech.edu/~idoud/documents/TAINTTC.pdf
Et tu crois que qqe APIs suffisent pour un kernel ? Tu n'as visiblement aucune idee de ce qu'un kernel contient.
Maintenant explique moi comment fait .net pour empêcher les buffers overflow alors? C'est de la programmation orientée objet, et une vérification à la compilation à moins que .net interprète ton code.
Si tu crois que .net fait de la verif a la compilation, tu n'as rien ocmpris a .NEt, c'est a l'execution que c'est verifie, et c'est pas interprete (tout comme Java).
Et je me répète, mais y'a pas que les processus qui font des accès mémoire, le matériel aussi. Et le matériel peut être programmé pour faire un accès mémoire qui va modifier les bits que tu veux au bon endroit même si la page mémoire est marquée comme ro (et oui).
Et comment tu lancera un soft qui programmera ton materiel sous Singularity ? Tu ne peux pas.
Tu crois pour je ne sais quelle raison que tu peux faire tourner le code que tu veux sous Singularity, c'est pas le cas.
Comment ils font? 2 choix, soit le manifest décrit le fonctionnement du programme de façon formelle de façon à ce que le kernel puisse voir si c'est normal ou pas.
Soit le manifest ne contient que des informations de plus haut niveau qui permettent à l'OS de choisir de l'exécuter ou pas.
Dans le 2ème cas, le kernel devrait vérifier que le manifest soit pas bidonné, donc, il faut utiliser l'analyseur statique pour vérifier le code.
J'aime l'idée du manifest qui indique les besoins d'un programme, c'est une très bonne chose. Mais c'est pas au kernel de vérifier ça! C'est à un dépôt de vérifier ça puis de livrer les applications à l'utilisateur signées par le dépôt.
Pourquoi centraliser qqe chose qui n'a pas besoin d'etre centralise ? Si un depot ne contient pas le soft que tu veux alors tu peux pas le lancer ? Super
à l'arrogance, je te retourne le compliment. Pourquoi la recherche sur la sécurité mémoire ne s'est pas arrêtée lors de l'arrivée de .net et C#? Oh, mais que je suis bête, c'est simplement parce que C# ne résout rien...
Parce que tout le monde ne veut pas ecrire un OS avec les attributs de Singularity, tout comme tout le monde ne mange pas que des fettuccine comme pates.
De toute façon, C# ne peut être meilleur que la virtualisation ... qui n'est pas de la sécurité.
Il y a toute la partie controle d'acces que visiblement tu as rate.
Je le répète, je suis à l'aise avec ce sujet car j'ai fais mon mémoire de master sur la gestion d'accès aux pages mémoires, j'ai étudié la sécurité durant 3 ans (spécialité mobilité et virtualisation) et je débute dans l'écriture de driver (je bosse sur Nouveau, le driver libre nvidia). Tu fais quoi toi pour me traiter d'incapable?
Je ne te traite pas d'incapable mais d'arrogant. Quand a moi, ca fait plus de 10 ans que je bosses chez MS, dont plus de 6 sur la securite de l'OS et 4 sur la stack reseau, dans le kernel. On va dire que la securite d'un OS je connais.
Super, quel rapport ? Il parle du fait qu'il existe des bouts de code non-manage, ca ne dit rien sur l'architecture de Singularity a part que L4 est plus petit et plus facilement verifiable..
Bla, c'est du vent tout ça. Un processus qui tourne en ring0 reste un processus en ring0 même si y'a le miracle .net et de la vérification statique avant. Un processus en ring0 accède à ce qu'il veut, fait ce qu'il veut et court-circuite le kernel si il veut. C'est irresponsable comme concept.
N'importe quoi. Tu m'expliques comment ce processus passera la verification ?
Un processeur exécute du x86 et pas du C#, y'a pas besoin d'API pour exécuter du code, simplement une zone mémoire où s'écrire et $ip placé au bon endroit.
Tu n'as clairement rien compris, ton code ne s'executera pas si il ne peut pas etre lance car il n'a pas passe la verification.
Comment tu peux oser dire que .net empêche $ip d'aller dans cette zone? Alors oui tu peux marquer les pages mémoires avec les bons droits et utiliser le bit NX pour grandement empêcher ça mais un processus en ring0 a la possibilité d'enlever ce bit. Faire confiance à l'analyse statique pour vérifier ça, c'est vraiment chercher la merde.
Et comment tu mets l'addresse de $ip a ce que tu veux dans Singularity ? Tu ne peux pas, tout comme tu ne peux pas ecrire d'assembleur ou autre code binaire qui s'executera directement sous Singularity.
C'est un peu facile de se défouler sur les membres de l'ISO. MS leur donne un document extrêmement difficile à digérer, on leur dit "faites le en urgence", on obscurcit la procédure, l'ISO pond docilement une "norme" alors que plusieurs principes de base sont piétinés: pas de doublons (et oui, ODF est là pour ça, mais MS n'a aucun intérêt à compléter cette norme grâce à son expertise dans le domaine), et plusieurs implémentations de la norme (alors qu'aucun logiciel aujourd'hui ne sait écrire un document OOXML en mode Strict...).
a) On leur a dit "faites en urgence" ? Non, ils ont refuse la version preliminaire ce qui leur a donne le temps de revoir les differences. Personne n'a obscurcit la procedure, que MS ne controle pas, quand a l'ISO pondant "docilement" une norme, on ne va rien dire sur le fait que l'ISO a passe ODF avec des trous beants hein.
b) ODF est la pour ca ? C'est flagrant oui, ODF en est a 1.2, ISO n'a jamais rien vu passer a par 1.0, il a des trous beants, il etait a l'epoque totalement controle par les concurrents les plus feroces de MS. Bienvenue dans le monde reel.
c) Il y a plusieurs logiciels qui savent ecrire en Strict, simplement pas Office
Tout ce qu'il a réussi à faire, c'est créer une norme ISO qu'il est en fait seul à maîtriser. Et ça, c'est tout sauf une norme. Pour bien faire, il aurait fallu passer par un processus itératif plus long, dans un esprit constructif avec l'ISO. MS n'avait pas de temps de faire les choses correctement, mais ils l'ont fait quand même, et ça ce n'est pas jouer le jeu des standards.
a) Office 2007 avait une version "Basic" qui etait pas tres loin de Starter
b) Tu assumes que les constructeurs installent Office sur la plupart des PCs, ce qui est faux
Epic Fail... Pourquoi se passer de la sécurité presque gratuite apportée par la mmu? Éviter le coût du context switch userspace/kernelspace? C'est vraiment n'importe quoi! Et il se passe quoi si j'écris un programme non managé sur cet "OS"? J'ai accès à toute la ram, aux périphériques, etc...?
Epic fail ? Non l'epic fail c'est toi qui ne comprend pas Singularity et qui n'a pas compris les avantages d'enlever cette barriere ainsi que les barrieres entre processus (message passing sans copie necessaire)
Et il se passe quoi si j'écris un programme non managé sur cet "OS"? J'ai accès à toute la ram, aux périphériques, etc...?
Tu vas le faire tourner comment ton programme non manage exactement ? T'as un API miracle pour le lancer ?
Serieusement, ranges ton arrogance dans l'armoire, et ait un minimum d'humilite. Tu ne comprends visiblement pas grand-chose a l'architecture de Singularity et ses avantages / desavantages , plutot qu'emettre des affirmations farfelues je te suggeres d'y mettre bcp plus de conditionel.
1) Et ? Tu m'expliques le probleme ?
2) Si tu crois que C# se limite a debordements de tampons c'est que tu n'as rien compris a C# et encore moins a Singularity. Ensuite si tu es assez naif pour croire que les problemes de gestion de tampon se reglent avec une API quelconque c'est que tu n'as rien compris a la programmation...
3) De nouveau, tu n'as rien compris, un gestionnaire de paquets depot/app store n'a rien a voir avec la problematique en jeu, ces manifestes c'est pas une histoire de dependance ou securite sur le paquet lui-meme
Pour te donner un bon exemple, tu n'as visiblement rien compris a l'utilite de C# en relation au fait qu'il n'y a pas besoin de barriere kernel/user par exemple.
Pour le reste, tu m'excuseras de bien rigoler sur ton arrogance et la facilite avec laquelle tu rejettes un truc sur lequel plus d'une dizaine de chercheurs experiementes bossent, car visiblement tu ne comprends meme pas le sujet.
Perso je te suggeres de bien reflechir a 2 fois avant de parler de sujets que tu ne comprends pas, et surtout de bien te poser la question suivante : un tas de gars plutot bons et avec plus d'experience que moi bossent dessus, sont-ils vraiment si idiots que ca ou ai-je rate un truc ?
MS a d'abord essayé d'implémenter l'ISO 24500 avec le support de la date ISO 8601. Sauf que l'ISO 24500 était tellement bourée d'incohérences par rapport à l'utilisation de ce format de date normalisé qu'ils ont finalement rebroussé chemin
Tu remarqueras que ce n'est pas MS qui a ajoute ce support ISO 8601 dans Transitional, mais les membres de l'ISO.
Et bien MS a rendu l'ISO 24500 plus floue, et le format de date est maintenant un truc fait maison.
MS n'a rien fait du tout, ils n'ont jamais mis ISO 8601 dans Transitional, c'est l'ISO qui l'a fait.
Et comme actuellement Excel ne sait que respecter la norme en mode "Transitional" pour l'écriture, autant dire que ça ne sert à rien de dire que MS Office respecte une norme. Ça fait joli, mais si au final la norme consiste à dire "ISO 24500 c'est ce qu'écrit MS Office 2010. Débrouillez-vous pour les détails.", ben l'intérêt est nul.
Rien a voir, le format de date est documente, c'est juste un autre format que ISO 8601
Le plus désespérant étant que MS espère que la norme ISO 8601 soit modifiée pour ses petits besoins, alors que dans ton lien c'est clairement la norme 24500 qui est contradictoire.
Tu connais les details du probleme ? Moi non. Partant de la, dur de dire si le probleme est dans ISO 29500 ou dans ISO 8601 auquel il manquerait qqe chose.
Quand a modifier ISO 8601, si c'est ce qui est necessaire tu prefererais quoi d'autre ? Un format non-standard ? Un autre format ISO de date cree ?
Tu peux pas te plaindre que MS joue le jeu des standards et en meme temps te plaindre ue MS veuille standardiser les choses dont il a besoin
Bref, il y a peut-être encore de gros manques dans ODF 1.2, ça progresse lentement, mais au moins quand ODF aura comblé ces manques on n'aura pas l'impression qu'il faudrait tout réécrire pour que ça ressemble enfin à une norme!
Ca reste a voir. Il y a 3 ans tout le monde repetait a tut-tete que ODF c'est super, c'est interoperable, etc... et au final tout le monde se rend compte que c'etait de la poudre aux yeux.
Mais tu as de tout de facon tord. La prochaine version ne respectera pas plus les dates dans le format strict.
Tiens tu es voyant maintenant ? Tu peux me filer les numeros du loto STP ?
Donc la norme ISO defini tel quel il y a 3 ans n'a pas et n'aura jamais d'implementation.
Toujours tes problemes de francais hein. Office 2010 lit Strict et Transitional et ecrit en Transitional, et la prochaine version ecrira et lira en Strict et en Transitional
Microsoft Office 2010 n'est pas capable de supporter les dates ISO et ceci fait parti de la norme ISO/IEC IS 29500 par consequent et ne pourra visiblement jamais.
Je te copie les lignes importantes du lien que j'ai donne et qui prouve mes dires (desole c'est en anglais mais tu trouveras bien quelqu'un pour te le traduire...:
Non c'est toi qui n'a rien compris.
Il y a 2 modes dans ISO 29500 : Strict et Transitional. Tu peux respecter ISO 29500 en ne supportant qu'un des 2 modes, c'est qu'Office 2010 fait pour l'instant en supportant transitional.
Transitional ne demande pas d'ecrire des dates en ISO 8601. Si tu faisais l'effort de lire la page sur MSDN, tu aurais lu que Office 2010 supportait ISO 8601 car c'etait au depart dans transitional, et qu'au final il a ete enleve de transitional, et donc d'Office 2010.
Et une petite citation d'un autre lien (je te laisse le trouver comme exercice dans l'utilisation d'un moteur de recherche).
_
Serial dates for spreadsheet cell values were not allowed in the Strict form and have not been reintroduced in the Strict form by Working Group 4_
Quel guignol quand meme, depuis le tout debut je te dis qu'Office 2010 supporte Transitional et pas Strict, tu sais lire ?
Ah tiens j'ai confondu post et reponse, corrigeons ca.
Mon 1er message est faux ? Prouve le !
Prouve en quoi Office 2010 respecte ISO 29500 transitional moins bien qu'OOo respecte ODF 1.2
Parce que si ta prose est qu'on ne peut pas dire qu'Office 2010 respecte ISO 29500 car la preuve formelle est impossible, alors ta meme logique s'applique a OOo, pourtant tu ne te genes pas pour dire qu'il respecte ODF.
Office 2010 respecte ISO/IEC IS 29500 en mode transitional pour l'ecriture et en mode Strict en lecture, avec le mode Strict en ecriture dans la prochaine version.
Ce qui est 100% vrai. Les dates ISO 8601 ne sont pas dans transitional, partant de la Office 2010 respecte ISO 29500 transitional meme en ecrivant les dates dans l'ancien format.
ISO 8601 a ete enleve de transitional par le comite ISO. MS le supportait dans la beta d'Office 2010, mais apres discussion avec le comite ISO il a ete enleve de transitional, et donc d'Office 2010
Bref encore une fois, tu ne sais pas de quoi tu parles
Fais seulement, donne moi les instructions pour prouver qu'un soft non trivial respecte totalement un format non trivial, et je te donnerai le resultat.
Je ne demandes qu'a suivre tes instructions, pour autant qu'elles existent.
D'ici la, je te suggeres d'aller apprendre ce qu'est un probleme NP-complet
Quel guignol quand meme, tu sais lire ?
Son test est la pour voir si Office 2010 gere "Strict", et comme dit plus haut dans le point a), Office 2010 gere "Transitional", qui inclut les dates en non-ISO 8601
Bref, Office 2010 respecte ISO 29500 sur ce point, en mode Transitional.
Maintenant va reprendre tes cours d'anglais, visiblement tu en as besoin
OOXML n'a pas de probleme de format de date, il supporte plusieurs formats de date, dont le format ISO, et un ancien format pour raisons de compatibilite.
La première version était déjà utilisable pour beaucoup de monde, autant prendre le temps de réfléchir pour éviter les ennuis.
La premiere version etait utilisable par bcp de monde ? Vraiment ? Tu m'excuseras mais je suis d'un tout autre avis.
Les gens restant sous OOo et derives pouvaient certainement utiliser ODF, parce qu'OOo comblait les trous du format selon ses desirs, mais ODF etait et est toujours inutilisable d'une point de vue interop a cause de ses manques. Passer un fichier ODF entre differents softs posait et pose toujours probleme.
Bref, oui ODF est un format de document, non ce n'est pas un format interoperable.
Faut comprendre, c'est de ta faute si ODF a des manques de ce genre. Les experts d'ODF eux, qui avaient deja oublie les formules, le change tracking et j'en passe, n'y sont pour rien, ils n'ont rien fait de faux. Tu ne peux t'en prendre qu'a toi-meme, ca t'apprendra !
Va regarder la difference dans le dictionnaire et la maniere dont ils sont habituellement utilises dans les RFC et specs, et tu comprendras que should ne resoud rien.
[^] # Re: Tres drole
Posté par pasBill pasGates . En réponse au journal andLinux ou comment faire tourner linux dans windows sans virtualbox. Évalué à -2.
CoFS: http://colinux.wikia.com/wiki/Cofs_in_0.6.3
# Tres drole
Posté par pasBill pasGates . En réponse au journal andLinux ou comment faire tourner linux dans windows sans virtualbox. Évalué à -6.
et je constate qu'effectivement la vitesse d'execution des script bash est plus rapide par rapport a cygwin , vue qu'on a vraiment un bon kernel tux et un systeme de fichier qui va avec correct , il a accès au fichier windows soit via samba soit via cofs (j'ignore ce que c'est ) .
Perso je te suggeres de te renseigner 30 secondes sur comment coLinux (sur lequel andLinux est base) fonctionne avant de raconter n'importe quoi...
Indice: le systeme de fichier est un wrapper par dessus NTFS
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -2.
OOXML et ODF sont aussi du bete ASCII (du XML), donc j'en deduis qu'ils sont 100% portable aussi, peu importe le rendu...
[^] # Re: Bonne interview
Posté par pasBill pasGates . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à -1.
Il est impossible de prouver une propriété en faisant de l'analyse statique pour la bonne et simple raison qu'il est impossible pour un programme de vérifier tous les cas. C'est un truc que tu vois dans les 20 premières minutes d'un cours sur l'analyse statique. La seule solution pour prouver le bon fonctionnement d'un programme en un temps raisonnable, c'est de générer des tonnes de faux négatifs. Ça revient à demander à un compilateur de générer des patterns de code. Pourquoi pas, mais c'est documenté? Quid de la vitesse d'exécution?
Qui t'a dit que ca s'arrete a l'analyse statique ?
Tu lis vraiment ce que tu veux lire. C'est le seul intérêt de C# citée dans http://research.microsoft.com/en-us/news/features/singularity.aspx . Je m'arrête donc là.
Et tu rates la moitie du truc quand tu t'arretes a une page d'introduction
Si tu veux vraiment éviter les buffers overflows, il faut contrôler la création de buffers puis tous les accès subséquents. La seule façon crédible de faire ça et vérifier à l'exécution et la seule façon de vérifier et de faire des processeurs qui soient au courant de la taille de ton "buffer".
Ça a déjà été "fait": http://www.cc.gatech.edu/~idoud/documents/TAINTTC.pdf
Et tu crois que qqe APIs suffisent pour un kernel ? Tu n'as visiblement aucune idee de ce qu'un kernel contient.
Maintenant explique moi comment fait .net pour empêcher les buffers overflow alors? C'est de la programmation orientée objet, et une vérification à la compilation à moins que .net interprète ton code.
Si tu crois que .net fait de la verif a la compilation, tu n'as rien ocmpris a .NEt, c'est a l'execution que c'est verifie, et c'est pas interprete (tout comme Java).
Et je me répète, mais y'a pas que les processus qui font des accès mémoire, le matériel aussi. Et le matériel peut être programmé pour faire un accès mémoire qui va modifier les bits que tu veux au bon endroit même si la page mémoire est marquée comme ro (et oui).
Et comment tu lancera un soft qui programmera ton materiel sous Singularity ? Tu ne peux pas.
Tu crois pour je ne sais quelle raison que tu peux faire tourner le code que tu veux sous Singularity, c'est pas le cas.
Comment ils font? 2 choix, soit le manifest décrit le fonctionnement du programme de façon formelle de façon à ce que le kernel puisse voir si c'est normal ou pas.
Soit le manifest ne contient que des informations de plus haut niveau qui permettent à l'OS de choisir de l'exécuter ou pas.
Dans le 2ème cas, le kernel devrait vérifier que le manifest soit pas bidonné, donc, il faut utiliser l'analyseur statique pour vérifier le code.
J'aime l'idée du manifest qui indique les besoins d'un programme, c'est une très bonne chose. Mais c'est pas au kernel de vérifier ça! C'est à un dépôt de vérifier ça puis de livrer les applications à l'utilisateur signées par le dépôt.
Pourquoi centraliser qqe chose qui n'a pas besoin d'etre centralise ? Si un depot ne contient pas le soft que tu veux alors tu peux pas le lancer ? Super
à l'arrogance, je te retourne le compliment. Pourquoi la recherche sur la sécurité mémoire ne s'est pas arrêtée lors de l'arrivée de .net et C#? Oh, mais que je suis bête, c'est simplement parce que C# ne résout rien...
Parce que tout le monde ne veut pas ecrire un OS avec les attributs de Singularity, tout comme tout le monde ne mange pas que des fettuccine comme pates.
De toute façon, C# ne peut être meilleur que la virtualisation ... qui n'est pas de la sécurité.
Il y a toute la partie controle d'acces que visiblement tu as rate.
Je le répète, je suis à l'aise avec ce sujet car j'ai fais mon mémoire de master sur la gestion d'accès aux pages mémoires, j'ai étudié la sécurité durant 3 ans (spécialité mobilité et virtualisation) et je débute dans l'écriture de driver (je bosse sur Nouveau, le driver libre nvidia). Tu fais quoi toi pour me traiter d'incapable?
Je ne te traite pas d'incapable mais d'arrogant. Quand a moi, ca fait plus de 10 ans que je bosses chez MS, dont plus de 6 sur la securite de l'OS et 4 sur la stack reseau, dans le kernel. On va dire que la securite d'un OS je connais.
Et puis si encore j'étais le seul: http://www.ok-labs.com/blog/entry/about-security-singularity-vs-l4-part-2/ Et j'ai passé 10s sur google pour le trouver.
Super, quel rapport ? Il parle du fait qu'il existe des bouts de code non-manage, ca ne dit rien sur l'architecture de Singularity a part que L4 est plus petit et plus facilement verifiable..
[^] # Re: Bonne interview
Posté par pasBill pasGates . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 4.
Bla, c'est du vent tout ça. Un processus qui tourne en ring0 reste un processus en ring0 même si y'a le miracle .net et de la vérification statique avant. Un processus en ring0 accède à ce qu'il veut, fait ce qu'il veut et court-circuite le kernel si il veut. C'est irresponsable comme concept.
N'importe quoi. Tu m'expliques comment ce processus passera la verification ?
Un processeur exécute du x86 et pas du C#, y'a pas besoin d'API pour exécuter du code, simplement une zone mémoire où s'écrire et $ip placé au bon endroit.
Tu n'as clairement rien compris, ton code ne s'executera pas si il ne peut pas etre lance car il n'a pas passe la verification.
Comment tu peux oser dire que .net empêche $ip d'aller dans cette zone? Alors oui tu peux marquer les pages mémoires avec les bons droits et utiliser le bit NX pour grandement empêcher ça mais un processus en ring0 a la possibilité d'enlever ce bit. Faire confiance à l'analyse statique pour vérifier ça, c'est vraiment chercher la merde.
Et comment tu mets l'addresse de $ip a ce que tu veux dans Singularity ? Tu ne peux pas, tout comme tu ne peux pas ecrire d'assembleur ou autre code binaire qui s'executera directement sous Singularity.
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -2.
Les specs que je vois avec des dizaines de changements disent le contraire.
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -3.
C'est un peu facile de se défouler sur les membres de l'ISO. MS leur donne un document extrêmement difficile à digérer, on leur dit "faites le en urgence", on obscurcit la procédure, l'ISO pond docilement une "norme" alors que plusieurs principes de base sont piétinés: pas de doublons (et oui, ODF est là pour ça, mais MS n'a aucun intérêt à compléter cette norme grâce à son expertise dans le domaine), et plusieurs implémentations de la norme (alors qu'aucun logiciel aujourd'hui ne sait écrire un document OOXML en mode Strict...).
a) On leur a dit "faites en urgence" ? Non, ils ont refuse la version preliminaire ce qui leur a donne le temps de revoir les differences. Personne n'a obscurcit la procedure, que MS ne controle pas, quand a l'ISO pondant "docilement" une norme, on ne va rien dire sur le fait que l'ISO a passe ODF avec des trous beants hein.
b) ODF est la pour ca ? C'est flagrant oui, ODF en est a 1.2, ISO n'a jamais rien vu passer a par 1.0, il a des trous beants, il etait a l'epoque totalement controle par les concurrents les plus feroces de MS. Bienvenue dans le monde reel.
c) Il y a plusieurs logiciels qui savent ecrire en Strict, simplement pas Office
Tout ce qu'il a réussi à faire, c'est créer une norme ISO qu'il est en fait seul à maîtriser. Et ça, c'est tout sauf une norme. Pour bien faire, il aurait fallu passer par un processus itératif plus long, dans un esprit constructif avec l'ISO. MS n'avait pas de temps de faire les choses correctement, mais ils l'ont fait quand même, et ça ce n'est pas jouer le jeu des standards.
Et c'est exactement la meme chose avec ODF
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -6.
Super, ca montre quoi a part qu'il y a eu un lobbyisme crasse de la part de Google & IBM ? Rien
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à 0.
a) Office 2007 avait une version "Basic" qui etait pas tres loin de Starter
b) Tu assumes que les constructeurs installent Office sur la plupart des PCs, ce qui est faux
[^] # Re: Bonne interview
Posté par pasBill pasGates . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 6.
Epic Fail... Pourquoi se passer de la sécurité presque gratuite apportée par la mmu? Éviter le coût du context switch userspace/kernelspace? C'est vraiment n'importe quoi! Et il se passe quoi si j'écris un programme non managé sur cet "OS"? J'ai accès à toute la ram, aux périphériques, etc...?
Epic fail ? Non l'epic fail c'est toi qui ne comprend pas Singularity et qui n'a pas compris les avantages d'enlever cette barriere ainsi que les barrieres entre processus (message passing sans copie necessaire)
Et il se passe quoi si j'écris un programme non managé sur cet "OS"? J'ai accès à toute la ram, aux périphériques, etc...?
Tu vas le faire tourner comment ton programme non manage exactement ? T'as un API miracle pour le lancer ?
Serieusement, ranges ton arrogance dans l'armoire, et ait un minimum d'humilite. Tu ne comprends visiblement pas grand-chose a l'architecture de Singularity et ses avantages / desavantages , plutot qu'emettre des affirmations farfelues je te suggeres d'y mettre bcp plus de conditionel.
[^] # Re: Bonne interview
Posté par pasBill pasGates . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 4.
1) Et ? Tu m'expliques le probleme ?
2) Si tu crois que C# se limite a debordements de tampons c'est que tu n'as rien compris a C# et encore moins a Singularity. Ensuite si tu es assez naif pour croire que les problemes de gestion de tampon se reglent avec une API quelconque c'est que tu n'as rien compris a la programmation...
3) De nouveau, tu n'as rien compris, un gestionnaire de paquets depot/app store n'a rien a voir avec la problematique en jeu, ces manifestes c'est pas une histoire de dependance ou securite sur le paquet lui-meme
Pour te donner un bon exemple, tu n'as visiblement rien compris a l'utilite de C# en relation au fait qu'il n'y a pas besoin de barriere kernel/user par exemple.
Pour le reste, tu m'excuseras de bien rigoler sur ton arrogance et la facilite avec laquelle tu rejettes un truc sur lequel plus d'une dizaine de chercheurs experiementes bossent, car visiblement tu ne comprends meme pas le sujet.
Perso je te suggeres de bien reflechir a 2 fois avant de parler de sujets que tu ne comprends pas, et surtout de bien te poser la question suivante : un tas de gars plutot bons et avec plus d'experience que moi bossent dessus, sont-ils vraiment si idiots que ca ou ai-je rate un truc ?
Ca t'aidera bcp dans ta carriere.
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -2.
MS a d'abord essayé d'implémenter l'ISO 24500 avec le support de la date ISO 8601. Sauf que l'ISO 24500 était tellement bourée d'incohérences par rapport à l'utilisation de ce format de date normalisé qu'ils ont finalement rebroussé chemin
Tu remarqueras que ce n'est pas MS qui a ajoute ce support ISO 8601 dans Transitional, mais les membres de l'ISO.
Et bien MS a rendu l'ISO 24500 plus floue, et le format de date est maintenant un truc fait maison.
MS n'a rien fait du tout, ils n'ont jamais mis ISO 8601 dans Transitional, c'est l'ISO qui l'a fait.
Et comme actuellement Excel ne sait que respecter la norme en mode "Transitional" pour l'écriture, autant dire que ça ne sert à rien de dire que MS Office respecte une norme. Ça fait joli, mais si au final la norme consiste à dire "ISO 24500 c'est ce qu'écrit MS Office 2010. Débrouillez-vous pour les détails.", ben l'intérêt est nul.
Rien a voir, le format de date est documente, c'est juste un autre format que ISO 8601
Le plus désespérant étant que MS espère que la norme ISO 8601 soit modifiée pour ses petits besoins, alors que dans ton lien c'est clairement la norme 24500 qui est contradictoire.
Tu connais les details du probleme ? Moi non. Partant de la, dur de dire si le probleme est dans ISO 29500 ou dans ISO 8601 auquel il manquerait qqe chose.
Quand a modifier ISO 8601, si c'est ce qui est necessaire tu prefererais quoi d'autre ? Un format non-standard ? Un autre format ISO de date cree ?
Tu peux pas te plaindre que MS joue le jeu des standards et en meme temps te plaindre ue MS veuille standardiser les choses dont il a besoin
Bref, il y a peut-être encore de gros manques dans ODF 1.2, ça progresse lentement, mais au moins quand ODF aura comblé ces manques on n'aura pas l'impression qu'il faudrait tout réécrire pour que ça ressemble enfin à une norme!
Ca reste a voir. Il y a 3 ans tout le monde repetait a tut-tete que ODF c'est super, c'est interoperable, etc... et au final tout le monde se rend compte que c'etait de la poudre aux yeux.
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -3.
Mais tu as de tout de facon tord. La prochaine version ne respectera pas plus les dates dans le format strict.
Tiens tu es voyant maintenant ? Tu peux me filer les numeros du loto STP ?
Donc la norme ISO defini tel quel il y a 3 ans n'a pas et n'aura jamais d'implementation.
Toujours tes problemes de francais hein. Office 2010 lit Strict et Transitional et ecrit en Transitional, et la prochaine version ecrira et lira en Strict et en Transitional
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à 0.
Microsoft Office 2010 n'est pas capable de supporter les dates ISO et ceci fait parti de la norme ISO/IEC IS 29500 par consequent et ne pourra visiblement jamais.
Je te copie les lignes importantes du lien que j'ai donne et qui prouve mes dires (desole c'est en anglais mais tu trouveras bien quelqu'un pour te le traduire...:
Non c'est toi qui n'a rien compris.
Il y a 2 modes dans ISO 29500 : Strict et Transitional. Tu peux respecter ISO 29500 en ne supportant qu'un des 2 modes, c'est qu'Office 2010 fait pour l'instant en supportant transitional.
Transitional ne demande pas d'ecrire des dates en ISO 8601. Si tu faisais l'effort de lire la page sur MSDN, tu aurais lu que Office 2010 supportait ISO 8601 car c'etait au depart dans transitional, et qu'au final il a ete enleve de transitional, et donc d'Office 2010.
Et une petite citation d'un autre lien (je te laisse le trouver comme exercice dans l'utilisation d'un moteur de recherche).
_
Serial dates for spreadsheet cell values were not allowed in the Strict form and have not been reintroduced in the Strict form by Working Group 4_
Quel guignol quand meme, depuis le tout debut je te dis qu'Office 2010 supporte Transitional et pas Strict, tu sais lire ?
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -1.
Je cree un format d'image proprietaire et cree des documents contenant ces images.
Ton soft a toi il ne pourra pas lire ce document correctement, malgre toutes les bonnes intentions du monde.
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -2.
Ah tiens j'ai confondu post et reponse, corrigeons ca.
Mon 1er message est faux ? Prouve le !
Prouve en quoi Office 2010 respecte ISO 29500 transitional moins bien qu'OOo respecte ODF 1.2
Parce que si ta prose est qu'on ne peut pas dire qu'Office 2010 respecte ISO 29500 car la preuve formelle est impossible, alors ta meme logique s'applique a OOo, pourtant tu ne te genes pas pour dire qu'il respecte ODF.
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -2.
Toujours tes problemes de comprehension du francais je vois, mon commentaire : http://linuxfr.org/nodes/86034/comments/1233701
Je dis :
Office 2010 respecte ISO/IEC IS 29500 en mode transitional pour l'ecriture et en mode Strict en lecture, avec le mode Strict en ecriture dans la prochaine version.
Ce qui est 100% vrai. Les dates ISO 8601 ne sont pas dans transitional, partant de la Office 2010 respecte ISO 29500 transitional meme en ecrivant les dates dans l'ancien format.
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à 4.
Ou as tu vu que transitional specifiait l'utilisation des dates ISO ?
cf. http://msdn.microsoft.com/en-us/openspecifications/gg482167
ISO 8601 a ete enleve de transitional par le comite ISO. MS le supportait dans la beta d'Office 2010, mais apres discussion avec le comite ISO il a ete enleve de transitional, et donc d'Office 2010
Bref encore une fois, tu ne sais pas de quoi tu parles
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -2.
Fais seulement, donne moi les instructions pour prouver qu'un soft non trivial respecte totalement un format non trivial, et je te donnerai le resultat.
Je ne demandes qu'a suivre tes instructions, pour autant qu'elles existent.
D'ici la, je te suggeres d'aller apprendre ce qu'est un probleme NP-complet
Merci d'avoir joue
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à 1.
La norme ISO contient Strict et Transitional
cf. http://www.iso.org/iso/pressrelease.htm?refid=Ref1181 et la 4eme partie
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -4.
Le jour ou tu me montreras qu'OOo respecte ODF 1.0, 1.1 ou 1.2 (au choix) totalement, je me ferais un plaisir de faire la meme chose pour Office
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -1.
Quel guignol quand meme, tu sais lire ?
Son test est la pour voir si Office 2010 gere "Strict", et comme dit plus haut dans le point a), Office 2010 gere "Transitional", qui inclut les dates en non-ISO 8601
Bref, Office 2010 respecte ISO 29500 sur ce point, en mode Transitional.
Maintenant va reprendre tes cours d'anglais, visiblement tu en as besoin
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à 2.
Ils ont oublié ou ils n'ont pas voulu faire un truc à la Rache© avec des problème sur les formats de date?
OOXML n'a pas de probleme de format de date, il supporte plusieurs formats de date, dont le format ISO, et un ancien format pour raisons de compatibilite.
La première version était déjà utilisable pour beaucoup de monde, autant prendre le temps de réfléchir pour éviter les ennuis.
La premiere version etait utilisable par bcp de monde ? Vraiment ? Tu m'excuseras mais je suis d'un tout autre avis.
Les gens restant sous OOo et derives pouvaient certainement utiliser ODF, parce qu'OOo comblait les trous du format selon ses desirs, mais ODF etait et est toujours inutilisable d'une point de vue interop a cause de ses manques. Passer un fichier ODF entre differents softs posait et pose toujours probleme.
Bref, oui ODF est un format de document, non ce n'est pas un format interoperable.
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à -3.
Faut comprendre, c'est de ta faute si ODF a des manques de ce genre. Les experts d'ODF eux, qui avaient deja oublie les formules, le change tracking et j'en passe, n'y sont pour rien, ils n'ont rien fait de faux. Tu ne peux t'en prendre qu'a toi-meme, ca t'apprendra !
[^] # Re: Vraiment ?
Posté par pasBill pasGates . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à 1.
should
must
Va regarder la difference dans le dictionnaire et la maniere dont ils sont habituellement utilises dans les RFC et specs, et tu comprendras que should ne resoud rien.