In article <cel3cs$ig1$, Yannick Patois wrote:
Perso, j'aime pas utiliser des lettres grecques pour les machins
pas bien definis, mais heureusement, dans la suite, ca s'arrange.
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
coquille: appartenant, pas inclus.
l'action de l'utilisateur.
Un systeme de configuration donnee ne permet pas forcement d'adresser
tout Omega,
j'ajouterai meme qu'une fonction de configuration n'est pas definie
sur tout Omega. (genre, dans l'etat "j'ai efface le fichier
/etc/important" comment je modifie le fichier /etc/important ?)
F_c est une fonction de Omega dans mathcal{P}(Omega).
(comme ca, F_c(E) = emptyset si pas definie)
et on peut rajouter :
pour tout E dans Omega, |F_c(E)| leq 1
parcequ'un processus de configuration est un processus deterministe,
c'est bien connu. (sic)
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.
avec ma definition, on peut rendre Omega encore plus cryptique :
(Cup_{c} F_c)^*(E0), c'est mieux non ? :)
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)).
Je recapitule ce que j'ai cru comprendre :
- tu as un ensemble Omega
- tu appelles "systeme de configuration" un paquet de fonctions
partielles sur Omega
- tu choisis E0 dans Omega
- tu consideres Omega0 la partie de Omega atteignable par ton
"systeme de configuration"
- tu dis que Omega0 est stable s'il est fortement connexe (pour
parler "graphes" parceque c'est classe d'utiliser le vocabulaire
d'une autre theorie, juste pour faire joli ;-))
(si j'ai bon, j'ai une remarque, la def du sys de conf est pas super
claire, elle dit "un sys de conf est _une_ fonction F_c". j'aurais
prefere "est une famille (F_c) de fonctions")
- 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.
clair, c'est meme le principal, je dirais.
- 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 ?
dans (F_c) tu veux dire ?
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.
je pense franchement qu'il y a des tas d'etats non atteignables (pas
seulement des "pas facile" a atteindre) dans les sys de conf qu'on
rencontre dans le vrai monde.
par exemple, les etats tels que tous les bits de la RAM sont a 0,
meme si t'as un un cd de boot, je parie que t'y arrive pas.
meme en ecrivant un noyau from scratch, je sais pas si c'est possible.
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).
interdire les arguments au noyal, c'est violent comme contrainte
sur le sys de conf. :-)
Passons maintenant aux axiomes:
*** A/ Je pretends ici que si Omega0 est inclus dans Omega_{okc} la
FCNE est meilleure.
le contraire, plutot ("Il est evident que Omega0 est inclus dans
Omega_{okc}" dixit plus haut), non ?
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.
tu te restreints aux sys de conf stables ? (si oui, faut le dire)
*** 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.
ah mais non, rien ne va plus la.
ca voudrait dire que la tache d'apprentissage de perl est compliquee ?
c'est pas possible ;-)
- 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,
je ne vois pas le rapport entre la taille de Omega0 et la stabilite.
du bidule. Et je trouve qu'au contraire, plus on a un controle fin,
plus on a de chance d'avoir un sys stable.
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.
- 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
Ah oui mais la, tu consideres comme (F_c) *toutes* les modifs de /etc,
c'est trop gros. Si tu te restreints a des conventions de syntaxe
non ambigues, et aux modifs qui font que des trucs bien, ca va.
- 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}
euh... j'ai ptet loupe un truc dans tes definitions, mais j'avais
compris que Omega_{coherent} subset Omega_{ok}. (c'est dans l'autre
sens ?)
a/ On y peut rien, on sait que c'est comme ca, c'est meme voulu.
"on n'y peut rien" n'est pas une raison pour tolerer n'importe quoi.
Il faut quand meme verifier que meme en restant dans Omega0g on peut
atteindre un etat ou on a sa disposition une machine de Turing
universelle. Sinon, c'est pas la peine d'avoir un ordinateur.
D'ailleurs j'aime pas les sys de confs qui sont pas turing-complets ;-)
Par contre, elles sont souvent assez bonne sur:
c/ stable
je suis pas du tout d'accord. je trouve qu'au contraire avec une GUI,
c'est super facile de casser un truc sans espoir de reparation.
(de reparation avec la GUI, bien sur)
genre, desinstaller le pilote de la souris sous windows, c'est
possible, non ? (j'ai pas de windows sous la main pour verifier)
(et celui du clavier, parceque sinon on peut faire tab* entree)
d/ inclus dans Omega_{coherent}
quoi quoi quoi ? on peut meme rien casser avec une GUI ?
tu te restreints peut etre aux GUI non-buggees ? :)
vu que je trouve que c est dans "mauvais", je dirais qu'un mauvais c
est bien pire qu'un mauvais b (du point de vue du debutant). si je me
mets a la place d'un debutant, j'aurai vraiment trop peur de casser un
truc.
sinon, toutes ces definitions pour dire que :
- macos <10, on clique ca marche, mais c'est chiant de faire des
choses bizarres ;
- macos X, on clique ca marche, et ca permet meme de faire pas mal de
choses bizarres ;
- windows, c'est le bordel ;
- linux, on peut cliquer si on veut, mais ca marche quand meme mieux
avec un clavier ;
ca m'a bien amuse.
FU2 fr.sci.maths ? :)
In article <cel3cs$ig1$1@sunnews.cern.ch>, Yannick Patois wrote:
Perso, j'aime pas utiliser des lettres grecques pour les machins
pas bien definis, mais heureusement, dans la suite, ca s'arrange.
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
coquille: appartenant, pas inclus.
l'action de l'utilisateur.
Un systeme de configuration donnee ne permet pas forcement d'adresser
tout Omega,
j'ajouterai meme qu'une fonction de configuration n'est pas definie
sur tout Omega. (genre, dans l'etat "j'ai efface le fichier
/etc/important" comment je modifie le fichier /etc/important ?)
F_c est une fonction de Omega dans mathcal{P}(Omega).
(comme ca, F_c(E) = emptyset si pas definie)
et on peut rajouter :
pour tout E dans Omega, |F_c(E)| leq 1
parcequ'un processus de configuration est un processus deterministe,
c'est bien connu. (sic)
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.
avec ma definition, on peut rendre Omega encore plus cryptique :
(Cup_{c} F_c)^*(E0), c'est mieux non ? :)
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)).
Je recapitule ce que j'ai cru comprendre :
- tu as un ensemble Omega
- tu appelles "systeme de configuration" un paquet de fonctions
partielles sur Omega
- tu choisis E0 dans Omega
- tu consideres Omega0 la partie de Omega atteignable par ton
"systeme de configuration"
- tu dis que Omega0 est stable s'il est fortement connexe (pour
parler "graphes" parceque c'est classe d'utiliser le vocabulaire
d'une autre theorie, juste pour faire joli ;-))
(si j'ai bon, j'ai une remarque, la def du sys de conf est pas super
claire, elle dit "un sys de conf est _une_ fonction F_c". j'aurais
prefere "est une famille (F_c) de fonctions")
- 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.
clair, c'est meme le principal, je dirais.
- 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 ?
dans (F_c) tu veux dire ?
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.
je pense franchement qu'il y a des tas d'etats non atteignables (pas
seulement des "pas facile" a atteindre) dans les sys de conf qu'on
rencontre dans le vrai monde.
par exemple, les etats tels que tous les bits de la RAM sont a 0,
meme si t'as un un cd de boot, je parie que t'y arrive pas.
meme en ecrivant un noyau from scratch, je sais pas si c'est possible.
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).
interdire les arguments au noyal, c'est violent comme contrainte
sur le sys de conf. :-)
Passons maintenant aux axiomes:
*** A/ Je pretends ici que si Omega0 est inclus dans Omega_{okc} la
FCNE est meilleure.
le contraire, plutot ("Il est evident que Omega0 est inclus dans
Omega_{okc}" dixit plus haut), non ?
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.
tu te restreints aux sys de conf stables ? (si oui, faut le dire)
*** 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.
ah mais non, rien ne va plus la.
ca voudrait dire que la tache d'apprentissage de perl est compliquee ?
c'est pas possible ;-)
- 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,
je ne vois pas le rapport entre la taille de Omega0 et la stabilite.
du bidule. Et je trouve qu'au contraire, plus on a un controle fin,
plus on a de chance d'avoir un sys stable.
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.
- 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
Ah oui mais la, tu consideres comme (F_c) *toutes* les modifs de /etc,
c'est trop gros. Si tu te restreints a des conventions de syntaxe
non ambigues, et aux modifs qui font que des trucs bien, ca va.
- 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}
euh... j'ai ptet loupe un truc dans tes definitions, mais j'avais
compris que Omega_{coherent} subset Omega_{ok}. (c'est dans l'autre
sens ?)
a/ On y peut rien, on sait que c'est comme ca, c'est meme voulu.
"on n'y peut rien" n'est pas une raison pour tolerer n'importe quoi.
Il faut quand meme verifier que meme en restant dans Omega0g on peut
atteindre un etat ou on a sa disposition une machine de Turing
universelle. Sinon, c'est pas la peine d'avoir un ordinateur.
D'ailleurs j'aime pas les sys de confs qui sont pas turing-complets ;-)
Par contre, elles sont souvent assez bonne sur:
c/ stable
je suis pas du tout d'accord. je trouve qu'au contraire avec une GUI,
c'est super facile de casser un truc sans espoir de reparation.
(de reparation avec la GUI, bien sur)
genre, desinstaller le pilote de la souris sous windows, c'est
possible, non ? (j'ai pas de windows sous la main pour verifier)
(et celui du clavier, parceque sinon on peut faire tab* entree)
d/ inclus dans Omega_{coherent}
quoi quoi quoi ? on peut meme rien casser avec une GUI ?
tu te restreints peut etre aux GUI non-buggees ? :)
vu que je trouve que c est dans "mauvais", je dirais qu'un mauvais c
est bien pire qu'un mauvais b (du point de vue du debutant). si je me
mets a la place d'un debutant, j'aurai vraiment trop peur de casser un
truc.
sinon, toutes ces definitions pour dire que :
- macos <10, on clique ca marche, mais c'est chiant de faire des
choses bizarres ;
- macos X, on clique ca marche, et ca permet meme de faire pas mal de
choses bizarres ;
- windows, c'est le bordel ;
- linux, on peut cliquer si on veut, mais ca marche quand meme mieux
avec un clavier ;
ca m'a bien amuse.
FU2 fr.sci.maths ? :)
In article <cel3cs$ig1$, Yannick Patois wrote:
Perso, j'aime pas utiliser des lettres grecques pour les machins
pas bien definis, mais heureusement, dans la suite, ca s'arrange.
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
coquille: appartenant, pas inclus.
l'action de l'utilisateur.
Un systeme de configuration donnee ne permet pas forcement d'adresser
tout Omega,
j'ajouterai meme qu'une fonction de configuration n'est pas definie
sur tout Omega. (genre, dans l'etat "j'ai efface le fichier
/etc/important" comment je modifie le fichier /etc/important ?)
F_c est une fonction de Omega dans mathcal{P}(Omega).
(comme ca, F_c(E) = emptyset si pas definie)
et on peut rajouter :
pour tout E dans Omega, |F_c(E)| leq 1
parcequ'un processus de configuration est un processus deterministe,
c'est bien connu. (sic)
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.
avec ma definition, on peut rendre Omega encore plus cryptique :
(Cup_{c} F_c)^*(E0), c'est mieux non ? :)
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)).
Je recapitule ce que j'ai cru comprendre :
- tu as un ensemble Omega
- tu appelles "systeme de configuration" un paquet de fonctions
partielles sur Omega
- tu choisis E0 dans Omega
- tu consideres Omega0 la partie de Omega atteignable par ton
"systeme de configuration"
- tu dis que Omega0 est stable s'il est fortement connexe (pour
parler "graphes" parceque c'est classe d'utiliser le vocabulaire
d'une autre theorie, juste pour faire joli ;-))
(si j'ai bon, j'ai une remarque, la def du sys de conf est pas super
claire, elle dit "un sys de conf est _une_ fonction F_c". j'aurais
prefere "est une famille (F_c) de fonctions")
- 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.
clair, c'est meme le principal, je dirais.
- 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 ?
dans (F_c) tu veux dire ?
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.
je pense franchement qu'il y a des tas d'etats non atteignables (pas
seulement des "pas facile" a atteindre) dans les sys de conf qu'on
rencontre dans le vrai monde.
par exemple, les etats tels que tous les bits de la RAM sont a 0,
meme si t'as un un cd de boot, je parie que t'y arrive pas.
meme en ecrivant un noyau from scratch, je sais pas si c'est possible.
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).
interdire les arguments au noyal, c'est violent comme contrainte
sur le sys de conf. :-)
Passons maintenant aux axiomes:
*** A/ Je pretends ici que si Omega0 est inclus dans Omega_{okc} la
FCNE est meilleure.
le contraire, plutot ("Il est evident que Omega0 est inclus dans
Omega_{okc}" dixit plus haut), non ?
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.
tu te restreints aux sys de conf stables ? (si oui, faut le dire)
*** 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.
ah mais non, rien ne va plus la.
ca voudrait dire que la tache d'apprentissage de perl est compliquee ?
c'est pas possible ;-)
- 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,
je ne vois pas le rapport entre la taille de Omega0 et la stabilite.
du bidule. Et je trouve qu'au contraire, plus on a un controle fin,
plus on a de chance d'avoir un sys stable.
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.
- 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
Ah oui mais la, tu consideres comme (F_c) *toutes* les modifs de /etc,
c'est trop gros. Si tu te restreints a des conventions de syntaxe
non ambigues, et aux modifs qui font que des trucs bien, ca va.
- 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}
euh... j'ai ptet loupe un truc dans tes definitions, mais j'avais
compris que Omega_{coherent} subset Omega_{ok}. (c'est dans l'autre
sens ?)
a/ On y peut rien, on sait que c'est comme ca, c'est meme voulu.
"on n'y peut rien" n'est pas une raison pour tolerer n'importe quoi.
Il faut quand meme verifier que meme en restant dans Omega0g on peut
atteindre un etat ou on a sa disposition une machine de Turing
universelle. Sinon, c'est pas la peine d'avoir un ordinateur.
D'ailleurs j'aime pas les sys de confs qui sont pas turing-complets ;-)
Par contre, elles sont souvent assez bonne sur:
c/ stable
je suis pas du tout d'accord. je trouve qu'au contraire avec une GUI,
c'est super facile de casser un truc sans espoir de reparation.
(de reparation avec la GUI, bien sur)
genre, desinstaller le pilote de la souris sous windows, c'est
possible, non ? (j'ai pas de windows sous la main pour verifier)
(et celui du clavier, parceque sinon on peut faire tab* entree)
d/ inclus dans Omega_{coherent}
quoi quoi quoi ? on peut meme rien casser avec une GUI ?
tu te restreints peut etre aux GUI non-buggees ? :)
vu que je trouve que c est dans "mauvais", je dirais qu'un mauvais c
est bien pire qu'un mauvais b (du point de vue du debutant). si je me
mets a la place d'un debutant, j'aurai vraiment trop peur de casser un
truc.
sinon, toutes ces definitions pour dire que :
- macos <10, on clique ca marche, mais c'est chiant de faire des
choses bizarres ;
- macos X, on clique ca marche, et ca permet meme de faire pas mal de
choses bizarres ;
- windows, c'est le bordel ;
- linux, on peut cliquer si on veut, mais ca marche quand meme mieux
avec un clavier ;
ca m'a bien amuse.
FU2 fr.sci.maths ? :)
Michel Billaud wrote:Yannick Patois writes:Ce qui peut être ou ne pas être correct, ce sont des couples
(etat de la machine, environnement)
Tu as raison.
Forcément.
C'est un axiome? ;-)
Alors c'est mal barré pour qu'il soit capable de préciser "la nature
des connexions" entre ses ordinateurs et internet.
Ils n'en sont pas capable, bien sur, ils indiquent ce qu'ils veulent faire.
Ils peuvent certes cliquer sans comprendre. Ca n'explosera pas.
Le but de l'interface bien faite est justement de permetre que des
clics, y compris quasiment au hasard (on a affaire a un non expert) ne
mette jamais la machine dans un etat non fonctionnel ou non secure.
realiser la fonction, c'est vraiment le dernier stade. Déjà il faut savoir
ce qu'on a besoin de faire, choisir un compromis entre ce qu'on veut faire
et ce que permet le systeme, et ensuite lancer les actions qui permettont
de le faire.
Il faut donc determiner le minimum absolut d'informations necessaire
entre le stade "savoir ce qu'on a besoin" et "lancer les actions" etg
ensuite mettre en place l'interface qui ne demande que cela et sache
partir du besoin exprime.
Les premiers ordinateurs
n'etaient utilise que par des specialistes, tous docteurs en maths ou
ingenieurs de haut niveau.
Ceci dit les premiers ordinateurs n'avaient pas de
carte son, de modem ADSL, de firewall et d'imprimantes USB ni de Wifi,
encore moins de voisinage réseau et autres partages de fichiers.
Et pourtant ils sont devenu plus simples a utiliser.
Il faut dire que le niveau d'exigence concernant ce qu'on veut faire
avec un ordinateur a considérablement baissé. Dans le temps c'était
un investissement qui amenait un gain de productivité considérable par
ce que ça automatisait le traitement des informations. Investissement
financier et intellectuel: pour automatiser il faut programmer, donc
réfléchir.
Oui. Mais ces travaux exigeants ont aussi profite de la simplification
de l'interface. Entre perforer des cartes en Fortran et utiliser
Mathematica, y'a un gain enorme en productivite, y compris pour le
docteur en math.
Dans un tout autre domaine, pense aux films d'animations. Il y aura
des codeurs pour le rendu, mais aussi beaucoup de monde pour coder
l'interface que les graphistes (non informaticiens) vont utiliser pour
decrire et manipuler les objets du film. Entre tapper des coordonnees
de polygones dans un .pov et utiliser des curseurs et des menus dans
une apllication dediee a l'animations de personnages, par exemple, la
quantite de connaissance a maitriser (et la productivite) est
incomparable.
Maintenant c'est un tourne-disque / telex à peine amélioré.
Dans ce cas, on doit pouvoir en rendre l'administration aussi simple
que celle de ces deux objet, non ?
Michel Billaud wrote:
Yannick Patois <patois@calvix.org> writes:
Ce qui peut être ou ne pas être correct, ce sont des couples
(etat de la machine, environnement)
Tu as raison.
Forcément.
C'est un axiome? ;-)
Alors c'est mal barré pour qu'il soit capable de préciser "la nature
des connexions" entre ses ordinateurs et internet.
Ils n'en sont pas capable, bien sur, ils indiquent ce qu'ils veulent faire.
Ils peuvent certes cliquer sans comprendre. Ca n'explosera pas.
Le but de l'interface bien faite est justement de permetre que des
clics, y compris quasiment au hasard (on a affaire a un non expert) ne
mette jamais la machine dans un etat non fonctionnel ou non secure.
realiser la fonction, c'est vraiment le dernier stade. Déjà il faut savoir
ce qu'on a besoin de faire, choisir un compromis entre ce qu'on veut faire
et ce que permet le systeme, et ensuite lancer les actions qui permettont
de le faire.
Il faut donc determiner le minimum absolut d'informations necessaire
entre le stade "savoir ce qu'on a besoin" et "lancer les actions" etg
ensuite mettre en place l'interface qui ne demande que cela et sache
partir du besoin exprime.
Les premiers ordinateurs
n'etaient utilise que par des specialistes, tous docteurs en maths ou
ingenieurs de haut niveau.
Ceci dit les premiers ordinateurs n'avaient pas de
carte son, de modem ADSL, de firewall et d'imprimantes USB ni de Wifi,
encore moins de voisinage réseau et autres partages de fichiers.
Et pourtant ils sont devenu plus simples a utiliser.
Il faut dire que le niveau d'exigence concernant ce qu'on veut faire
avec un ordinateur a considérablement baissé. Dans le temps c'était
un investissement qui amenait un gain de productivité considérable par
ce que ça automatisait le traitement des informations. Investissement
financier et intellectuel: pour automatiser il faut programmer, donc
réfléchir.
Oui. Mais ces travaux exigeants ont aussi profite de la simplification
de l'interface. Entre perforer des cartes en Fortran et utiliser
Mathematica, y'a un gain enorme en productivite, y compris pour le
docteur en math.
Dans un tout autre domaine, pense aux films d'animations. Il y aura
des codeurs pour le rendu, mais aussi beaucoup de monde pour coder
l'interface que les graphistes (non informaticiens) vont utiliser pour
decrire et manipuler les objets du film. Entre tapper des coordonnees
de polygones dans un .pov et utiliser des curseurs et des menus dans
une apllication dediee a l'animations de personnages, par exemple, la
quantite de connaissance a maitriser (et la productivite) est
incomparable.
Maintenant c'est un tourne-disque / telex à peine amélioré.
Dans ce cas, on doit pouvoir en rendre l'administration aussi simple
que celle de ces deux objet, non ?
Michel Billaud wrote:Yannick Patois writes:Ce qui peut être ou ne pas être correct, ce sont des couples
(etat de la machine, environnement)
Tu as raison.
Forcément.
C'est un axiome? ;-)
Alors c'est mal barré pour qu'il soit capable de préciser "la nature
des connexions" entre ses ordinateurs et internet.
Ils n'en sont pas capable, bien sur, ils indiquent ce qu'ils veulent faire.
Ils peuvent certes cliquer sans comprendre. Ca n'explosera pas.
Le but de l'interface bien faite est justement de permetre que des
clics, y compris quasiment au hasard (on a affaire a un non expert) ne
mette jamais la machine dans un etat non fonctionnel ou non secure.
realiser la fonction, c'est vraiment le dernier stade. Déjà il faut savoir
ce qu'on a besoin de faire, choisir un compromis entre ce qu'on veut faire
et ce que permet le systeme, et ensuite lancer les actions qui permettont
de le faire.
Il faut donc determiner le minimum absolut d'informations necessaire
entre le stade "savoir ce qu'on a besoin" et "lancer les actions" etg
ensuite mettre en place l'interface qui ne demande que cela et sache
partir du besoin exprime.
Les premiers ordinateurs
n'etaient utilise que par des specialistes, tous docteurs en maths ou
ingenieurs de haut niveau.
Ceci dit les premiers ordinateurs n'avaient pas de
carte son, de modem ADSL, de firewall et d'imprimantes USB ni de Wifi,
encore moins de voisinage réseau et autres partages de fichiers.
Et pourtant ils sont devenu plus simples a utiliser.
Il faut dire que le niveau d'exigence concernant ce qu'on veut faire
avec un ordinateur a considérablement baissé. Dans le temps c'était
un investissement qui amenait un gain de productivité considérable par
ce que ça automatisait le traitement des informations. Investissement
financier et intellectuel: pour automatiser il faut programmer, donc
réfléchir.
Oui. Mais ces travaux exigeants ont aussi profite de la simplification
de l'interface. Entre perforer des cartes en Fortran et utiliser
Mathematica, y'a un gain enorme en productivite, y compris pour le
docteur en math.
Dans un tout autre domaine, pense aux films d'animations. Il y aura
des codeurs pour le rendu, mais aussi beaucoup de monde pour coder
l'interface que les graphistes (non informaticiens) vont utiliser pour
decrire et manipuler les objets du film. Entre tapper des coordonnees
de polygones dans un .pov et utiliser des curseurs et des menus dans
une apllication dediee a l'animations de personnages, par exemple, la
quantite de connaissance a maitriser (et la productivite) est
incomparable.
Maintenant c'est un tourne-disque / telex à peine amélioré.
Dans ce cas, on doit pouvoir en rendre l'administration aussi simple
que celle de ces deux objet, non ?
Yannick Patois writes:Michel Billaud wrote:Yannick Patois writes:Ce qui peut être ou ne pas être correct, ce sont des couples
(etat de la machine, environnement)
Tu as raison.
Forcément.
C'est un axiome? ;-)
Carrément une théorie. Scientifique au sens Poppérien, cependant,
puis qu'on peut imaginer qu'elle puisse etre mise en défaut.
Ils peuvent certes cliquer sans comprendre. Ca n'explosera pas.
Le but de l'interface bien faite est justement de permetre que des
clics, y compris quasiment au hasard (on a affaire a un non expert) ne
mette jamais la machine dans un etat non fonctionnel ou non secure.
Un message "mettez le CD installation #1" et un bouton OK dessous, ça
correspond à la description.
Les premiers ordinateurs
n'etaient utilise que par des specialistes, tous docteurs en maths ou
ingenieurs de haut niveau.
Ceci dit les premiers ordinateurs n'avaient pas de
carte son, de modem ADSL, de firewall et d'imprimantes USB ni de Wifi,
encore moins de voisinage réseau et autres partages de fichiers.
Et pourtant ils sont devenu plus simples a utiliser.
est-ce bien sur.... Le pourcentage du temps perdu à des activités non
"productives" (genre je defragmente, je reinstalle, je reconfigure...)
a-t-il baissé notablement ?
Oui. Mais ces travaux exigeants ont aussi profite de la simplification
de l'interface. Entre perforer des cartes en Fortran et utiliser
Mathematica, y'a un gain enorme en productivite, y compris pour le
docteur en math.
Je ne parle pas de ce type d'utilisateur, qui doit bien représenter
quelques pourcent des acheteurs d'ordinateurs, et qui a d'ailleurs des
ingénieurs et techniciens sous la main pour se démerder avec les
problèmes techniques.
J'en étais à monsieur dupont, artisan plombier, qui s'achete un
ordinateur, et a qui une appli de 10 pages en basic bricolée par le
beauf fait gagner 3 heures de paperasse par semaine. Ce qui lui fait
3 heures de plus chez le client.
Maintenant c'est un tourne-disque / telex à peine amélioré.
Dans ce cas, on doit pouvoir en rendre l'administration aussi simple
que celle de ces deux objet, non ?
On file un boitier figé + un abonnement haut débit, et le tout
(chargement/installation des applis en local, acces en client
léger/lourd aux applis distantes, configuration, sauvegardes) est géré
automatiquement par le fournisseur qui s'occupe de tout, moyennement
abonnement.
Yannick Patois <patois@calvix.org> writes:
Michel Billaud wrote:
Yannick Patois <patois@calvix.org> writes:
Ce qui peut être ou ne pas être correct, ce sont des couples
(etat de la machine, environnement)
Tu as raison.
Forcément.
C'est un axiome? ;-)
Carrément une théorie. Scientifique au sens Poppérien, cependant,
puis qu'on peut imaginer qu'elle puisse etre mise en défaut.
Ils peuvent certes cliquer sans comprendre. Ca n'explosera pas.
Le but de l'interface bien faite est justement de permetre que des
clics, y compris quasiment au hasard (on a affaire a un non expert) ne
mette jamais la machine dans un etat non fonctionnel ou non secure.
Un message "mettez le CD installation #1" et un bouton OK dessous, ça
correspond à la description.
Les premiers ordinateurs
n'etaient utilise que par des specialistes, tous docteurs en maths ou
ingenieurs de haut niveau.
Ceci dit les premiers ordinateurs n'avaient pas de
carte son, de modem ADSL, de firewall et d'imprimantes USB ni de Wifi,
encore moins de voisinage réseau et autres partages de fichiers.
Et pourtant ils sont devenu plus simples a utiliser.
est-ce bien sur.... Le pourcentage du temps perdu à des activités non
"productives" (genre je defragmente, je reinstalle, je reconfigure...)
a-t-il baissé notablement ?
Oui. Mais ces travaux exigeants ont aussi profite de la simplification
de l'interface. Entre perforer des cartes en Fortran et utiliser
Mathematica, y'a un gain enorme en productivite, y compris pour le
docteur en math.
Je ne parle pas de ce type d'utilisateur, qui doit bien représenter
quelques pourcent des acheteurs d'ordinateurs, et qui a d'ailleurs des
ingénieurs et techniciens sous la main pour se démerder avec les
problèmes techniques.
J'en étais à monsieur dupont, artisan plombier, qui s'achete un
ordinateur, et a qui une appli de 10 pages en basic bricolée par le
beauf fait gagner 3 heures de paperasse par semaine. Ce qui lui fait
3 heures de plus chez le client.
Maintenant c'est un tourne-disque / telex à peine amélioré.
Dans ce cas, on doit pouvoir en rendre l'administration aussi simple
que celle de ces deux objet, non ?
On file un boitier figé + un abonnement haut débit, et le tout
(chargement/installation des applis en local, acces en client
léger/lourd aux applis distantes, configuration, sauvegardes) est géré
automatiquement par le fournisseur qui s'occupe de tout, moyennement
abonnement.
Yannick Patois writes:Michel Billaud wrote:Yannick Patois writes:Ce qui peut être ou ne pas être correct, ce sont des couples
(etat de la machine, environnement)
Tu as raison.
Forcément.
C'est un axiome? ;-)
Carrément une théorie. Scientifique au sens Poppérien, cependant,
puis qu'on peut imaginer qu'elle puisse etre mise en défaut.
Ils peuvent certes cliquer sans comprendre. Ca n'explosera pas.
Le but de l'interface bien faite est justement de permetre que des
clics, y compris quasiment au hasard (on a affaire a un non expert) ne
mette jamais la machine dans un etat non fonctionnel ou non secure.
Un message "mettez le CD installation #1" et un bouton OK dessous, ça
correspond à la description.
Les premiers ordinateurs
n'etaient utilise que par des specialistes, tous docteurs en maths ou
ingenieurs de haut niveau.
Ceci dit les premiers ordinateurs n'avaient pas de
carte son, de modem ADSL, de firewall et d'imprimantes USB ni de Wifi,
encore moins de voisinage réseau et autres partages de fichiers.
Et pourtant ils sont devenu plus simples a utiliser.
est-ce bien sur.... Le pourcentage du temps perdu à des activités non
"productives" (genre je defragmente, je reinstalle, je reconfigure...)
a-t-il baissé notablement ?
Oui. Mais ces travaux exigeants ont aussi profite de la simplification
de l'interface. Entre perforer des cartes en Fortran et utiliser
Mathematica, y'a un gain enorme en productivite, y compris pour le
docteur en math.
Je ne parle pas de ce type d'utilisateur, qui doit bien représenter
quelques pourcent des acheteurs d'ordinateurs, et qui a d'ailleurs des
ingénieurs et techniciens sous la main pour se démerder avec les
problèmes techniques.
J'en étais à monsieur dupont, artisan plombier, qui s'achete un
ordinateur, et a qui une appli de 10 pages en basic bricolée par le
beauf fait gagner 3 heures de paperasse par semaine. Ce qui lui fait
3 heures de plus chez le client.
Maintenant c'est un tourne-disque / telex à peine amélioré.
Dans ce cas, on doit pouvoir en rendre l'administration aussi simple
que celle de ces deux objet, non ?
On file un boitier figé + un abonnement haut débit, et le tout
(chargement/installation des applis en local, acces en client
léger/lourd aux applis distantes, configuration, sauvegardes) est géré
automatiquement par le fournisseur qui s'occupe de tout, moyennement
abonnement.
Michel Billaud wrote:Yannick Patois writes:Michel Billaud wrote:Yannick Patois writes:Ce qui peut être ou ne pas être correct, ce sont des couples
(etat de la machine, environnement)
Tu as raison.
Forcément.
C'est un axiome? ;-)
Carrément une théorie. Scientifique au sens Poppérien, cependant,
puis qu'on peut imaginer qu'elle puisse etre mise en défaut.
Si je retrouve une de tes copies ou tu n'as pas 20/20, j'ai mis en
défaut ? ;)
Ils peuvent certes cliquer sans comprendre. Ca n'explosera pas.
Le but de l'interface bien faite est justement de permetre que des
clics, y compris quasiment au hasard (on a affaire a un non expert) ne
mette jamais la machine dans un etat non fonctionnel ou non secure.
Un message "mettez le CD installation #1" et un bouton OK dessous, ça
correspond à la description.
Suis pas sur de suivre, la...
On file un boitier figé + un abonnement haut débit, et le tout
(chargement/installation des applis en local, acces en client
léger/lourd aux applis distantes, configuration, sauvegardes) est géré
automatiquement par le fournisseur qui s'occupe de tout, moyennement
abonnement.
Les gens n'en voudront pas, avec raison (tous les essais en ce sens
ont échoués). Avoir la maitrise du systeme que l'on utilise (à son
niveau) semble important a la plupart.
Les problemes de
confidentialite en particulier sont insurmontables.
Michel Billaud wrote:
Yannick Patois <patois@calvix.org> writes:
Michel Billaud wrote:
Yannick Patois <patois@calvix.org> writes:
Ce qui peut être ou ne pas être correct, ce sont des couples
(etat de la machine, environnement)
Tu as raison.
Forcément.
C'est un axiome? ;-)
Carrément une théorie. Scientifique au sens Poppérien, cependant,
puis qu'on peut imaginer qu'elle puisse etre mise en défaut.
Si je retrouve une de tes copies ou tu n'as pas 20/20, j'ai mis en
défaut ? ;)
Ils peuvent certes cliquer sans comprendre. Ca n'explosera pas.
Le but de l'interface bien faite est justement de permetre que des
clics, y compris quasiment au hasard (on a affaire a un non expert) ne
mette jamais la machine dans un etat non fonctionnel ou non secure.
Un message "mettez le CD installation #1" et un bouton OK dessous, ça
correspond à la description.
Suis pas sur de suivre, la...
On file un boitier figé + un abonnement haut débit, et le tout
(chargement/installation des applis en local, acces en client
léger/lourd aux applis distantes, configuration, sauvegardes) est géré
automatiquement par le fournisseur qui s'occupe de tout, moyennement
abonnement.
Les gens n'en voudront pas, avec raison (tous les essais en ce sens
ont échoués). Avoir la maitrise du systeme que l'on utilise (à son
niveau) semble important a la plupart.
Les problemes de
confidentialite en particulier sont insurmontables.
Michel Billaud wrote:Yannick Patois writes:Michel Billaud wrote:Yannick Patois writes:Ce qui peut être ou ne pas être correct, ce sont des couples
(etat de la machine, environnement)
Tu as raison.
Forcément.
C'est un axiome? ;-)
Carrément une théorie. Scientifique au sens Poppérien, cependant,
puis qu'on peut imaginer qu'elle puisse etre mise en défaut.
Si je retrouve une de tes copies ou tu n'as pas 20/20, j'ai mis en
défaut ? ;)
Ils peuvent certes cliquer sans comprendre. Ca n'explosera pas.
Le but de l'interface bien faite est justement de permetre que des
clics, y compris quasiment au hasard (on a affaire a un non expert) ne
mette jamais la machine dans un etat non fonctionnel ou non secure.
Un message "mettez le CD installation #1" et un bouton OK dessous, ça
correspond à la description.
Suis pas sur de suivre, la...
On file un boitier figé + un abonnement haut débit, et le tout
(chargement/installation des applis en local, acces en client
léger/lourd aux applis distantes, configuration, sauvegardes) est géré
automatiquement par le fournisseur qui s'occupe de tout, moyennement
abonnement.
Les gens n'en voudront pas, avec raison (tous les essais en ce sens
ont échoués). Avoir la maitrise du systeme que l'on utilise (à son
niveau) semble important a la plupart.
Les problemes de
confidentialite en particulier sont insurmontables.
Merci de cette critique qui pointe mes erreurs et ommissions.
Christophe Delage wrote:In article <cel3cs$ig1$, Yannick Patois wrote:
Perso, j'aime pas utiliser des lettres grecques pour les machins
pas bien definis, mais heureusement, dans la suite, ca s'arrange.
Je le laisse ou j'utilise un autre terme ?
J'ai pas d'idees...
Un systeme de configuration donnee ne permet pas forcement d'adresser
tout Omega,
j'ajouterai meme qu'une fonction de configuration n'est pas definie
sur tout Omega. (genre, dans l'etat "j'ai efface le fichier
/etc/important" comment je modifie le fichier /etc/important ?)
Oui, tu as raison. Et une bonne interface ne doit proposer que des
fonctions définie pour l'état courant.
et on peut rajouter :
pour tout E dans Omega, |F_c(E)| leq 1
parcequ'un processus de configuration est un processus deterministe,
c'est bien connu. (sic)
Si on admet que l'ordinateur est un systeme déterministe et que la seule
entrée est l'execution de F_c() alors ca doit etre vrais.
C'est effectivement un postulat implicite (mais raisonable) que j'ai
utilisé.
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.
avec ma definition, on peut rendre Omega encore plus cryptique :
(Cup_{c} F_c)^*(E0), c'est mieux non ? :)
Omega0, non ?
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)).
Je recapitule ce que j'ai cru comprendre :
- tu as un ensemble Omega
- tu appelles "systeme de configuration" un paquet de fonctions
partielles sur Omega
- tu choisis E0 dans Omega
E0 est sensé etre l'état inital, juste après l'installation, dans un cas
concret.- tu consideres Omega0 la partie de Omega atteignable par ton
"systeme de configuration"
- tu dis que Omega0 est stable s'il est fortement connexe (pour
parler "graphes" parceque c'est classe d'utiliser le vocabulaire
d'une autre theorie, juste pour faire joli ;-))
Stable, ca serait juste connexe, le chemin pour y arriver peut etre
non direct.
- 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.
clair, c'est meme le principal, je dirais.
OK, nous voila d'accord sur un point (au dela des definitions).
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.
je pense franchement qu'il y a des tas d'etats non atteignables (pas
seulement des "pas facile" a atteindre) dans les sys de conf qu'on
rencontre dans le vrai monde.
par exemple, les etats tels que tous les bits de la RAM sont a 0,
meme si t'as un un cd de boot, je parie que t'y arrive pas.
meme en ecrivant un noyau from scratch, je sais pas si c'est possible.
Je pense que c'est possible en ecrivant un noyau qui lance un programme
qui efface la RAM (et le noyau) dont la derniere routine soit
suffisement réduite pour tenir dans le cache processeur. Ensuite un
reset doit passer tous les états du proc en defaut et c'est bon.
OK, ca sert a rien, et il y a sans doute des états vraiment inacessible
a l'interieur du proc lui meme.
interdire les arguments au noyal, c'est violent comme contrainte
sur le sys de conf. :-)
Ils sont autorisés seulement s'ils sont défini avant un reboot (par
exemlpe, je change de noyau, je passe par le systeme de conf et au
procahin reboot un argument est appliqué). Je veux excclure la nécéssité
par l'utilisateur non expert de tapper des arguments obscurs dans une
interface tres réduite avant le boot. Ceci aussi oblige a considerer une
methode de config telle que "tu reboot en single user et on répare".
Passons maintenant aux axiomes:
*** A/ Je pretends ici que si Omega0 est inclus dans Omega_{okc} la
FCNE est meilleure.
le contraire, plutot ("Il est evident que Omega0 est inclus dans
Omega_{okc}" dixit plus haut), non ?
J'ai ecris quoi comme conneries, moi ? Je relis...
Oui, en fait, j'avais oublié que j'avais dis stable pluis haut.
En fait, cette condition oblige a avoir un systeme stable.
On peut éventuellement "récupéré" un systeme égaré (donc Omega_{okc}
n'est pas forcement inclus dans Omega0)
*** 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.
ah mais non, rien ne va plus la.
ca voudrait dire que la tache d'apprentissage de perl est compliquee ?
c'est pas possible ;-)
Hum, je maintiens. Dans le meme ordre plus le graphe est proche d'un
graphe fortemet connexe (ou disons pus le nombre maximum de noeuds a
franchir pour passer d'un état quelconque a un autre est faible) mieux
c'est.
Ah oui mais la, tu consideres comme (F_c) *toutes* les modifs de /etc,
c'est trop gros. Si tu te restreints a des conventions de syntaxe
non ambigues, et aux modifs qui font que des trucs bien, ca va.
Le probleme c'est que l'utilisateur non expert, il sait pas tout ca. Il
clique et tappe du texte au hasard, disons un peu mieux que le hasard
mais d'un rapport signal/bruit qui décroit avec la compétance.
Le fait que je ne puisse pas écrire "Oui" en face d'un argument que je
veux activer est un probleme. Le fait qu'il ne soit pas immédiat que les
seules réponses possible soiuent "yes" et "no" (encore faut il connaitre
ces termes et leur sens dans une langue étrangere) est un autre
probleme, le fait que parfois on puisse en plus avoir, par exemple
"auto" ou "user-defined", je ne vois pas de moyen de borner cela.
L'interface interactive présente en meme temps que la question l'étendus
des réponses possibles.
- 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}
euh... j'ai ptet loupe un truc dans tes definitions, mais j'avais
compris que Omega_{coherent} subset Omega_{ok}. (c'est dans l'autre
sens ?)
Non, tu as raison, il faut inverser. Tu fais souvent de la relecture
pour des publi ? ;)
a/ On y peut rien, on sait que c'est comme ca, c'est meme voulu.
"on n'y peut rien" n'est pas une raison pour tolerer n'importe quoi.
Il faut quand meme verifier que meme en restant dans Omega0g on peut
atteindre un etat ou on a sa disposition une machine de Turing
universelle. Sinon, c'est pas la peine d'avoir un ordinateur.
Ca, pas de probleme. Je travaille sur pleins de machines ou je n'ai pas
access à la configuration (je n'y suis pas root), je peux cependant y
executer tous les algorithmes possibles.
D'ailleurs j'aime pas les sys de confs qui sont pas turing-complets ;-)
Une conf pour non experts ne peut pas l'etre, en raison meme des
contraintes que l'on s'y est imposé (il me semble impossible d'assurer
algorithmiquement le bon fonctionnement d'un systeme de ce type).
d/ inclus dans Omega_{coherent}
quoi quoi quoi ? on peut meme rien casser avec une GUI ?
tu te restreints peut etre aux GUI non-buggees ? :)
Oui, je veux que si le non expert veut faire quelque chose sans trop
savoir quoi, il puisse cliquer au hasard et toujours avoir une machine
qui marche "raisonablement".
OK, c'est un peu utopique.
sinon, toutes ces definitions pour dire que :
- macos <10, on clique ca marche, mais c'est chiant de faire des
choses bizarres ;
- macos X, on clique ca marche, et ca permet meme de faire pas mal de
choses bizarres ;
- windows, c'est le bordel ;
- linux, on peut cliquer si on veut, mais ca marche quand meme mieux
avec un clavier ;
ca m'a bien amuse.
Ouais, cette construction m'est venu dans la nuit et je l'ai écrit tel
quel au matin... C'est probablement un peu ridicule...
FU2 fr.sci.maths ? :)
Pas vraiment, c'est aps des math, mais vraiment une question d'interface
humains/machines.
Merci encore pour cette critique pointue!
Merci de cette critique qui pointe mes erreurs et ommissions.
Christophe Delage wrote:
In article <cel3cs$ig1$1@sunnews.cern.ch>, Yannick Patois wrote:
Perso, j'aime pas utiliser des lettres grecques pour les machins
pas bien definis, mais heureusement, dans la suite, ca s'arrange.
Je le laisse ou j'utilise un autre terme ?
J'ai pas d'idees...
Un systeme de configuration donnee ne permet pas forcement d'adresser
tout Omega,
j'ajouterai meme qu'une fonction de configuration n'est pas definie
sur tout Omega. (genre, dans l'etat "j'ai efface le fichier
/etc/important" comment je modifie le fichier /etc/important ?)
Oui, tu as raison. Et une bonne interface ne doit proposer que des
fonctions définie pour l'état courant.
et on peut rajouter :
pour tout E dans Omega, |F_c(E)| leq 1
parcequ'un processus de configuration est un processus deterministe,
c'est bien connu. (sic)
Si on admet que l'ordinateur est un systeme déterministe et que la seule
entrée est l'execution de F_c() alors ca doit etre vrais.
C'est effectivement un postulat implicite (mais raisonable) que j'ai
utilisé.
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.
avec ma definition, on peut rendre Omega encore plus cryptique :
(Cup_{c} F_c)^*(E0), c'est mieux non ? :)
Omega0, non ?
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)).
Je recapitule ce que j'ai cru comprendre :
- tu as un ensemble Omega
- tu appelles "systeme de configuration" un paquet de fonctions
partielles sur Omega
- tu choisis E0 dans Omega
E0 est sensé etre l'état inital, juste après l'installation, dans un cas
concret.
- tu consideres Omega0 la partie de Omega atteignable par ton
"systeme de configuration"
- tu dis que Omega0 est stable s'il est fortement connexe (pour
parler "graphes" parceque c'est classe d'utiliser le vocabulaire
d'une autre theorie, juste pour faire joli ;-))
Stable, ca serait juste connexe, le chemin pour y arriver peut etre
non direct.
- 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.
clair, c'est meme le principal, je dirais.
OK, nous voila d'accord sur un point (au dela des definitions).
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.
je pense franchement qu'il y a des tas d'etats non atteignables (pas
seulement des "pas facile" a atteindre) dans les sys de conf qu'on
rencontre dans le vrai monde.
par exemple, les etats tels que tous les bits de la RAM sont a 0,
meme si t'as un un cd de boot, je parie que t'y arrive pas.
meme en ecrivant un noyau from scratch, je sais pas si c'est possible.
Je pense que c'est possible en ecrivant un noyau qui lance un programme
qui efface la RAM (et le noyau) dont la derniere routine soit
suffisement réduite pour tenir dans le cache processeur. Ensuite un
reset doit passer tous les états du proc en defaut et c'est bon.
OK, ca sert a rien, et il y a sans doute des états vraiment inacessible
a l'interieur du proc lui meme.
interdire les arguments au noyal, c'est violent comme contrainte
sur le sys de conf. :-)
Ils sont autorisés seulement s'ils sont défini avant un reboot (par
exemlpe, je change de noyau, je passe par le systeme de conf et au
procahin reboot un argument est appliqué). Je veux excclure la nécéssité
par l'utilisateur non expert de tapper des arguments obscurs dans une
interface tres réduite avant le boot. Ceci aussi oblige a considerer une
methode de config telle que "tu reboot en single user et on répare".
Passons maintenant aux axiomes:
*** A/ Je pretends ici que si Omega0 est inclus dans Omega_{okc} la
FCNE est meilleure.
le contraire, plutot ("Il est evident que Omega0 est inclus dans
Omega_{okc}" dixit plus haut), non ?
J'ai ecris quoi comme conneries, moi ? Je relis...
Oui, en fait, j'avais oublié que j'avais dis stable pluis haut.
En fait, cette condition oblige a avoir un systeme stable.
On peut éventuellement "récupéré" un systeme égaré (donc Omega_{okc}
n'est pas forcement inclus dans Omega0)
*** 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.
ah mais non, rien ne va plus la.
ca voudrait dire que la tache d'apprentissage de perl est compliquee ?
c'est pas possible ;-)
Hum, je maintiens. Dans le meme ordre plus le graphe est proche d'un
graphe fortemet connexe (ou disons pus le nombre maximum de noeuds a
franchir pour passer d'un état quelconque a un autre est faible) mieux
c'est.
Ah oui mais la, tu consideres comme (F_c) *toutes* les modifs de /etc,
c'est trop gros. Si tu te restreints a des conventions de syntaxe
non ambigues, et aux modifs qui font que des trucs bien, ca va.
Le probleme c'est que l'utilisateur non expert, il sait pas tout ca. Il
clique et tappe du texte au hasard, disons un peu mieux que le hasard
mais d'un rapport signal/bruit qui décroit avec la compétance.
Le fait que je ne puisse pas écrire "Oui" en face d'un argument que je
veux activer est un probleme. Le fait qu'il ne soit pas immédiat que les
seules réponses possible soiuent "yes" et "no" (encore faut il connaitre
ces termes et leur sens dans une langue étrangere) est un autre
probleme, le fait que parfois on puisse en plus avoir, par exemple
"auto" ou "user-defined", je ne vois pas de moyen de borner cela.
L'interface interactive présente en meme temps que la question l'étendus
des réponses possibles.
- 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}
euh... j'ai ptet loupe un truc dans tes definitions, mais j'avais
compris que Omega_{coherent} subset Omega_{ok}. (c'est dans l'autre
sens ?)
Non, tu as raison, il faut inverser. Tu fais souvent de la relecture
pour des publi ? ;)
a/ On y peut rien, on sait que c'est comme ca, c'est meme voulu.
"on n'y peut rien" n'est pas une raison pour tolerer n'importe quoi.
Il faut quand meme verifier que meme en restant dans Omega0g on peut
atteindre un etat ou on a sa disposition une machine de Turing
universelle. Sinon, c'est pas la peine d'avoir un ordinateur.
Ca, pas de probleme. Je travaille sur pleins de machines ou je n'ai pas
access à la configuration (je n'y suis pas root), je peux cependant y
executer tous les algorithmes possibles.
D'ailleurs j'aime pas les sys de confs qui sont pas turing-complets ;-)
Une conf pour non experts ne peut pas l'etre, en raison meme des
contraintes que l'on s'y est imposé (il me semble impossible d'assurer
algorithmiquement le bon fonctionnement d'un systeme de ce type).
d/ inclus dans Omega_{coherent}
quoi quoi quoi ? on peut meme rien casser avec une GUI ?
tu te restreints peut etre aux GUI non-buggees ? :)
Oui, je veux que si le non expert veut faire quelque chose sans trop
savoir quoi, il puisse cliquer au hasard et toujours avoir une machine
qui marche "raisonablement".
OK, c'est un peu utopique.
sinon, toutes ces definitions pour dire que :
- macos <10, on clique ca marche, mais c'est chiant de faire des
choses bizarres ;
- macos X, on clique ca marche, et ca permet meme de faire pas mal de
choses bizarres ;
- windows, c'est le bordel ;
- linux, on peut cliquer si on veut, mais ca marche quand meme mieux
avec un clavier ;
ca m'a bien amuse.
Ouais, cette construction m'est venu dans la nuit et je l'ai écrit tel
quel au matin... C'est probablement un peu ridicule...
FU2 fr.sci.maths ? :)
Pas vraiment, c'est aps des math, mais vraiment une question d'interface
humains/machines.
Merci encore pour cette critique pointue!
Merci de cette critique qui pointe mes erreurs et ommissions.
Christophe Delage wrote:In article <cel3cs$ig1$, Yannick Patois wrote:
Perso, j'aime pas utiliser des lettres grecques pour les machins
pas bien definis, mais heureusement, dans la suite, ca s'arrange.
Je le laisse ou j'utilise un autre terme ?
J'ai pas d'idees...
Un systeme de configuration donnee ne permet pas forcement d'adresser
tout Omega,
j'ajouterai meme qu'une fonction de configuration n'est pas definie
sur tout Omega. (genre, dans l'etat "j'ai efface le fichier
/etc/important" comment je modifie le fichier /etc/important ?)
Oui, tu as raison. Et une bonne interface ne doit proposer que des
fonctions définie pour l'état courant.
et on peut rajouter :
pour tout E dans Omega, |F_c(E)| leq 1
parcequ'un processus de configuration est un processus deterministe,
c'est bien connu. (sic)
Si on admet que l'ordinateur est un systeme déterministe et que la seule
entrée est l'execution de F_c() alors ca doit etre vrais.
C'est effectivement un postulat implicite (mais raisonable) que j'ai
utilisé.
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.
avec ma definition, on peut rendre Omega encore plus cryptique :
(Cup_{c} F_c)^*(E0), c'est mieux non ? :)
Omega0, non ?
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)).
Je recapitule ce que j'ai cru comprendre :
- tu as un ensemble Omega
- tu appelles "systeme de configuration" un paquet de fonctions
partielles sur Omega
- tu choisis E0 dans Omega
E0 est sensé etre l'état inital, juste après l'installation, dans un cas
concret.- tu consideres Omega0 la partie de Omega atteignable par ton
"systeme de configuration"
- tu dis que Omega0 est stable s'il est fortement connexe (pour
parler "graphes" parceque c'est classe d'utiliser le vocabulaire
d'une autre theorie, juste pour faire joli ;-))
Stable, ca serait juste connexe, le chemin pour y arriver peut etre
non direct.
- 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.
clair, c'est meme le principal, je dirais.
OK, nous voila d'accord sur un point (au dela des definitions).
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.
je pense franchement qu'il y a des tas d'etats non atteignables (pas
seulement des "pas facile" a atteindre) dans les sys de conf qu'on
rencontre dans le vrai monde.
par exemple, les etats tels que tous les bits de la RAM sont a 0,
meme si t'as un un cd de boot, je parie que t'y arrive pas.
meme en ecrivant un noyau from scratch, je sais pas si c'est possible.
Je pense que c'est possible en ecrivant un noyau qui lance un programme
qui efface la RAM (et le noyau) dont la derniere routine soit
suffisement réduite pour tenir dans le cache processeur. Ensuite un
reset doit passer tous les états du proc en defaut et c'est bon.
OK, ca sert a rien, et il y a sans doute des états vraiment inacessible
a l'interieur du proc lui meme.
interdire les arguments au noyal, c'est violent comme contrainte
sur le sys de conf. :-)
Ils sont autorisés seulement s'ils sont défini avant un reboot (par
exemlpe, je change de noyau, je passe par le systeme de conf et au
procahin reboot un argument est appliqué). Je veux excclure la nécéssité
par l'utilisateur non expert de tapper des arguments obscurs dans une
interface tres réduite avant le boot. Ceci aussi oblige a considerer une
methode de config telle que "tu reboot en single user et on répare".
Passons maintenant aux axiomes:
*** A/ Je pretends ici que si Omega0 est inclus dans Omega_{okc} la
FCNE est meilleure.
le contraire, plutot ("Il est evident que Omega0 est inclus dans
Omega_{okc}" dixit plus haut), non ?
J'ai ecris quoi comme conneries, moi ? Je relis...
Oui, en fait, j'avais oublié que j'avais dis stable pluis haut.
En fait, cette condition oblige a avoir un systeme stable.
On peut éventuellement "récupéré" un systeme égaré (donc Omega_{okc}
n'est pas forcement inclus dans Omega0)
*** 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.
ah mais non, rien ne va plus la.
ca voudrait dire que la tache d'apprentissage de perl est compliquee ?
c'est pas possible ;-)
Hum, je maintiens. Dans le meme ordre plus le graphe est proche d'un
graphe fortemet connexe (ou disons pus le nombre maximum de noeuds a
franchir pour passer d'un état quelconque a un autre est faible) mieux
c'est.
Ah oui mais la, tu consideres comme (F_c) *toutes* les modifs de /etc,
c'est trop gros. Si tu te restreints a des conventions de syntaxe
non ambigues, et aux modifs qui font que des trucs bien, ca va.
Le probleme c'est que l'utilisateur non expert, il sait pas tout ca. Il
clique et tappe du texte au hasard, disons un peu mieux que le hasard
mais d'un rapport signal/bruit qui décroit avec la compétance.
Le fait que je ne puisse pas écrire "Oui" en face d'un argument que je
veux activer est un probleme. Le fait qu'il ne soit pas immédiat que les
seules réponses possible soiuent "yes" et "no" (encore faut il connaitre
ces termes et leur sens dans une langue étrangere) est un autre
probleme, le fait que parfois on puisse en plus avoir, par exemple
"auto" ou "user-defined", je ne vois pas de moyen de borner cela.
L'interface interactive présente en meme temps que la question l'étendus
des réponses possibles.
- 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}
euh... j'ai ptet loupe un truc dans tes definitions, mais j'avais
compris que Omega_{coherent} subset Omega_{ok}. (c'est dans l'autre
sens ?)
Non, tu as raison, il faut inverser. Tu fais souvent de la relecture
pour des publi ? ;)
a/ On y peut rien, on sait que c'est comme ca, c'est meme voulu.
"on n'y peut rien" n'est pas une raison pour tolerer n'importe quoi.
Il faut quand meme verifier que meme en restant dans Omega0g on peut
atteindre un etat ou on a sa disposition une machine de Turing
universelle. Sinon, c'est pas la peine d'avoir un ordinateur.
Ca, pas de probleme. Je travaille sur pleins de machines ou je n'ai pas
access à la configuration (je n'y suis pas root), je peux cependant y
executer tous les algorithmes possibles.
D'ailleurs j'aime pas les sys de confs qui sont pas turing-complets ;-)
Une conf pour non experts ne peut pas l'etre, en raison meme des
contraintes que l'on s'y est imposé (il me semble impossible d'assurer
algorithmiquement le bon fonctionnement d'un systeme de ce type).
d/ inclus dans Omega_{coherent}
quoi quoi quoi ? on peut meme rien casser avec une GUI ?
tu te restreints peut etre aux GUI non-buggees ? :)
Oui, je veux que si le non expert veut faire quelque chose sans trop
savoir quoi, il puisse cliquer au hasard et toujours avoir une machine
qui marche "raisonablement".
OK, c'est un peu utopique.
sinon, toutes ces definitions pour dire que :
- macos <10, on clique ca marche, mais c'est chiant de faire des
choses bizarres ;
- macos X, on clique ca marche, et ca permet meme de faire pas mal de
choses bizarres ;
- windows, c'est le bordel ;
- linux, on peut cliquer si on veut, mais ca marche quand meme mieux
avec un clavier ;
ca m'a bien amuse.
Ouais, cette construction m'est venu dans la nuit et je l'ai écrit tel
quel au matin... C'est probablement un peu ridicule...
FU2 fr.sci.maths ? :)
Pas vraiment, c'est aps des math, mais vraiment une question d'interface
humains/machines.
Merci encore pour cette critique pointue!
