Vincent Danjean a écrit 132 commentaires

Vu tout ce que Koha utilise comme modules Perl, je ne pense pas que PHP soit aussi riche (ni ne le devienne dans un avenir proche) :-)

Sinon, a propos des dépendance de Koha 3.0 dans Debian, il y a tout dans lenny sauf quelques modules Perl (ajoutée trop tard dans Koha pour passer avant le freeze de lenny) et idzebra. Ces modules et idzebra sont dans unstable (et seront dans backports.org quand lenny sera sortie) [idzebra a été accepté par ftpmaster hier :-) ]

Le packaging de koha est assez bien avancé (visible dans un repo git du projet collab-maint d'alioth) mais il me manque quelques infos sur les divers scripts fournis ainsi que sur les fichiers de config. J'en discute tranquillement avec les gens de biblibre donc ça devrait se terminer assez rapidement (sauf que j'ai un peu moins de temps libre en ce moment)

Je n'ai pas encore eu le temps de me pencher dessus mais on m'a signalé qu'il y avait maintenant un mode parallèle expérimental pour la STL. Je ne sais pas non plus à quel point ça dépend de gcc 4.3 (ou pas) mais en tout cas, ça m'a l'air d'un truc intéressant à suivre.

http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html

Dans les entreprises, institutions, ... le mail est rarement émis par le poste de travail directement mais plutôt par un serveur mail. De même, le mail reçu l'est par un serveur (évenruellement le même) qui sotcke les messages et donne un accès par IMAP(S) (voire POP(S)).
Dans ces conditions, avoir un antivirus au niveau de ces serveurs permet d'éviter d'envoyer et/ou recevoir trop de virus. Et ce, quelque soit l'OS des postes de travail.

Autre exemple : si on fournit une redirection de mail (une série d'alias sans stockage de mail), il est important de filtrer les mails transitant par le serveur du domaine relayé sinon ce serveur risque de se faire marquer comme spammeur par les serveur SMTP auxquels il relaie ses mails.

Bref, il y a tout plein de raisons d'avoir un antivirus (pour toutes les plateformes) fonctionnant sous linux.

Le langage naturel est plus compliqué que la logique booléenne (sinon, les correcteurs syntaxiques seraient déjà là...).
Bref, même en laissant le sens booléen à l'élément de langage 'et' (sens "les deux"), la phrase "vous pouvez A et B" peut très bien être interprétée par "(vous pouvez A) et (vous pouvez B)" et non pas comme "vous pouvez (A et B)" Cette élision du langage naturel (supprimer le deuxième "vous pouvez") est très courante et c'est, il me semble, le sens classique que l'on donne à "vous pouvez A et B". Et je pense que c'est le sens que retiendrait le juge.

Quand tu indiques de commenter les deux lignes dans /usr/bin/test-windows-key, il faut aussi commenter le 'if' ... 'fi' ou bien
mettre une autre commande (':' par exemple).
En effet, bash n'accepte pas un then (ou un else) vide :

vdanjean@cayuga:~$ if test -x t ; then fi
bash: syntax error near unexpected token `fi'
vdanjean@cayuga:~$ if test -x t ; then ; fi
bash: syntax error near unexpected token `;'

Dernière petite chose : je ne connais pas d'implémentation de MPI qui soit threadsafe ET performante. Si quelqu'un en connaît une, ça m'intéresse.

Marcel+Madeleine+mpich=http://runtime.futurs.inria.fr/mpi/

Tu as testé ? Si tu as rencontré des cas pathologiques, ils seront intéressés par les infos. Et passe le bonjour de ma part à Marc ;-)

Pour geoffroy, "threadsafe ET performante" ça veut dire ne pas faire du tout d'attente active, recouvrir correctement calcul et comm, faire progresser les comm MPI pendant que les autres threads calculs, ...
A priori, LAM et Open MPI étaient assez décevants quand les processus avaient quelques centaines de threads de calcul... Ça peut-être changé, ça fait un moment que je n'ai pas regardé.

J'ai l'impression qu'il peut maintenant tracer la surface 3D d'un champ de données qui ne serait pas positionné sur une grille en x, y

C'est avec quoi que tu fais ça ?

Par ailleurs, est-ce que gnuplot peut maintenant faire des barres 3D ? Je ne sais pas si 'barre' est le bon terme, mais ayant des coordonnées x et y quelconques (pas sur une grille), je cherche à tracer à ces coordonnées des parallélépipèdes de hauteur z (en gros des immeubles de hauteur choisie à des coordonnées choisies).
Je me demande si le mode 'vectors' va (enfin) me permettre de faire ça.

Pour utiliser des CPU (ou coeurs) différent, il faut que le flot d'exécution soit géré par le noyau. C'est le cas des programmes classiques (monothreadés) ainsi que, pour le programmes multithreadés, des threads dits de niveau noyau. La bibliothèque de threads de linux ne propose que des threads de niveau noyau. Donc linux est capable d'assigner aux différents processeurs (ou coeurs) indifféremment un processus classique (monothreadé) ou un thread d'un processus multithreadé.

on a tous plusieurs dixaines de programmes qui tournent sur une machine donc un proc multi-coeurs va - de toute façon - accélérer le tout.

Regarde bien l'occupation de ton processeur (il y a plein d'applets pour ça). Tu verras qu'il passe une très grande partie de son temps à ne rien faire. Tu as beau avoir plein de processus 'qui tournent', ces processus sont généralement en attente d'événements (clic, touche clavier, timer, ...) et ils n'ont alors pas besoin du processeur.
Et quand ton processeur est vraiment occupé, il n'y a généralement alors qu'un seul programme qui en a besoin à ce moment (par exemple gcc peut facilement occuper 100% du CPU). Et pour accélérer ce programme (et te faire l'impression que ta machine va plus vite), alors il faut que ce programme utilise des threads. Il y a rarement plusieurs programmes qui tournent (au sens utilisent vraiment le CPU) systématiquement en même temps.

L'exception la plus classique est le serveur X qui doit répondre en même temps que tes applications quand ces dernières ont des choses à faire. Dans ce cas, avoir deux CPU permet effectivement au noyau de répartir ces deux tâches (l'application et le serveur X). On aura alors l'impression d'une amélioration beaucoup plus grande entre le passage de 1 à 2 CPU que de 2 à 4.
Avoir des CPU supplémentaires peut aussi être utile si tu as des programmes en tâche de fond qui consomment vraiment du CPU (lecteur mp3/divx, encodage mp3/divx, indexation automatique des documents de ta machine, ...)

Moralité, on n'optimise pas un programme pour ce truc, on le conçoit aux petits oignons ... c'est pour ça que tu n'est pas près d'en avoir un chez toi !

Ça dépend de quoi tu parles. Si c'est du programme applicatif, celui qui fait les calculs (calculs d'écoulement de fluides autour d'une voiture ou d'un avion, calculs de propagation d'ondes, ...), alors généralement non. Le but de ces programmes (écrits par les grosses entreprises) est d'avoir un code qui tournera pendant 20 ans. Donc on ne l'optimise pas pour une architecture particulière. Mais on l'écrira de manière à ce qu'il puisse être parallélisé facilement/efficacement.

On l'écrira donc en utilisant des couches de portabilité sur des environnements plus ou moins standards et/ou libres comme MPI ou PM2 ( http://runtime.futurs.inria.fr/pm2/ ). Et ces environnement là seront effectivement optimisés pour l'architecture ciblée.

Et ne peut-on pas imaginer que le compilo puisse s'occuper seul de la parallèlisation?
La réponse est non si on veut que la parallélisation soit efficace.
Il y a eu beaucoup (BEAUCOUP) de travaux de recherche sur ce thème. Je ne connais pas une seule équipe qui soutient encore que la parallélisation peut être faite entièrement automatiquement.

Par contre, il est certain que le compilateur et/ou le runtime peuvent aider grandement le programmeur en lui fournissant des outils ou des analyses partielles. La plupart des travaux de recherche sur le parallélisme que je connais vont dans cette direction.

Un programmeur a trop l'habitude d'une exécution séquentielle et d'une mémoire partagée pour qu'un outil puisse extraire automatiquement une version parallèle efficace de son programme en respectant exactement la sémantique du code séquentiel. Dès que le programmeur commence à mettre des annotations (ie dans cette fonction, je ne touche pas à l'état globale, je me contente de lire sans écrire ces variables, ...), une parallélisation automatique devient beaucoup plus envisageable.

Le compilo restera très utile pour détecter le parallélisme au niveau instruction (et remplir correctement les différentes unités de calcul du processeur ciblé). Mais il ne sera pas capable de paralléliser efficacement sans aide un programme 'classique'.

Athapascan1 n'est qu'une interface (simplifiée) de Kaapi maintenant.
La référence officielle est désormais cette page :
http://kaapi.gforge.inria.fr/
[la page du site d'www-id sera bientôt une redirection là bas]
Une nouvelle release de kaapi devrait être faite d'ici quelques semaines.
L'idée de kaapi/athapascan est que le programmeur décrit les dépendances entre les fonctions/modules de son programme. Le runtime kaapi s'occupe ensuite tout seul de l'exécuter en parallèle sur la ou les machines à sa disposition. Évidemment, c'est destiner à paralléliser des programmes de calcul. Si on veut des affichages graphiques (ou tout autre E/S sur une machine particulière), ça marchera moins bien (kaapi ne pourra pas déporter ces parties du calcul). Et bien sûr, kaapi ne trouvera pas de parallélisme s'il n'y en a pas dans le programme (ie dans la description des dépendances entre tâches).

Je n'ai pas encore vu le numéro en question, mais je vais probablement l'acheter. Si 01 informatique voit ses ventes augmenter avec un tel numéro, ça les incitera peut-être à parler plus souvent du LL.

FreeDOS n'a pas besoin de Linux pour tourner. On peut très bien booter (par D7, USBKey, CDROM, ...) sur un freeDOS pour lancer une mise à jour de BIOS.

Si tu veux qu'on regarde ton paquet, c'est le .dsc, le .orig.tar.gz et le .diff.gz qu'il faut fournir... Le .deb a peu d'intérêt (pour le packageur, c'est différent pour l'utilisateur)

J'ai déjà plusieurs paquets python dans Debian (mercurial, tailor, commit-tool). Si tu as besoin d'un coup de main, fait moi signe.

Dans la distrib officielle ? (J'ai vu passer un ITP sur hachoir juste avant que j'en fasse un)

Il faudra qu'ils soient validés par ftpmaster, ce qui peut prendre quelques jours (voire mois) en fonction de leur temps libre. Il y a moyen de voir les paquets sur un site perso en attendant ?

J'ai vu que le paquet Debian est sur le site du projet. Est-il prévu d'en faire un vrai paquet Debian (ie intégré dans la distribution) ?

pourquoi pas un simple :
apt-get install paje.app

On le trouve dans unstable/testing/stable (même si les versions sont un peu vieilles pour testing/stable.
Et sinon, recompiler à partir des sources du paquet Debian permet de profiter du travail d'adaptation du mainteneur pour Debian...

vdanjean@cayuga:~$ apt-cache search paje
paje.app - generic visualization tool (Gantt chart and more)
vdanjean@cayuga:~$ apt-cache policy paje.app
paje.app:
Installé : 1.4.0-1
Candidat : 1.4.0-1
Table de version :
*** 1.4.0-1 0
990 ftp://ftp.debian.org unstable/main Packages
100 /var/lib/dpkg/status
1.3.2-4 0
500 ftp://ftp.debian.org testing/main Packages
1.3.2-3 0
500 http://ftp.debian.org stable/main Packages

Les mutex utilisateurs (libpthread) n'ont strictement rien à voir (au niveau implémentation) avec les sémaphores (et maintenant mutex) du noyau.

Pour infos, dans l'ancienne libpthread (celle de Xavier Leroy), les mutex (utilisateurs) utilisaient les signaux pour communiquer (arrêt, redémarrage, ...). La nouvelle libpthread (nptl de Ulrich Drepper) utilise les futex (founis par les noyaux linux récents).

Pour rubber, voir mon poste en dessous. Je rajouterai cependant que je converti aussi à la volé les fichiers xfig. Je n'ai pas touché le metapost parce que je ne l'utilise pas, mais je ne vois pas de problème majeur à le gérer si on me donne un exemple à faire marcher.

Par rapport à latex-mk, je trouve qu'il ne répond absolument pas à ma problématique première : compiler automatique un document LaTeX en gérant correctement et automatiquement les dépendances (inclusions, bibliographies, index, glossaires, ...) (et donc oui, latex-utils recompile avec latex, lance bibtex, ... quand il faut et tant qu'il y en a besoin).

Oups, effectivement j'avais oublié l'URL. J'avais fait une dépêche avec les liens qui a été refusée, et j'ai oublié de remettre les liens dans le journal.
Il y a aussi ma page avec le paquet Debian :
http://dept-info.labri.fr/~danjean/deb.html#latex-utils

Par rapport à rubber, il y a deux choses qui me font éviter rubber :
1) d'après la doc de rubber "Dependency analysis is performed by parsing the source files" et ça ne marche jamais dès qu'on veut faire des choses un tant soit peu intéressante en LaTeX (noms de fichier à inclure générés par des macros, ...)
2) rubber me semble s'interfacer très mal avec un Makefile normal . Et je veux garder ça : parfois des bouts de mon document LaTeX sont générés par d'autres programmes (texifyc, ...). Je sais très bien exprimer ça en Makefile, pas avec rubber. Attention, c'est peut-être possible, je n'ai pas vérifier. Mais je n'avais pas envie de passer à un autre système de gestion de dépendances.

C'est le cas à l'heure actuelle, puisque chaque executable a son propre gecko. Avec Xulrunner ce n'est en principe pas le cas : chaque appli utilisant le même executable (xulrunner), donc les bibliothèques de xulrunner ne sont chargés qu'une fois en mêmoire.

Je ne comprends pas très bien ce paragraphe (ou plutôt j'en vois plusieurs interprétations). Si quelqu'un pouvait m'éclairer...

Est-ce que Xulrunner sera :
-(1) une bibliothèque partagée liées aux diverses application (firefox, ...)
-(2) un "demon" lancé par l'utilisateur utilisé par firefox, ... (communication par socket, mémoire partagée, ...)
-(3) une application qui charge dynamiquement les "modules" souhaités (firefox, ...)

Les trois formes permettent de partager le code en mémoire. Par contre, (2) nécessite d'avoir un logiciel vraiment déboggué (je n'ai pas envie que le plantage de "firefox" plante le demon et par suite les autres appli xul). (3) est encore pire puisqu'il faut que toutes les applis xul soient sans bug.

Est-ce qu'un modérateur pourrait corriger le lien sur l'Interview qui pointe actuellement sur la deuxième page de l'interview (remplacer le 2 par 1 à la fin de l'URL) ?

Les fichiers de debian sont par assez ennuyeux à lire par de simples scripts bash (à mon avis)...

Sous debian, normalement tout passe par ifup/dwon et le fichier /etc/network/interface. Il me semble que ça serait un bon angle pour intégrer : ifup eth0 profile=MonProfile En plus, ifup/down me semble assez répendu les les distrib maintenant, non ? (je n'en suis pas sûr ici) Pour moi, l'utilité d'un tel outil vient surtout du wifi où il faut fréquemment changer la config pour s'adapter à un nouveau réseau. Générer un fichier de config éditable pour une connection à partir de 'iwlist ethX scan' serait très intéressant. Pour ma part, j'utilise déjà les interfaces logiques de ifupdown pour configurer mes réseaux, mais à chaque nouveau réseau wifi, je dois rajouter quelques lignes dans /etc/network/interface :

iface home inet dhcp
#       wireless-mode ad-hoc
        wireless-essid XXX
        wireless-key XXXXXXXXX

iface otherhome inet dhcp
        wireless-essid YYYYY
        wireless-key YYYYYYYYYYYYYYYYYY

iface fac inet dhcp
        post-up vpnc-connect fac

iface workvpn inet dhcp
        wireless-essid ZZZZZZ
        pre-up /etc/init.d/cisco-vpnclient start
        post-up echo y | vpnclient connect ZZZZZZZZZZZ
        post-down /etc/init.d/cisco-vpnclient stop

iface workvpnvisit inet dhcp
        wireless-essid WWWWWWWWW
        wireless-key WWWWWWWWWWW

Et après, j'utilise ifup ethX=home, ifup ethX=fac, ... Le profile de netswitch sera vraiment capable de gérer le client vpnc, le client cisco (et oui, vpnc ne gère pas encore les certificats :-( ), ... ? Et les configs que je montre ici ne sont même pas très compliquées encore...

Concernant les fichiers de configuration, en effet, c'est un n-ième système car aucune distribution n'est capable de s'accorder sur ce point.

Bon, et bien ça a très peu de chances de m'intéresser en définitive. Pour moi, une "distribution compatible', ça voulait dire que ça s'intégrait bien dans la distribution en question (ie en respectant le placement des fichiers, en évitant de refaire ce que d'autres outils font, ...). J'espérai que votre outil joue pour le réseau un peu le rôle de resolvconf pour le DNS : il récupère les infos de config des divers fichiers standard de la distrib et les présente de manière'normalisée" aux différentes interfaces utilisateurs (graphiques ou non). S'il est encore plus puissant, il permet aussi l'autre sens (ie les interfaces modifient les config)
Évidemment, c'est autre chose que de simplement repartir sur de nouvelles bases en jettant l'existant.
Pour moi, l'intérêt d'un fichier 'Profile' à transporter est assez limité : pour une config simple, j'ai plus vite fait de taper les quelques commandes 'ifconfig/iwconfig/route/...' (qui existent sur toutes les distrib et fonctionnent de la même façon). Pour une config compliquée (tunnels VPN dans un réseau privé avec authentification par page web, ...), je n'ai pas encore vu de 'Profile' assez souple pour gérer correctement ça : il y a des dépendances entre les interfaces/Profiles (le réseau privé doit être mis en place avant les VPN, ...), les noms des interfaces changeront d'une machine à une autre, ... Même avec la souplesse de /etc/network/interface et les commande pre/post-up/down, il faut parfois rajouter des scripts perso.