Jiehong a écrit 592 commentaires

Je parle de l'acquisition en question…

Sh en mode interactif n'est plus très utilisé. Ce qui fait que tu as tendance à connaitre Bash et Sh si tu fais des scripts (historique, alias, contrôle des processus, etc.)
Ensuite, les tests mathématiques en Sh, non merci.

En outre, le /bin/sh est souvent un lien vers /bin/bash dans une partie des distributions (dans mon Archlinux par exemple)

Enfin, il faut bien avancer un peu. À quand une mise-à-jour de POSIX ?

Bref, c'est un choix personnel.

J'ai pas de debian sous la main, mais c'est le {..} qui passe pas avec les arguments en variable. Ainsi, for i in {"$a".."$b"} devient for i in "{24..36}", ce qui ne fait qu'une seule boucle, et ne renvoie rien du coup.

Du coup, je m'excuse pour le seq, car soit tu utilises un $(seq "$a" "$b"), ou $(eval echo "{$a..$b}"). Bash doit évaluer 2 fois la demande.

Bref, voici la version finale pour le coup (et désolé…) :

#!/bin/bash
# recupere la liste des paquets à desinstaller à partir des parametres.

# VERSION sera 3.x.y
VERSION="$1"

# DEBUT et FIN seront les variantes (le z dans 3.x.y-z de la version du paquet)
DEBUT="$2"
FIN="$3"

# on fait une boucle sur la sequence comprise entre $DEBUT et $FIN avec l'outil seq
# pour chaque valeur de la boucle, on fait cherche les paquets correspondants avec dpkg -l | grep...
# on filtre cette liste pour ne recuperer que la 2e colonne de la sortie de dpkg avec awk

LISTE=$(for i in $(seq "$DEBUT" "$FIN"); do dpkg -l | grep "$VERSION-$i" | awk '{print $2}'; done)

# on demande à aptitude de purger tous les paquets que l'on a listés juste avant.
echo "$LISTE"

Ça devrait marcher, si tu pouvais confirmer.

Bon, je vais faire mon chieur, mais tu devrais changer quelques trucs niveau habitudes (pour Bash) :

1) Les backquotes sont un reliquat d'un temps révolu. Remplace-les par $(…)
2) Même remarque pour la commande seq. Tu peux la remplacer avantageusement par {1..3} par exemple
3) Quotes! Si tu veux t'éviter des bogues bien piquantes (bash séparer les noms constitués d'espaces entre autres), je te conseille vivement de changer tes appels de variables : "$VAR".
4) il n'y a pas de première ligne indiquant l'interpréteur ! #!/bin/bash

Ça donnerait ça (pas testé, mais ça devrait aller tout seul ) :

#!/bin/bash
# recupere la liste des paquets à desinstaller à partir des parametres.

# VERSION sera 3.x.y
VERSION="$1"

# DEBUT et FIN seront les variantes (le z dans 3.x.y-z de la version du paquet)
DEBUT="$2"
FIN="$3"

# on fait une boucle sur la sequence comprise entre $DEBUT et $FIN avec l'outil seq
# pour chaque valeur de la boucle, on fait cherche les paquets correspondants avec dpkg -l | grep...
# on filtre cette liste pour ne recuperer que la 2e colonne de la sortie de dpkg avec awk

LISTE=$(for i in {"$DEBUT".."$FIN"}; do dpkg -l | grep "$VERSION-$i" | awk '{print $2}'; done)

# on demande à aptitude de purger tous les paquets que l'on a listés juste avant.
sudo aptitude purge "$LISTE"

Elle n'a qu'à pas poster des annonces sur un site qui n'est manifestement pas fait pour ça. De plus, accepter les critiques, et la liberté d'expression de tout un chacun est ce qu'il y a de plus fondamental. Il faudrait peut-être apprendre ça d'abord.

La majorité des langages de programmation sont fait par des Américains, et ce n'est donc pas du tout pris en compte.

Il est souvent possible d'afficher la valeurs correctement en fonction de tes variables locales, comme avec Python, mais le calcul se fera toujours avec des points.

De plus, les virgules sont souvent utilisées en tant que séparateurs pour les listes, etc.

Exemple en Python:

1.2 + 3 = 4.2
1,2 + 3 = (1, 5)
float("1,2".replace(",","."))+3 = 4.2

Utiliser la virgule signifierait changer toute la syntaxe du langage ici.

J'ai regarder Linotte, un langage en français, mais c'est construit par dessus Python, alors le problème reste le même.

En cherchant rapidement sur Google, on trouve que, par exemple, l'Iphone 4 serait l'auteur de 45 kg de CO2 au cours de sa vie.

Est-ce beaucoup ? C'est ~10 % des émissions allouables sur 1 année pour 1 personne.

C'est pas si négligeable je trouve (et c'est aussi à mettre en regard avec une voiture, ou un ordinateur de bureau, ou la viande rouge…)

Équitable ≠ bon pour l'environnement.

Le commerce équitable propose d'y penser, mais c'est optionnel. Le commerce équitable n'a pour seul but que celui de diminuer les disparités économiques.

Pour un écologiste, un café devrait être bio, et équitable (tant qu'à faire) (et même produit localement, car être bio ne signifie pas être produit localement aussi bizarrement que celui puisse paraître).

À quand un ordiphone bio et équitable ? Un jour peut-être… ou pas.

Si on regarde en arrière, c'est plutôt rare d'avoir des temps si frais.

Il est fort possible que le passage à l'été va se faire comme un échelon : d'un coup !

C'est pas clés en main, mais c'est sympa, bien fait, et simple à utiliser en python : matplotlib

Il faudrait donc unifier les chemins, et la logique sous-jacente. Je crois, en fait, que cette démarche aboutirait à la création d'une seule distribution, puisque peu de choses pourraient distinguer deux distributions basées sur une « architecture » de paquet unifiée.

L'éclectisme des distributions actuelles est aussi une force que je voudrais pas voir disparaître…

pour résumer, la notion de paquets est dépassée car les distributions veulent contrôler beaucoup trop, sont donc trop lentes à intégrer de nouveaux venus ou simplement les mises à jours.

Étant sous Archlinux, cet avis est simplement fallacieux pour moi. D'ailleurs, le système des paquets fait que les mises-à-jours sont plus régulières, et mieux suivies.

Par contre, l'idée de paquet universel —  standard et adopté par la majorité des distributions — a vraiment du sens ( et non fait du sens, hein). Cela faciliterait grandement la tâche des contributeurs, mais aussi des distributions. Ça implique de regrouper les plus grands acteurs des distributions libres autour d'une table, et de se mettre d'accord sur le fond, mais aussi la forme pour gérer tous les cas. C'est ça l'avenir pour moi.

Rappels :
Million ---> M
Milliard --> Md ou Mrd

J'en profite pour demander quelques corrections sur cette dépêche :

• les apostrophes doivent être changées de "" vers «  »
• « L'ancien mécanisme d'extension est toujours supporté mais… » ---> « L'ancien mécanisme d'extension est toujours pris en charge, mais…
• cross-compilation --> compilation croisée
• débugger --> débogueur

Ni la grammaire :P

C'est bien de supporter IPv6 pour qu'il soit utilisé partout. Ainsi, c'est vraiment une demande de prise en charge…

Oui, bon, je sors --->[]

C'est exactement ce que je fais : j'utilise des phrases de 5 mots au moins. C'est assez simple à retenir je trouve, et efficace (majuscule en début de phrase, ponctuation en fin, et pourquoi pas des chiffres, hein.)

Par contre, que faire quand un site nous fait chier pour des caractères spéciaux, mais qu'il n'accepte pas les mots de passe trop long ? (c'est idiot).

J'ai aussi pensé à utiliser Unicode parfois. Comme par exemple avoir des mots de passe en caractères chinois.

J'utilise aussi un mot de passe test au début : c'est un mot de passe que je changerai, après avoir testé le site, et pour savoir s'il m'envoie mon mot de passe ou pas. Si c'est le cas, je me désinscrit.

Au démarrage et à l'extinction, il me semble que des fichiers journaux sont écrit, et chaque ligne est datée.

J'ai eu le même soucis. Au début, on se dit qu'on va pouvoir aider ! Mais une grande partie des choses est déjà faite.

Finalement, je me suis rendu compte qu'il manque une grande partie des numéros des bâtiments, ainsi que leurs noms.

J'habitais un village de campagne qui n'est pas fait du tout, alors j'en fait une partie de temps en temps par dessus l'imagerie Bing, en utilisant ma mémoire, et en vérifiant des noms de rue sur Google Maps par exemple.

Mais je me fait toujours avoir par le temps : il m'en faut toujours beaucoup plus que je ne le pensais à chaque fois.

Il y a donc ASCIIMathML.js qui semblerait simple aussi.

Il y a aussi jsMath dans le même esprit.

Ça fait plaisir de voir une dépêche sur DragonFly BSD !

Cependant, je me demande si elle a vraiment été relue par les modérateurs, car elle contient pas mal de fôtes qui passent quand on est fatigué…

Voici mon score :
0.04s user 0.22s system 15% cpu 1.710 total

C'est quasiment identique, mais plus général avec xargs. Voici ce que j'obtiens chez moi :

Sachant que find -name "*.h" | wc -l donne 3711.

Ex : time grep -r --include "*.h" 'include' . > /dev/null
0.10s user 0.56s system 28% cpu 2.324 total

Ex : time find -name "*.h" | xargs grep 'include' > /dev/null
find -name "*.h" 0.04s user 0.08s system 11% cpu 1.004 total
xargs grep 'include' > /dev/null 0.04s user 0.08s system 8% cpu 1.408 total
Soit 2.4s.

Ex : time find -name "*.h" -exec grep 'include' {} \; > /dev/null
0.04s user 0.38s system 6% cpu 6.529 total

J'ai testé Ack pendant un temps au boulot, mais j'ai trouvé ça trop lent.

De manière générale, je créer un alias comme celui-ci :
alias grep='grep --line-buffered --color=auto -s -P'

Ensuite, pour sélectionner par type de fichier, je me fis aux extensions :
find -name "*.py" | xargs grep 'Hello'

De plus, je préfère comment Grep surligne le résultat.