arnaudus a écrit 5317 commentaires

Sans compter que ça dépend énormément du type de bug. Si le bug c'est une faute de frappe (ça peut être extrêmement bloquant, par exemple un export de fichier "pdd" au lieu de "pdf" <- déja vu, comme bug idiot, dans un produit professionnel en plus), il faudra m'expliquer comment tu justifies plusieurs jours de tests.

Ça dépend aussi de comment le produit en question est codé. Parce que dans une grosse suite bureautique, j'imagine qu'il y a des centaines de modules indépendants. Si l'API est bien documentée, en principe, personne n'aurait dû profiter d'une fonction bugguée pour coder un compensant qui dépend de ce bug pour fonctionner. Et ça de toutes manières, ça doit se "sentir" quand on corrige le bug en fonction de l'importance du composant buggué etc. Un bug qui porte sur le correcteur orthographique, si tu crains des répercussions sur le dessins des cercles à la souris, tu devrais peut-être penser à revoir l'architecture du programme.

Enfin, j'imagine aussi que les bugs sont corrigés en série sur une version instable, puis la release est freezée et testée, avant d'être distribuée au client. Je vois mal des "gros clients" se contenter d'un diff et d'un lien vers le cvs... Je conçois donc qu'une batterie de tests sur plusieurs plateformes etc. peuvent être particulièrement longue (mais elle peut être au moins en partie automatisée, surtout si les releases sont fréquentes, ca doit valoir le coup), mais en tout cas, un bug mineur -> plusieurs jours de tests me semble être une équivalence hasardeuse, et ce même pour un gros projet. C'est peut-être ce qu'on raconte à un décideur pressé pour faire passer une facture salée, mais je reste persuadé qu'il y a des manières de s'organiser en interne pour maintenir la qualité du produit tout en gagnant du temps.

D'un autre côté, comme c'est illégal de produire un outil de contournement des DRM, ça me parait tangeant de développer quelque chose qui va dans ce sens... même si c'est "juste pour regarder comment le fichier est fait M le juge"...

Tu es quand même au courant que ce type de vote n'aura jamais une quelconque légalité? La principale raison, c'est que personne ne pourra garantir que l'électeur n'a pas voté sous la contrainte : tu peux t'assurer que c'est bien lui qui a voté, à la limite par autant de moyens biométriques que tu veux, mais le fait est qu'il est impossible de savoir s'il était ou non seul devant son PC au moment du vote.

Pour les problèmes techniques, ça me parait encore plus délicat. Soit tu donnes l'enveloppe contenant le mot de passe en personne, soit il faut un artifice particulier (du type de ces enveloppes que tu ne peux ouvrir qu'en déchirant des pointillés, ou un code caché derrière un scotch noir qui ne peut pas être recollé).

J'espère ne pas dire de conneries, mais :
* On a N clés C1 distribuées sous forme de mot de passe de manière confidentielle
* On a N clés C2 sans aucune autre info stockées sur le serveur
* On a N checksum S générés par C1 * C2, stockés sur le serveur, et les C1 sont définitivement supprimées du serveur.

Quand on vote, on rentre sa clé C1, le serveur la combine avec toutes les C2 existantes jusqu'à tomber sur un S : il valide le vote, stocke le résultat et supprime le C2 et le S qui ont matché.

Ce qui est sûr, c'est que l'admin du serveur a accès à des données sensibles, mais c'est inévitable, mais il ne peut pas reconstituer les mots de passe. De toutes manières il aura aussi les logs avec les IP etc, donc tu ne peux pas empêcher un point faible de ce côté là. On peut certainement bricoler un truc avec deux serveurs et deux admins différents pour plus de sécurité.

Enfin en fait j'y connais pas grand chose, donc c'est peut-être complètement idiot mon truc.

On peut aussi ajouter qu'XML a le bon goût d'être lisible par un parseur et par un être humain (le périphérique situé entre la chaise et l'écran), surtout si la structure du fichier est bien conçue. Et ça, c'est quand même la classe.

Moi j'aime aussi XML parce qu'il n'y a rien de plus facile que de lire une valeur dans un fichier de 10000 lignes, par exemple avec une expression régulière.

Pour avoir testé, XML c'est quand même la merde par contre pour les gros fichiers.

Je me suis pissé dessus sur "PATH le chemin". En tout cas, c'est mon psy qui va pas être content :-)

Bah non, ça serait trop facile autrement :-) Non, sans blague, je n'arrive pas à comprendre ce qui, dans ma remarque, justifierait ma participation au concours. Je n'aurais jamais eu les idées ni les compétences pour le faire. Par contre, je trouve que certaines idées proposées sont excellentes, et que certaines réalisations graphiques sont excellentes aussi, mais je pense qu'elles ne sont pas forcément dans les mêmes images (à part "ils nous tiennent pas les oreilles", qui n'a pas été promu). Je pense par exemple qu'on obtiendrait quelque chose de vraiment bien en combinant l'aspect graphique du premier avec les barbelés du deuxième, quitte à retirer le verrou. Voila, je viens de participer au concours en donnant une idée :-)

J'imagine que tout a été fait dans les règles avec jury et dessins anonymes et tout? Non, parce qu'en fait j'en aimais bien certains autres. J'imagine qu'il y avait certains critères définis?

Et puis, juste une remarque gratuite, comme ça, en passant : ce qui serait gigantesque, c'est de réutiliser les concepts proposés et de travailler sur l'aspect graphique. Par exemple, j'adore le truc avec les barbelés, mais je trouve que l'image sous-exploite complètement l'idée. Le principe du libre, c'est pas que tout le monde participe sur un projet commun?

Le TLFI dit :

CHIOTTE,Fin de l'objet 1 de la requête (Mot vedette) subst. fém.
Trivial
A. 1. Au plur. Cabinets d'aisances. Aller aux chiottes; le trou des chiottes. La cabine téléphonique du bistrot, (...), si sale qu'on la prend toujours pour les chiottes (CÉLINE, Voyage au bout de la nuit, 1932, p. 297).
Au sing., rare. Ce trou d'homme qui s'éboulait en revêtissant le soldat d'un uniforme de boue où, à chaque relève, l'un ou l'autre restait enseveli comme dans une chiotte sans issue (CENDRARS, La Main coupée, 1946, p. 160).
Au fig., emploi exclamatif. [Exprimant le dépit ou l'irritation en présence d'une affaire désagréable] Quasi-synon. merde. Quelle chiotte! C'est la chiotte! C'était fini l'indépendance! Merde le silence! Chiotte la vadrouille! (CÉLINE, Mort à crédit, 1936, p. 320).
2. P. méton., au plur. Corvée de caserne, consistant à nettoyer les cabinets.

L'usage impose donc le pluriel quand il désigne les toilettes : "les chiottes sont bouchées". "La chiotte" n'est pas incorrecte, mais semble très rare.

Par contre, "une chiotte" est tout à fait correct quand on dit "quelle chiotte ce truc".

On en apprend des trucs...

c'est hyper simple de faire un feu de joie avec un peu de papier et du bois bien sec.

Je suis un gars des banlieues moi monsieur, alors les trucs à la Rahan... :-) Un barbecue, ça s'allume comme une voiture : un peu d'essence, une allumette, et !flash! ça grille. Faut partir en courant, évidemment.

Non, sans blagues, l'alcool faut le mettre avant de foutre le feu, évidemment, sinon tu vas te prendre un retour de flammes. Tu gagnes un temps fou, surtout si le charbon est un peu hunide, et en plus ca te met le feu uniformément sur toute la surface de barbecue.

C'est pas hors-sujet, ça va? :-)

Bah de toutes manières, cette taxe mal ficelée sent l'arnaque depuis le début : c'est comme si on te faisait payer la taxe sur les alcools sur l'alcool à brûler dont tu te sers pour allumer ton BBQ.

Je pense qu'il ne faut pas raisonner de manière individuelle (du style : "Je ne vais pas graver de musique sur ce CD, je ne dois pas payer la taxe"). Il s'agit d'une taxe globale, ciblée vers les gens qui tripotent du "numérique"; en cela, elle est certainement plus juste qu'un impôt supplémantaire sur la retraite de Papy René qui ne fait que regarder Derrick à la télé : si tu graves des trucs, c'est que tu as un ordinateur et tout le matos qui va avec, et qu'il est plus probable que tu fasses des trucs pas très nets avec tes CD. Ça n'a qu'un grossier caractère de probabilité, c'est bête et méchant mais c'est comme ça.

En bref, le fait qu'une entreprise qui grave des Debian ou qui sauvegarde le contenu de ses serveurs toutes les semaines ne puisse pas se faire dédommager, ce n'est pas vraiment une lacune : c'est dans la logique de la loi. Si on dédommage les boîtes, alors on devrait aussi dédommager les particuliers, et je ne vous raconte pas la paperasserie et les milliers de fonctionnaires nécessaires (remarquez, ça ferait baisser le chômage). Pensez à la sécu : vous payez même si vous n'êtes pas malade. Pensez à la retraite : vous cotisez même si vous avez un cancer généralisé à 25 ans. On paye des impôts pour réparer les routes quand on n'a pas de voiture, pour payer les radars automatiques quand on n'a pas le permis, pour couvrir le déficit du Crédit Lyonnais quand on est à la BNP. C'est de la mutualisation de l'impôt, qui apparaît injuste dans ce cas parce que 1) il n'est que partiellement mutualisé, sur un critère assez discutable, et que 2) le fondement même de cet impôt et la redevance versée en cadeau aux producteurs est très discutable.

La simplicité de la GPL (la remettre en cause demande de remettre en cause les principes fondamentaux du droit d'auteur internationnal) et son caractère équitable (pas d'injustice ou d'abus à redresser par le juge) en font une license excessivement solide dans tous les pays du monde, France comprise

Je ne peux pas t'empêcher de penser ça, mais je pense que tu as tort. Ces problèmes d'ailleurs ne sont pas propres à la GPL, mais sont partagés par plusieurs licences libres.

Exemple existant : un gusse vient recopier le contenu de son site Internet sur Wikipédia (c'est de la GFDL, mais c'est le même principe). Comme 99,99% des gens, il ne lit pas la GFDL. Quinze jours plus tard, le gusse s'aperçoit de sa connerie. Entre temps, sa prose a été modifiée, diffusée sur des centaines de sites miroirs, potentiellement distribuée sous forme de DVD ou d'édition papier, etc. Démontre-moi qu'un juge ne peut pas trouver les clauses illicites (cessation à vie des droits de diffusion à des inconnus) de la GFDL comme abusives. Il est évident que le mec ne va pas utiliser la clause de rétractation : ça lui coûterait trop cher. Par contre il peut dénoncer cette cessation irréversible de ses droits.

Exemple n°2 : un groupe de zique de quartier diffuse son premier album sous CC-BY-SA (philosophiquement proche de la GPL). Trois ans après, les mecs signent un contrat avec la SACEM, contrat qui impose que la totalité de l'oeuvre musicale soit gérée par la SACEM. Tu crois qu'un juge ne pourrait pas penser que cette CC et sa clause de non-rétractabilité sur le premier album ne nuit pas au détenteur de la propriété de l'oeuvre?

À cela,tu ajoutes l'histoire des vices cachés (ce qui rend la clause "aucune garantie..." caduque) et tu as un cocktail de failles de sécurité potentielles dans la GPL. Il y a des centaines de moyens d'attaquer une licence comme la GPL. La clause de "redistribution des sources" a été jugée solide dans une ou deux circonstances particulières, soit, mais j'ai du mal à comprendre d'où te viens cette confiance aveugle. Beaucoup s'accordent à dire par exemple que ce qui est lié ou non à une application, c'est quand même très flou. Beaucoup s'accordent à dire que l'utilisation d'applis GPL dans un contexte de service en réseau est une manière assez aisée de contourner la GPL, et qu'en tout cas, la GPL est basée sur des considérations hyper-techniques (liaison statique ou dynamique, threads ou pipes...), et rien ne te dit que tu puisses trouver un juge qui développe du kernel sur son temps libre pour apprécier que cette appli qui utilise un plugin/bibliothèque sous GPL via une interface en LGPL doit être distribuée sous GPL ou non.

Alors oui, la GPL a été écrite par des gens qui connaissent leur boulot. Oui jusqu'ici ses clauses fondammentales ont résisté aux attaques de boîtes de mauvaise foi mal conseillées juridiquement. Mais non, le droit international est trop complexe et les nuances trop subtiles pour pouvoir affirmer que la GPL est valide éternellement et partout. Et non, la GPL n'a jamais subi une vraie épreuve du feu, dirigée par des avocats spécialisés dans les droits numériques, sur des problèmes subtils liés au concept de "redistribution" ou de "liaison à un logiciel sous GPL". Et non, la GPL n'a jamais été attaquée hors des USA sur des points qui sont justement différents en Europe et dans le reste du monde. Jusqu'ici tout va bien, et c'est tant mieux.

Je te souhaite une longue et prospère vie, mais tu n'as jamais entendu parler de trucs comme les accidents de voiture ou les morsures par des chauves-souris enragées? Qui va accepter de changer la licence des softs si une faille est détectée dans la GPL2? Tes ayant-droits? Je comprends ton point de vue, mais je pense que c'est quand même beaucoup plus compliqué que ça.

D'un autre côté, tu prends un logiciel libre, tu remplaces le texte du menu "Enregistrer sous" par "Les XXX sont tous des YYY" (remplacez XXX par Juifs, Musulmans, Énarques, Femmes, Homosexuels etc. au choix, et YYY par porcs, nains qui mangent leurs excréments, etc.), tu n'as plus le droit de le diffuser, donc il n'est pas libre ?

La liberté de diffusion sous-entend le fait que les modifs que tu as faites sont licites. Donc tel que tu le poses, je ne vois pas vraiment le problème.

Oui mais attention : si ce n'est pas le cas du noyau, de très nombreux programmes sont diffusés sous "GPL 2 ou version supérieure, à votre choix", c'est à dire au choix de l'utilisateur. J'ai toujours trouvé problématique cette question impossible à trancher : si on release en GPL2 strict, on expose de futurs utilisateurs et développeurs à des attaques ciblées si des failles dans la GPL2 sont démontrées. Si on choisit la GPL2 ou supérieure, on s'expose à des boulettes de la FSF dans les versions postérieures. Par exemple si tu as un brevet sur ton code, tu releases en GPL2>, quelqu'un reprend ton code et le diffuse en GPL3, que devient ton brevet?

Par ailleurs, il me semble important de discuter de la GPL3 qui est le futur du logiciel libre. Apparemment, pour la FSF, il est hors de question de forker la GPL à la manière des CC, donc autant avoir un consensus autour d'une GPL 3.

Bon, d'un autre côté, les graphismes non libres semblent 1) très marginaux, et 2) très temporaires. C'est plus une erreur de jeunesse qu'autre chose...

C'est amusant de voir ce troll littéraire resurgir de temps en temps, alors que l'Académie (pourtant traditionnelle par nature) considère depuis un sacré bout de temps que les formes "respectant" de pluriel de la langue d'origine doivent être considérées comme pédantes.

Le problème, c'est que la plupart du temps, les formes latinisées ne sont pas des latinismes, mais bien malheureusement des anglicismes, puisque la conservation du pluriel d'origine est très courante en anglais.

En Français du XXIe siècle, on dit donc des scénarios (avec un accent), des aquariums, des saunas, des ferrys (des lobbys, etc.), des locus, des maximums (optimums, forums...). Sauf si on est pédant :-)

Ce qui est certain, c'est que la GPL sera probablement invalidée (ou tout du moins une certaine partie de ses clauses) en France si le plaignant est l'un des auteurs du soft. Deux raisons:
* Le Code de la propriété intellectuelle prévoit une clause de rétractation, même après publication (sous réserve de dédommagement, mais je ne sais pas comment ça pourrait se faire : le dev qui souhaite rétracter ses contributions devrait payer quelque chose au projet? Aux utilisateurs?)
* La jurisprudence condamne clairement les contrat de cessation des droits dont la durée est abusive. Et là, "à vie", ça me paraît clairement abusif.

Donc la GPL est probablement minée en France si un particulier (ou plus embêtant, une entreprise) a contribué à un soft sous GPL et regrette sa contribution plus tard. C'est plutôt embêtant.

Par contre, je n'ai jamais entendu parler de failles potentielles de la GPL si le plaignant est un simple réutilisateur et/ou distributeur du code. Des infos là dessus?

C'est vrai, ces projets sont "semi-libres" : la licence des logiciels est libre, mais l'accueil de la communauté n'est pas à la hauteur de ce qu'on est en droit d'attendre pour un projet libre. Mais au lieu de hurler sur les comportement des uns et des autres, pourquoi ne pas s'"extasier" (bon, OK, c'est un peu fort) sur la puissance des licences libres et des possibilités qui sont offertes aux utilisateurs? On est typiquement dans le cas où le comportement du dev déplait aux utilisateurs (que son comportement soit justifié ou non, c'est une autre histoire). Même "semi libre", même avec des marques déposées assez contraignantes, un fork est possible, et rien n'est perdu, à part du temps et des méga-octets de trolls.

La compétition est aussi ce qui fait avancer le libre. Si Nvu déconne, si sa redistribution n'est pas facile, si le soft est buggé et ne bouge plus, alors les distributions vont commencer à intégrer le fork, à reporter les bugs à la version forkée, des dev indépendants vont se sentir mieux accueillis et vont proposer des améliorations, et le fork va se développer plus vite, mieux, autour d'une communauté mieux structurée. Si au contraire Nvu 2.0 déchire des mamans ours lors de sa sortie, KompoZer va progressivement tomber dans l'oubli. Si les deux projets sont de bonne qualité et complémentaires, alors on aura le choix d'installer l'un ou l'autre selon ses gouts ou l'utilisation qu'on compte en faire.

Au final, le gagnant est définitivement l'utilisateur. La compétition entre projets libres, même hostile, reste néanmoins extrêmement stimulante en termes de qualité et de développement d'une image forte (killer features, améliorations de l'ergonomie, de l'aide etc). Donc c'est peut-être dommage de dupliquer les efforts, mais c'est aussi comme ça que le libre avance.

Les langages de programmation (enfin les "vieux") ont été conçus à une époque où on n'avait pas de recul sur les gestions de versions, sur les éditeurs de texte, sur la diversité des conventions, etc. Ils trainent donc des erreurs du passé, et le mélange fond/forme dans un fichier source, c'est AMHA une erreur de conception profonde du langage. Les sauts de ligne faisant partie de la forme (et malheureusement parfois du fond), ils sont traînés comme des boulets depuis 20 ans.

Error: helloworld.c:1 : c'est évidemment un bug du compilateur. Ça serait beaucoup plus logique qu'il indique le caractère dans le fichier qui pose problème, et pas la ligne.

Ce que je veux dire, c'est que le système a une inertie terrible : 1) les langages de programmation existants prennent parfois en compte des informations de mise en page du code, 2) les éditeurs savent très mal travailler l'indentation d'un fichier, 3) les programmeurs sont probablement encore plus intertes que le reste de l'humanité, et faire changer ses habitudes à un programmeur, ca doit être au moins aussi stimulant intellectuellement que de faire rentrer des notions de politique internationale dans la tête de G. W. Bush. La conclusion de ça, c'est que dans 30 ans, les fichiers seront encore indentés à la main ou très mal indentés par un éditeur, les languages (comme C++++) prendront toujours en compte des informations de fond pour fabriquer du sens, il faudra toujours un bac +30 pour faire fonctionner les autotools (dont la version 37.8 sera bien entendu incompatible avec la 37.7, elle même incompatible avec la 37.6).

Mais ça me rend juste triste de voir qu'il faut implémenter des workarounds sales dans les svn en 2006 parce qu'il est rigoureusement impossible de comprendre qu'un gusse a remplacé une tab par 8 espaces. Ça me rend aussi triste de voir que des projets comme Gnome ou KDE (et probablement des centaines d'autres) continuent à se prendre la tronche et donc à perdre un temps fou sur la définition de normes pour l'indentation, alors qu'encore une fois ça serait tellement simple si ça pouvait être géré par l'éditeur de chacun, en fonction des préférences de chacun, mais seulement à l'affichage, puisque c'est bien de ça qu'il s'agit, et pas dans le fichier source lui-même. Tout ça parce qu'on traine les erreurs du passé, comme un boulet au pied auquel on est tellement habitué que ça nous ferait presque mal de nous en débarrasser.

Bon, j'y ai peut-être été un peu fort sur les sauts de ligne, mais je reste quand même persuadé que le saut de ligne est un caractère "forme" et pas "fond", tout comme l'espace et la tabulation.

Utiliser un éditeur de texte qui ne sait pas lire le code, par exemple Word, pour lire un fichier C, ne rendrait pas le truc illisible :

int main(int argc,char** argv){printf("Hello Word!\n");}

reste quelque chose de "compréhensible" (bon, c'est sûr, si le fichier fait 200ko, ça va être moins lisible...). Mais ça reste du texte, et ça ne compromet en rien la lecture, la modification, la recherche de chaines de caractères etc. Mais la mise en page est neutre, et c'est à l'éditeur de texte, si l'utilisateur le veut, de remettre ça en page pour faciliter la lecture et l'édition. Donc je persiste à dire par exemple qu'en C, le saut de ligne est un caractère de mise en forme, il n'a aucun sens (autre que celui de séparateur, et malheureusement, de fin de commentaire pour les // du C++). Au passage, cette "suppression de tous les caractères inutiles avant publication" est courante pour le HTML, je ne vois pas pourquoi ça ne pourrait pas se faire pour les autres languages.

L'informatique n'échappe pas à la tendance naturelle à l'immobilisme : si un gars s'est fait chier 20 ans avec les Makefile merdiques, il va voir d'un mauvais oeil l'apparition d'une nouvelle syntaxe qui va tout révolutionner.

L'indentation et l'alignement dans les fichiers source sont une hérésie qui persiste encore de nos jours pour des raisons historiques. Ça aurait toujours dû être le boulot de l'éditeur de rajouter les espaces et les sauts de ligne là où il faut, le fichier source devant contenir le code à la queue leu leu pour 1) gagner de la place et 2) forcer l'utilisateur à utiliser un éditeur qui sache gérer le code :-)

Évidemment, la tâche n'est pas simplifiée par les langages à la con qui accordent un sens à des caractères invisibles (ou pire: à la répétition de caractères invisibles, comme les doubles sauts de ligne en Latex). Je pense qu'on devrait retrouver les types qui ont mis au point ces langages, leur couper les couilles, les faire frire et leur faire bouffer.

Sans déconner, est-ce que vous pourriez estimer la perte de productivité de l'humanité toute entière due aux milliards d'heures perdues par des devs à réaligner du code, à discuter sans fin de conventions de codage ou à débogguer un Makefile dans lequel un esprit de l'axe du Mal(TM) a remplacé une tab par des espaces?

<mode stroumph grognon> Moi j'aime pas les formats binaires </mode stroumph grognon>

Il faut que tu m'expliques en quoi ton format binaire 'achement vien foutu est tellement supérieur à XML qu'il peut se permettre d'imposer à l'utilisateur d'installer un soft pour le lire.

Parce que pour moi, la possibilité de se priver de

vi ~/.toto
:%s/blue/red/g
:wq

a un coût gigantesque.

Et XML, c'est, je paraphrase, C'est un format binaire texte pour lequel de nombreuses bibliothèques sont disponibles pour le rendre lisible et qui a l'avantage d'avoir une grammaire extensible et normalisée.

Ma (faible, je l'accorde) expérience m'incite à penser que la seule raison valable pour abandonner un format XML bien foutu, c'est quand les fichiers deviennent trop gros et que les accès sont trés fréquents, auquel cas il faut se tourner vers une structure de type base de données. Mais passer d'XML à un format binaire, ça me semble être un retour à la préhistoire. Même si je sais que mon opinion n'est pas vraiment partagée, je pense qu'un des avantages du gain de performances des machines, c'est aussi qu'on peut se passer de micro-optimisations désastreuses pour l'ergonomie et le développement.

Il faut comparer ce qui est comparable. Comparer XML avec quoi exactement? Quel autre format souple permet de stocker des données hiérarchiquement, de rendre ces fichiers lisibles à l'aide de tout un tas de front-ends sur tout un tas de plateformes, de rendre les fichiers de conf insensibles à ces p...tain d'aberrations syntaxiques (espaces vs TAB, espace avant le = ou non), de pouvoir utiliser des bibliothèques externes disponibles pour tous les langages au lieu de recoder un parseur à chaque fois, de gérer différents encodages, etc?

Parfois, il est préférable de perdre en performances à des fins d'interopérabilité, et je pense que c'est clairement le cas des fichiers de conf.

Au fait, je me réponds à moi même, mais ce qui serait cool, c'est juste un petit apt-get install album_Truc_Bidule . J'ai perdu l'habitude d'aller télécharger moi-même des trucs sur le web, c'est dégradant :-)

Je dois vivre dans la préhistoire, ou je deviens vieux et fuis la nouveauté, mais c'est quoi l'intérêt de ce postcast-truc-machin à la place de bons vieux liens en dur? Quand je clique dessus, Firefox m'ouvre un beau fichier xml. Il faut que j'enregistre le .xml et que je l'ouvre dans un autre logiciel, qui va aller me télécharger mes fichiers? On n'arrête pas le progrès :-)