J'ai lu quelques trucs qui laisse le sous-entendre.
Rien de très consistant. Il reste deux mois pour porter plainte. Des bruits circules qu'IBM est en train afûter les couteaux et un blog de MS joue déjà la victime de l'ignoble et sans scrupule IBM.
Ton ZOB-XML est très existant et j'ai bien envie de me le prendre. Mais est-il optimisé brown orifice avec droit d'exclusivité (brevet et toussa) ? Parce que tant qu'à mis mettre, je préfère être tout seul et ne pas avoir ODF qui me pèle le jon.
L'argumentaire est pertinent.
Mais pour ODF on est dans le domaine des standards ouverts (les vrais, pas les usurpé)s. Pour ODF on est dans le domaine du libre. Beaucoup de "libristes" ne veulent pas de MS-OOXML car il n'est pas libre. Qu'il soit (peut-être) meilleur ou plus utilisé que ODF est to-ta-le-ment accessoire. Donc l'évolution de ODF est beaucoup moins contrainte par des enjeux commerciaux ou de défense de monopole que MS-OOXML. ODF prendra la voix qui lui convient le mieux, la plus efficace. N'oublions pas que les ressources disponibles pour ODF (et OOo) sont bien moindres que celles pour MS-OOXML.
ODF (et OOo) est inscrit dans le long terme. Et in fine, a mon avis, et à l'instart de Mozilla/Firefox, ça payera. Ça sera une sorte de conséquence et non un objectif tenu.
D'ailleurs beaucoup s'intérogent sérieusement sur la pérénité de MS-OOXML et ne voit en lui qu'un format transitoire. Ce qui n'est pas du tout le cas de ODF.
Ce n'est pas une concurrence classique comme on le voit dans le logiciel proprio.ODF (et OOo) peut se permettre d'être moins bon que MS-OOXML/MS-Office et pour longtemps. MS ne peut pas se permettre d'être pris de vitesse par ODF. La brutalité de la réaction pour être ratifié ISO le démontre. Oui MS-OOXML est une place forte. Mais avec une certaine fragilité qu'on aurait tord de sous-estimer (ce que ne fait pas MS).
D'une certaine manière le raisonnement est frappé du bon sens.
Mais pourquoi tu n'inverses pas les rôles ?
Il n'y a que MS qui va maintenir MS-OOXML. MS-OOXML est un format MS pour MS. Si quelqu'un propose, par exemple, de le rendre réellement plus intéropérable, de le rapprocher d'ODF, etc, MS ne voudra pas. Et c'est exactement ce qu'ont a vu durant l'ISO malgrés une participation massive et un nombre de commentaires "délirants". Mais au final, la norme est telle que veux MS et non telle que veut l'ensemble des participants à l'ISO.
Participes à MS-OOXML si tu veux. Mais ça sera comme parler dans un puit sans fond.
En passant, il n'y a que la maintenance (au sens ISO, c-à-d les corrections mineurs) qui ne sera pas faite par MS. Les décisions importantes sont prises par MS.
Bref, ce n'est pas un standard ouvert !
Les mailings sont fermées, ont ne sait qu'au dernier moment les décisions prises, etc.
Notons que MS a poussé la normalisation lorsque MS avait le produit ! La norme MS-OOXML n'est pas le format MS-Office 2007, mais il s'en est fallu très peu et ce n'est pas faute à MS d'avoir essayé.
Et pour la prochaine version de MS-OOXML, c'est ce qu'on va voir encore. MS va développer son produit et un peu avant qu'il soit terminé il va faire normaliser la nouvelle version. MS se donne un atout anti-concurrentiel. Ceci n'a rien à voir avec l'ISO ou des standards ouverts. Avec MS, une norme est conçu suivant un produit alors qu'il faudrait concevoir les produits selon une norme (évidemment largement discuté en amont).
Dans ses conditions, pourquoi diable aider MS ?
N'oublions pas la nature du libre. Le libre c'est être libre. Le libre ne va pas aller s'emprisonner avec MS-OOXML.
Rob Weir explique ça très bien : http://www.robweir.com/blog/2008/01/standard-trolls.html
Or, in plain English, in order to be able to claim conformance with OOXML, an application must not crash when presented with a valid OOXML document, or must be able of producing at least a single valid OOXML document. This is not exactly a high threshold.
Some examples of applications that support OOXML by that definition:
1. The DOS "copy" command is a conforming OOXML consumer and producer, since it can accept and produce valid OOXML documents.
2. The DOS "del" command is a valid OOXML consumer, and one which I heartily recommend.
3. WinZip, PkWare and every other Zip application out there are also conforming producers and consumers of OOXML.
4. Every text editor and every XML editor and every other application that can consume text or XML also supports OOXML.
etc
On est ravis d'apprendre que les commandes copy et del sont couvertes par OSP.
http://www.microsoft.com/france/interop/osp/default.mspx
Pour clarifier, les « Revendications Microsoft nécessaires » représentent les revendications de brevets détenus ou contrôlés par Microsoft qui sont nécessaires pour implémenter uniquement les parties requises de la Spécification couverte qui sont décrites en détail
Et qu'es-ce qui est requis par MS-OOXML ?
Pratiquement rien.
De la spec MS-OOXML : 2.5 Application Conformance
Application conformance is purely syntactic; it also involves only Items 1 and 2 in §2.3 above.
* A conforming consumer shall not reject any conforming documents of the document type (§4) expected by that application.
* A conforming producer shall be able to produce conforming documents.
Pour mesurer la catastrophe qu'a été cette ratification, remarquons que la norme n'est pas encore faite ! MS l'a promis pour fin mars et elle n'est pas là. Notons que pour prendre une décision dans ces conditions...
Il y a la spèc soumis par l'ECMA et un gros patch de 2300 pages (!) réalisé à l'arrache et discuté durant une semaine.
C'est incroyable, mais c'est ça qu'a ratifié l'ISO ! Une norme super mauvaise et inconnue...
Pas seulement eux. Mais aussi les libristes qui pensent qu'il faut "collaborer" avec MS. MS est hyper ambigü dans les discours. MS nous parle d'intéropérabilité, que le nouveau MS arrive (voire le bruit fait sur la disponibilité de doc alors que c'est seulement la conséquence des exigences légitimes de l'UE, l'ultra flou OSP à l'incompatibilité GPL non avouée, des sites web à gogo qui se veulent neutres et open, etc).
Il n'y a pas de nouveaux MS. C'est le même, légèrement adapté pour leurer.
Le titre m'a bien fait rigoler. Non qu'il soit à côté de la plaque, il est tout à fait juste, mais à cause du dernier blog de Brian Jones de MS. Blog semble-t-il bien préparé par le département communication de MS : http://blogs.msdn.com/brian_jones/archive/2008/04/01/open-xm(...)
Open XML Overwhelmingly Approved as an ISO / IEC standard (IS 29500): the end of the file formats war
En passant, ce blog court de Rob Weir : http://www.robweir.com/blog/2008/04/new-paths-in-standardiza(...)
Now that it has been demonstrated that pushing proprietary interfaces, protocols and formats through ISO is cheaper and faster than writing code to implement existing open standards, one assumes that the future is bright for more such boutique standards from Redmond. Open HTML, anyone?
Mais c'est clair depuis le début.
M'enfin tu ne peux (ou ne devrais pas) sous-entendre qu'un tar (gzip en plus ou pas) n'est pas un backup. C'est un backup avec ses faibles comme tous les backups.
Tu peux le juger moins fiable, c'est tout à fait recevable et compréhensible.
J'évite les archives et la compression seulement car c'est moins pratique (ça ne se prête pas à un rsync par exemple). Pas car c'est (forcément) moins fiable.
Si tu fais un mirroir de kernel.org, tu n'as pratiquement que des fichiers compressés, mais c'est un backups. Évidemment si tu mets le tout dans un gros tar de 10 To, ce n'est pas malin.
Tips and tricks: How can I increase the security of my workstations?
1. First delete the password lists for all profiles on the machine. del c:windows*.pwl
2. From the command line: REGEDIT /s \MY_PDCnetlogonnocache.reg
This will run regedit with no program output and a registry input file named nocache.reg, which looks like this: REGEDIT4
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesNetwork]
"DisablePwdCaching"=dword:00000001
3. Save that as plain text and name it nocache.reg.
Following these steps will greatly increase the security of your Windows 9x machines. Enjoy!
Mais ce n'était pas vraiment de ma faute. J'avais une nouvelle bécane de développement. Pour le développement, on a le mot de passe root. Je demande le mot de passe à l'admin, il me le donne et je le sent un peu embarassé.
Quelques minutes après je veux rebooter la bécane (pour passer sur la dernière version de l'OS et faire des tests/portages/etc), je fais "su ... reboot". Sauf que j'étais sur le serveur...
Cet "abrutis" d'admin avait mis le même mot de passe root sur ma bécane que sur le serveur.
Heureusement ce n'était pas 30 000 utilisateur, mais une bonne cinquantaine. En 5 secondes on m'enformait que le serveur était down. Ce qui expliquait que ma bécane n'était en train de rebooter...
> Maintenant, si tu as des arguments au niveau algorithmique justifiant le fait que gzip est génial pour du backup
Je n'ai pas dit ça.
Je n'ai pas dit que X ou Y est génial.
En passant, je n'utilise pas tar.
> Personnellement, JE t'ai sorti plein d'infos avec des sources tel que les RFC, les descriptions des algorithmes qui permettent de se faire une opinion argumenté ...
Ton raisonnement est : si ça va de travers, ben ça va de travers. Et si tu utilises tar ou gzip, ça ira encore plus de travers. ON EST D'ACCORD !
Mais si mon fichier tar ou gzip est pourri, ben je le sais. Et je récupère un sauvegarde précédante. Je ne vais pas prendre le risque de vaguement restaurer un truc. Et toi ? Et restaure vaguement des trucs ?
Si un backup a un problème, ben il a un problème. Et même si ce n'est qu'un fichier, va savoiir quelles sont répercutions.
Oui, si un secteur de disque dur ou bande magnétique déconne ben t'aura plus de problème avec tar/gzip que si tu utilises rien. C'est évident, pas besoin de RFC pour savoir ça.
Mais tu (ou je) peux aussi dire, arguments (ou RFC) à l'appuis, qu'un système de fichier c'est dangereux pour les backups car si il déconne t'es dans la merde et qu'il vaut mieux et "tar .... > /dev/sdm" qu'un "cp -r ... [destination]". Que ODF qui groupe des fichiers dans une archive c'est plus dangereux que si c'est non compressé et dispersé sur plusieurs fichiers. Qu'un système de fichier + journalisation + lvm + raid c'est HYPER dangereux car il suffit qu'un seul déconne pour être dans une merde noir. A chaque fois que tu ajoutes un truc, il y a un risque.
Mais si tar (ou cpio, ou rsync ou gzip ou...) marche, ben il marche (et ce n'est pas de la croyance, c'est un constat). Si ton système raid/lwn/ext3/pg_dump marche, ben il marche. Si les archives compressées de ODF marchent, ben elle marchent. Au fais, tu décompresses systématiquement tes fichiers ODF ?
J'imagine que tu dois rêver d'un SDB qui mets chaque enregistrement et chaque champs dans un fichier séparé... Pour le "au cas où" (comme pour le "au cas où un bit de ton gzip ....")
Tu peux aussi éviter les disques durs, les bandes magnétiques, etc car ils finissent tous par planter et privilégier la pierre gravée tant que tu y es.
Il y a toujours un risque. Mais il doit être évalué.
Es-ce que utiliser tar un gros risque ?
Je ne crois pas. Du moins si l'ensemble sauvegarde/restauration est sérieusement testé ET plusieurs sauvegardes archivées (rotation).
Si je peux éviter tar, ben j'évite tar. Si tar me rend service, ben je l'utilise.
J'utilise, et ça va être un standal pour toi, le format "custom" de pg_dump (PosgreSQL) qui par défaut est compressé. Et je ne suis VRAIMENT pas le seul. Ça présente plein d'avantage par rapport au dump SQL "plain". Es-ce un risque ? Oui. Mais ridicule. Et ça marche (comme tes serveurs en prod).
> "RFC" contre "croyance benoite"
Lis ce que j'ai écris.
Si j'avais une "croyance benoite" tu crois que je vérifierais mes backup et procédures de restauration tous les mois ?
> "RFC"
Ben lit la doc sur ext3, et ext3 comme tar, s'il y a un problème de disque (secteur ou autres) ou qu'un problème d'OS, ou la mémoire vive qui déconne, ben tu n'es pas à l'abris de perdre des donnés (un secteur, un cluster, un group ou 1000 fois pire). C'est hypra clair. Pourtout tu utilises bien des systèmes de fichier ?
Tar est une sorte de un système de fichier, ça a les mêmes problèmes.
> Pour quel raison faire un upgrade d'une version majeur d'un SGBD alors que tu as une prod qui fonctionne ( hors faille de sécurité ) ?
Car tu ne sauvegardes pas les serveurs de développement, pré-production ?
C'est les développeurs qui vont être heureux d'entendre ça...
Puis le "ça marche je n'y touche pas" il est vrai pour une période donnée. Sinon les admins seraient au chômage.
Il y a plein de serveur en production qui doivent évoluer. Et parfois tu ne peux pas avoir la base de production complète en test (trop cher) et faire des tests exhautif.
> ON NE COUPE PAS UN SERVICE QUI FONCTIONNE !
BEN MES BACKUPS GZIP, PG_DUMP, ETC MARCHENT !
> pour moi, si il y a une mise à jour du sgbd, il y a test, recette et donc vérification de la compatibilité de tous le systeme d'information pour toi, tu fais le jacgeek, tu fais du tuning de soft plutot que que voiture, mais c'est pareil, plus le numero de version est gros et plus tu es content.
Puisque tu le dis...
T'as trouvé ça dans une RFC ?
> je m'en fous d'avoir une truc top moumoute
T'es seulement obsédé à avoir un truc théoriquement sans point faible. Mais il ne l'ai pas et ne le sera jamais (idem pour moi).
Je te laisse dans ta croyance absolue de ton système parfait.
> Par contre, prend une image, gzip là, change 1 octet quelque part, et ungzip apres ...
Change un secteur d'un système de fichier au hazard. Tu m'en diras des nouvelles. Si t'as un peu de chance, tu tombes sur un secteur non utilisé. Si t'as moins de chance, ça va te prendre des semaines pour constater les dégâts, remonter le problème et récupérer un backup vieux de 2 semaines.
Mais dis moi, si pour toi c'est dangeureux d'utiliser tar ou gzip, pourquoi tu utilises les systèmes fichiers ?
J'ai eu un pote pro-ODF au téléphone et a un moment on a glissé sur la normalisation de MS-OOXML. Il me dit :
- Super, on va pouvoir baiser MS à arme égale !
> Et rsync peut aussi merder (ça m'est déjà arrivé).
Et j'ai aussi eu cpio qui merdait (et pas pour faire une archive, mais un cpio -p). Les droit et propriétaire des fichiers étaient perdus (ce qui est très casse couille).
> Donc sur ton tar.gz, il suffit d'une petite erreur ( facile à obtenir ), pour chier ton archive.
Mais c'est comme ça pour tout !
T'as une merde dans le dump de base de donnée, et le dump peut être foiré. Et les dumps en pure SQL tu ne peux pas toujours les faires (sinon ça prend des prombe). T'as une merde dans l'outil qui fait le dump, et le dump est foiré. T'as un merde dans le SGBD, et le dump est foiré. T'as une merde dans le FS, et tous tes backups sont foireux, etc.
Mais pour une raison que j'ignore, tu fais une fixation sur tar et gzip.
Tu m'expliques ?
Je ne fais pas une fixation sur tar ou pg_dump ou autre. Je fais une fixation sur l'ensemble de la chaine. D'où l'importance de faire des restaures réguliers pour tester l'ensemble.
Un exemple de "petit problème". .Tes backups et dumps de base de données roulent nickel. Un l'admin fait une mise à jour de la base de donnée. Manque de chance, pour les dumps t'utilise une option qui n'est plus supportée. Bref, tes backups sont nazes.
Ou avec la nouvelle version de la base donnée, l'admin de la base de donnée utilise de nouvelle fonctionnalité qui sont sauvegardées que si tu utilises la nouvelle option "-z" de l'outils de dump de base. Mais comme cette option n'est pas activée...
Bref, ça peut merder à 50 endroits, alors pourquoi cette fixation sur tar ?
Et rsync peut aussi merder (ça m'est déjà arrivé).
Pourquoi MS ne participe pas au filtre d'import/export d'ODF pour MS-Office ?
MS fait son filtre dans un coin, mais ne participe au filtre que fait Sun ni ne l'inclus. Sun (et d'autres) le fait car le filtre d'import/export ODF de MS-Office est tout pourri. MS préfère fournir un filtre pourri qu'un meilleur filtre. C'est un fait.
Ben ce n'est pas exactement ce qui est dit.
Lis un peu mon coco.
Je dis (et l'article le dit mieux que moi), que les politiciens se sont pris les pieds dans le tapis et qu'ils pratiques de (ou pousse à) la standardisation de complaisance.
> vous cherchez des excuses pour eviter de voir la realite en face.
Et toi non.
Toi qui dit que MS-OOXML est un standard comme un autre alors que c'est un spèc de plus de 6000 pages (qui passe en fast-tack...) avec un gros patch inconnu de plus de 2300 pages validé en moins de 2 mois et qui est vaguement connu.
Mais continue ton délire bisounours.
> C'est tellement plus simple d'accuser les gens d'etre corrompus quand leur decision ne vous plait pas.
Tu nous explique que Kerberos est fait pour être incompatible avec Kerberos ?
Ben voyons...
Merci MS de ne pas violer dans la lettre un standard.
Pour MS, être standard, c'est être compatible avec MS.
Et c'est ça les promesses "ouvertures et d'intéropérabilité" de MS ?
> MS n'a jamais dit que l'OSP couvrait tout ce qu'il fait
Ça couvre seulement se qui est requis pour implémenter ce qui est nécessaire pour être considéré conforme et est décrit en détail. Et en plus c'est incompatible GPL. Bref, du pipeau dans le cas de MS-OOXML.
> tout comme IBM et sa promesse vis-a-vis des patentes.
Faux. La promesse d'IBM couvre toute ce qui est décrit dans la spéc et pas seulement ce qui est requis pour être conforme.
En passant, pour être conforme MS-OOXML, il suffit de ne rien faire. La spèc dit qu'un programme conforme doit ne pas afficher de message d'erreur si on lui donne un fichier conforme. La spèc ne dit pas ce que le programme doit faire, mais ce qu'il ne doit pas faire. Bref, vim est conforme (faudra peut-être virer le warning qu'il donne lorsqu'on ouvre un fichier binaire, n'importe quoi est conforme. La spèc indique aussi que le programme doit pouvoir enregistre le fichier à l'identique. J'ouvre avec vim, je fait ":w mon_doc.docx" et voilà, je suis conforme MS-OOXML.
> OpenXML donne une methode pour encoder les caracteres non permis dans XML 1.0
Méthode qui impose xsd:string (du standard XML) et ce dernier INTERDIT les caractères non unicode !
xsd-string a une signification. MS en fait un blob binaire. Et tu dis que ça c'est faire de l'intéropérabilité ?
Avec ST_Xstring on peut y mettre une vidéo...
> il ne met pas ses caracteres directement dans du XML.
C'est bien documenté avec des liens sur la norme et tout. Et en plus c'est facile à lire même pour un non expert XML.
Une fois qu'ils auront lu, ils vont conclure que tu ne dis que des grosses connerie et du pûr FUD.
C'est un projet libre.
Si quelqu'un veut faire un filtre import/export MS-OOXML, ben on ne peut pas (et on ne doit pas) l'en empêcher.
OOo peut avoir un super filtre d'import/export MS-OOXML (du moins théoriquement).
Microsoft ne fera jamais un super filter d'import/export ODF. Et même si MS en a un, il va le pourrir exprès.
On ne doit pas empreinder à MS ses magouilles. Bien que ça soit fort tentant...
> MS a annonce qu'Office 2007 serait modifie pour etre conforme au standard vote par l'ISO
Déjà il faut savoir quel standard puisque personne ne l'a vu. Il y a un gros patch de plus de 2000 pages qui traine on ne sait où.
Comme d'hab avec MS, il faut s'avoir lire entre les lignes.
Par exemple la spec a plein de "application-defined", sauf que la spec ne demande pas que ce qui est "application-defined" soit défini... La spec C++ a plein de "application-defined" mais exige qu'une implémentation qui se conforme à la norme décrive tous ses "application-defined".
Autre exemple de problème, MS-OOXML a été beaucoup critiqué sur les formats de date. Ben maintenant c'est 7 formats de date que va supporter MS-OOXML. Mais es-ce que le support de ces 7 formats sera requis par la norme ? J'en doute. Il n'y en aura qu'un ou deux de requis. Et si MS-Office n'arrive pas à charger un document MS-OOXML qui pourtant utilise un format de date de la spèc, ben c'est tant pis pour ta gueule.
Autre exemple de problème, afin de bien embrouiller le bousin (ou le simplifier et cacher la misère dans un coin), la spec MS-OOXML met des éléments en "obsolète". Déjà il est mortel de rire qu'un nouveau format soit déjà... Mais la spèc ne dit pas qu'un programme qui respecte la norme n'écrive pas les nouveaux documents avec des éléments obsolètes.
En passant, comment on va faire pour distinguer un format MS-Office 2007 non mis à jour pour l'ISO et un mis à jour pour l'ISO ?
Pour l'instant on ne sait pas...
Bref, une spèc de merde. Que MS-Office supporte une spèc de merde ne change rien.
Oui.
Mais j'ai l'impression que tu es limite dans un délire. Tu peux faire des checksum, mais à dans ce cas de parano, il faut aussi auditer les outils qui font les dumps, etc...
Le tar.gz c'est bien. Ce n'est pas parfait, mais c'est bien. S'il manque un 1 bit, gzip et tar savent gérer ça. Mais OK, tu perds plus d'un 1 bit.
Notons que tous les archivages vidéo sont en compressé... Sinon c'est impossible.
Autre avantage de tar, il stocke les informations du système de fichier. Comment tu fais pour sauvegarder les droit rwxrwxrwx sur Windows ? Comment tu fais pour sauvegarder les propriétaires si tu n'as accès qu'à un compte sur le serveur de backup ? Comment tu fais si tu as les fichiers TOTO et toto et le serveur de backup est Windows ?
On ne devrait pas parler d'un backup mais de plusieurs backups. Car il faut toujours au moins deux backups (sur deux bécanes différentes ou qu'une bécane mais archiver les bandes dans des lieux différents).
Enfin il faut mettre dans le contexte. Pour un serveur, je fais des sauvegardes en cpiio.gz, dump de base de données, etc. Je gardes sur 2 mois (10 backups fait la nuit et 10 backups fait le week). Mais surtout je m'impose de faire un test de restauration tous les mois ! Si je n'arrive pas à restaurer mon serveur rapidement, alors j'ai un problème dans mes procédures de backup/restauration. Que j'utilise du cpio.gz est accessaire. Évidemment, c'est pour mon cas particulier et d'autres cas demande d'autres procédures.
[^] # Re: Oh, juste un doigt...
Posté par IsNotGood . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 2.
http://tirania.org/blog/archive/2008/Apr-02.html
Je ne peux pas croire qu'il écrit ça de sa plume...
[^] # Re: Question
Posté par IsNotGood . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 2.
Rien de très consistant. Il reste deux mois pour porter plainte. Des bruits circules qu'IBM est en train afûter les couteaux et un blog de MS joue déjà la victime de l'ignoble et sans scrupule IBM.
[^] # Re: Lancement d'un nouveau format de bureautique ISO
Posté par IsNotGood . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 1.
[^] # Re: ooxml
Posté par IsNotGood . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 2.
Mais pour ODF on est dans le domaine des standards ouverts (les vrais, pas les usurpé)s. Pour ODF on est dans le domaine du libre. Beaucoup de "libristes" ne veulent pas de MS-OOXML car il n'est pas libre. Qu'il soit (peut-être) meilleur ou plus utilisé que ODF est to-ta-le-ment accessoire. Donc l'évolution de ODF est beaucoup moins contrainte par des enjeux commerciaux ou de défense de monopole que MS-OOXML. ODF prendra la voix qui lui convient le mieux, la plus efficace. N'oublions pas que les ressources disponibles pour ODF (et OOo) sont bien moindres que celles pour MS-OOXML.
ODF (et OOo) est inscrit dans le long terme. Et in fine, a mon avis, et à l'instart de Mozilla/Firefox, ça payera. Ça sera une sorte de conséquence et non un objectif tenu.
D'ailleurs beaucoup s'intérogent sérieusement sur la pérénité de MS-OOXML et ne voit en lui qu'un format transitoire. Ce qui n'est pas du tout le cas de ODF.
Ce n'est pas une concurrence classique comme on le voit dans le logiciel proprio.ODF (et OOo) peut se permettre d'être moins bon que MS-OOXML/MS-Office et pour longtemps. MS ne peut pas se permettre d'être pris de vitesse par ODF. La brutalité de la réaction pour être ratifié ISO le démontre. Oui MS-OOXML est une place forte. Mais avec une certaine fragilité qu'on aurait tord de sous-estimer (ce que ne fait pas MS).
[^] # Re: ooxml
Posté par IsNotGood . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 8.
Mais pourquoi tu n'inverses pas les rôles ?
Il n'y a que MS qui va maintenir MS-OOXML. MS-OOXML est un format MS pour MS. Si quelqu'un propose, par exemple, de le rendre réellement plus intéropérable, de le rapprocher d'ODF, etc, MS ne voudra pas. Et c'est exactement ce qu'ont a vu durant l'ISO malgrés une participation massive et un nombre de commentaires "délirants". Mais au final, la norme est telle que veux MS et non telle que veut l'ensemble des participants à l'ISO.
Participes à MS-OOXML si tu veux. Mais ça sera comme parler dans un puit sans fond.
En passant, il n'y a que la maintenance (au sens ISO, c-à-d les corrections mineurs) qui ne sera pas faite par MS. Les décisions importantes sont prises par MS.
Bref, ce n'est pas un standard ouvert !
Les mailings sont fermées, ont ne sait qu'au dernier moment les décisions prises, etc.
Notons que MS a poussé la normalisation lorsque MS avait le produit ! La norme MS-OOXML n'est pas le format MS-Office 2007, mais il s'en est fallu très peu et ce n'est pas faute à MS d'avoir essayé.
Et pour la prochaine version de MS-OOXML, c'est ce qu'on va voir encore. MS va développer son produit et un peu avant qu'il soit terminé il va faire normaliser la nouvelle version. MS se donne un atout anti-concurrentiel. Ceci n'a rien à voir avec l'ISO ou des standards ouverts. Avec MS, une norme est conçu suivant un produit alors qu'il faudrait concevoir les produits selon une norme (évidemment largement discuté en amont).
Dans ses conditions, pourquoi diable aider MS ?
N'oublions pas la nature du libre. Le libre c'est être libre. Le libre ne va pas aller s'emprisonner avec MS-OOXML.
[^] # Re: Une bonne nouvelle
Posté par IsNotGood . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 6.
http://www.robweir.com/blog/2008/01/standard-trolls.html
Or, in plain English, in order to be able to claim conformance with OOXML, an application must not crash when presented with a valid OOXML document, or must be able of producing at least a single valid OOXML document. This is not exactly a high threshold.
Some examples of applications that support OOXML by that definition:
1. The DOS "copy" command is a conforming OOXML consumer and producer, since it can accept and produce valid OOXML documents.
2. The DOS "del" command is a valid OOXML consumer, and one which I heartily recommend.
3. WinZip, PkWare and every other Zip application out there are also conforming producers and consumers of OOXML.
4. Every text editor and every XML editor and every other application that can consume text or XML also supports OOXML.
etc
On est ravis d'apprendre que les commandes copy et del sont couvertes par OSP.
[^] # Re: Une bonne nouvelle
Posté par IsNotGood . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 5.
OPS ne permet pas à une implémentation de MS-OOXML d'être compatible GPL :
http://www.softwarefreedom.org/resources/2008/osp-gpl.html
http://www.microsoft.com/france/interop/osp/default.mspx
Pour clarifier, les « Revendications Microsoft nécessaires » représentent les revendications de brevets détenus ou contrôlés par Microsoft qui sont nécessaires pour implémenter uniquement les parties requises de la Spécification couverte qui sont décrites en détail
Et qu'es-ce qui est requis par MS-OOXML ?
Pratiquement rien.
De la spec MS-OOXML :
2.5 Application Conformance
Application conformance is purely syntactic; it also involves only Items 1 and 2 in §2.3 above.
* A conforming consumer shall not reject any conforming documents of the document type (§4) expected by that application.
* A conforming producer shall be able to produce conforming documents.
Rien d'autre.
# Une honte
Posté par IsNotGood . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 10.
Il y a la spèc soumis par l'ECMA et un gros patch de 2300 pages (!) réalisé à l'arrache et discuté durant une semaine.
C'est incroyable, mais c'est ça qu'a ratifié l'ISO ! Une norme super mauvaise et inconnue...
[^] # Re: Oh, juste un doigt...
Posté par IsNotGood . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 10.
Pas seulement eux. Mais aussi les libristes qui pensent qu'il faut "collaborer" avec MS. MS est hyper ambigü dans les discours. MS nous parle d'intéropérabilité, que le nouveau MS arrive (voire le bruit fait sur la disponibilité de doc alors que c'est seulement la conséquence des exigences légitimes de l'UE, l'ultra flou OSP à l'incompatibilité GPL non avouée, des sites web à gogo qui se veulent neutres et open, etc).
Il n'y a pas de nouveaux MS. C'est le même, légèrement adapté pour leurer.
# Re: La guerre des formats de bureautique normalisés ISO commence
Posté par IsNotGood . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 5.
http://blogs.msdn.com/brian_jones/archive/2008/04/01/open-xm(...)
Open XML Overwhelmingly Approved as an ISO / IEC standard (IS 29500): the end of the file formats war
En passant, ce blog court de Rob Weir :
http://www.robweir.com/blog/2008/04/new-paths-in-standardiza(...)
Now that it has been demonstrated that pushing proprietary interfaces, protocols and formats through ISO is cheaper and faster than writing code to implement existing open standards, one assumes that the future is bright for more such boutique standards from Redmond. Open HTML, anyone?
[^] # Re: De la nécessité de tester les sauvegardes
Posté par IsNotGood . En réponse au journal Migration foirée. Évalué à 2.
Mais c'est clair depuis le début.
M'enfin tu ne peux (ou ne devrais pas) sous-entendre qu'un tar (gzip en plus ou pas) n'est pas un backup. C'est un backup avec ses faibles comme tous les backups.
Tu peux le juger moins fiable, c'est tout à fait recevable et compréhensible.
J'évite les archives et la compression seulement car c'est moins pratique (ça ne se prête pas à un rsync par exemple). Pas car c'est (forcément) moins fiable.
Si tu fais un mirroir de kernel.org, tu n'as pratiquement que des fichiers compressés, mais c'est un backups. Évidemment si tu mets le tout dans un gros tar de 10 To, ce n'est pas malin.
# Re:
Posté par IsNotGood . En réponse à la dépêche Poisson d'avril de 2008. Évalué à 2.
Tips and tricks: How can I increase the security of my workstations?
1. First delete the password lists for all profiles on the machine.
del c:windows*.pwl2. From the command line:
REGEDIT /s \MY_PDCnetlogonnocache.regThis will run regedit with no program output and a registry input file named nocache.reg, which looks like this:
REGEDIT4[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesNetwork]
"DisablePwdCaching"=dword:00000001
3. Save that as plain text and name it nocache.reg.
Following these steps will greatly increase the security of your Windows 9x machines. Enjoy!
A qui est ce poission d'avril ?
Ça m'a pris du temps pour me rendre compte que c'était un poisson. Mais chut.
À Red Hat :
http://www.redhatmagazine.com/2008/04/01/tips-and-tricks-how(...)
[^] # Re: Mise au point
Posté par IsNotGood . En réponse au journal Migration foirée. Évalué à 3.
Mais ce n'était pas vraiment de ma faute. J'avais une nouvelle bécane de développement. Pour le développement, on a le mot de passe root. Je demande le mot de passe à l'admin, il me le donne et je le sent un peu embarassé.
Quelques minutes après je veux rebooter la bécane (pour passer sur la dernière version de l'OS et faire des tests/portages/etc), je fais "su ... reboot". Sauf que j'étais sur le serveur...
Cet "abrutis" d'admin avait mis le même mot de passe root sur ma bécane que sur le serveur.
Heureusement ce n'était pas 30 000 utilisateur, mais une bonne cinquantaine. En 5 secondes on m'enformait que le serveur était down. Ce qui expliquait que ma bécane n'était en train de rebooter...
[^] # Re: De la nécessité de tester les sauvegardes
Posté par IsNotGood . En réponse au journal Migration foirée. Évalué à 2.
Je n'ai pas dit ça.
Je n'ai pas dit que X ou Y est génial.
En passant, je n'utilise pas tar.
> Personnellement, JE t'ai sorti plein d'infos avec des sources tel que les RFC, les descriptions des algorithmes qui permettent de se faire une opinion argumenté ...
Ton raisonnement est : si ça va de travers, ben ça va de travers. Et si tu utilises tar ou gzip, ça ira encore plus de travers.
ON EST D'ACCORD !
Mais si mon fichier tar ou gzip est pourri, ben je le sais. Et je récupère un sauvegarde précédante. Je ne vais pas prendre le risque de vaguement restaurer un truc. Et toi ? Et restaure vaguement des trucs ?
Si un backup a un problème, ben il a un problème. Et même si ce n'est qu'un fichier, va savoiir quelles sont répercutions.
Oui, si un secteur de disque dur ou bande magnétique déconne ben t'aura plus de problème avec tar/gzip que si tu utilises rien. C'est évident, pas besoin de RFC pour savoir ça.
Mais tu (ou je) peux aussi dire, arguments (ou RFC) à l'appuis, qu'un système de fichier c'est dangereux pour les backups car si il déconne t'es dans la merde et qu'il vaut mieux et "tar .... > /dev/sdm" qu'un "cp -r ... [destination]". Que ODF qui groupe des fichiers dans une archive c'est plus dangereux que si c'est non compressé et dispersé sur plusieurs fichiers. Qu'un système de fichier + journalisation + lvm + raid c'est HYPER dangereux car il suffit qu'un seul déconne pour être dans une merde noir. A chaque fois que tu ajoutes un truc, il y a un risque.
Mais si tar (ou cpio, ou rsync ou gzip ou...) marche, ben il marche (et ce n'est pas de la croyance, c'est un constat). Si ton système raid/lwn/ext3/pg_dump marche, ben il marche. Si les archives compressées de ODF marchent, ben elle marchent. Au fais, tu décompresses systématiquement tes fichiers ODF ?
J'imagine que tu dois rêver d'un SDB qui mets chaque enregistrement et chaque champs dans un fichier séparé... Pour le "au cas où" (comme pour le "au cas où un bit de ton gzip ....")
Tu peux aussi éviter les disques durs, les bandes magnétiques, etc car ils finissent tous par planter et privilégier la pierre gravée tant que tu y es.
Il y a toujours un risque. Mais il doit être évalué.
Es-ce que utiliser tar un gros risque ?
Je ne crois pas. Du moins si l'ensemble sauvegarde/restauration est sérieusement testé ET plusieurs sauvegardes archivées (rotation).
Si je peux éviter tar, ben j'évite tar. Si tar me rend service, ben je l'utilise.
J'utilise, et ça va être un standal pour toi, le format "custom" de pg_dump (PosgreSQL) qui par défaut est compressé. Et je ne suis VRAIMENT pas le seul. Ça présente plein d'avantage par rapport au dump SQL "plain". Es-ce un risque ? Oui. Mais ridicule. Et ça marche (comme tes serveurs en prod).
> "RFC" contre "croyance benoite"
Lis ce que j'ai écris.
Si j'avais une "croyance benoite" tu crois que je vérifierais mes backup et procédures de restauration tous les mois ?
> "RFC"
Ben lit la doc sur ext3, et ext3 comme tar, s'il y a un problème de disque (secteur ou autres) ou qu'un problème d'OS, ou la mémoire vive qui déconne, ben tu n'es pas à l'abris de perdre des donnés (un secteur, un cluster, un group ou 1000 fois pire). C'est hypra clair. Pourtout tu utilises bien des systèmes de fichier ?
Tar est une sorte de un système de fichier, ça a les mêmes problèmes.
> Pour quel raison faire un upgrade d'une version majeur d'un SGBD alors que tu as une prod qui fonctionne ( hors faille de sécurité ) ?
Car tu ne sauvegardes pas les serveurs de développement, pré-production ?
C'est les développeurs qui vont être heureux d'entendre ça...
Puis le "ça marche je n'y touche pas" il est vrai pour une période donnée. Sinon les admins seraient au chômage.
Il y a plein de serveur en production qui doivent évoluer. Et parfois tu ne peux pas avoir la base de production complète en test (trop cher) et faire des tests exhautif.
> ON NE COUPE PAS UN SERVICE QUI FONCTIONNE !
BEN MES BACKUPS GZIP, PG_DUMP, ETC MARCHENT !
> pour moi, si il y a une mise à jour du sgbd, il y a test, recette et donc vérification de la compatibilité de tous le systeme d'information pour toi, tu fais le jacgeek, tu fais du tuning de soft plutot que que voiture, mais c'est pareil, plus le numero de version est gros et plus tu es content.
Puisque tu le dis...
T'as trouvé ça dans une RFC ?
> je m'en fous d'avoir une truc top moumoute
T'es seulement obsédé à avoir un truc théoriquement sans point faible. Mais il ne l'ai pas et ne le sera jamais (idem pour moi).
Je te laisse dans ta croyance absolue de ton système parfait.
> Par contre, prend une image, gzip là, change 1 octet quelque part, et ungzip apres ...
Change un secteur d'un système de fichier au hazard. Tu m'en diras des nouvelles. Si t'as un peu de chance, tu tombes sur un secteur non utilisé. Si t'as moins de chance, ça va te prendre des semaines pour constater les dégâts, remonter le problème et récupérer un backup vieux de 2 semaines.
Mais dis moi, si pour toi c'est dangeureux d'utiliser tar ou gzip, pourquoi tu utilises les systèmes fichiers ?
# Re:
Posté par IsNotGood . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 3.
- Super, on va pouvoir baiser MS à arme égale !
Fun.
[^] # Re: petition a OpenOffice.org
Posté par IsNotGood . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 2.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par IsNotGood . En réponse au journal Migration foirée. Évalué à 1.
Et j'ai aussi eu cpio qui merdait (et pas pour faire une archive, mais un cpio -p). Les droit et propriétaire des fichiers étaient perdus (ce qui est très casse couille).
[^] # Re: De la nécessité de tester les sauvegardes
Posté par IsNotGood . En réponse au journal Migration foirée. Évalué à 3.
Mais c'est comme ça pour tout !
T'as une merde dans le dump de base de donnée, et le dump peut être foiré. Et les dumps en pure SQL tu ne peux pas toujours les faires (sinon ça prend des prombe). T'as une merde dans l'outil qui fait le dump, et le dump est foiré. T'as un merde dans le SGBD, et le dump est foiré. T'as une merde dans le FS, et tous tes backups sont foireux, etc.
Mais pour une raison que j'ignore, tu fais une fixation sur tar et gzip.
Tu m'expliques ?
Je ne fais pas une fixation sur tar ou pg_dump ou autre. Je fais une fixation sur l'ensemble de la chaine. D'où l'importance de faire des restaures réguliers pour tester l'ensemble.
Un exemple de "petit problème". .Tes backups et dumps de base de données roulent nickel. Un l'admin fait une mise à jour de la base de donnée. Manque de chance, pour les dumps t'utilise une option qui n'est plus supportée. Bref, tes backups sont nazes.
Ou avec la nouvelle version de la base donnée, l'admin de la base de donnée utilise de nouvelle fonctionnalité qui sont sauvegardées que si tu utilises la nouvelle option "-z" de l'outils de dump de base. Mais comme cette option n'est pas activée...
Bref, ça peut merder à 50 endroits, alors pourquoi cette fixation sur tar ?
Et rsync peut aussi merder (ça m'est déjà arrivé).
[^] # Re: petition a OpenOffice.org
Posté par IsNotGood . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 3.
MS-Office sera nickel pour convertir d'ODF à MS-OOXML.
[^] # Re: petition a OpenOffice.org
Posté par IsNotGood . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 2.
MS fait son filtre dans un coin, mais ne participe au filtre que fait Sun ni ne l'inclus. Sun (et d'autres) le fait car le filtre d'import/export ODF de MS-Office est tout pourri. MS préfère fournir un filtre pourri qu'un meilleur filtre. C'est un fait.
[^] # Re: L'Angleterre comme la Norvège ?
Posté par IsNotGood . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 2.
Ben ce n'est pas exactement ce qui est dit.
Lis un peu mon coco.
Je dis (et l'article le dit mieux que moi), que les politiciens se sont pris les pieds dans le tapis et qu'ils pratiques de (ou pousse à) la standardisation de complaisance.
> vous cherchez des excuses pour eviter de voir la realite en face.
Et toi non.
Toi qui dit que MS-OOXML est un standard comme un autre alors que c'est un spèc de plus de 6000 pages (qui passe en fast-tack...) avec un gros patch inconnu de plus de 2300 pages validé en moins de 2 mois et qui est vaguement connu.
Mais continue ton délire bisounours.
> C'est tellement plus simple d'accuser les gens d'etre corrompus quand leur decision ne vous plait pas.
Mais oui bisounours.
[^] # Re: Bon ...
Posté par IsNotGood . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 3.
Tu nous explique que Kerberos est fait pour être incompatible avec Kerberos ?
Ben voyons...
Merci MS de ne pas violer dans la lettre un standard.
Pour MS, être standard, c'est être compatible avec MS.
Et c'est ça les promesses "ouvertures et d'intéropérabilité" de MS ?
> MS n'a jamais dit que l'OSP couvrait tout ce qu'il fait
Ça couvre seulement se qui est requis pour implémenter ce qui est nécessaire pour être considéré conforme et est décrit en détail. Et en plus c'est incompatible GPL. Bref, du pipeau dans le cas de MS-OOXML.
> tout comme IBM et sa promesse vis-a-vis des patentes.
Faux. La promesse d'IBM couvre toute ce qui est décrit dans la spéc et pas seulement ce qui est requis pour être conforme.
En passant, pour être conforme MS-OOXML, il suffit de ne rien faire. La spèc dit qu'un programme conforme doit ne pas afficher de message d'erreur si on lui donne un fichier conforme. La spèc ne dit pas ce que le programme doit faire, mais ce qu'il ne doit pas faire. Bref, vim est conforme (faudra peut-être virer le warning qu'il donne lorsqu'on ouvre un fichier binaire, n'importe quoi est conforme. La spèc indique aussi que le programme doit pouvoir enregistre le fichier à l'identique. J'ouvre avec vim, je fait ":w mon_doc.docx" et voilà, je suis conforme MS-OOXML.
> OpenXML donne une methode pour encoder les caracteres non permis dans XML 1.0
Méthode qui impose xsd:string (du standard XML) et ce dernier INTERDIT les caractères non unicode !
xsd-string a une signification. MS en fait un blob binaire. Et tu dis que ça c'est faire de l'intéropérabilité ?
Avec ST_Xstring on peut y mettre une vidéo...
> il ne met pas ses caracteres directement dans du XML.
Ben si.
> Grosse connerie et pur FUD,
J'invite les gens à lire : http://www.robweir.com/blog/2008/03/ooxmls-out-of-control-ch(...)
C'est bien documenté avec des liens sur la norme et tout. Et en plus c'est facile à lire même pour un non expert XML.
Une fois qu'ils auront lu, ils vont conclure que tu ne dis que des grosses connerie et du pûr FUD.
> Encore une fois, tu racontes des salades
J'invite les gens à lire http://www.robweir.com/blog/2008/03/ooxmls-out-of-control-ch(...) et à se forger un avis.
> ca te ferait chier de reflechir 2 seconds avant de faire un copier-coller du moindre truc anti-OOXML que tu trouves ?
J'invite les gens à lire http://www.robweir.com/blog/2008/03/ooxmls-out-of-control-ch(...) et à se forger un avis.
[^] # Re: petition a OpenOffice.org
Posté par IsNotGood . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 2.
Si quelqu'un veut faire un filtre import/export MS-OOXML, ben on ne peut pas (et on ne doit pas) l'en empêcher.
OOo peut avoir un super filtre d'import/export MS-OOXML (du moins théoriquement).
Microsoft ne fera jamais un super filter d'import/export ODF. Et même si MS en a un, il va le pourrir exprès.
On ne doit pas empreinder à MS ses magouilles. Bien que ça soit fort tentant...
[^] # Re: .
Posté par IsNotGood . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 2.
Déjà il faut savoir quel standard puisque personne ne l'a vu. Il y a un gros patch de plus de 2000 pages qui traine on ne sait où.
Comme d'hab avec MS, il faut s'avoir lire entre les lignes.
Par exemple la spec a plein de "application-defined", sauf que la spec ne demande pas que ce qui est "application-defined" soit défini... La spec C++ a plein de "application-defined" mais exige qu'une implémentation qui se conforme à la norme décrive tous ses "application-defined".
Autre exemple de problème, MS-OOXML a été beaucoup critiqué sur les formats de date. Ben maintenant c'est 7 formats de date que va supporter MS-OOXML. Mais es-ce que le support de ces 7 formats sera requis par la norme ? J'en doute. Il n'y en aura qu'un ou deux de requis. Et si MS-Office n'arrive pas à charger un document MS-OOXML qui pourtant utilise un format de date de la spèc, ben c'est tant pis pour ta gueule.
Autre exemple de problème, afin de bien embrouiller le bousin (ou le simplifier et cacher la misère dans un coin), la spec MS-OOXML met des éléments en "obsolète". Déjà il est mortel de rire qu'un nouveau format soit déjà... Mais la spèc ne dit pas qu'un programme qui respecte la norme n'écrive pas les nouveaux documents avec des éléments obsolètes.
En passant, comment on va faire pour distinguer un format MS-Office 2007 non mis à jour pour l'ISO et un mis à jour pour l'ISO ?
Pour l'instant on ne sait pas...
Bref, une spèc de merde. Que MS-Office supporte une spèc de merde ne change rien.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par IsNotGood . En réponse au journal Migration foirée. Évalué à 2.
Oui.
Mais j'ai l'impression que tu es limite dans un délire. Tu peux faire des checksum, mais à dans ce cas de parano, il faut aussi auditer les outils qui font les dumps, etc...
Le tar.gz c'est bien. Ce n'est pas parfait, mais c'est bien. S'il manque un 1 bit, gzip et tar savent gérer ça. Mais OK, tu perds plus d'un 1 bit.
Notons que tous les archivages vidéo sont en compressé... Sinon c'est impossible.
Autre avantage de tar, il stocke les informations du système de fichier. Comment tu fais pour sauvegarder les droit rwxrwxrwx sur Windows ? Comment tu fais pour sauvegarder les propriétaires si tu n'as accès qu'à un compte sur le serveur de backup ? Comment tu fais si tu as les fichiers TOTO et toto et le serveur de backup est Windows ?
On ne devrait pas parler d'un backup mais de plusieurs backups. Car il faut toujours au moins deux backups (sur deux bécanes différentes ou qu'une bécane mais archiver les bandes dans des lieux différents).
Enfin il faut mettre dans le contexte. Pour un serveur, je fais des sauvegardes en cpiio.gz, dump de base de données, etc. Je gardes sur 2 mois (10 backups fait la nuit et 10 backups fait le week). Mais surtout je m'impose de faire un test de restauration tous les mois ! Si je n'arrive pas à restaurer mon serveur rapidement, alors j'ai un problème dans mes procédures de backup/restauration. Que j'utilise du cpio.gz est accessaire. Évidemment, c'est pour mon cas particulier et d'autres cas demande d'autres procédures.