sur le principe du sous marin appliqué à un aerostat, cela à l'air sympa : à pression équivalente, l'hélium est plus leger que l'air.
Le sous marin fait cela avec des salles d'air qui explusent l'eau pour monter, et une evacuation de l'air de la salle pour descendre.
Tu peux imaginer :
un réservoir d'hélium comprimé ( comme les bombonnes qui existe dans le commerce spécialisé et qui ne s'envole pas )
une salle de détente pouvant retenir l'hélium tout en le maintenant à la pression extérieur
sauf que le sous marin utilise la gravité pour s'aider ce qui fait qu'il est peu consommateur d'énergie sur ses phases ascendantes et descendantes ( sauf usage de moteur pour forcer les choses ).
Par contre, se pose 2 grosses questions bien complexe dans ton cas :
- comment forceras tu le retour de l'hélium dans son reservoir ?
- comment fais tu pour produire ou récolter de l'hélium ?
En fait, c'est cela tes deux gros problèmes ;)
restera les détails comme la régulation de la pression dans la salle de détente et le controle de l'ascension et de la descente pour éviter les accidents vasculaires, ... mais globalement, les solutions existent déjà.
pour le moment, la dépêche a plus de personne favorable que de personnes défavorables, et un tro^Wdébat émerge sur qu'est ce que le hors sujet en dépêche de linuxfr ;)
de toute facon, comme tu l'as dit dans ta dépêche, le film est déjà sorti depuis un moment, alors rassure toi ;)
En fait, il y a les partisans du " c'est sympa cela permet de varier ", du " c'est la tradition, et les traditions sont sacrés ", du " ca ne parle pas du libre donc dehors ".
Perso, je vote " c'est sympa ca permet de varier " ...
et j'argue sur des faits et les choix éditoriaux des hors sujets :
- aucune dépêche racketiciel n'a de lien avec le libre puisque cela n'empeche pas d'installer linux, c'est juste de la propagande de défense de consommateur
- DADVSI & co, parle la portée de la responsabilité pénale des devs et éditeurs, question qui est identique pour un soft propriétaire dont les entreprises éditrices et developpeuses sont aussi pénalement responsable
- A coté de cela, les brevets logiciels touchent aussi bien le libriste que le non-libriste donc hors sujet aussi
- je ne parle pas de la pub déguisé quand tel société ou commercant vend tel produit dans tel condition
Donc de cette liste pourtant qui semble en charte, s'avèrent être dans les faits plutôt limite.
Quand on regarde les dépêches "réellement en charte" et qui passent ( la très grande majorité sont bien faite - merci aux rédacteurs ), nous avons :
- une release de distrib
- une install party
- une conf de stallman qui dit que le libre c'est cool
- une release de wikiroxor ou libglop ou ERPcoincoin ( le seul ERP libre moule-compliant ) ou le dernier framework rupyhp de la mort qui change le web 2.x et le web 3.x
- un salon , évenement, une soirée bière
Si on se limite à cela, les dépêches linuxfr devriendraient chiant à lire.
Diversifier sur les thèmes voisins ou intéressant les geeks permet de maintenir l'interêt au delà du simple planete/agregateur RSS des sites de libristes francophone.
Linuxfr est linuxfr et n'est pas un digg, fuzzer, skyblog de libriste ...
Linuxfr n'est pas un site ultra spécialisé sur le libre, c'est avant tout un point de convergence autour du monde du libre.
Et comme tout point de convergence, il est généraliste et se doit de le rester pour rester ce point d'accueil.
Maintenant, est ce que le cinéma, la litterature ou une humeur a sa place sur linuxfr en dépêche ?
Oui si cela ne represente pas une depeche par pet de travers, film sorti, livre publié. Ce qui fait la force de linuxfr est la diversité de son contenu et de son lectorat ! Se spécialiser à outrance ne pourra que faire fuir ce lectorat et non le fidéliser puisque ce qui lui manque, il le cherchera ailleurs. donc autant aussi aller chercher ailleurs les informations précises sur la dernieres version de gnome, la nouvelle install parti à marly-gaumont, ...
Maintenant, lui apporter des informations variées et diversifiées, ne veut pas dire uniquement que cela ... linuxfr n'est pas non plus un slashdot ;)
Ces informations HS doivent être équilibré et ne pas représenté l'essentiel de l'information, juste une ouverture sur d'autres sujets qui ont plut ( comme pour les dépeches ) aux admoderelecteurs :)
Parce que le geek n'est pas qu'un no-life qui passe sa vie à regarder sa gentoo se compiler, le geek est avant tout quelqu'un de curieux qui s'intéresse à plein de sujets divers, il me semble important de lui apporter aussi des informations hors sujet, des informations auquel il ne pensera pas nécessairement.
Avec Moun's chacun et tous ensemble construisons un linuxfr meilleur !
Moun's le président des news HS sur linuxfr !
Votez le changement dans le respect des traditions !
Votez Moun's !
apache + mod_php c'est juste un interpreteur qui reste persistant en mémoire.
Donc comme pour les scripts python, perl, shell, ... , ton code PHP peut etre bien écrit et optimisé pour la tenue en charge.
Sauf que comme pour la trop grande majorité des scripts python, perl, shell, ton code PHP que tu fais tourné est mal codé avec des algorithmes consommateurs de CPU et pleins de trucs qui ne servent à rien.
Donc si c'est toi qui a codé ce qui tourne, je te conseille vivement de te pencher sur les bouquins d'algorithmiques théoriques, sur les strategies d'optimisation & co ...
Si tu es juste l'admin ou que tu as choisi le soft qui tourne, trouves-en un bien foutu qui fasse la même chose, ca doit exister et il sera dur à trouver.
donc mod_status t'aidera, et si tu as le loisir de faire le goret "ab" ( apache benchmark ) est un bon stress test pour savoir ou cela merde :)
désolé, mais ce que tu as fait signifie que tu n'as pas compris le fonctionnement de la configuration de apache. Il te faut relire le manuel de apache.
ServerName doit contenir un nom pouvant etre résolu/transformé par le systeme en une adresse IP ( cad un nom du type www.exemple.com ou une entrée de ton /etc/hosts )
DocumentRoot déclare le chemin racine d'un host ou d'un virtualhost et ton documentroot pointe directement vers un dossier semblant stocker un phpmyadmin
NameVirtualHost ne sert uniquement que si tu utilises la directive VirtualHost de tel manière que la selection ne se fait pas sur l'IP mais sur le nom
Sans directive VirtualHost, la directive NameVirtualHost ne sert à rien.
Comme tu ne donnes que ton fichier dans conf.d , j'en conclus necessairement qu'il manque pleins de fichiers et que ta conf risque de ne jamais marché car tu entres en collision avec des confs et des virtualhosts déjà parametrés.
Je ne connais aucun tutoriels pour la conf apache, j'ai simplement lu la doc sur http://httpd.apache.org pour chacune des versions apache avec lesquelles j'ai bossées.
Déjà prend le temps de regarder comment est configuré dans son ensemble ton apache, cela t'aidera beaucoup pour avoir une vision globale de la chose.
Globalement c'est très courant. Pour les étudiants c'est une bizutage qui dure longtemps. Une fois que les étudiants ont passé ce bizutage, ils sont très content de profiter de leur status d'ex-étudiant. Et vu le bizutage subit, ils leurs semblent qu'ils méritent bien ce nouveau traitement de faveur et donc vont le défendre.
On voit ça très souvent et pas seulement dans l'éducation. Inutile de chercher les politiques pour trouver ce type de comportement lamentable.
c'est comme les criminels et autres délinquants multi-récidivistes qui arguent de mal traitance & co dans leur enfance et une reproduction d'un schema connu.
Ou comme les esclaves qui étaient contre la liberté dans "les petits dieux" de terry pratchett ... au choix.
En fait, j'appelle le client pour lui dire que j'arrive dans le train suivant suite :
- à une grève de la RATP
- à un incident de voyageur
- à une manif qui a bloqué le taxi
je lui donne rendez vous pas loin de la gare, et m'engage à l'inviter à déjeuner.
Je sors discretement de la gare, va trouver une prostituée pour me calmer un peu. Au passage, je lui demande si elle a une adresse d'un dealer pour un peu de coke histoire de me détendre juste avant le rendez vous, et fait une remarque salace qui se veut drole sur le fait que je ne peux arriver la braguette ouverte.
Je vais voir le dealer, prend la coke et essaie de me procurer une arme à feu. Pour le faire rire, je lui demande une facture avec TVA pour la faire passer en note de frais.
J'arrive au rendez vous, et déjeune tranquillement avec le client. Nous rigolons, puis allons voir ma nouvelle copine qui travaille près de la gare.
Je retourne au taff, et vais negocier avec mon arme, grouillot et Duglandier un peu de tranquilité jusqu'à ma retraite. J'en profite pour faire passer la coke, les passes, le train, l'arme et le déjeuner en note de frais lié au déplacement pro.
pfff ... meme pas besoin de citation car il faudrait citer aussi mes phrases que tu tronques, et les erreurs de lectures que tu fais.
un soft que tu écris qui utilise du code affero, tu dois mettre un lien vers ton source et dire qu'il existe un originel et donc fournir le lien aussi.
un soft que tu écris qui utilise du code sous licence BSD, tu dois mettre une mention ou un lien vers un document quelque part qui parle de l'outil originel, fournir les sources ne sont pas obligatoires.
tu la vois la grosse ressemblance ?
tu vois qu'il y a presque les mêmes obligations, juste que l'affero oblige à fournir un source là où la bsd à pub non ?
Je parle de se poser des questions, et tu me répond que je ne m'en pose pas ? je ne dis pas avoir les réponses, sinon je demandrai à être cru.
je dois être à l'ouest des fois ...
Je parle de la prévalence d'une GPL sur l'autre ?
Laquelle des deux prévaut ?
c'est pourtant simple, non ?
tu me donnes même raison sans t'en rendre compte ... c'est fort ca.
Je te suggere fortement de lire l'article 9 de la GPL, qui dit que s'il est spécifié "any later version", tu peux distribuer selon les termes de la version précisée OU n'importe quelle autre version ulterieure.
donc selon l'article 9, une GPL 2 c'est uniquement GPL 2 et une GPL 2+ est version 2 ou supérieur.
C'est ce que je dis, ce que j'écris !
Maintenant, quand tu mélanges du code GPL 2 et GPL 2+ ... le final doit respecter quoi ?
réfléchit au fait que tu n'as pas le droit de modifier les termes de la licence originelle !
donc au final ta licence GPL2 issu du mélange sera avec ou sans la mention "or any later version" ?
dire que c'est la GPL2 qui prévaut sur la GPL2+ revient à restreindre le droit concédé par l'auteur originel aux utilisateurs ... et ca TOUTES LES GPL L'INTERDISENT.
et vice versa et pour exactement les memes raisons, la GPL2+ ne peut prévaloir sur la GPL2.
c'est une évidence ...
Si pour toi ce n'est pas une évidence :
quelle est la licence finale d'un code mélangeant à l'origine du code GPL2 et GPL2+ sachant que tu n'es pas l'ayant droit de ces codes ?
ta réponse ne tiens qu'en 4 possibilités :
A. violation de la GPL
B. GPL2
C. GPL2+
D. Obiwan kenobi
est dite GPL 2 :
"you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License"
est dite GPL 2+ :
"you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or any later version."
Donc quand tu mélange du code GPL 2 et GPL 2+ ... la quelle des deux mentions doit tu garder ?
aucune car si tu garde l'une tu entres en violation du désir de l'auteur de l'autre en restreignant les droits concédés ou en étendant ces mêmes droits !
si tu gardes la GPL 2 ... tu enleves le "or any later version" de l'autre ce qui est interdit par la GPL2+ .
si tu gardes la GPL 2+ ... tu ajoute le "or any later version" à l'autre ce qui est interdit par la GPL2 .
Voila pourquoi une GPL2 et une GPL2+ ne sont pas compatible.
GPL2 et GPL2+ sont compatibles tant qu'on essaye pas de passer la partie "+" sous GPL3, il n'y a donc pas de soucis si on reste au plus petit dénominateur commun.
En fait c'est la même chose tant qu'on regarde pas les différences.
Les licences BSD avec clause "publicité" sont incompatibles avec la GPL2/3 et donc incompatibles avec AGPL3 (qui n'est qu'un hack de la GPL3).
sur la page faite surement par des noobs moins au courant que toi http://www.fsf.org/licensing/licenses/gpl-howto.html :
If you are releasing your program under the GNU AGPL, and it can interact with users over a network, the program should offer its source to those users in some way. For example, if your program is a web application, its interface could display a “Source” link that leads users to an archive of the code. The GNU AGPL is flexible enough that you can choose a method that's suitable for your specific program—see section 13 for details.
tu comprends comment ton obligation de lien source ? C'est une putain de clause de publicité !
Donc prendre une BSD avec publicité ( obligation de mettre une mention sur l'origine pas nécessairement les source ) et prendre une affero ... les 2 licences sont respecté si tu colles un lien vers les 2 sources !
Un peu de bon sens quand meme, il faut sortir des poncifs de la FSF quand on parle de licence. Si on a un cerveau pour détecter le FUD Microsoft anti libre, ce même cerveau est capable de marcher de la même manière pour détecter les incohérences de discours de la FSF
ca fait plusieurs années que j'en parle - et très certainement, je suis libriste et fais du lobbyisme pro libre bien avant que tu installes ton premier linux - à la différence des autres lobbyistes, je ne te demande pas de me croire, je te demande de chercher la réponse par toi même, de t'interroger.
- GPL 2 strict est incompatible avec GPL 3 strict par exemple.
- Pour ce qui est de l'artistic, on parle de la 1 ou la 2 ?
- il me semble qu'il manque certaines licences "importantes"
- j'ai comme un doute sur le cas CECILL+LGPL , ils faut integrer chacun des deux projets dans des GPL de meme saveur que la LGPL pour pouvoir obtenir uniquement du GPL a la fin sachant que les projets initiaux gardent leur licence
Pourtant, il me semble qu'un code source sous licence BSD peut être inclus dans un code source sous licence GPLv2. Ou bien ceci implique de mettre les fichiers modifiés en question sous double licence ?
Alors tu as des licences qui explicitement se subrogent à une autre ( LGPL -> GPL ), d'autre se subrogent implicitement selon le contexte ( GPL2->GPL2 ).
une GPL2 et une GPL2+ sont incompatible uniquement parce que mélanger ces deux licences dans du code impose de violer une des deux licences ( par le non respect d'une des deux fameuse clause absorbante de projet annexes ).
Sur le même principe la BSD à publicité n'est pas compatible avec la GPL puisque la clause de publicité n'est pas une clause absorbable par une GPL ( donc violation d'une des deux licences ).
Par contre, il serait interessant d'étudier la comptabilité d'une BSD à publicité avec l'Affero GPL : intuitivement ( vu l'heure ), il y a possibilité de rendre la BSD à publicité absorbable par l'Affero GPL.
Il ne faut pas croire que cela annule la licence originelle ! sinon cela serait une violation de cette meme licence. Sans être de la double licence, la licence est uniquement spécifique à chaque ligne de code ... donc c'est mono licence par ligne de code :)
GRRR tar n'est pas moins fiable ou plus fiable ... tar est bien pour un lecteur de bande.
tu fais pas 3 000 kilometres de désert en smart, tu fais pas tous les jours tes 10 blocs d'immeuble à paris avec un 4x4 :
- un 4x4 c'est adapté au désert
- une smart c'est adapté à la ville
tu ne stockes pas une FS sur une bande, c'est contre performant au niveau des IO.
de la même manière utilisé un tar plutôt qu'une image disque sur un disque est contre performant au niveau des IO.
tar est linéaire, une fs est un arbre ... et si tu prend une fs pensé de manière judicieuse, tu te garantie une profondeur d'au plus log(total fichier)/log(densité)
et cette profondeur représente le nombre maximum d'accès disque pour trouver un fichier.
donc si tu veux une densité de 256, pour une profondeur de 4, tu gères 4 milliards de fichiers :)
donc tu peux identifier un fichier parmis 4 000 000 000 en seulement 4 acces disques ! sur un tar, au mieux tu auras 1 acces disque au pire tu en auras 4 000 000 000 :)
donc, sur une bande linéraire ou tu ne peux que dérouler ou enrouler, tar est parfait, et il te faudra dérouler les 4 000 000 000 de fichiers si celui que tu cherches est tout à la fin de la bande.
sur un disque, tar est contre productif. ca ne veut pas dire que c'est un mauvais outil, non, tar est un bon outil ... mais il faut l'utiliser là ou c'est utile :)
maintenant, c'est une question de liberté individuelle, comme pour les 4x4 en ville : certaines aiment les 4x4 en ville d'autre trouvent cela absurde ;)
debugfs est mon meilleur ami depuis decembre 95 :D
tu confond un systeme parfait avec un système dont on sait qu'il peut tomber en panne.
Si tu as de la chance, cela ne tombe pas en panne.
Si tu n'en as pas, en cas de panne, tu peux identifier ce qui merde.
Entre restaurer un fichier client intégral datant de J-14 ou la quasi intégralité du fichier qui a J-7 et juste ce qui manque dans le fichier J-14 ... il y a une différence ;)
Détail, l'intégrité des données est importante, et cela se gere aussi du coté backup ... donc, il faut pouvoir identifier les informations manquantes pour agir en conséquence.
maintenant, un secteur complet d'une FS qui est corrompu, fsck en mode -n ( le -y etant le piège à con ) pour identifier les problèmes, debugfs pour reconstruire ... c'est plus mieux quand meme qu'un tgz intégralement bon pour la poubelle.
je me repete :
tar n'est pas un probleme, c'est juste un format d'archivage linéaire/séquentiel ... donc parfait pour une lecteur de bande, inutile pour un disque avec des accès aléatoire.
il faut d'autres modèles d'archivage sur disque qu'un archivage de type bande ... surtout pour de la sauvegarde incrémental ( et le mode batch de rsync est cool pour déterminer le delta à archiver et le delta qui a été archivé ).
maintenant, gzip/compress/rar/zip/uc2/bzip/... sont des algorithmes de compression de données ... le but de la compression n'est pas de faire des archives, mais de faire que l'information prenne le moins de place possible en éliminant la redondance, les bits inutiles.
Donc plus ton taux de compression est important plus chaque bit du fichier compressé comporte de l'information. Si tu introduit une corruption dans un fichier compressé, cette corruption n'a pas un impact local, mais à un impact global sur toute le document.
Si tu corromps un tar non compressé, tu peux détecter la corruption et essayer de passer outre ( histoire de vanter tar tout court ) ... même si ce n'est pas facile à faire, c'est faisable.
par contre, sur ton tar.gz, si tu le corromps, tout est bon pour la poubelle.
maintenant, un systeme de fichier offre des outils comme fsck et un systeme d'accès non linéaire ... alors que pour sortir un fichier d'une grosse archive tar, il faut :
init - aller au début
1 - lire les entete
2 - si le nom correspond on extrait le fichier et on s'arrete
3 - sinon deplacer la tete de la taille en octet déclaré dans les entetes puis aller à l'etape 1
donc un tar de 1Go de plein de petits fichiers, c'est une plaie au niveau acces ... alors qu'une filesystem de 1Go avec les memes petits fichiers, offre un moyen de trouver rapidement le fichier que l'on cherche.
maintenant, rien ne t'empeche de compresser ton image disque, mais cela sera comme un tar.gz ;)
Quand tu rétablis une sauvegarde, tu ne rétabli pas nécessairement toute cette sauvegarde ... par exemple tu n'as besoin que de rétablir 2 fichiers et non le reste.
l'image disque offre donc un moyen d'acces rapide quand on stocke ses sauvegardes sur des disques ... sur un lecteur de bande, tar est largement plus efficace.
JE n'ai aucun problème particulier avec tar ou gzip :D
JE les utilise là où JE considère qu'ils satisfassent mes attentes.
par contre, JE expose MON opinion en disant "tar et gzip c'est bien pour certaines choses mais JE ne l'utilise pas au niveau backup disk pour diverses raisons"
Et quand une personne m'interpelle sur le pourquoi, j'expose plus précisement MES raison qui ME permettent de justifier MON opinion.
par contre TU as un problème de lecture du francais, TU sembles avoir une lecture orientée de MON propos.
Maintenant, si tu as des arguments au niveau algorithmique justifiant le fait que gzip est génial pour du backup ( je te rappelle que j'ai dit que tar etait bien pour les backup sur bande ), expose les.
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é ... TOI, TU n'as exposé que TON sentiment, aucun argument laissant entendre une preuve avec une démonstration.
"RFC" contre "croyance benoite" ... ben ca dépend si tu es croyant parce qu'il faut croire ou tu crois à ce que tu peux expliquer.
Donc ton exemple de on upgrade un SGBD ... je te pose une question simple :
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é ) ?
TU N'AS AUCUNE RAISON !
ON NE COUPE PAS UN SERVICE QUI FONCTIONNE !
TU NE COUPE QUE POUR DES PROBLEMES DE SECURITE OU D'INTEGRITE DES DONNEES !
en fait, je pense qu'elle est là la différence entre MA vision et TA vision :
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.
tu fais ta prod en unstable, tu as 300 gentoo différentes ( compilé chacune à la mano avec amour ).
Moi, j'ai une vie, je veux que mon SI soit stable, je m'en fous d'avoir une truc top moumoute, je veux pouvoir dormir la nuit, pouvoir aller au ciné ... en fait, ne pas avoir à dire "je suis informaticien, le boulot m'appelle" chaque fois que je sors diner avec ma femme ... donc, validation, vérification, controle, redondance, redondance, duplication.
Concretement, un tar étendu via un BASE64+controle sur les 4x2bits vacants , ca me semble largement plus sur que le meme tar suivi d'un gzip
Ton gzip prend peu de place à coté de mon bloat ...
maintenant, essaie de corrompre la totalité de mon bloat autrement qu'en passant au pilon le support :p
Par contre, prend une image, gzip là, change 1 octet quelque part, et ungzip apres ...
je pense que tu vois la différence ... sauf si tu n'as rien compris au seul interêt de la compression de données.
donc en fait tu stockes dans un gzip, ton arbre de token via un arbre de huffman ( = le token le plus fréquent sera le plus court ), puis tes données sous forme de liste de token.
Donc, une erreur dans l'arbre de token, sur un token long est peu génant, une erreur sur un token court est grave.
Apres une erreur dans la liste des tokens est génante ... tu peux imaginer des sommes de controle sur ton block mais bof.
Du coté de tar, tu as l'option -t qui permet de verifier l'intégrité d'un tar. en cas de problème, le tar considère que tout le reste est foiré ... sauf bidouille assez infect dans le format tar, cela n'est pas top.
Donc sur ton tar.gz, il suffit d'une petite erreur ( facile à obtenir ), pour chier ton archive.
je n'appelle pas cela un format de sauvegarde, c'est bien pour un truc qui est "in the cloud" ( pour faire dans la hype actuelle - sinon pour faire dans le revival du film "antitrust", "la solution est dans la bande passante !" ).
un exemple avec tes photos argentiques :
tu entasses et presse au sers-join les negatifs et les photos ou tu les séparent proprement en isolant chacun de manière plus ou moins hermetique de l'humidité, de la lumière, de la poussière ?
dans un cas, ca prend moins de place et au moindre probleme tout par à la poubelle ... dans l'ordre, ca prend beaucoup plus de place mais au moins tu les conserve pendant très longtemps et si un negatif ou une photo à un probleme, c'est juste un petit probleme dans une immensité bien conservé.
je me cite moi meme :
le tar ne doit être utilisé que comme outil qui à l'origine archivait sur bande ... donc avec un lecteur de bande.
je ne jette pas l'oprobe sur tar !
nous parlons de sauvegarde, et tar rend service sur un lecteur de bande pas sur un disque !
le format tar.gz est un détournement de l'usage originel de tar ( un peu comme cliquer sur "démarrer" pour éteindre son windows :p )
un des critères les plus important d'une sauvegarde est la fiabilité d'une information.
je parle de cela.
Compresser une information dans le but de sauvegarde est pire que ne pas faire de sauvegarde.
Pourquoi je parle de cela ? parce que les problèmes nécessitant une sauvegarde sont :
- risque de corruption des données
- risque de perte des données
- risque d'indisponibilité partielle ou totale des données ( hard cassé )
Donc une sauvegarde doit garantir :
- une étanchéité vis à vis du support = support un peu défaillant, données lisibles
- une étanchéité vis à vis du format = format plus ou moins corrompu, format quand meme exploitable
- une étanchéité vis à vis des outils = le soft de restitution est out, il faut pouvoir retablir
- une étanchéité vis à vis de l'accessibilité = il faut pouvoir vérifier rapidement l'intégrité du support, du format, des outils de restitution
Donc :
A. il ne faut pas stocker dans un format compressé.
L'exemple du RLE était parfait pour comprendre.
sur un algorithme de la famille des LZ qui est à dictionnaire dynamique ( cas de compress, zip, gzip & co ), une erreur de reconstitution du dictionnaire produit un arret de l'algorithme donc tout est perdu après l'erreur
B. il faut un format le plus proche du format natif
le mieux pour sauvegarder des données SQL est un fichier texte contenant des INSERT.
le mieux pour un fichier HTML est HTML.
le mieux pour un binaire, c'est le binaire lui meme et ses sources.
un binarydump des tables ou une copie à chaud des tables, introduit un risque d'erreur indetectabe. on peut détecter une erreur de charset ( en UTF16 ou UTF32 ) d'un fichier texte, pas une erreur dans un binaire sans un parser pour chaque format.
C. il faut que le support ( logique ou/et physique ) offre une redondance des données
souvenir souvenir, les lignes séries, les bits de terminaison, les sommes de controles & co ...
on envoyait plus d'info sur une liaison de type série longue distance, ce qui induisait un debit effectif largement inférieur au débit réel : pour éviter de rejouer l'ensemble d'une communication, il était préférable de pouvoir détecter les séquences à problèmes et les corriger automatiquement et d'envoyer un signal d'erreur pour qu'il rejoue la fenetre de séquence.
Au niveau du support logique et physique, il faut la même chose :
- des sommes de contrôles non pas sur un tar ou une iso, mais sur chaque fichier de l'iso ou du tar
- pouvoir automatiser les corrections les plus fréquentes ( plusieurs fois 1 bits unique dans un bloc signé )
D. l'outil doit s'assurer qu'il sauvegarde bien ce qu'il doit sauvegader
Sur une sauvegarde, il faut que le support physique puisse offrir une redondance exploitable mais il faut aussi que l'outil de sauvegarde ( le cas de rsync me semble t il moyennant le mode batch et checksum ) puisse garantir que ce qui a été copié est bien ce qui devait être copié ( comparaison post copie ).
Sur une FS subissant beaucoup d'ecriture, un LVM snapshot sera nécessaire au préalable après s'être assuré du lock de la FS pour sauvegarder un état sans écriture en cours.
Conclusion :
un tar + gz + ftp ( ou autre ) n'offre pas la même garantie au niveau sauvegarde que ce dont je parle.
Si c'est pour sauvegarder ses photos de voyage, un tgz sur cd gravé est parfait.
Si c'est des données d'une entreprise, il faut s'assurer que ce qui est fait est bien fait, et il faut donc vérifier/Tester ( et je rejoins celui à qui je répondais ).
mais vérifier 1 sauvegarde, ne fait que vérifier 1 sauvegarde au moment de la vérification, cela n'offre aucune garantie qu'au bout de 1 semaine les données sont toujours exploitable ... c'est un pari sur une croyance pas un fait garanti.
La sauvegarde ne s'improvise pas ... et les bons outils de sauvegardes libres sont très rare, et ceux qui sont simple à mettre en oeuvre, sont inexistant.
Donc je maintiens, si la time machine d'apple n'est pas parfaite, elle doit servir de modèle.
de la nécessité de ne pas compresser les sauvegarde ... comme ca, l'intégrité du support ne nuit que très faiblement à la qualité de la sauvegarde.
1bit de modifié sur un tgz, et c'est le tgz qui est bon pour la poubelle.
1bit sur une image FS, ca se récupère plus facilement.
donc ne jamais faire des fichiers tar et encore moins de tar.gz pour de la sauvegarde !
le tar ne doit être utilisé que comme outil qui à l'origine archivait sur bande ... donc avec un lecteur de bande.
sur un disque, rsync c'est très bien ( par contre, je ne sais pas si il existe une FS avec systeme de correction d'erreur pour l'intégrité des données - genre backupFS et non e2fs over RAID )
Au pire, tu prend un MACOS X léopard avec time-machine + time capsule ( pas de truc équivalent au niveau backup en libre ).
# petit petit petit ! par ici ! petit petit petit !
Posté par Mouns (site web personnel) . En réponse au journal Moyen de transport farfelu. Évalué à 5.
Le sous marin fait cela avec des salles d'air qui explusent l'eau pour monter, et une evacuation de l'air de la salle pour descendre.
Tu peux imaginer :
un réservoir d'hélium comprimé ( comme les bombonnes qui existe dans le commerce spécialisé et qui ne s'envole pas )
une salle de détente pouvant retenir l'hélium tout en le maintenant à la pression extérieur
sauf que le sous marin utilise la gravité pour s'aider ce qui fait qu'il est peu consommateur d'énergie sur ses phases ascendantes et descendantes ( sauf usage de moteur pour forcer les choses ).
Par contre, se pose 2 grosses questions bien complexe dans ton cas :
- comment forceras tu le retour de l'hélium dans son reservoir ?
- comment fais tu pour produire ou récolter de l'hélium ?
En fait, c'est cela tes deux gros problèmes ;)
restera les détails comme la régulation de la pression dans la salle de détente et le controle de l'ascension et de la descente pour éviter les accidents vasculaires, ... mais globalement, les solutions existent déjà.
[^] # Re: question
Posté par Mouns (site web personnel) . En réponse au journal Iron Man. Évalué à 10.
pour le moment, la dépêche a plus de personne favorable que de personnes défavorables, et un tro^Wdébat émerge sur qu'est ce que le hors sujet en dépêche de linuxfr ;)
de toute facon, comme tu l'as dit dans ta dépêche, le film est déjà sorti depuis un moment, alors rassure toi ;)
En fait, il y a les partisans du " c'est sympa cela permet de varier ", du " c'est la tradition, et les traditions sont sacrés ", du " ca ne parle pas du libre donc dehors ".
Perso, je vote " c'est sympa ca permet de varier " ...
et j'argue sur des faits et les choix éditoriaux des hors sujets :
- aucune dépêche racketiciel n'a de lien avec le libre puisque cela n'empeche pas d'installer linux, c'est juste de la propagande de défense de consommateur
- DADVSI & co, parle la portée de la responsabilité pénale des devs et éditeurs, question qui est identique pour un soft propriétaire dont les entreprises éditrices et developpeuses sont aussi pénalement responsable
- A coté de cela, les brevets logiciels touchent aussi bien le libriste que le non-libriste donc hors sujet aussi
- je ne parle pas de la pub déguisé quand tel société ou commercant vend tel produit dans tel condition
Donc de cette liste pourtant qui semble en charte, s'avèrent être dans les faits plutôt limite.
Quand on regarde les dépêches "réellement en charte" et qui passent ( la très grande majorité sont bien faite - merci aux rédacteurs ), nous avons :
- une release de distrib
- une install party
- une conf de stallman qui dit que le libre c'est cool
- une release de wikiroxor ou libglop ou ERPcoincoin ( le seul ERP libre moule-compliant ) ou le dernier framework rupyhp de la mort qui change le web 2.x et le web 3.x
- un salon , évenement, une soirée bière
Si on se limite à cela, les dépêches linuxfr devriendraient chiant à lire.
Diversifier sur les thèmes voisins ou intéressant les geeks permet de maintenir l'interêt au delà du simple planete/agregateur RSS des sites de libristes francophone.
Linuxfr est linuxfr et n'est pas un digg, fuzzer, skyblog de libriste ...
Linuxfr n'est pas un site ultra spécialisé sur le libre, c'est avant tout un point de convergence autour du monde du libre.
Et comme tout point de convergence, il est généraliste et se doit de le rester pour rester ce point d'accueil.
Maintenant, est ce que le cinéma, la litterature ou une humeur a sa place sur linuxfr en dépêche ?
Oui si cela ne represente pas une depeche par pet de travers, film sorti, livre publié. Ce qui fait la force de linuxfr est la diversité de son contenu et de son lectorat ! Se spécialiser à outrance ne pourra que faire fuir ce lectorat et non le fidéliser puisque ce qui lui manque, il le cherchera ailleurs. donc autant aussi aller chercher ailleurs les informations précises sur la dernieres version de gnome, la nouvelle install parti à marly-gaumont, ...
Maintenant, lui apporter des informations variées et diversifiées, ne veut pas dire uniquement que cela ... linuxfr n'est pas non plus un slashdot ;)
Ces informations HS doivent être équilibré et ne pas représenté l'essentiel de l'information, juste une ouverture sur d'autres sujets qui ont plut ( comme pour les dépeches ) aux admoderelecteurs :)
Parce que le geek n'est pas qu'un no-life qui passe sa vie à regarder sa gentoo se compiler, le geek est avant tout quelqu'un de curieux qui s'intéresse à plein de sujets divers, il me semble important de lui apporter aussi des informations hors sujet, des informations auquel il ne pensera pas nécessairement.
Avec Moun's chacun et tous ensemble construisons un linuxfr meilleur !
Moun's le président des news HS sur linuxfr !
Votez le changement dans le respect des traditions !
Votez Moun's !
# yeah !
Posté par Mouns (site web personnel) . En réponse au journal Antispam pour blog et forum. Évalué à 2.
outre le PR, la position, ca va être le TrustRank qui va monter pour ce site.
Si le domaine n'est pas déjà pris, il va l'être dans les prochaines minutes ca c'est certain :D
[^] # Re: apache + mod_php = interpreteur
Posté par Mouns (site web personnel) . En réponse au message process apache gourmand. Évalué à 2.
as tu un awstats ou un webalizer ?
as tu apachetop ?
Maintenant, il ne faut pas croire que "projet réputé avec une super communauté" est un gage sur la qualité et la performance du code.
[^] # Re: Bug ou pas-bug ?
Posté par Mouns (site web personnel) . En réponse au message Test de BilboBlog version 0.2.0. Évalué à 2.
# apache + mod_php = interpreteur
Posté par Mouns (site web personnel) . En réponse au message process apache gourmand. Évalué à 2.
Donc comme pour les scripts python, perl, shell, ... , ton code PHP peut etre bien écrit et optimisé pour la tenue en charge.
Sauf que comme pour la trop grande majorité des scripts python, perl, shell, ton code PHP que tu fais tourné est mal codé avec des algorithmes consommateurs de CPU et pleins de trucs qui ne servent à rien.
Donc si c'est toi qui a codé ce qui tourne, je te conseille vivement de te pencher sur les bouquins d'algorithmiques théoriques, sur les strategies d'optimisation & co ...
Si tu es juste l'admin ou que tu as choisi le soft qui tourne, trouves-en un bien foutu qui fasse la même chose, ca doit exister et il sera dur à trouver.
donc mod_status t'aidera, et si tu as le loisir de faire le goret "ab" ( apache benchmark ) est un bon stress test pour savoir ou cela merde :)
[^] # Re: Conclusion Redmondienne :
Posté par Mouns (site web personnel) . En réponse au journal Statistiques sur les procédures fast track de l'ECMA. Évalué à 3.
N'oublions pas que tout Sir Concis qu'il puisse être, la méthode pour en faire le tour n'en fait qu'un autre Sir Conscrit.
# en fait ...
Posté par Mouns (site web personnel) . En réponse au message Configuration apache. Évalué à 5.
ServerName doit contenir un nom pouvant etre résolu/transformé par le systeme en une adresse IP ( cad un nom du type www.exemple.com ou une entrée de ton /etc/hosts )
DocumentRoot déclare le chemin racine d'un host ou d'un virtualhost et ton documentroot pointe directement vers un dossier semblant stocker un phpmyadmin
NameVirtualHost ne sert uniquement que si tu utilises la directive VirtualHost de tel manière que la selection ne se fait pas sur l'IP mais sur le nom
Sans directive VirtualHost, la directive NameVirtualHost ne sert à rien.
Comme tu ne donnes que ton fichier dans conf.d , j'en conclus necessairement qu'il manque pleins de fichiers et que ta conf risque de ne jamais marché car tu entres en collision avec des confs et des virtualhosts déjà parametrés.
Je ne connais aucun tutoriels pour la conf apache, j'ai simplement lu la doc sur http://httpd.apache.org pour chacune des versions apache avec lesquelles j'ai bossées.
Déjà prend le temps de regarder comment est configuré dans son ensemble ton apache, cela t'aidera beaucoup pour avoir une vision globale de la chose.
[^] # Re: Re:
Posté par Mouns (site web personnel) . En réponse au journal Corpus des fonctionnaires contre les étudiants. Évalué à 5.
On voit ça très souvent et pas seulement dans l'éducation. Inutile de chercher les politiques pour trouver ce type de comportement lamentable.
c'est comme les criminels et autres délinquants multi-récidivistes qui arguent de mal traitance & co dans leur enfance et une reproduction d'un schema connu.
Ou comme les esclaves qui étaient contre la liberté dans "les petits dieux" de terry pratchett ... au choix.
# what if ...
Posté par Mouns (site web personnel) . En réponse au journal Henry III. Évalué à 10.
- à une grève de la RATP
- à un incident de voyageur
- à une manif qui a bloqué le taxi
je lui donne rendez vous pas loin de la gare, et m'engage à l'inviter à déjeuner.
Je sors discretement de la gare, va trouver une prostituée pour me calmer un peu. Au passage, je lui demande si elle a une adresse d'un dealer pour un peu de coke histoire de me détendre juste avant le rendez vous, et fait une remarque salace qui se veut drole sur le fait que je ne peux arriver la braguette ouverte.
Je vais voir le dealer, prend la coke et essaie de me procurer une arme à feu. Pour le faire rire, je lui demande une facture avec TVA pour la faire passer en note de frais.
J'arrive au rendez vous, et déjeune tranquillement avec le client. Nous rigolons, puis allons voir ma nouvelle copine qui travaille près de la gare.
Je retourne au taff, et vais negocier avec mon arme, grouillot et Duglandier un peu de tranquilité jusqu'à ma retraite. J'en profite pour faire passer la coke, les passes, le train, l'arme et le déjeuner en note de frais lié au déplacement pro.
[^] # Re: aux bonheur des drames
Posté par Mouns (site web personnel) . En réponse au journal Comment comparer les licences de logiciel ?. Évalué à 1.
un soft que tu écris qui utilise du code affero, tu dois mettre un lien vers ton source et dire qu'il existe un originel et donc fournir le lien aussi.
un soft que tu écris qui utilise du code sous licence BSD, tu dois mettre une mention ou un lien vers un document quelque part qui parle de l'outil originel, fournir les sources ne sont pas obligatoires.
tu la vois la grosse ressemblance ?
tu vois qu'il y a presque les mêmes obligations, juste que l'affero oblige à fournir un source là où la bsd à pub non ?
Je parle de se poser des questions, et tu me répond que je ne m'en pose pas ? je ne dis pas avoir les réponses, sinon je demandrai à être cru.
je dois être à l'ouest des fois ...
[^] # Re: aux bonheur des drames
Posté par Mouns (site web personnel) . En réponse au journal Comment comparer les licences de logiciel ?. Évalué à 2.
Laquelle des deux prévaut ?
c'est pourtant simple, non ?
tu me donnes même raison sans t'en rendre compte ... c'est fort ca.
Je te suggere fortement de lire l'article 9 de la GPL, qui dit que s'il est spécifié "any later version", tu peux distribuer selon les termes de la version précisée OU n'importe quelle autre version ulterieure.
donc selon l'article 9, une GPL 2 c'est uniquement GPL 2 et une GPL 2+ est version 2 ou supérieur.
C'est ce que je dis, ce que j'écris !
Maintenant, quand tu mélanges du code GPL 2 et GPL 2+ ... le final doit respecter quoi ?
réfléchit au fait que tu n'as pas le droit de modifier les termes de la licence originelle !
donc au final ta licence GPL2 issu du mélange sera avec ou sans la mention "or any later version" ?
dire que c'est la GPL2 qui prévaut sur la GPL2+ revient à restreindre le droit concédé par l'auteur originel aux utilisateurs ... et ca TOUTES LES GPL L'INTERDISENT.
et vice versa et pour exactement les memes raisons, la GPL2+ ne peut prévaloir sur la GPL2.
c'est une évidence ...
Si pour toi ce n'est pas une évidence :
quelle est la licence finale d'un code mélangeant à l'origine du code GPL2 et GPL2+ sachant que tu n'es pas l'ayant droit de ces codes ?
ta réponse ne tiens qu'en 4 possibilités :
A. violation de la GPL
B. GPL2
C. GPL2+
D. Obiwan kenobi
[^] # Re: aux bonheur des drames
Posté par Mouns (site web personnel) . En réponse au journal Comment comparer les licences de logiciel ?. Évalué à 1.
[^] # Re: aux bonheur des drames
Posté par Mouns (site web personnel) . En réponse au journal Comment comparer les licences de logiciel ?. Évalué à 1.
"you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License"
est dite GPL 2+ :
"you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or any later version."
Donc quand tu mélange du code GPL 2 et GPL 2+ ... la quelle des deux mentions doit tu garder ?
aucune car si tu garde l'une tu entres en violation du désir de l'auteur de l'autre en restreignant les droits concédés ou en étendant ces mêmes droits !
si tu gardes la GPL 2 ... tu enleves le "or any later version" de l'autre ce qui est interdit par la GPL2+ .
si tu gardes la GPL 2+ ... tu ajoute le "or any later version" à l'autre ce qui est interdit par la GPL2 .
Voila pourquoi une GPL2 et une GPL2+ ne sont pas compatible.
[^] # Re: aux bonheur des drames
Posté par Mouns (site web personnel) . En réponse au journal Comment comparer les licences de logiciel ?. Évalué à 2.
En fait c'est la même chose tant qu'on regarde pas les différences.
Les licences BSD avec clause "publicité" sont incompatibles avec la GPL2/3 et donc incompatibles avec AGPL3 (qui n'est qu'un hack de la GPL3).
sur la page faite surement par des noobs moins au courant que toi http://www.fsf.org/licensing/licenses/gpl-howto.html :
If you are releasing your program under the GNU AGPL, and it can interact with users over a network, the program should offer its source to those users in some way. For example, if your program is a web application, its interface could display a “Source” link that leads users to an archive of the code. The GNU AGPL is flexible enough that you can choose a method that's suitable for your specific program—see section 13 for details.
tu comprends comment ton obligation de lien source ? C'est une putain de clause de publicité !
Donc prendre une BSD avec publicité ( obligation de mettre une mention sur l'origine pas nécessairement les source ) et prendre une affero ... les 2 licences sont respecté si tu colles un lien vers les 2 sources !
Un peu de bon sens quand meme, il faut sortir des poncifs de la FSF quand on parle de licence. Si on a un cerveau pour détecter le FUD Microsoft anti libre, ce même cerveau est capable de marcher de la même manière pour détecter les incohérences de discours de la FSF
ca fait plusieurs années que j'en parle - et très certainement, je suis libriste et fais du lobbyisme pro libre bien avant que tu installes ton premier linux - à la différence des autres lobbyistes, je ne te demande pas de me croire, je te demande de chercher la réponse par toi même, de t'interroger.
[^] # Re: Matrice de compatibilité de licences... suffisait de demander :-)
Posté par Mouns (site web personnel) . En réponse au journal Comment comparer les licences de logiciel ?. Évalué à 3.
- GPL 2 strict est incompatible avec GPL 3 strict par exemple.
- Pour ce qui est de l'artistic, on parle de la 1 ou la 2 ?
- il me semble qu'il manque certaines licences "importantes"
- j'ai comme un doute sur le cas CECILL+LGPL , ils faut integrer chacun des deux projets dans des GPL de meme saveur que la LGPL pour pouvoir obtenir uniquement du GPL a la fin sachant que les projets initiaux gardent leur licence
# aux bonheur des drames
Posté par Mouns (site web personnel) . En réponse au journal Comment comparer les licences de logiciel ?. Évalué à 4.
Alors tu as des licences qui explicitement se subrogent à une autre ( LGPL -> GPL ), d'autre se subrogent implicitement selon le contexte ( GPL2->GPL2 ).
une GPL2 et une GPL2+ sont incompatible uniquement parce que mélanger ces deux licences dans du code impose de violer une des deux licences ( par le non respect d'une des deux fameuse clause absorbante de projet annexes ).
Sur le même principe la BSD à publicité n'est pas compatible avec la GPL puisque la clause de publicité n'est pas une clause absorbable par une GPL ( donc violation d'une des deux licences ).
Par contre, il serait interessant d'étudier la comptabilité d'une BSD à publicité avec l'Affero GPL : intuitivement ( vu l'heure ), il y a possibilité de rendre la BSD à publicité absorbable par l'Affero GPL.
Il ne faut pas croire que cela annule la licence originelle ! sinon cela serait une violation de cette meme licence. Sans être de la double licence, la licence est uniquement spécifique à chaque ligne de code ... donc c'est mono licence par ligne de code :)
[^] # Re: C'est gonflé ...
Posté par Mouns (site web personnel) . En réponse au journal Etudes sur les sociétés s'impliquant le plus dans le développe du noyau Linux. Évalué à 3.
c'est un choix personnel ( comme pour tar ou les 4x4 ;) ) de mettre des morceaux de GNU autour de son linux.
[^] # Re: Bof...
Posté par Mouns (site web personnel) . En réponse au journal Linuxfr le site le plus moche au monde?. Évalué à 3.
le petit article qui m'a fait découvrir ce fabuleux site
http://www.fredcavazza.net/2008/03/21/havenworks-le-pire-sit(...)
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . En réponse au journal Migration foirée. Évalué à 3.
tu fais pas 3 000 kilometres de désert en smart, tu fais pas tous les jours tes 10 blocs d'immeuble à paris avec un 4x4 :
- un 4x4 c'est adapté au désert
- une smart c'est adapté à la ville
tu ne stockes pas une FS sur une bande, c'est contre performant au niveau des IO.
de la même manière utilisé un tar plutôt qu'une image disque sur un disque est contre performant au niveau des IO.
tar est linéaire, une fs est un arbre ... et si tu prend une fs pensé de manière judicieuse, tu te garantie une profondeur d'au plus log(total fichier)/log(densité)
et cette profondeur représente le nombre maximum d'accès disque pour trouver un fichier.
donc si tu veux une densité de 256, pour une profondeur de 4, tu gères 4 milliards de fichiers :)
donc tu peux identifier un fichier parmis 4 000 000 000 en seulement 4 acces disques ! sur un tar, au mieux tu auras 1 acces disque au pire tu en auras 4 000 000 000 :)
donc, sur une bande linéraire ou tu ne peux que dérouler ou enrouler, tar est parfait, et il te faudra dérouler les 4 000 000 000 de fichiers si celui que tu cherches est tout à la fin de la bande.
sur un disque, tar est contre productif. ca ne veut pas dire que c'est un mauvais outil, non, tar est un bon outil ... mais il faut l'utiliser là ou c'est utile :)
maintenant, c'est une question de liberté individuelle, comme pour les 4x4 en ville : certaines aiment les 4x4 en ville d'autre trouvent cela absurde ;)
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . En réponse au journal Migration foirée. Évalué à 2.
debugfs est mon meilleur ami depuis decembre 95 :D
tu confond un systeme parfait avec un système dont on sait qu'il peut tomber en panne.
Si tu as de la chance, cela ne tombe pas en panne.
Si tu n'en as pas, en cas de panne, tu peux identifier ce qui merde.
Entre restaurer un fichier client intégral datant de J-14 ou la quasi intégralité du fichier qui a J-7 et juste ce qui manque dans le fichier J-14 ... il y a une différence ;)
Détail, l'intégrité des données est importante, et cela se gere aussi du coté backup ... donc, il faut pouvoir identifier les informations manquantes pour agir en conséquence.
maintenant, un secteur complet d'une FS qui est corrompu, fsck en mode -n ( le -y etant le piège à con ) pour identifier les problèmes, debugfs pour reconstruire ... c'est plus mieux quand meme qu'un tgz intégralement bon pour la poubelle.
je me repete :
tar n'est pas un probleme, c'est juste un format d'archivage linéaire/séquentiel ... donc parfait pour une lecteur de bande, inutile pour un disque avec des accès aléatoire.
il faut d'autres modèles d'archivage sur disque qu'un archivage de type bande ... surtout pour de la sauvegarde incrémental ( et le mode batch de rsync est cool pour déterminer le delta à archiver et le delta qui a été archivé ).
maintenant, gzip/compress/rar/zip/uc2/bzip/... sont des algorithmes de compression de données ... le but de la compression n'est pas de faire des archives, mais de faire que l'information prenne le moins de place possible en éliminant la redondance, les bits inutiles.
Donc plus ton taux de compression est important plus chaque bit du fichier compressé comporte de l'information. Si tu introduit une corruption dans un fichier compressé, cette corruption n'a pas un impact local, mais à un impact global sur toute le document.
Si tu corromps un tar non compressé, tu peux détecter la corruption et essayer de passer outre ( histoire de vanter tar tout court ) ... même si ce n'est pas facile à faire, c'est faisable.
par contre, sur ton tar.gz, si tu le corromps, tout est bon pour la poubelle.
maintenant, un systeme de fichier offre des outils comme fsck et un systeme d'accès non linéaire ... alors que pour sortir un fichier d'une grosse archive tar, il faut :
init - aller au début
1 - lire les entete
2 - si le nom correspond on extrait le fichier et on s'arrete
3 - sinon deplacer la tete de la taille en octet déclaré dans les entetes puis aller à l'etape 1
donc un tar de 1Go de plein de petits fichiers, c'est une plaie au niveau acces ... alors qu'une filesystem de 1Go avec les memes petits fichiers, offre un moyen de trouver rapidement le fichier que l'on cherche.
maintenant, rien ne t'empeche de compresser ton image disque, mais cela sera comme un tar.gz ;)
Quand tu rétablis une sauvegarde, tu ne rétabli pas nécessairement toute cette sauvegarde ... par exemple tu n'as besoin que de rétablir 2 fichiers et non le reste.
l'image disque offre donc un moyen d'acces rapide quand on stocke ses sauvegardes sur des disques ... sur un lecteur de bande, tar est largement plus efficace.
Est ce plus clair ?
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . En réponse au journal Migration foirée. Évalué à 6.
JE n'ai aucun problème particulier avec tar ou gzip :D
JE les utilise là où JE considère qu'ils satisfassent mes attentes.
par contre, JE expose MON opinion en disant "tar et gzip c'est bien pour certaines choses mais JE ne l'utilise pas au niveau backup disk pour diverses raisons"
Et quand une personne m'interpelle sur le pourquoi, j'expose plus précisement MES raison qui ME permettent de justifier MON opinion.
par contre TU as un problème de lecture du francais, TU sembles avoir une lecture orientée de MON propos.
Maintenant, si tu as des arguments au niveau algorithmique justifiant le fait que gzip est génial pour du backup ( je te rappelle que j'ai dit que tar etait bien pour les backup sur bande ), expose les.
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é ... TOI, TU n'as exposé que TON sentiment, aucun argument laissant entendre une preuve avec une démonstration.
"RFC" contre "croyance benoite" ... ben ca dépend si tu es croyant parce qu'il faut croire ou tu crois à ce que tu peux expliquer.
Donc ton exemple de on upgrade un SGBD ... je te pose une question simple :
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é ) ?
TU N'AS AUCUNE RAISON !
ON NE COUPE PAS UN SERVICE QUI FONCTIONNE !
TU NE COUPE QUE POUR DES PROBLEMES DE SECURITE OU D'INTEGRITE DES DONNEES !
en fait, je pense qu'elle est là la différence entre MA vision et TA vision :
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.
tu fais ta prod en unstable, tu as 300 gentoo différentes ( compilé chacune à la mano avec amour ).
Moi, j'ai une vie, je veux que mon SI soit stable, je m'en fous d'avoir une truc top moumoute, je veux pouvoir dormir la nuit, pouvoir aller au ciné ... en fait, ne pas avoir à dire "je suis informaticien, le boulot m'appelle" chaque fois que je sors diner avec ma femme ... donc, validation, vérification, controle, redondance, redondance, duplication.
Concretement, un tar étendu via un BASE64+controle sur les 4x2bits vacants , ca me semble largement plus sur que le meme tar suivi d'un gzip
Ton gzip prend peu de place à coté de mon bloat ...
maintenant, essaie de corrompre la totalité de mon bloat autrement qu'en passant au pilon le support :p
Par contre, prend une image, gzip là, change 1 octet quelque part, et ungzip apres ...
je pense que tu vois la différence ... sauf si tu n'as rien compris au seul interêt de la compression de données.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . En réponse au journal Migration foirée. Évalué à 3.
http://en.wikipedia.org/wiki/Gzip ( http://www.ietf.org/rfc/rfc1952.txt pour le format ) algo http://en.wikipedia.org/wiki/DEFLATE ( mix de LZ77 et Huffman ) connu sous la RFC 1951 ( http://www.ietf.org/rfc/rfc1951.txt ).
donc en fait tu stockes dans un gzip, ton arbre de token via un arbre de huffman ( = le token le plus fréquent sera le plus court ), puis tes données sous forme de liste de token.
Donc, une erreur dans l'arbre de token, sur un token long est peu génant, une erreur sur un token court est grave.
Apres une erreur dans la liste des tokens est génante ... tu peux imaginer des sommes de controle sur ton block mais bof.
Du coté de tar, tu as l'option -t qui permet de verifier l'intégrité d'un tar. en cas de problème, le tar considère que tout le reste est foiré ... sauf bidouille assez infect dans le format tar, cela n'est pas top.
Donc sur ton tar.gz, il suffit d'une petite erreur ( facile à obtenir ), pour chier ton archive.
je n'appelle pas cela un format de sauvegarde, c'est bien pour un truc qui est "in the cloud" ( pour faire dans la hype actuelle - sinon pour faire dans le revival du film "antitrust", "la solution est dans la bande passante !" ).
un exemple avec tes photos argentiques :
tu entasses et presse au sers-join les negatifs et les photos ou tu les séparent proprement en isolant chacun de manière plus ou moins hermetique de l'humidité, de la lumière, de la poussière ?
dans un cas, ca prend moins de place et au moindre probleme tout par à la poubelle ... dans l'ordre, ca prend beaucoup plus de place mais au moins tu les conserve pendant très longtemps et si un negatif ou une photo à un probleme, c'est juste un petit probleme dans une immensité bien conservé.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . En réponse au journal Migration foirée. Évalué à 5.
le tar ne doit être utilisé que comme outil qui à l'origine archivait sur bande ... donc avec un lecteur de bande.
je ne jette pas l'oprobe sur tar !
nous parlons de sauvegarde, et tar rend service sur un lecteur de bande pas sur un disque !
le format tar.gz est un détournement de l'usage originel de tar ( un peu comme cliquer sur "démarrer" pour éteindre son windows :p )
un des critères les plus important d'une sauvegarde est la fiabilité d'une information.
je parle de cela.
Compresser une information dans le but de sauvegarde est pire que ne pas faire de sauvegarde.
Pourquoi je parle de cela ? parce que les problèmes nécessitant une sauvegarde sont :
- risque de corruption des données
- risque de perte des données
- risque d'indisponibilité partielle ou totale des données ( hard cassé )
Donc une sauvegarde doit garantir :
- une étanchéité vis à vis du support = support un peu défaillant, données lisibles
- une étanchéité vis à vis du format = format plus ou moins corrompu, format quand meme exploitable
- une étanchéité vis à vis des outils = le soft de restitution est out, il faut pouvoir retablir
- une étanchéité vis à vis de l'accessibilité = il faut pouvoir vérifier rapidement l'intégrité du support, du format, des outils de restitution
Donc :
A. il ne faut pas stocker dans un format compressé.
L'exemple du RLE était parfait pour comprendre.
sur un algorithme de la famille des LZ qui est à dictionnaire dynamique ( cas de compress, zip, gzip & co ), une erreur de reconstitution du dictionnaire produit un arret de l'algorithme donc tout est perdu après l'erreur
B. il faut un format le plus proche du format natif
le mieux pour sauvegarder des données SQL est un fichier texte contenant des INSERT.
le mieux pour un fichier HTML est HTML.
le mieux pour un binaire, c'est le binaire lui meme et ses sources.
un binarydump des tables ou une copie à chaud des tables, introduit un risque d'erreur indetectabe. on peut détecter une erreur de charset ( en UTF16 ou UTF32 ) d'un fichier texte, pas une erreur dans un binaire sans un parser pour chaque format.
C. il faut que le support ( logique ou/et physique ) offre une redondance des données
souvenir souvenir, les lignes séries, les bits de terminaison, les sommes de controles & co ...
on envoyait plus d'info sur une liaison de type série longue distance, ce qui induisait un debit effectif largement inférieur au débit réel : pour éviter de rejouer l'ensemble d'une communication, il était préférable de pouvoir détecter les séquences à problèmes et les corriger automatiquement et d'envoyer un signal d'erreur pour qu'il rejoue la fenetre de séquence.
Au niveau du support logique et physique, il faut la même chose :
- des sommes de contrôles non pas sur un tar ou une iso, mais sur chaque fichier de l'iso ou du tar
- pouvoir automatiser les corrections les plus fréquentes ( plusieurs fois 1 bits unique dans un bloc signé )
D. l'outil doit s'assurer qu'il sauvegarde bien ce qu'il doit sauvegader
Sur une sauvegarde, il faut que le support physique puisse offrir une redondance exploitable mais il faut aussi que l'outil de sauvegarde ( le cas de rsync me semble t il moyennant le mode batch et checksum ) puisse garantir que ce qui a été copié est bien ce qui devait être copié ( comparaison post copie ).
Sur une FS subissant beaucoup d'ecriture, un LVM snapshot sera nécessaire au préalable après s'être assuré du lock de la FS pour sauvegarder un état sans écriture en cours.
Conclusion :
un tar + gz + ftp ( ou autre ) n'offre pas la même garantie au niveau sauvegarde que ce dont je parle.
Si c'est pour sauvegarder ses photos de voyage, un tgz sur cd gravé est parfait.
Si c'est des données d'une entreprise, il faut s'assurer que ce qui est fait est bien fait, et il faut donc vérifier/Tester ( et je rejoins celui à qui je répondais ).
mais vérifier 1 sauvegarde, ne fait que vérifier 1 sauvegarde au moment de la vérification, cela n'offre aucune garantie qu'au bout de 1 semaine les données sont toujours exploitable ... c'est un pari sur une croyance pas un fait garanti.
La sauvegarde ne s'improvise pas ... et les bons outils de sauvegardes libres sont très rare, et ceux qui sont simple à mettre en oeuvre, sont inexistant.
Donc je maintiens, si la time machine d'apple n'est pas parfaite, elle doit servir de modèle.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . En réponse au journal Migration foirée. Évalué à 2.
1bit de modifié sur un tgz, et c'est le tgz qui est bon pour la poubelle.
1bit sur une image FS, ca se récupère plus facilement.
donc ne jamais faire des fichiers tar et encore moins de tar.gz pour de la sauvegarde !
le tar ne doit être utilisé que comme outil qui à l'origine archivait sur bande ... donc avec un lecteur de bande.
sur un disque, rsync c'est très bien ( par contre, je ne sais pas si il existe une FS avec systeme de correction d'erreur pour l'intégrité des données - genre backupFS et non e2fs over RAID )
Au pire, tu prend un MACOS X léopard avec time-machine + time capsule ( pas de truc équivalent au niveau backup en libre ).
http://www.apple.com/fr/timecapsule/