Vincent Danjean a écrit 150 commentaires

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.

Je n'ai pas regardé en détail l'application (juste les commentaires ici + les screenshots du site) donc je parle peut-être dans le vide. En tout cas, je n'ai pas trouvé rapidement le point qui m'intéresse, à savoir :
Est-ce que la config "naturelle" de la distrib est respectée ? Je ne voudrais pas avoir des réglages réseaux ailleurs que dans /etc/network/interfaces sur une Debian par exemple.

J'ai l'impression d'une n-ième réécriture d'un outil de configuration réseau, différent ce ce qui existait jusqu'à maintenant, donc incomptatible avec les autres outils (ifup/ifdown/...) utilisés par de nombreuses applis maintenant.
La sortie d'écran de la commande info me semble inutilement différente de celle pouvant être fournie par ifconfig/iwconfig par exemple.

Et qu'en est-il de la gestion des droits ? Est-ce qu'il faut être root pour choisir l'accès à un nouveau réseau wifi ? à un réseau wifi déjà existant/configuré ?
ou bien est-ce que l'appartenance à un groupe suffit ? Comment ça se passe si on a plusieurs sessions ? (ie qui monitore les réseaux wifi accessibles ?)
En gros, j'aimerais avoir tout plein d'info sur l'architecture de votre application. Ça me paraît BEAUCOUP plus important que les fonctionnalités que vous proposez actuellement (on peut toujours en rajouter si le code est bien conçu). J'irai peut-être lire votre code si je trouve un peu de temps libre pour avoir mes réponses (c'est tout l'intérêt du LL ;-) )

dans /etc/dhcp3/dhclient.conf, rajouter :

request smtp-server;

Ecrire un script dans /etc/dhcp3/dhclient-exit-hooks.d/smtp du genre :

#!/bin/sh

smtp_setup() {
        # No need to continue if we're called with an unsupported option

        if [ "$reason" != BOUND ] && [ "$reason" != RENEW ] \
           && [ "$reason" != REBIND ] && [ "$reason" != REBOOT ] \
           && [ "$reason" != EXPIRE ] && [ "$reason" != FAIL ]
        then
                return
        fi

        if [ -n "$new_smtp_server" ]; then
                echo "New smtp server : '$new_smtp_server'"
                server="$new_smtp_server"
        else
                server="son-serveur-avec-authentification" 
                echo "No smtp server : using default relay ($server)"
        fi
        old_server="`postconf -h relayhost`"
        if [ "$old_server" != "$server" ]; then
                postconf -e "relayhost=$server"
                invoke-rc.d postfix reload
        fi
}
smtp_setup

Ce que je n'aime pas dans cette solution :

• ne gère pas les configs non dhcp
• ne gère pas les connexions multiples (filiaire + wifi par exemple)
• pas assez souple dans la config (remplacer un serveur par un autre, choisir son serveur sur d'autres critères, ...)
• ne marche pas si dhcp n'envoie pas l'info (dhcpd mal configuré par l'administrateur du site)
• et bien sûr, le script en exemple est spécifique à postfix. Il faudrait faire la même chose pour les autres (exim[34], ...)

Je pense qu'il faudrait quelque chose de beaucoup plus souple. Un truc ressemblant à resolvconf me semblerait pas mal (en fait, il y aurait surement pas mal de chose à unifier/partager dans ces deux systèmes...) En fait, il y a plusieurs étapes :

1. Récupérer le/les serveurs smtp de l'interface (avec l'option dhcp, une config statique, ...), un peu comme resolvconf avec les réglages DNS ici.
2. choisir le smtp qu'on veut réellement utiliser (avec une config par défaut correcte) en fonction de la liste précédemment récolté et/ou des configs/règles locales (par exemple, essayer aussi smtp.'domaine' ou mail.'domaine'
3. mettre à jour la config des programmes qui en ont besoin (postfix, exim, ...)

Whitelister (https://projects.aaege.net/mailtools/wiki/Project.Whitelister)(...) permet comme effet de bord d'utiliser SPF avec postfix (c'est juste un démon externe, pas besoin de recompilation de postfix)

INRIA signifie Institut National de Recherche en Informatique et en Automatique. Des brevets en automatique pourraient être corrects, non ? Évidemment, sur LinuxFR, on ne voit pas beaucoup cette composante de l'INRIA...

J'ai fait rapidement un packet debian de cogito. Pour les gens intéressés, c'est ici :
http://dept-info.labri.fr/~danjean/deb.html#cogito(...)

Je t'ai juste rappelé que c'est faux: on peut aussi utiliser un spinlock même si c'est rarement plus efficace à cause du bouclage, en effet. Les spinlocks ont des inconvénients, et je ne les aime pas plus que toi.

Ça fait un bout de temps que je vous regarde vous étriper sur les mutex/spinlock.
Quelques remarques :
1) Conceptuellement, mutex et spinlock, c'est très semblable. Les spinlock peuvent être vus comme une implémentation particulière de mutex à base d'attente active. Si le processeur possède des instructions atomiques, il est possible d'implémenter les spinlock entièrement en espace utilisateur. Seul pb: risque d'occupation indue du processeur. Risque de deadlock également si les priorités 'hard' des deux flots d'exécution sont différentes.
2) Pour synchroniser des flots d'exécution parallèle (j'entends par là "gérés par l'ordonnanceur du noyau"), l'arbitrage du l'ordonnanceur du noyau est indispensable pour éviter le problème évoqué précédemment (attente active, risque de consommation du CPU pour rien, deadlock, ...)
3) Depuis les noyaux 2.6 (peut-être pas les premiers), Linux contient les 'futex'. Ils permettent de synchroniser des flots d'exécution parallèle en restant en espace utilisateur s'il n'y a pas de contention et en demandant l'arbitrage du noyau dans le cas contraire. A noter que ce mécanisme ne suppose pas que les flots partagent la même VM. La nouvelle libpthread (nptl) permet ainsi de faire de la synchro entre threads d'applications différentes grâce à des futex placés dans une zone de mémoire partagé (cf pthread_mutexattr_setpshared())

Enfin, une remarque générale. Les problèmes de synchro sont globalement les mêmes entre threads ou process avec mémoire partagée. L'intérêt des threads étant qu'il y a déjà beaucoup d'outils dispo (mutex, sémaphores, ...) qui utilisent les futex (crucial pour avoir de bonnes perf dans un maximum de cas).
Avec les process à mémoire partagée, il faudra réécrire ces outils (c'est peut-être déjà fait, mais je ne connais pas). En outre, le code de démarrage/arrêt est plus compliqué : il faut gérer des 'objets' extérieurs au processus, donc l'initialisation et la destruction à la terminaison est plus délicate. Pour les threads, l'initialisation se déroule naturellement au démarrage lorsque les threads ne sont pas encore créés, et la destruction est faite par l'OS à la destruction du processus.

Et pour finir, ne pas oublier qu'avec la mémoire partagée, rien ne certifie a priori qu'elle sera mappée au même endroit : cela oblige à manipuler des handle plutôt que des pointeurs, ce qui peut être source d'une indirection supplémentaire (et de complexification du code et des structures de données)

Ça prouve bien le sérieux de l'étude : « Trust me, I'm a doctor. »

En france, les titres sont très peu utilisés. Ce n'est pas le cas dans de nombreux autres pays.