Comment reconnaitre un bon Linuxien d'un vrai neuneu ?
832 réponses
Xandros
Salut,
Depuis les quelques mois que je suis sous Linux et que je fréquente les
Forums dédiés, j'ai pu remarquer une chose.
Il existe 3 types de personnes :
1) Les novices qui viennent du monde Windows et qui posent pleins de
questions sans vraiment chercher les réponses. J'en faisais parti, mais
je me soigne depuis ;)
2) Les neuneux de base, qui n'y connaissent pas grand chose et qui se
défoulent sur le premier novice venu. On les reconnait par leurs
réponses standards : "trop gros - passera pas" - "va chercher sur
Google" - "Prouves le" - "Vas lire MAN ou HOWTO"
En fait, il n'apportent jamais rien au débat, mais font croire qu'ils
s'y connaissent trop pour perdre leur temps avec des novices.
3) Enfin, les "vrais", ceux qui t'apportent LA solution, on les
reconnait par la simplicité de leurs réponses, un lien, une commande,
une solution quoi.
Un grand merci à eux !!!
Tout ça pour dire que le monde Linux serait bien plus simple si la 2eme
cathégorie pouvait simplement admettre qu'ils font parti de la 1er, ou
alors si ils veulent se prétendre de la 3eme, qu'ils apportent de l'aide
ou bien qu'il ferme leurs gue...le.
--
Message envoyé avec ThunderBird
Sous Linux Xandros Deluxe 3.0
la peur du chomage excuse bien des choses car les systemes pick sont oriente utilisateur et sont plus puissant que les SGBDR , les develloppeurs de SGBDR obtient des resultat moins bon que les utilisateur PICK
Il a quarante ans ton système. Il est possible qu'il arrive un jour à remplacer tout ce qui existe. Mais je ne vois pas pourquoi il arriverait à faire en très peu de temps ce qu'il n'a pas réussit à faire en quarante ans.
Ton système ne me fait absolument pas peur d'être au chômage.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
helios wrote:
la peur du chomage excuse bien des choses car les systemes pick sont
oriente utilisateur et sont plus puissant que les SGBDR , les
develloppeurs de SGBDR obtient des resultat moins bon que les utilisateur
PICK
Il a quarante ans ton système. Il est possible qu'il arrive un jour à
remplacer tout ce qui existe. Mais je ne vois pas pourquoi il arriverait
à faire en très peu de temps ce qu'il n'a pas réussit à faire en quarante
ans.
Ton système ne me fait absolument pas peur d'être au chômage.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
la peur du chomage excuse bien des choses car les systemes pick sont oriente utilisateur et sont plus puissant que les SGBDR , les develloppeurs de SGBDR obtient des resultat moins bon que les utilisateur PICK
Il a quarante ans ton système. Il est possible qu'il arrive un jour à remplacer tout ce qui existe. Mais je ne vois pas pourquoi il arriverait à faire en très peu de temps ce qu'il n'a pas réussit à faire en quarante ans.
Ton système ne me fait absolument pas peur d'être au chômage.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
helios
mais toi parle moi du fonctionnement interne de oracle quel est l'algo de
tris utilise ?
QuickSort, tu vois une raison d'utiliser un algo plus complexe en moyenne et dans le pire des cas ?
la performance optimal est une raison
comment est calculer une factoriel ? si un btree est utilise
Stirling ? Pourquoi utiliser des trucs plus complexes ?
de quel ordre est il ?
C'est peut-etre paramétrable en cherchant bien, non ?
tu sait pas
pour pick c'est un btree mais je connait pas de quel ordre
quel sont les type de pile utilise lifo fifo ou lifo ? tailles des piles ?
Pour la pile, je suppose que tu voulais demander filo, fifo ou lifo ? lifo et filo, fondamentalement, c'est la meme chose, non ?
fifo, c'est pas vraiment une pile, c'est une file... Pour la taille de la pile, j'espere qu'elle est dynamique...
tu ne sait pas
bref tu ne sait pas grand chose du fonctionnement interne de ton SGBD rassure toi j'en sait pas beaucoup plus sur le fonctionnement interne de pick
en fait si on compare les base de donnees aux voitures :
en sgbd on a
un users ou conducteur un administrateur ou garagiste un concepteur ou motoriste (ibm, .....)
mais toi parle moi du fonctionnement interne de oracle quel est l'algo
de
tris utilise ?
QuickSort, tu vois une raison d'utiliser un algo plus complexe en
moyenne et dans le pire des cas ?
la performance optimal est une raison
comment est calculer une factoriel ? si un btree est utilise
Stirling ? Pourquoi utiliser des trucs plus complexes ?
de quel ordre est il ?
C'est peut-etre paramétrable en cherchant bien, non ?
tu sait pas
pour pick c'est un btree mais je connait pas de quel ordre
quel sont les type de pile utilise lifo fifo ou lifo ? tailles des piles
?
Pour la pile, je suppose que tu voulais demander filo, fifo ou lifo ?
lifo et filo, fondamentalement, c'est la meme chose, non ?
fifo, c'est pas vraiment une pile, c'est une file... Pour la taille de
la pile, j'espere qu'elle est dynamique...
tu ne sait pas
bref tu ne sait pas grand chose du fonctionnement interne de ton SGBD
rassure toi j'en sait pas beaucoup plus sur le fonctionnement interne de
pick
en fait si on compare les base de donnees aux voitures :
en sgbd on a
un users ou conducteur
un administrateur ou garagiste
un concepteur ou motoriste (ibm, .....)
D'après ce que j'ai lu d'helios (je ne connais pas pick non plus), pick peut faire un peu plus que ça. Il peut aussi créer des utilisateurs,
Ahhh, c'est pour ça qu'ils sont si nombreux...
-- Richard
helios
"Stéphane CARPENTIER" a écrit dans le message de news:42e7f570$0$15780$
helios wrote:
la peur du chomage excuse bien des choses car les systemes pick sont oriente utilisateur et sont plus puissant que les SGBDR , les develloppeurs de SGBDR obtient des resultat moins bon que les utilisateur
PICK
Il a quarante ans ton système. Il est possible qu'il arrive un jour à remplacer tout ce qui existe. Mais je ne vois pas pourquoi il arriverait à faire en très peu de temps ce qu'il n'a pas réussit à faire en quarante ans.
parce que en 5 ans il a plus progresse que dans les 35annees precedente parce que les micro d'aujourd hui sont plus puissant que les mini d'hier parce que c'est l'evolution parce que ibm microsoft ... le develloppent
"Stéphane CARPENTIER" <stef.carpentier@gratuit.fr.invalid> a écrit dans le
message de news:42e7f570$0$15780$626a14ce@news.free.fr...
helios wrote:
la peur du chomage excuse bien des choses car les systemes pick sont
oriente utilisateur et sont plus puissant que les SGBDR , les
develloppeurs de SGBDR obtient des resultat moins bon que les
utilisateur
PICK
Il a quarante ans ton système. Il est possible qu'il arrive un jour à
remplacer tout ce qui existe. Mais je ne vois pas pourquoi il arriverait
à faire en très peu de temps ce qu'il n'a pas réussit à faire en quarante
ans.
parce que en 5 ans il a plus progresse que dans les 35annees precedente
parce que les micro d'aujourd hui sont plus puissant que les mini d'hier
parce que c'est l'evolution
parce que ibm microsoft ... le develloppent
"Stéphane CARPENTIER" a écrit dans le message de news:42e7f570$0$15780$
helios wrote:
la peur du chomage excuse bien des choses car les systemes pick sont oriente utilisateur et sont plus puissant que les SGBDR , les develloppeurs de SGBDR obtient des resultat moins bon que les utilisateur
PICK
Il a quarante ans ton système. Il est possible qu'il arrive un jour à remplacer tout ce qui existe. Mais je ne vois pas pourquoi il arriverait à faire en très peu de temps ce qu'il n'a pas réussit à faire en quarante ans.
parce que en 5 ans il a plus progresse que dans les 35annees precedente parce que les micro d'aujourd hui sont plus puissant que les mini d'hier parce que c'est l'evolution parce que ibm microsoft ... le develloppent
Nicolas Le Scouarnec
personnellement je trouve la requete pick plus naturel car meme avec l'anglais pick me semble plus simple
Sauf que le PICK reste confidentiel, plus que le SQL. Les lycéens (STG) parlent le SQL courament, alors que le PICK... Et les lycéens STG s'orientent vers des filières gestion, eventuellement secrétariat, mais pas vraiment info.
en fait cela ce resume a Pick permet au utilisateur de se passer des informaticiens en faisant leur requete eux meme mais en realite les
C'est un argument qui ne tiens pas debout. On est d'accord, du C, c'est abominable, et pourtant, il y des physiciens qui en font, ils n'ont pas une formation info complete pourtant... Alors SQL est loin d'etre insurmontable. Surtout que pour des trucs simple, c'est relativement intuitif...
-- Nicolas Le Scouarnec
personnellement je trouve la requete pick plus naturel car meme avec
l'anglais pick me semble plus simple
Sauf que le PICK reste confidentiel, plus que le SQL. Les lycéens (STG)
parlent le SQL courament, alors que le PICK... Et les lycéens STG
s'orientent vers des filières gestion, eventuellement secrétariat, mais
pas vraiment info.
en fait cela ce resume a Pick permet au utilisateur de se passer des
informaticiens en faisant leur requete eux meme mais en realite les
C'est un argument qui ne tiens pas debout. On est d'accord, du C, c'est
abominable, et pourtant, il y des physiciens qui en font, ils n'ont pas
une formation info complete pourtant... Alors SQL est loin d'etre
insurmontable. Surtout que pour des trucs simple, c'est relativement
intuitif...
personnellement je trouve la requete pick plus naturel car meme avec l'anglais pick me semble plus simple
Sauf que le PICK reste confidentiel, plus que le SQL. Les lycéens (STG) parlent le SQL courament, alors que le PICK... Et les lycéens STG s'orientent vers des filières gestion, eventuellement secrétariat, mais pas vraiment info.
en fait cela ce resume a Pick permet au utilisateur de se passer des informaticiens en faisant leur requete eux meme mais en realite les
C'est un argument qui ne tiens pas debout. On est d'accord, du C, c'est abominable, et pourtant, il y des physiciens qui en font, ils n'ont pas une formation info complete pourtant... Alors SQL est loin d'etre insurmontable. Surtout que pour des trucs simple, c'est relativement intuitif...
-- Nicolas Le Scouarnec
helios
"Stéphane CARPENTIER" a écrit dans le message de news:42e7f445$0$15780$
Yannick Patois wrote:
Un démon (appelons le pickd-login) tournant sous root attend les connections. Ce démon ne sait faire que "login: password:", une fois la personne identifiée, il fork un process user (appelons le pick-user) dans lequel tournera l'interpréteur pick.
- Certes, pickd-login tourne en root, mais son rôle est excessivement simple: validation du password et fork sous l'uid validé:
D'après ce que j'ai lu d'helios (je ne connais pas pick non plus), pick peut faire un peu plus que ça. Il peut aussi créer des utilisateurs, il peut aussi monter des périphériques. Ce qu'un utilisateur de base ne peut pas faire (ou pas n'importe quels périphériques).
pick peut le faire mais pas non plus n'importe quel utilisateur sous pick
seul l'administrateur pick peut le faire , l'administrateur pick est sous root
"Stéphane CARPENTIER" <stef.carpentier@gratuit.fr.invalid> a écrit dans le
message de news:42e7f445$0$15780$626a14ce@news.free.fr...
Yannick Patois wrote:
Un démon (appelons le pickd-login) tournant sous root attend les
connections. Ce démon ne sait faire que "login: password:", une fois la
personne identifiée, il fork un process user (appelons le pick-user)
dans lequel tournera l'interpréteur pick.
- Certes, pickd-login tourne en root, mais son rôle est excessivement
simple: validation du password et fork sous l'uid validé:
D'après ce que j'ai lu d'helios (je ne connais pas pick non plus), pick
peut faire un peu plus que ça. Il peut aussi créer des utilisateurs, il
peut aussi monter des périphériques. Ce qu'un utilisateur de base ne peut
pas faire (ou pas n'importe quels périphériques).
pick peut le faire mais pas non plus n'importe quel utilisateur sous pick
seul l'administrateur pick peut le faire , l'administrateur pick est sous
root
"Stéphane CARPENTIER" a écrit dans le message de news:42e7f445$0$15780$
Yannick Patois wrote:
Un démon (appelons le pickd-login) tournant sous root attend les connections. Ce démon ne sait faire que "login: password:", une fois la personne identifiée, il fork un process user (appelons le pick-user) dans lequel tournera l'interpréteur pick.
- Certes, pickd-login tourne en root, mais son rôle est excessivement simple: validation du password et fork sous l'uid validé:
D'après ce que j'ai lu d'helios (je ne connais pas pick non plus), pick peut faire un peu plus que ça. Il peut aussi créer des utilisateurs, il peut aussi monter des périphériques. Ce qu'un utilisateur de base ne peut pas faire (ou pas n'importe quels périphériques).
pick peut le faire mais pas non plus n'importe quel utilisateur sous pick
seul l'administrateur pick peut le faire , l'administrateur pick est sous root
Nicolas Le Scouarnec
Ben dis donc, c'est pratique pour partager des donnees ca. J'avais envisage les ACL pour gerer les autorisation inter-user, mais visiblement helios n'avait pas releve (la methode de securite d'Unix en elle meme est totalement inadapte a une base de donnees, facile d'en convenir). ou est le problem de partage plusieurs user peuvent avoir des droits sur le
meme fichier
Sans ACL, sous Unix, il y a un seul utilisateur: le priopriétaire qui a des droits. Il y a aussi un groupe d'utilisateurs, et enfin, tout le monde. Ca ne fait que trois catégorie. A moins de creer des groupes en pagaille (ce qui n'est pas possible), on est vraiment limité, il faut trouver d'autres moyens...
-- Nicolas Le Scouarnec
Ben dis donc, c'est pratique pour partager des donnees ca. J'avais
envisage les ACL pour gerer les autorisation inter-user, mais
visiblement helios n'avait pas releve (la methode de securite d'Unix en
elle meme est totalement inadapte a une base de donnees, facile d'en
convenir).
ou est le problem de partage plusieurs user peuvent avoir des droits sur le
meme fichier
Sans ACL, sous Unix, il y a un seul utilisateur: le priopriétaire qui a
des droits. Il y a aussi un groupe d'utilisateurs, et enfin, tout le
monde. Ca ne fait que trois catégorie. A moins de creer des groupes en
pagaille (ce qui n'est pas possible), on est vraiment limité, il faut
trouver d'autres moyens...
Ben dis donc, c'est pratique pour partager des donnees ca. J'avais envisage les ACL pour gerer les autorisation inter-user, mais visiblement helios n'avait pas releve (la methode de securite d'Unix en elle meme est totalement inadapte a une base de donnees, facile d'en convenir). ou est le problem de partage plusieurs user peuvent avoir des droits sur le
meme fichier
Sans ACL, sous Unix, il y a un seul utilisateur: le priopriétaire qui a des droits. Il y a aussi un groupe d'utilisateurs, et enfin, tout le monde. Ca ne fait que trois catégorie. A moins de creer des groupes en pagaille (ce qui n'est pas possible), on est vraiment limité, il faut trouver d'autres moyens...
-- Nicolas Le Scouarnec
helios
J'imagine que les administrateurs remerciés par des entreprises trop crédules ont vite réussi à vendre du support à leurs anciens employeurs :-)
pour les administrateurs et les pickmen n'imagines pas c'est le cas :-)
J'imagine que les administrateurs remerciés par des entreprises trop
crédules ont vite réussi à vendre du support à leurs anciens employeurs
:-)
pour les administrateurs et les pickmen n'imagines pas c'est le cas
:-)
J'imagine que les administrateurs remerciés par des entreprises trop crédules ont vite réussi à vendre du support à leurs anciens employeurs :-)
pour les administrateurs et les pickmen n'imagines pas c'est le cas :-)
helios
"Nicolas Le Scouarnec" nospam. invalid> a écrit dans le message de news:
la question n'est pas est ce que SQL peux gerer 128 tables mais est ce que
gerer 128 tables a la place d'une est plus performant?
A priori, oui, on n'aura pas besoin de charger tous les champs dans la mémoire, on va pouvoir commencer a faire les selections dans le bon order, pour ne manipuler qu'un nombre très faible de champs. Alors qu'avec une seule table, on va avoir mal, très mal, vu qu'on va lire l'enregistrement en entier, sans pouvoir selectionner...
avec sql tu n'as pas les outil pour travailler en multivaleur donc tu aurais ces contraintes et ensuite autre donne Pick travail en memoire virtuel donc .....
Ces documents ont l'air de décrire ce dont je veux parler: (optimisation de requetes)
L'optimisation peut-etre automatique, le SQL est un langage, on le transforme en algèbre relationelle, on l'optimise, on trouve ensuite un algo adapté suivant les index (important ca...) dispos...
-- Nicolas Le Scouarnec
"Nicolas Le Scouarnec" <root@india.ath.cx. nospam. invalid> a écrit dans le
message de news:slrndefrno.1a75.root@shiva.india.ath.cx...
la question n'est pas est ce que SQL peux gerer 128 tables mais est ce
que
gerer 128 tables a la place d'une est plus performant?
A priori, oui, on n'aura pas besoin de charger tous les champs dans la
mémoire, on va pouvoir commencer a faire les selections dans le bon
order, pour ne manipuler qu'un nombre très faible de champs. Alors
qu'avec une seule table, on va avoir mal, très mal, vu qu'on va lire
l'enregistrement en entier, sans pouvoir selectionner...
avec sql tu n'as pas les outil pour travailler en multivaleur donc tu aurais
ces contraintes et ensuite autre donne Pick travail en memoire virtuel donc
.....
Ces documents ont l'air de décrire ce dont je veux parler:
(optimisation de requetes)
L'optimisation peut-etre automatique, le SQL est un langage, on le
transforme en algèbre relationelle, on l'optimise, on trouve ensuite un
algo adapté suivant les index (important ca...) dispos...
"Nicolas Le Scouarnec" nospam. invalid> a écrit dans le message de news:
la question n'est pas est ce que SQL peux gerer 128 tables mais est ce que
gerer 128 tables a la place d'une est plus performant?
A priori, oui, on n'aura pas besoin de charger tous les champs dans la mémoire, on va pouvoir commencer a faire les selections dans le bon order, pour ne manipuler qu'un nombre très faible de champs. Alors qu'avec une seule table, on va avoir mal, très mal, vu qu'on va lire l'enregistrement en entier, sans pouvoir selectionner...
avec sql tu n'as pas les outil pour travailler en multivaleur donc tu aurais ces contraintes et ensuite autre donne Pick travail en memoire virtuel donc .....
Ces documents ont l'air de décrire ce dont je veux parler: (optimisation de requetes)
L'optimisation peut-etre automatique, le SQL est un langage, on le transforme en algèbre relationelle, on l'optimise, on trouve ensuite un algo adapté suivant les index (important ca...) dispos...
-- Nicolas Le Scouarnec
Nicolas Le Scouarnec
QuickSort, tu vois une raison d'utiliser un algo plus complexe en moyenne et dans le pire des cas ? la performance optimal est une raison
Ca veut dire quoi ? Ca n'est pas une réponse; la performance optimale, c'est d'utiliser QuickSort a moins qu'Oracle connaisse un algo révolutionnaire encore meilleur. Sinon, il y avait une réponse valable: QuickSort n'est pas le meilleur sur une liste déja triée. Il n'est bon que sur des listes dans le désorde le plus complet...
C'est peut-etre paramétrable en cherchant bien, non ? tu sait pas
pour pick c'est un btree mais je connait pas de quel ordre
Effectivement, je ne connais pas assez bien, est-ce que l'ordre d'un B-arbre ne peut pas etre calculé de manière optimale a partir des données a stocker ?
Pour la pile, je suppose que tu voulais demander filo, fifo ou lifo ? lifo et filo, fondamentalement, c'est la meme chose, non ?
fifo, c'est pas vraiment une pile, c'est une file... Pour la taille de la pile, j'espere qu'elle est dynamique... tu ne sait pas
Je sais déja pleins de trucs: ta pile elle est filo et lifo puisque c'est la meme chose. Et les files, elles sont fifo ou lilo, puisque c'est aussi la meme chose. Sinon, une pile de taille limité, ca amène a des limitations marrantes... Surtout que ca n'est pas si compliqué que ca de rendre une pile extensible...
-- Nicolas Le Scouarnec
QuickSort, tu vois une raison d'utiliser un algo plus complexe en
moyenne et dans le pire des cas ?
la performance optimal est une raison
Ca veut dire quoi ? Ca n'est pas une réponse; la performance optimale,
c'est d'utiliser QuickSort a moins qu'Oracle connaisse un algo
révolutionnaire encore meilleur. Sinon, il y avait une réponse valable:
QuickSort n'est pas le meilleur sur une liste déja triée. Il n'est bon
que sur des listes dans le désorde le plus complet...
C'est peut-etre paramétrable en cherchant bien, non ?
tu sait pas
pour pick c'est un btree mais je connait pas de quel ordre
Effectivement, je ne connais pas assez bien, est-ce que l'ordre d'un
B-arbre ne peut pas etre calculé de manière optimale a partir des
données a stocker ?
Pour la pile, je suppose que tu voulais demander filo, fifo ou lifo ?
lifo et filo, fondamentalement, c'est la meme chose, non ?
fifo, c'est pas vraiment une pile, c'est une file... Pour la taille de
la pile, j'espere qu'elle est dynamique...
tu ne sait pas
Je sais déja pleins de trucs: ta pile elle est filo et lifo puisque
c'est la meme chose. Et les files, elles sont fifo ou lilo, puisque
c'est aussi la meme chose. Sinon, une pile de taille limité, ca amène a
des limitations marrantes... Surtout que ca n'est pas si compliqué que
ca de rendre une pile extensible...
QuickSort, tu vois une raison d'utiliser un algo plus complexe en moyenne et dans le pire des cas ? la performance optimal est une raison
Ca veut dire quoi ? Ca n'est pas une réponse; la performance optimale, c'est d'utiliser QuickSort a moins qu'Oracle connaisse un algo révolutionnaire encore meilleur. Sinon, il y avait une réponse valable: QuickSort n'est pas le meilleur sur une liste déja triée. Il n'est bon que sur des listes dans le désorde le plus complet...
C'est peut-etre paramétrable en cherchant bien, non ? tu sait pas
pour pick c'est un btree mais je connait pas de quel ordre
Effectivement, je ne connais pas assez bien, est-ce que l'ordre d'un B-arbre ne peut pas etre calculé de manière optimale a partir des données a stocker ?
Pour la pile, je suppose que tu voulais demander filo, fifo ou lifo ? lifo et filo, fondamentalement, c'est la meme chose, non ?
fifo, c'est pas vraiment une pile, c'est une file... Pour la taille de la pile, j'espere qu'elle est dynamique... tu ne sait pas
Je sais déja pleins de trucs: ta pile elle est filo et lifo puisque c'est la meme chose. Et les files, elles sont fifo ou lilo, puisque c'est aussi la meme chose. Sinon, une pile de taille limité, ca amène a des limitations marrantes... Surtout que ca n'est pas si compliqué que ca de rendre une pile extensible...
