Consideration sur les notions de facilite de configuration
Le
Yannick Patois
En francais, Bonjour,
A mon tour de demarrer le troll de l'ete.
Je vais tenter de definir le contexte dans lequel je me place, puis par
rapport a ce contexte de definir une notion de "facilite de
configuration", et voir ensuite comment elle s'applique aux systemes
existants et conclure.
Tout d'abord, le contexte. Je ne m'interesse pas ici aux hackers, mais
bien aux personnes non specialites et qui ne le seront jamais mais qui
doivent utiliser et configurer leur ordinateur au quotidien (cas de la
plupart des ordinateurs familiaux). Ces personnes ont aucunes notions
theoriques en informatique, et une experience limite des systemes
d'exploitation. De plus elles n'ont ni le temps ni la motivation d'en
apprendre beaucoup.
Fournir a ces personnes un systeme fiable, robuste qu'ils puissent
utiliser sans faire trop appel a une aide exterieur me parait important.
Je vais definir la Facilite de Configuration pour Non Experts (FCNE),
par rapport a la population defini precedemment: qu'est-ce qui pour elle
sera plus simple ?
Bien sur, toute generalisation est abusive, et je risque de me planter
parfois, j'espere toutefois arriver a exprimer des tendances averees.
Mais tout d'abord, un peu de definitions.
Soit \Omega l'ensemble des etats de configurations possibles sur une
machine. Je restreint volontairement \Omega aux elements
"configurables", meme si cette notion reste un peu flou, je pense que le
discours reste valide si l'on etends \Omega a l'ensemble des etats
possibles (en gros 2^{40.10^9*8}*2^{256*2^20*8}*2^10, en imaginant un
disque dur de 40Go, 256 Mo de RAM et environ 1000 etats de la PROM).
L'etat E0 est un etat initial fonctionnel de la machine. Ce peut etre
l'etat juste apres installation du systeme, ou mieux, l'etat juste
*avant* installation du systeme, mais je prendrai la premiere
definition, moins generale mais qui possede plus de proprietes
interessante et suffit a la discussion.
Un sous-ensemble de \Omega est \Omega_{ok}, qui sont les etats dans
lequel le systeme fonctionne de maniere satisfaisante pour
l'utilisateur. Cette notion est tres floue mais ne peut etre evitee dans
la mesure ou c'est celle qui preocupe l'utilisateur. Nous allons
cependant nous interesser a un sous-ensemble un peu plus large mais
mieux defini, \Omega_{okc} qui est le sous-ensemble des etats de
configurations dans lesquels l'utilisateur a acces au systeme de
configuration de maniere totalement fonctionnel (il permet d'acceder a
l'ensemble des etats de configuration, ceci suppose bien sur que celui
ci soit stable - voir ci-dessous -).
\Omega_{ok} etant tres vague quoi que central, je vais introduire
\Omega_{coherent}, qui est l'ensemble des etats de configuration qui
sont fonctionnels et susceptible de repondre au besoin d'un utilisateur
non expert (par exemple, un etat dans lequel apache charge le module php
mais dans lequel aucunes extensions n'a ete defini pour l'appeler n'est
pas coherent).
Le systeme de configuration est une fonction F_c qui fait passer le
systeme d'un etat E1 vers un etat E2 (E1, E2 inclus dans \Omega) sous
l'action de l'utilisateur.
Un systeme de configuration donnee ne permet pas forcement d'adresser
tout \Omega, mais plus probablement un sous-ensemble \Omega_{Fc(E0)}
depuis un etat initial E0 (accessible en une ou plusieurs etapes, par
exemple, E3ü_2(Fc_{1}(E0)) appartient bien a \Omega_{Fc(E0)}.
Simplification d'ecriture: \Omega_{Fc(E0)} sera ecrit \Omega0 dans la suite.
Je dis que le systeme de configuration est stable si quelque soit E_1 et
E_2 appartenant a \Omega0 alors il exite une serie fini de
transformation Fc_i tel que E_2=O_{tous les i}Fc_i (E_1) (O est ici la
composition de fonctions: Fc_1(Fc_2(Fc_3(.Fc_i(E1)).
- Il est evident que \Omega0 est inclus dans \Omega_{okc}, l'inverse
n'est pas forcement vrais: jette par des vent mauvais dans un etat E1
hors de \Omega0, il est possible qu'une serie de fonctions Fc nous y
ramene, c'est meme souhaitable (sinon le systeme doit etre repare par un
expert).
- Avoir un systeme de configuration stable est important. L'inverse veut
dire que l'on peu arriver dans des etats dont on ne peut plus revenir.
- Un systeme de configuration performant minimise probablement le nombre
d'etapes pour passer d'un etat a un autre.
- Une intervention exterieur (reboot sur CD ou disquette) est elle dans
\Omega0 ? Pour la discussion, je considererai que non, meme si en
pratique c'est parfois difficilement evitable. Ceci parce que sinon on a
trivialement \Omega0=\Omega, meme si c'est pas forcement "facile" a
obtenir. C'est pour cela aussi que \Omega0 a ete defini comme l'etat
*apres* installation. De la meme facon, un reboot en "mode sans echec"
ou avec des arguments autres que ceux par defaut sera considere comme
hors \Omega0 (essentiellement parceque ce sont des etats que
l'utilisateur non expert ne veut pas avoir a connaitre).
Dans la pratique, bien des systemes de configurations ne sont pas
stables (mettre "0" comme runlevel par defaut, par exemple).
Passons maintenant aux axiomes:
*** A/ Je pretends ici que si \Omega0 est inclus dans \Omega_{okc} la
FCNE est meilleure.
En francais, cela signifie que le systeme est plus simple a configurer
pour un non expert si quelque soit les erreurs que celui-ci fait, il se
retrouve toujours dans un etat ou il peut la corriger a partir de son
interface de configuration.
Justification: L'utilisateur non expert fera des erreurs (l'expert
aussi, mais moins et il aura access a des methodes d'experts pour les
corriger), si ces erreurs peuvent ammener la machine dans un etat ou le
systeme de configuration qu'il connait ne marche plus, il est coince et
doit faire appel a un expert.
*** B/ Je pretends que si \Omega0 est inclus dans \Omega_{coherent} la
FCNE est meilleure.
En francais, cela veut dire que le systeme est plus simple a configurer
si aucune fonction de configuration accessible ne peut mettre le systeme
dans un etat qui serait d'aucun interet pour un utilisateur non expert.
Limitation: j'aurais aime mettre \Omega_{ok}, mais cela me semble
impossible, il y a a developper la dessus, en gros, il faut que
l'interface de configuration lui presente des choix qu'il puisse
comprendre afin de les faire dans son interet.
Justification: en gros la meme que ci-dessus.
*** C/ Je pretends ici que plus l'ensemble des Fc est reduite meilleurs
est la FCNE.
Il doit exister peu de manieres differentes d'arriver dans un meme etat
E afin de ne pas compliquer la tache d'apprentissage.
- Considerations pour le hacker
Le hacker veut un controle maximal sur sa machine, pour lui, plus
\Omega0 se rapproche de \Omega, plus il est heureux, meme si en
contrepartis son systeme de configuration n'est plus stable, voir meme
peut planter serieusement.
Pour lui \Omega_{okc} se limite a "je peux deplanter en rebootant sur un
CD de rescue", et \Omega_{coherent}, il le fait avec ses petits doigts.
On voit deja que cela se distingue serieusement de ce que j'ai presente
des souhaits de l'utilisateur non expert.
- Consequences pratiques
* La configuration texte n'est pas adaptee a l'utilisateur non expert.
Justification: la config texte casse souvent les axiomes A et B et
toujours C.
Exemple, un fichier de config avec cette ligne:
RhostsAuthentication no
Casser C:
RhostsAuthentication no
RhostsAuthentication no
RhostsAuthentication no
RhostsAuthentication NO
(Une multitude de fonctions de configs ammene au meme resultat)
Casser B:
RhostsAuthentication yes
(L'utilisateur familial n'a pas besoin de cette option)
RhostsAuthentication Oui
RhostsAuthentication @#78)*&2
(ces deux entrees sont invalides, sshd se casse la figure, le systeme
est hors \Omega_{coherent})
Pour casser A, il faut suffit de modifier un fichier de config de base.
Par exemple, mettre dans un des script d'init la chaine:
reboot
- Qualites d'une interface graphique
Le gros probleme des interfaces graphiques de configuration sous linux,
et que souvent leur \Omega0g (espace de configuration accessible par
l'interface graphique) est:
a- tres petite devant \Omega0t (configuration par interface texte)
b- Ne couvre pas \Omega_{coherent}, ni meme \Omega_{ok}
a/ On y peut rien, on sait que c'est comme ca, c'est meme voulu.
b/ Tant que \Omega0g n'atteint pas \Omega_{ok}, le systeme est non
administrable par un utilisateur non expert.
Par contre, elles sont souvent assez bonne sur:
c/ stable
d/ inclus dans \Omega_{coherent}
Malheureusement, ce n'est pas parfait ici non plus, or ces points sont
cruciaux.
Pour moi, c'est sur le point b/ qu'il faut mettre les efforts dans la
mesure ou l'on souhaite pouvoir confier des machine a un environemment
non expoert type familial.
- Pour conclure, comparaison (subjective).
- Sous MacOS <10, on a \Omega0g a peu pres egal a \Omega_{coherent},
mais insufisant pour couvrir \Omega_{ok}. Tres stable et sort peu de
\Omega_{coherent}.
- Sous MacOS X, on a \Omega0g plus reduit que \Omega_{coherent}, mais
ouvrant a peu pres \Omega_{ok}, et \Omega0t, pour completer.
- Sous Windows, on a \Omega0g plus reduit que \Omega_{coherent},
probablement insufisant pour \Omega_{ok}, completer tient du cauchemar.
- Sous Linux, on a \Omega0g tres petit devant \Omega_{coherent},
totalement insufisant pour \Omega_{ok}, \Omega0t complete parfaitement.
Bref bref bref
Yannick, qui a sans doute ecrit pas mal de conneries
--
_/ Yannick Patois \___________________________________________________
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: patois@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |
A mon tour de demarrer le troll de l'ete.
Je vais tenter de definir le contexte dans lequel je me place, puis par
rapport a ce contexte de definir une notion de "facilite de
configuration", et voir ensuite comment elle s'applique aux systemes
existants et conclure.
Tout d'abord, le contexte. Je ne m'interesse pas ici aux hackers, mais
bien aux personnes non specialites et qui ne le seront jamais mais qui
doivent utiliser et configurer leur ordinateur au quotidien (cas de la
plupart des ordinateurs familiaux). Ces personnes ont aucunes notions
theoriques en informatique, et une experience limite des systemes
d'exploitation. De plus elles n'ont ni le temps ni la motivation d'en
apprendre beaucoup.
Fournir a ces personnes un systeme fiable, robuste qu'ils puissent
utiliser sans faire trop appel a une aide exterieur me parait important.
Je vais definir la Facilite de Configuration pour Non Experts (FCNE),
par rapport a la population defini precedemment: qu'est-ce qui pour elle
sera plus simple ?
Bien sur, toute generalisation est abusive, et je risque de me planter
parfois, j'espere toutefois arriver a exprimer des tendances averees.
Mais tout d'abord, un peu de definitions.
Soit \Omega l'ensemble des etats de configurations possibles sur une
machine. Je restreint volontairement \Omega aux elements
"configurables", meme si cette notion reste un peu flou, je pense que le
discours reste valide si l'on etends \Omega a l'ensemble des etats
possibles (en gros 2^{40.10^9*8}*2^{256*2^20*8}*2^10, en imaginant un
disque dur de 40Go, 256 Mo de RAM et environ 1000 etats de la PROM).
L'etat E0 est un etat initial fonctionnel de la machine. Ce peut etre
l'etat juste apres installation du systeme, ou mieux, l'etat juste
*avant* installation du systeme, mais je prendrai la premiere
definition, moins generale mais qui possede plus de proprietes
interessante et suffit a la discussion.
Un sous-ensemble de \Omega est \Omega_{ok}, qui sont les etats dans
lequel le systeme fonctionne de maniere satisfaisante pour
l'utilisateur. Cette notion est tres floue mais ne peut etre evitee dans
la mesure ou c'est celle qui preocupe l'utilisateur. Nous allons
cependant nous interesser a un sous-ensemble un peu plus large mais
mieux defini, \Omega_{okc} qui est le sous-ensemble des etats de
configurations dans lesquels l'utilisateur a acces au systeme de
configuration de maniere totalement fonctionnel (il permet d'acceder a
l'ensemble des etats de configuration, ceci suppose bien sur que celui
ci soit stable - voir ci-dessous -).
\Omega_{ok} etant tres vague quoi que central, je vais introduire
\Omega_{coherent}, qui est l'ensemble des etats de configuration qui
sont fonctionnels et susceptible de repondre au besoin d'un utilisateur
non expert (par exemple, un etat dans lequel apache charge le module php
mais dans lequel aucunes extensions n'a ete defini pour l'appeler n'est
pas coherent).
Le systeme de configuration est une fonction F_c qui fait passer le
systeme d'un etat E1 vers un etat E2 (E1, E2 inclus dans \Omega) sous
l'action de l'utilisateur.
Un systeme de configuration donnee ne permet pas forcement d'adresser
tout \Omega, mais plus probablement un sous-ensemble \Omega_{Fc(E0)}
depuis un etat initial E0 (accessible en une ou plusieurs etapes, par
exemple, E3ü_2(Fc_{1}(E0)) appartient bien a \Omega_{Fc(E0)}.
Simplification d'ecriture: \Omega_{Fc(E0)} sera ecrit \Omega0 dans la suite.
Je dis que le systeme de configuration est stable si quelque soit E_1 et
E_2 appartenant a \Omega0 alors il exite une serie fini de
transformation Fc_i tel que E_2=O_{tous les i}Fc_i (E_1) (O est ici la
composition de fonctions: Fc_1(Fc_2(Fc_3(.Fc_i(E1)).
- Il est evident que \Omega0 est inclus dans \Omega_{okc}, l'inverse
n'est pas forcement vrais: jette par des vent mauvais dans un etat E1
hors de \Omega0, il est possible qu'une serie de fonctions Fc nous y
ramene, c'est meme souhaitable (sinon le systeme doit etre repare par un
expert).
- Avoir un systeme de configuration stable est important. L'inverse veut
dire que l'on peu arriver dans des etats dont on ne peut plus revenir.
- Un systeme de configuration performant minimise probablement le nombre
d'etapes pour passer d'un etat a un autre.
- Une intervention exterieur (reboot sur CD ou disquette) est elle dans
\Omega0 ? Pour la discussion, je considererai que non, meme si en
pratique c'est parfois difficilement evitable. Ceci parce que sinon on a
trivialement \Omega0=\Omega, meme si c'est pas forcement "facile" a
obtenir. C'est pour cela aussi que \Omega0 a ete defini comme l'etat
*apres* installation. De la meme facon, un reboot en "mode sans echec"
ou avec des arguments autres que ceux par defaut sera considere comme
hors \Omega0 (essentiellement parceque ce sont des etats que
l'utilisateur non expert ne veut pas avoir a connaitre).
Dans la pratique, bien des systemes de configurations ne sont pas
stables (mettre "0" comme runlevel par defaut, par exemple).
Passons maintenant aux axiomes:
*** A/ Je pretends ici que si \Omega0 est inclus dans \Omega_{okc} la
FCNE est meilleure.
En francais, cela signifie que le systeme est plus simple a configurer
pour un non expert si quelque soit les erreurs que celui-ci fait, il se
retrouve toujours dans un etat ou il peut la corriger a partir de son
interface de configuration.
Justification: L'utilisateur non expert fera des erreurs (l'expert
aussi, mais moins et il aura access a des methodes d'experts pour les
corriger), si ces erreurs peuvent ammener la machine dans un etat ou le
systeme de configuration qu'il connait ne marche plus, il est coince et
doit faire appel a un expert.
*** B/ Je pretends que si \Omega0 est inclus dans \Omega_{coherent} la
FCNE est meilleure.
En francais, cela veut dire que le systeme est plus simple a configurer
si aucune fonction de configuration accessible ne peut mettre le systeme
dans un etat qui serait d'aucun interet pour un utilisateur non expert.
Limitation: j'aurais aime mettre \Omega_{ok}, mais cela me semble
impossible, il y a a developper la dessus, en gros, il faut que
l'interface de configuration lui presente des choix qu'il puisse
comprendre afin de les faire dans son interet.
Justification: en gros la meme que ci-dessus.
*** C/ Je pretends ici que plus l'ensemble des Fc est reduite meilleurs
est la FCNE.
Il doit exister peu de manieres differentes d'arriver dans un meme etat
E afin de ne pas compliquer la tache d'apprentissage.
- Considerations pour le hacker
Le hacker veut un controle maximal sur sa machine, pour lui, plus
\Omega0 se rapproche de \Omega, plus il est heureux, meme si en
contrepartis son systeme de configuration n'est plus stable, voir meme
peut planter serieusement.
Pour lui \Omega_{okc} se limite a "je peux deplanter en rebootant sur un
CD de rescue", et \Omega_{coherent}, il le fait avec ses petits doigts.
On voit deja que cela se distingue serieusement de ce que j'ai presente
des souhaits de l'utilisateur non expert.
- Consequences pratiques
* La configuration texte n'est pas adaptee a l'utilisateur non expert.
Justification: la config texte casse souvent les axiomes A et B et
toujours C.
Exemple, un fichier de config avec cette ligne:
RhostsAuthentication no
Casser C:
RhostsAuthentication no
RhostsAuthentication no
RhostsAuthentication no
RhostsAuthentication NO
(Une multitude de fonctions de configs ammene au meme resultat)
Casser B:
RhostsAuthentication yes
(L'utilisateur familial n'a pas besoin de cette option)
RhostsAuthentication Oui
RhostsAuthentication @#78)*&2
(ces deux entrees sont invalides, sshd se casse la figure, le systeme
est hors \Omega_{coherent})
Pour casser A, il faut suffit de modifier un fichier de config de base.
Par exemple, mettre dans un des script d'init la chaine:
reboot
- Qualites d'une interface graphique
Le gros probleme des interfaces graphiques de configuration sous linux,
et que souvent leur \Omega0g (espace de configuration accessible par
l'interface graphique) est:
a- tres petite devant \Omega0t (configuration par interface texte)
b- Ne couvre pas \Omega_{coherent}, ni meme \Omega_{ok}
a/ On y peut rien, on sait que c'est comme ca, c'est meme voulu.
b/ Tant que \Omega0g n'atteint pas \Omega_{ok}, le systeme est non
administrable par un utilisateur non expert.
Par contre, elles sont souvent assez bonne sur:
c/ stable
d/ inclus dans \Omega_{coherent}
Malheureusement, ce n'est pas parfait ici non plus, or ces points sont
cruciaux.
Pour moi, c'est sur le point b/ qu'il faut mettre les efforts dans la
mesure ou l'on souhaite pouvoir confier des machine a un environemment
non expoert type familial.
- Pour conclure, comparaison (subjective).
- Sous MacOS <10, on a \Omega0g a peu pres egal a \Omega_{coherent},
mais insufisant pour couvrir \Omega_{ok}. Tres stable et sort peu de
\Omega_{coherent}.
- Sous MacOS X, on a \Omega0g plus reduit que \Omega_{coherent}, mais
ouvrant a peu pres \Omega_{ok}, et \Omega0t, pour completer.
- Sous Windows, on a \Omega0g plus reduit que \Omega_{coherent},
probablement insufisant pour \Omega_{ok}, completer tient du cauchemar.
- Sous Linux, on a \Omega0g tres petit devant \Omega_{coherent},
totalement insufisant pour \Omega_{ok}, \Omega0t complete parfaitement.
Bref bref bref
Yannick, qui a sans doute ecrit pas mal de conneries
--
_/ Yannick Patois \___________________________________________________
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: patois@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |
Poser une question
perso, je dis pas mal. J'ai rien compris.
nico
Tentative d'interprétation:
Un bon système de configuration pour un non informaticien
est un système de configuration graphique qui garanti
que toute modification de la configuration laissera l'application
en état de fonctionner.
Là où je ne rejoint pas l'auteur est sur la nécessité de l'interface
graphique.
Je pense qu'un fichier texte peut fonctionner aussi bien, dans la mesure
où l'application refuse de démarrer avec un fichier invalide. Par
contre, une application sera non-expert-friendly si et seulement si elle
est capable de redonner au non-expert la dernière configuration qui
fonctionnait (voire un historique des dernières configurations).
Je ne nie pas l'utilité de l'interface graphique, celle-ci permettant de
modifier de façon conviviale le fichier texte. Cependant, d'un point de
vue d'implémentation, il est important que le module de vérification de
la cohérence des données soit distinct du module de saisie.
Un firewall passoire qui laisse tout passer, ou rien passer, est il en
état de fonctionner ?
Un utilisateur ignare configure son firewall avec les pieds, n'ayant
aucune idée claire de ce qu'il faut laisser entrer/sortir.
L'interface de configuration lui permet de le faire aisément. Est-ce
un bon système de configuration ?
MB
--
Michel BILLAUD
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
En effet.
Y'en a un qui suit ;)
Oui, mais la tu as un systeme non fonctionnel.
La question est moins graphique/non graphique que interactif/non interactif.
Un systeme de config simple est intactif: il propose un jeu de choix
restreint qui evolue en fonction des choix precedents.
A ma connaissance, seul un systeme "graphique" peut faire cela aisement
(il peut etre curses, bien sur, mais vi me parait un peu juste la quand
meme).
Mieux serait "si ca fonctionne pas, relancer l'appli avec la derniere
configuration qui marchait". Mais c'est pas optimal. Le fichier de
config fautif ne devrait jamais avoir ete ecrit par l'outils de
configuration.
C'est une meilleure garantis de fonctionnement, en effet. Surtout que
les répercutions d'une configuration vont bien plus loin que la seule
application configurée, parfois.
Yannick
--
_/ Yannick Patois ___________________________________________________
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |
Michel Billaud wrote:
Non.
Non, pas au sens que j'ai defini precedemment. C'est un bon systeme pour
un expert (maximum de liberté) pas pour un non expert (qui a besoin
d'etre guidé). Une machine dans un état insecure n'est pas dans un etat
de fonctionnement correct (pas dans Omega_{ok}, dans le jargon precedent).
L'interface de configuration du firewall, ne doit probablement pas meme
exister en tant que telle a ce niveau, ce n'est pas un concept
manipulable par le non-expert.
Sur un tel systeme, le firewall est configure par defaut a un niveau de
securite eleve (tout est bloqué en entre, par exemple), et l'utilisateur
ne peut pas agir directement sur ce point.
Tu peux juste imaginer un melange d'exploration automatique et de
d'entrees des donnes de l'utilisateur qui decrive au systeme la
topologie de son réseau fmailial: "Ici le PC de mon conjoint, la celui
de mon fils, par la c'est internet", ce qui permetra dee definir le
routage, apres que l'utilisateur ait autorisé ou interdit la sortie vers
internet de chacune de ces machines et la nature des connexions
partagées "partage de disque" (montages NFS) par exemple.
Le firewall n'apparait qu'en creux dans les configs. Par exemple,
lorsque l'utilisateur demande a lancer un serveur web, on lui demande
"qui poura y acceder" ? La validation du réseau local ne posera aucun
probleme, par contre, trouver une option permettant de le rendre visible
du réseua nécéssitera un passage en mode "avancé" de l'interface, ainsi
qu'une justificatioin de ces précautions. De meme, la requete "je veux
pouvoir me connecter en ssh depuis le bureau", reconfigurera le firewall
(si possible restreint aux IPs du bureau), et controlera au prealable la
qualité du mot de pase de l'utilisateur autorisé, ou l'utilisation
correcte d'une clef ssh.
L'un des points important, qu'il me semble que seul une interface
interactive peutr resoudre elegemment est cette interaction entre de
multiples aspects de la config, comme par exemple entre le serveur
apache et le firewall. Lorsque l'utilisateur demande a pouvoir faire
voir son web local a un utilisateur distant, il faut a la fois
reconfigurer le fichier de config d'apache et celui du firewall, par
exemple.
Toute la difficulté consiste a faire un systeme a la fois archi-blindé
et en meme temps suffisement souple pour que l'ensemble des souhaits
d'un utilisateur non experts soit satisfait.
Vaste programme... C'est prouquoi je suis partit d'un langage très
formel pour tenter de le définir.
Yannick
--
_/ Yannick Patois ___________________________________________________
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |