David Anderson a écrit 75 commentaires

Subversion implémente xdelta, un algorithme de diff binaire très efficace. C'est l'une des grosses différences par rapport à CVS : Ce dernier stocke le "fulltext" (fichier complet) de toute révision d'un fichier binaire, alors que Subversion fait aussi des diffs dessus.

Bon après, si le binaire en question est un .zip (par exemple), c'est sur que la modif d'une ligne d'un fichier dans le zip produit un delta ridiculement gros, mais ca c'est un problème du à la nature du fichier, et on y peut pas grand chose (sauf pour gzip, ou nous proposons l'intégration générale d'un patch disponible dans debian, qui permet de produire des .gz "rsyncable", tentant de minimiser les changements de la signature binaire du fichier compressé).

Il y a eu quelques articles de ci de là sur l'utilisation "de base" de Subversion, mais il n'existe à l'heure actuelle aucune documentation en francais traduite.

Le Subversion Book (http://www.svnbook.org/ ), édité en papier par O'Reilly, a été mis en ligne par les auteurs sous une licence Creative Commons libre. Il serait donc possible qu'une équipe de gens motivés en fasse la traduction. Ca s'est déjà fait dans d'autres langues, il faut juste que des gens motivés le fassent :-).

Ah, et des contributions à la l10n française de Subversion sont les bienvenues aussi. Il y a une équipe qui bosse dessus, mais les coups de main sont toujours les bienvenus!

Cela fonctionne effectivement dans le cas d'un dépot FSFS, mais tu notes que cela ne permet de défaire que la toute dernière révision. Si entretemps la moindre petite chose à été committée, il faut redeltifier tout ce qui suit la révision supprimée, ce qui n'est pas possible dans l'API actuelle de Subversion (cf mon commentaire au dessus).

Donc oui, un workaround partiel, mais cela ne résout pas tous les problèmes qu'obliterate est censé résoudre.

En réponse à la question de gael75 sur obliterate, j'ai fait un peu de recherche pour me mettre à jour sur "oùsque ca en est".

Déjà, un peu de fond sur le problème: Subversion a été conçu avec comme principe premier la protection des données à tout prix. Cela se répercute directement dans l'API, et en particulier dans celle qui implémente le "Système de fichiers versionné", le coeur de Subversion.

En effet, si on consulte cette API, on se rend compte qu'elle ne permet pas du tout d'ouvrir et altérer des données qui ont déjà été commitées. Le seul moyen d'éditer un fichier, c'est démarrer un nouveau commit avant d'éditer, auquel cas toutes les modifications se font dans la transaction en préparation, qui est le seul endroit dans Subversion ou les données sont altérables. Donc, au niveau de toute la conception de Subversion, tout ce qui a été committé un jour est par définition immutable.

Ce qui pose un problème très épineux pour obliterate. Là, on nous demande de programmer une commande qui viole quasiment tous les principes de conception de subversion : Il faut altérer des révisions passées (censées être immutables), voire même modifier toute une ligne d'historique pour faire disparaitre un fichier et l'ensemble de ses modifications. Non-seulement nous sommes réticents à le faire sur le principe (c'est mal de donner aux gens de quoi se tirer une balle dans le pied), mais en plus nous serons obligés de contourner notre API pour le faire, parce qu'elle refusera catégoriquement de toucher à ce qui est immutable.

Ensuite, en ce qui concerne la solution que tu proposes (remplacer le fichier par un fichier vide), elle a été réfléchie, en effet. Mais l'inquiétude réside dans le fait que nous avons deux volontés différentes pour la fonction de cette commande : certains veulent simplement une commande "anti-disque-plein", qui serait adéquatement implémentée par le remplacement par le vide. Mais d'autres (et la très légère majorité je crois) veulent que l'effacement soit "juridiquement correct", c'est à dire qu'il n'y aie aucune trace de l'existence même du fichier. Dans ce cas là, il y a besoin de faire un effacement, un vrai.

Il y a aussi des volontés différentes par rapport à ce que obliterate devrait effectivement détruire : une révision? Un fichier et toute son histoire? Une seule révision d'un certain fichier? Le consensus semble être d'implémenter la suppression d'une révision précise d'un fichier précis, puisque toute autre opération peut se construire par dessus. Mais cela pose d'autres problèmes: s'il y a un historique après la révision, il faudrait re-deltifier le dépot, pour conserver son intégrité. Faut-il re-deltifier en effaçant l'existence du morceau supprimé (cas effacement juridique), ou re-deltifier en fusionnant le morceau effacé avec des révisions futures (Le cas "effacement pour gagner de l'espace disque) ?

Problème épineux donc, au niveau de sa conception de haut niveau (que doit effectivement faire 'svnadmin obliterate' ?), au niveau de l'acceptation (pas mal de développeurs ne sont pas favorables au principe ministère-de-la-Vérité d'obliterate. Cela n'empêchera pas son développement, mais réduit le nombre de développeurs prêts à bosser dessus). Mais de loin le plus gros problème que nous aurons à résoudre, c'est qu'en l'état actuel, notre API ne nous permet matériellement pas d'implémenter obliterate, et que nous ne voulons pas rendre disponible dans l'API publique un svn_fs_obliterate() aux conséquences on ne peut plus irréversibles.

Bref, nous n'avons pas oublié la doléance : c'est le bug #516 de Subversion, un vétéran, et il nous concerne toujours. Mais nous travaillons sur des choses plus importantes à nos yeux (récemment, et en vue de svn 1.4 : un nouveau système de stockage de deltas, avec un gain d'espace disque coté serveur avoisinant les 20%, et de nombreuses optimisations de la vitesse de traitement dans la bibliothèque de gestion de copie de travail), et n'avons simplement actuellement pas de temps alloué à ce problème.

Bien sur, si quelqu'un est motivé, les contributeurs sont les bienvenus! ;-)

Euh, mon intention même. Oups.

Oui, je sais que je ne suis pas le seul, et j'espère que mon commentaire ne donnait pas l'impression que je me la pétais genre "Je suis le seul warrior qui a survécu!" Ce n'était pas du tout mon attention.

Je voulais par là répondre à une inquiétude assez répandue du temps du Summer of Code : que la grosse carotte financière n'attirerait que des mercenaires, et n'apporterait au final pas grand chose de durable au libre (c'était souvent suivi par un laïus sur pourquoi il aurait fallu ouvrir le SoC aux non-étudiants aussi, ce que je trouvais d'assez mauvaise foi pour être franc).

Bref, voila. Et sinon, Looking Glass, ca avance? :-)

Je rajoute mon petit^Wtrès gros grain de sel à la discussion sur Subversion.

Le gros du problème entre Subversion et BDB est blocage de la base BDB en cas d'arrêt violent du traitement d'une requête par le serveur svn. Cela arrive relativement souvent quand on utilise mod_dav_svn, ou toute interface web maniant le dépôt et pouvant être interrompue violemment. Le problème, c'est que le dévérouillage (et l'éventuelle réparation) ne peut pas se faire automatiquement par l'application cliente (Subversion) sans risques de corruption, sauf si on peut lui garantir un accès exclusif à la base pendant la réparation. Donc, le dépot reste vérouillé jusqu'a ce qu'un d'admin coupe tous les moyens d'accès au dépot et exécute `svnadmin recover` dessus (qui lui par dessous dit à BDB qu'il peut réparer tranquillement).

Cette situation a été discutée avec SleepyCat Software. Ils ont demandé aux développeurs de Subversion ce qu'ils aimeraient avoir dans les prochaines versions de BDB, et la réponse fut massive: "Database auto-recovery", c'est à dire le dévérouillage et la réparation automatique et sans risques dans un environnement où l'accès est non-exclusif (lire: en prod).

Et c'est chose faite. Comme l'indique la liste des nouvelles fonctionalités ci-dessus, BDB 4.4 ferme plusieurs tickets internes traitant de cette réparation automatique en-ligne. Avec BDB 4.4, Subversion n'aura plus qu'a ouvrir le dépot normalement, et la bibliothèque BDB effectuera automatiquement l'équivalent de `svnadmin recover` avant d'ouvrir la base. BDB revient donc à égalité à FSFS (l'autre système de stockage de dépot de Subversion) : dans les deux, une mort violente de Subversion n'entraine que quelques fichiers de verrou et de journal qui trainent dans le dépot, et qui seront nettoyés à l'ouverture suivante de celui-ci.

BDB 4.4 venant de sortir, il faudra patienter au moins jusqu'a Subversion 1.4 (la 1.3 est en Release Candidate en ce moment) pour avoir le support BDB 4.4. Et pour répondre à la question d'origine, il faudra sans doute faire un dump/load pour mettre à jour un dépot Subversion BDB, lorsque le support BDB 4.4 apparaitra. Le changement dans la structure interne de BDB est qualitativement similaire à celui qui a eu lieu entre BDB 4.2 et BDB 4.3 .

Enfin, une petite note par rapport au commentaire précédent, qui dit en substance que Subversion va "plus vite" avec un dépot FSFS. Ce n'est pas entièrement vrai. Les données sont stockées très différemment dans un dépot FSFS par rapport à un dépot BDB, et ces différences font que parfois c'est l'un qui est meilleur, et parfois c'est l'autre.

Par exemple, BDB stocke la dernière version entièrement, et exprime les révisions précédentes sous forme de delta, alors que FSFS stocke une révision N en entier et exprime les révisions suivantes sous forme de delta ; un checkout de la dernière version avec BDB sera donc très rapide, alors que FSFS aura besoin de temps et de ressources pour recombiner les deltas à partir de la dernière révision complète.

De même, FSFS est beaucoup plus rapide pendant la construction d'une transaction à commiter dans le dépôt, mais la finalisation (étape ultime du commit ou le serveur construit le fichier de révision et l'insère dans le dépot) prend un temps proportionnel au volume de modifications propagées. Il est donc possible avec FSFS qu'un très gros commit (plusieurs centaines de Mo de diffs) fasse timeouter le client pendant la phase de finalisation. BDB au contraire étale l'impact d'un gros commit sur toutes les phases, autant la construction de la transaction que sa finalisation, et ne souffrira donc pas de ces problèmes.
(Le dernier exemple avec des diffs de plusieurs centaines de Mo peut sembler tirée par les cheveux, mais c'est tiré d'histoires vraies - certaines entreprises gardent des Go d'isos de DVD dans Subversion; les commits de centaines de Mo ne sont pas exceptionnels, quand l'iso est modifiée)

Tout ça pour dire que les deux backends ont leurs avantages et leurs inconvénients respectifs. Il est vrai que BDB, avec son problème de verrous, a une mauvaise image auprès des utilisateurs. Mais s'il est encore distribué avec Subversion, c'est bien parce qu'il peut etre meilleur que FSFS dans certains cas - et l'ajout de réparation automatique ne fera que le rendre plus attractif à mon humble avis. Je vous recommande vivement la lecture du Subversion Book, sur http://www.svnbook.org/ . Le début du chapitre 5 compare les deux solutions, et discute des avantages et inconvénients respectifs.

Voila voila, fin de la réponse de barbare. Bravo si vous lisez encore :-)

Si tu persistes, tu t'expatrieras vers un pays ou tu n'es pas vu comme une charge et un fardeau. Vers un pays ou les gens au pouvoir ont la compréhension des choses sur lesquelles portent leur législation.

Vivement qu'un tel pays se mette à exister... :-(

Monde de merde.

... Une chanson de Didier Super (oui, je sais, niveau référence culturelle ça vole bas, m'enfin), intitulée On va tous Crever:

...
Et puis ya les martiens qui vont nous j'ter des boules de feu,
Exprès pour que ca nous bruuuleuh!
Et puis ya le lapin géant bouffeur de planètes,
Il bouffe des planètes alors que YA DES GENS DESSUS!!
...

C'est a ranger avec le passage du coté obscur donc: les martiens et leurs boules de feu, et le lapin géant bouffeur de planètes ;-)

Déconnade à part, je suis on ne peut plus de ton avis. Je trouve ce genre de surclassification assez énervante, que ce soit d'un coté ou de l'autre d'ailleurs (les partisans du oui ont eu le droit aux mêmes généralisations de la part de certains supporters du non).

La mailing list répond à beaucoup de ces interrogations. Voici un condensé de ce qu'il faut pour passer en mode moniteur et faire comprendre à Kismet comment obtenir du paquet:

- Bien vérifier qu'on a désinstallé toute trace de l'ancien pilote
- Télécharger le nouveau firmware, remplacer l'ancien et relancer hotplug pour générer un nouvel événement hotplug (pour envoyer le nouveau firmware)
- Compiler et installer les nouveaux pilotes
- Couper l'interface réseau `ifconfig eth1 down`
- S'assurer qu'il n'y a rien qui pourait essayer de controller la carte (client dhcp, outils de config automatiques du type wpa_supplicant...)
- Changer de mode `iwconfig eth1 mode monitor`
- Activer la carte réseau `ifconfig eth1 up` (sinon le noyau ne recoit pas les paquets passés par le driver)

A ce stade, la carte est en mode moniteur et le noyau reçoit tous les paquets qu'elle capture. Ensuite, il faut configurer son logiciel d'analyse pour qu'il sache selon quel protocole lire les paquets. Pour ceux qui (comme moi) avaient loupé l'épisode ou c'était expliqué, le mode moniteur est implémenté "comme ca nous arrange, nous les programmeurs du firmware", donc les façons de lire les paquets capturés ainsi (qui contournent beaucoup du code normal de lecture) varient pas mal, et donc les progs d'analyse ont plusieurs modes de lecture de paquets.

Pour la configuration des logiciels, cherchez sur le net tout ce qui concerne le mode moniteur pour ipw2100; les pilotes sont développés en tandem, mais ca fait plus longtemps que le moniteur est disponible pour ipw2100 (il ne l'était pas sur 2200 pour questions légales concernant le firmware), donc les logiciels se sont déjà adaptés.

Sur la mailing list, la seule configuration qui aie été donnée est pour Kismet: dans le fichier de config de Kismet, il suffirait d'indiquer 'source=ipw2100,ethX,ipw2200'. Il faut une version relativement récente de Kismet par contre. Des rumeurs courent comme quoi 'source=orinoco,eth1,ipw2200' marcherait aussi.

Bref, dans l'ordre, essayer la capture de type ipw2200 (peu probable), ipw2100, orinoco, et en dernier recours, n'importe quoi au pif jusqu'a ce que ca marche ;-)

Voila voila. Abonnez vous a la mailing list, il y circule souvent des infos sympa. En plus, maintenant que la carte supporte le mode moniteur, son pire troll est mort ("Et pourquoi on peut pas passer en moniteur? [...] Et c'est quand que ces feignasses de développeurs vont laisser tomber le WPA dont tout le monde se branle pour qu'on puisse airsnorter?"). On pourra peut-etre même avoir des conversations normales maintenant :-)

Simplement une petite intervention pour nuancer un peu la question de la participation massive. Nous sommes actuellement 8 à travailler sur la version linux. Et quand je dis 8, c'est 4 qui peuvent bosser et 4 qui attendent qu'on atteigne sur le moteur de jeu un stade ou on peut subdiviser le travail. Alors perso je ne vais pas refuser l'aide qui se propose, mais il faut voir qu'on ne peut pas bosser à 15 sur le portage des 3 mêmes lignes de code. Déjà là, à 8, je pense qu'on aura plus ou moins couvert tout ce qui concerne le moteur de jeu. Reste encore à porter quelques outils annexes (convertisseur/compilateur de maps, programme qui vérifie les versions/mods des joueurs d'une partie...), mais je ne pense honnêtement pas que nous en soyons à un stade de recrutage massif.

De plus, l'équipe des développeurs de Clan SY a expressément demandé d'essayer d'éviter une "explosion" de la communauté avant qu'une prochaine version plus stable et complète ne voie le jour. C'est pour quelques raisons assez simple: éviter que des gens viennent en s'attendant à un produit fini, soient déçus par l'instabilité ou par l'impression de "pas fini" et s'en aillent pour ne plus revenir; ensuite, au niveau développement, il n'y a pour l'instant qu'assez peu de gestion de projet. Avec la mise en place (toute récente) du projet sur SourceForge, on peut espérer que cela ira en s'améliorant. Il suffit de voir ce qui s'est passé quand j'ai proposé de porter le code et que l'équipe de portage s'est formée. À essayer de discuter de modifications profondes par phpbb interposé, ca virait de plus en plus à l'anarchie.

Donc pour ma part, je suis plutot satisfait que l'annonce ne soit pas passée en première page. Ca évitera un deuxième effet slashdot (ils sont passé sur la page jeux de la maison mère il y a quelques semaines), ca évitera que la communauté en cours de formation ne fasse imploser le projet à ce moment assez critique de son évolution, et ca évitera qu'on se retrouve a 42 sur le port alors qu'il y a pour l'instant de quoi faire pour une dizaine ;-)

Oups, ca m'apprendra à ne pas vérifier les liens que je mets avant de poster le commentaire! Le projet openrts sur sourceforge est un projet mort. Celui dont je parlais, le collègue qui développe un moteur de RTS libre et qui nous donne un coup de main, c'est http://orts.sf.net(...) .

Le problème avec SDL, c'est un peu justement que tout est intégré. À utiliser uniquement une partie, on le sous-utiliserait. À tout utiliser, on devrait pas mal chambouler le code pour s'adapter à la façon de faire les choses qu'a SDL. Or, dans notre cas, on s'en servirait pour initialiser une surface vidéo et la refiler à OpenGL et gérer les entrées (clavier/souris/joystick), ce qu'OpenGlut, la continuation ouverte de Glut, fait tout aussi bien sans avoir à intégrer tout une infrastructure dans notre code.

Donc non, à priori l'utilisation de SDL ne simplifierait rien du tout, puisqu'il faudrait non-seulement toujours réecrire les sous-systèmes non-portables, mais en plus altérer l'architecture de la partie déjà indépendante de la plateforme pour y intégrer SDL.

Pour ma part, si on me sort un ultime avantage qu'a l'architecture SDL sur tout ce qu'on compte utiliser, pourquoi pas; mais je pense que l'acceptation du port auprès des développeurs originels sera d'autant plus facile si on ne se met pas à réecrire les morceaux qui marchent déjà parce que soi-disant on sait mieux qu'eux quoi faire. Terminons déjà un premier port qui n'impacte que le strict nécéssaire dans le code. Ensuite, on verra pour ce qui est de les faire utiliser toutes les bibliothèques libres à la mode ;-)

Peut-être le billet sur mon blog était-il un peu exagéré. En technologies non-portables, il n'y a pas tant de choses que ca. Ca ne va pas etre simple, mais ce n'est pas impossible comme s'ils avaient tout codé en Direct3d.

- La 3D utilise OpenGL, avec des routines Win32 pour l'ouverture de fenêtre. En remplaçant ces dernières par du code OpenGlut, le moteur graphique ne devrait pas avoir besoin d'autres modifications.
- Le son utilise DirectSound, qui sera remplacé par OpenAL.
- Le réseau utilise du winsock, qui sera "remplacé" dans un premier temps par du code sockets BSD avec les quelques appels en plus nécéssaires à winsock entourés de #ifdefs. Il semblerait qu'une discussion sur un changement radical d'architecture réseau est en cours dans la communauté, donc en attendant d'y voir plus clair, le moins de boulot on fournira la dessus, mieux ca sera.
- La gestion des entrées est faite avec du code Win32, qu'OpenGlut remplacera sans problème.
- L'accès aux ressources de jeu se fait via une bibliothèque de lecture de fichiers HPI, un format spécifique à Total Annihilation qui a été décortiqué par les moddeurs. Un collègue (travaillant sur http://openrts.sf.net(...) ) nous a proposé d'utiliser sa réimplémentation portable du lecteur de fichiers HPI. Là aussi, sur le long terme, un basculement vers un autre format (zip et 7zip sont à l'étude) pourrait nous faciliter la tâche.

Il y a sans doute d'autres parties à problème, je n'ai évoqué que les principales parties qu'on a actuellement isolé dans le boulot préliminaire (reussir, en excluant tous les morceaux pas portables à coup de #ifdef NO_SUBSYSTEM, à faire compiler plus ou moins le reste).

Bref, tout cà pour dire que oui, il y a du travail, mais étant donné l'architecture du moteur, il y a de bonnes chances que ce qu'il faut modifier sera confiné dans quelques fichiers/classes, ou que du moins il n'y aura pas besoin de réecrire un tiers du moteur pour que ca marche. J'ai donc bon espoir qu'on pourra réintégrer nos modifs de "portabilisation" dans l'arbre de sources principal et ne pas scinder en deux une communauté émergente.

Hein quoi, on m'apelle?

Hereusement, après mon annonce que je m'attaquais au port, plein de monde a rejoint la joyeuse aventure. On doit maintenant être à 8, et les choses avancent de bon train. Encore heureux d'ailleurs, je suis pris jusqu'a fin mai avec un autre projet, pour lequel je dois rendre un rapport et faire une soutenance, alors ca me fait plaisir qu'il y aie du monde pour que le port continue pendant mon absence temporaire :)

Pour résumer:
- le serveur (un peu l'équivalent d'un serveur battle.net, il fait uniquement la mise en relation des joueurs) compile et tourne presque
- le client était écrit en C# et est entrain d'être réecrit en C++/WxGlade.
- le moteur du jeu en lui-même est entrain d'être tailladé pour compiler sous linux en excluant la compilation de tous les sous-systèmes problématiques, ce qui devrait être fini dans la semaine. Une fois cela fait, on se distribuera les sous-systèmes pour les rendre portables (OpenGL/Win32 vers OpenGL/OpenGlut, DirectSound vers OpenAL...).

Bref, on est pas arrivés, mais au moins on est partis :)

Le wiki causant du port: https://opensvn.csie.org/traccgi/taspring_linux/(...) (liens vers le dépot subversion dessus). Une mailing list sera bientot crée sur sourceforge par les administrateurs SF du projet.

Enfin, pour ceux qui parlent de fork, essayez de vous retenir: Clan SY (les développeurs de TA Spring) ont longtemps hésité avant de mettre le code source sous licence GPL. Une de leur plus grosse inquiétude était l'apparition d'une multitude de forks et la dilution de communauté qui s'en suivrait. Pour ma part, lorsque j'ai annoncé ma volonté de porter le jeu, je comptais bien leur rendre toutes les modifications pour intégration dans le projet officiel, et non lancer un quelconque "TA Pingouin" qui serait encore forké quatre fois au moins. Si on pouvait garder la communauté autour du jeu (qui grossit à vue d'oeil) intacte, ca serait vraiment bien.

Après, si cela va être possible étant donné l'ampleur des modifications qu'on devra apporter... Je ne sais pas, mais ca vaut le coup d'essayer!

En parcourant le site de Joël Spolsky, je suis tombé sur une véritable mine d'or d'articles sur une grande variété de sujets touchant à l'ingénerie logicielle:

http://www.joelonsoftware.com/navLinks/fog0000000247.html(...)

Entre autres, il met à disposition en ligne une version condensée d'un livre qu'il a écrit sur la conception d'interfaces utilisateur (premiers liens des archives), ou il expose des problèmes classiques d'ergonomie d'interface et donne des solutions.

Entre autres et de tête, on y retrouve le principe "Si c'est un bouton, ca doit ressembler à un bouton" évoqué par Robin des Bulles, l'histoire de la "mile high bar" d'Apple et de l'application ratée qu'en a fait Microsoft dans windows 95. L'auteur travaille beaucoup à partir d'exemples de ses expériences professionelles, et je trouve que ca rend la lecture beaucoup plus agréable qu'une liste de concepts abstraits.

Je ne sais pas si c'est exactement ce que tu cherches, mais en tout cas il y a de bonnes indications générales sur la conception d'interfaces qui ne donnent pas des furoncles aux gens qui essayent de s'en servir, c'est un bon départ ;)

Et pour les autres, tous les articles de Joël sont un vrai plaisir à parcourir, autant du point de vue du style littéraire que du contenu d'information. Je vous les recommande vivement!

- David

Ah ben zut, j'avais pas vu ce fil de commentaires intéressant en bas des conneries :)

J'ai contacté l'auteur pour obtenir l'autorisation de traduire et publier l'article, et je suis entrain de le faire à la suite d'une réponse positive de sa part.

Je suis déjà bien avancé (fin de page 2), mais des relecteurs (tant pour l'orthographe que pour le style, je rouille un peu en version) sont les bienvenus :)

Histoire de te rassurer, certains (dont moi) ont été fortement interessés par ce journal.

D'ailleurs, en réaction à ton "Je pense que cette article mériterait une traduction", j'ai contacté l'auteur pour lui demander la permission de traduire son oeuvre (étant bilingue). J'ai reçu une réponse positive ce matin, et j'y travaille depuis.

Là ou je rejoins ton opinion, c'est que je n'ai pas posté de commentaire à ton journal, parce qu'au vu des débilités de maternelle qui précédaient, j'ai estimé que mon post passerai soit inapperçu, soit serait pourri par les amibes monocellulaires qui hantent linuxfr.

Je posterai un journal quand j'aurai fini, ça aura au moins le mérite que les gens interessés pourront voir l'info.

Impressionnant, comme tout le monde.

"On appelle cette ville la ville ou le temps s'est arrêté, peut être parce que toutes les horloges affichent un taux de radiations."

On s'organise des vacances?

Ah ben je fais mieux: l'installateur commence la detection Plug&Play, puis aux deux tiers, fait un écran bleu! Si si, mais pas tout a fait comme ceux qu'on a habituellement. Pas de dump hexa ni rien, juste ces deux phrases:

Hardware failure.

Please contact your computer manufacturer.

Et je paye mon hard reset...
Pourtant, moi je trouve pas que mon hardware a des failures: windows 98, redhat 7.2, mandrake 9, debian woody puis sid, tous me disent que tout marche très très bien.

Comme quoi, le Plug And Pray marche bien dans 2k. Mais je dois trop prier avec ma tête et pas assez avec mon portefeuille, ca doit être pour ca que ca merde :)

- Dave

Ah, forcement, si tu fais du raid hardware en gros bourrin...

Faudra voir si ton controlleur raid a pas un moyen de diviser un disque en parties, parce que c'est quand meme bien con de perdre tout cet espace.

David, qui prefere le software raid top moumoute

Ca marchera, mais ton disque ne sera qu'a moitié utilisé, ce qui craint un peu :)

Ce que tu peux faire, c'est partitionner ton disque en 2x18Go (en prenant bien garde a ce qu'au moins une des deux partitions aie un nombre de blocs superieur ou égal au nombre de blocs des disques 18Go de l'array), puis d'assigner sdX1 au raid, et formater sdX2 et l'utiliser normalement.

Bon, il y aura eventuellement une petite perte de perfs, c'est vrai. Mais dans ce cas, insère également sdX2 dans l'array, mais en tant que spare-disk. Comme ca si un autre 18Go meurt, suivi de l'autre (après la resync du spare quand meme :), ben tu auras quand meme encore tes données, même si tout sur un seul disque c'est un poil paradoxal pour du raid.

David

Quand un disque lache, le contenu de /proc/mdstat change pour t'indiquer que l'array tourne en mode dégradé, et la liste des disques participant a l'array est mis a jour.

Pour être prévenu lorsqu'un disque meurt, simplasse: lancer mdadm au boot (il me semble que Debian le fait tout seul si la version 2 des raidtools est installée) avec l'option -F, qui le fait tourner en daemon de surveillance. Des qu'un array perd une unité ou tombe complètement, un mail est dispatché a root pour lui informer de l'événement.

Et pour le raid materiel, en effet l'OS ne voit qu'un seul disque, puisque la demultiplication est gérée en hardware... Mais ce n'est pas pour ca que l'OS n'a pas de pilotes pour causer au controlleur raid pour savoir ce qui se passe!

Au niveau des sockets (que tu vas devoir gérer pour ton proxy HTTP), je ne puis trop te recommander le guide de beej (recherche "beej guide network programming"). Si ton niveau en anglais le permet, consulte la version originale, la traduction francaise est en retard d'une version majeure et comporte donc moultes omissions.

En particulier, j'attire ton attention sur le fait que l'auteur parle d'utiliser les sockets BSD, presents sur un grand nombre (pour ne pas dire tous) de systemes un*x. Dans un environnement win32, deux choix: utiliser MingW, un compilateur permettant (dans une certaine mesure) de compiler des app posix sous win32, soit d'utiliser quelque chose comme visual c++, auquel cas il te faudra consulter le guide de beej pour voir les particularites de winsock.

Bonne chance, tpe interessant :)

Parait-il que c'est encore plus marrant avec un semi-automatique ;)