Frédéric Perrin a écrit 207 commentaires

Oui, enfin, utiliser un proxy SOCKS pour passer le part-feu de la boîte et mouler sur le Net depuis le boulot, ça se comprend (et il paraît que certains le font...) ; devoir utiliser un proxy depuis chez soi vers une box qui du vrai Internet alors qu'on a déjà payé un abonnement "internet", c'est moins normal.

> ou la porte

Chez Orange/FT, c'est plutôt "ou la fenêtre", non ?

Pour les gens qui n'ont pas de Thunderbird, tu peux montrer quelques lignes du prefs.js que tu lis ?

J'ai l'impression qu'il doit ressembler à :

mail.server.server1.type XYZ
mail.server1.address mail.example.org
mail.server.server2.type ABC
mail.server2.address mail.example.com
...

Si c'est bien le cas :

grep -c mail.server.server'.*'.type prefs.js

Est-ce que c'est Skype qui se comporte de façon crade, ou est-ce que c'est le réseau qui ressemble tellement peu à Internet qui est tout pourri ?

Bah de toute façon, pour passer au 100M, il faudra déjà refaire le réseau d'accès ("la tranchée jusqu'à chez toi"), et probablement la formation des gens. Donc tant qu'on y est, autant mettre de la FO partout...

Ca commence par "version légère", ça continue par "Ubuntu... Firefox... GDM... Flash et Java...".

Pourquoi ne pas être reparti sur une base simple de Debian, sans avoir à enlever le gazillon de services Ubuntu ?

D'ailleurs, plus que la liste des logiciels par défaut, ce qui serait intéressant est la liste des services que tu as désactivé.

Piste pour les autres logiciels : Midori (ou Kazehakase, mais semble peu évoluer ces derniers temps), xdm (ou entrance ? SLiM ?). Pour les deux autres, le navigateur oueb est configuré pour ne pas les jouer par défaut, j'espère ?

Sur ton site, tu n'expliques pas pourquoi je devrais utiliser cette distribution plutôt que mettre $distrib_préférée et utiliser mon gestionnaire de paquets pour installer un nouveau gestionnaire de fenêtres et les quelques paquets que tu cites.

Avec ceci, j'ai la liste des révisions dont TOTO est l'auteur :

IFS='| '
svn log | grep '^r' | while read rev author date size; do [ $author == "TOTO" ] && echo $rev; done

A toi de remplacer svn log par la commande de SVN qui te donne les révisions qui t'intéressent, et le grep par une expression un peu plus restrictive (ça marche sur mon dépôt à moi parce que les règles de rédaction des messages font que, mais enfin...).

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/(...)

En résumé : echo options loop max_loop=64 >> /etc/modprobe.conf. Il sera probablement nécessaire de démonter tous les CD actuellement montés, puis de décharger / recharger le module noyal (ou au pire, reboot).

Sur le deuxième lien, il est dit à propos de l'extension à 18 mois :

des mises à jour du système de base · sont fournies pendant 18 mois (6 mois supplémentaires) (kernel, Apache, ...).

Donc je pense que c'est plus un oubli de MLO qu'autre chose.

Je dirais plutôt, pourquoi utiliser perl si c'est pour invoquer des programmes externes (et surtout grep !) ?

open WHO, "|-", "who";
while (<$who>) {
next if m/\(:/;
my ($user) = split;
print "$user est connecté\n";
}
close $who;

>> pas forcément efficacement, sans forcément que le bénéfice fasse baisser le prix des billets.

> Les stats servent pour planifier à long terme les nouvelles lignes, en sachant qui va où (sur le réseau RER), qui entre tout ça... Et c'est tout.

En quoi y a-t-il besoin de données que l'on peut rattacher à un individu pour cela ? Sans parler du fait que la population qui utilise Navigo n'est certainement pas représentative de la population qui utilise le métro.

Observer les flux de la foule ne doit pas être bien compliqué, surtout vu le nombre de mouchards de vidéo-surveillance...

Ou pour ajouter des polices à X. Je suis peut-être vraiment mauvais, mais j'ai pas réussi à trouver comment faire sans ajouter une directive FontPath à mon xorg.conf et relancer le serveur X. Faut dire que j'ai pas cherché plus de dix minutes, la solution décrite ici ne prenant que le temps de se souvenir de la syntaxe de xorg.conf (et je n'étais pas dans l'humeur pour fouiller des fichiers de conf, XML sembe-t-il, du nouveau composant qui maintenant gère tout cela.

echo $tri | tr -d ' '

Non, je plaisante, hein.

info bash "Shell Variables" "Bourne Shell Variables"

IFS permet de dire comment splitter une ligne de texte en lexèmes. Ça te permettra quelque chose de bien plus simple que ce que tu as ici :

#!/bin/bash

IFS=","

cat villes.csv | tr -d \" | while read pays ville num; do
pays=$(echo $pays | cut -c1-3)
num=$(echo $num | tr -d '[A-Z]')

echo "$pays$ville$num"
done

Je n'ai pas compris le commentaire "Pour trier", puisque tu ne tries rien du tout, donc j'ai peut-être loupé quelque chose.

Quoi qu'il en soit : en modifiant IFS, je laisse au shell le soin de splitter la ligne lui-même. Ça évite les | cut -d, -f X. Ensuite, en factorisant la suppression des guillemets, il est plus simple de voir le traitement qui est commun à tous les champs et celui qui diffère à chaque fois. Tu tronquais deux fois $pays à trois caractères, j'ai supprimé ça. J'ai ramené la suppression des lettres de $num en-dehors de l'echo.

Pour revenir à la question initiale, $tri contient après l'exécution de la longue ligne chaque champ, séparés par des retours à la ligne. Quand ton shell lit "echo $tri", avec la valeur par défaut de IFS, il sépare $tri en trois lexèmes, passés en arguments à echo, qui les affiche les uns après les autres séparés par des espaces.

Questions en suspens : que se passe-t-il le jour où une ville contient une virgule, par exemple si tu fais du commerce avec "Paris, Texas" ? Est-on sûrs que le champ $num est toujours de la forme Xn, avec X une lettre et n un unique chiffre ? Que se passe-t-il le jour où quelqu'un ajoute un quatrième champ ? N'y a-t-il pas d'accents sur le nom « Perou » ou « Pekin » ? Pourquoi les habitants de Barcelonne, ce (probablement charmant) village de la Drôme ont-ils fait allégeance à la couronne espagnole ?

Pour aller à Toulouse depuis Paris, je conseillerais plutôt un changement à Strasbourg pour éviter d'aller tout droit en Allemagne.

Si les séquences communes (typiquement, une fonction déplacée d'un fichier à l'autre) sont "loin" les unes des autres (>32ko, d'après [1]), elles ne seront pas détectées, si ? Et donc, cela veut dire que si le .tar des sources fait >16ko, on risque de passer à côté de recoupements... Or, 16ko de sources, ce n'est pas grand'chose...

Ceci dit, c'est éblouissant de simplicité et d'élégance :-)

[1] http://www.gzip.org/algorithm.txt

Non : je viens de vérifier, si un fichier a été renommé dans la révision 106, alors avec svn diff -r 105:107 je vois un fichier avec l'ancien nom supprimé, et un fichier avec le nouveau nom ajouté. Avec --no-diff-deleted, je vois uniquement un ajout de fichier (on va dire que ça divise par deux l'erreur commise, mais si il y a eu de vraies suppressions à prendre en compte, ça va les zapper :-/).

Effectivement, dans les commentaires et dans main() les tests sont 0 = MEMCPY, 1 = DUMB, 2 = MCBLOCK, dans worker() c'est 1 = MEMCPY, 2 = MCBLOCK et 3 = DUMB.

Ça m'étonnait d'autant plus qu'après avoir posté, je suis allé faire un tour dans /usr/src/lib/libc/i386 (c'est beau un BSD, les sources sont à un cd de distance :-p ), et memcpy (identique à memmove) était écrit en assembleur. Je savais pas trop quoi penser d'un compilateur qui optimise mieux de l'assembleur écrit avec amour que du C écrit à la main...

Sinon, pour rebondir sur ce que disait quelqu'un d'autre plus haut, memcpy copie la source vers la destination par mots entiers (dans BSD libc toujours).

Pour apporter quelques points de données supplémentaires, des tests sur d'autres systèmes que les tiens. Sur Linux-sparc64 pas très jeune (machine multi-utilisateurs, avec 512Mo de RAM dont 300 sont réellement utilisés). On constate les mêmes choses :

fperrin@gadget:~/mbw$ ./mbw 10|grep AVG
AVG     Method: MEMCPY  Elapsed: 0.14899        MiB: 10.00000   Copy: 67.116 MiB/s
AVG     Method: DUMB    Elapsed: 0.07369        MiB: 10.00000   Copy: 135.695 MiB/s
AVG     Method: MCBLOCK Elapsed: 0.07356        MiB: 10.00000   Copy: 135.940 MiB/s

Sur FreeBSD (7.2, sur i386) :

papillon:~% tar -xf mbw-1.1-1.tar.gz
papillon:~% cd mbw
papillon:~/mbw% make mbw
cc -O -Wall -g  mbw.c  -o mbw
mbw.c: In function 'worker':
mbw.c:102: warning: implicit declaration of function 'mempcpy'
mbw.c:102: warning: incompatible implicit declaration of built-in function 'mempcpy'
mbw.c:105: warning: incompatible implicit declaration of built-in function 'mempcpy'
/var/tmp//ccz83HJk.o(.text+0x1f5): In function `worker':
/home/fred/mbw/mbw.c:102: undefined reference to `mempcpy'
/var/tmp//ccz83HJk.o(.text+0x247):/home/fred/mbw/mbw.c:105: undefined reference to `mempcpy'
*** Error code 1

Stop in /usr/home/fred/mbw.
zsh: exit 1     make mbw
papillon:~/mbw% vi mbw.c
# remplacer mempcpy avec un no-op...
papillon:~/mbw% make mbw
cc -O -Wall -g  mbw.c  -o mbw
mbw.c: In function 'worker':
mbw.c:89: warning: unused variable 'c'
papillon:~/mbw% ./mbw 100 | grep AVG
AVG     Method: MEMCPY  Elapsed: 0.17829        MiB: 100.00000  Copy: 560.894 MiB/s
AVG     Method: DUMB    Elapsed: 0.14917        MiB: 100.00000  Copy: 670.365 MiB/s
AVG     Method: MCBLOCK Elapsed: 0.00000        MiB: 100.00000  Copy: 62500000.000 MiB/s
papillon:~/mbw% ./mbw 200 | grep AVG
AVG     Method: MEMCPY  Elapsed: 0.33782        MiB: 200.00000  Copy: 592.032 MiB/s
AVG     Method: DUMB    Elapsed: 0.28624        MiB: 200.00000  Copy: 698.709 MiB/s
AVG     Method: MCBLOCK Elapsed: 0.00000        MiB: 200.00000  Copy: 133333333.333 MiB/s

# en enlevant -g
papillon:~/mbw% gcc -O -Wall mbw.c -o mbw
mbw.c: In function 'worker':
mbw.c:89: warning: unused variable 'c'
papillon:~/mbw% ./mbw 100|grep AVG
AVG     Method: MEMCPY  Elapsed: 0.17197        MiB: 100.00000  Copy: 581.484 MiB/s
AVG     Method: DUMB    Elapsed: 0.14150        MiB: 100.00000  Copy: 706.733 MiB/s
AVG     Method: MCBLOCK Elapsed: 0.00000        MiB: 100.00000  Copy: 62500000.000 MiB/s

# avec -O3
papillon:~/mbw% gcc -O3 -Wall mbw.c -o mbw
mbw.c: In function 'worker':
mbw.c:89: warning: unused variable 'c'
papillon:~/mbw% ./mbw 100|grep AVG
AVG     Method: MEMCPY  Elapsed: 0.15598        MiB: 100.00000  Copy: 641.096 MiB/s
AVG     Method: DUMB    Elapsed: 0.14457        MiB: 100.00000  Copy: 691.689 MiB/s
AVG     Method: MCBLOCK Elapsed: 0.00000        MiB: 100.00000  Copy: 62500000.000 MiB/s

Donc : les GNUism, c'est pas génial ; il y a d'autres OS sous lesquels memcpy n'est pas si mauvais que ça ; il faudrait tester wmemcpy ; -O3 semble profiter plus à memcpy qu'à la copie manuelle.

C'est tout à fait correct, mais en l'absence de contexte il n'est pas facile de voir de quoi tu parles. La « belle bleue », tu parles de la mer ou d'un feu d'artifice ? Pour le « nouveau », tu parles d'une nouvelle personne arrivée dans l'équipe, d'un nouveau magasin en ville, d'un pilote de carte graphique ?

Et même si « un nouveau » est courant pour parler d'une nouvelle personne dans un groupe, c'est la première fois que je vois utilisé « live » pour « live CD ».

Ça donnerait quelque chose comme :

fichier=$1

# Si l'utilisateur donne quelque chose qui ressemble à un pourcentage, on l'utilise
# Sinon, on prend 40 par défaut
if [ $2 -ge 0 -a $2 -le 100 ]; then
    taille=$2
else
    taille=40
fi

case $fichier in
*.[Jj][Pp][Gg]|*.[Jj][Pp][Ee][Gg])
    convert -resize "$taille%" "$fichier" "little_$fichier"
    ;;
*)
    echo $fichier ne semble pas être un fichier JPEG
    echo Utilisation :
    echo $0 image.jpg [taille]
    echo Si taille (en %) n'est pas donnée ou n'est pas comprise entre 0 et 100, utilise une
    echo valeur par défaut de 40.
    exit 1
    ;;
esac

Utilisation : mon_script image.jpg [taille]. Par contre : ce script ne retaille qu'une seule image, c'est dommage. Une solution serait de prendre la taille comme le premier argument (mais dans ce cas la taille n'est plus optionnelle), puis de looper sur les arguments. Je te laisse ça en exercice ?

Je me réponds à moi-même : convert est effectivement assez intelligent pour retrouver le format des images.

frlanw0f03384:/tmp/a$ file *
Blue-5_4.jpg: JPEG image data, JFIF standard 1.02
fossil.png: PNG image data, 128 x 128, 8-bit/color RGB, non-interlaced
pattern-clouds.svg: XML 1.0 document text
frlanw0f03384:/tmp/a$ for I in *; do convert -resize 40% $I little_$I; done
convert: no image vector graphics `little_pattern-clouds.svg'.
frlanw0f03384:/tmp/a$ file *
Blue-5_4.jpg: JPEG image data, JFIF standard 1.02
fossil.png: PNG image data, 128 x 128, 8-bit/color RGB, non-interlaced
little_Blue-5_4.jpg: JPEG image data, JFIF standard 1.01
little_fossil.png: PNG image data, 51 x 51, 16-bit/color RGB, non-interlaced
pattern-clouds.svg: XML 1.0 document text

Bon, convert a buté sur le fichier SVG, il a dit qu'il ne savait pas comment le gérer et n'a rien fait. C'est pas le comportement qui t'intéresse ?

convert(1) n'est-il pas assez intelligent pour détecter le format d'entrée ? Par ailleurs, un fichier JPEG peut avoir une extension quelconque, comme l'a dit NeoX, mais même sans chercher bien loin : .jpg, .jpeg, .JPG, .Jpeg, etc. Pour répondre à la question, case permet de faire du matching limité :

$ while read line; do
> case $line in
> *.[Jj][Pp][Gg]|*.[Jj][Pp][Ee][Gg])
> echo "C'est un fichier JPEG (peut-être)"
> ;;
> *)
> echo "C'est pas du JPEG"
> ;;
> esac
> done
blah.png
C'est pas du JPEG
blah.jpeg
C'est un fichier JPEG (peut-être)
blah.JPG
C'est un fichier JPEG (peut-être)
blah.jpeg2000
C'est pas du JPEG

Sinon, dans sa forme le script me paraît améliorable :

#Pour vérifier s'il y a au moins 1 argument.
if [ $# -eq 0 ];then
echo "Veuillez entrer un nom de fichier"
else
#Pour déclarer le répertoire en cours comme lieu d'éxécution.
cd ./
fichiers=*.jpg
fi
fichiers=$1

Ceci signifie : si l'utilisateur ne donne aucun argument, alors on le dispute (mais on continue), sinon on met dans $fichiers la liste des .jpg du dossier. Mais de toute façon, à la ligne suivante on met dans $fichiers le premier argument (qui est peut-être vide, puisque si l'utilisateur n'a pas donné d'arguement on a décidé de continuer).

#Pour déclarer le répertoire en cours comme lieu d'éxécution.
cd ./

Que veux-tu faire là ? cd . est toujours un no-op (sauf cas très particulier). Donc ceci peut partir.

Et même "rmdir -p **/".

Mais comme l'a dit quelqu'un d'autre, c'est spécifique zsh. Avec une variation sur le find :

find /partage/echange -type d -print0 | xargs -0 rmdir -p \{\} \;

C'est rigolo, après les concours de "qui a la plus grosse", c'est le concours de "qui a la plus petite machine"...

Un souci d'un gestionnaire de paquets fonctionnant par deltas est la taille du dépôt des paquets (il me semble que sous Arch, ça avait été une opposition avancée contre le passage à une distribution par delta). En effet, si tu proposes la libtoto-1, quand la libtoto-2 sort, tu doit avoir sur ton dépôt non seulement libtoto-2, mais aussi libtoto-delta-1-2. Et quand libtoto-3 sort, tu dois avoir libtoto-delta-2-3, mais il serait aussi très intéressant d'avoir libtoto-delta-1-3 pour les utilisateurs qui ont raté une version (ou alors, les utilisateurs qui ratent une version sont obligés de reprendre un libtoto-3 tout frais ? mais dans ce cas on perd l'intérêt d'une distribution par delta...)

Dans la même veine : il est de bon goût de garder (pour des raisons d'archivage, d'audit des évolutions, tout ça) les versions passées des paquets. Donc dans l'exemple précédent, on aurait sur le dépôt libtoto-1, libtoto-2, libtoto-3, libtoto-delta-1-2, libtoto-delta-1-3, libtoto-delta-2-3... Rapidement on ne s'en sort plus.

Qu'est-ce que tu comptes faire pour ceci ? Ne supporter les mises à jour (donc la construction des delta) que entre la version courante et les 3 versions précédentes ?