Matthieu Moy a écrit 3257 commentaires

Ben cite un autre outil qui était selon toi à un niveau comparable à BK au moment ou Linus a migré.

> Ouai, mais Linus a vraiment été très arrogant sur ce coup.

Linus arrogant ? C'est un pléonasme ;-)

> Rien ne permet de prouver que l'accélération de l'inclusion des nouveautés dans le noyau est due à BK.

Je pense que Linus est bien mieux placé que nous deux pour en juger, et il est plus que clair là dessus.

> l'absence de noyau 2.7, etc.

L'abscence de noyau 2.7, elle est due a la possibilité de tester les patchs dans des branches différentes avant inclusion dans la mainline. Tu te vois sérieusement faire ça avec CVS ?

> Et s'il avait demandé à la communauté de développer un outil proposant les
> mêmes fonctionalités que bitkeeper au moment où il a décidé de l'adopter, tu
> ne penses pas qu'il y aurait des solutions beaucoup plus évoluées à l'heure actuelle?

C'est un peu ce qu'il s'est passé, non ? Arch est né avec comme objectif affiché de remplacer BK pour le kernel par exemple. Linus dit dans son mail: « I sure had hoped that it would have happened only once there was a reasonable open-source alternative. », ce qui veut bien dire qu'il aurait migré vers une solution open-source si elle avait été a la hauteur.

La licence de BitKeeper fait ch**r, tout le monde préfère que Linux utilise autre chose. En attendant, je suis bien content d'avoir un noyau Linux qui marche bien avec un développement actif et rapide. C'est en partie grace a BK, on ne peut pas le nier.

> IBM ou les autre paieraient sans doute, non ?

Ben justement, pas tous les autres.

Un des rôles de Torvalds, c'est d'animer une communauté autour du noyau. BitKeeper était déjà source de conflits avec la version gratuite, là, c'est la goute d'eau qui fait déborder le vase. La bourde, ça serait de continuer avec BK. Cf. son mail sur la lkml ou il explique ça très bien.

http://lkml.org/lkml/2005/4/6/121(...)

> maintenant il l'a dans le cul...

A mon avis non. Si Torvalds n'avait pas migré vers BitKeeper, il y a pas mal de gens qui seraient restés a CVS sans se poser de questions. Le coup de pied dans la fourmilière a permis de montrer qu'on pouvait faire mieux, et du coup, des alternatives intéressantes se développent.

Résultat, d'ici quelques mois, il aura quelque chose de comparable a BitKeeper en open-source. Ça n'aurait probablement pas été le cas autrement.

Oui, mais si "l'avant" bitkeeper a été abandonné, c'est qu'il ne passait pas a l'échelle. L'après bitkeeper ne peut pas être le même que l'avant.

Par contre, il y a pleins de bonnes idées qui se balladent sous différentes formes en matière de gestions de versions. En rassemblant un peu les forces, il y a moyen de faire quelque chose de très bon en open-source.

> seuls ses collègues peuvent voir le code.

L'admin du serveur n'est pas forcément un collègue ...

Oups, oui, j'avais "oublié" l'époque du Qt pas libre.

> Retrospectivement, KDE a bien eu de la chance avec Trolltech.

Qt est GPL. Si trolltech déconne, il y a un fork dans les 5 minutes.

Par ailleurs, il y a un accord plus ou moins formel entre KDE et Trolltech, j'ai plus l'URL en tête, mais en gros, si Trolltech arrête la version GPL, les versions disponibles passent carrément en BDS.

> C'était avant le Web alors je n'ai pas d'URL

En cherchant bien, tu aurais pu trouver une URL quand même : elle est dans le journal.

Ce mode de magnétisation ne date pourtant pas d'hier. Il a été découvert il y a plus d'un siècle par le scientifique danois Valdemar Poulsen mais n'avait pas jusqu'à ce jour été testé pour les disques dur.

Surement pas. Linus veut un gestionnaire de versions distirbué. Subversion ne fait pas partie de cette catégorie.

> il semble que certains dev soient plutôt bon.

Le principal dev, c'est Martin Pool, auteur de distcc et rsync, c'est déjà plutôt bon signe.

Pour le cache, baz (un fork de tla) a un système de cache. tla a quelque chose qui ressemble fort au cache (revision library, mirroir local) sans en être vraiment un.

> svn je doute

Y'a svk basé sur svn et qui a l'air pas mal. Jamais essayé.

> GNU Arch, c'est bon mangez-en

Si par "GNU Arch", tu entends tla, soyons clairs : Une organisation sérieuse n'investira *jamais* dans tla. Une "équipe" de dev même pas capable de dire ou est son bugtracker, qui sort régulièrement des version rcX ou pre-Y sans qu'elles aboutissent sur des versions stables (un truc rigolo est de suivre l'historique du "partial undo". Le code a été écrit il y a a peu près un an, il a été mergé deux fois dans la branche supposée principale, mais les deux fois, cafouillage et recommençage a zero - on peut toujours attendre). Un développement capable de passer au point mort complet pendant des mois, de mettre 3 ou 4 mois a corriger une faille de sécurité. Un mainteneur qui considère qu'ajouter un cache a tla serait une "bloated feature", ...

Par contre, du coté de baz, il y a pas mal d'espoir. D'autant que c'est supporté par canonical, qui ne nous a pas habitué a faire de la merde ...

Le problème de darcs, c'est qu'il a besoin de charger tout l'historique du projet pour un certain nombre de commandes. Donc, c'est inenvisageable sur des gros projets. Par contre, ce qui est extraordinaire, c'est que pour contribuer a un projet existant, il suffit de faire

[ apt-get install darcs ]
darcs get ...
[modif]
darcs record -a
darcs send

Et hop, avec 3 commandes, j'ai envoyé un patch !! (même pas la peine d'ouvrir mon mailer, même pas besoin d'avoir les droits sur le repository principal)

> La question est donc de savoir si c'est intéressant de garder /dev/shm/ de monté en tmpfs,

1) Ca n'est pas pénalisant de le laisser

2) Est tu sur qu'aucune application que tu utilise n'a besoin de /dev/shm ?

> Lance-toi plutôt directement dans la ligne de commande,

Dans ce cas, il faut quand même un éditeur de texte. Les plus connus sont Emacs et Vim.

Sinon, dans la série des trucs intégrés, il y a aussi eclipse, anjuta, netbeans, ...

A priori, ta variable contient bien les retour chariots. Par contre, il faut mettre des guillemets autour quand tu l'utilises:

echo "${jour}"

devrait le faire.

C'est richard qui l'a convaincu ;-)

> Je suppute d'ailleurs qu'il relit bestialement le fichier depuis le début.

D'après strace, ça n'a pas l'air d'être le cas. Par contre, il réaffiche tout l'écran, contrairement a less.

> c'est pas moins barbare, juste ca fait pas du tout pareil.

Ben entre le mec qui lit ses logs avec "rev" et celui qui les lit avec "tac", qui est le plus barbare, hein ;-)

(entièrement d'accrord pour le reste)

http://www.google.com/search?q=df+linuxfr+forum(...)

> mieux, installe PHP5 directement avec les package mandrake des contribs.

J'approuve. "débutant sous linux" et "la commande ./configure." ne font pas bon ménage ...