Matthieu Moy a écrit 3255 commentaires

> Mais tu remarqueras que très tôt, les gens ont senti le besoin de créer des surcouches à Git, Cogito, StGit, c'est bien pour une raison.

> > Juste faut arrêter de croire que le développement de Git s'est arrêté à Linus
> D'où tu sors ça ?

Pas besoin d'aller chercher très loin, ton affirmation juste quelques lignes au dessus est très représentative.

cogito, c'est une surcouche "conviviale" qui a été créée par dessus le coeur de Git, à l'époque où git lui-même n'avait pas vocation d'être convivial. cogito a disparu il y a bien longtemps, justement parce que Git a évolué depuis.

http://www.enseignementsup-recherche.gouv.fr/cid22763/plan-c(...)

revaloriser le début de carrière des jeunes maîtres de conférences : leur rémunération sera augmentée de 240 à 510 euros bruts par mois, ce qui représente de 12 à 25 % d'augmentation immédiate grâce à la prise en compte du doctorat et des activités contractuelles antérieures. (je ne retrouve pas la grille de salaires précise qui est sortie de cette annonce, mais en gros, les nouveaux recrutés entamment directement au salaire des anciens avec 2 ans d'ancienneté).

proposer des chaires entre universités et organismes de recherche : le maître de conférences lauréat d'une chaire, recruté sur concours par une université et un organisme de recherche, bénéficiera d'une prime significative d'au moins 6 000 euros (pouvant atteindre 15 000 euros) et d'une dotation de recherche de 10 000 à 20 000 euros par an. Il sera déchargé pour 2/3 de sa charge d'enseignement afin de pouvoir développer son activité scientifique dans l'université. (Au final, les chaires sont payés 1/3 de plus que les autres. Le système des chaires a des tas d'inconvénients, c'est entre autre une magouille pour faire apparaitre le même poste dans deux listes de postes officiels et faire croire qu'on ouvre deux postes alors qu'il n'y a qu'un fonctionnaire recruté, mais si il y a de bons arguments contre, celui du salaire trop bas n'en est pas un).

Remis en question par les enseignants, ou par la ministre.

Parce que justement, y'a un sacré coup de pouce sur les salaires des futurs recrutés, qui a été annoncé avant les grèves.

thésard = doctorant = celui qui prépare une thèse mais qui ne l'a pas encore
docteur = celui qui l'a déjà soutenue.

fsync, c'est pour assurer la cohérence suite à un crash du système.

pour garantir que les données sont « sorties du processus », c'est juste fflush, c'est beaucoup moins cher ...

Y'a pas qu'un renommage, y'a un "write()" aussi. Si le fichier est gros, ça va être hyper lent. Enfin heureusement qu'une bonne base de données ne ré-écrit pas le fichier à chaque écriture ;-).

Le problème n'est pas tellement l'interface avec le noyau, mais surtout l'interface avec les bibliothèques compilées avec autre chose que LLVM. En gros, la compatibilité au niveau ABI, ça permet de faire des appels de fonctions d'un binaire à l'autre (donc d'un programme vers un .so, ...).

Si tu vas chez un assembleur et pas une grande surface, tu n'as pas forcément la possibilité d'avoir un windows OEM...

Donc, effectivement, trois tentatives suffisent pour écrire une ligne correcte en shell ;-).

(sinon, « for i in ./* » ou « for i in *; do blablabla "./$i"... » marchent aussi).

D'ailleurs, ta version n'est pas robuste non plus. Je te laisse trouver le nom de fichier qui la fera planter ;-).

(c'est un classique)

Là, on parlait du « | » du powershell.

Effectivement, quand on n'utilise pas le « | » du shell normal, on n'a pas de problème avec, mais ça ne répond pas vraiment à la question. Le jour où tu voudras traiter une liste de fichiers que tu ne peux pas obtenir par globbing, tu mettras une commande à la place du « * », et tu retombera dans les mêmes problèmes.

Ceci dit, perso, je n'utilise pas le fameux powershell, je suis sous zsh et j'en suis très content. Ce que j'écris en ligne de commande est en général très « quick and dirty », mais je m'en fout. Par contre, je ne compte pas le nombre de scripts que j'ai pu écrire et qui ne sont pas robustes à cause de ce genre de trucs.

C'est le genre d'exemples qui ressort à tous les coups quand on parle de shell objet.

Et comme à chaque fois, la réponse est : « Donnes-nous la version robuste aux espaces dans les noms de fichiers » (et j'anticipe sur la réponse à la réponse : et la version robuste aux retours chariots dans les noms de fichiers ?).

Effectivement, écrire des trucs pas robustes, « quick and dirty » en bash, ça marche bien, mais quand il s'agit de faire des trucs qui marchent vraiment, toujours, partout, là, c'est une autre paire de manches.

Le globbing a toujours été supporté par bash, non ? Le globbing, c'est juste le fait de pouvoir écrire *.c pour dire « tous les fichiers terminant par .c ».

Par contre, le globbing a été amélioré, d'après l'annonce, ** est (enfin) supporté comme zsh, pour pouvoir écrire des choses comme **/*.c pour dire « tous les fichiers *.c dans un sous-répertoire du répertoire courant ». Et ça, c'est LA fonctionalité de zsh qui tue, et c'est vraiment cool que bash s'y mette.

Attention, sur pas mal de distribs, /bin/sh est assez permissif (sous Debian, c'est un bash par exemple). Sur ces distribs, on peut écrire des scripts pas POSIX du tout et qui marcheront quand même ... jusqu'à ce qu'on passe sur une autre distrib (typiquement, j'alterne entre Debian et Ubuntu, et ubuntu a un dash fait pour être strict comme /bin/sh, donc mes scripts mal écrits n'y marcheront pas).

Si tu as 1 fichier, 1 révision. Disons un .jpg de 2Mo.

Sur le serveur, tu as 1 copie de ce fichier, dans la seule révision. Le dépôt fera ~2Mo. Dans la copie locale, tu as le fichier sur lequel tu travailles, plus le fichier base caché dans un .svn/, donc tu as le fichier en double.

Testé à l'instant :

$ du -sh *
3.8M checkout
2.0M repo
$ du -sh checkout/dsc04507.jpg checkout/.svn/text-base/dsc04507.jpg.svn-base
1.9M checkout/dsc04507.jpg
1.9M checkout/.svn/text-base/dsc04507.jpg.svn-base

Non, pour SVN, il faut bien "double place", i.e. pour un arbre de travail de 1Mo, il faut un peu plus de 2Mo pour le stoquer en local. Ce qui est bête, c'est que les fichiers "base" ne soient pas compressés.

Pour Git, par exemple, c'est carrément tout l'historique qui est dupliqué en local, mais suffisament bien compressé pour prendre en général moins de place que l'arbre de travail.

En pratique, en général, on s'en fout un peu : l'arbre de travail est un truc qui n'a pas besoin de beaucoup d'attention au niveau sauvegarde, et vu le prix des disques durs, ... (par contre, l'archive, elle, elle est stoquée sur des disques qui coûtent cher en général, et on est bien content qu'elle soit compressée comme il faut).

Tu connais beaucoup de gestionnaires de versions qui ont besoin d'envoyer une copie entière au serveur pour faire le diff ? (à part CVS, je n'en connais pas. SVN a les .svn/prop-base/, Git, Mercurial, Bazaar ont une copie de l'historique en local dans leur mode de fonctionnement classique, ...).

> A mon avis, c'est typiquement ce qu'il ne faut pas faire : réinventer la roue.

Oui.

> Ce que tu viens de décrire doit être en gros ce que fait rsync.

Pas tout à fait. La difficulté de rsync, c'est qu'il ne veut envoyer que le patch, mais que pour calculer le diff correctement, il faudrait avoir les deux copies sur la même machine, et ça, justement, c'est ce qu'on cherche à faire. Du coup, rsync se débrouille en coupant le fichier en morceaux, envoyant les checksums des différents bouts, ... mais c'est quand même sous-optimal.

Une solution qui fait des diffs en local, et qui envoie le patch, ça existe déjà aussi, c'est ce que fait à peu près n'importe quel gestionnaire de versions. Donc, une solution assez simple serait d'utiliser par exemple Git, un commit sur la machine distante, un "pull" et le tour est joué.

À la base, c'est plus ou moins un jeu de mot entre « en:B-Tree » et « better ».

Aussi : rst2html, asciidoc

(j'ai déjà vu un étudiant avoir un fichier avec mtime < ctime et prétendre qu'il avait fait ce fichier lui-même avec un éditeur de texte ;-) )

Sous Unix, justement, il y a les deux dates : mtime (Modification) et ctime (Change).

On peut tricher facilement sur le mtime (touch permet de le modifier, cp -a le conserve, tar xf le restaure, ...), mais difficilement sur le ctime, qui correspond de manière bien plus fiable à la date de dernier changement sur le inode du fichier (certaines opérations comme créer un lien en dur modifient le ctime et pas le mtime).

Pour voir les deux : ls -l et ls -l --time=ctime.

Oui, mais n'importe quel outil qui cherche à passer à l'échelle va justement tout faire pour éviter de faire le moindre open() sur un fichier, et se contenter d'un lstat().

Make, mais aussi la quasi-totalité des gestionnaires de versions.

T'as besoin de perl pour git-svn et quelques autres commandes. Le coeur de Git est en C, et il y a encore quelques scripts shell (mais la tendance est à les ré-écrire en C).

Non, justement. Pékin, c'est l'ancien nom Français.