(réponse officielle du stagiaire Google impliqué dans le SoC de cette année)
Pour la question, c'est un peu réponse libre. Google n'oblige pas à sélectionner selon l'un ou l'autre critère, donc c'est à chaque projet de voir ce qu'ils veulent retirer du Summer of Code. Beaucoup d'organisations fournissent une liste d'idées mixtes, certaines convenant à des newbies du monde libre, d'autres plus ouvertes et ambitieuses pour des candidats qui sont déjà à l'aise.
Il y a de la lecture intéressante qui touche un petit peu au sujet des "profils à chercher" pour les futurs mentors sur le wiki du SoC, http://code.google.com/p/google-summer-of-code/w/list . Je recommande aussi vivement la page "Advice for Students" pour les futurs candidats.
(réponse perso)
Ceci étant, je pense que le but premier du SoC, au dela de permettre à des étudiants de ne pas avoir a bosser au macdo pendant l'été, c'est d'amener du sang neuf dans le monde du logiciel libre. Les plus grandes success stories du SoC concernent des étudiants qui ne connaissaient le libre que de nom ou très superficiellement avant le SoC, et qui sont maintenant très actifs au sein de leur communautés respectives.
Le risque en prenant un développeur qui s'y connait déjà, comme tu le remarques, c'est qu'il est tentant pour ce dernier de se considérer comme un mercenaire, qui va pisser du code pendant quelques mois puis s'en aller. C'est un peu dommage à mon avis, mais ca s'est déjà vu aussi.
Bref, personellement, je chercherais plutot du sang neuf, ou une personne expérimentée qui montre un certain désir de rester au dela du SoC, mais cela dépend vraiment de la communauté et des besoins (ou envies) de chaque projet.
J'ai malheureusement survolé, étant pressé, mais pour la fin, ou tu ouvres sur les langages naturels: que penses tu d'Inform 7 ? Il s'agit d'un langage de création de jeu d'aventure interactif. Le langage de "programmation" est un sous-ensemble de l'anglais, qui permet de décrire le monde de l'aventure et de poser relations et activités sur les objets du monde, pour construire le fil de l'aventure.
Bien sur, ce n'est pas tout à fait de l'anglais, des fois les constructions sont un peu lourdingues, mais c'est vraiment un plaisir de décrire une aventure en utilisant ce langage, plutot qu'en composant des objets avec attributs et méthodes, comme il fallait le faire avec Inform 6.
Ton troll sur le Tibet dans Google Maps m'a interpellé (on pourrait aussi dire "J'ai mordu au troll", désolé pour les autres qui vont devoir subir la réponse, en plus du truc originel), et je suis donc allé me renseigner. Comme je n'ai pas que ca à faire non plus, je me suis arrêté à wikipedia. Oui, je sais, pas fiable tout ca, mais pour un premier constat ca peut être bien.
Ces sections expliquent que, quelle que soit l'opinion des défenseurs de l'occupation chinoise ou des contestataires de celle-ci, aucun pays au monde ne reconnait l'indépendance du Tibet. De fait, le Tibet n'a pas à apparaitre dans Google Maps, puisque Maps s'efforce de dresser une carte du monde telle qu'elle est généralement admise par les hautes instances politiques de ce monde, qui ne reconnaissent pas l'existence du Tibet en tant qu'autre chose que province chinoise.
Après, on peut dire que c'est dégueulasse, qu'il faut faire la révolution et aller enfiler son costume de Batman, mais je crois que le pire qu'on puisse reprocher à Google sur ce point précis, c'est d'être le plus apolitique possible dans ces débats qui échauffent tout le monde, en se ralliant à l'avis des nations unies.
Après, on peut aussi y voir un complot des chinois du FBI pour que Google puisse s'implanter en Chine, mais je trouve le scénario ridiculement emblématique de la tendance que l'esprit humain a de former des théories du complot (surtout que pragmatiquement, la Chine n'a rien à dire à une entreprise américaine en dehors du domaine .cn), surtout quand une alternative plus logique (ralliement à l'ONU) est disponible.
Merci de la mise au point, c'est sympa de venir nous expliquer.
Petites questions en passant, qui ne sont ni une interpellation ni une tentative de lynchage ou quoi que ce soit :-)
Avez-vous pensé à Google Checkout? Pour ce que j'en ai vu, l'interface pour brancher le magasin dessus est très interopérable (une requête POST signée vers un serveur gcheckout), et fonctionne de manière similaire à Paypal une fois passé sur les serveurs gcheckout - sans les trucs qui font que Paypal est détesté de par le monde ;-). (disclaimer - J'ai été stagiaire chez google, j'essaye d'etre objectif, mais je préfère prévenir)
Après, tu dis que si le numéro de CB n'est pas enregistré chez Paypal, il y a un autre système de paiement? Un truc qui passe via un système de paiement d'une banque? Si oui, pourquoi encore avoir Paypal dans le mix?
Totalement hors sujet, mais bon, autant mettre un peu de bonne humeur éducative dans cette discussion bien trollifère :-)
Je ne sais pas s'il y a une technique plus simple, mais globalement, il faut mapper quelque part sur ton clavier la touche de composition, qui te permettra de composer un 'é' a partir de ''' et 'e' (d'ailleurs, j'écris ceci sur un clavier qwerty :-)).
Lance xev, place la souris dans la fenêtre, et regarde le keycode que pond xev quand tu appuies sur la touche 'windows'. Tu peux utiliser une autre touche, mais je trouve que la touche winwin est parfaitement placée pour servir de touche de composition.
Une fois trouvé le keycode, il suffit de placer la ligne suivante dans le fichier '.Xmodmap' dans ton home:
keycode 0x73 = Multi_key
(ou 0x73 est le keycode que t'as pondu xev, en hexadécimal)
Si tu as Gnome, KDE ou Xfce comme gestionnaire de bureau, il devrait te proposer de charger automatiquement cette modification du map clavier à la prochaine ouverture de session. Si ce n'est pas le cas, il faut expliquer d'une manière ou d'une autre à ton gestionnaire de bureau qu'il faut exécuter 'xmodmap ~/.Xmodmap' à l'ouverture de session. Si tu veux profiter de la touche de composition sans rouvrir une session, exécuter cette commande a la mimine dans un terminal marche très bien.
Voila. Une fois tout ce foutoir accompli, tu devrais pouvoir faire un <win>-'-e et obtenir un magnifique é. De même pour d'autres combinaisons comme W-^-e, W-`-a, W-a-a (å), W-/-o (ø) ...
Mea culpa, je plaide la folie temporaire causée par la fatigue. Tu as tout à fait raison, après relecture de mon exemplaire du CPI (article L121-1 pour le droit moral et L122-7 pour les droits patrimoniaux).
Comme quoi, je devrais pas faire le juriste de comptoir le matin...
(mais alors c'est quoi la différence avec le droit américain? Je me souviens qu'il y en a une importante, en plus de l'impossibilité de placer dans le domaine public par acte de son vivant...)
Il est impossible de renoncer au droit d'auteur sur une oeuvre, mais il est possible de le transférer. En d'autres termes, il est impossible en droit français de placer une oeuvre dans le domaine public sans mourir et attendre que le droit d'auteur expire, mais tu peux transférer tes droits à un tiers. Il y a toujours [au moins] un auteur, mais celui-ci peut varier au fil du temps.
Et comme tu fais bien de le noter, c'est une spécificité du droit français. Mais même si dans d'autres droits, notament américain, il est possible de placer une oeuvre dans le domaine public par acte de son vivant, il est difficile de le faire "correctement", de telle manière qu'un tribunal acceptera que tu as renoncé à ton droit d'auteur.
C'est à cause de cela notament que l'utilisation assez à la mode du domaine public comme "licence la plus permissive et sécurisante qui soit" (un non-sens déjà parce que le domaine public n'est pas une licence) est fortement déconseillée pour du logiciel libre: non seulement ce n'est pas une licence, mais elle se base sur du droit qui varie fortement de pays en pays, et qui est soit impossible, soit difficile à réaliser sans se planter.
Et si tu te plante, c'est un monde de douleur pour ceux qui utilisent ton logiciel dans des contextes ou le doute sur le plan légal n'est pas permis, et pire, tu t'exposes à des poursuites pour des défauts de ton logiciel, puisque tu n'as pas limité ta responsabilité par une licence (ben ouais, tu pouvais pas, tu as renoncé a ton droit d'auteur, donc pour construire une licence par dessus ce droit, c'est rapé).
(comme quoi, faire un stage aux US et avoir comme collègue un Intellectual Property Lawyer, ca peut servir!)
Tout d'abord, je voudrais juste souligner la timeline qui a été présentée dans l'article: les organisations qui disent participer au SoC 2007, s'il y en a sur le net, ne devraient pas dire ça: Google n'a pas publié la liste des organisations qui ont été acceptées, elles ne peuvent donc pas savoir. Au mieux, elles ont candidaté. Encore quelques jours de patience ;-).
A part ca, je ne vais que réitérer ce que j'ai pu dire l'année dernière: J'ai participé aux SoC 2005 et 2006, d'abord en tant qu'étudiant puis en tant que mentor pour le projet Subversion. Cette expérience m'a permis de m'intégrer au développement d'un gros projet libre, de faire la connaissance de plein de gens géniaux (d'abord sur internet, puis en personne aux Summer of Code Mentor/Admin Summit et Subversion Developer Summit, qui ont eu lieu au Googleplex), et d'occuper un été a améliorer mon karma en contribuant au monde du libre.
Bien sur, on ne va pas se voiler la face, les 4500$ étaient plus que bienvenus pour l'étudiant que je suis, et ca fait évidemment très bien sur le CV. Mais le SoC sera vraiment plus riche en récompenses pour ceux qui voient au dela de l'aspect purement mercantile du deal.
Aux candidats potentiels: je vous recommande vivement la lecture du wiki monté pour le SoC, en particulier la page http://code.google.com/p/google-summer-of-code/wiki/Advicefo(...) , qui donne des conseils sur la candidature, le contact des organisations, tout ca. C'est assez effrayant de voir le nombre de candidatures de deux lignes que les projets ont recu les deux années passées qui disent en gros "Je veux les sous, et puis votre projet il a l'air bien, mais est-ce que je suis payé en avance?". J'espere qu'il n'y en aura pas de comme ca de la part de linuxiens français ;-)
Un grand bravo pour avoir pris en compte les retours d'utilisation de DLFP aussi rapidement! Je n'ai pas vraiment d'autre commentaire (pour l'instant) sur Teardrop lui-même, mais une telle réactivité doit être félicitée!
L'API SOAP de Google peut quand même être une solution acceptable dans ton cas, avec une légère extension de ton schéma XML de définition de moteurs de recherche.
SOAP est un protocole de RPC qui utilise XML et HTTP comme transport, donc faire une requête à l'API google revient à envoyer une requête POST à une certaine URL. En réponse, tu recevras un bloc de XML, que ton parseur actuel (regex) peut décortiquer à priori.
Je vois que ton format supporte déjà le fait de dire si l'url doit etre accédée par GET ou POST. Si ce n'est déjà fait, il faudrait donc simplement intégrer un bloc de CDATA, contenant le XML a envoyer comme corps de requête POST (avec la possibilité d'y insérer un %q, comme c'est présentement possible avec les éléments GET).
Avec cette modification, il serait possible d'avoir un moteur Teardrop utilisant l'API SOAP de Google pour faire des recherches. Le seul problème restant est qu'il faut que chaque utilisateur obtienne une API key, et qu'il puisse la renseigner relativement facilement dans Teardrop (ou au pire, il édite le XML et colle son API key au bon endroit).
En ce qui concerne le disclaimer, il peut te protéger toi, l'auteur du logiciel. Mais les utilisateurs qui utilisent ton logiciel seront en violation des TOS dès qu'ils feront une recherche. Et quand google (ou un autre) décidera de les bloquer pour violation de TOS, c'est toi qu'ils viendront engueuler :-)
Voila. Sinon, sympa ton logiciel, je l'avais pas dit. J'aime bien le format de moteur extensible. Maintenant, s'il était un tout petit peu plus complet, il serait possible d'utiliser les API officielles de certains moteurs, plutot que d'émuler a la sauvage un navigateur. Au final, ca devrait t'arranger aussi, puisque parser un XML qui contient uniquement tes données, c'est carrément moins compliqué que parser un HTML coincoin qui doit convenir a des yeux humains.
Tous les moteurs de recherche que je connais interdisent les requêtes automatisées, car il s'agit d'un abus de leur infrastructure sans gain aucun pour eux.
Pour ce qui est du "on ne peut meme pas discuter", je crois que tu as traduit trop littéralement la clause du TOS. La référence a de la recherche implique pour moi qu'ils entendent meta-search au sens "je pourrais pas juste avoir accès a vos index bruts et fouiller dedans?"
Quoi qu'il en soit, dans l'état ce logiciel est bien en violation des Terms of Service au moins de Google (et je doute que Yahoo et MSN autorisent les recherches automatisées). Mais vu que ton logiciel a priori n'a pas comme but d'effectuer des meta-searches a leur sens, tu peux toujours faire la demande d'une autorisation.
L'autre solution, dans le cas de Google, est de modifier ton logiciel pour passer par l'API SOAP (documentée sur le site qui rassemble les efforts open source de Google: http://code.google.com/apis/soapsearch/ ). Cette API est la façon officielle de faire des requêtes aupres de Google depuis des logiciels tierce partie (donc tu n'enfreins pas les TOS en l'utilisant). De plus, l'API te renverra les résultats en tant qu'objets SOAP, que tu pourras analyser beaucoup plus facilement à l'aide de bibliothèques spécialisées.
Ensuite, les utilisateurs qui voudront utiliser Google dans ton logiciel devront faire la demande d'une "API key", une clé qui leur permet de faire des recherches. Ce système d'API key est là pour éviter l'abus de l'API de recherche (genre pas plus de 1000 requetes par jour avec une clé, ce qu'un particulier utilisant ton logiciel ne dépassera jamais), mais à part ca elles sont données à qui en fait la demande.
Oui, c'est plus compliqué, oui c'est plus chiant, mais perso je trouve que rester dans la légalité et respecter les termes d'utilisation des services qu'on utilise dans nos logiciels libres, c'est essentiel, non seulement pour éviter les emmerdes, mais surtout pour entretenir le karma bénéfique du logiciel libre en général.
Version détaillée, puisque ça semble intéresser une bonne portion de gens:
` svn diff -x '-w' ` produira un diff unifié qui ignore les changements d'indentation. Il me semble qu'il est possible de configurer son client de telle manière qu'il passe systématiquement le -w au moteur de diff interne. Par défaut, le diff est toujours un diff unifié normal, qui montre tous les changements.
A noter que la nouveauté ici est bien que le moteur de diff *interne* de Subversion supporte ces options. Il était déjà possible de dire a `svn diff` d'utiliser un logiciel de diff externe, comme GNU Diff, et lui passer des options similaires.
Alors, je n'ai pas les détails (je les aurai au SVN Summit), mais ce que je sais, c'est que dans le dépot officiel du projet, il y a une branche merge-tracking, et que ceux qui travaillent dessus disent être suffisament avancés dans leur travail pour que la branche soit utilisable, au moins par les développeurs. Il y a encore tout un travail de stabilisation et de tests avant de pouvoir diffuser ca au monde.
Concernant le remplacement de Clearcase par Subversion, je dois être franc et te dire que ça va être difficile. Clearcase est plus, bien bien plus, qu'un simple outil de revision control. Il incorpore toute une floppée d'autres aspects du cycle de développement. De plus, son UI est très différente de tous les autres outils existants, ce qui va rendre la migration vers autre chose difficile.
Donc, je serais de l'avis de commencer, comme tu le suggères, par des petites équipes pilotes. Etudiez les problèmes de migration qu'il y a sur un petit projet, pour mieux planifier une éventuelle migration totale.
À noter également que Collabnet, l'entreprise qui est à l'origine de Subversion, propose des solutions plus complètes se basant sur Subversion, qui pourraient éventuellement remplacer plus efficacement l'intégralité de Clearcase. Disclaimer: Je ne suis pas employé de Collabnet, je n'ai jamais déployé leurs systèmes en entreprise. J'en ai simplement entendu du bien, et il est clair qu'ils rassemblent encore à ce jour une grande expertise sur Subversion, qu'aucune autre entreprise ne peut à ce jour prétendre égaler.
Si tu as besoin d'aide pour la migration, n'oublie pas la liste de diffusion users@subversion.tigris.org, ou tu trouveras peut-être d'autres gens qui ont fait des migrations depuis Clearcase. Et dans tous les cas, que ce soit un succès ou non, n'oublie pas de nous rapporter le résultat de cette étude/migration, ça nous intéresse!
Le but avoué de Subversion est de proposer un remplaçant à CVS. Le projet à été lancé au début de ce siècle, par le groupe qui représentait les derniers mainteneurs actifs du code source de CVS, et qui étaient donc dans une position idéale pour juger des faiblesses de CVS et les corriger. L'un des fondateurs de Subversion, Karl Fogel, a écrit un livre sur l'utilisation de CVS qui est une référence sur le sujet.
Quant à la remarque sur l'utilisation intensive du branch/merge, j'avoue ne pas comprendre, a moins que tu n'aie jamais utilisé CVS. La gestion des branches dans CVS est l'une des pires facettes de ce logiciel. J'admets, il n'y a pas encore de merge tracking intégré à Subversion, mais d'un autre coté, dans CVS non plus. C'est un affreux hack qui ne garantit en rien l'intégrité des données. Le développement du merge tracking dans Subversion avance, et en attendant, l'outil svnmerge.py implémente les trois quarts de ce qui est nécessaire pour le commun des mortels de ce coté là.
OpenCVS, sans vouloir lancer de troll, je me demande si ca servira à quiconque autre qu'OpenBSD. Rester coincé sur la compatibilité avec "l'outil d'avant" est l'erreur que CVS a fait en se basant sur RCS, et RCS sur SCCS. Ils ont trainé des erreurs de conception sur plus de 20 ans avec ce principe, et OpenBSD veut maintenant les perpétuer dans son propre projet.
Ce n'est pas pour rien à mon avis que tant de projets se détachant du code de CVS sont nés. CVS est dans l'impasse depuis 2000, mis a terre par sa compatibilité ascendante à outrance, trainant plus de 20 ans d'erreurs, refusant obstinément de changer pour préserver une compatibilité qui n'a plus lieu d'être. Le monde s'est rendu compte que c'était une impasse, et a commencé a bosser sur d'autres produits: bitkeeper dans le monde propriétaire, et une constellation d'outils dans le monde libre. Bon sang, les développeurs les plus actifs de CVS à l'époque ont déserté pour écrire Subversion, ça devrait envoyer un message clair!
Concernant les autres outils existants, moi je dis bravo. Gits, TLA, Mercurial, Darcs, Codeville, tout ca, bravo. Ce sont des projets intéressants, plus ou moins avancés, mais intéressants. Ils cherchent tous à faire avancer le monde en proposant des outils performants, et font avancer la théorie du revision control en général. Et ils n'ont pas peur de dire "Non, on ne va pas etre compatible avec le format de dépot tout à fait pourri de CVS. On va oser changer la tronche de l'interface utilisateur, parce qu'on pense pouvoir faire mieux."
Désolé de m'emporter, mais en tant que développeur et passioné d'outils de revision control, CVS m'a traumatisé, et le fait qu'on puisse en 2006 prétendre que cet outil à un avenir autre que la casse me fait voir rouge.
J'ai répondu, en catimini, dans le détail de la dépêche: la politique de compatibilité de Subversion est très stricte de ce coté là: pour toute combinaison existante de x et y, un client 1.x peut communiquer avec un client 1.y .
Donc, ton client 1.4 peut sans problèmes communiquer avec un serveur 1.1.4. Bien entendu, les fonctionalités coté serveur seront limitées à celles présentes dans Subversion 1.1, et tu ne bénéficieras pas de quelques optimisations du protocole de communication. Mais tout devrait toujours fonctionner, sinon c'est une régression.
Le jour ou Subversion 2.0 sortira, il n'y a aucune promesse autre que "Il sera possible de passer de 1.x a 2.0 d'une façon ou d'une autre". Les clients 1.x ne pourront vraisemblablement pas communiquer avec un serveur 2.0.
Merci pour ces précisions! J'ajouterais juste que le "SVN Book" édité par Oreilly tient lieu de documentation officielle du projet. En tant que telle, elle peut parfois être trop détaillée. Le livre d'Eyrolles est un livre écrit par l'un des développeurs, se focalisant lui sur une approche didactique, quitte à passer sous silence des détails ésotériques.
Bref, les deux ont leur utilité. Je recommanderais également le Eyrolles à des gens cherchant une introduction à Subversion. Pour ceux qui veulent un ouvrage de référence, l'Oreilly est à préférer. Sa version originale en anglais est disponible sur le web, sous une licence creative commons: http://svnbook.red-bean.com/ .
C'est un dénigrement abusif du XML. Comme format d'échange entre applications, le XML a un véritable rôle à jouer. Par exemple, le protocole WebDAV est encodé en XML, ce qui permet a de multiples clients et serveurs de communiquer en utilisant un format parfaitement défini. Et c'est très bien.
Malheureusement, lors du développement de Subversion, le XML s'était aussi infiltré dans des fichiers qui ne sont lus que localement. L'idée était de pouvoir changer incrémentalement de format aisément, et de profiter de bibliothèques de lecture/écriture déjà très développées et performantes.
L'optimisation consistant à changer le format est venue suite à un effort de rendre toute la bibliothèque de gestion de copie de travail "streamy", c'est à dire opérant le plus possible sur des flux et des transformations de ces flux, plutot que sur le modèle "tout charger, modifier, tout ecrire". Et c'est là qu'un problème du XML se manifeste: il est difficile de lire seulement une partie d'un fichier sans d'abord tout charger pour avoir le DOM.
Le nouveau format s'affranchit partiellement de ce problème. De plus, maintenant que les métadonnées de copie de travail sont stabilisées et établies, l'extensibilité que promettait le format XML n'est plus vraiment utile. Une extensibilité plus limitée nous suffira jusqu'a Subversion 2.0.
C'est un point intéressant que tu soulèves. Merci d'avoir fait la recherche, ça fait un moment que je cherche une traduction de revision control.
Notons néanmoins que "gestion de versions" peut induire en erreur, parce qu'on utilise souvent "version" pour parler de sorties stables d'un logiciel, plutot que les changements incrémentaux qui prennent place pendant le développement. C'est pour cela que Subversion préfère en anglais "revision control", plutot que le "version control" que CVS utilisait.
Alors, "gestion de révisions" ? Moyen encore, puisque ca peut se comprendre comme "outil pour gérer son bac". La langue française est mal fichue des fois :-)
Merci de cette précision! Signalons également que les paquets debian doivent déjà être dans unstable, le mainteneur des paquets les avait prêts avant que je n'annonce la sortie officielle!
Perso j'en ai un autre de Samsung, recommandé par un ami. Le YP-MT6Z est reconnu comme une clé USB de 1Go partout, lit le mp3 et l'ogg, ainsi que d'autres formats dont je me cogne, fait aussi récepteur radio FM et enregistreur (avec encodage direct en mp3). Il tourne sur une seule pile AA, qui lui fournit 14 heures d'autonomie en fonctionnement.
En gros, c'est presque pareil, sauf qu'elle fait 1Go, et qu'elle est en fin de vie, donc un peu moins chère :-)
Je pourrais faire le lourd et parler de journaux publics, mal, toussa.
Mais je suis metalleux, donc merci de l'avertissement. Je n'avais pas d'After Forever dans ma liste de courses musicales, et maintenant je sais pourquoi :-).
Pas grand chose à voir, mais je prends une seconde pour rediriger sur http://www.machinaesupremacy.com , le site de Machinae Supremacy, un groupe de SID-metal qui passe par la petite porte: diffusion d'une grosse partie de la discographie en mp3 ou ogg sur leur site, et les albums sont sortis par des contrats de distribution uniquement, ce qui leur donne le controle total de leur musique. Et bien qu'ils ne mettent pas celle-ci sous licence libre, ils sont extrêmement ouverts en ce qui concerne des autorisations de s'en servir.
Ah, et leurs albums ne sont pas protégés contre la copie. En fait, ca ne les dérange pas qu'on partage leur musique sur le net, même celle des albums. "Si ca permet à une personne qui ne nous connait pas de nous découvrir, même s'ils n'achètent quand même rien, ca nous va".
Donnez moi un logiciel open source potable pour faire du sous-titrage, et je vous fais (ou au moins je participe à) les sous-titres.
Ce n'est pas un truc que je dis en l'air, je suis bilingue et en vacances, donc j'ai les capacités, et, à priori, le temps d'entamer ou finir le boulot. Mais je ne connais aucun outil qui permette de sous-titrer une vidéo confortablement (ie. se balader dans le film, créer des sous-titres, les placer facilement au bon endroit dans le film...).
Pour une solution a base de subversion, il existe FSVS, une surcouche spécialisée dans le contrôle de révisions de morceaux de systèmes de fichiers. Entre autres, il sauvegarde également les permissions et les dates de modification des fichiers.
Je crois voir quel était le bug en question (mauvaise gestion du stdout/err du script de pre-commit), et il est effectivement corrigé.
Attention aussi si tu utilises 1.3.0 et pas 1.3.1, la .0 avait un autre bug au niveau du post-commit: lancer des programmes en background ne marchait pas, le client reste bloqué jusqu'a la fin de tous les programmes lancés par le script post-commit. C'est corrigé dans la 1.3.1, sortie il y a bien un mois maintenant.
[^] # Re: Dollar...
Posté par David Anderson . En réponse à la dépêche Lancement du Google Summer of Code™ 2008. Évalué à 2.
Pour la question, c'est un peu réponse libre. Google n'oblige pas à sélectionner selon l'un ou l'autre critère, donc c'est à chaque projet de voir ce qu'ils veulent retirer du Summer of Code. Beaucoup d'organisations fournissent une liste d'idées mixtes, certaines convenant à des newbies du monde libre, d'autres plus ouvertes et ambitieuses pour des candidats qui sont déjà à l'aise.
Il y a de la lecture intéressante qui touche un petit peu au sujet des "profils à chercher" pour les futurs mentors sur le wiki du SoC, http://code.google.com/p/google-summer-of-code/w/list . Je recommande aussi vivement la page "Advice for Students" pour les futurs candidats.
(réponse perso)
Ceci étant, je pense que le but premier du SoC, au dela de permettre à des étudiants de ne pas avoir a bosser au macdo pendant l'été, c'est d'amener du sang neuf dans le monde du logiciel libre. Les plus grandes success stories du SoC concernent des étudiants qui ne connaissaient le libre que de nom ou très superficiellement avant le SoC, et qui sont maintenant très actifs au sein de leur communautés respectives.
Le risque en prenant un développeur qui s'y connait déjà, comme tu le remarques, c'est qu'il est tentant pour ce dernier de se considérer comme un mercenaire, qui va pisser du code pendant quelques mois puis s'en aller. C'est un peu dommage à mon avis, mais ca s'est déjà vu aussi.
Bref, personellement, je chercherais plutot du sang neuf, ou une personne expérimentée qui montre un certain désir de rester au dela du SoC, mais cela dépend vraiment de la communauté et des besoins (ou envies) de chaque projet.
# Inform?
Posté par David Anderson . En réponse au journal L'expressivité des langages. Évalué à 2.
Bien sur, ce n'est pas tout à fait de l'anglais, des fois les constructions sont un peu lourdingues, mais c'est vraiment un plaisir de décrire une aventure en utilisant ce langage, plutot qu'en composant des objets avec attributs et méthodes, comme il fallait le faire avec Inform 6.
Voila :)
[^] # Re: Solution
Posté par David Anderson . En réponse au journal Je suis un affreux truand .... Évalué à 3.
http://en.wikipedia.org/wiki/History_of_Tibet#In_the_People.(...)
http://en.wikipedia.org/wiki/Tibetan_sovereignty_debate#Thir(...)
Ces sections expliquent que, quelle que soit l'opinion des défenseurs de l'occupation chinoise ou des contestataires de celle-ci, aucun pays au monde ne reconnait l'indépendance du Tibet. De fait, le Tibet n'a pas à apparaitre dans Google Maps, puisque Maps s'efforce de dresser une carte du monde telle qu'elle est généralement admise par les hautes instances politiques de ce monde, qui ne reconnaissent pas l'existence du Tibet en tant qu'autre chose que province chinoise.
Après, on peut dire que c'est dégueulasse, qu'il faut faire la révolution et aller enfiler son costume de Batman, mais je crois que le pire qu'on puisse reprocher à Google sur ce point précis, c'est d'être le plus apolitique possible dans ces débats qui échauffent tout le monde, en se ralliant à l'avis des nations unies.
Après, on peut aussi y voir un complot des chinois du FBI pour que Google puisse s'implanter en Chine, mais je trouve le scénario ridiculement emblématique de la tendance que l'esprit humain a de former des théories du complot (surtout que pragmatiquement, la Chine n'a rien à dire à une entreprise américaine en dehors du domaine .cn), surtout quand une alternative plus logique (ralliement à l'ONU) est disponible.
[^] # Re: Pourquoi O'Reilly a choisi Paypal
Posté par David Anderson . En réponse au journal oreilly, paypal = n'importe quoi ..... Évalué à 3.
Petites questions en passant, qui ne sont ni une interpellation ni une tentative de lynchage ou quoi que ce soit :-)
Avez-vous pensé à Google Checkout? Pour ce que j'en ai vu, l'interface pour brancher le magasin dessus est très interopérable (une requête POST signée vers un serveur gcheckout), et fonctionne de manière similaire à Paypal une fois passé sur les serveurs gcheckout - sans les trucs qui font que Paypal est détesté de par le monde ;-). (disclaimer - J'ai été stagiaire chez google, j'essaye d'etre objectif, mais je préfère prévenir)
Après, tu dis que si le numéro de CB n'est pas enregistré chez Paypal, il y a un autre système de paiement? Un truc qui passe via un système de paiement d'une banque? Si oui, pourquoi encore avoir Paypal dans le mix?
Merci encore d'avoir tiré les choses au clair!
[^] # Re: QWERTY n'est pas incompatible avec les accents
Posté par David Anderson . En réponse au journal J'aurai mal compris ?. Évalué à 2.
Je ne sais pas s'il y a une technique plus simple, mais globalement, il faut mapper quelque part sur ton clavier la touche de composition, qui te permettra de composer un 'é' a partir de ''' et 'e' (d'ailleurs, j'écris ceci sur un clavier qwerty :-)).
Lance xev, place la souris dans la fenêtre, et regarde le keycode que pond xev quand tu appuies sur la touche 'windows'. Tu peux utiliser une autre touche, mais je trouve que la touche winwin est parfaitement placée pour servir de touche de composition.
Une fois trouvé le keycode, il suffit de placer la ligne suivante dans le fichier '.Xmodmap' dans ton home:
keycode 0x73 = Multi_key
(ou 0x73 est le keycode que t'as pondu xev, en hexadécimal)
Si tu as Gnome, KDE ou Xfce comme gestionnaire de bureau, il devrait te proposer de charger automatiquement cette modification du map clavier à la prochaine ouverture de session. Si ce n'est pas le cas, il faut expliquer d'une manière ou d'une autre à ton gestionnaire de bureau qu'il faut exécuter 'xmodmap ~/.Xmodmap' à l'ouverture de session. Si tu veux profiter de la touche de composition sans rouvrir une session, exécuter cette commande a la mimine dans un terminal marche très bien.
Voila. Une fois tout ce foutoir accompli, tu devrais pouvoir faire un <win>-'-e et obtenir un magnifique é. De même pour d'autres combinaisons comme W-^-e, W-`-a, W-a-a (å), W-/-o (ø) ...
Happy to help!
[^] # Re: pour l'instant j'ai ça :)
Posté par David Anderson . En réponse au journal Une configuration Puissante, pas chère, libre et silencieuse ?. Évalué à 1.
[^] # Re: Transfert de droit d'auteur???
Posté par David Anderson . En réponse à la dépêche Concours de logo pour XMMS2. Évalué à 1.
Comme quoi, je devrais pas faire le juriste de comptoir le matin...
(mais alors c'est quoi la différence avec le droit américain? Je me souviens qu'il y en a une importante, en plus de l'impossibilité de placer dans le domaine public par acte de son vivant...)
[^] # Re: Transfert de droit d'auteur???
Posté par David Anderson . En réponse à la dépêche Concours de logo pour XMMS2. Évalué à 3.
Et comme tu fais bien de le noter, c'est une spécificité du droit français. Mais même si dans d'autres droits, notament américain, il est possible de placer une oeuvre dans le domaine public par acte de son vivant, il est difficile de le faire "correctement", de telle manière qu'un tribunal acceptera que tu as renoncé à ton droit d'auteur.
C'est à cause de cela notament que l'utilisation assez à la mode du domaine public comme "licence la plus permissive et sécurisante qui soit" (un non-sens déjà parce que le domaine public n'est pas une licence) est fortement déconseillée pour du logiciel libre: non seulement ce n'est pas une licence, mais elle se base sur du droit qui varie fortement de pays en pays, et qui est soit impossible, soit difficile à réaliser sans se planter.
Et si tu te plante, c'est un monde de douleur pour ceux qui utilisent ton logiciel dans des contextes ou le doute sur le plan légal n'est pas permis, et pire, tu t'exposes à des poursuites pour des défauts de ton logiciel, puisque tu n'as pas limité ta responsabilité par une licence (ben ouais, tu pouvais pas, tu as renoncé a ton droit d'auteur, donc pour construire une licence par dessus ce droit, c'est rapé).
(comme quoi, faire un stage aux US et avoir comme collègue un Intellectual Property Lawyer, ca peut servir!)
# Une experience géniale
Posté par David Anderson . En réponse à la dépêche Le Google Summer of Code est lancé. Évalué à 10.
A part ca, je ne vais que réitérer ce que j'ai pu dire l'année dernière: J'ai participé aux SoC 2005 et 2006, d'abord en tant qu'étudiant puis en tant que mentor pour le projet Subversion. Cette expérience m'a permis de m'intégrer au développement d'un gros projet libre, de faire la connaissance de plein de gens géniaux (d'abord sur internet, puis en personne aux Summer of Code Mentor/Admin Summit et Subversion Developer Summit, qui ont eu lieu au Googleplex), et d'occuper un été a améliorer mon karma en contribuant au monde du libre.
Bien sur, on ne va pas se voiler la face, les 4500$ étaient plus que bienvenus pour l'étudiant que je suis, et ca fait évidemment très bien sur le CV. Mais le SoC sera vraiment plus riche en récompenses pour ceux qui voient au dela de l'aspect purement mercantile du deal.
Aux candidats potentiels: je vous recommande vivement la lecture du wiki monté pour le SoC, en particulier la page http://code.google.com/p/google-summer-of-code/wiki/Advicefo(...) , qui donne des conseils sur la candidature, le contact des organisations, tout ca. C'est assez effrayant de voir le nombre de candidatures de deux lignes que les projets ont recu les deux années passées qui disent en gros "Je veux les sous, et puis votre projet il a l'air bien, mais est-ce que je suis payé en avance?". J'espere qu'il n'y en aura pas de comme ca de la part de linuxiens français ;-)
# Bravo
Posté par David Anderson . En réponse au journal Sortie de Teardrop 1.0. Évalué à 4.
[^] # Re: Conditions d'utilisation des moteurs
Posté par David Anderson . En réponse à la dépêche Sortie de Teardrop 0.9 : méta-moteur de recherche. Évalué à 1.
SOAP est un protocole de RPC qui utilise XML et HTTP comme transport, donc faire une requête à l'API google revient à envoyer une requête POST à une certaine URL. En réponse, tu recevras un bloc de XML, que ton parseur actuel (regex) peut décortiquer à priori.
Je vois que ton format supporte déjà le fait de dire si l'url doit etre accédée par GET ou POST. Si ce n'est déjà fait, il faudrait donc simplement intégrer un bloc de CDATA, contenant le XML a envoyer comme corps de requête POST (avec la possibilité d'y insérer un %q, comme c'est présentement possible avec les éléments GET).
Avec cette modification, il serait possible d'avoir un moteur Teardrop utilisant l'API SOAP de Google pour faire des recherches. Le seul problème restant est qu'il faut que chaque utilisateur obtienne une API key, et qu'il puisse la renseigner relativement facilement dans Teardrop (ou au pire, il édite le XML et colle son API key au bon endroit).
En ce qui concerne le disclaimer, il peut te protéger toi, l'auteur du logiciel. Mais les utilisateurs qui utilisent ton logiciel seront en violation des TOS dès qu'ils feront une recherche. Et quand google (ou un autre) décidera de les bloquer pour violation de TOS, c'est toi qu'ils viendront engueuler :-)
Voila. Sinon, sympa ton logiciel, je l'avais pas dit. J'aime bien le format de moteur extensible. Maintenant, s'il était un tout petit peu plus complet, il serait possible d'utiliser les API officielles de certains moteurs, plutot que d'émuler a la sauvage un navigateur. Au final, ca devrait t'arranger aussi, puisque parser un XML qui contient uniquement tes données, c'est carrément moins compliqué que parser un HTML coincoin qui doit convenir a des yeux humains.
[^] # Re: Conditions d'utilisation des moteurs
Posté par David Anderson . En réponse à la dépêche Sortie de Teardrop 0.9 : méta-moteur de recherche. Évalué à 1.
Pour ce qui est du "on ne peut meme pas discuter", je crois que tu as traduit trop littéralement la clause du TOS. La référence a de la recherche implique pour moi qu'ils entendent meta-search au sens "je pourrais pas juste avoir accès a vos index bruts et fouiller dedans?"
Quoi qu'il en soit, dans l'état ce logiciel est bien en violation des Terms of Service au moins de Google (et je doute que Yahoo et MSN autorisent les recherches automatisées). Mais vu que ton logiciel a priori n'a pas comme but d'effectuer des meta-searches a leur sens, tu peux toujours faire la demande d'une autorisation.
L'autre solution, dans le cas de Google, est de modifier ton logiciel pour passer par l'API SOAP (documentée sur le site qui rassemble les efforts open source de Google: http://code.google.com/apis/soapsearch/ ). Cette API est la façon officielle de faire des requêtes aupres de Google depuis des logiciels tierce partie (donc tu n'enfreins pas les TOS en l'utilisant). De plus, l'API te renverra les résultats en tant qu'objets SOAP, que tu pourras analyser beaucoup plus facilement à l'aide de bibliothèques spécialisées.
Ensuite, les utilisateurs qui voudront utiliser Google dans ton logiciel devront faire la demande d'une "API key", une clé qui leur permet de faire des recherches. Ce système d'API key est là pour éviter l'abus de l'API de recherche (genre pas plus de 1000 requetes par jour avec une clé, ce qu'un particulier utilisant ton logiciel ne dépassera jamais), mais à part ca elles sont données à qui en fait la demande.
Oui, c'est plus compliqué, oui c'est plus chiant, mais perso je trouve que rester dans la légalité et respecter les termes d'utilisation des services qu'on utilise dans nos logiciels libres, c'est essentiel, non seulement pour éviter les emmerdes, mais surtout pour entretenir le karma bénéfique du logiciel libre en général.
[^] # Re: Enfin !!
Posté par David Anderson . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 1.
` svn diff -x '-w' ` produira un diff unifié qui ignore les changements d'indentation. Il me semble qu'il est possible de configurer son client de telle manière qu'il passe systématiquement le -w au moteur de diff interne. Par défaut, le diff est toujours un diff unifié normal, qui montre tous les changements.
A noter que la nouveauté ici est bien que le moteur de diff *interne* de Subversion supporte ces options. Il était déjà possible de dire a `svn diff` d'utiliser un logiciel de diff externe, comme GNU Diff, et lui passer des options similaires.
[^] # Re: Merge tracking
Posté par David Anderson . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 4.
Concernant le remplacement de Clearcase par Subversion, je dois être franc et te dire que ça va être difficile. Clearcase est plus, bien bien plus, qu'un simple outil de revision control. Il incorpore toute une floppée d'autres aspects du cycle de développement. De plus, son UI est très différente de tous les autres outils existants, ce qui va rendre la migration vers autre chose difficile.
Donc, je serais de l'avis de commencer, comme tu le suggères, par des petites équipes pilotes. Etudiez les problèmes de migration qu'il y a sur un petit projet, pour mieux planifier une éventuelle migration totale.
À noter également que Collabnet, l'entreprise qui est à l'origine de Subversion, propose des solutions plus complètes se basant sur Subversion, qui pourraient éventuellement remplacer plus efficacement l'intégralité de Clearcase. Disclaimer: Je ne suis pas employé de Collabnet, je n'ai jamais déployé leurs systèmes en entreprise. J'en ai simplement entendu du bien, et il est clair qu'ils rassemblent encore à ce jour une grande expertise sur Subversion, qu'aucune autre entreprise ne peut à ce jour prétendre égaler.
Si tu as besoin d'aide pour la migration, n'oublie pas la liste de diffusion users@subversion.tigris.org, ou tu trouveras peut-être d'autres gens qui ont fait des migrations depuis Clearcase. Et dans tous les cas, que ce soit un succès ou non, n'oublie pas de nous rapporter le résultat de cette étude/migration, ça nous intéresse!
[^] # Re: OpenCVS
Posté par David Anderson . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 10.
Quant à la remarque sur l'utilisation intensive du branch/merge, j'avoue ne pas comprendre, a moins que tu n'aie jamais utilisé CVS. La gestion des branches dans CVS est l'une des pires facettes de ce logiciel. J'admets, il n'y a pas encore de merge tracking intégré à Subversion, mais d'un autre coté, dans CVS non plus. C'est un affreux hack qui ne garantit en rien l'intégrité des données. Le développement du merge tracking dans Subversion avance, et en attendant, l'outil svnmerge.py implémente les trois quarts de ce qui est nécessaire pour le commun des mortels de ce coté là.
OpenCVS, sans vouloir lancer de troll, je me demande si ca servira à quiconque autre qu'OpenBSD. Rester coincé sur la compatibilité avec "l'outil d'avant" est l'erreur que CVS a fait en se basant sur RCS, et RCS sur SCCS. Ils ont trainé des erreurs de conception sur plus de 20 ans avec ce principe, et OpenBSD veut maintenant les perpétuer dans son propre projet.
Ce n'est pas pour rien à mon avis que tant de projets se détachant du code de CVS sont nés. CVS est dans l'impasse depuis 2000, mis a terre par sa compatibilité ascendante à outrance, trainant plus de 20 ans d'erreurs, refusant obstinément de changer pour préserver une compatibilité qui n'a plus lieu d'être. Le monde s'est rendu compte que c'était une impasse, et a commencé a bosser sur d'autres produits: bitkeeper dans le monde propriétaire, et une constellation d'outils dans le monde libre. Bon sang, les développeurs les plus actifs de CVS à l'époque ont déserté pour écrire Subversion, ça devrait envoyer un message clair!
Concernant les autres outils existants, moi je dis bravo. Gits, TLA, Mercurial, Darcs, Codeville, tout ca, bravo. Ce sont des projets intéressants, plus ou moins avancés, mais intéressants. Ils cherchent tous à faire avancer le monde en proposant des outils performants, et font avancer la théorie du revision control en général. Et ils n'ont pas peur de dire "Non, on ne va pas etre compatible avec le format de dépot tout à fait pourri de CVS. On va oser changer la tronche de l'interface utilisateur, parce qu'on pense pouvoir faire mieux."
Désolé de m'emporter, mais en tant que développeur et passioné d'outils de revision control, CVS m'a traumatisé, et le fait qu'on puisse en 2006 prétendre que cet outil à un avenir autre que la casse me fait voir rouge.
[^] # Re: Compatibilité ascendante
Posté par David Anderson . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 3.
Donc, ton client 1.4 peut sans problèmes communiquer avec un serveur 1.1.4. Bien entendu, les fonctionalités coté serveur seront limitées à celles présentes dans Subversion 1.1, et tu ne bénéficieras pas de quelques optimisations du protocole de communication. Mais tout devrait toujours fonctionner, sinon c'est une régression.
Le jour ou Subversion 2.0 sortira, il n'y a aucune promesse autre que "Il sera possible de passer de 1.x a 2.0 d'une façon ou d'une autre". Les clients 1.x ne pourront vraisemblablement pas communiquer avec un serveur 2.0.
[^] # Re: Bouquins sur Subversion
Posté par David Anderson . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 3.
Bref, les deux ont leur utilité. Je recommanderais également le Eyrolles à des gens cherchant une introduction à Subversion. Pour ceux qui veulent un ouvrage de référence, l'Oreilly est à préférer. Sa version originale en anglais est disponible sur le web, sous une licence creative commons: http://svnbook.red-bean.com/ .
[^] # Re: Vous devez entrer un sujet
Posté par David Anderson . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 6.
Malheureusement, lors du développement de Subversion, le XML s'était aussi infiltré dans des fichiers qui ne sont lus que localement. L'idée était de pouvoir changer incrémentalement de format aisément, et de profiter de bibliothèques de lecture/écriture déjà très développées et performantes.
L'optimisation consistant à changer le format est venue suite à un effort de rendre toute la bibliothèque de gestion de copie de travail "streamy", c'est à dire opérant le plus possible sur des flux et des transformations de ces flux, plutot que sur le modèle "tout charger, modifier, tout ecrire". Et c'est là qu'un problème du XML se manifeste: il est difficile de lire seulement une partie d'un fichier sans d'abord tout charger pour avoir le DOM.
Le nouveau format s'affranchit partiellement de ce problème. De plus, maintenant que les métadonnées de copie de travail sont stabilisées et établies, l'extensibilité que promettait le format XML n'est plus vraiment utile. Une extensibilité plus limitée nous suffira jusqu'a Subversion 2.0.
Voila pour le raisonnement derrière tout ca.
[^] # Re: Contrôle de révision.
Posté par David Anderson . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 4.
Notons néanmoins que "gestion de versions" peut induire en erreur, parce qu'on utilise souvent "version" pour parler de sorties stables d'un logiciel, plutot que les changements incrémentaux qui prennent place pendant le développement. C'est pour cela que Subversion préfère en anglais "revision control", plutot que le "version control" que CVS utilisait.
Alors, "gestion de révisions" ? Moyen encore, puisque ca peut se comprendre comme "outil pour gérer son bac". La langue française est mal fichue des fois :-)
[^] # Re: A noter
Posté par David Anderson . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 1.
# SAMSUNG YP-MT6Z
Posté par David Anderson . En réponse au journal Lecteur OGG/MP3/WMA/WAV/ASF SAMSUNG YP-U2XW. Évalué à 5.
En gros, c'est presque pareil, sauf qu'elle fait 1Go, et qu'elle est en fin de vie, donc un peu moins chère :-)
# Merci bien
Posté par David Anderson . En réponse au journal Amateur de Metal : Attention piège à cons. Évalué à 9.
Mais je suis metalleux, donc merci de l'avertissement. Je n'avais pas d'After Forever dans ma liste de courses musicales, et maintenant je sais pourquoi :-).
Pas grand chose à voir, mais je prends une seconde pour rediriger sur http://www.machinaesupremacy.com , le site de Machinae Supremacy, un groupe de SID-metal qui passe par la petite porte: diffusion d'une grosse partie de la discographie en mp3 ou ogg sur leur site, et les albums sont sortis par des contrats de distribution uniquement, ce qui leur donne le controle total de leur musique. Et bien qu'ils ne mettent pas celle-ci sous licence libre, ils sont extrêmement ouverts en ce qui concerne des autorisations de s'en servir.
Ah, et leurs albums ne sont pas protégés contre la copie. En fait, ca ne les dérange pas qu'on partage leur musique sur le net, même celle des albums. "Si ca permet à une personne qui ne nous connait pas de nous découvrir, même s'ils n'achètent quand même rien, ca nous va".
# Sous-titres
Posté par David Anderson . En réponse au journal BBC World : Documentaire sur les logiciels libres. Évalué à 2.
Ce n'est pas un truc que je dis en l'air, je suis bilingue et en vacances, donc j'ai les capacités, et, à priori, le temps d'entamer ou finir le boulot. Mais je ne connais aucun outil qui permette de sous-titrer une vidéo confortablement (ie. se balader dans le film, créer des sous-titres, les placer facilement au bon endroit dans le film...).
# FSVS
Posté par David Anderson . En réponse au journal Sauvegarde automatique des fichiers de conf. Évalué à 2.
http://fsvs.tigris.org/
[^] # Re: Bug subversion
Posté par David Anderson . En réponse au journal Développer avec Subversion, Trac et Buildbot. Évalué à 3.
Attention aussi si tu utilises 1.3.0 et pas 1.3.1, la .0 avait un autre bug au niveau du post-commit: lancer des programmes en background ne marchait pas, le client reste bloqué jusqu'a la fin de tous les programmes lancés par le script post-commit. C'est corrigé dans la 1.3.1, sortie il y a bien un mois maintenant.
Voila voila :-)