Après avoir lu la méga flame-war sur http://www.kerneltraffic.org/kernel-traffic/latest.html(...) je me pose certaines questions.
le contexte
Pour le développement du noyau Linus Torvalds a choisi un outil propriétaire non libre (BitKeeper) car il est (était ?) supérieur techniquement.
Andréa arcangeli (un autre kernel hacker) demande sur la liste de diffusion si on ne pourrait pas utiliser le logiciel libre Arch qui a fait beaucoup de progrès depuis un an.
petit résumé de la flame-war
Linus répond (assez brutalement) qu'il n'existe rien de comparable à BitKeeper.
Andrea lui indique que au vu de sa réponse il n'a pas suivi le developpement de Arch depuis au moins trois ans.
ensuite grande discussion sur la scalabilité réelle de Arch par rapport à BitKeeper.
Linus veut mettre fin à la discussion en disant qu'il choisit les outils qu'il veut pour son travail et que du moment qu'il n'impose rien aux autres on ne doit rien lui imposer (voir ci-dessous l'extrait):
Andrea, shut up.
It's not _your_ decision to make, or your decision to complain about. It's the developers decision. It was mine, Jeff's, David's, Andrew's... Not yours.
It's your decision is to not use BK. Fine. But then complaining when people decide to use the best tool available is fricking impolite. Not just to Larry, but to the people who made the choice.
You whine about BK taking rights away, but the fact is, BK is an _option_ for people to use. _YOU_ are the one trying to limit what people are supposed to do.
In short, BK isn't the problem. You are.
cela continue encore et encore....
mes questions
je suis d'accord (comme tout le monde je pense) pour reconnaitre que chacun a la liberté d'utiliser les logiciels qu'il souhaîte, même des logiciels non libres.
le problème ici est ; est-ce que ce choix fait par linus impacte d'une quelconque façon les autres developpeurs ?
il semble que oui au vu de cette reflexion faite par un autre hacker à Linus:
nobody cares what you are using privately, but your decisions as kernel maintainer have an effect on other people, may this be the patches you include in the next release or the tools you distribute them with.
Comment ça marche le dev du noyau ? les hackers puristes du libre et utilisant Arch peuvent-ils soumettre leurs patchs sans aucun problème pour inclusion dans l'arbre BitKeeper de Linus ?
Journal BitKeeper ou Arch
18
nov.
2004
# BK conçu pour Linus
Posté par ZeroHeure . Évalué à 8.
Au départ a été conçu pour les besoins de Linus, par un dev du noyau. A mon avis, ça joue beaucoup dans la tête de Linus.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: BK conçu pour Linus
Posté par mansuetus (site web personnel) . Évalué à 1.
c'est arch (je suppose) qui a été construit pour le noyau ? pourquoi cela joue en mal ?!
[^] # Re: BK conçu pour Linus
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Mais un des objectifs de Arch était de pouvoir remplacer BK pour le développement de Linux. Pour l'instant, il est encore à la traine sur un bon nombre de points.
[^] # Re: BK conçu pour Linus
Posté par chl (site web personnel) . Évalué à 2.
Tu saurais quels sont ces points a la traine ? Ou une url qui les listerait ?
[^] # Re: BK conçu pour Linus
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
* Tous les messages de log sont conservés dans l'arbre de travail, chacun dans un fichier séparé. Pour le développement de Xtla, qui est un tout petit projet par rapport à Linux, l'ensemble des fichiers de log prends 8 fois plus de place sur le disque que les sources ! Résultat, il faut de temps en temps effacer des fichiers, et on perd les traces de l'historique.
* Le mode de fonctionnement par défaut de BK, c'est que le programmeur doit dire quel fichiers il modifie (en pratique, il programme son éditeur de texte pour le faire). Résultat, la plupart des operations sur l'arbre sont en O(nombre de fichiers modifiés) et non en O(nombre total de fichiers).
* Arch utilise des expressions régulières pour classifier les fichiers. C'est très pratique, sauf que le moteur d'expression régulières n'est pas des plus efficaces, donc, il y a un assez gros problème de performances a ce niveau là.
* La réactivité de l'équipe de devs. J'ai du m'y reprendre à 3 fois pour faire accepter un patch de une ligne. Si on regarde l'historique de tla depuis la version 1.2, c'est assez drôle : Une faille de sécurité dont la correction a mis plusieurs mois à être intégrée à une release officielle, une 1.2.2rc2 qui n'est jamais devenue 1.2.2 pour cause de conflits personnels entre développeurs, le changelog entre la 1.2 et la 1.3rc2 qui se trouve du coup ridiculement petit par rapport aux mois de développement qui séparent ces deux versions. La moitié des liens du site officiel www.gnuarch.org qui pointent sur une erreur 404, ... Bref, dans l'état actuel des choses, généraliser l'utilisation de arch pour un projet de grande taille me parait bien risqué ...
# bk et linux
Posté par itstimetogo . Évalué à 3.
C'est pour l'image du libre que ce n'est pas terrible.
Pour allimenter le troll sur "je me prend pour un hacker de noyau donc je veux un outils pour hacker de noyau :
http://www.darcs.net/(...)
Qui nous fait un Bk vs Arch vs Darcs pour les hackers de noyau ?
[^] # Re: bk et linux
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: bk et linux
Posté par itstimetogo . Évalué à 3.
Un patch est un patch. Tu l'envoies à Linus et il l'applique ou pas à son arbre.
Le dernier snapshots de Linus est ici :
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/(...)
Il n'y a pas de problème de compatibilité, mais c'est plus chiant.
Si Linus utilisait Subversion et que quelqu'un veut lui "imposer" Arch, il y aurait les même désagréments.
[^] # Re: bk et linux
Posté par Edouard Gomez (site web personnel) . Évalué à 6.
Ah non, tu envoies à Linus un patch corrigeant un bug pour le 2.6.7, bug toujours présent dans le 2.6.9. Manque de bol, c'est pas synchronisé avec les derniers patchs de Linus, car le code a beaucoup changé sur la forme... bah ton patch a de fortes chances d'etre rejeté.
Donc non, le probleme d'un patch, c'est qu'il doit etre relativement synchronisé avec la version de dev. Tous les patchs ne se valent pas.
Donc comme j'explique plus bas, utiliser BitKeeper n'est pas une obligation mais permet d'etre sur de soumettre des patchs que Linus a de fortes chances de ne pas rejeter pour cause de desynchronisation avec son arbre.
>Si Linus utilisait Subversion et que quelqu'un veut lui "imposer" Arch, il y aurait les même désagréments.
Non arch et SVN ont des formats de patchsets connus, et rien n'empeche de creer des passerelles equifonctionnelles pour qu'un patchset arch soit repercuté sur le repository SVN et vice versa.
Avec BitKeeper, tu pries pour que Larry accepte de te coder la passerelle dont tu reves, et surtout comme tu connais pas ce que fait bitkeeper, tu reves pour que un patchset ne soit pas dégradé au passage. eg: BitKeeper -> CVS est un changement à perte, puisque tu n'es plus capable d'extraire un patchset particulier en raison du fait que CVS versionne par fichier et non l'arbre complet.
[^] # Re: bk et linux
Posté par itstimetogo . Évalué à 7.
T'as un snapshot quotidien de la branche Linus sur www.kernel.org !
Ce n'est pas le bout du monde de synchroniser ton patch.
> Donc comme j'explique plus bas, utiliser BitKeeper n'est pas une obligation mais permet d'etre sur de soumettre des patchs que Linus a de fortes chances de ne pas rejeter pour cause de desynchronisation avec son arbre.
Ça ne change rien. BitKeeper ou pas tu dois synchroniser ton patch.
Sans BitKeeper c'est moins pratique mais tout a fait réalisable sans grande difficulté.
Andrew Morton utilise Bk depuis peu de temps. Avant il faisait sans Bk et il en brasse des patchs.
Alan Cox n'utilise pas Bk.
etc.
[^] # Re: bk et linux
Posté par M . Évalué à 4.
Ce n'est pas le bout du monde de synchroniser ton patch.
Mieux t'as le repository cvs via "rsync rsync://rsync.kernel.org/pub/scm/linux/kernel/bkcvs/linux-2.5/"
[^] # Re: bk et linux
Posté par golum . Évalué à 1.
Clearcase <--> SVN <-> Arch <--> BK<-->Perforce<-->PVCS
Qui dit mieux ?
Bien sûr que le choix d'un outil de gestion de conf impacte une équipe et même plus, il influe sur le mode et le processus de développement.
Va essayer de faire du dev libre (massivement distribué) avec du Clearcase (si'il etait opensouce, bine sùr).
Y'en a même qui ont essayé.
http://www.netcraft.com.au/geoffrey/katie/(...)
Il n'en reste pas moins que l'auteur de Linux est Linus et qu'il a le droit de choisir avec quel outil il veut développer. Les autres s'adaptent ou s'en vont à moins qu'on lui prouve qu'Arch est vraiment mieux que Bk.
Une migration, ca se fait pas en 5 mn et en plus, il faut que les gens se forment, surtout quand on voit le design d'arch(tla) et sa complexité. La dernière fois que j'ai jeté un oeil dessus, il y'avait 3 modes pour gérer l'ajout automatique des fichiers au contrôle de version avec des cas particuliers partout, une vraie UAG.Mais on comprend que ca plaise aux fanas du s/ruby/$_/
Et comme Linus pose la question est-ce que ca tient la charge.
Il est poilu cui là ... Hein
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bk et linux
Posté par golum . Évalué à 2.
[^] # Re: bk et linux
Posté par Alvarez . Évalué à 1.
[^] # Re: bk et linux
Posté par golum . Évalué à 2.
En plus, il me parait raisonnable ce monsieur donc si les arguments pour abandonner Bk pour un autre gestionnaire de source étaient décisifs , il ne s'entêterait pas.
[^] # Re: bk et linux
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Linus est propriétaire de la marque déposée "Linux", et il est propriétaire de ses propres contributions à Linux. Or, la grande majorité du code de Linux vient de contributions extérieures, le rôle de Linus étant de s'assurer de la qualité et de l'abscence de backdoor dans le code avant de l'intégrer au noyau officiel. Donc, la grande majorité du code ne lui appartient pas.
Par contre, c'est lui le "chef de projet", et il fait bien ce qu'il veut avec Linux. Si les gens ne sont pas d'accord avec lui, ils peuvent forker, mais je crois que personne ne serait assez fou pour ça ...
[^] # Re: bk et linux
Posté par Romain Vinot . Évalué à 3.
Ce qui a comme conséquence indirecte qu'il est pratiquement absolument impossible de changer la licence de Linux de GPL à autre chose car il faudrait demander leur accord à plusieurs milliers d'individus.
Donc, non. Linus n'est pas le détenteur légitime de Linux, uniquement de ses propres lignes de code, ce qui ne doit plus faire un si grand pourcentage...
[^] # Re: bk et linux
Posté par Tonton Th (Mastodon) . Évalué à 0.
Ouiménon. Un whois linux.org n'arrive pas à me convaincre que linux.org est quelqu'un qui fait parti du monde Linux. Surtout quand tu regarde le site du type: http://www.invlogic.com/(...)
Tu as donc PERDU.
[^] # Re: bk et linux
Posté par golum . Évalué à 2.
A tout le monde
man os ????
man GPL
moi qui croyais que les dev libres faisaient ca pour la gloire , si ils ont même pas le droit de voir figurer leur nom, ils seront tous canonisés
Allelluia
[^] # Re: bk et linux
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Bien sur que si, ils ont leur nom !
Tu télécharges les sources de Linux, et tu regardes le fichier CREDITS à la racine de l'arbre. (Il y a du monde !!)
[^] # Re: bk et linux
Posté par allcolor (site web personnel) . Évalué à 1.
[^] # Re: bk et linux
Posté par thomas . Évalué à 1.
# Pourquoi ca impacte tous les devs...
Posté par Edouard Gomez (site web personnel) . Évalué à 10.
Le principal point à prendre en considération est que linus est celui qui pour l'instant maintient la branche principale, les autres devs maintiennent des branches secondaires et donc l'une des taches les plus courantes pour ces developpeurs, c'est de se resynchroniser avec la branche principale sous peine de se rajouter de la charge de travail à devoir réadapter leurs patchs par pans entiers.
Or si linus n'expose ses derniers changements que via BitKeeper, les autres devs sont obligés d'utiliser BitKeeper... ce qui en soit ne serait pas ultra choquant même s'il est non libre. LE plus gros problème est la license de BitKeeper, qui non content d'etre non libre (ce qui deja réduit la liberté des hackers noyaux qui doivent l'utiliser pour se resynchroniser), elle impose que tout utilisateur renonce à travailler sur des projets pouvant concurrencer BitKeeper. Donc tu renonces au droit de modifier/acceder aux sources de BitKeeper, mais en plus tu renonces carrement à participer au developpement d'un gestionnaire de source.
Donc le choix de Linus n'impacte pas seulement comment les autres développeurs doivent travailler (via BitKeeper pour ne pas morfler), il réduit de facon indirecte les options de travail d'un dévéloppeur noyau. Donc prend n'importe quel dev noyau, qui aime CVS/Arch/SVN/Darcs/Monotone, bah s'il respecte la license, il aurait pas le droit de contribuer activement a ces projets.
PS: ce genre de clause doit surement etre illégale en France, un peu comme la clause de non concurrence d'un contrat de travail doit etre limité dans le temps, dans l'espace et le domaine d'activité, ou bien compensée financièrement.
PPS: la clause super tordue de BitKeeper n'est la que pour la version Freeware dispo pour tout un chacun, la version payée ne l'integre pas il me semble.
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par William Steve Applegate (site web personnel) . Évalué à 6.
Il y a tout de même une passerelle BK -> CVS, si j'ai bonne mémoire : [http://lwn.net/Articles/25203/(...)]. J'ai même cru ouïr quelque chose à propos d'une passerelle vers SubVersion, mais je n'en jurerais pas.
> LE plus gros problème est la license de BitKeeper, qui […] impose que tout utilisateur renonce à travailler sur des projets pouvant concurrencer BitKeeper
Larry McVoy pense que, si quelqu'un veut écrire un projet concurrent au sien avec son soft, il n'a qu'à le payer (comme tu l'indiques, la version commerciale n'a pas cette restriction). On peut discuter longtemps pour savoir si cette attitude est injuste, immorale, etc., mais en fin de compte, je trouve l'affaire BitKeeper un peu hors de proportions. Linus semble apprécier M. McVoy et son logiciel, c'est son droit. De toute manière, si vraiment ça agace trop de monde, tout ce que Linus va gagner à s'obstiner, c'est des forks hostiles, des devs qui vont s'en aller rejoindre d'autres projets, etc. Si ça ne se produit pas, à mon avis c'est qu'en fin de compte les gens arrivent à travailler sans gros problèmes, BK ou pas BK.
Envoyé depuis mon PDP 11/70
[^] # dans une réponse d'andrea
Posté par modr123 . Évalué à 3.
il ne veut pas develloper un produit concurrent avec BK , mais le fait de l'utiliser BK l'empeche de develloper un produit concurrent
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par M . Évalué à 2.
Elle ne marche plus a cause des pn de secu introduit par cvs.
Par contre du peut recuperer le repository cvs via rsync :
rsync rsync://rsync.kernel.org/pub/scm/linux/kernel/bkcvs/linux-2.5/
[^] # Précision
Posté par Seazor . Évalué à 3.
Elle interdit quoi exactement ?
scenar 1) Utiliser BK pour n'importe quel projet à partir du moment ou on bosse sur un soft concurrent.
scenar 2) Utiliser BK pour gérer le dev d'un concurrent.
Avis perso :
Si c'est le 1, ca mérite qu'on discute autour de cette clause.
Si c'est le 2, c'est pas bien grave et ca ne vaut pas tout ce foin.
[^] # Re: Précision
Posté par jmf . Évalué à 4.
[^] # Re: Précision
Posté par golum . Évalué à 6.
Chez Bk, ils font déjà l'effort de proposer une version gratuite pour le dev de projet libres. La clause tordue en question qui refuse d'heberger un projet concurrent ne me parait pas intolérable. Faut quand même pa se tirer une balle dans le pied et y faut bien vivre.
En plus cette clause, elle est vachement restrictive hein. Si on fait le compte des projets libre de gestionnaires de source il y a plethore par rapport à la masse de projets actuelle.
En plus, le premier challenge des ces outils c'est bien l'autohosting , alors vraiment vous chipotez.
Ca me rappelle le super débat sur la license Qt de Windows, mais ils ont le droit eux parce que c'est GPL partout ailleurs.
Tiens des gestionnaires de sources, y'en a plein qui valent bien Arch
et le harcèlement envers Linus ca finit par ressemblr à du fanatisme.
Jetez un coup d'oeil à ceux là et pour les fans de SCM distribués allez voir plutôt monotone et darcs ou svk (version distribuée de SVN)
darcs
http://abridgegame.org/darcs/(...)
monotone
http://www.venge.net/monotone/(...)
svk
http://svk.elixus.org/(...)
openCM
http://www.opencm.org/(...)
codeville
http://codeville.org/(...)
vesta
http://www.scooter.cx/vestaweb/(...)
http://research.compaq.com/SRC/vesta/(...)
aegis
http://aegis.sourceforge.net/(...)
stellation
http://www.eclipse.org/stellation/(...)
MetaCvs
http://users.footprints.net/~kaz/mcvs.html(...)
Source Jammer
http://sourceforge.net/projects/sourcejammer/(...)
Superversion (tout simple quand on veut faire son projet dans son coin)
http://www.superversion.org/(...)
et quelques autres plus ou moins actifs
http://sourceforge.net/projects/cbe/(...)
http://sourceforge.net/projects/cryptognome/(...)
http://sourceforge.net/projects/bfre/(...)
http://sourceforge.net/projects/xvcs/(...)
http://sourceforge.net/projects/jibe/(...)
http://sourceforge.net/projects/jrms/(...)
http://sourceforge.net/projects/jvvs/(...)
http://sourceforge.net/projects/vvs/(...)
Ca en fait des projets evincés et mecontents
Bonne pioche
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par golum . Évalué à 2.
Donc tu renonces au droit de modifier/acceder aux sources de BitKeeper, mais en plus tu renonces carrement à participer au developpement d'un gestionnaire de source.
Là , j'ai un doute:
1/ les developpeurs kernel qui participent en plus au dev d'un projet de gestionnaire de source ne doivent pas être légion
2/ la clause empêche que le projet de gestionnaire auquel ils participeraient soit hébergé sou Bk, mais il pourraient toujours utiliser Bk pour participer au dev du kernel
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par golum . Évalué à 1.
les clauses en question
(d) No free use for competitors: Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a product which contains substantially similar capa- bilities of the BitKeeper Software, or, in the reasonable opinion of BitMover, competes with the BitKeeper Software.
(e) No combination with competing products: Inclusion of the BitKeeper Software for use with a system having substan- tially similar capabilities of the BitKeeper Software requires prior written permission from BitMover.
Ca ne précise pas qu'on ne peut pas utiliser Bk pour Linux si on on developpe un gestionnaire concurrent.
Ce qu'il ne veulent pas, c'est heberger gratuitement un projet concurrent. Ca parait humain.
Et même si c'était le cas je pense qu'il suffirait de leur demander la permission ou dans le pire des cas on prend une licence payante. Et on veut bien se cotiser pour la payer au gars en question.
Quand on voit ce qu'on récolté l'équipe Firefox ca devrait pas être un pb.
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par Christophe Fergeau . Évalué à 2.
« (d) No free use for competitors: Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a product which contains substantially similar capa- bilities of the BitKeeper Software, or, in the reasonable opinion of BitMover, competes with the BitKeeper Software. »
C'est écrit où que la seule restriction, ça concerne l'hébergement d'un project concurrent dans un repository bitkeeper si t'utilise la version gratuite ? De la façon dont je comprends cette licence (j'ai pas lu tout la licence, donc c'est peut être clarifié autre part), qqu'un qui bosserait dans la boîte qui développe ClearCase par exemple n'a pas le droit d'utiliser la licence gratuite de BitKeeper pour faire du développement noyau même s'il travaille sur un projet n'ayant aucune relation avec ClearCase.
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par golum . Évalué à 1.
Mais à mon avis dans leur esprit c'est plutôt héberger un projet concurrent qui les gêne
et je pense qu'il n'imaginaient pas que quelqu'un puisse bosser sur deux projets en même temps. C'est un flou dans la license qu'ils n'avaient pas prévu.
c'est pourquoi j'avais précisé
Et même si c'était le cas je pense qu'il suffirait de leur demander la permission
parce que moi non plus j'ai pas envie de me palucher à lire toute la license.
J'ai déjà pris la peine de la rechercher les clauses qui me paraissaient coller alors à minuit tu comprendras que je m'embrouille .
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
En particulier, si tu développe un concurent à BK, tu ne peux pas récupérer BK gratuitement pour voir comment ça marche et reprendre des idées.
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par mickabouille . Évalué à 2.
Il n'avais pas le droit d'utiliser bk pour le devel linux s'il contribuait à arch (y compris sans utiliser bk).
Faudrait que je retrouve le message.
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par golum . Évalué à 3.
La question est de savoir si cette clause est volontaire,
si des kernels developpeur ont essuyé un refus
ou s'il est possible de negocier avec Bk peut-être, tout simplement parce qu'il y une ambiguité dans leur license.
Est-ce quelqu'un s'est adressé à eux en expliquant, je développe un gestionnaire concurrent mais je travaille également sur un projet libre
ai-je le droit d'utilser Bk sur ce projet ou peut on négocier ?
Je me rabâche, mais c'est important car là on peut mesurer s'ils ont des pratique anti-concurrentielles.
Si vraiment la clause est appliquée à la lettre ils sont critiquables.
En attendant je préfère leur accorder le bénéfice du doute.
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par tinodeleste . Évalué à 4.
http://www.bitkeeper.com/Company.Founders.html(...)
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par Christophe Fergeau . Évalué à 5.
[^] # Re: Pourquoi ca impacte tous les devs...
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
> gestionnaire de source ne doivent pas être légion
1) à peut près toutes les distributions Linux
2) plusieurs contributeurs de Arch sont aussi contributeurs de Linux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.