Je remarque que tous les gens intelligents m'ont répondu
avec des réflexions très savantes.
Mais moi qui suite à toutes ces réflexion est convaincu d'être un ignorant,
je constate donc que linux est fait pour une élite. Que l'utilisateur lambda
qui veut s' investir ne peut le faire dans linux.
On parle de chmod avec des numéros mais où trouver la liste des numéro avec
les valeurs et leurs effets après des journées de recherche sur internet
alors que mon temps est compté?
Pour postgresql on explique mais dans tous les sens. Il faut deux jours de
recherche pour savoir qu'un su postgres n'est pas le su root. On explique
tous sauf les points de départs. Dans chaque explication rencontrée il y a
toujours un élément qui manque. Ce genre de chose est certainement le grand
point faible de linux.
Ce que je voulais dire , c'est que pour décoller il faut qu'il y est de la
part de la communauté linux , un site qui permet à chacun depuis le départ:
à ZERO jusqu'à un utilisateur autonome qui puisse se référer.
Sachez qui si vous vous n' êtes pas au point de départ le reste des
utilisateurs d'informatique le sont pour linux cela fait 90% du parc
informatique. Ce que je viens de dire Microsoft la compris puisque les 90%
l'utilise uniquement avec du BEABA pour 80% de leurs besoins. Le reste
vient en fonction de la progression de chacun. La litérature n'est pas
beaucoup mieux.
Le 08-05-2004, à propos de Re: linux et windows, Rakotomandimby Mihamina écrivait dans fr.comp.os.linux.debats :
Le but n'a pas ete de remplacer Apache . Le but n'a meme pas ete de vanter les merites de Zope ( et donc du Zserver ) . Le but a ete juste de reconforter JKB sur le fait qu'il n'existe pas _que_ des panurgistes ...
Je le sais très bien, et heureusement encore, mais il faut bien comprendre que les moutons sont très nombreux.
JKB
Le 08-05-2004, à propos de
Re: linux et windows,
Rakotomandimby Mihamina écrivait dans fr.comp.os.linux.debats :
Le but n'a pas ete de remplacer Apache . Le but n'a meme pas ete de
vanter les merites de Zope ( et donc du Zserver ) . Le but a ete juste
de reconforter JKB sur le fait qu'il n'existe pas _que_ des panurgistes ...
Je le sais très bien, et heureusement encore, mais il faut bien
comprendre que les moutons sont très nombreux.
Le 08-05-2004, à propos de Re: linux et windows, Rakotomandimby Mihamina écrivait dans fr.comp.os.linux.debats :
Le but n'a pas ete de remplacer Apache . Le but n'a meme pas ete de vanter les merites de Zope ( et donc du Zserver ) . Le but a ete juste de reconforter JKB sur le fait qu'il n'existe pas _que_ des panurgistes ...
Je le sais très bien, et heureusement encore, mais il faut bien comprendre que les moutons sont très nombreux.
JKB
Rakotomandimby Mihamina
nicolas vigier wrote:
Ha bon Zope c'est un remplacant d'apache maintenant ?
J'ai jamais dit ca ! Je voulais dire que j'ai eu a choisir un serveur http . Et la ou des "moutons de panurge" auraient vite fait de penser Apache , j'ai plutot pense Zope . Pour mon besoin , Zope est ce qui me convient . Pour les besoins d'un autre , voir avec cet autre .
Mais c'est quoi tous ces gens qui se servent d'apache pour faire marcher leur Zope alors ?
Ben des gens qui en eprouvent le besoin surement ! Et si ils le font c'est qu'il ont leur raisons . Je ne pense aucun mal ni d'Apache ni de ceux qui l'utilisent ... chacun a fait son choix technologique ..
Peu être que tu veux parler de ZServer, mais ca ne remplace pas Apache.
Le but n'a pas ete de remplacer Apache . Le but n'a meme pas ete de vanter les merites de Zope ( et donc du Zserver ) . Le but a ete juste de reconforter JKB sur le fait qu'il n'existe pas _que_ des panurgistes ...
T'es pas censé connaitre ca en tant que "Professionnel de l'informatique" qui a fait de très longues années d'étude ? :)
L'informatique est un vaste sujet . D'une part je n'ai jamais dit que j'etais un professionnel de l'informatique . Je connais des choses que tu ne connais pas , et vice versa ... -- Rakotomandimby Mihamina Andrianifaharana Tel : +33 2 38 76 43 65 http://stko.dyndns.info/site_principal/Members/mihamina
nicolas vigier wrote:
Ha bon Zope c'est un remplacant d'apache maintenant ?
J'ai jamais dit ca !
Je voulais dire que j'ai eu a choisir un serveur http . Et la ou des
"moutons de panurge" auraient vite fait de penser Apache , j'ai plutot
pense Zope . Pour mon besoin , Zope est ce qui me convient . Pour les
besoins d'un autre , voir avec cet autre .
Mais c'est quoi tous ces gens qui se servent d'apache pour faire marcher
leur Zope alors ?
Ben des gens qui en eprouvent le besoin surement ! Et si ils le font
c'est qu'il ont leur raisons . Je ne pense aucun mal ni d'Apache ni de
ceux qui l'utilisent ... chacun a fait son choix technologique ..
Peu être que tu veux parler de ZServer, mais ca ne remplace pas Apache.
Le but n'a pas ete de remplacer Apache . Le but n'a meme pas ete de
vanter les merites de Zope ( et donc du Zserver ) . Le but a ete juste
de reconforter JKB sur le fait qu'il n'existe pas _que_ des panurgistes ...
T'es pas censé connaitre ca en tant que "Professionnel de l'informatique"
qui a fait de très longues années d'étude ? :)
L'informatique est un vaste sujet . D'une part je n'ai jamais dit que
j'etais un professionnel de l'informatique . Je connais des choses que
tu ne connais pas , et vice versa ...
--
Rakotomandimby Mihamina Andrianifaharana
Tel : +33 2 38 76 43 65
http://stko.dyndns.info/site_principal/Members/mihamina
Ha bon Zope c'est un remplacant d'apache maintenant ?
J'ai jamais dit ca ! Je voulais dire que j'ai eu a choisir un serveur http . Et la ou des "moutons de panurge" auraient vite fait de penser Apache , j'ai plutot pense Zope . Pour mon besoin , Zope est ce qui me convient . Pour les besoins d'un autre , voir avec cet autre .
Mais c'est quoi tous ces gens qui se servent d'apache pour faire marcher leur Zope alors ?
Ben des gens qui en eprouvent le besoin surement ! Et si ils le font c'est qu'il ont leur raisons . Je ne pense aucun mal ni d'Apache ni de ceux qui l'utilisent ... chacun a fait son choix technologique ..
Peu être que tu veux parler de ZServer, mais ca ne remplace pas Apache.
Le but n'a pas ete de remplacer Apache . Le but n'a meme pas ete de vanter les merites de Zope ( et donc du Zserver ) . Le but a ete juste de reconforter JKB sur le fait qu'il n'existe pas _que_ des panurgistes ...
T'es pas censé connaitre ca en tant que "Professionnel de l'informatique" qui a fait de très longues années d'étude ? :)
L'informatique est un vaste sujet . D'une part je n'ai jamais dit que j'etais un professionnel de l'informatique . Je connais des choses que tu ne connais pas , et vice versa ... -- Rakotomandimby Mihamina Andrianifaharana Tel : +33 2 38 76 43 65 http://stko.dyndns.info/site_principal/Members/mihamina
luc wastiaux
JKB wrote:
Le 08-05-2004, à propos de Re: linux et windows, Michel Talon écrivait dans fr.comp.os.linux.debats :
JKB wrote:
Mais à ce jour, je n'ai pas vu beaucoup de code écrit en C fiable (avec test de toutes les valeurs retournées, pas seulement celles du malloc(), mais de toutes les autres fonctions...).
Parce que le même programme écrit en Fortran est plus fiable! Allons c'est pitoyable. En ce moment j'essaye de comprendre un programme écrit en Fortran (COLNEW) qui par ailleurs est génial, je m'arrache les cheveux, c'est pire que de l'assembleur.
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs écrits en C (ou C++, même combat) du type :
unsigned char i; i = 255; i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre une question d'outils ?
-- luc wastiaux
JKB wrote:
Le 08-05-2004, à propos de
Re: linux et windows,
Michel Talon écrivait dans fr.comp.os.linux.debats :
JKB <bertrand@chezmoi.com> wrote:
Mais à ce jour, je n'ai pas vu beaucoup de code écrit en C fiable
(avec test de toutes les valeurs retournées, pas seulement celles du
malloc(), mais de toutes les autres fonctions...).
Parce que le même programme écrit en Fortran est plus fiable! Allons
c'est pitoyable. En ce moment j'essaye de comprendre un programme
écrit en Fortran (COLNEW) qui par ailleurs est génial, je m'arrache
les cheveux, c'est pire que de l'assembleur.
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs
écrits en C (ou C++, même combat) du type :
unsigned char i;
i = 255;
i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux
x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre
une question d'outils ?
Le 08-05-2004, à propos de Re: linux et windows, Michel Talon écrivait dans fr.comp.os.linux.debats :
JKB wrote:
Mais à ce jour, je n'ai pas vu beaucoup de code écrit en C fiable (avec test de toutes les valeurs retournées, pas seulement celles du malloc(), mais de toutes les autres fonctions...).
Parce que le même programme écrit en Fortran est plus fiable! Allons c'est pitoyable. En ce moment j'essaye de comprendre un programme écrit en Fortran (COLNEW) qui par ailleurs est génial, je m'arrache les cheveux, c'est pire que de l'assembleur.
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs écrits en C (ou C++, même combat) du type :
unsigned char i; i = 255; i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre une question d'outils ?
-- luc wastiaux
Richard Delorme
JKB wrote:
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs écrits en C (ou C++, même combat) du type :
unsigned char i; i = 255; i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre une question d'outils ?
Quel bug ?
Le code écrit par JKB est parfaitement légal mais non portable en raison d'un comportement défini par l'implémentation : i peut valoir 256 ou 0 selon la valeur de UCHAR_MAX définie dans <limits.h>. Pour rendre le code portable on peut écrire, si la valeur attendue de i est 0 : unsigned char i; i = -1; i++;
ou unsigned char i; i = UCHAR_MAX; i++;
ou uint8_t i; i = 255; i++; Avec la nuance, pour ce dernier exemple, qu'il peut ne pas compiler partout, mais il marche partout à l'identique là où il compile.
J'espère que Valgrind ne se plaint pas sur du code bien formé.
-- Richard
JKB wrote:
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs
écrits en C (ou C++, même combat) du type :
unsigned char i;
i = 255;
i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux
x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre
une question d'outils ?
Quel bug ?
Le code écrit par JKB est parfaitement légal mais non portable en raison
d'un comportement défini par l'implémentation : i peut valoir 256 ou 0
selon la valeur de UCHAR_MAX définie dans <limits.h>.
Pour rendre le code portable on peut écrire, si la valeur attendue de i
est 0 :
unsigned char i;
i = -1;
i++;
ou
unsigned char i;
i = UCHAR_MAX;
i++;
ou
uint8_t i;
i = 255;
i++;
Avec la nuance, pour ce dernier exemple, qu'il peut ne pas compiler
partout, mais il marche partout à l'identique là où il compile.
J'espère que Valgrind ne se plaint pas sur du code bien formé.
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs écrits en C (ou C++, même combat) du type :
unsigned char i; i = 255; i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre une question d'outils ?
Quel bug ?
Le code écrit par JKB est parfaitement légal mais non portable en raison d'un comportement défini par l'implémentation : i peut valoir 256 ou 0 selon la valeur de UCHAR_MAX définie dans <limits.h>. Pour rendre le code portable on peut écrire, si la valeur attendue de i est 0 : unsigned char i; i = -1; i++;
ou unsigned char i; i = UCHAR_MAX; i++;
ou uint8_t i; i = 255; i++; Avec la nuance, pour ce dernier exemple, qu'il peut ne pas compiler partout, mais il marche partout à l'identique là où il compile.
J'espère que Valgrind ne se plaint pas sur du code bien formé.
-- Richard
Richard Delorme
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs écrits en C (ou C++, même combat) du type :
unsigned char i; i = 255; i++;
et boum !
Pourquoi ? Même sur une DS-9000, ce code doit bien se comporter.
Et au bout de trois semaines de calculs sur un Convex, j'aime autant dire que j'étais content ! Et lorsqu'on n'a pas écrit soi-même le petit bout de .h en cause, on peut chercher des heures !
Il n'existe aucun contrôle de type en C.
Aucun est exagéré. Le langage C est un langage typé, avec un contrôle statique (à la compilation) du type. Sur les types non signés, qui obéissent à une arithmétique modulo, les dépassements de capacité ne sont pas possibles, mais ils le sont sur les types signés, et une implémentation est libre de générer un signal dans ce cas.
Je ne dis pas qu'il faut être aussi paranoïaque qu'en ADA, mais il y a un juste milieu à trouver. Le compilo sous VMS retourne par défaut une erreur ou un warning selon les options de compilation. g77 est laxiste, mais c'est un autre débat ! Chaque langage est prévu pour un type d'application bien particulier et il n'existe aucun langage généraliste à moins de le surcharger de rustines (style PL/1, nouveau besoin, nouveau patch !).
En fait, le langage C a été créé parce que leurs auteurs n'aimaient pas le PL/1.
Le C a été créé pour faire de la programmation système.
Non. Le C a été créé comme langage généraliste, pour écrire un système, mais aussi des outils.
Il est ridicule de vouloir écrire un OS en ADA ou en Fortran, de même qu'il est complètement absurde de vouloir écrire un programme scientifique sérieux en C (de façon simple). Et je sais de quoi je parle... Si vous voulez voir un peu comment contrôler les dépassements de capacité en C, regardez un peu le fichier src/depassements.c de mon RPL/2 (www.makalis.fr/~bertrand/rpl2) et dites-moi honnêtement si c'est simple et facilement compréhensible par un programmeur de base. Je n'ai _jamais_ vu de telles protections dans des programmes complexes d'analyse numériques écrits dans des langages peu fiables (par peu fiables, j'entends des langages qui laissent à l'utilisateur le choix de vérifier les résultats des calculs).
Le contrôle des dépassements n'empêche pas les programmes de faire boom, surtout quand ils fonctionnent dans une fusée.
-- Richard
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs
écrits en C (ou C++, même combat) du type :
unsigned char i;
i = 255;
i++;
et boum !
Pourquoi ? Même sur une DS-9000, ce code doit bien se comporter.
Et au bout de trois semaines de calculs sur un Convex,
j'aime autant dire que j'étais content ! Et lorsqu'on n'a pas écrit
soi-même le petit bout de .h en cause, on peut chercher des heures !
Il n'existe aucun contrôle de type en C.
Aucun est exagéré. Le langage C est un langage typé, avec un contrôle
statique (à la compilation) du type. Sur les types non signés, qui
obéissent à une arithmétique modulo, les dépassements de capacité ne
sont pas possibles, mais ils le sont sur les types signés, et une
implémentation est libre de générer un signal dans ce cas.
Je ne dis pas qu'il faut
être aussi paranoïaque qu'en ADA, mais il y a un juste milieu à
trouver. Le compilo sous VMS retourne par défaut une erreur ou un
warning selon les options de compilation. g77 est laxiste, mais
c'est un autre débat ! Chaque langage est prévu pour un type
d'application bien particulier et il n'existe aucun langage
généraliste à moins de le surcharger de rustines (style PL/1,
nouveau besoin, nouveau patch !).
En fait, le langage C a été créé parce que leurs auteurs n'aimaient pas
le PL/1.
Le C a été créé pour faire de la programmation système.
Non. Le C a été créé comme langage généraliste, pour écrire un système,
mais aussi des outils.
Il est
ridicule de vouloir écrire un OS en ADA ou en Fortran, de même qu'il
est complètement absurde de vouloir écrire un programme scientifique
sérieux en C (de façon simple). Et je sais de quoi je parle... Si
vous voulez voir un peu comment contrôler les dépassements de
capacité en C, regardez un peu le fichier src/depassements.c de mon
RPL/2 (www.makalis.fr/~bertrand/rpl2) et dites-moi honnêtement si
c'est simple et facilement compréhensible par un programmeur de base.
Je n'ai _jamais_ vu de telles protections dans des programmes
complexes d'analyse numériques écrits dans des langages peu
fiables (par peu fiables, j'entends des langages qui laissent à
l'utilisateur le choix de vérifier les résultats des calculs).
Le contrôle des dépassements n'empêche pas les programmes de faire boom,
surtout quand ils fonctionnent dans une fusée.
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs écrits en C (ou C++, même combat) du type :
unsigned char i; i = 255; i++;
et boum !
Pourquoi ? Même sur une DS-9000, ce code doit bien se comporter.
Et au bout de trois semaines de calculs sur un Convex, j'aime autant dire que j'étais content ! Et lorsqu'on n'a pas écrit soi-même le petit bout de .h en cause, on peut chercher des heures !
Il n'existe aucun contrôle de type en C.
Aucun est exagéré. Le langage C est un langage typé, avec un contrôle statique (à la compilation) du type. Sur les types non signés, qui obéissent à une arithmétique modulo, les dépassements de capacité ne sont pas possibles, mais ils le sont sur les types signés, et une implémentation est libre de générer un signal dans ce cas.
Je ne dis pas qu'il faut être aussi paranoïaque qu'en ADA, mais il y a un juste milieu à trouver. Le compilo sous VMS retourne par défaut une erreur ou un warning selon les options de compilation. g77 est laxiste, mais c'est un autre débat ! Chaque langage est prévu pour un type d'application bien particulier et il n'existe aucun langage généraliste à moins de le surcharger de rustines (style PL/1, nouveau besoin, nouveau patch !).
En fait, le langage C a été créé parce que leurs auteurs n'aimaient pas le PL/1.
Le C a été créé pour faire de la programmation système.
Non. Le C a été créé comme langage généraliste, pour écrire un système, mais aussi des outils.
Il est ridicule de vouloir écrire un OS en ADA ou en Fortran, de même qu'il est complètement absurde de vouloir écrire un programme scientifique sérieux en C (de façon simple). Et je sais de quoi je parle... Si vous voulez voir un peu comment contrôler les dépassements de capacité en C, regardez un peu le fichier src/depassements.c de mon RPL/2 (www.makalis.fr/~bertrand/rpl2) et dites-moi honnêtement si c'est simple et facilement compréhensible par un programmeur de base. Je n'ai _jamais_ vu de telles protections dans des programmes complexes d'analyse numériques écrits dans des langages peu fiables (par peu fiables, j'entends des langages qui laissent à l'utilisateur le choix de vérifier les résultats des calculs).
Le contrôle des dépassements n'empêche pas les programmes de faire boom, surtout quand ils fonctionnent dans une fusée.
-- Richard
luc wastiaux
luc wastiaux wrote:
JKB wrote:
Le 08-05-2004, à propos de Re: linux et windows, Michel Talon écrivait dans fr.comp.os.linux.debats :
JKB wrote:
Mais à ce jour, je n'ai pas vu beaucoup de code écrit en C fiable (avec test de toutes les valeurs retournées, pas seulement celles du malloc(), mais de toutes les autres fonctions...).
Parce que le même programme écrit en Fortran est plus fiable! Allons c'est pitoyable. En ce moment j'essaye de comprendre un programme écrit en Fortran (COLNEW) qui par ailleurs est génial, je m'arrache les cheveux, c'est pire que de l'assembleur.
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs écrits en C (ou C++, même combat) du type :
unsigned char i; i = 255; i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre une question d'outils ?
En fait je viens de tester, et valgrind ne signale pas d'erreur. Je pensais qu'il le ferait mais.. ca n'a pas l'air d'etre aussi simple que ca.
-- luc wastiaux
luc wastiaux wrote:
JKB wrote:
Le 08-05-2004, à propos de
Re: linux et windows,
Michel Talon écrivait dans fr.comp.os.linux.debats :
JKB <bertrand@chezmoi.com> wrote:
Mais à ce jour, je n'ai pas vu beaucoup de code écrit en C fiable
(avec test de toutes les valeurs retournées, pas seulement
celles du
malloc(), mais de toutes les autres fonctions...).
Parce que le même programme écrit en Fortran est plus fiable! Allons
c'est pitoyable. En ce moment j'essaye de comprendre un programme
écrit en Fortran (COLNEW) qui par ailleurs est génial, je m'arrache
les cheveux, c'est pire que de l'assembleur.
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs
écrits en C (ou C++, même combat) du type :
unsigned char i;
i = 255;
i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux
x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre
une question d'outils ?
En fait je viens de tester, et valgrind ne signale pas d'erreur. Je
pensais qu'il le ferait mais.. ca n'a pas l'air d'etre aussi simple que ca.
Le 08-05-2004, à propos de Re: linux et windows, Michel Talon écrivait dans fr.comp.os.linux.debats :
JKB wrote:
Mais à ce jour, je n'ai pas vu beaucoup de code écrit en C fiable (avec test de toutes les valeurs retournées, pas seulement celles du malloc(), mais de toutes les autres fonctions...).
Parce que le même programme écrit en Fortran est plus fiable! Allons c'est pitoyable. En ce moment j'essaye de comprendre un programme écrit en Fortran (COLNEW) qui par ailleurs est génial, je m'arrache les cheveux, c'est pire que de l'assembleur.
Et oui... J'ai déjà perdu des heures infinies à rechercher des bugs écrits en C (ou C++, même combat) du type :
unsigned char i; i = 255; i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre une question d'outils ?
En fait je viens de tester, et valgrind ne signale pas d'erreur. Je pensais qu'il le ferait mais.. ca n'a pas l'air d'etre aussi simple que ca.
-- luc wastiaux
Jerome Lambert
Le Fri, 07 May 2004 23:53:39 +0200, amorces a écrit :
Je remarque que tous les gens intelligents m'ont répondu avec des réflexions très savantes. Mais moi qui suite à toutes ces réflexion est convaincu d'être un ignorant, je constate donc que linux est fait pour une élite. Que l'utilisateur lambda qui veut s' investir ne peut le faire dans linux.
Bien sur que si. Tout est une question de volonté (comme beaucoup de choses dans la vie d'ailleurs...).
On parle de chmod avec des numéros mais où trouver la liste des numéro avec les valeurs et leurs effets après des journées de recherche sur internet alors que mon temps est compté?
Et bien si le type connait le principe de man, maintes fois exposé dans toute doc digne de ce nom, il trouvera l'extrait suivant en tapant "man chmod":
Une valeur numérique pour le mode est constituée de 1 à 4 chiffres en octal (0 a 7), calculés en additionnant les bits de valeurs 4, 2, et 1. Un bit non mentionné étant considéré comme nul. Le premier chiffre cor- respond aux attributs Set-UID (4), Set-GID (2), et conservation du code en mémoire ['sticky bit'] (1). Le second chiffre correspond aux autorisations de lecture (4), écriture (2) et exécution pour l'utilisateur propriétaire du fichier. Les troisième et quatrième chiffres correspondent respectivement aux autorisations d'accès pour les membres du groupe du fichier, et pour les autres utilisateurs.
Dingue, non?
(snip postresqul)
Ce que je voulais dire , c'est que pour décoller il faut qu'il y est de la part de la communauté linux , un site qui permet à chacun depuis le départ: à ZERO jusqu'à un utilisateur autonome qui puisse se référer.
Vous prenez le problème à l'envers. Quand vous vous intéressez à un domaine, vous vous lancez sans vous être documente AU PREALABLE?
Et bien en informatique, c'est la même chose...
Sachez qui si vous vous n' êtes pas au point de départ le reste des utilisateurs d'informatique le sont pour linux cela fait 90% du parc informatique. Ce que je viens de dire Microsoft la compris puisque les 90% l'utilise uniquement avec du BEABA pour 80% de leurs besoins. Le reste vient en fonction de la progression de chacun. La litérature n'est pas beaucoup mieux.
Si vous voulez du "simple", sachez qu'on peut apprivoiser Linux via une belle "boite à clics" qui déstabilise autant un utilisateur Lambda qu'un passage d'une version de Windows à une autre.
Pour reprendre votre exemple du chmod, je préfère le faire comme cela: http://users.swing.be/sw051431/Linux/droits.png
-- Jerome. "Fais aux autres ce que tu voudrais qu'ils te fassent, sois fier de ce que tu fais et prend du plaisir à le faire". (Linus Torvalds, "Just for fun")
Le Fri, 07 May 2004 23:53:39 +0200, amorces a écrit :
Je remarque que tous les gens intelligents m'ont répondu
avec des réflexions très savantes.
Mais moi qui suite à toutes ces réflexion est convaincu d'être un ignorant,
je constate donc que linux est fait pour une élite. Que l'utilisateur lambda
qui veut s' investir ne peut le faire dans linux.
Bien sur que si. Tout est une question de volonté (comme beaucoup de
choses dans la vie d'ailleurs...).
On parle de chmod avec des numéros mais où trouver la liste des numéro avec
les valeurs et leurs effets après des journées de recherche sur internet
alors que mon temps est compté?
Et bien si le type connait le principe de man, maintes fois exposé dans
toute doc digne de ce nom, il trouvera l'extrait suivant en tapant "man
chmod":
Une valeur numérique pour le mode est constituée de 1 à 4 chiffres en
octal (0 a 7), calculés en additionnant les bits de valeurs 4, 2, et 1.
Un bit non mentionné étant considéré comme nul. Le premier chiffre cor-
respond aux attributs Set-UID (4), Set-GID (2), et conservation du code
en mémoire ['sticky bit'] (1). Le second chiffre
correspond aux autorisations de lecture (4), écriture (2) et
exécution pour l'utilisateur propriétaire du fichier. Les
troisième et quatrième chiffres correspondent respectivement
aux autorisations d'accès pour les membres du groupe du fichier,
et pour les autres utilisateurs.
Dingue, non?
(snip postresqul)
Ce que je voulais dire , c'est que pour décoller il faut qu'il y est de la
part de la communauté linux , un site qui permet à chacun depuis le départ:
à ZERO jusqu'à un utilisateur autonome qui puisse se référer.
Vous prenez le problème à l'envers. Quand vous vous intéressez à un
domaine, vous vous lancez sans vous être documente AU PREALABLE?
Et bien en informatique, c'est la même chose...
Sachez qui si vous vous n' êtes pas au point de départ le reste des
utilisateurs d'informatique le sont pour linux cela fait 90% du parc
informatique. Ce que je viens de dire Microsoft la compris puisque les 90%
l'utilise uniquement avec du BEABA pour 80% de leurs besoins. Le reste
vient en fonction de la progression de chacun. La litérature n'est pas
beaucoup mieux.
Si vous voulez du "simple", sachez qu'on peut apprivoiser Linux via une
belle "boite à clics" qui déstabilise autant un utilisateur Lambda qu'un
passage d'une version de Windows à une autre.
Pour reprendre votre exemple du chmod, je préfère le faire comme cela:
http://users.swing.be/sw051431/Linux/droits.png
--
Jerome.
"Fais aux autres ce que tu voudrais qu'ils te fassent, sois fier de ce que tu
fais et prend du plaisir à le faire".
(Linus Torvalds, "Just for fun")
Le Fri, 07 May 2004 23:53:39 +0200, amorces a écrit :
Je remarque que tous les gens intelligents m'ont répondu avec des réflexions très savantes. Mais moi qui suite à toutes ces réflexion est convaincu d'être un ignorant, je constate donc que linux est fait pour une élite. Que l'utilisateur lambda qui veut s' investir ne peut le faire dans linux.
Bien sur que si. Tout est une question de volonté (comme beaucoup de choses dans la vie d'ailleurs...).
On parle de chmod avec des numéros mais où trouver la liste des numéro avec les valeurs et leurs effets après des journées de recherche sur internet alors que mon temps est compté?
Et bien si le type connait le principe de man, maintes fois exposé dans toute doc digne de ce nom, il trouvera l'extrait suivant en tapant "man chmod":
Une valeur numérique pour le mode est constituée de 1 à 4 chiffres en octal (0 a 7), calculés en additionnant les bits de valeurs 4, 2, et 1. Un bit non mentionné étant considéré comme nul. Le premier chiffre cor- respond aux attributs Set-UID (4), Set-GID (2), et conservation du code en mémoire ['sticky bit'] (1). Le second chiffre correspond aux autorisations de lecture (4), écriture (2) et exécution pour l'utilisateur propriétaire du fichier. Les troisième et quatrième chiffres correspondent respectivement aux autorisations d'accès pour les membres du groupe du fichier, et pour les autres utilisateurs.
Dingue, non?
(snip postresqul)
Ce que je voulais dire , c'est que pour décoller il faut qu'il y est de la part de la communauté linux , un site qui permet à chacun depuis le départ: à ZERO jusqu'à un utilisateur autonome qui puisse se référer.
Vous prenez le problème à l'envers. Quand vous vous intéressez à un domaine, vous vous lancez sans vous être documente AU PREALABLE?
Et bien en informatique, c'est la même chose...
Sachez qui si vous vous n' êtes pas au point de départ le reste des utilisateurs d'informatique le sont pour linux cela fait 90% du parc informatique. Ce que je viens de dire Microsoft la compris puisque les 90% l'utilise uniquement avec du BEABA pour 80% de leurs besoins. Le reste vient en fonction de la progression de chacun. La litérature n'est pas beaucoup mieux.
Si vous voulez du "simple", sachez qu'on peut apprivoiser Linux via une belle "boite à clics" qui déstabilise autant un utilisateur Lambda qu'un passage d'une version de Windows à une autre.
Pour reprendre votre exemple du chmod, je préfère le faire comme cela: http://users.swing.be/sw051431/Linux/droits.png
-- Jerome. "Fais aux autres ce que tu voudrais qu'ils te fassent, sois fier de ce que tu fais et prend du plaisir à le faire". (Linus Torvalds, "Just for fun")
Thierry Boudet
On 2004-05-08, luc wastiaux wrote:
unsigned char i; i = 255; i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre une question d'outils ?
Valgrind est capable de détecter que cette construction parfaitement
légale pose un problème ? Ouah, comment-fait-il exactement ?
On 2004-05-08, luc wastiaux <dustpuppy@airpost.net> wrote:
unsigned char i;
i = 255;
i++;
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux
x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre
une question d'outils ?
Valgrind est capable de détecter que cette construction parfaitement
légale pose un problème ? Ouah, comment-fait-il exactement ?
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre une question d'outils ?
Valgrind est capable de détecter que cette construction parfaitement
légale pose un problème ? Ouah, comment-fait-il exactement ?
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre une question d'outils ?
Prenons le temps d'un peu de publicité! Depuis quelques jours valgrind est aussi disponible sous FreeBSD.
--
Michel TALON
luc wastiaux <dustpuppy@airpost.net> wrote:
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux
x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre
une question d'outils ?
Prenons le temps d'un peu de publicité! Depuis quelques jours valgrind
est aussi disponible sous FreeBSD.
Pourtant si tu avais utilise la machine virtuelle Valgrind, sous linux x86, tu aurais repere ce bug a sa premiere apparition. C'est peut etre une question d'outils ?
Prenons le temps d'un peu de publicité! Depuis quelques jours valgrind est aussi disponible sous FreeBSD.
