zaurus a écrit 105 commentaires

J'avais utilise leur module pour appeller des commandes unix.
J'avais fait du transcodage de video distribue avec (vlc en ayant coupe la video
au prealable).

Sinon, si tu peux ecrire tes taches comme des commandes unix et qu'Hadoop
ne convient pas, genre:
---
traiter_image.exe image1 -o image1.out
traiter_image.exe image2 -o image2.out
traiter_image.exe image3 -o image3.out
...
traiter_image.exe imageN -o imageN.out
---
Tu peux jeter un oeil a mon projet:

http://savannah.nongnu.org/projects/par/

Amuse-toi bien!
Francois.

A ce propos, je conseille a tous ceux qui sont pour le vote electronique
de lire ce papier de maitre Ken Thompson:

http://cm.bell-labs.com/who/ken/trust.html

J'adore cet article!
C'est un article qu'il a presente pour la remise de son prix "Turing award" je crois.
Ca donne a reflechir, vraiment...

J'aime bien la phrase: "The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)".

ATT lui aurait demande de mettre une backdoor dans la version qu'ils vendaient?
Suspense! :-D

Deja que je l'aimais pas cet environnement! :-D

1) je ne suis pas encore vieux :0)

2) je n'ai jamais ete pris en otage par un fonctionnaire, ou alors je souffre du syndrome
de Stockholm

Beau projet de recherche, il y a des resultats qui sortent
et qui font envie: genre le FS distribue.
En plus c'est libre: bravo et merci!

Je pense que le Google-Go est aussi adapte pour ce genre de processeurs:
certaines constructions du langage permettent de gerer le massivement multi-thread
(ce qu'ils appallent les goroutines).
De l'ordre de 100 000 par coeurs d'apres la video ou Rob Pike fait son speach de
presentation du langage.

Si vous telechargez les sources, il y a un test (un petit script shell).
Si vous regardez un peu ce qu'il fait, vous comprendrez comment
ca marche.

En gros, vous avez un fichier de commandes a executer.
Chaque commande est independante des autres (l'ordre, on s'en fiche donc).
Le script garantie juste que le plus de commandes possibles sont executees en
parallele sur la meme machine.

Ce qui ressemble le plus a ce que je fais, c'est xargs -P.

Pour l'instant le script s'appelle parallel.py.
Il n'y a pas de commande par donc.

Un exemple:

parallel.py -i commandes

'commandes' doit contenir quelque chose comme:

echo toto
echo titi
echo tata

Bien sur, c'est un exemple bateau juste pour montrer que ca
parrallelise bien l'execution.

C'est clair que les distributions a base de RPMs installent bien moins
vite que celles a base de deb.
Mon experience personnelle: mandrake, mandriva, fedora, redhat, debian, ubuntu.
Il est clair que celles utilisant deb installent plus vite et gerent mieux les dependances
et les mise a jour de paquets.
Ceci dit, j'ai essaye un BSD il y a peu. L'installeur etait pkg_add je crois.
Je suis reste sur le cul quand j'ai vu a quelle vitesse il installait un nouveau paquet,
c'etait impressionnant!

Le CNES utilise un soft comme ca pour verifier les softs embarques.
Je ne me rappelle plus du nom, mais je pourrais retrouver si ca interesse
quelqu'un.
Leur outil n'avait pas besoin d'annotations du code, par contre il fallait
preciser un processeur cible je crois.
J'avais lu un rapport issu de leur outil.

En plus de ce que propose de tester Pierre, je conseillerais aussi de tester une mise en veille et un reveil de la machine, avant d'essayer d'eteindre la machine donc. ;0)

C'est pour depasser une portee seulement francophone, tout simplement.

Un sujet connexe est les banques de temps:
des gens echangent du temps passe a faire des taches.

Par exemple: si tu donnes 1 heure de cours de bureautique a quelqu'un, tu aurais
le droit a 1 heure du temps de quelqu'un d'autre, pour apprendre le chinois par exemple.

J'avais vu un film la dessus, c'etait assez interessant, meme si un peu utopique.

Et decider de faire un soft portable des le debut, c'etait pas possible?

Je trouve qu'elle definit quelqu'un d'assez malin pour economiser ses efforts:

"Given a choice between spending an hour doing a task manually, or spending three hours writing a program to do it automatically... a geek will write the program, every single time."

La deuxieme partie definit un rebelle:

"And, if not given the choice, if explicitly ordered to do the job manually, we'll disobey and write the program anyway."

C'est donc la definition d'un rebelle malin,
qui est a mon avis un ensemble ne comprenant pas que des geeks.

Ici:

http://www.google.com/chrome/intl/en/linux.html

il est dit "Google Chrome for Linux is in development".
Et il y a plus de 6 mois de cela c'etait deja dans le meme etat...

Ben, quand tu profites d'un truc, il est bien de contribuer au bout d'un moment.
Histoire d'equilibrer la balance.
Genre t'achetes des DVDs/poster/T-shirt de ta distribution, tu leur fais un dont, etc.
Je trouve moche que la version de Chrome initiale ne soit que pour windows/MacOS.

Ca marche vraiment bien grid5000, ca restera un tres bon souvenir de l'INRIA pour moi.
J'adorais le fait de pouvoir deployer son propre OS sur plein de noeuds, tu etais
vraiment libre de faire ce que tu voulais des machines.

Par exemple l'IUP SI de la même université! ;)

Il serait normal que des étudiants en fin d'université
commencent à travailler sur des projets utiles
et permettant de mettre les pieds dans
des codes de taille consistante ainsi que de se frotter au
controle de version, entre autres exemples.

"Open Source" ne rime pas avec "manpower for free"...

Le but suivi par Alan est celui-ci:

"ce brevet serait le petit caillou déclenchant l'avalanche qui enterrera le DRM (de Microsoft, Apple et autres majors)"

Il essaie d'avoir un brevet surpassant tous ceux concernant les DRM, afin d'empêcher les majors de les utiliser.
Bien sûr, sa demande risque grandement d'être rejetée puisque c'est trop généraliste comme spécification.
A moins que l'office des brevets ne soit pas très doué...

Oui, le commentaire est faux.
D'ailleurs, il pourrait aussi y avoir une fonction

function usage ()
{
echo "usage: cvs_move [old_name] [new_name]"
}

à la place des echo "usage..." un peu partout

1) sur certains projets tu n'auras pas accès au serveur CVS et/ou tu n'auras pas les droits pour faire ce que tu dis
2) tu perds l'info de la position original de ton fichier
3) si tu filtres moins méchemment que nous le log CVS, tu peux ne pas perdre d'info de log dans les nouveaux ficiers. De plus, on ne fait que rajouter des choses dans CVS donc on ne perd pas d'infos.

Sinon, pour ceux qui sont un peu frileux: le 'cvs remove' et les 'rm' des fichiers temporaires créés sont laissés à la charge de l'utilisateur, c'est trop critique pour laisser le script faire ça automatiquement. De plus il y a une option --dry-run pour
se rassurer avant de lancer pour de vrai.

Imagine que tu es sur un gros projet qui existe déjà depuis longtemps.
Tu n'as peut-être (sûrement) pas la possibilité de faire changer le gestionnaire
de version de tout le projet (car pleins de scripts de déploiement impactés).
Donc c'est bien de dire que subversion c'est mieux et que les nouveaux projets
doivent peut-être utiliser ça plutôt que CVS, mais ce n'est pas ça qui t'aidera à bouger ton fichier sous CVS...