unix4fun

Alors je sais pas ce que ca vaut, mais j'avais besoin d'un hash sur un petit bloc de donnees et de maniere repetee, et surtout dont le resultat reste sur 32 ou 64bits avec une bonne distribution pour "eviter","limiter" les collisions.

Apres avoir teste sha1 et md5, et bon en le rapellant trop souvent c'est quand meme un ptit peu lent.

poz ou ppr m'ont parle de ca, y a longtemps il me semble :

http://isthe.com/chongo/tech/comp/fnv/

si y a des gens avec de l'experience et un peu matheux, qui veulent bien commenter :)

Des p'tites infos et projets interessants au cours de mon joujou avec ma sunblade 1500.

Deja je me suis fait chier avec SunStudio mais en fait j'ai decouvert ca (trop tard!): http://cooltools.sunsource.net/gcc/

Pour les petits documents utiles :

• http://wikis.sun.com/display/SunStudio/Dwarf+Differences+between+Sun+Studio+and+GCC+compilers
• http://developers.sun.com/sunstudio/documentation/ss11/mr/READMEs/c++_faq.html

Sinon j'imagine que comme d'hab je suis le dernier a decouvrir ca mais y a pleins de trucs convi a lire :

http://wikis.sun.com/dashboard.action

Y a des gens qui comme moise (toute ressemblance serait purement fortuite) qui arrivent a separer la mer en deux pour faire passer des trucs, parait que moise c'etait pour faire passer des gens (eh oui moise est un passeur, mais il avait rendu le passage industriel avant meme qu'on y pense!)

Alors la y a Kristaps Džonsons qui fait pareil avec du code, il matte le code, hope ca se separe en deux, meme en trois, attendez.. c'est quoi ces histoires !?!?!?

(en gros il a pris un NetBSD et il a fait un truc qui sent les "zone" de solaris ou jail chez freebsd ( oui oui c'est pas implemente pareil, la granularite est pas pareil, c'est pas le meme systeme tout ca tout ca, mais je parle de concepts...))

sinon y a des projets "un peu" similaire ou related genre : ca ou ca

moi qui refais du C en ce moment, alors me voila a me replonger avec plaisir la dedans, je savais plus ce que ca definissait exactement const et volatile, qqes souvenirs, j'ai vite relu ca rapidos et pouf c'est revenu..

have fun!

Je sais pas si vous avez remarqué, mais depuis quelques jours, c'est l'hiver. Il fait froid et tout. C'est donc avec joie que j'accueille tous les moyens de me réchauffer... Et un truc (SUPER VIEUX) mais qui fait chauffer les méninges, c'est le très connu Project Euler .

L'idée, c'est qu'il y a 174 (bientôt 175) problèmes à résoudre ; il suffit de donner la réponse, peu importe la méthode employée. On peut coder en C, J, Python, OCaml (Yeah baby !), utiliser Matlab, etc.

J'ai vite fait commencé le 24 décembre (non, je n'ai pas d'amis ni de famille, c'est d'ailleurs pour ça que je poste des news ici.. paskeu l'autre il me volait mes billes quand j'étais petit et... hum je m'égare.), et c'est rigolo. Etant donné qu'il s'agît d'un challenge, on va éviter de poster les réponses ici hein.

C'est enfin publie, ils ont reussi a obtenir (comprendre generer) deux codes, deux binaires distinct avec un hash md5 identique et ca se passe ici pour des details :

http://www.win.tue.nl/hashclash/SoftIntCodeSign/

Un livre aupres du quel j'ai appris les faibles bases du fonctionnement des reseaux de neuronnes, recommande par un ami a l'epoque pour que j'apprenne.

Les reseaux de neuronnes artificiels : introduction par Claude Touzet

encore une fois on est pas doue pour les horaires tout ca, mais mieux vaut tard que jamais hein! :)

Ce week-end, à imprimer et lire :

• Automatic Vulnerability Detection Using Static Source Code Analysis par Alexander Ivanov Sotirov. Le pépeur porte bien son nom et est derrière la théorie de vulncheck -- on me traitera peut-être de fainéasse, mais l'idée d'eau pour le WEF est excellente. Comme il est assez consistant, ça devrait tenir votre week-end. PDF. 118 pages.
• Oui, c'est tout : je paye une bière à celui qui le finit dans le week-end.

Au sommaire de uninformed #8 :

• Covert Communications : Real-time Steganography with RTP
• Engineering in Reverse : PatchGuard Reloaded: A Brief Analysis of PatchGuard Version 3
• Exploitation Technology : Getting out of Jail: Escaping Internet Explorer Protected Mode, OS X Kernel-mode Exploitation in a Weekend
• Rootkits : A Catalog of Windows Local Kernel-mode Backdoors
• Static Analysis : Generalizing Data Flow Information

Avec eau (aka. Le Frelon Dardé du Gabon) on discutait d'une appli en développement basée sur python et la pylibpcap. Le modèle de l'application était composé de deux threads : une thread pour l'envoi de paquets et une thread utilisant pcap pour la réception. Le problème de ce modèle appliqué à python est que cette application ne pouvait pas marcher "as is" : la thread d'envoi ne pouvait pas démarrer car la pylibpcap acquiert le GIL (Global Interpreter Lock) et ne le libère jamais. En d'autres termes : la thread d'envoi n'était jamais démarré et python se consacrait à la thread de réception qui, du coup, ne recevait rien.

Petite explication nécessaire : les développeurs de Python ont décidé de développer un interpréteur qui n'est pas thread-safe, pour la simplicité. Cependant, pour tout de même proposer des threads, il leur a été nécessaire de créer un lock, global, entre elles. Chaque thread acquiert donc ce lock (le GIL) exécute un nombre donné (et configurable) d'instructions python, puis libère le GIL. De l'extérieur tout se passe comme si les threads étaient exécutées séquentiellement pendant un certain nombre d'instructions plutôt que parallèlement. C'est la raison d'un des plus gros trolls sur python, après l'indentation : le GIL.

La réponse de Guido van Rossum, le BDFL de python est toujours la même : n'utilisez pas de threads, développez plusieurs processus et faites les communiquer par IPC. C'est un des éléments de la philosophie python et les arguments de Guido sont nombreux.

Donc, en ce qui concerne l'application en développement, plutôt que de patcher la pylibpcap, il est peut-être plus intéressant de développer l'application dans un modèle "à la python" avec un processus d'écoute qui transmet à un processus de traitement les paquets lus, par IPC.

L'intérêt n'est pas de décider si le GIL est une bonne ou une mauvaise idée mais de comprendre pourquoi il est là et la philosophie du langage quand on a à l'utiliser. Donc, voici les quelques ressources citées dans l'article, pour ceux qui veulent en savoir plus :

1. Python/C API Reference Manual, Thread State and the Global Interpreter Lock, http://docs.python.org/api/threads.html
2. python-list, pylibpcap and multiple threads : http://mail.python.org/pipermail/python-list/2005-January/303798.html
3. Needled by Threads : http://cleverdevil.org/computing/30/needled-by-threads
4. python-3000, the future of the GIL : http://mail.python.org/pipermail/python-3000/2007-May/007414.html