Vincent Danjean a écrit 143 commentaires

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.

Ce n'est pas des threads que tu veux alors. Ou du moins, pas des threads POSIX.
Rien dans la norme POSIX n'impose aux threads d'être gérés par le noyau. Ils peuvent très bien l'être par une bibliothèque en mode utilisateur (ou même un peu des deux : cf NGPT d'IBM il y a un ou deux ans). La protection mémoire étant gérée au niveau de l'OS, si les threads ne le sont pas, tu ne pourras pas avoir les fonctionnalités que tu demandes. Donc reste à shm si tu veux ça. Les threads POSIX permettent de partager toutes les ressources d'un processus par plusieurs flots d'exécution. Si tu ne veux pas de ce partage, n'utilise pas les threads.

Le serveur openloging fermera le 1er juillet. A cette date, le client libre fournit par BitMover permettra encore de récupérer les données et méta-données, mais aucun nouveau commit ne sera possible. Pour cela, il faudra utiliser une version payante de BK.
Donc tous les projets utilisant BK et voulant permettre des commit sans acheter de licence doivent migrer avant le 1er juillet

J'ai vu sur la page web que l'architecture ia64 était prévue (ajout de la base) mais apparemment pas du tout complète.
Il y a des infos sur ce support ? (abandonné, en attente de développeurs compétents, en attente de temps libre pour le faire, en attente d'utilisateurs potentiels (j'en suis un ;-), autre... )

L'UTF-16 et l'UTF-32 entre autres...

Oui, mais pour lire cette balise dans la page, encore faut-il pouvoir décoder le début de la page. Pour l'UTF-8, c'est cool : c'est comme l'ASCII (généralement les caractères accentués ou autres arrivent plus tard). Mais si le codage n'est pas compatible avec l'ASCII, ça se passe comment ? Le navigateur essaie tous les codages jusqu'à en trouver un bon ? Il demande à l'utilisateur ? Il demande au serveur ?

> > MAIS il faut qu'il recoive cette licence.
>
> Tu n' as pas lu la GPL.
>
> C'est le permier article :
> Article 1

Tu es toujours à côté de la plaque. Comme l'on dit pas mal de personne, il faut absolument que tu reviennes à la définition juridique d'une licence. C'est un contrat entre 2 personnes, régissant l'utilisation/diffusion/... d'un programme. Pas un texte attaché ad nihilo à un programme.
On parle souvent par abus de langage de programme GPL pour dire programme dont on peut acquérir une licence GPL en le téléchargeant sur un site publique.

> > Tu ne peux acquérir une licence d'utilisation d'un logiciel GPL qu'auprès d'une personne possédant une telle licence
>
> Qui sont-elles et comment fait-on pour avoir ce privilège ?

Soit c'est l'auteur : il peut fournir son code sous la licence qu'il veut, y compris la GPL.
Soit c'est une personne ayant une licence GPL qui le redistribue. Dans ce cas, du fait de la licence GPL elle-même, cette personne fournit automatiquement une licence GPL à toute personne à qui elle redistribue le logiciel. Si tu ne possèdes qu'une licence GPL (et pas d'autres licences) sur un logiciel, toute distribution s'accompagne automatiquement d'une licence GPL.

> > Une fois que tu l'auras, tu pourras la céder comme bon te semble, mais il faut l'avoir avant.
>
> C'est dramatique. J'utilise linux depuis de nombreux année en voyou. J'amais personne m'a donné une licence GPL.

Si, si. C'est juste que tu ne t'en es pas rendu compte. Heureusement, parce que sinon rien ne t'authoriserait à utiliser tous tes programmes

> S'il te plait, tu peux me donner l'adresse d'un fournisseur de licence GPL ?

Toute personne fournissant publiquement le code.

> L'employeur à la monopole des droits de la GPL.
> C'est fou de lire ça.
> Personne n'a lu la GPL ici ?

L'employeur a aquis une licence GPL. Pas l'employé. Du moins, pas par son travail. S'il aquiert une licence par un autre moyen (téléchargement sur un site ftp publique, ...), libre à lui de rediffuser son travail.

La licence GPL est une licence avant tout. On ne peut pas l'aquérir différemment des autres licences, c'est-à-dire de quelqu'un qui a le droit de nous la céder.