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 :)

[ Répondre ]

d'un autre coté, il existe des systemes d'exploitation linux sans aucun morceau GNU dedans.

c'est un choix personnel ( comme pour tar ou les 4x4 ;) ) de mettre des morceaux de GNU autour de son linux.

[ Répondre ]

un concour avait été fait sur digg.com : le pire site est http://havenworks.com/

le petit article qui m'a fait découvrir ce fabuleux site
http://www.fredcavazza.net/2008/03/21/havenworks-le-pire-sit(...)

[ Répondre ]

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 ;)

[ Répondre ]

* smack * ( bruit d'un bisou amical )

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 ?

[ Répondre ]

pourquoi cette fixation sur tar ?

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.

[ Répondre ]

S'il manque un 1 bit, gzip et tar savent gérer ça.

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é.

[ Répondre ]

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.

[ Répondre ]

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 ).

http://www.apple.com/fr/timecapsule/

[ Répondre ]

un journal qui périclite ...
d'un parti qui périclite ...
d'un pays qui périclite ...
d'une forme de vie qui périclite ...
au point de finir absorbé dans un trou noir ou de mourir suite au réchauffement climatique.

[ Répondre ]

non, il vient de se pendre ... ca ne le concerne plus du tout.

[ Répondre ]

Je suis d'accord avec toi ... la croissance infinie est impossible.

Toujours est il que sans postuler d'une croissance infini, sans même postuler d'une croissance tout court, il est important de rééquilibrer les richesses ... même dans les pays riches.

Ce que je propose ( et qui ne sera jamais fait ) aura un effet ponctuel sur la croissance, c'est évident, mais cela aura pour effet de donner des moyens financiers à une population qui est aujourd'hui étranglée.

Quand certains après une enquête constatent une petite augmentation du prix du panier de la ménagère, ils oublient un peu vite le sens d'une moyenne.

Aujourd'hui, beaucoup de monde le constate et je le constate moi même, une augmentation des prix importante sur des aliments peu cher.

Mon constat se fait sur mes péchés ( comprendre grosse consommation ) :
- jus de fruit frais
- compotes
- poissons

Je dois dire que mon ticket de caisse hebdomadaire a augmenté de manière significative.

Donc quand un ministre nous sort une étude et nous pond une moyenne de l'augmentation ... cela ne signifie R-I-E-N à part démontrer l'incompétence de ce ministre.

prenons un panier à la con :
- viande 40€
- yahourt 3€

le yahourt passe à 4€ ... le panier total n'augmente que de 1 euro sur 43€ soit à peine 2% pourtant ces foutus yahourts connaissent une augmentation de 33%.

Donc, on peut parler de faire plein de mesure à la con sur la consommation, on peut parler de l'absurdité de représente la croissance ( surtout qu'elle est calculé sur la TVA ), il n'en reste pas moins qu'aujourd'hui, il est nécessaire d'augmenter les salaires.

[ Répondre ]

c'est beau la TVA machin ou la TVA bidule, mais dans les faits :

Soit tu l'appliques à tous les produits et c'est donc les 50% de la population aux revenus "faible" qui se trouvera réellement lésé par cette nouvelle taxe.

Soit tu la mets sur les produits qui ne sont pas de première nécessité : un téléphone fixe n'est pas un produit de première nécessité mais est légalement considéré comme un "luxe" que le consommateur s'accorde ... tu peux ajouter Internet, le ipod, l'ordi, la console, les voyages, les voitures

Soit tu la mets sur les produits de luxe : cartier, vuitton, gautier, chanel, ...

De toute facon, le resultat sera une belle insatisfaction.

Maintenant, tu oses une idée étrange :
si une entreprise s'engage à verser sur 5 ans plus de 1,5 fois l'inflation en augmentation de salaire, alors l'entreprise profitera d'une diminution de charge social a hauteur du double du dépassement tant que la mesure durera. En cas d'arrêt de la mesure, l'entreprise devra rembourser sur les 3 dernieres années l'intégralité des réductions accordées.

Imaginons qu'une entreprise propose une augmentation de inflation+2% sur 10 ans à chacun des salariés, l'entreprise aura donc durant 10 ans 4% de réduction de charges sociales.

Donc le salarié y gagne, l'entreprise y gagne ... ok mais l'état ? ... le salarié du fait de son augmentation dépensera plus ... donc plus de recette TVA et l'état recupère les sous de cette manière.

Ce n'est pas une TVA sociale, mais cela permettra de revaloriser les salaires en donnant à chacun un interet pour le faire.

Mais, c'est osé comme disposition ... d'un autre coté, il n'y a que notre président pour se faire une augmentation de 169%.

[ Répondre ]

en fait ce que tu souhaiterais, c'est une sorte de base de "blob" contenant tes mails et leurs headers et que tu puisse à ta guise construire des arborescences de ces blobs au fils du temps, des filtres et des tes actions ?

En fait, à part réinventer la roue^W^W GIT, je ne vois pas comment faire autrement.

tu peux faire de la merde via des hard-links & co, tu peux passer par une bdd qui représentera un over-head très couteux quand tu auras un beau volume de mail, tu peux inventer plein de technos funs ...

... mais j'ai le sentiment que git fait ce que tu cherches.

En fait, si je devais coder un client mail, je coderai en premier lieu, une interface graphique qui "git-add" les nouveaux mails dans un dossier inbox, "git-mv" dans les différents dossiers, "git-rm" pour la mise à la corbeille, et enfin "git-gc" pour faire le garbage collecting et la refacto des l'arbo. ... après tu peux ajouter le deplacement de l'origine pour le really "expunge" de tes mails et ne garder que les derniers effacés et ceux que tu souhaites bien entendu conserver :)

[ Répondre ]

Bonjour,
M Peter Brabeck boss de Nestlé lance un cri d'alarme contre la transformation de produit alimentaire en bio-carburant.
Selon lui si on continue nous risquons de manquer de nourriture.

Savez-vous que pour produire un litre de bio-carburant il faut utiliser 4000 litre d'eau ?

en quoi ca le dérange ?
n'est ce pas lui qui trouve que l'eau doit être vendu ?
alors 4 000 litres d'eau pour 1 litre de bio carburant, cela lui fait une belle augmentation du chiffre d'affaire de sa boite ?

A moins que cela ne soit pas son eau qui soit utilisé mais une autre et cela l'attriste ... le pov'mossieu.

Clairement, vu les propos qu'il a pu tenir dans son interview diffusé à la fin du film "we feed the world" ( qui est le slogan de Nestlé ), je trouve qu'écouter cet humaniste est plus une connerie qu'autre chose.

Que la production de biocarburant soit polluante, c'est une évidence pour ceux qui ont un peu de bon sens, que le mythe de l'énergie non polluante a encore de beau jour est une autre évidence, mais de là à prendre un vendeur d'eau ( qui est contre l'eau potable gratuite pour tous ) hurler contre le volume d'eau nécessaire pour fabriquer un biocarburant me fait rire ...

... mais bon, qu'il ait raison ou qu'il ait tord, le plus gros problème est la prise de conscience que ce qui cloche dans notre modèle n'est pas nos sources d'énergie mais notre besoin démesurément absurde d'énergie.

Mais chut, EDF & Total & Shell feed the world

[ Répondre ]

http://fr.wikipedia.org/wiki/Berkeley_Software_Distribution

j'ai bien vérifié puisque ma mémoire aurait pu me jouer des tours ... en 1992 et 1993, il n'y avait que 386BSD qui fut abandonné vite fait.

De 386BSD naquirent fin 1993, 2 forks, dont NetBSD reforka par la suite en OpenBSD ...

Je ne veux pas dire, mais ca fait penser à de la dispersion non ?

[ Répondre ]

Pour le rappel, j'ajoute que linux a percé parce que GNU Hurd n'a jamais fonctionné

Stallman nous a promis en 93 que le GNU Hurd allait sortir très bientot et que linux ne sera jamais utilisé ... 15 ans après, on voit que linux a été seul, et a bizarrement percé alors qu'il était seul.

la dispersion est la grande force du libre, sa dispersion est son plus grand point faible.

[ Répondre ]

parce qu'il n'y avait pas qu'un communisme, mais pleins de variations autour.

l'internationnal situationniste a connu aussi la même histoire, à grand coups d'exclusion des dissidents.

Le PS connait la même histoire ... trop de mouvances internes différentes, pas d'union réelle, pas de cohésion, pas un programme du parti, juste des idées entres les tetes d'affiches qui se tirent dans les pattes ... du vide ... rien.

En face, on a de Gaule, puis dissidence et bordel ayant laissé mitterand qui unissait. Puis Chirac et Sarkozy qui ont uni quand la gauche revivait des querelles internes ( la fumeuse gauche plurielle ou gauche polythéiste ).

Aux élections ont à 40 listes de gauches, une liste MoDem, une liste UMP, une liste FN.

Pour les distribs linux c'est pareil, les CMS pareil ...

MediaWiki a uni grace à Wikipédia car wikipedia n'a aucune alternative.

FireFox a uni car il a été rapidement le seul navigateur à peu pres multiplateforme et constant dans son fonctionnement.

OpenOffice.org domine car il n'a aucun concurrent.

GCC est le compilateur ayant uni car il est le seul compilateur multiplateforme et multilangage.

[ Répondre ]

d'avoir expliqué pourquoi le monothéisme a gagné sur le polythéisme.

Un dieu unique avec plein de croyant fait une foule unanime face à une foulitude de dieux avec chacun de ces dieux plusieurs adeptes.

Après, il est toujours plus facile de tuer au nom d'un dieu unique alors que pour le polythéisme, il faut trouver un super dieu qui veut mettre une branlée générale pour pouvoir le faire.

[ Répondre ]

Il faut forcer le meme charset à l'import qu'à l'export.

je n'ai jamais eu de probleme en procédant ainsi.

[ Répondre ]