Vincent Danjean a écrit 132 commentaires

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.

Ça devient lassant de répéter la même chose sans que tu lises ce qu'on écrit. C'est mon dernier essai (surtout que pas mal d'autres ont déjà dit la même chose).

> Moi je suis allez le downloadé car j'y ai accès. C'est tout.
> J'ai une licence GPL pour utiliser Linux ?
> Oui ou non ?

Oui

> Il me faut obligatoirement la label "employeur" pour bénéfier de la GPL ?

Non

> > Seule l'entreprise qui a la licence GPL sur ce code peut distribuer ce code si elle le désire.

> Tu expliques ?

Elle l'a reçu (par accord, achat, téléchargement ou tout autre méthode qui te vient à l'esprit) de quelqu'un (entité physique ou morale) qui avait possédait ce logiciel avec cette licence (GPL) et donc avait le droit de donner/vendre ce logiciel sous cette licence.

N'importe quel utilisateur (employé ou pas) recevant ce logiciel sous licence GPL de quelqu'un en possédant déjà une licence GPL peut le redistribuer. MAIS il faut qu'il recoive cette licence.

Ici, ce n'est pas parce que l'entreprise a obtenu une licence (GPL) de son fournisseur que l'employé aussi. De même, ce n'est pas parce que le code ajouté est aussi sous licence GPL que l'employé a reçu une licence (GPL) pour utiliser (et redistribuer) ce code.

Ce que je veux dire, et que tu ne sembles pas comprendre, c'est qu'utiliser un logiciel (GPL ou non) de la part d'un employé ni signifie pas que cet employé possède une licence de ce logiciel, seulement que son entreprise en a une. Et sans licence, l'employé ne peut pas décider de diffuser ce logiciel (de quel droit le ferait-il ?). Ceci reste vrai quelque soit ce qu'il y a dans la licence accordée à l'entreprise.

Sinon, c'est que tu considères que l'employé a acquis une licence GPL sur le logiciel (qui lui donne le droit de le redistribuer). D'où provient alors cette licence ?
Si tu considères qu'elle provient du fait que son employeur lui a fournit ce logiciel, alors je comprends ta position, mais je ne la partage pas (ça me semble évident en considérant d'autres licences qui interdisent justement de sous licencier : un employé peut quand même utiliser les logiciels de sa boîte sans en avoir une licence personnellement).
Si tu considères qu'elle vient de l'utilisation du logiciel lui-même, c'est faux. Juridiquement, une licence est nécessairement cédée/vendue/donnée... par quelqu'un qui a le droit de le faire.
Si tu considères qu'elle vient d'ailleurs, dit moi d'où.

> - "je n'ai pas le droit de downloader (donc copier) Linux car je n'utilise pas Linux et donc la GPL ne s'applique pas."
>
> Reconnais que c'est ridicule.

Oui, ton arguement est ridicule. Linus (et les autres contributeurs) ont mis leur code en GPL ET ils le diffusent sur leur site (www.kernel.org ?). Ils sont les auteurs, ils peuvent diffuser comme bon leur semble.
Les propriétaires des serveurs FTP l'ont mis sur leur site parce qu'ils ont récupéré les sources avec une licence GPL donnée par les auteurs (ou un autre intermédiaire comme eux) leur permettant de les redistribuer (avec la même licence).
Par contre, les modifications, sous licence GPL, du noyau faites par une entreprise X, personne n'aura le droit de les diffuser tant que X ne les aura pas diffusées lui-même. Un pirate qui volerait les sources sur le réseau de l'entreprise ne possèderait pas pour autant la licence GPL les accompagnant. Une licence (GPL ou pas) est un contrat entre deux personnes (au moins). Voler, espionner, ... ne te permet pas de t'approprier ce contrat et de te servir de lui pour justifier d'autres actions (diffuser le code volé/intercepté).

Tu ne peux acquérir une licence d'utilisation d'un logiciel GPL qu'auprès d'une personne possédant une telle licence et acceptant de t'en vendre/donner une (par exemple auprès d'un mainteneur de site ftp en téléchargeant le logiciel proposé). Une fois que tu l'auras, tu pourras la céder comme bon te semble, mais il faut l'avoir avant. Et si une entreprise l'a, un employé ne l'a pas nécessairement même s'il utilise le logiciel.

> Oui. Mais toute personne qui a accès au programme a le droit de le copier/diffuser. Cette personne, peut être un employer.

D'abord, non. Ce n'est pas parce qu'on a accès à quelque chose qu'on peut le copier/diffuser. C'est, dans le cas qui nous occupe, parce qu'on a reçu (et accepté) une licence (GPL) qui nous authorise à le faire. Si on refuse la licence ou si cette licence ne nous est pas proposée, on ne peut pas copier/diffuser.

Dans ce cas présent, comme dis en détail dans d'autres contributions, c'est l'entreprise qui a la licence GPL sur le programme (modifié ou non). Évidemment, si le programme non modifié est distribué librement, alors il est facile à n'importe qui d'acquérir une licence GPL (avec tous les droits et devoirs que cela comporte).

Mais, lorsque le programme (ou ses modifications faites dans l'entreprise) ne sont pas distribuées, alors un employé ne peut pas distribuer ce code. Tout simplement parce qu'il n'a pas la licence qui lui permet de le faire. Seule l'entreprise qui a la licence GPL sur ce code peut distribuer ce code si elle le désire.

Maintenant, un juriste pourrait peut-être argumenter que l'entreprise a effectivement distribué le logiciel à ses employés, les rendant libre (par la GPL) de le rediffuser. Mais ça ne me semble pas vraiment tenable. Comme dit dans d'autres posts, une entreprise n'a pas à (voire même ne peut pas) re/sous licencier les logiciels pour lesquels elle a aquis une licence (fut-elle GPL ou propriétaire).

> Il est GPL ou pas ce programme ?

Le programme de base, probablement oui.

Mais je suppute que ce qui pose problème, ce sont les modifications que l'employé y apporte. SI il les distribue, alors ça sera nécessairement sous licence GPL. Mais encore faut-il qu'il en ait le droit. Pour cela, ses modifications doivent être sous une licence :
1) compatible avec la GPL (à cause du programme de base sous GPL)
2) compatible avec les règlements de son employeur (c'est du travail, pas du développement personnel)

Remarque en passant : si les deux sont incompatibles, alors le logiciel modifié n'est pas distribuable. Ce n'est pas spécifique aux logiciels propriétaires : c'est aussi le cas de logiciels composées de briques "libres", mais avec des licences incompatibles entre elles (exemple : Qt et GPL pendant un certain temps il me semble (à vérifier)).

Je pense que, lié par un contrat de travail, le code appartient à l'employeur. Ce dernier n'en est pas l'auteur, mais c'est lui qui choisit la licence à utiliser. Et tant qu'il ne le distribue pas, il n'est pas tenu de fournir les sources à qui que ce soit.

Reste pour les jusristes à définir si "utiliser du code appartenant à une entreprise au sein de cette entreprise" constitue une forme de distribution et permet (sous réserve que le code soit sous licence compatible GPL) aux employés de réclamer les sources pour les rediffuser eux-mêmes. Et là, ça me paraît beaucoup plus délicat à argumenter (et largement au delà de mes compérences)

A propos des licenses, je fais une thèse dans une équipe INRIA. Voici quelques observations que j'ai pu faire :

Les chercheurs autour de moi ne faisaient pas très attention aux licenses. Ça change pas mal ces dernières années, mais il faut bien comprendre que c'est quelque chose de récent. Je parle bien sûr des 'petits' codes. 'petits' n'est pas au sens de 'peu de ligne de code', mais 'développé pendant peu de temps' (une thèse, une tâche, ...)

Généralement, les chercheurs sont très contents si des personnes désirent utiliser leur code : ça fait tout plein de retour d'expérience, ce qui est souvent très profitable.

Par contre, il faut aussi comprendre que le travail de diffusion (packaging, documentation complète, publicité, ...) n'est pas très valorisable auprès de nos instances (sauf si le projet/code a déjà acquis une certaine notoriété). C'est pourquoi il faut généralement directement s'adresser aux équipes/développeurs pour avoir une doc un peu plus récente/à jour, ... Et tous les chercheurs ne sont pas prêts à s'investir sur leur temps libre pour faire ce travail de diffusion s'ils n'ont pas la certitude que ça intéressera un certain nombre de personnes. Énormément de code développé est abandonné au bout de quelque temps : des concepts sont validés et subsistent (dans d'autres projets/codes), mais le code de base est souvent archivé et laissé tel quel.


Autre remarque : l'INRIA est structurée en équipes (approximativement 5 à 20 personnes en moyenne) relativement indépendantes. Cela explique les nombreuses disparités dans les politiques de diffusion de code. L'INRIA (centrale) demande de faire remonter les logiciels diffusés (ceux de la page citée plus haut), mais toutes les équipes ne le font pas nécessairement : elles estiment parfois que leur code n'est pas prêt pour une diffusion (pas assez de doc, trop compliquer à compiler/installer sans aide, ...). Les choix de licences, supports, ... sont entièrement fixés par les équipes, pas par un 'bureau central'.

Pour le budget, ne pas perdre de vue que l'INRIA crée actuellement trois pôles supplémentaires (Lille,Saclay, Bordeaux) en plus des cinq autres déjà existants. Cela nécessite des moyens importants (nouveaux locaux et personnel (chercheur et administratif))

Si l'info vient bien d'une ligne de 'top', alors
1) il s'agit de 2h45 (et pas de 2 min 45)
2) il s'agit du temps CPU consommé (et pas de la durée de vie de l'appli)

Ça me semble parfaitement normal qu'une application interactive consomme peu de CPU. C'est le contraire qui serait étonnant/inquiétant.

Pour info, quand j'ouvre une page avec du flash (libé/lemonde), gkrellm passe de 1-4% à 15-20% de consommation CPU. J'essaye donc de penser à fermer les onglets contenant du flash quand j'ai fini de les lire (mais je laisse firefox ouvert).

Tu ne peux pas te renseigner un minimum quand on te fournit des objections pour les vérifier avant de les réfuter brutalement ?
http://packages.debian.org/stable/base/kernel-image-2.4.18-386(...)

Il y a peu d'importance : la plupart des sources de jpeg ont une taille en multiple de 16 (et pas 8 : certaines composantes n'ont par défault que 8 valeurs stockées pour 16 pixels), en particulier tous les appareils photos.
Cette limitation provient du format JPEG lui-même. Vu qu'il stocke l'image en la découpant en bloc, on ne peut pas tourner ces blocs sans les recompresser (ie refaire une FFT) si on change leur frontière.

Ça permet de calculer 0.1+0.1+0.1+...+0.1 (dix fois) et d'obtenir 1.0
En effet, 0.1 n'est pas représentable en binaire. Le BCD permet d'éviter des erreurs d'arrondi pour les calculs en base 10.

D'après le serveur ftp (http://security.debian.org/pool/updates/main/g/gaim/(...)), le packet a été installé le 28 janvier pour l'archi i386 (5 février pour mipsel).

A mon avis, ce qu'on peut reprocher à Debian, c'est de ne pas publier de DSA avant que les packets ne soient disponibles pour toutes les architectures. Mais que faire alors : un DSA pour la découverte du problème, puis un DSA pour chacun des nouveaux packets par architecture qui essayent de corriger le problème, puis un DSA pour le packet bien testé par architecture qui corrige le problème, puis un DSA quand tout est prêt (le seul actuel) ?
Pour ma part, bof, il suffit vérifier chaque jour qu'aucune mise à jour de sécurité n'est disponible. Et ça, ça se fait très bien avec une crontab pour la distrib stable.
Associé à apt-listchanges, ça permet de choisir si on veut la mise à jour où si on attend la version certifiée/testée.

ça ne risque pas. C'est plus malin que ça. Les chercheurs menacent de démissionner de leurs responsibilités administratives, pas de leur poste.

Or, une fois qu'un labo n'a plus de directeur, il ne peut (légalement) continuer à recevoir du monde : il n'y a plus personne pour couvrir la responsabilité des personnes présentes. La démission (administrative) des chercheurs, en particulier des grands chercheurs, aurait pour conséquence une complète désorganisation de la recherche publique française.

C'est ça qui peut faire peur au gouvernement : la menace ne dérange pas réellement les chercheurs sur le plan personnel, par contre ça gênerait énormément les structures administratives/le ministère. Le fait que tant de chercheurs avec des postes haut placés signent cette pétition montre l'ampleur des problèmes dans cette branche.

Quand je programme directement sur la ligne de commande, j'utilise cette technique. Quand je fais un script que je veux pouvoir débogguer facilement (ou lancer de temps à autre en étant sur de ne rien cassé), j'ai quelques techniques simples:

# SHOW est choisi (par édition ou avec une option quelconque)
# Ici on débug
SHOW=echo
# ici on fait l'opération
SHOW=
# et après, pour les étapes dangeureuses :
$SHOW rm  ...
$SHOW mv ...

Dans le même ordre d'idée, j'ai aussi :

run() {
    if [ "$verbose" = 1 ]; then
        echo -n "Running:"
        for arg; do
            echo -n " '$arg'"
        done
        echo
    fi
    "$@"
}