castorpilot a écrit 98 commentaires

Avec certaines versions de netcat, l'option -u permet de passer en udp (tcp par default).

Et j'en profites pour répondre à la question :

awk 'NR == FNR{ligne[$1]=1} NR != FNR {if(!($1 in ligne))print}' file2 file1

ou en formaté correctement ;-)

NR == FNR { ligne[$1] = 1 }
NR != FNR {
if ( !($1 in ligne))
print
}

avec en entrée file2 file1

Explications :

l'astuce FNR == NR sert à savoir si on est en train de lire le premier fichier ou le second.
Donc si on est en train de lire file2, FNR == NR, et on remplit un tableau avec pour clef l'entrée qui se trouve sur la ligne.
Si on lit le second fichier (qui est en fait file1), on n'a plus qu'à verifier que la ligne lue n'était pas présente dans le fichier 2 (l'operateur "in" sur le tableau "ligne"). Si c'est le cas, on affiche la ligne.

Ce n'est pas pour troller, mais je pense que la solution la plus immediate est d'utiliser join, qui est explicitement fait pour ce cas de figure :-)

join -v 1 file1 file2

Eh, je me souviens de cette question prolog apparue sur le forum (il n'y en a pas tant que ça dans ce langage). Ravi d'avoir pu etre utile :-)

Sinon, tout à fait d'accord quant à l'efficacité de ce type de langage pour des problemes de ce genre. Pour avoir un peu bossé dans le domaine de l'embarqué et de la verification de circuit, ça peut etre vraiment utile.

Interessante en effet :)

Par default, Redmine dispose du necessaire pour la gestion de projet Agile type "Scrum" : burndown chart, diagramme de gantt, planning/calendrier, ...

Sous Trac, on retrouve ce type de d'outils avec ScrumBurndownPlugin.

Je viens de faire un commit sous git, et l'outil m'a donné la ligne suivante :

2 files changed, 380 insertions(+), 419 deletions(-)
rewrite file.c (62%)


J'ai repensé à ce thread. Je ne sais pas d'où git sors ce chiffre, mais c'est peut etre interressant de creuser dans cette direction.
En tout cas, une solution serait d'utiliser git :)

J'ai utilisé Trac et suis maintenant passé à Redmine.
Apres avoir lu le site et le wiki, je trouve Retrospectiva assez similaire à Redmine.

Quelqu'un aurait-il utilisé les deux ? Quels sont les differences, avantages, inconvenients de chacun ?

J'ai cette ligne dans mon .bashrc :

export _JAVA_OPTIONS="-Dawt.useSystemAAFontSettings=on"

J'ai cette ligne dans mon .bashrc :

export _JAVA_OPTIONS="-Dawt.useSystemAAFontSettings=on"

Je ne sais pas pourquoi, mais ça marche mieux avec un Java Sun qu'avec IcedTea.

Une petite question à ce sujet :

Comment est-ce que duplicity gere l'antagonisme crypté/rsync ?

A savoir, normalement, les algo de crypto sont prevus pour diffuser, de façon à ce qu'un petit changement fasse "avalanche". Cela met en general à genou les algos types rsync.

J'ai entendu parlé de rsyncrypto qui tente de resoudre ça en faisant du AES-CBC qui reboucle regulierement sur l'IV initial, sorte de ECB a large bloc.

Non, il vaut mieux quelque chose qui s'execute avec une vitesse parametrable, et qui bien sur a un espace IO suffisant. Evidemment, la lenteur de l'algo n'est pas la seule variable interessante, mais c'est un facteur determinant, sachant que quelque soit l'espace d'entrée, si tu es dans le cas d'un mot de passe, tu peux probablement donner comme limite superieure 100 caracteres ASCII (exemple au pif).
Pour ce qui est des attaques en hardware, c'est JUSTEMENT celles là que ces methodes essaient de contrer. Voici ce qui est ecrit sur la page de scrypt :

"We estimate that on modern (2009) hardware, if 5 seconds are spent computing a derived key, the cost of a hardware brute-force attack against scrypt is roughly 4000 times greater than the cost of a similar attack against bcrypt (to find the same password), and 20000 times greater than a similar attack against PBKDF2."

Pour preciser ce propos, comme ça l'a été demandé un peu plus bas, on pourrait meme dire : la vitesse est un PROBLEME pour les hashs de mots de passe.
Voir à ce sujet le billet "Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes" sur le blog matasano (apparement, leur site est hors ligne en ce moment, je ne donne donc pas de lien mort, le cache google est votre ami).

Pour resumer, la vitesse d'un algo utilisé pour du hash de mot de passe sert principalement l'attaquant, parce que ça va faciliter l'attaque "brute force".
Par exemple, passer 100 fois plus de temps à calculer le hash lors du login est generalement negligeable, mais ce meme temps passé en plus multiplie par 100 la durée d'une attaque exhaustive.
D'ou des algos genre bcrypt (dans OpenBSD), ou plus recemment scrypt (http://www.tarsnap.com/scrypt/).

Bien sur, ce n'est pas du tout l'objet du concours SHA-3 !

Pour les amateurs d'Orwell : achetez les bouquins !

sans vouloir entrer dans le troll, un facteur 2 n'est pas si etonnant que ça.
Ruby est en general plus lent que Perl, ne serait-ce que parce que l'interpreteur Perl est plus optimisé.
Ce probleme est connu de la communauté Ruby, et plusieurs projets tentent d'y remedier (cf. YARV, Jruby, ...).

Voici une idée de solution (non testée, à verifier) :

S'il s'agit juste d'eclater les blocs, c''est à) dire bloc 1 ecrit tel quel dans fichier.1, bloc 2 dans fichier.2, etc, alors il "suffit", lorsqu'on voit passer un '>', de changer le nom du fichier de sortie. Ce qui donne :

awk 'BEGIN{file = "bloc_file";i=0; fichier_courrant = file "." i} />/{i++ ; fichier_courrant = file "." i; next} {print > fichier_courrant}'

grosso modo : quand on voit passer ">", on incremente un compteur de blocs, i, puis on change le nom de fichier "bloc_file.i". next permet de passer direct à la ligne suivant, pour eviter le print.
En temps normal, on se contente de faire un print de la ligne lue dans le fichier courrant.
Le bloc BEGIN initialise les variables.

pas forcement en reponse directe à ton besoin, mais je mentionne quand meme :

Hudson est un outil d'integration continue assez efficace. (https://hudson.dev.java.net/).
Il permet de lancer des jobs (souvent des compilations et test, mais ça peut etre n'importe quoi).

- multi-plateforme (Java)
- Gestion des dependances entre jobs
- peut repartir les jobs sur plusieurs machines. Il est facile de "mettre en ligne" un noeud de calcul avec une interface web et un applet, pas besoin d'infrastructure "cluster".
- facile de voir les jobs (output console en live, statistiques)
- facile de les lancer (interface web, bouton "start").
- reporting agreable, stylme meteo : pour chaque projet : nuage si le jobs a fini sur une erreur, soleil si ça a marché ...

Et ça marche bien, relativement simple à mettre en place aussi.

ulimit permet de donner des limites de ressources aux programmes.
Dans ce cas, probablement les options -v et -s non ?

Electric Fence est une bibliotheque qui override malloc et permet de debugger.
En gros, les zones malloc'ées sont entouré par des barrieres, et le moindre overflow provoque direct un segfault.
Sans cette lib, un programme peut tres bien ecrire n'importe quoi n'importe ou, et le probleme survient 200 lignes de code plus tard ...

Tres pratique

Dans le fichier authorized_keys, placer un command="" avant la clef. Cette commande sera executée automatiquement à la connexion, puis la connexion s'arrete une fois la commande terminée.

On lit dans man sshd :

"This option might be useful to restrict certain public keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. "

ça me semble etre exactement ton cas !

exemple :

---- authorized_keys ----
command="ls" ssh-rsa AAAB3NzaC1yc2EAAAABIwAAAQEA7qpkG [...]

Il me semble que j'etais tombé sur le meme os en voulant aidé un ami egaré sous tcsh :)
En regardant de plus pres, j'ai l'impression que le probleme vient en effet de csh :
la commande jobs n'ecrit pas sur les descripteurs standards stdout et stderr, mais semble etre affiché "directement" sur le tty. Et donc n'est pas recuperable dans un pipe.

exemple : (tcsh)

[user@host ~]$ jobs
[1] + Running xclock
[user@host ~]$ jobs | grep xclock
[user@host ~]$ jobs |& grep xclock

Les deux commandes renvoient ... rien !

Solutions :

1) UTILISER UN SHELL TYPE SH !!!!
2) tricher en recuperant la liste des jobs sans la commande jobs : pgrep -P $$
soit : recuperer la liste des processus dont le parent a le PID du shell.

PS : pour info, la commande jobs de bash affiche sur stdout

Je precise :
si le but est de faire des additions de flottants sans flottants, il faut peut etre regarder du coté "fixed point arithmetic".

Bonjour,

je ne suis pas sur de bien saisir. Sur la plupart des processeurs, "l'algorithme" en question n'est pas réalisé au niveau du langage, mais par le processeur.
Dans le cas enoncé, le compilo va se contenter de generer les opcodes floating point, et ce sera au processeur de se debrouiller pour faire l'addition des flottants.
A part dans certains domaines particuliers, ce n'est pas au programmeur de s'occuper de gerer le bit de signe, l'exposant, et tout.
Pour avoir l'algo, je pense qu'il vaut mieux regarder directement le standard :
http://en.wikipedia.org/wiki/IEEE_754

Il me semble que sqlite lit directement les commandes depuis l'entrée standard.
Ton probleme initial (ranger les données depuis le fichier vers la base) peut donc se decomposer ainsi :

awk -F\| '{ print "update p_foret set s_matrice=" $2 " where parcelle="$1}' fichier | sqlite3 psg.db

Procmail ou maildrop semblent en effet repondre à ton probleme.
Ils te permettent de crée des "filtres" sur tes mails, directement au niveau du serveur.
Un exemple de regle maildrop (dans le fichier ~/.mailfilter) :

if (/^Subject:.*lesujetquivabien/:h)
{
exception {
to "|$HOME/bin/script"
}
}

A la reception du mail avec le sujet en question, sur l'adresse correspondant au compte qui a le .mailfilter dans son $HOME, le mail sera "pipé" au script. Apres, le script fait ce qu'il veut.

Merci beaucoup pour l'explication !
Conclusion : se fier plutot à [:upper:] et [:lower:], ou passer en locale LC_ALL=C
Encore merci

Merci encore d'avoir pris le temps de regarder ça.
Du coup, je ne sais pas trop à qui remonter le probleme. Sed ? Mandriva ?
Je vais essayer sur d'autres machines pour voir.