Je réagis car, étant utilisateur de Mercurial par exemple dans le projet Brebis, j'ai été véritablement passionné par cet article qui va un peu à l'encontre de l'engouement actuel autour de Git. Ceci étant dit, on comprend très bien que, ayant eu dès le départ l'idée d'étendre Mercurial pour couvrir leur besoin, Facebook ait privilégié Mercurial codé en Python qui peut être ressenti plus "accessible" que Git quand on veut entrer dans le code, leur but n'étant pas de développer un business-model autour mais juste de faire converger Mercurial vers leurs besoins.
Dans tous les cas je recommande chaudement la lecture de l'article. C'est un bel exemple de comportement gagnant-gagnant entre un projet libre et une entreprise. Et juste une petite phrase extraite de cet article pour l'illustrer :
"To narrow this performance gap, we've contributed over 500 patches to Mercurial over the last year and a half."
stopspam : la somme de hachage du fichier est une excellente habitude à avoir dans les échanges de fichiers.
Maintenant c'est un peu du tout ou rien. Tu sais qu'il y a un problème, mais lequel ? Est-ce qu'il y a simplement une corruption de l'archive ? Est-ce que des fichiers à l'intérieur de l'archive ont été impactés ? Brebis est exhaustif dans ses rapports et va présenter tous les problèmes rencontrés (somme de hachage de l'archive incorrecte mais aussi sommes de hachage de tous les fichiers à l'intérieur de l'archive, tailles des fichiers, droits…).
Mais surtout la somme de hachage ne permet pas de garantir la conformité de l'archive envoyée du point de vue du destinataire.
Disons que qu'une société A envoie une archive à une société B contenant certains fichiers vides. L'archive n'est pas corrompue, l'envoi se déroulera bien, somme de hachage bonne, mais l'archive ne sera pas dans un état acceptable pour le destinataire. Et cette anomalie va monopoliser une ressource sur une tâche peu motivante pour être détectée. Brebis permet de définir un référentiel de l'archive (fichiers ou répertoires devant être présents, tailles (<,> ou =), droits,…) qui permettra à chaque transfert de garantir le respect de la conformité du format et du contenu de l'archive attendue.
Katyucha: Je dirais que Brebis se situe plutôt du côté de l'exploitation quotidienne, pour clôre le cycle des sauvegardes et assurer une exploitation possible des données surveillées.
Maintenant si l'environnement nécessaire à la restauration n'est plus là et que ça impacte le business on est dans le cas d'un désastre qui doit être prévu au niveau organisationnel et technique dans le cadre de plan de continuité d'activité/plan de reprise d'activité.
niclone: pris comme ça c'est sans fin c'est sûr :) Blague à part, si tu mets en place Brebis sur un serveur de backups, n'hésite pas à faire un petit feedback.
Katyucha : c'est malheureusement peu souvent vrai qu'une sauvegarde fonctionne, pour la simple et bonne raison que, comme à peu près dans tous les domaines de l'informatique, ce qui n'est pas testé ne marche pas.
J'ai rencontré dans ma vie professionnelle des sauvegardes jamais testées qui contenaient des fichiers vides, des archives corrompues et des archives qui contenaient tous les fichiers possibles sauf celui dont l'admin avait besoin pour redémarrer son système le plus vite possible. Ces découvertes arrivent bien sûr toujours au pire moment.
Brebis se propose de contrôler de façon automatisée les sauvegardes. Il est donc possible de le faire régulièrement sans monopoliser une ressource pour effectuer ce travail fastidieux. Ce qui permet justement de restaurer sans crainte son système d'information à l'aide des sauvegardes régulièrement contrôlées par Brebis.
François Chaix : on peut utiliser Brebis dans cette optique et c'est même l'un des deux cas principaux d'utilisations de Brebis.
Il arrive souvent que deux sociétés échangent des fichiers sous la forme d'archive et d'après mon expérience professionnelle le contrôle du bon déroulement du transfert et de la cohérence du contenu des archives est effectué manuellement par les équipes de production, ce qui fait perdre un temps considérable pour une tâche peu gratifiante.
Avec Brebis, tu peux générer avant l'export de l'archive une liste des fichiers contenus dans l'archive. Elle permettra au receveur de réutiliser Brebis pour vérifier que rien n'a changé et si quelque chose a changé l'identifier. Tout cela bien sûr de manière automatisée.
Pour répondre plus directement à ta question, Brebis n'effectue que le contrôle du contenu de l'archive et l'identification d'éventuels changements. Il n'effectue pas de réparation.
Barret Michel: non, pas encore. Mais c'est une bonne suggestion merci, il y a en effet sûrement du bon à prendre. Je suis parti d'un besoin (comme bien souvent) et j'ai fait grandir en intégrant ce qui me servait et paraissait cohérent. J'ai commencé ce travail de comparaisons de façon un peu plus systématique récemment mais je n'avais pas encore pensé aux HIDS.
aedrin: il faut que je me renseigne sur par2 pour déterminer un cas d'usage de ce dernier avec Brebis. N'hésite pas à m'en dire plus, je ne sais pas bien à ce jour utiliser par2.
Lors de mon test de la démo, ça allait vite et réagissait bien. J'abonde dans le sens de la mauvaise bonne idée pour le hash qui identifie les tickets. Par exemple ici au taf on passe notre journée à dire "t'a avancé sur PROD-737 ?" ou "ça en est où INT-2121?" Si ça doit être remplacé par une somme de hachage ça fait quelque chose d'inexploitable à moins d'avoir un support écrit à chaque fois. C'est un peu dommage je pense.
Oui, elles sont en effet incompatibles, c'est le prix à payer pour les vraies nouveautés et pour retrouver une syntaxe cohérente (passage au monde moderne avec l'unicode par défaut, fin du mot-clé print et des noms de modules avec des majuscules et bien d'autres). Sans parler de la ré-écriture du code. T'as un excellent utilitaire fourni avec les archives de Python qui te traduit du code 2.x vers 3.x. Le script s'appelle 2to3.
pas de "vraies" nouveautés de grande empleur
Si on omet ce que j'ai déjà évoqué, ça fait quand même deux versions (2.6 et 2.7) que les nouvelles fonctionnalités les plus intéressantes de la branche 2.x arrivent directement de la branche 3.x.
tous les modules ne sont pas encore traduit pour Python 3, et / ou pas encore empaquetés dans les distributions Linux
Franchement ça se fera pas en un jour mais le chantier progresse bien. Tu trouves des grosses bibliothèques comme sqlalchemy qui tournent sous python3. Sachant que Python c'est "battery included" t'as vraiment de quoi t'en sortir en attendant.
Enfin pour quelqu'un qui veut commencer le Python aujourd'hui, lui conseiller même python2.7 face à python3.1 ou python3.2 qui sort en début 2011 serait une grave erreur à mon avis (alors que je considère que python2.7 est une excellente dernière version de branche).
En fait c'est surtout que c'est une analyse assez personnelle du sujet. J'apporte mon point de vue de contributeur Debian sur la nouvelle en elle-même et je n'ai pas de prétention à être neutre ou impartial, d'où la qualification en journal. Maintenant ça m'est arrivé de faire des dépêches et je pense que j'en referai :)
Il est même courant qu'un programme qui a été abandonné en amont soit maintenu dans Debian car le responsable associé l'utilise de façon régulière. Il assure alors une maintenance minimale voire inclut ses propres patches pour le faire évoluer.
> Sur les miroirs
Debian, les logs conservent les requêtes HTTP ou FTP qui ont été effectuées sur
telle URL (donc des .deb) en provenance de telle adresse IP.
Tout à fait. Lorsqu'on parle d'anonymat, il s'agit surtout du fait qu'aucune information à caractère privé n'est requise pour exécuter popularity-contest. Après Debian a bien conscience des limites de cet anonymat et tu peux trouver les informations relatives à ce sujet évoquées dans la FAQ du popularity contest : http://popcon.debian.org/FAQ
> Je pensais plutôt à la façon dont les paquets étaient rangés sur les CD et DVD Debian,
C'est en effet l'une des premières utilisations des statistiques remontées par le concours de popularité. On peut ainsi savoir quoi mettre sur le premier CD.
C'est en effet possible. Chaque paquet dans Debian a un coût, dans le sens où il requière un effort de la part du responsable du paquet qui doit corriger les bugs qui sont remontés régulièrement et également le mettre à jour quand le projet amont sort une nouvelle version.
Mais je te rassure, Debian n'a pas de politique du type "si un soft a moins de X utilisateurs, on le vire", ce sera plutôt un facteur d'informations supplémentaires pour l'enlever de l'archive officielle s'il est bourré de bugs, qu'il n'est plus développé activement, qu'il a été abandonné par son responsable, qu'aucun autre ne veut le prendre en charge et qu'enfin, on s'aperçoit sur sa valeur popcon que personne ne l'utilise.
J'apprends à l'instant que Ubuntu ne propose pas de paquet pour le logiciel Tor car ce dernier change trop souvent pour la version LTS et qu'ils n'ont pas de dépôt équivalent à debian-volatile.
Si un développeur Ubuntu peut confirmer ou infirmer cette information, je pense que ça va intéresser du monde.
# Packaging Debian
Posté par Carl Chenet (site web personnel) . En réponse à la dépêche La folie Docker. Évalué à 6.
Docker 1.0 est non seulement dans Sid (unstable), mais aussi dans Jessie (testing). Yabon.
# Mercurial vu par Facebook
Posté par Carl Chenet (site web personnel) . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 9.
Je réagis car, étant utilisateur de Mercurial par exemple dans le projet Brebis, j'ai été véritablement passionné par cet article qui va un peu à l'encontre de l'engouement actuel autour de Git. Ceci étant dit, on comprend très bien que, ayant eu dès le départ l'idée d'étendre Mercurial pour couvrir leur besoin, Facebook ait privilégié Mercurial codé en Python qui peut être ressenti plus "accessible" que Git quand on veut entrer dans le code, leur but n'étant pas de développer un business-model autour mais juste de faire converger Mercurial vers leurs besoins.
Dans tous les cas je recommande chaudement la lecture de l'article. C'est un bel exemple de comportement gagnant-gagnant entre un projet libre et une entreprise. Et juste une petite phrase extraite de cet article pour l'illustrer :
"To narrow this performance gap, we've contributed over 500 patches to Mercurial over the last year and a half."
Quand même.
[^] # Re: Noel et vocabulaire
Posté par Carl Chenet (site web personnel) . En réponse au journal Brebis 0.9 "Bouddhinette", le vérificateur automatisé de sauvegarde, publié pour Noël. Évalué à 2.
Effectivement, on oublie trop rapidement le rôle des lutins dans cette affaire…
[^] # Re: Par2
Posté par Carl Chenet (site web personnel) . En réponse à la dépêche Brebis, le vérificateur automatisé de sauvegarde. Évalué à 3.
stopspam : la somme de hachage du fichier est une excellente habitude à avoir dans les échanges de fichiers.
Maintenant c'est un peu du tout ou rien. Tu sais qu'il y a un problème, mais lequel ? Est-ce qu'il y a simplement une corruption de l'archive ? Est-ce que des fichiers à l'intérieur de l'archive ont été impactés ? Brebis est exhaustif dans ses rapports et va présenter tous les problèmes rencontrés (somme de hachage de l'archive incorrecte mais aussi sommes de hachage de tous les fichiers à l'intérieur de l'archive, tailles des fichiers, droits…).
Mais surtout la somme de hachage ne permet pas de garantir la conformité de l'archive envoyée du point de vue du destinataire.
Disons que qu'une société A envoie une archive à une société B contenant certains fichiers vides. L'archive n'est pas corrompue, l'envoi se déroulera bien, somme de hachage bonne, mais l'archive ne sera pas dans un état acceptable pour le destinataire. Et cette anomalie va monopoliser une ressource sur une tâche peu motivante pour être détectée. Brebis permet de définir un référentiel de l'archive (fichiers ou répertoires devant être présents, tailles (<,> ou =), droits,…) qui permettra à chaque transfert de garantir le respect de la conformité du format et du contenu de l'archive attendue.
[^] # Re: Projets
Posté par Carl Chenet (site web personnel) . En réponse à la dépêche Brebis, le vérificateur automatisé de sauvegarde. Évalué à 3.
Katyucha: Je dirais que Brebis se situe plutôt du côté de l'exploitation quotidienne, pour clôre le cycle des sauvegardes et assurer une exploitation possible des données surveillées.
Maintenant si l'environnement nécessaire à la restauration n'est plus là et que ça impacte le business on est dans le cas d'un désastre qui doit être prévu au niveau organisationnel et technique dans le cadre de plan de continuité d'activité/plan de reprise d'activité.
[^] # Re: Mais qui va vérifier brebis ?
Posté par Carl Chenet (site web personnel) . En réponse à la dépêche Brebis, le vérificateur automatisé de sauvegarde. Évalué à 2.
niclone: pris comme ça c'est sans fin c'est sûr :) Blague à part, si tu mets en place Brebis sur un serveur de backups, n'hésite pas à faire un petit feedback.
[^] # Re: Projets
Posté par Carl Chenet (site web personnel) . En réponse à la dépêche Brebis, le vérificateur automatisé de sauvegarde. Évalué à 3.
Katyucha : c'est malheureusement peu souvent vrai qu'une sauvegarde fonctionne, pour la simple et bonne raison que, comme à peu près dans tous les domaines de l'informatique, ce qui n'est pas testé ne marche pas.
J'ai rencontré dans ma vie professionnelle des sauvegardes jamais testées qui contenaient des fichiers vides, des archives corrompues et des archives qui contenaient tous les fichiers possibles sauf celui dont l'admin avait besoin pour redémarrer son système le plus vite possible. Ces découvertes arrivent bien sûr toujours au pire moment.
Brebis se propose de contrôler de façon automatisée les sauvegardes. Il est donc possible de le faire régulièrement sans monopoliser une ressource pour effectuer ce travail fastidieux. Ce qui permet justement de restaurer sans crainte son système d'information à l'aide des sauvegardes régulièrement contrôlées par Brebis.
[^] # Re: Par2
Posté par Carl Chenet (site web personnel) . En réponse à la dépêche Brebis, le vérificateur automatisé de sauvegarde. Évalué à 4.
François Chaix : on peut utiliser Brebis dans cette optique et c'est même l'un des deux cas principaux d'utilisations de Brebis.
Il arrive souvent que deux sociétés échangent des fichiers sous la forme d'archive et d'après mon expérience professionnelle le contrôle du bon déroulement du transfert et de la cohérence du contenu des archives est effectué manuellement par les équipes de production, ce qui fait perdre un temps considérable pour une tâche peu gratifiante.
Avec Brebis, tu peux générer avant l'export de l'archive une liste des fichiers contenus dans l'archive. Elle permettra au receveur de réutiliser Brebis pour vérifier que rien n'a changé et si quelque chose a changé l'identifier. Tout cela bien sûr de manière automatisée.
Pour répondre plus directement à ta question, Brebis n'effectue que le contrôle du contenu de l'archive et l'identification d'éventuels changements. Il n'effectue pas de réparation.
[^] # Re: libarchive + mtree
Posté par Carl Chenet (site web personnel) . En réponse au journal Brebis, le vérificateur automatisé de sauvegarde. Évalué à 2.
d-jo : merci :) Pour la suggestion sur mtree et libarchive, c'est en effet sur ma todo list depuis que l'empaqueteur FreeBSD de Brebis m'en a parlé.
[^] # Re: HIDS
Posté par Carl Chenet (site web personnel) . En réponse au journal Brebis, le vérificateur automatisé de sauvegarde. Évalué à 1.
Barret Michel: non, pas encore. Mais c'est une bonne suggestion merci, il y a en effet sûrement du bon à prendre. Je suis parti d'un besoin (comme bien souvent) et j'ai fait grandir en intégrant ce qui me servait et paraissait cohérent. J'ai commencé ce travail de comparaisons de façon un peu plus systématique récemment mais je n'avais pas encore pensé aux HIDS.
[^] # Re: Par2 ?
Posté par Carl Chenet (site web personnel) . En réponse au journal Brebis, le vérificateur automatisé de sauvegarde. Évalué à 3.
aedrin: il faut que je me renseigne sur par2 pour déterminer un cas d'usage de ce dernier avec Brebis. N'hésite pas à m'en dire plus, je ne sais pas bien à ce jour utiliser par2.
[^] # Re: Accès aux sources
Posté par Carl Chenet (site web personnel) . En réponse au journal Brebis, le vérificateur automatisé de sauvegarde. Évalué à 2.
merci pour la remarque, je vais essayer d'améliorer ça. Je te conseille de passer par l'outil du redmine qui est bien fait je trouve http://brebisproject.org/projects/brebis/repository
# rapide retour
Posté par Carl Chenet (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 5.
Lors de mon test de la démo, ça allait vite et réagissait bien. J'abonde dans le sens de la mauvaise bonne idée pour le hash qui identifie les tickets. Par exemple ici au taf on passe notre journée à dire "t'a avancé sur PROD-737 ?" ou "ça en est où INT-2121?" Si ça doit être remplacé par une somme de hachage ça fait quelque chose d'inexploitable à moins d'avoir un support écrit à chaque fois. C'est un peu dommage je pense.
# Retour très intéressant
Posté par Carl Chenet (site web personnel) . En réponse à la dépêche Deux ans de projet libre : bilan. Évalué à 1.
Merci bien :)
# Excellente initiative !
Posté par Carl Chenet (site web personnel) . En réponse à la dépêche Les Variations Goldberg dans le domaine public. Évalué à 3.
Excellente initiative à mon sens, merci à toutes les personnes qui ont travaillé à la libération des Variations Goldberg.
[^] # Re: Bravo
Posté par Carl Chenet (site web personnel) . En réponse à la dépêche Sortie officielle de « Ma Petite Auto-Entreprise » et Aemanager 1.0. Évalué à 3.
J'espère que ça va prendre, c'est un bon business model que tu as choisi et le service que tu délivres peut servir à un grand nombre de personnes.
[^] # Re: Python dans Debian
Posté par Carl Chenet (site web personnel) . En réponse à la dépêche Python 3.2. Évalué à 2.
Python 3.1.1 est rentré en Sid début 2010. Python 3.1.3 fin 2010. Par contre 3.2.1 est rentré hier dans Sid.
Pour plus d'infos : http://packages.qa.debian.org/p/python3.1.html ou http://packages.qa.debian.org/p/python3.2.html
[^] # Re: Excellente nouvelle... qui se lance ?
Posté par Carl Chenet (site web personnel) . En réponse au journal pypy de plus en plus rapide ?. Évalué à 4.
Oui, elles sont en effet incompatibles, c'est le prix à payer pour les vraies nouveautés et pour retrouver une syntaxe cohérente (passage au monde moderne avec l'unicode par défaut, fin du mot-clé print et des noms de modules avec des majuscules et bien d'autres). Sans parler de la ré-écriture du code. T'as un excellent utilitaire fourni avec les archives de Python qui te traduit du code 2.x vers 3.x. Le script s'appelle 2to3.
pas de "vraies" nouveautés de grande empleur
Si on omet ce que j'ai déjà évoqué, ça fait quand même deux versions (2.6 et 2.7) que les nouvelles fonctionnalités les plus intéressantes de la branche 2.x arrivent directement de la branche 3.x.
tous les modules ne sont pas encore traduit pour Python 3, et / ou pas encore empaquetés dans les distributions Linux
Franchement ça se fera pas en un jour mais le chantier progresse bien. Tu trouves des grosses bibliothèques comme sqlalchemy qui tournent sous python3. Sachant que Python c'est "battery included" t'as vraiment de quoi t'en sortir en attendant.
Enfin pour quelqu'un qui veut commencer le Python aujourd'hui, lui conseiller même python2.7 face à python3.1 ou python3.2 qui sort en début 2011 serait une grave erreur à mon avis (alors que je considère que python2.7 est une excellente dernière version de branche).
[^] # Re: Commentaire inutile
Posté par Carl Chenet (site web personnel) . En réponse au journal Le projet Debian s’ouvre aux contributeurs qui ne gèrent pas de paquets. Évalué à 4.
# Je trouve l'idée excellente !
Posté par Carl Chenet (site web personnel) . En réponse au journal Du bon, du gros, du lourd !. Évalué à 8.
[^] # Re: disparition des derniers ?
Posté par Carl Chenet (site web personnel) . En réponse au journal Le concours de popularité de Debian. Évalué à 3.
[^] # Re: Autres distributions
Posté par Carl Chenet (site web personnel) . En réponse au journal Le concours de popularité de Debian. Évalué à 3.
Debian, les logs conservent les requêtes HTTP ou FTP qui ont été effectuées sur
telle URL (donc des .deb) en provenance de telle adresse IP.
Tout à fait. Lorsqu'on parle d'anonymat, il s'agit surtout du fait qu'aucune information à caractère privé n'est requise pour exécuter popularity-contest. Après Debian a bien conscience des limites de cet anonymat et tu peux trouver les informations relatives à ce sujet évoquées dans la FAQ du popularity contest : http://popcon.debian.org/FAQ
[^] # Re: disparition des derniers ?
Posté par Carl Chenet (site web personnel) . En réponse au journal Le concours de popularité de Debian. Évalué à 4.
C'est en effet l'une des premières utilisations des statistiques remontées par le concours de popularité. On peut ainsi savoir quoi mettre sur le premier CD.
[^] # Re: disparition des derniers ?
Posté par Carl Chenet (site web personnel) . En réponse au journal Le concours de popularité de Debian. Évalué à 10.
Mais je te rassure, Debian n'a pas de politique du type "si un soft a moins de X utilisateurs, on le vire", ce sera plutôt un facteur d'informations supplémentaires pour l'enlever de l'archive officielle s'il est bourré de bugs, qu'il n'est plus développé activement, qu'il a été abandonné par son responsable, qu'aucun autre ne veut le prendre en charge et qu'enfin, on s'aperçoit sur sa valeur popcon que personne ne l'utilise.
# Pas de Tor dans Ubuntu
Posté par Carl Chenet (site web personnel) . En réponse au journal Rôle du dépôt debian-volatile dans Debian. Évalué à 2.
Si un développeur Ubuntu peut confirmer ou infirmer cette information, je pense que ça va intéresser du monde.