Bon étant donné l'engouement générale, je fais modifier un peu l'histoire. Il y actuellement deux personnes intéressées,  avec moi ça fait trois. Donc étant donné qu'on est trois intéressé, ça aurait été bien qu'on se voit.
Malheureusement Trim a eu un empêchement de dernière minute et on a donc annuler la rencontre (vu qu'on était que deux, on a discuter en point à point).

On va donc abandonner les dates prévues dans le poll doodle et s'organiser autour d'une liste de diffusion, je crois que c'est le meilleur moyen. Malheureusement n'ayant pas trouvé de solution suffisamment légère pour mon pauvre vps, je vais donc devoir juste développer le logiciel de liste de diffusion pour pouvoir en mettre en place une (et comme il y a férié qui vient je devrais avoir quelque chose (de suffisant) d'ici ce week-end).

Donc je suis déjà en contact avec les deux inscrits et tout ceux qui sont intéresse peuvent m'envoyer un mail, je les ajouterais à la liste de diffusion une fois celle-ci existante.

Si je n'arrive pas à avoir un outil fonctionnel d'ici ce week-end, je chercherais un service différent chez un fournisseur (je crois que j'ai accès à une liste "Sympa" sur un autre domaine).

Oui, est-ce qu'il y a du nouveau de ce côté là ?

Est-ce que les intéressés à la proposition de tchetch et tchetch lui même, ne voudrais pas rejoindre les forces qui commencent à ce mettre en place au niveau suisse ? voir http://www.durabilite-numerique.ch/

Suite à discussion avec OdyX, on s'est dis qu'il serait intéressant de prendre contact avec S. Fanti, l'avocat sédunois qui s'intéresse aux libertés numériques et à la protection de la vie privée. Je vais discuter avec le GULL pour organiser une soirée dans le cadre des cours du GULL avec cette personne.

Salut,
Est-ce que swisslinux n'a pas implémenté mailman http://www.list.org/
Meilleures salutations.

fbianco a écrit:

Et mailman ???

Pas de support LDAP (et de nouveau, langage de script, mon petit serveur va être sur les genoux (comme pour sympa))

fbianco a écrit:

Je voulais justement proposer au GULL de l'inviter pour une des soirées de "cours", est-ce que l'on pourrait utiliser ton contact si jamais ?

Ben je penses.

fbianco a écrit:

Et c'est pour ça que tu refais une autre liste cantonale ... pour que l'on travaille tous ensemble ?

Pour que l'on puisse agir sur les spécificités. Il est possible de faire, par exemple, passer une loi qui impose au canton d'utiliser un format libre et ouvert. Regarde la loi contre la fumée, c'est cantonal comme action et il y a de grande chance que cela finisse fédérale. Chaque canton a des représentant dans les deux chambres fédérales. Pour le Valais ça fait 9. Il faut donc aussi s'organiser au niveau cantonal pour avoir un impact fédéral. Maintenant le mail est un format interopérable, répandu, simple et sûre. C'est donc pas un frein à la communication. Ce qui est un frein c'est d'utiliser les forums, les blogs, ... C'est pas facilement exportable, pas possible de signer son message et surtout pas pratique.

fbianco a écrit:

Est-ce qu'avant de partir dans ta nouvelle quête de la liberté électronique en Valais, est-ce que tu songerai à rencontrer les associations existantes, genre le GULL et Swisslinux.org ? Tu avais proposé des dates de rencontre, mais avec un délai de même pas une semaine.

C'était pas interdit de mettre un commentaire pour dire "non tes dates ça va pas, tu pourrais pas proposer genre la période là à là". Je suis pas expert en organisation de réunion et à vrai dire j'ai de la peine à gérer ce genre de truc. Mais oui bien entendu que j'ai envie de faire une rencontre avec les différentes personnes intéressées.

fbianco a écrit:

Oui, je pense que le libre doit fonctionner de manière ouverte et transparente, mais si on veut coordonner certaine action il faut une liste fermée, sinon on ne pourrait même pas s'échanger de l'information confidentielle en avance. Donc cela accroît la transparence entre les différents groupes.

Si c'est confidentiel, il y a, par exemple, GnuPG qui permet de crypter ces communications, les mails point-à-point. Une liste de diffusion peut servir, par exemple, pour indiquer des dates de rencontres, proposer des idées, promouvoir les idées (l'utilisateur lambda qui tombe sur les archives pourraient être amené à découvrir ça). Il y a des choses à faire derrière des portes fermées, mais pas tout. Donc une liste ouverte est, amha, une nécessité absolue.
Par exemple la discussion qu'on a maintenant, elle pourrait avoir lieu sur une liste de discussion ouverte, il y a rien de secret.

BOFH a écrit:

et la (http://www.google.fr/search?q=mailman+ldap) y'a rien qui convient ?

Je suis assez peu pour ce genre de méthode de régulièrement dupliquer les données entre deux systèmes différents utilisant les mêmes données. J'ai envie de donner les informations nécessaires pour que le système sache où aller chercher ces informations et aille directement à la source.

BOFH a écrit:

A mon très humble avis, le gain de performance sur le CPU sera complètement occulté par la latence du réseau lors d'une requête LDAP.

La vitesse n'est pas à prendre en compte. Si tu as besoin de vitesse tu va soit mettre un openldap faisant du cache sur la machine accéder à travers le cache en local ou alors une réplication. Et pratiquement, si tu as ton serveur ldap sur une machine différentes de ton serveur de liste, il y a fort à parier que le réseau entre les deux machines soient à la hauteur pour ne pas être le goulet d'étranglement.
Et finalement l'utilisation d'une base sql, comme les autres serveurs font, à le même problème, sauf que les annuaires sont optimiser pour une lecture rapide. Donc, dans un sens, tu devrais aller plus vite avec un annuaire qu'une base sql.

A moins que le dit serveur aie été récupéré dans une décharge il y a 15 ans, mais à ce moment la le temps perdu en développement te coutera plus cher que l'achat de matériel neuf, non ?

Mais il n'y a pas de matériel. J'ai besoin de ça pour un serveur virtuel que je loue chez une société Suisse. J'ai pris l'option la moins chère et je compte pas investir plus (pour le moment). Dessus j'ai déjà pas mal de service qui tourne et je veux pas rajouter des services en langage de script. Lorsque je lance spamassassin ou sympa, j'ai un réel ralentissement de la machine qui se produit.
Le problème des ces solutions est surtout qu'elles incluent plein de fonctionnalité qui ne sont pas utiles et j'ai envie d'avoir une serveur de liste de diffusion simple, efficace et uniquement basé sur du ldap.
Le temps que je vais investir ne compte pas, je le fais pour avoir une solution qui me plaît et pour le plaisir en partie (c'est comme ça que fonctionne l'opensource non ?). Donc oui, le projet pourrait me coûter plus qu'une simple augmentation de mémoire sur mon VPS, mais c'est pas le but.
Et finalement si mon truc est bien et fonctionne d'autres gens pourraient avoir envie de l'utiliser et peut-être qu'il finira dans les dépôts de la majorité des distributions Linux, ce qui a plus de valeur que la centaine de francs que me coûteraient l'augmentation de mémoire sur mon VPS.

BOFH a écrit:

... <snip des 3 premiers paragraphes> ...

En fait le ralentissement est à vide. Pas de scan de mail, rien. Comme pour sympa. Le problème est que j'ai 256Mo de RAM, quand j'ai MySQL, openLDAP, Exim4, Apache2 et d'autres petits services qui tourne, il me reste peu de ressources en mémoire vive. Le processeur lui est largement suffisant. Une fois les services, en perl ou python, lancés, j'ai une chute dramatique dans mes ressources en mémoire.
Je pourrais me dire d'optimiser un peu, ce que j'ai fait pour apache, l'utilisation de la mémoire, mais j'ai pas le temps et le fait qu'un côté de moi à envie de faire un petit serveur de liste de diffusion ...
Le protocole LDAP est relativement léger et je n'ai jamais observer de latence imputable au protocole en lui-même, mais je ne l'ai jamais benchmarké ou quoique se soit de "scientifique".
Les langages de scripts sont assez lourds car il réclame un interpréteur chargé, qui n'est pas forcément léger. De plus ce genre de gros projets ont tendance à avoir un quantité de modules chargés ce qui alourdi encore plus. Mais de nouveau rien de scientifique, juste mon impression personnelle basée sur l'utilisation de ces services à vide.
Donc uniquement subjectif, mon observation.

BOFH a écrit:

Mais pour l'immense majorité des utilisateurs, le gain de performance du C n'a aucun intérêt, pour une tâche qui n'est clairement pas orientée CPU. Par contre, tu t'exposes volontairement à une classe entière de bugs et de failles (segfaults, buffer overflows, double free, memory leaks, injections diverses, et que sais-je encore); sans compter que tu passeras 90% de ton temps a écrire du boilerplate qui serait inutile dans un langage plus haut niveau. Tout ce temps pourrait être dévolu à améliorer ou alléger une solution existante...

Oui possible, mais j'ai tiré à pile ou face le langage ... Non plus sérieusement, mais justement, je penses que pour un système qui passe plus de temps à ne rien faire plutôt qu'à faire quelque chose, ça ne sert à rien d'avoir des ressources utilisées pour une machine virtuelle qui ne fait rien.
J'ai fait un test, très naïf. Lancer l'interpréteur python me mange 2M de ram. Pour rien, si ce n'est attendre un entrée de l'utilisateur. Je penses pas arriver à ça avec mon service à vide (si j'arrive à ça, ce serait un échec).
Je m'expose à plein de bugs super cool que je ne trouverais pas dans d'autres langages, peut-être, mais j'en suis pas certain. Et puis si c'est la peur du bug qui doit gouverner le développement logiciel, il y a plus personne qui en ferait.

Donc oui, c'est un serveur qui va utiliser le protocole LDAP, qui sera fait en C et opensourcer. Et rien ne me fera changer d'avis vu que toute la partie ldap est faites, que j'ai déjà un lecture des en-têtes des mails et qu'il me faut encore juste la partie smtp pour pouvoir dire qu'il s'agit d'un serveur de liste de diffusion (basique).

Hello, à sierre se déroule chaque samedi un marché ou il y quelques stand alors pourquoi ne pas en faire un pour le logiciel libre avec possibilité d'installer etc (si intéressé contacté moi par mail)