Développeur : Linus développe un remplaçant original à BitKeeper
Posté par Colin Leroy (page perso, ). Modéré le 12 avril 2005.
Linus Torvalds a passé ces derniers jours à tester différentes solutions SCM [source code management] et a commencé à écrire un content tracker nommé git pour remplacer BitKeeper. D'autres développeurs ont contribué des idées et du code à ce petit outil, au point qu'au bout de moins d'une semaine, il est prêt pour un test grandeur nature. Andrew Morton vient d'envoyer un email titré "Incoming" sur la linux-kernel mailing-list, suivi de deux centaines de patches, qui vont être intégrés à l'arbre officiel par l'intermédiaire de git.
Espérons que les développeurs du noyau pourront être aussi efficaces avec git qu'ils l'étaient avec BitKeeper. La rapidité de ce changement d'outils laisse à penser que l'on peut être optimiste à ce sujet.
![[en]](../images/en.png)
Le README de Git (2436 hits)-
"Incoming", le mail de Andrew Morton (1377 hits)
![[fr]](../images/fr.png)
DLFP: Bitkeeper: plus de version gratuite (1323 hits)
> Lire la dépêche (77 commentaires, moyenne: 4).
Vous avez demandé le commentaire #560723.
Run by 
Cette page a été générée par Templeet en 0.1401s (dont 0.014 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
L'info sur kerneltrap
http://kerneltrap.org/node/4982(...)
RIen de bien transcendant : l'échange sur la liste du noyau, et deux trois commentaires qui valent la peine qu'on les lise.
[^]Re: L'info sur kerneltrap
J'ai un peu suivi l'evolution du developpement de GIT sur la LKML... et de mon point de vue, je crois que Linus Torvalds ne semble pas regarder plus loin que ses besoins immediats.
Il a à peine évoquer les raisons qui l'ont poussé à rejeter Monotone. N'a pas cité Arch, ni Darcs. Je parlerai principalement d'arch/tla ou bazaar car c'est le SCM que j'utilise depuis plus de 2 ans, mais j'ai aussi regardé du coté de Monotone recemment, voir du tres tres jeune bazaar-ng (plus proche de monotone dans sa gestion du tracking des sources).
Ayant utilisé arch/tla, je sais que ce n'est pas une solution viable aujourd'hui, car tla (ou bazaar) se trainent des problemes de conception qui remontent au prototype arch/larch codé à coup de sh/gawk/gnutar/gnudiff par Tom Lord qui cherchait à valider les idées fondatrices de son futur outils de versionning. Je ne donnerai ici que quelques examples:
- le gachi monumental d'inode pour l'historique (qui devient un cauchemar sur des FS comme ext2/3, et est un peu pres vivable sur des FS comme ReiserFS qui merge les petits fichiers directement dans l'inode).
- des conventions de nommage qui sont bien loin de toutes les habitudes
- une CLI trop centrée autour du design interne du code et pas assez orienté user (c'est ce que tente de reparer bazaar)
- une redondance monstre dans le suivi des patchs mergés (c'est pas optimal, mais ca marche)
- des doublons dans les possibilités laissées a l'utilisateur pour avoir un tla efficace (pristines trees hardlinkés, revision libraries...)
- une documentation qui se ne couvre meme pas tout car le dev de tla a connu une periode tres riche et la doc n'a jamasi suivi).
Vu comme ça, arch/tla ou bazaar peuvent sembler bien nuls, mais en fait pour des projets de taille raisonnable (pas un noyau linux en somme), c'est largement suffisant à condition de s'imposer quelques restrictions sur sa gestion des archives. C'est pour ça, que je continue à utiliser bazaar.
Aussi, Andrea Arcangeli (auteur de la VM des noyaux >= 2.4.10 iirc) avait jeté un coup d'oeil sur tla, et avait proposé des améliorations qui auraient permis à des dev de bosser sur des arbres de source comme linux. Il avait réussi à obtenir plus ou moins le type de résultats que Linus obtient aujourd'hui avec son outil GIT pour la génération d'un patchset entre deux arbres... mais bon d'autresdéfauts de tla me font croire que tla n'est pas capable de gérer les quelques 60000 patchsets du noyau 2.5/2.6 par exemple. Sur XviD avec seulement 600 patchs, y'a des fois ou je me dis que arch/tla a quelques defauts :-).
Enfin bon, ce que code Linus, est plus proche du mode de fonctionnement de Monotone, qui maintient un inventaire des fichiers de source en leur attribuant leur somme SHA1, que de arch/tla.
Puis certes, comme le dit Linus, Monotone est lent. Mais je trouve plus que dommage, qu'au lieu d'investir un peu (tant en termes d'efforts de dev ou d'argent) sur l'evolution d'un SCM decentralisé existant qui serait utilisé par les devs de Linux, bah Linus choisit la voie du "je me fais ma sauce dans mon coin".
Bizzarement sur la LKML, personne ne semble s'en rendre compte et tout le monde se penche sur ce GIT que "comme c'est Linus qui code, c'est trop de la bombe, faut trop que je mette mon nom dans le AUTHORS".
PS: je sais, que mes propos peuvent sembler prétentieux, mais si on reflechi deux nanosecondes, c'est pas bien dur de voir que Linus s'embarque dans un choix qui risque d'engendrer un outil purement dédié à SES besoins et à rien d'autre. Bref un peu un gachi, car il va monopoliser des forces de développement dont auraient pu profiter plus de personnes en travaillant sur un SCM plus générique.
[^]Re: L'info sur kerneltrap
Puis certes, comme le dit Linus, Monotone est lent. Mais je trouve plus que dommage, qu'au lieu d'investir un peu (tant en termes d'efforts de dev ou d'argent) sur l'evolution d'un SCM decentralisé existant qui serait utilisé par les devs de Linux, bah Linus choisit la voie du "je me fais ma sauce dans mon coin".
Je suis assez d'accord avec toi ... Le syndrome du "Not invented here" ?
[^]Re: L'info sur kerneltrap
Et alors ? Le plus important dans l'histoire, c'est qu'il ait un outil qui réponde à SES besoins. Le plus important, c'est de développer le noyau linux, pas de participer au développement d'un SCM existant qui ne répond pas à SES besoins.
Participer à un truc déjà existant, c'est trés dur : il faut déjà avoir le temps de se plonger dans le code existant; il faut avoir le temps de tisser des liens avec les développeurs actuels. Discuter des évolutions avec les développeurs actuels, ça prend beaucoup de temps. Sans être sûr au bout du compte que les évolutions qu'on veut soient accépté. Bref, on arrive pas dans un projet existant comme ça, en voulant le diriger pour qu'il corresponde à nos propres besoins (qui sont urgents, dans le cas de linus). C'est donc beaucoup de temps perdu.
C'est pour ça que linus a préféré développer son truc dans son coin : il sait au moins que ça correspondra à ses besoins, que ça ira au moins aussi vite (la preuve..) que l'intégration d'un projet existant (dont aucun ne semble répondre à ses besoins), et qu'il n'aura pas à se prendre la tête avec d'autres développeurs.
Je ne vois pas où est le mal.
C'est sûr que les premières versions de son truc, c'est pas universel. Ça n'est pas forcément générique. Le principal c'est que ça réponde à SES besoins immédiats. Mais peut être aussi qu'à l'avenir, quand il répondra à TOUT ses besoins, le soft évoluera de façon à satisfaire à des besoins moins urgent, plus universel.
D'ailleurs, je te rappelle que "répondre à ses propres besoins", c'est un peu la philosophie du logiciel libre ;-) Si t'es pas content, envoie un patch :-p Et si t'es vraiment pas content, développe un autre produit "concurrent".
[^]Re: L'info sur kerneltrap
Participer à un truc déjà existant, c'est trés dur : il faut déjà avoir le temps de se plonger dans le code existant; il faut avoir le temps de tisser des liens avec les développeurs actuels.
C'est vrai .. pourquoi developper pour le noyau. Autant acheter Winblows XP, au moins y'a pas besoin de regarder des sources pour essayer de comprendre/fixer un bug et par la-meme en faire profiter d'autres ,,,
D'ailleurs, je te rappelle que "répondre à ses propres besoins", c'est un peu la philosophie du logiciel libre ;-) Si t'es pas content, envoie un patch :-p Et si t'es vraiment pas content, développe un autre produit "concurrent".
De ce que j'ai vu, Monotone etait considere comme "trop lent" .. Je crois pas qu'il se soit donne la peine de poster un patch pour qu'il soit plus rapide et par la-meme aider la communaute des utilisateurs de Monotone (dont je ne fais pas partie).
Avec cette philosophie la, on aurait eu 10.000 OS libre au lieu d'avoir 10.000 personnes aidant a developper un OS.
[^]Re: L'info sur kerneltrap
D'apres la mailing list du kernel, Linus a discuté de ses besoins avec les développeurs de monotone.
Et dans le Changelog de la dernière version de monotone (0.18) sortie le 10, on peut lire:
mes 0.02¤
[^]Re: L'info sur kerneltrap
Alors pourquoi ne pas l'utiliser ?
[^]Re: L'info sur kerneltrap
Ils ont gagnés un facteur de 2, mais bon l'eternité deux fois plus courte... ;^)
je disparais ---> *pouf*
^d^c
[^]Re: L'info sur kerneltrap
« L'éternité c'est long, surtout vers la fin ».
Alors deux fois plus courte : est-ce qu'on coupe la fin ou s'en rapproche d'un grand coup ?
Parce que soit ça rend la fin moins longue, soit on trouve l'éternité longue plus tôt...
Moi, je prends la porte, c'est classique mais moins tape à l'½il. Hop, hop -->[]
[^]Re: L'info sur kerneltrap
Je ne vois pas le rapport avec le schmilblick.
Je parlais du cas de l'opportunité ou non d'intégrer une équipe déjà en place.
concernant le noyau, Linus n'a pas eu ce cas de figure, puisque c'est lui, qui a démarrer le projet de ce noyau.
Et pourquoi d'ailleurs ? parce que ce qui existait alors ne correspondait pas à ses besoins.
Si windows correspondait à ses besoins à l'époque, on aurait effectivement pas de linux. Mais où aurait été le mal, si le produit correspondait à ses besoins ?
[+] [^]Re: L'info sur kerneltrap
Je parlais du cas de l'opportunité ou non d'intégrer une équipe déjà en place.
C'est bien ce que je disais .... C'est plus dur d'integrer l'equipe de dev Linux que de passer direct sous Winblows.
Si windows correspondait à ses besoins à l'époque, on aurait effectivement pas de linux. Mais où aurait été le mal, si le produit correspondait à ses besoins ?
Il n'y a aucun mal.. mais si chaque contributeur Linux avait fait pareil, on en serait a XXX OS libres ..
[+] [^]Re: L'info sur kerneltrap
Et alors? Alors y en a marre des caprices de Linus. Il n'est pas seul à développer le noyau et son attitude est exaspérante pour les autres développeurs qui s'impliquent pour la communauté du libre.
L'avis des autres développeurs devrait être entendu et une solution consensuelle choisie. Au lieu de cela, comme d'habitude il n'en fait qu'à sa tête. (Généralement, il demande aux gens de faire des propositions, répond par des "ça sux" et finalement décrète qu'il retient la solution X). Pas très démocratique tout cela...
[^]Re: L'info sur kerneltrap
Il a fait plusieurs appels sur la ml pour demander à ce que les autres développeurs testent le maximum de SCM et fassent de commentaires, que lui n'aurait pas le temps de les étudier tous. Mais très peu l'ont fait, et à chaque fois pour dire que ce n'était pas au point pour le moment (monotone et darcs trop lents, arch c'est fait déscendre en flêche, bazaar-ng pas prêt, svn pas fait pour ça, et les autres aucun commentaire)...
Hors pour comprendre les SCM afin d'en choisir un, le meilleur moyen c'est d'en écrire un sommaire, ça permet de voir quels sont les problèmes, comment les autres les ont réglés, quelle vitesse maximale on peut atteindre etc... Le GIT sert à ça, se pencher sur le problème et en même temps avoir un premier outil que l'on maitrise parfaitement.
Le fait qu'on soit dans le monde du libre, il sera facile de repartir de ce GIT pour utiliser un autre SCM, il sera aussi plus facile pour les autres developpeurs d'utiliser un SCM différent de celui de Linus.
Martin Pool, le développeur de bazaar-ng a déjà signalé qu'il n'exclurait pas l'idée d'utiliser du code de GIT au sein de son moteur.
C'est vraiment du développement distribué pour des scm distribués !
[^]Re: L'info sur kerneltrap
Tom LORD, l'auteur de Arch/tla à envoyé une lettre personnelle expliquant le principe, les objectifs, et les possibilités de Arch.
De plus sur la lkml, et par des mails privés, Linus THORVALD a reçu des benchmarks sur l'intégration de tous les changesets, du noyau, ainsi que des benchmarks sur des cas d'utilisation, à la fois côté mainteneur et côté développeur.
L'utilisation de Arch sur le plan performance ne pose aucun problème, j'ai moi même fait des tests poussés, en respectant la règle du "je test dans le pire des cas".
La question est est-ce que la logique de Arch lui plait ou non ? Monotone semble plus lui convenir, et enfin, après les longues discussions enflammés ou il a dut défendre bec et ongle bitkeeper par rapport à l'utilisation des autres solutions, va-t-il avoir le courage de se tourner vers des solutions qu'il avait cassé ? (souvent à juste titre, on compare avec le niveau actuel des outils, mais auparavant c'était catastrophique).
GIT est la solution facile.
Mais peut importe il faut voir si cette solution à une perennité, si ce n'est pas le cas, développer son propre outils ne sert à rien et ne fait que reculer l'échéance et gaspiller les efforts
[^]Re: L'info sur kerneltrap
De l'avis général, Arch ne correspond pas à ce que les développeurs de Linux (dont le fameux Linus Torvalds, sans "h" et avec un "s") désirent.
Linus a passé 5 jours a évaluer les solutions existantes, et aucune ne lui a semblé idoine. Donc il a dû écrire lui même un programme qui réponde à ses besoins.
Oui "git" est la solution facile. Il fallait dans l'urgence remplacer Bitkeeper, et la solution facile était devant cette contrainte la solution idéale.
[^]Re: L'info sur kerneltrap
tout à fait.
Mon intervention visait à replacer certains point notamment par rapport aux performances.
Linus Torvalds à une grande masse de travail d'incorporation à faire et il ne souhaite pas changer ses habitudes, ce qui est légitime.
Ce qui m'inquiète plutôt est la perennité du GIT, tant qu'à développer quelque chose, il faut que çà dure, sinon on ne fait que retarder la résolution du problème.
Le temps portera donc conseil, en espérant que le choix de Linus se révélera être le bon, car pour l'instant il essait de faire quelque chose qui réponde à se besoins.
[^]Re: L'info sur kerneltrap
Pas très démocratique tout cela...
Oui, mais dans le fond, ça reste d'abors son joujou... Il en fait ce que bon lui semble, et c'est tout... c'est son droit...
Quand on est développeur et qu'on veut contribuer, on sait à quoi on s'engage et qui est le chef du projet.
Je serais à sa place, je n'aimerais de toutes façons pas me faire imposer "démocratiquement" une méthode de travail pour un projet que j'ai mis sur pied moi même durant mon temps libre.
Maintenant, si il pousse le bouchon trop loin, peut-être verrons-nous un fork du kernel, mais ça, c'est à lui de gérer.
Sinon, ceux qui ne sont pas d'accord peuvent toujours bosser sur Hurd...
[^]Re: L'info sur kerneltrap
Et alors ?
Tu préfères un noyau Linux (démocratique et pourrave) ou (totalitaire et performant) ? La démocratie c'est bien pour certaines choses, mais faut arrêter de la ressortir n'importe où quand ça n'a rien à y fouttre.
[^]Re: L'info sur kerneltrap
J'ai une question.
Qu'est-ce qui force à ce qu'ils trouvent un remplaçant à BT si vite.
D'accord, BT change de licence et ne sera plus libre mais la
version actuelle est encore utilisable. Non?
Et si changer de système n'est pas si urgent, qu'est-ce qui empèche
Linus et ses acolytes de s'intéresser à un système existant pour
l'améliorer?
De (très) loin, ça me semble plus une réaction épidermique de
quelqu'un pris en flagrant déli de s'être planté (merde, ce connard
de RMS a eu raison) et qui veut changer le plus vite possible pour
montrer que ce qu'a dit RMS n'était pas si grave (BT, c'est bien
mais regardez, en 10 minutes, je m'en passe).
Se dire qu'on écrit un petit hack super spécifique et que les autres
vont améliorer, c'est:
1. mépriser les autres qui devront faire un gros boulot pour au final
devoir presque tout réécrire;
2. mépriser ceux qui travaillent depuis longtemps (à 2) sur des
systèmes génériques qui voient 100 mecs se ruer sur 100 lignes
de code du dieu Linus (ça me ferait mal ça);
[^]Re: L'info sur kerneltrap
> Qu'est-ce qui force à ce qu'ils trouvent un remplaçant à BT si vite.
> D'accord, BT change de licence et ne sera plus libre mais la
> version actuelle est encore utilisable. Non?
Non, il semble que Bitkeeper ne sera plus utilisable dans 3 mois.
Extrait de l'article KernelTrap :
> Over the next three months, BitMover intends to phase out
> the free BitKeeper product.
[^]Re: L'info sur kerneltrap
En fait, Linus utilise la version payante de BitKeeper, non ?
mais c'est le changement de politique concernant la version libre qui les a poussés à changer... de toutes façons une version libre *figée* de bitkeeper restera disponible, donc il n'y a aucune urgence AMHA.
[^]Re: L'info sur kerneltrap
J'ai cru comprendre que non, que les commits (qui passent par un serveur central pour la version libres) ne passeront plus dans quelques temps.
[^]Re: L'info sur kerneltrap
Le serveur openloging fermera le 1er juillet. A cette date, le client libre fournit par BitMover permettra encore de récupérer les données et méta-données, mais aucun nouveau commit ne sera possible. Pour cela, il faudra utiliser une version payante de BK.
Donc tous les projets utilisant BK et voulant permettre des commit sans acheter de licence doivent migrer avant le 1er juillet
[^]Re: L'info sur kerneltrap
Tiens, toi zici!
Je ne comprens plus rien.
J'avais compris que BitMachin était un SCM distribué, que Linus
l'avais choisi pour ça et que d'autres systèmes étaient caca
parce qu'ils étaient centralisés.
Et là, tu me dis qu'il suffit qu'une seule machine contrôlée par
BitDidule ferme et pouf, on ne peut plus faire un seul commit?
Merde, ils ont changé la définition du mot distribué sans me
prévenir.
Plus sérieusement, y a-t-il quelqu'un pour m'expliquer comment
fonctionne ce truc?
[^]Re: L'info sur kerneltrap
C'est uniquement le cas d'une version *libre* (entendez ici libre pas très libre) qui pour l'utiliser nécessite un *login* sur le serveur de chez BitMover.
[^]Re: L'info sur kerneltrap
version *libre* --> version gratuite..
Tu en sais en Français, il n'y a pas l'ambiguité free/Free de l'Anglais, autant en profiter!
[^]Re: L'info sur kerneltrap
un choix qui risque d'engendrer un outil purement dédié à SES besoins et à rien d'autre.
Il était une fois un jeune finlandais un peu fou. Seul dans sa chambre, dans la pénombre, face à son écran, il affichait "ABABABABA" afin de pouvoir ensuite écrire un émulateur de terminal pour lire fr.comp.minix sur l'ordinateur de son université.
Le reste est l'Histoire.
Plop
et
Plop
[^]Re: L'info sur kerneltrap
Et tu fais quoi des contributeurs .. Si chacun avait fait ce que Linus est en train de faire, on n'aurait certainement XXX OS libres non-finalises ...
[^]Re: L'info sur kerneltrap
Si on voulait démocratiser ce processus, il faudrait:
- déterminer qui a le droit de vote
- déterminer si chaque personne ayant un droit de vote possède le même nombre de voies
- organiser le vote
- appliquer le résultat du vote au risque de voir des développeurs quitter le navire, y compris Linus...
Pour moi, la "dictature éclairée" de LT est plus performante.
C'est son projet et je ne vois pas pourquoi qui que ce soit qui ne fait pas partie des kernel dev aurait la prétention de lui dire comment diriger sa barque.
[^]Re: L'info sur kerneltrap
non, car, aussi compliqué soit-il, un projet de SCM n'a pas vraiment l'envergure de celui d'un OS vois tu. Il est donc plus aisé de repartir à 0 pour un SCM que pour un OS.
Ensuite, j'ai l'impression que tu n'as pas saisie la notion du temps.
Si Linus a décidé de créer un nouvel outils, c'est trés certainement parce qu'il pense qu'il mettra beaucoup moins de temps à le développer qu'à integrer un projet existant, à se mettre d'accord avec les devs etc...
bref, compare ce qui est comparable.
[^]Re: L'info sur kerneltrap
Réflexion à court terme : autant s'investir dans un projet existant prend du temps, autant en maintenir un nouveau en bouffe.
D'un autre côté, on peut comprendre le souhait de Linus : je me suis fait avoir une fois, cette fois je fais mon propre truc comme ça personne ne pourra venir m'arnaquer. Soit dit en passant, ça traduit une certaine méconnaissance des licences, mais tout le monde sait que Linus se brosse un peu des licences ;)
[^]Re: L'info sur kerneltrap
Je pense surtout que Linus sait ce qu'il veut après avoir utilisé bitkeeper... utiliser une application quotidiennement et la critiquer est le meilleur moyen pour savoir ce dont on a besoin et ce dont on a pas besoin... Il peut se permettre maintenant d'aller droit au but sans se perdre dans des choses inutiles... Et puis bon, c'est loin d'être une bille en programmation, ni en gestion de projet... il faut lui faire confiance.
[^]Re: L'info sur kerneltrap
A lire le resume sur kerneltrap, la contrainte no 1 est le temps qu'il faut pour appliquer un jeu de changement. Il a evalue tous les SCM et a chaque fois, il semble que cela ait ete le point bloquant.
Dans un mail, il disait qu'il avait facilement chaque jour 200 patchs a integrer pour une personne. Si integrer un patch prend 30 secondes, 200 patch, ca fait 1h20, ce qui ne semble pas le temps dont Linus a a sa disposition. Partant de la, on comprends qu'il developpe son truc, qu'a l'air pas mal et qui resoud aussi un autre probleme, le probleme de la confiance.
Linux est developpe avec une dictature bienveillante. Si tu veux une democratie, tu peux faire un fork du noyau qui sera developpe democratiquement avec un gestionnaire de source choisi democratiquement, auxquels les developpeurs du noyau contribueront pour qu'il arrive a gerer les 60 000 fichiers du noyau. Bonne chance !
phil.freehackers.org
[^]Re: L'info sur kerneltrap
Si tu veux une democratie...
Je crois que tu as compris mon message à l'envers, je suis absolument du même avis que toi.
[^]Re: L'info sur kerneltrap
Linus s'embarque dans un choix qui risque d'engendrer un outil purement dédié à SES besoins et à rien d'autre
ça alors!
Il avait fait pareil pour Linux puis tout le monde a ajouté un tas de truc partout... Linux "n'était pas portable et ne le serait jamais" (LT), mais ALan Cox s'est acharné sur le port pour m68k et Linux est devenu portable... ;-)
Autant le reste de ton propos est pertinent autant là c'est un peu tôt pour dire Linus s'embarque dans "un gachi". Tu dis toi-même que tu gères un beaucoup plus petit projet et qu'à son échelle les besoins ne sont pas les mêmes...
Enfin j'ai du mal à croire que Linus soit un imbécile pas pragmatique du tout.
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: L'info sur kerneltrap
>Enfin j'ai du mal à croire que Linus soit un imbécile pas pragmatique du tout.
Je tiens juste a dire que mes propos n'ont jamais présenté Linus comme un imbécile. Ce sont tes propres conclusions.
Aussi je voudrais répondre à l'argument "Linus a bien codé Linux ! C'etait spécifique".
Sauf que les deux cas sont peu comparables.
Dans le cas de Linux, il n'y avait pas de noyau Unix-like tournant sur le i386 que Linus utilisait. Minix avait une architecture qui ne correspondait pas tout a fait au modele unix traditionnel, de plus la license ne convenait pas. Et a l'epoque 386BSD n'existait pas si je me trompe pas.
Aujourd'hui Linus a au moins 3 projets sur lesquels se pencher, avec une license qui convient. Dans les 3 cas, ca peut faire ce qu'il cherche a faire, c'est a dire stocker/manager des changesets.
L'excuse du manque de temps pour faire accepter ses vues dans les divers projets, c'est une excuse bien tardive. Il a eu 3 ans pour chercher un remplacant. Or pendant 3 ans, il n'a fait que demonter (verbalement) les solutions de rechange proposées par divers kernel dev (dont Arcangeli) et retorquait toujours que BK lui convenait et tant qu'aucun projet libre ne donnerait exactement les meme features, il utiliserait BK. Or aujourd'hui bizarrement, GIT ca va lui convenir, or GIT c'est un embryon de SCM, bien loin de couvrir ce que fait BK, et Monotone/Darcs/Arch....
Alors maintenant qu'il reparte dans une implementation d'un simili-SCM-tronqué dont on peut douter de la durée de vie, ca me derange pas du tout. Il est libre de faire ce que bon lui semble. Par contre, qu'il chippe les forces de dév en attirant des gens sur un projet à la durée de vie contestable (solution de rechange d'après ses dires), et dont la communauté de l'OSS ne pourrait pas profiter car trop Linux-centré, je trouve ça un peu dommage.
[^]Re: L'info sur kerneltrap
> Or aujourd'hui bizarrement, GIT ca va lui convenir
Bizarre en effet qu'un logiciel qu'il developpe lui-meme lui convienne. C'est encore plus bizarre, que pendant 3 ans il critique les divers SCM et que au bout de 3 ans, tout d'un coup, il ne se mettent pas a convenir par un coup de baguette magique. Dans tes bizzareries, j'y verrai juste une opinion technique persistante.
> GIT c'est un embryon de SCM, bien loin de couvrir ce que fait BK, et Monotone/Darcs/Arch....
Il faut voir que Linus n'utilise pas un SCM de facon traditionelle. D'habitude, les SCM servent a partager du code et a garder une tracabilite. Dans le cas de Linux, le gestionnaire doit permettre a Linus de lire et d'integrer rapidement les patchs qu'on lui soumet avec une contrainte majeur de vitesse.
Les divers SCM dont tu parles n'ont pas ete developpe dans ce contexte et il n'est pas surprenant qu'ils ne conviennent pas parfaitement.
> Par contre, qu'il chippe les forces de dév en attirant des gens
Il ne vole personne, les gens sont libres de travailler sur ce que bon leur semble. Est-ce qu'on se plaint que KDE vole des forces de dev Gnome ?
> sur un projet à la durée de vie contestable
Dans la mesure ou c'est un projet central du noyau, sa duree de vie sera incontestablement liee a la duree de vie du noyau. Autant dire que pour l'instant, c'est partie pour longtemp.
> dont la communauté de l'OSS ne pourrait pas profiter car trop Linux-centré, je trouve ça un peu dommage.
La communaute des developpeurs du noyau profite. En fait, tu lui reproches de bosser trop sur Linux ? Pourquoi ne pas lui demander de bosser pour KDE aussi ?
phil.freehackers.org
[^]Re: L'info sur kerneltrap
> Il ne vole personne, les gens sont libres de travailler sur ce que bon leur semble. Est-ce qu'on se plaint que KDE vole des forces de dev Gnome ?
Oui, tous des voleurs les kdeistes, rendez-nous nos développeurs!!! ;)
> Pourquoi ne pas lui demander de bosser pour KDE aussi ?
Pour GNOME c'est mieux :p
[^]Re: L'info sur kerneltrap
je sais bien que tu n'as pas traité Linus d'imbécile et que c'est un raccourci (audacieux) de ma part. Je crois bien avoir plussé ton commentaire d'ailleurs. Mais on pourrait y comprendre que Linus n'a pas réfléchi beaucoup:
Linus Torvalds ne semble pas regarder plus loin que ses besoins immediats.
(...)
Il a à peine évoquer les raisons qui l'ont poussé à rejeter Monotone. N'a pas cité Arch, ni Darcs.
Par imbécile pas pragmatique je voulais dire qu'il a certainement testé les autres outils et que son côté pragmatique a du entrer en action.
Et puis après tout Linus peut très bien trouver super fun de coder un SCM! et s'il code un outil qui lui convient, cet outil a de forte chance de convenir à d'autres gros projets. C'est d'ailleurs comme ça que l'histoire de Bit Keeper a commencé: un outil d'abord conçu pour les besoins de Linus.
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: L'info sur kerneltrap
j'oubliais: on a tous fait ça.
On a tous codé un truc nouveau plutôt qu'adapter un existant!
Tu te rappelle le temps où les hommes étaient des hommes et se bagarraient avec les bits? (C'est LT qui parle)
On a tous voulu avoir les mains sales et pleines de cicatrices des codeurs fous, la fierté du hacker qui voit s'éteindre les réverbères au matin, et qui rejoint son lit après une nuit de chasse au bug acharné.
Vive les mains dans le camboui! Je me suis écrit un clone de Vignette (c'était en 1999), j'ai même refait tout le site salon.com avec, c'était génial de code pourri, de café froid, de bugs inavouables et de nuits blanches dans la gueule. J'ai pris des mois de retard, mais quand les premiers utilisateurs sont arrivés j'en aurai foutu ma bite sur la lune!
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: L'info sur kerneltrap
il n'y avait pas de noyau Unix-like tournant sur le i386 que Linus utilisait. Minix [...]. Et a l'epoque 386BSD n'existait pas si je me trompe pas.
NetBSD existait je crois (pas sous ce nom-là, mais d'après l'URL plus bas "Networking Release 2" : "our second greatly expanded freely-redistributable release began shipping in June 1991"), mais il y a eu la poursuite de USL (Unix System Laboratories) contre l'université de Berkeley et ça a dû écarter pas mal de monde du projet à l'époque.
J'ai déjà lu que si BSD n'avait pas souffert du procès (qui a été abandonné grâce à Ray Noorda quand il est arrivé à la tête d'USL, suite à son rachat par Novell), il serait peut-être à la place de Linux actuellement, et que Linux n'aurait pas connu un tel essor.
Pour plus d'infos, cf http://ezine.daemonnews.org/200312/editorial.html(...) par ex :
Shortly after BSDI began their sales campaign, they received a letter from Unix System Laboratories (USL) (a mostly-owned subsidiary of AT&T spun off to develop and sell Unix). The letter demanded that they stop promoting their product as Unix. [...] This turned into a lawsuit against BSDI and The University of California, Berkeley, and came to include FreeBSD and NetBSD.
Conclusion du procès, commencé début 1992 : a settlement was finally reached in January 1994. The result was that three files were removed from the 18,000 that made up Networking Release 2, and a number of minor changes were made to other files. In addition, the University agreed to add USL copyrights to about 70 files, although those files continued to be freely redistributed.
Pour l'historique de BSD, y compris le procès de USL/AT&T : http://www.oreilly.com/catalog/opensources/book/kirkmck.html(...) .
[^]Re: L'info sur kerneltrap
Il a à peine évoquer les raisons qui l'ont poussé à rejeter Monotone.
Des raisons de performances principalement. Et aussi monotone n'est pas "prêt", c'est ce qu'on lui a dit : il y a encore des bugs, l'UI n'est pas vraiment fignolée, on peut être ecore amené à faire des grands changements dans les concepts, etc.
En fait git reprend de trés trés près la structure de monotone. Les grosses différences sont :
- monotone utilise une base sql
- monotone stocke des diffs entre fichiers alors que git stocke les fichiers entiers
- monotone possède des métadonnées signées
- git effectue le transport réseau via rsync alors que monotone a son propre protocole.
Sinon les données sont organisées de la même façon, en 3 couches :
- les fichiers, identifiées par le SHA1 hash de leur contenu ;
- les arbres, ("tree" pour git, "manifest" pour monotone) représentant un état de l'arbre à un moment donné ;
- ce qu'on appelle les "revisions" dans monotone, ("commit" pour git) référençant un abre et l'historique qui y a conduit.
J'écrit une petite application pour visualiser les graphes monotone :
http://oandrieu.nerim.net/monotone-viz/(...)
En bidouillant un peu (réécriture d'un module), je peux aussi afficher les graphes pour git:
http://oandrieu.nerim.net/monotone-viz/Screenshot-git-viz.png(...)
[^]Re: L'info sur kerneltrap
Merci pour ton retour d'expérience au sujet de tla.
A mon sens, le problème majeur de tla s'appelle Tom Lord
donc il n'y a rien à attendre de mieux à l'avenir. Il suffit de lire
les listes de diffusion pour voir passer tout un tas de délires
fumeux (Pika, XL, Furth) et l'autisme par rapport aux désirata des
utilisateurs.
Personnellement, j'utilise bazaar car c'est une bonne amélioration
de l'interfaçe de tla, même s'il se traine tous les défauts. C'est
un outil transitoire en attendant mieux.
darcs est très agréable mais pas très performant.
montone est très lent et l'idée de mettre tout le repository
dans une base sqlite n'est pas franchement ingénieux.
A mon sens bazaar-ng est très prometteur. La documentation
est riche. Le but n'est pas de réinventer la roue mais de
prendre le meilleur de tous et d'en faire quelquechose
d'apréciable. Qu'en penses-tu ?