Dire qu'un programme est GPL est un abus de langage. La GPL n'est pas une propriété du programme, mais c'est une licence, qui s'applique au moment de la distribution.
Donc, dans un premier temps, tu peux te demander si tu es propriétaire du code. C'est indépendent de la GPL, et ça dépends juste des loies sur la propriété intellectuelle (qui disent comme le précisent d'autres commentaires, que tu es propriétaire si c'est toi qui a écrit le code, ou si tu l'as racheté, en gros), et après, tu peux réfléchir si tu as la possibilité de l'obtenir ou de le distribuer sous GPL.
Le commit se fait sur la branche distante, de manière atomique. C'est à dire que soit ta branche est à jour, et le commit se fait, soit tu n'es pas à jour, et on te demande de faire un update.
Avec les autres que je connais, tu peux faire presque ça, en vérifiant avant que tu es à jour, mais il y a toujours une fenêtre de temps pendant laquelle quelqu'un d'autre peut faire un commit. Bref, avec bzr, tu peux, si tu veux, t'assurer que tu n'auras jamais un historique non-linéaire.
Mais la grosse différence, c'est surtout la simplicité de l'interface utilisateur. En une commande, tu dis que « update » doit aller chercher à une URL, et que « commit » doit mettre tes changements au même endroit, ... (et en bonnus, les utilisateurs de CVS/SVN n'ont pas besoin de changer tout de suite leur modèle de pensée).
Le gros point commun de git par rapport à Bazaar, c'est les perfs. Sur un projet pas trop imposant, à peu près toutes les commandes de git sont littéralement instantanées, c'est vraiment appréciable. Bazaar a beaucoup progressé, mais il reste du chemin.
Mais en fait, perso, ce qui me donne envie de quitter bzr, c'est surtout que je n'ai aucune confiance en Canonical pour la maintenance future du logiciel. Ils m'ont déjà fait perdre des dizaines d'heures en me laissant bosser sur Bazaar 1 avant de fouttre mon boulot à la poubelle, maintenant, ils ré-écrivent l'histoire en laissant plus ou moins entendre que le mot Bazaar a toujours désigné bzr, et que l'ancien s'appelait Baz [http://bazaar-vcs.org/Branding]. Maintenant, ils jouent aux marqueteux avec les numéros de versions (passage de 0.18 à 0.90, parce que 0.19, ça faisait pas assez bien). Les gros projets (Mozilla, Linux, OpenSolaris, X.org, ...) migrent petit à petit vers des solutions décentralisées, et pour l'instant, bzr n'a pas réussi à en convaincre un vraiment important. Bref, git et Mercurial me paraissent plus sûrs niveau pérénité.
Pour travailler en centralisé avec git, ce que je fais, c'est que je met un « git push » dans le hook « post-commit ». C'est pas tout à fait équivalent, mais ça ressemble à ce que fait « bzr bind ».
Le principe de git (quand tu t'apprête à faire un commit sans -a), c'est que tu as l'« index », ou « staging area », qui est l'endroit où tu met ce que tu vas commiter. Pour mettre des choses dedans, tu fais « git add fichier ».
Exemple bête : tu veux faire un commit selectif sur les fichiers A.txt, B.txt, mais pas les autres :
Dans ce cas, tu aurais pu faire la même chose avec
$ git commit -m "..." A.txt B.txt
mais c'est assez pratique aussi de pouvoir prendre ton temps pendant que tu sélectionne les fichiers que tu veux. Par exemple, juste avant de commiter, tu peux faire « git diff » pour voir ce que tu as dans ton arbre de travail mais pas dans l'index, et « git diff --cached » pour voir ce que tu vas vraiment commiter. Avec des outils comme « git add --interactive » ou « git gui », tu peux même faire un commit selectif au niveau des portions de patch.
Avec la plupart des gestionnaires de versions, tu as des interfaces graphiques pour faire des commits selectifs. Tu sélectionne un certain nombre de fichiers, et tu as un bouton « commit » quelque part. Tu peux voir l'index comme ce système de selection de fichiers, mais c'est stoqué sur le disque, donc persistant entre deux appels.
Ceci dit, les commit selectifs, il faut s'en méfier. Ça veut dire que ce que tu commites n'a probablement jamais existé en temps que tel sur le disque, donc que ça n'a jamais vraiment été testé. Mais même pour des commits non-selectifs, ça peut être pratique. Par exemple, tu as un paquet de changement dans ton arbre de travail, et tu veux vérifier que tu n'as pas fait de conneries. « git diff » te montre ce qu'il te reste à vérifier, et en faisant « git add », tu valides le changement. A ce moment, tu ne fais commit que quand « git diff » ne dit plus rien (« git status » te donne la même info sous une autre forme).
C'est assez pénible au départ, mais on s'y fait, et après quelques semaines d'utilisation, c'est le système des autres outils que je trouve bizare ;-).
Niveau perfs, git et mercurial se valent à peu près. git est un peu plus rapide une fois que le cache est "chaud", alors que Mercurial prends en compte les accès disque, donc, est un peu plus rapide pour le premier accès à des fichiers.
L'import du noyau Linux dans Mercurial, ça n'aurait pas pris quelques années, c'est fait, et maintenu en synchro : http://www.kernel.org/hg/linux-2.6/
Finalement, Mercurial et Git sont assez proches. Comme différences, je dirais :
* Gestion des renomages : Mercurial enregistre les renomages au moment du commit (copy + delete), git les detecte après coup.
* Git est écrit en C, concu pour être scriptable en shell facilement, Mercurial est écrit en Python, conçu pour être extensible via des plugins
* hg est conçu pour être simple (au niveau de l'interface utilisateur, mais aussi un code source petit : 32000 lignes de python), git est conçu pour être puissant et flexible. Si c'est simple, tant mieux, mais ça n'est pas prioritaire.
* "hg commit" prends le contenu des fichiers au moment où on fait le commit. "git commit" prends le contenu des fichiers au moment où on a fait un "git add" pour la dernière fois. C'est très puissant, par exemple pour faire des commits partiels, mais assez déroutant au début (c'est le fameux "index").
* Git a un format de stoquage remarquablement compact (un facteur 10 par rapport à Subversion sur certains projets, par exemple, le repository Linux fait 174Mo avec git, et 463 avec hg), mais il n'est pas utilisé par défaut. Il faut lancer "git gc" de temps en temps pour recompresser le repository.
* "git blame" a quelque chose qu'à ma connaissance personne d'autre ne fait : il detecte les déplacements de code à l'intérieur et à l'extérieur du fichier. Donc, il est capable de dire que telle ligne du fichier toto.c à été au départ commité dans le fichier titi.c à telle ou telle date, ...
Mais :
* Les deux sont très rapides
* Les deux utilisent des checksums pour identifier les révisions (hérités de monotone)
* Les deux fonctionnent avec un repository par arbre de travail, et des push/pull/merge (hérités de BitKeeper paraît-il)
* Les deux ont un moyen de gérer des files de patchs (mq et stgit, mais je connais pas bien)
* Les deux ont une commande pour réappliquer une branche sur un autre (rebase et transplant)
...
Bref, il y a des différences entre les deux, mais c'est difficile de dire si l'un est meilleur que l'autre. Je crois que c'est surtout une question de goût. Perso, je n'ai pas encore fait mon choix définitif.
C'est encore loin d'être parfait, et globalement, on sent que git a été fait par des très bons codeurs, mais bien moins bons pour l'interface utilisateur et la doc (il y a des tas de cas où git montre à l'utilisateur des trucs qui devraient être des détails d'implémentation). Mais ça s'améliore vraiment.
les applies qui utilisent gconf, c'est pas juste le window-manager de Gnome. C'est toutes les applies gnome, et d'autres (firefox par exemple). Donc, installer E17, ça va pas changer grand chose à la question to-gconf-or-not-to-gconf ...
C'est pas tellement une question d'être pieds et point liés avec MS, je crois qu'ils veulent surtout éviter que le pekin de base achète un truc avec Ubuntu, et qu'il rale après parce que Photoshop et MS Word ne s'installent pas dessus. Je serais à leur place, je mettrais aussi un filtre pour éviter que les gens ne cliquent sur Ubuntu par erreur.
Par ailleurs, tu « oublies » quand même de citer la suite :
L'open source est généralement plus fiable et plus flexible, et bénéficie de mises à jour et correctifs plus rapides, le tout à moindre prix.
Il faut dire aussi que google a amélioré énormément la qualité des images ces derniers mois. Pour Grenoble par exemple, la dernière fois que j'avais regardé, google avait une résolution toute pourrie, et là, je vois les piétons, et les voitures de plusieurs pixels de large ...
* la Ms-RL est clairement non-opensource au sens de l'OSI : elle ne permet déjà pas la clause 1-redistribution
Le texte de la licence dit :
the Licensor grants you a non-transferable, non-exclusive, worldwide, royalty-free copyright license to reproduce the software for reference use.
C'est peut-être le « non-transferable » qui pose problème ? Enfin, si j'ai bien compris, c'est une licence du type creative common ND (pas libre, mais c'est la modification qui pose problème, pas la distribution).
* la Ms-PL est aussi non-opensource au sens de l'OSI : elle restreint à l'utilisation du programme sur Windows
Le texte de la licence ne mentionne pas Windows. Visiblemement, il y a confusion avec la licence « Microsoft Limited Permissive License ».
Euh, tu crois sérieusement que les progrès en puissance de calcul vont permettre à n'importe quelle application de tourner sur une seule machine ?
Ça fait quand même quelques dizaines d'années qu'on progresse à peu près à la même vitesse (loi de Moore), et les gens qui nous promettent que tous nos problèmes seront résolus l'année prochaine ne sont quand même pas terriblement crédibles (640k should be enough for everyone ...).
Pour rappel, des grosses applies web (google & co), ce sont des clusters (pas du genre OpenMosix, mais clusters quand même) où on compte les machines par dizaines de milliers ...
En l'occurence, Apple a racheté la propriété intellectuelle du code, et a partiellement changé la licence (c'est maintenant une GPL + exception pour eux).
[^] # Re: N'importe quoi...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Dell propose des logiciels libres.... Évalué à 10.
Chaque élément que tu achète dans le pack est disponible individuellement par ailleurs, et il est même gratuit.
Ce que tu payes, c'est le fait d'avoir du tout-en-un. Si ça ne te va pas, tu prends les trucs individuels.
[^] # Re: Version non "open source"
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le propriétaire de Snort achète ClamAV. Évalué à 7.
Donc, dans un premier temps, tu peux te demander si tu es propriétaire du code. C'est indépendent de la GPL, et ça dépends juste des loies sur la propriété intellectuelle (qui disent comme le précisent d'autres commentaires, que tu es propriétaire si c'est toi qui a écrit le code, ou si tu l'as racheté, en gros), et après, tu peux réfléchir si tu as la possibilité de l'obtenir ou de le distribuer sous GPL.
[^] # Re: "restreint et payant"
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le propriétaire de Snort achète ClamAV. Évalué à 4.
Payant, c'est possible en opensource.
Restreint, non. Si tu as accès au soft une fois, tu as le droit de l'utiliser éternellement. Cf. point 6 de la définition.
[^] # Re: bazaar
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sondage pour utilisateurs de git. Évalué à 2.
[^] # Re: bazaar
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sondage pour utilisateurs de git. Évalué à 3.
Avec bzr, tu peux faire quelque chose comme :
$ bzr checkout bzr+ssh://je-sais.pas/ou rep
$ cd rep
hack hack hack
$ bzr commit -m foo
Le commit se fait sur la branche distante, de manière atomique. C'est à dire que soit ta branche est à jour, et le commit se fait, soit tu n'es pas à jour, et on te demande de faire un update.
Avec les autres que je connais, tu peux faire presque ça, en vérifiant avant que tu es à jour, mais il y a toujours une fenêtre de temps pendant laquelle quelqu'un d'autre peut faire un commit. Bref, avec bzr, tu peux, si tu veux, t'assurer que tu n'auras jamais un historique non-linéaire.
Mais la grosse différence, c'est surtout la simplicité de l'interface utilisateur. En une commande, tu dis que « update » doit aller chercher à une URL, et que « commit » doit mettre tes changements au même endroit, ... (et en bonnus, les utilisateurs de CVS/SVN n'ont pas besoin de changer tout de suite leur modèle de pensée).
[^] # Re: bazaar
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sondage pour utilisateurs de git. Évalué à 2.
Mais en fait, perso, ce qui me donne envie de quitter bzr, c'est surtout que je n'ai aucune confiance en Canonical pour la maintenance future du logiciel. Ils m'ont déjà fait perdre des dizaines d'heures en me laissant bosser sur Bazaar 1 avant de fouttre mon boulot à la poubelle, maintenant, ils ré-écrivent l'histoire en laissant plus ou moins entendre que le mot Bazaar a toujours désigné bzr, et que l'ancien s'appelait Baz [http://bazaar-vcs.org/Branding]. Maintenant, ils jouent aux marqueteux avec les numéros de versions (passage de 0.18 à 0.90, parce que 0.19, ça faisait pas assez bien). Les gros projets (Mozilla, Linux, OpenSolaris, X.org, ...) migrent petit à petit vers des solutions décentralisées, et pour l'instant, bzr n'a pas réussi à en convaincre un vraiment important. Bref, git et Mercurial me paraissent plus sûrs niveau pérénité.
Pour travailler en centralisé avec git, ce que je fais, c'est que je met un « git push » dans le hook « post-commit ». C'est pas tout à fait équivalent, mais ça ressemble à ce que fait « bzr bind ».
[^] # Re: git et mercurial
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sondage pour utilisateurs de git. Évalué à 3.
Exemple bête : tu veux faire un commit selectif sur les fichiers A.txt, B.txt, mais pas les autres :
$ git add A.txt
$ git add B.txt
$ git commit -m "commit selectif machinbidule"
Dans ce cas, tu aurais pu faire la même chose avec
$ git commit -m "..." A.txt B.txt
mais c'est assez pratique aussi de pouvoir prendre ton temps pendant que tu sélectionne les fichiers que tu veux. Par exemple, juste avant de commiter, tu peux faire « git diff » pour voir ce que tu as dans ton arbre de travail mais pas dans l'index, et « git diff --cached » pour voir ce que tu vas vraiment commiter. Avec des outils comme « git add --interactive » ou « git gui », tu peux même faire un commit selectif au niveau des portions de patch.
Avec la plupart des gestionnaires de versions, tu as des interfaces graphiques pour faire des commits selectifs. Tu sélectionne un certain nombre de fichiers, et tu as un bouton « commit » quelque part. Tu peux voir l'index comme ce système de selection de fichiers, mais c'est stoqué sur le disque, donc persistant entre deux appels.
Ceci dit, les commit selectifs, il faut s'en méfier. Ça veut dire que ce que tu commites n'a probablement jamais existé en temps que tel sur le disque, donc que ça n'a jamais vraiment été testé. Mais même pour des commits non-selectifs, ça peut être pratique. Par exemple, tu as un paquet de changement dans ton arbre de travail, et tu veux vérifier que tu n'as pas fait de conneries. « git diff » te montre ce qu'il te reste à vérifier, et en faisant « git add », tu valides le changement. A ce moment, tu ne fais commit que quand « git diff » ne dit plus rien (« git status » te donne la même info sous une autre forme).
C'est assez pénible au départ, mais on s'y fait, et après quelques semaines d'utilisation, c'est le système des autres outils que je trouve bizare ;-).
[^] # Re: git et mercurial
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sondage pour utilisateurs de git. Évalué à 7.
Niveau perfs, git et mercurial se valent à peu près. git est un peu plus rapide une fois que le cache est "chaud", alors que Mercurial prends en compte les accès disque, donc, est un peu plus rapide pour le premier accès à des fichiers.
L'import du noyau Linux dans Mercurial, ça n'aurait pas pris quelques années, c'est fait, et maintenu en synchro : http://www.kernel.org/hg/linux-2.6/
Finalement, Mercurial et Git sont assez proches. Comme différences, je dirais :
* Gestion des renomages : Mercurial enregistre les renomages au moment du commit (copy + delete), git les detecte après coup.
* Git est écrit en C, concu pour être scriptable en shell facilement, Mercurial est écrit en Python, conçu pour être extensible via des plugins
* hg est conçu pour être simple (au niveau de l'interface utilisateur, mais aussi un code source petit : 32000 lignes de python), git est conçu pour être puissant et flexible. Si c'est simple, tant mieux, mais ça n'est pas prioritaire.
* "hg commit" prends le contenu des fichiers au moment où on fait le commit. "git commit" prends le contenu des fichiers au moment où on a fait un "git add" pour la dernière fois. C'est très puissant, par exemple pour faire des commits partiels, mais assez déroutant au début (c'est le fameux "index").
* Git a un format de stoquage remarquablement compact (un facteur 10 par rapport à Subversion sur certains projets, par exemple, le repository Linux fait 174Mo avec git, et 463 avec hg), mais il n'est pas utilisé par défaut. Il faut lancer "git gc" de temps en temps pour recompresser le repository.
* "git blame" a quelque chose qu'à ma connaissance personne d'autre ne fait : il detecte les déplacements de code à l'intérieur et à l'extérieur du fichier. Donc, il est capable de dire que telle ligne du fichier toto.c à été au départ commité dans le fichier titi.c à telle ou telle date, ...
Mais :
* Les deux sont très rapides
* Les deux utilisent des checksums pour identifier les révisions (hérités de monotone)
* Les deux fonctionnent avec un repository par arbre de travail, et des push/pull/merge (hérités de BitKeeper paraît-il)
* Les deux ont un moyen de gérer des files de patchs (mq et stgit, mais je connais pas bien)
* Les deux ont une commande pour réappliquer une branche sur un autre (rebase et transplant)
...
Bref, il y a des différences entre les deux, mais c'est difficile de dire si l'un est meilleur que l'autre. Je crois que c'est surtout une question de goût. Perso, je n'ai pas encore fait mon choix définitif.
[^] # Re: C'est fait :)
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sondage pour utilisateurs de git. Évalué à 4.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.(...)
et beaucoup de pages de man.
C'est encore loin d'être parfait, et globalement, on sent que git a été fait par des très bons codeurs, mais bien moins bons pour l'interface utilisateur et la doc (il y a des tas de cas où git montre à l'utilisateur des trucs qui devraient être des détails d'implémentation). Mais ça s'améliore vraiment.
[^] # Re: 20 aout
Posté par Matthieu Moy (site web personnel) . En réponse au journal RMS aurait disparu?. Évalué à 10.
[^] # Re: 20 aout
Posté par Matthieu Moy (site web personnel) . En réponse au journal RMS aurait disparu?. Évalué à 10.
Ne surtout pas sous-estimer la capacité de RMS à coder Emacs dans n'importe quelles conditions...
http://matthieu.moy.free.fr/Belur-Halebid/pages/dsc02942.jpg(...)
(réalisé sans trucage)
# Réchauffé ...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Visionnaire du 21 ième Siècle. Évalué à -3.
[^] # Re: Dell cacherait ses options?
Posté par Matthieu Moy (site web personnel) . En réponse au journal Dell promeut Linux Ubuntu (enfin presque). Évalué à 4.
http://www.dell.fr
-> Grand public
-> PC portables
-> Ubuntu Linux
Et hop, ça donne :
[^] # Re: mon super programme !
Posté par Matthieu Moy (site web personnel) . En réponse au journal Votre journal. Évalué à 2.
J'ai demandé ça à un étudiant à un exam oral, il a pas été capable de me le sortir ;-).
[^] # Re: hein ? La Cathédrale ou le Bazar ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sortie de Gconf-Cleaner 0.0.3. Évalué à 6.
# En même temps ...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Dell promeut Linux Ubuntu (enfin presque). Évalué à 10.
Par ailleurs, tu « oublies » quand même de citer la suite :
[^] # Re: géoportail meilleur ???
Posté par Matthieu Moy (site web personnel) . En réponse au journal Geoportail 3d (et amélioration du site). Évalué à 3.
[^] # Re: Jamais Content
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Microsoft irait-il plus loin dans l'open source ?. Évalué à 1.
[^] # Re: NdM ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Microsoft irait-il plus loin dans l'open source ?. Évalué à 3.
The terms "reproduce," "reproduction" and "distribution" have the same meaning here, as under U.S. copyright law.
(damned, je suis pas encore près à devenir juriste ;-) ).
[^] # Re: NdM ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Microsoft irait-il plus loin dans l'open source ?. Évalué à 1.
Par contre, là où je suis pas clair, c'est si la personne a qui tu distribue a encore le droit de redistribuer.
[^] # Re: NdM ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Microsoft irait-il plus loin dans l'open source ?. Évalué à 1.
1. Definitions
The terms "reproduce," "reproduction" and "distribution" have the same meaning here as under U.S. copyright law.
# NdM ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Microsoft irait-il plus loin dans l'open source ?. Évalué à 1.
* la Ms-RL est clairement non-opensource au sens de l'OSI : elle ne permet déjà pas la clause 1-redistribution
Le texte de la licence dit :
the Licensor grants you a non-transferable, non-exclusive, worldwide, royalty-free copyright license to reproduce the software for reference use.
C'est peut-être le « non-transferable » qui pose problème ? Enfin, si j'ai bien compris, c'est une licence du type creative common ND (pas libre, mais c'est la modification qui pose problème, pas la distribution).
* la Ms-PL est aussi non-opensource au sens de l'OSI : elle restreint à l'utilisation du programme sur Windows
Le texte de la licence ne mentionne pas Windows. Visiblemement, il y a confusion avec la licence « Microsoft Limited Permissive License ».
[^] # Re: .
Posté par Matthieu Moy (site web personnel) . En réponse au journal Arrêt du projet OpenMosix. Évalué à 7.
Ça fait quand même quelques dizaines d'années qu'on progresse à peu près à la même vitesse (loi de Moore), et les gens qui nous promettent que tous nos problèmes seront résolus l'année prochaine ne sont quand même pas terriblement crédibles (640k should be enough for everyone ...).
Pour rappel, des grosses applies web (google & co), ce sont des clusters (pas du genre OpenMosix, mais clusters quand même) où on compte les machines par dizaines de milliers ...
[^] # Re: Ben et les contributeurs ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Apple rachète CUPS. Évalué à 3.
[^] # Re: Pour la fonction SIN
Posté par Matthieu Moy (site web personnel) . En réponse au journal Une nouvelle raison de refuser Microsoft openXML. Évalué à 4.
Et tu as quoi comme définition « utilisable en l'état » pour définir sin et cos ?
De toutes façons, j'ai une mauvaise nouvelle pour toi : en dehors du calcul symbolique, quand tu calcules sin(x), c'est toujours une approximation ...