fsfe-france
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fsfe-france] Rapport & Analyse personnelle sur le Serveur Libre et PeCo


From: loic
Subject: [Fsfe-france] Rapport & Analyse personnelle sur le Serveur Libre et PeCoVall
Date: Thu, 24 May 2001 00:09:38 +0200

[ 
  Je vois que les archives de la liste PeCoVall sont privées. Est-il
  possible d'y avoir accès ? 
  Pour info les archives de la mailing list savannah sont à 
  http://mail.gnu.org/pipermail/savannah-hackers/
]

        Merci de nous faire partager ton point de vue. J'ai commenté 
quelques points. 

 > nommé "VideoLan", très en avance en matière de 'streaming' vidéo,
 > démontrant par sa qualité technique et sa réalisation tout le bien
 > fondé que l'on peut avoir de l'image de cette école.

        Je pense qu'il faut décoreller totalement l'image de la personne,
entreprise ou université des resources techniques qui sont utilisées.
Si videolan hébergeait ses pages web sur ses propre serveurs tout en 
utilisant les resources techniques de sourceforge.net ou savannah.gnu.org,
l'impact serait exactement le même, la paternité du projet évidente.
        
        De très nombreux sites concernant un produit ont un nom de domaine
bien à eux et pointent sur sourceforge.net ou savannah.gnu.org quand il
s'agit d'accéder à l'arbre CVS, à la liste des tâches etc. Cela n'induit
aucune perte d'image. Si *toutes* les informations relatives au projet se
trouvent sur le serveur d'hébergement, y compris les pages web, alors il
y a une perte d'image.

        Supposer que l'utilisation de resources externes induit une perte
d'image à priori peut être handicapant. Si on pousse la logique dans 
ce sens, utiliser mailman induit une perte d'image puisqu'il s'agit 
d'une technologie dévelopée ailleurs. 
        
        Je pense qu'on est tous d'accord pour dire qu'il s'agit d'un
cas extrème que personne n'envisagerait. Mais supposons que cela soit
le cas malgré tout. Quelles solutions s'offrent à la personne qui veut
valoriser sont image tout en ayant un gestionaire de mailing list à
disposition ? En développer un à partir de rien. Ou alors contribuer à
Mailman et écrire des pages web sur son site web pour décrire la
teneur de ces contributions avec des pointeurs vers les parties
appropriées de Mailman ce qui démontre des capacités de dévelopement
et de travail coopératif. Ou encore faire tourner un serveur mailman
accessible à toutes et à tous qui met en avant des capacités
d'administration système.  Ou encore de participer à la maintenance et
à l'extension d'un serveur mailman accessible à toutes et à tous qui
démontre des capacités d'administration et de travail coopératif.

        Dans tous les cas de figure il est nécessaire de produire un
contenu rédactionel qui raconte et valorise ce qui a été fait et les
compétences que cela démontre. Je pense que la plateforme d'hébergement
présente exactement les même caractéristiques.

 > Mais, là encore une fois, cela nous oblige à nous doter d'un outil
 > irréprochable.

        A mon avis l'accent fort sur "irréprochable" renvoie à une
idée d'excellence qui n'existe nulle part dans le monde. sourceforge.net
comme savannah.gnu.org sont utilisés parcequ'ils sont utilisable. Un
espèce de serpent qui se mord la queue. L'un comme l'autre sont d'une
qualité très discutable par rapport à ce que l'on voudrait dans nos
rêves ;-)

 > Au début du développement (été 2000), il faut rappeler que SourceForge
 > n'était pas encore très accessible et ne pouvait donc pas constituer
 > de base de départ pour ce développement. Il a donc été décidé de débuter
 > la réalisation du "Serveur Libre".

        C'est un mauvais argument, je l'enlèverais tout simplement. 
Refaire à partir de rien était une erreur et SourceForge était déjà
très utilisable à cette époque. On fait tous des erreurs de ce
genre il ne me semble pas utile d'essayer de le justifier.

 >   * Il y a une amorce d'autoconfiguration de l'outil mais un tel programme
 >     reste évidement difficilement « empaquetable » et très spécifique.
 >     (à titre d'exemple, il m'a fallu trois jour pour installer correctement
 >     la solution sur ma machine personnelle).

        C'est à peu près le temps qu'il faut pour installer SourceForge
sur sa propre machine, un bon point pour les dévelopeurs donc.

 >   * Le code PHP est écrit de manière séquentielle (il n' y a qu'un
 >     seul petit module développé en objet) mélangeant de l'HTML et
 >     du code PHP. Cette particularité rend le code difficilement 
 > compréhensible
 >     et surtout difficilement extensible.

        La encore je souscrit à cette option de développement. Il
s'avère que c'est aussi le choix fait Tim Perdue pour SourceForge.net
(très peu de librairies, forte redondance du code). C'est une gestion
assez extrème du trade off structure du code/simplicité d'adaptation
qui permet un développement très rapide.

 > Autrement dit, je crée un fichier HTML avec quelques lignes PHP servant
 > à détruire le contenu des répertoires CVS, FTP, HTML que j'envoie
 > en tant que documentation et j'active ce script en regardant cette
 > documentation : Je détruis automatiquement et anonymement des milliers
 > d'heures de travail et de la même façon le 'Serveur Libre'. (J'ai
 > aussi testé cette affirmation).

        Heu ... il vaudrait peut être mieux fixer cela si ce n'est
déjà fait. 

 > L'accès CVS est actuellement donné par l'intermédiaire d'une requête
 > sur la base de données des utilisateurs. Ceci ne demande pas trop
 > de ressources pour quelques utilisateurs. Mais dans le cas d'une utilisation
 > plus poussée (30 projets), on peut émettre des doutes en ce qui concerne
 > la résistance du serveur Mysql : "Exemple : un commit général provoqué
 > par la fin des cours de 11h00".
 > 
 >  
 > 
 > Solution : Refaire le mode d'authentification : passer par des fichiers
 > temporaires.
 > 

        Peux-tu expliciter ? C'est peut être une idée interessante. 
CVS est très consomateur en mémoire et une solution permettant de
borner, accéler ou serier les commits serait intéressante.

 > De même, on déplore aucune documentation sur cette partie du projet.

        s/aucune/l'absence de/ ;-)

 > En vous reportant naturellement au chapitre précédent vous y trouverez
 > des problèmes cruciaux relatifs à la sécurité qu'il faut absolument
 > rectifier. 

        Les problèmes de sécurités sont monitorés et corrigés avec
fiabilité si et seulement si un serveur est dévelopé de façon
coopérative et publié sous une licence libre. Utiliser une plateforme
d'hébergement libre résoudra donc ce problème. C'est un des trois
bénéfices automatiques du dévelopement coopératif basé sur du Logiciel
Libre : sécurité/traduction/bug reports.

        Je dois partir manger. Suite plus tard.

-- 
Loic   Dachary         http://www.dachary.org/  address@hidden
24 av Secretan         http://www.senga.org/      address@hidden
75019    Paris         Tel: 33 1 42 45 09 16        address@hidden
        GPG Public Key: http://www.dachary.org/loic/gpg.txt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]